[Bug 60366] New: catalina.bat should not modify $JAVA_OPTS to add $LOGGING_MANAGER

2016-11-13 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=60366

Bug ID: 60366
   Summary: catalina.bat should not modify $JAVA_OPTS to add
$LOGGING_MANAGER
   Product: Tomcat 8
   Version: 8.5.8
  Hardware: PC
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
  Assignee: dev@tomcat.apache.org
  Reporter: icerm...@gmail.com
  Target Milestone: 

catalina.bat adds logging manager and logging configuration parameters to
JAVA_OPTS. This can cause issues when sub-processes are spawned. As far as I
understand, the sub-process tries to use java.util.logging but throws an
ClassNotFoundException because org.apache.juli.ClassLoaderLogManager is not on
classpath.

This has already been solved for catalina.sh back in 2013, see bug 54601 for
further explanations (https://bz.apache.org/bugzilla/show_bug.cgi?id=54601)

The same issuses as described in bug 54601, with Jenkins and Gradle, are still
present in the Windows version of Tomcat 8.5.8. Since the catalina.bat file
looks the same in this regard for tomcat 7 and 9 it is reasonable to believe
these versions are affected as well.

A solution similar to the one for catalina.sh solves the issue for me.

Remove the assignments to JAVA_OPTS in lines 213 and 218 and add the
LOGGING_CONFIG and LOGGING_MANAGER variables to where the JAVA_OPTS is used in
lines 336, 339, 343, 346

208 if not "%LOGGING_CONFIG%" == "" goto noJuliConfig
209 set LOGGING_CONFIG=-Dnop
210 if not exist "%CATALINA_BASE%\conf\logging.properties" goto noJuliConfig
211 set
LOGGING_CONFIG=-Djava.util.logging.config.file="%CATALINA_BASE%\conf\logging.properties"
212 :noJuliConfig
213 - set "JAVA_OPTS=%JAVA_OPTS% %LOGGING_CONFIG%"
214
215 if not "%LOGGING_MANAGER%" == "" goto noJuliManager
216 set
LOGGING_MANAGER=-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
217 :noJuliManager
218 - set "JAVA_OPTS=%JAVA_OPTS% %LOGGING_MANAGER%"

336 - %_EXECJAVA% %JAVA_OPTS% %CATALINA_OPTS% %DEBUG_OPTS% -classpath
"%CLASSPATH%"
336 + %_EXECJAVA% %LOGGING_CONFIG% %LOGGING_MANAGER% %JAVA_OPTS%
%CATALINA_OPTS% %DEBUG_OPTS% -classpath "%CLASSPATH%"

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 60367] New: null arbitrarily coerced to empty string on EL method call

2016-11-13 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=60367

Bug ID: 60367
   Summary: null arbitrarily coerced to empty string on EL method
call
   Product: Tomcat 9
   Version: 9.0.0.M13
  Hardware: PC
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
  Assignee: dev@tomcat.apache.org
  Reporter: 6s4vpwu...@snkmail.com
  Target Milestone: -

If I have a method in a Java class
public String doSomething(Boolean bValue, String sValue)

and I call this method from a JSP using
${myobject.doSomething(null, null)}

then the method is called with bValue being null, sValue being "".

This surprising behavior is caused by line 523 in
http://svn.apache.org/repos/asf/tomcat/tc9.0.x/branches/gsoc-jaspic/java/org/apache/el/lang/ELSupport.java

The code there looks like this:
if (!COERCE_TO_ZERO) {
if (obj == null && !type.isPrimitive() &&
!String.class.isAssignableFrom(type)) {
return null;
}
}

It isn't quite obvious to me why Strings are excluded from being returned as
null while all other types are allowed to pass as null.

For me currently this is more than an academic question or just a remarkable
oddity in Tomcat as I'm experiencing serious trouble implementing what I want
when I'm unable to give a String parameter as null. Some methods explicitly
expect to receive null in order to indicate something particular. It doesn't
feel like good design if I have to write an own wrapper around all these cases
with something like

public String doSomethingHack(Boolean bValue, String sValue)
{
   if (sValue!=null && sValue.isEmpty()) sValue=null;
   ref.doSomething(bValue, sValue);
}


There is no comment about why there is this hard-coded exclusion for one
arbitrary type in line 523.

Please kindly review this and consider a more consistent solution.
COERCE_TO_ZERO should either work for all types or none, but there shouldn't be
any specialties.
I necessary provide separate configuration for Strings COERCE_TO_EMPTY_STRING
although I would not consider this type of granularity good design.

Maybe the current behavior was chosen in order to avoid NPEs for some other use
cases, but these issues should be solved where values are read. The default
behavior in ELSupport.java should be that all values pass through as given as
long as types fit and unless configured otherwise.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 60362] Missing reason phrase in response

2016-11-13 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362

--- Comment #3 from Todd Pierce  ---
Reinstating the reason phrase to 8.0.x would be a good outcome.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org