[jira] Commented: (LOGGING-114) Silent Swallowing of NoClassDefFoundError
[ https://issues.apache.org/jira/browse/LOGGING-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511853 ] Simon Kitching commented on LOGGING-114: JCL has adopted the principle that logging problems should never stop an app from running. In the past exceptions from logging libs were allowed through JCL in some cases and there were loud user complaints. In many cases, the users didn't actually *want* logging output anyway, and didn't know how to fix the logging problems because they were complex and involved classloaders with different classpaths etc. So now, JCL *never* fails to init. In particular, if log4j is present but cannot be initialised (eg due to classloader problems) JCL quite deliberately ignores this problem and lets the app start. If someone really does want logging output but aren't getting what they expect *then* they can turn on JCL diagnostic output to see what's happening. I don't think there is likely to be agreement for any change to JCL's behaviour for this. Writing problems stuff to stdout etc is also unacceptable when diagnostics are not enabled. Again, this can cause problems for users who don't actually care about logging output anyway. However I would agree that when diagnostics are enabled, JCL should write out the message from the original exception. If it's not doing this then I would call that a bug. Silent Swallowing of NoClassDefFoundError - Key: LOGGING-114 URL: https://issues.apache.org/jira/browse/LOGGING-114 Project: Commons Logging Issue Type: Bug Affects Versions: 1.1.0 Environment: Various OSs, in combination with log4j 1.2.14. Reporter: Malcolm Cleaton Priority: Minor Hi. I'm using commons logging with log4j; my team ship a library which uses log4j, and some of our clients use it with commons-logging. If commons-logging is in its default configuration, and log4j is present but fails to load its configuration with an unhandled exception, the results are pretty nasty: - commons-logging silently swallows the exception and logs with something else. If diagnostics are turned on, the message is: Could not instantiate Log 'org.apache.commons.logging.impl.Log4JLogger' -- java.lang.reflect.InvocationTargetException: null - future attempts to use log4j directly get a pretty unhelpful error: java.lang.NoClassDefFoundError at org.apache.log4j.Logger.getLogger(Logger.java:117). I realise you're trying to deal with a very large number of cases in this code, but it does seem like something better could be done here. If nothing else is possible, at least recognising the InvocationTargetException and pulling out the target exception for the diagnostic log would have helped with tracking this one down. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (DIGESTER-29) [digester] Loading of resources causes webapp to fail redeploy under Tomcat 5.5.x
[ https://issues.apache.org/jira/browse/DIGESTER-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Kitching closed DIGESTER-29. -- Resolution: Fixed Fix Version/s: 1.8 Final Fixed in 1.8 release. [digester] Loading of resources causes webapp to fail redeploy under Tomcat 5.5.x - Key: DIGESTER-29 URL: https://issues.apache.org/jira/browse/DIGESTER-29 Project: Commons Digester Issue Type: Bug Affects Versions: 1.5 Final Environment: Operating System: other Platform: Other Reporter: Rich Feit Fix For: 1.8 Final Attachments: bug37034-fix.txt, strutsRedeploy.zip This was originally filed against Beehive as http://issues.apache.org/jira/browse/BEEHIVE-960 , but I've narrowed it down to either a Digester issue or a Tomcat issue. Tomcat seems to suggest that this is an issue related to getting resources out of a JAR: - http://issues.apache.org/bugzilla/show_bug.cgi?id=33830 - http://jakarta.apache.org/tomcat/faq/windows.html#lock Specifically, Tomcat turned off the behavior that prevents locking of JARs under Windows. They did this to improve startup time. I don't necessarily agree with this choice as a default, but if you believe their bug comments and FAQ, this actually just exposes Windows-specific bugs in the way resources are read out of JARs. To reproduce this: - Run 'ant build war' in the attached directory. - Copy strutsRedeploy.war into $CATALINA_HOME/webapps. - Verify that there is a fully-extracted webapp under $CATALINA_HOME/webapps/strutsRedeploy. - Copy strutsRedeploy.war (again) into $CATALINA_HOME/webapps. Now look in $CATALINA_HOME/webapps/strutsRedeploy -- it failed to redeploy, and the only file left in there is WEB-INF/lib/struts.jar. I'm attaching a Digester patch that fixes the issue. Note: the fix for this issue belongs in one of three places: - Tomcat (which has rejected working around it since it impacts startup time) - Digester - XML support in the JDK Hopefully you'll choose Digester. :) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BETWIXT-57) Class loader problem in JBoss version 4.0.4GA
[
https://issues.apache.org/jira/browse/BETWIXT-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464413
]
Simon Kitching commented on BETWIXT-57:
---
Ok, I've made this default to true. I've also ensured that when set to false,
lookup is relative to the classloader that loaded Betwixt, not the one that
loaded Digester. See r495842, r495843.
Class loader problem in JBoss version 4.0.4GA
-
Key: BETWIXT-57
URL: https://issues.apache.org/jira/browse/BETWIXT-57
Project: Commons Betwixt
Issue Type: Bug
Environment: JBoss application server version 4.0.4GA. Probably
affects most versions of JBoss
Reporter: Surjit Sen
Priority: Critical
When using betwixt in a JBoss application, Class not found exceptions get
thrown when Class.forName methods are called in classes
org.apache.commons.betwixt.digester.ElementRule and
org.apache.commons.betwixt.digester.ClassRule. Specifically the Class.forName
method uses the system class loader to load classes and in JBoss the
classpath normally does not contain the application jar files. The fix is
very simple. The Class.forName method calls in both the classes were replaced
with the following code lines in ElementRule and similar changes were made in
ClassRule as well. This fix ensures that the appropriate class loader is used
for loading classes and is similar to the fix made in log4j.
ClassLoader loader =
Thread.currentThread().getContextClassLoader();
if (loader == null) {
loader =
Class.forName(implementationClass).getClassLoader();
//Class clazz = Class.forName(implementationClass);
}
Class clazz = loader.loadClass(implementationClass);
descriptor.setImplementationClass(clazz);
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BETWIXT-57) Class loader problem in JBoss version 4.0.4GA
[
https://issues.apache.org/jira/browse/BETWIXT-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463858
]
Simon Kitching commented on BETWIXT-57:
---
Robert, I see that the new useContextClassLoader attribute defaults to false.
In Digester it defaults to false, but that is mainly because this feature was
added after Digester was already widely used and at a 1.x release. Changing the
existing behaviour would therefore not be acceptable.
Perhaps for Betwixt it should default to true instead? Or is it too late
already to change existing behaviour?
Either way, it would be nice if the javadoc indicated what the default
behaviour is...
Class loader problem in JBoss version 4.0.4GA
-
Key: BETWIXT-57
URL: https://issues.apache.org/jira/browse/BETWIXT-57
Project: Commons Betwixt
Issue Type: Bug
Environment: JBoss application server version 4.0.4GA. Probably
affects most versions of JBoss
Reporter: Surjit Sen
Priority: Critical
When using betwixt in a JBoss application, Class not found exceptions get
thrown when Class.forName methods are called in classes
org.apache.commons.betwixt.digester.ElementRule and
org.apache.commons.betwixt.digester.ClassRule. Specifically the Class.forName
method uses the system class loader to load classes and in JBoss the
classpath normally does not contain the application jar files. The fix is
very simple. The Class.forName method calls in both the classes were replaced
with the following code lines in ElementRule and similar changes were made in
ClassRule as well. This fix ensures that the appropriate class loader is used
for loading classes and is similar to the fix made in log4j.
ClassLoader loader =
Thread.currentThread().getContextClassLoader();
if (loader == null) {
loader =
Class.forName(implementationClass).getClassLoader();
//Class clazz = Class.forName(implementationClass);
}
Class clazz = loader.loadClass(implementationClass);
descriptor.setImplementationClass(clazz);
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LOGGING-110) Implement a Level class and a generic log method in Log
[ https://issues.apache.org/jira/browse/LOGGING-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Kitching updated LOGGING-110: --- Fix Version/s: 2.0 Affects Version/s: (was: 1.0.4) As there appears to be no enthusiasm for pushing this into the current release, assign for consideration in 2.0 Implement a Level class and a generic log method in Log --- Key: LOGGING-110 URL: https://issues.apache.org/jira/browse/LOGGING-110 Project: Commons Logging Issue Type: New Feature Reporter: Sebastiaan van Erk Fix For: 2.0 The Log API does not have a generic log method and there is no generic Level class. Since the levels which commons logging provides are fixed and since it would not break backwards compatibiliy I would like to suggest that these are added. To be more specific, I would like to see the following methods added: void log(Level level, Object message) Log a message with the specified log level. void log(Level level, Object message, Throwable t) Log a message and exception with the specified log level. boolean isEnabled(Level level) Is the specified logging level currently enabled? As an extra feature of the level class one could have string and integer conversions to and from log levels. These features would allow one to use commons logging in more complex situations without have to rely on specific logging implementations. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (LOGGING-108) Classloader reference leak on Tomcat 5.5.17 with log4j in webapp
[ https://issues.apache.org/jira/browse/LOGGING-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Kitching closed LOGGING-108. -- Resolution: Won't Fix As no responses were received on my last comment, closing as wontfix (tomcat/jasper issue, not JCL issue). Classloader reference leak on Tomcat 5.5.17 with log4j in webapp Key: LOGGING-108 URL: https://issues.apache.org/jira/browse/LOGGING-108 Project: Commons Logging Issue Type: Bug Affects Versions: 1.1.0 Environment: JDK 1.5.0_07, Tomcat 5.5.17 commons-logging-api-1.1.jar is configured for the Tomcat bootstrap commons-logging-adapters-1.1.jar is deployed with a webapp log4j-1.2.11 is deployed with webapp This is the configuration specifically described in the release notes for 1.1: New jar file commons-logging-adapters-xxx.jar is now provided. This can be used to resolve class cast conflicts where parts of commons-logging are deployed via different classloaders. It is not expected to be frequently used; it is only necessary in situations where a container has deployed commons-logging-api.jar and a webapp wants to bind to a third-party logging implementation such as log4j. In this case, the webapp can experience problems if it deploys commons-logging.jar as this causes duplicates of the core commons-logging classes, but commons-logging-adapters can be safely used. Reporter: Taras Tielkes Attachments: path.gif Some Tomcat Jasper implementation classes are initialized (that mean static fields and static initializer) when the current thread has the webapp classloader set as the context classloader. An example of this is org.apache.jasper.runtime.PageContextImpl If the first JSP page rendered on a freshly started Tomcat 5.5.17 is for a webapp that contains the configuration described in the Environment section above, a leak will occur: The class PageContextImpl (loader by CL above Webapp classloader in delegation chain) stays loaded for the duration of the JVM The log field in this class refers to a class loaded from a WebappClassloader. This produces a classloader reference leak to the webapp, even after undeployment. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-238) [lang] Add equals(type[]) to NumberUtils
[
http://issues.apache.org/jira/browse/LANG-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12461664
]
Simon Kitching commented on LANG-238:
-
I would agree with Stephen that an allEquals(a) method isn't likely to be
widely used. And besides, it can be implemented for non-floating-point as:
Setinteger aSet = new HashSetInteger(Arrays.asList(a));
boolean allEq = (aSet.size() = 1);
which doesn't seem to me sufficiently complicated to deserve inclusion in lang.
A containsOnly(a,b) method would be more generally useful but can be
implemented as:
SetInteger aSet = new HashSetInteger(Arrays.asList(a));
SetInteger bSet = new HashSetInteger(Arrays.asList(b));
// or if b has one element, bSet = Collections.singleton(val);
boolean contained = bSet.containsAll(aSet);
which again doesn't seem terribly complicated.
However if a more generic method is being considered, then how about:
T[] notIn(T[] a, T[] b);
which returns the elements in a that are not in b? I'm not a mathematician but
I believe this is written in set operations as a - b, or in words as the
complement of a with respect to b, so this method could also be called:
T[] subtract(T[] a, T[] b);
or
T[] complement(T[] a, T[] b);
though I think notIn is more obvious for most users.
Actually, this operation is the array equivalent of Collections.removeAll, so
that's an alternative name:
T[] removeAll(T[] a, T[] b);
The test allEquals(a, b) is then:
boolean allEq = NumberUtils.notIn(a, b).length == 0;
and the test allEquals(a) is:
boolean allEq = NumberUtils.notIn(a, new Integer[] {a[0]}).length == 0;
BTW, the a parameter is really an array representation of a bag, not a set so
maybe this set terminology could be misleading.
If such a set/bag operation is provided, then intersection and union could also
reasonably be provided for arrays:
T[] intersection(T[] a, T[] b);
T[] union(T[] a, T[] b);
Not sure whether union should treat its params as bags (in which case union
would be equivalent to concat) or sets (only one occurrence for elements in
both a and b).
At this point, this appears to be bordering on commons-collections or
commons-math functionality but as this is only for arrays I think a good
argument could be made for including this in lang..
[lang] Add equals(type[]) to NumberUtils
Key: LANG-238
URL: http://issues.apache.org/jira/browse/LANG-238
Project: Commons Lang
Issue Type: Improvement
Affects Versions: Nightly Builds
Environment: Operating System: other
Platform: Other
Reporter: Paul Benedict
Priority: Minor
Fix For: 3.0
It would be useful to add an equals() method like the current min and max
methods which take an array type and determine if all the values are equal.
I have found myself in need of this often. I have to retrieve objects from
multiple data sources in parallel to build an array of complex object. To
ensure
validity, I always compare that my sub-retrievals returned the same number of
objects as expected.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (LOGGING-25) [logging] call to getClassLoader() in LogFactoryImpl not checked for null
[ http://issues.apache.org/jira/browse/LOGGING-25?page=all ] Simon Kitching closed LOGGING-25. - Resolution: Fixed That's ok David; I've done that before :-). Marking as closed/fixed. [logging] call to getClassLoader() in LogFactoryImpl not checked for null - Key: LOGGING-25 URL: http://issues.apache.org/jira/browse/LOGGING-25 Project: Commons Logging Issue Type: Bug Affects Versions: 1.0.4 Environment: Operating System: other Platform: Other Reporter: Luke Sleeman In line 374 of LogFactoryImpl.java getClassLoader() is called: logInterface = this.getClass().getClassLoader().loadClass(LOG_INTERFACE); However, the docs for getClassLoader() state that some implementations may use null to return the system classloader. This occurs under CrEme a JVM for the PocketPC platform which some of our products run under, causing a null pointer exception. Perhaps it would be better to change line 374 to read: logClass = loadClass(LOG_INTERFACE); which seems to solve the problems I have been having. At any rate calls to getClassLoader() should be checked to ensure that they haven't returned null. In addition the error that I got: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: java.lang.NullPointerException (Caused by java.lang.NullPointerException) (Caused by org.apache.commons.logging.LogConfigurationException: java.lang.NullPointerException (Caused by java.lang.NullPointerException)) Certianly wasnt very helpfull for figuring out what is going on. - Luke -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LOGGING-25) [logging] call to getClassLoader() in LogFactoryImpl not checked for null
[
http://issues.apache.org/jira/browse/LOGGING-25?page=comments#action_12459088 ]
Simon Kitching commented on LOGGING-25:
---
Applying this patch would cause some undesirable side-effects. For example,
method logClassLoaderEnvironment uses this method to print diagnostic info.
With this patch, we would report that a certain class was loaded from the
system classloader when it is really loaded from the bootclassloader.
I think it's better to fix the place(s) where we try to dereference this loader
without checking for null. Presumably you get an exception with a stack trace
when this occurs. Can you please run the standard JCL 1.1.1 release with the
following code and post the resulting exception? (please also include the
output of java -version)
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
public class Tester {
public static Log log = LogFactory.getLog(foo);
public static void main(String[] args) {
log.error(testing);
}
}
java -Xbootclasspath/a:commons-logging-1.1.1.jar Tester
BTW, running the 1.1.1 release on Linux/java1.5 using
-Xbootclasspath/a:commons-logging-1.1.1.jar works fine. I'm pretty sure the
Apple JVM is just the Sun source code licensed by Apple and tweaked, so don't
know what could be causing a difference on Apple.
Thanks,
Simon
[logging] call to getClassLoader() in LogFactoryImpl not checked for null
-
Key: LOGGING-25
URL: http://issues.apache.org/jira/browse/LOGGING-25
Project: Commons Logging
Issue Type: Bug
Affects Versions: 1.0.4
Environment: Operating System: other
Platform: Other
Reporter: Luke Sleeman
In line 374 of LogFactoryImpl.java getClassLoader() is called:
logInterface = this.getClass().getClassLoader().loadClass(LOG_INTERFACE);
However, the docs for getClassLoader() state that some implementations may use
null to return the system classloader. This occurs under CrEme a JVM for the
PocketPC platform which some of our products run under, causing a null pointer
exception. Perhaps it would be better to change line 374 to read:
logClass = loadClass(LOG_INTERFACE);
which seems to solve the problems I have been having. At any rate calls to
getClassLoader() should be checked to ensure that they haven't returned null.
In addition the error that I got:
org.apache.commons.logging.LogConfigurationException:
org.apache.commons.logging.LogConfigurationException:
java.lang.NullPointerException (Caused by java.lang.NullPointerException)
(Caused by org.apache.commons.logging.LogConfigurationException:
java.lang.NullPointerException (Caused by java.lang.NullPointerException))
Certianly wasnt very helpfull for figuring out what is going on.
- Luke
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (LOGGING-25) [logging] call to getClassLoader() in LogFactoryImpl not checked for null
[ http://issues.apache.org/jira/browse/LOGGING-25?page=all ] Simon Kitching reopened LOGGING-25: --- Reopen due to report by David Smiley [logging] call to getClassLoader() in LogFactoryImpl not checked for null - Key: LOGGING-25 URL: http://issues.apache.org/jira/browse/LOGGING-25 Project: Commons Logging Issue Type: Bug Affects Versions: 1.0.4 Environment: Operating System: other Platform: Other Reporter: Luke Sleeman In line 374 of LogFactoryImpl.java getClassLoader() is called: logInterface = this.getClass().getClassLoader().loadClass(LOG_INTERFACE); However, the docs for getClassLoader() state that some implementations may use null to return the system classloader. This occurs under CrEme a JVM for the PocketPC platform which some of our products run under, causing a null pointer exception. Perhaps it would be better to change line 374 to read: logClass = loadClass(LOG_INTERFACE); which seems to solve the problems I have been having. At any rate calls to getClassLoader() should be checked to ensure that they haven't returned null. In addition the error that I got: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: java.lang.NullPointerException (Caused by java.lang.NullPointerException) (Caused by org.apache.commons.logging.LogConfigurationException: java.lang.NullPointerException (Caused by java.lang.NullPointerException)) Certianly wasnt very helpfull for figuring out what is going on. - Luke -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (LOGGING-111) Small patch to make debugging easier
[ http://issues.apache.org/jira/browse/LOGGING-111?page=all ]
Simon Kitching resolved LOGGING-111.
Resolution: Fixed
Small patch to make debugging easier
Key: LOGGING-111
URL: http://issues.apache.org/jira/browse/LOGGING-111
Project: Commons Logging
Issue Type: Improvement
Affects Versions: 1.1.0
Environment: Commons-Logging + Log4j
Reporter: Lilianne E. Blaze
Fix For: 1.1.1
During the last few days I had major problems trying to configure
Commons-Logging + Log4j on Glassfish.
It turned out to be related to Log4j UDPAppender, but it took me needlessly
long time to verify the problem was indeed in Log4j and not in
Commons-Logging, Glassfish or something else. Now, why am I posting it here
then - I made a small modification which logs Log4j failures more precisely,
instead of just:
[EMAIL PROTECTED] from [EMAIL PROTECTED] Could not instantiate Log
'org.apache.commons.logging.impl.Log4JLogger' --
java.lang.reflect.InvocationTargetException: null
which explains, basically, nothing, you get for example:
[EMAIL PROTECTED] from [EMAIL PROTECTED] Could not instantiate Log
'org.apache.commons.logging.impl.Log4JLogger' --
java.lang.reflect.InvocationTargetException: null
[EMAIL PROTECTED] from [EMAIL PROTECTED] ... InvocationTargetException:
java.lang.ExceptionInInitializerError: null
[EMAIL PROTECTED] from [EMAIL PROTECTED] ... ExceptionInInitializerError:
java.lang.IllegalStateException: Property layout must be set for UDPAppender
named appenderLocalhostUdp
which states clearly that Log4j was indeed loaded, and the problem was in its
configuration.
All it does is expand those two exceptions if they occurred. It could be more
general and more elegant, but this code should work in pre-1.4 Java.
Could you please include it in next build of Commons-Logging?
Attaching the patch text below.
Greetings, Lilianne E. Blaze
Index: LogFactoryImpl.java
***
D:\Work\Projects\Apache\commons-logging-custom\src\org\apache\commons\logging\impl\LogFactoryImpl.java
Base (BASE)
---
D:\Work\Projects\Apache\commons-logging-custom\src\org\apache\commons\logging\impl\LogFactoryImpl.java
Locally Modified (Based On LOCAL)
***
*** 1362,1369
--- 1362,1388
+ logAdapterClassName + ' --
+ discoveryFlaw.getClass().getName() + :
+ discoveryFlaw.getLocalizedMessage());
++ if ( discoveryFlaw instanceof
InvocationTargetException ) {
+ InvocationTargetException ite =
(InvocationTargetException)discoveryFlaw;
+ Throwable cause = ite.getTargetException();
+ logDiagnostic(... InvocationTargetException: +
+ cause.getClass().getName() + : +
+ cause.getLocalizedMessage());
++ if( cause instanceof
ExceptionInInitializerError ) {
+ ExceptionInInitializerError eiie =
(ExceptionInInitializerError)cause;
+ Throwable cause2 = eiie.getException();
+ logDiagnostic(... ExceptionInInitializerError: +
+ cause2.getClass().getName() + : +
+ cause2.getLocalizedMessage());
+ }
+ }
++ }
+ if (!allowFlawedDiscovery) {
throw new LogConfigurationException(discoveryFlaw);
}
Index: Log4JLogger.java
***
D:\Work\Projects\Apache\commons-logging-custom\src\org\apache\commons\logging\impl\Log4JLogger.java
Base (BASE)
---
D:\Work\Projects\Apache\commons-logging-custom\src\org\apache\commons\logging\impl\Log4JLogger.java
Locally Modified (Based On LOCAL)
***
*** 77,84
--- 77,86
//
static {
+
if (!Priority.class.isAssignableFrom(Level.class)) {
// nope, this is log4j 1.3, so force an
ExceptionInInitializerError
+ // note - it still works with log4j 1.3.8-alpha
throw new InstantiationError(Log4J 1.2 not available);
}
***
*** 112,117
--- 114,124
/** For use with a log4j factory.
*/
public Log4JLogger(Logger logger ) {
+ + if( logger == null ) {
+ throw new IllegalArgumentException(Warning - logger == null,
possible Log4j misconfiguration?);
+ }
+ this.name = logger.getName();
this.logger=logger;
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
[jira] Commented: (LOGGING-111) Small patch to make debugging easier
[
http://issues.apache.org/jira/browse/LOGGING-111?page=comments#action_12451127
]
Simon Kitching commented on LOGGING-111:
Looks good to me. I've committed this patch (with a couple of extra checks for
null causes).
Thanks very much for your contribution.
SVN commit: 476772 (LogFactoryImpl), 476774 (Log4JLogger).
Could you please check that this works fine for you?
Note for others: InvocationTargetException.getTargetException and
ExceptionInInitializerError.getException both exist in jdk1.2.2 (supported
platform for JCL).
Small patch to make debugging easier
Key: LOGGING-111
URL: http://issues.apache.org/jira/browse/LOGGING-111
Project: Commons Logging
Issue Type: Improvement
Affects Versions: 1.1.1
Environment: Commons-Logging + Log4j
Reporter: Lilianne E. Blaze
During the last few days I had major problems trying to configure
Commons-Logging + Log4j on Glassfish.
It turned out to be related to Log4j UDPAppender, but it took me needlessly
long time to verify the problem was indeed in Log4j and not in
Commons-Logging, Glassfish or something else. Now, why am I posting it here
then - I made a small modification which logs Log4j failures more precisely,
instead of just:
[EMAIL PROTECTED] from [EMAIL PROTECTED] Could not instantiate Log
'org.apache.commons.logging.impl.Log4JLogger' --
java.lang.reflect.InvocationTargetException: null
which explains, basically, nothing, you get for example:
[EMAIL PROTECTED] from [EMAIL PROTECTED] Could not instantiate Log
'org.apache.commons.logging.impl.Log4JLogger' --
java.lang.reflect.InvocationTargetException: null
[EMAIL PROTECTED] from [EMAIL PROTECTED] ... InvocationTargetException:
java.lang.ExceptionInInitializerError: null
[EMAIL PROTECTED] from [EMAIL PROTECTED] ... ExceptionInInitializerError:
java.lang.IllegalStateException: Property layout must be set for UDPAppender
named appenderLocalhostUdp
which states clearly that Log4j was indeed loaded, and the problem was in its
configuration.
All it does is expand those two exceptions if they occurred. It could be more
general and more elegant, but this code should work in pre-1.4 Java.
Could you please include it in next build of Commons-Logging?
Attaching the patch text below.
Greetings, Lilianne E. Blaze
Index: LogFactoryImpl.java
***
D:\Work\Projects\Apache\commons-logging-custom\src\org\apache\commons\logging\impl\LogFactoryImpl.java
Base (BASE)
---
D:\Work\Projects\Apache\commons-logging-custom\src\org\apache\commons\logging\impl\LogFactoryImpl.java
Locally Modified (Based On LOCAL)
***
*** 1362,1369
--- 1362,1388
+ logAdapterClassName + ' --
+ discoveryFlaw.getClass().getName() + :
+ discoveryFlaw.getLocalizedMessage());
++ if ( discoveryFlaw instanceof
InvocationTargetException ) {
+ InvocationTargetException ite =
(InvocationTargetException)discoveryFlaw;
+ Throwable cause = ite.getTargetException();
+ logDiagnostic(... InvocationTargetException: +
+ cause.getClass().getName() + : +
+ cause.getLocalizedMessage());
++ if( cause instanceof
ExceptionInInitializerError ) {
+ ExceptionInInitializerError eiie =
(ExceptionInInitializerError)cause;
+ Throwable cause2 = eiie.getException();
+ logDiagnostic(... ExceptionInInitializerError: +
+ cause2.getClass().getName() + : +
+ cause2.getLocalizedMessage());
+ }
+ }
++ }
+ if (!allowFlawedDiscovery) {
throw new LogConfigurationException(discoveryFlaw);
}
Index: Log4JLogger.java
***
D:\Work\Projects\Apache\commons-logging-custom\src\org\apache\commons\logging\impl\Log4JLogger.java
Base (BASE)
---
D:\Work\Projects\Apache\commons-logging-custom\src\org\apache\commons\logging\impl\Log4JLogger.java
Locally Modified (Based On LOCAL)
***
*** 77,84
--- 77,86
//
static {
+
if (!Priority.class.isAssignableFrom(Level.class)) {
// nope, this is log4j 1.3, so force an
ExceptionInInitializerError
+ // note - it still works with log4j 1.3.8-alpha
throw new InstantiationError(Log4J 1.2 not available);
}
***
*** 112,117
--- 114,124
/** For use with a log4j factory.
*/
public Log4JLogger(Logger logger ) {
+ +
[jira] Commented: (LOGGING-106) AccessControlException when loading LogFactory class without system properties permission
[ http://issues.apache.org/jira/browse/LOGGING-106?page=comments#action_12451130 ] Simon Kitching commented on LOGGING-106: Fixed by SVN r423654. Re the last paragraph above, using an AccessController too broadly is a security risk so this should not be done. AccessControlException when loading LogFactory class without system properties permission - Key: LOGGING-106 URL: http://issues.apache.org/jira/browse/LOGGING-106 Project: Commons Logging Issue Type: Bug Affects Versions: 1.1.0 Reporter: Simon Kitching The LogFactory static initializer calls createFactoryStore which calls System.getProperty. If the class doesn't have access rights to see system properties (eg when in an applet) then the LogFactory class cannot load, and hence the app is completely stuffed. I think the system property access should be wrapped in a try/catch, with any access failure behaving as if the propery is not set. In addition, we might want to use an AccessController in the static block so that a signed logging jar can be granted system property access [without having to grant all its callers that permission too]. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (LOGGING-106) AccessControlException when loading LogFactory class without system properties permission
[ http://issues.apache.org/jira/browse/LOGGING-106?page=all ] Simon Kitching resolved LOGGING-106. Resolution: Fixed AccessControlException when loading LogFactory class without system properties permission - Key: LOGGING-106 URL: http://issues.apache.org/jira/browse/LOGGING-106 Project: Commons Logging Issue Type: Bug Affects Versions: 1.1.0 Reporter: Simon Kitching The LogFactory static initializer calls createFactoryStore which calls System.getProperty. If the class doesn't have access rights to see system properties (eg when in an applet) then the LogFactory class cannot load, and hence the app is completely stuffed. I think the system property access should be wrapped in a try/catch, with any access failure behaving as if the propery is not set. In addition, we might want to use an AccessController in the static block so that a signed logging jar can be granted system property access [without having to grant all its callers that permission too]. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (LOGGING-106) AccessControlException when loading LogFactory class without system properties permission
[ http://issues.apache.org/jira/browse/LOGGING-106?page=all ] Simon Kitching reopened LOGGING-106: AccessControlException when loading LogFactory class without system properties permission - Key: LOGGING-106 URL: http://issues.apache.org/jira/browse/LOGGING-106 Project: Commons Logging Issue Type: Bug Affects Versions: 1.1.0 Reporter: Simon Kitching Fix For: 1.1.1 The LogFactory static initializer calls createFactoryStore which calls System.getProperty. If the class doesn't have access rights to see system properties (eg when in an applet) then the LogFactory class cannot load, and hence the app is completely stuffed. I think the system property access should be wrapped in a try/catch, with any access failure behaving as if the propery is not set. In addition, we might want to use an AccessController in the static block so that a signed logging jar can be granted system property access [without having to grant all its callers that permission too]. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (LOGGING-106) AccessControlException when loading LogFactory class without system properties permission
[ http://issues.apache.org/jira/browse/LOGGING-106?page=all ] Simon Kitching resolved LOGGING-106. Fix Version/s: 1.1.1 Resolution: Fixed AccessControlException when loading LogFactory class without system properties permission - Key: LOGGING-106 URL: http://issues.apache.org/jira/browse/LOGGING-106 Project: Commons Logging Issue Type: Bug Affects Versions: 1.1.0 Reporter: Simon Kitching Fix For: 1.1.1 The LogFactory static initializer calls createFactoryStore which calls System.getProperty. If the class doesn't have access rights to see system properties (eg when in an applet) then the LogFactory class cannot load, and hence the app is completely stuffed. I think the system property access should be wrapped in a try/catch, with any access failure behaving as if the propery is not set. In addition, we might want to use an AccessController in the static block so that a signed logging jar can be granted system property access [without having to grant all its callers that permission too]. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (LOGGING-106) AccessControlException when loading LogFactory class without system properties permission
[ http://issues.apache.org/jira/browse/LOGGING-106?page=all ] Simon Kitching closed LOGGING-106. -- AccessControlException when loading LogFactory class without system properties permission - Key: LOGGING-106 URL: http://issues.apache.org/jira/browse/LOGGING-106 Project: Commons Logging Issue Type: Bug Affects Versions: 1.1.0 Reporter: Simon Kitching Fix For: 1.1.1 The LogFactory static initializer calls createFactoryStore which calls System.getProperty. If the class doesn't have access rights to see system properties (eg when in an applet) then the LogFactory class cannot load, and hence the app is completely stuffed. I think the system property access should be wrapped in a try/catch, with any access failure behaving as if the propery is not set. In addition, we might want to use an AccessController in the static block so that a signed logging jar can be granted system property access [without having to grant all its callers that permission too]. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (LOGGING-107) AccessController use
[ http://issues.apache.org/jira/browse/LOGGING-107?page=all ] Simon Kitching resolved LOGGING-107. Fix Version/s: 1.1.1 Resolution: Fixed AccessController use Key: LOGGING-107 URL: http://issues.apache.org/jira/browse/LOGGING-107 Project: Commons Logging Issue Type: Bug Affects Versions: 1.1.0 Reporter: Simon Kitching Fix For: 1.1.1 A problem has been reported with 1.1 by Aaron Bruegl on 6/6/06. An AccessControlException is being thrown in an applet invoked from javascript even when the logging lib has been signed and granted permissions. LogFactoryImpl.java:1250 in the 1.1 release has this line: // try the parent classloader currentCL = currentCL.getParent(); which does seem to be a likely cause for the exception. This code should be executed under an AccessController, so that granting the logging jar the appropriate permissions can fix the problem; without this, all calling code also needs to have that permission. Maybe we should wrap method discoverLogImplementation in an AccessController, covering all cases like this? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LOGGING-110) Implement a Level class and a generic log method in Log
[ http://issues.apache.org/jira/browse/LOGGING-110?page=comments#action_12451136 ] Simon Kitching commented on LOGGING-110: You're right; sorry I got a little mixed up; trying to juggle too many things :0). What avalon doesn't support is getLogLevel(), which you are NOT proposing. As you say, all the functionality *can* be implemented for all underlying libs. The implementation for things that don't expose isEnabled(level) and log(level,msg) methods (eg Avalon) isn't terribly elegant but works, and is only a minor performance hit. For the primary targets, an extra array lookup or similar is all that's needed. The fact that introducing a new method is an incompatibility with existing external logging adapters is the biggest concern. The commons project takes compatibility very seriously; yes it's a pain but the commons libs are very widely used. Note that it should be possible to write adapters from Jdk14 logging to other libs (eg log4j), meaning that your app can use jdk14 logging as its api while still allowing users of the code to map that to whatever logging lib they prefer. It's not as easy to write such an adapter as it is for JCL due to the dumb design of jdk logging but I believe it's possible. So while I agree your proposal is sensible, I'd currently vote -0 on making this change to JCL due to compatibility issues, even on a 1.2 release. If there's enthusiasm for writing a 2.x release that has a new package name logging2 then that would avoid all compatibility issues, but I just can't see many people bothering to use such a thing. Let's see if any other commons developers have an opinion on this Implement a Level class and a generic log method in Log --- Key: LOGGING-110 URL: http://issues.apache.org/jira/browse/LOGGING-110 Project: Commons Logging Issue Type: New Feature Affects Versions: 1.0.4 Reporter: Sebastiaan van Erk The Log API does not have a generic log method and there is no generic Level class. Since the levels which commons logging provides are fixed and since it would not break backwards compatibiliy I would like to suggest that these are added. To be more specific, I would like to see the following methods added: void log(Level level, Object message) Log a message with the specified log level. void log(Level level, Object message, Throwable t) Log a message and exception with the specified log level. boolean isEnabled(Level level) Is the specified logging level currently enabled? As an extra feature of the level class one could have string and integer conversions to and from log levels. These features would allow one to use commons logging in more complex situations without have to rely on specific logging implementations. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LOGGING-110) Implement a Level class and a generic log method in Log
[
http://issues.apache.org/jira/browse/LOGGING-110?page=comments#action_12450911
]
Simon Kitching commented on LOGGING-110:
I agree it would be convenient to have a log level that can be queried and a
generic log method that takes a level.
However there are logging libraries that don't have this info available; it
would therefore not be possible for commons-logging to implement this when
wrapping those libraries. In particular, the Avalon framework's Logger class
does not suport this. Ok, this particular log lib is now rather obsolete but we
don't know how many other logging libs out there are like this.
Although you state that this would not break backwards compatibility, it
seems to me that it does; remember that users can write their own logging
adapters. Compiling an old logging class against the new API would fail.
Running an old binary logging class with the new API would work until someone
called one of the new methods at which time a MethodNotFound exception would
occur.
An alternative might be to write a LogUtils class:
Log log = LogFactory.getLog(someCategory);
if (LogUtils.isEnabled(log, Priority.WARN)) {
LogUtils.log(log, Priority.WARN, a message)
}
Where LogUtils has stuff like:
public boolean isEnabled(Log log, Priority p) {
if (p == Priority.DEBUG) {
return log.isDebugEnabled();
} else
}
This would have a performance impact, however, that would probably not make it
worthwhile using.
I'm not sure what code would make use of this new functionality anyway. Any
code that is targetted at java 1.4 or later should probably use the jdk14
logging API directly (with an alternate underlying implementation plugged in to
replace the pathetic default implementation). And application code should know
what logging lib it is distributed with and code to that lib directly. So the
only user of this stuff would be new framework or library code targetted at
java 1.3 or earlier; there's not a lot of that around I would expect...
Implement a Level class and a generic log method in Log
---
Key: LOGGING-110
URL: http://issues.apache.org/jira/browse/LOGGING-110
Project: Commons Logging
Issue Type: New Feature
Affects Versions: 1.0.4
Reporter: Sebastiaan van Erk
The Log API does not have a generic log method and there is no generic Level
class. Since the levels which commons logging provides are fixed and since it
would not break backwards compatibiliy I would like to suggest that these are
added. To be more specific, I would like to see the following methods added:
void log(Level level, Object message)
Log a message with the specified log level.
void log(Level level, Object message, Throwable t)
Log a message and exception with the specified log level.
boolean isEnabled(Level level)
Is the specified logging level currently enabled?
As an extra feature of the level class one could have string and integer
conversions to and from log levels.
These features would allow one to use commons logging in more complex
situations without have to rely on specific logging implementations.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BEANUTILS-255) ConvertUtilsBean does not support converts to a java.util.Date
[ http://issues.apache.org/jira/browse/BEANUTILS-255?page=comments#action_12446722 ] Simon Kitching commented on BEANUTILS-255: -- I'm not sure this is a good idea. Presumably this converter would use the system locale to determine how to parse the input strings. This means that 01/02/2006 will generate 01 Feb 2006 when run on a server in Europe, and 02 Jan 2006 when run on a server in the USA. That's not the kind of behaviour I would like to see a library default to. ConvertUtilsBean does not support converts to a java.util.Date -- Key: BEANUTILS-255 URL: http://issues.apache.org/jira/browse/BEANUTILS-255 Project: Commons BeanUtils Issue Type: Bug Reporter: Henri Yandell Fix For: 1.8.0 It's impossible to convert a String to a java.util.Date (see commons-user mail thread 'Digester and using of java.util.Date'). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (DIGESTER-109) FromXmlRuleSet and SetNextRule classloader issue
[ http://issues.apache.org/jira/browse/DIGESTER-109?page=comments#action_12446203 ] Simon Kitching commented on DIGESTER-109: - I'd be keener to implement support for null classloaders if I could think of a sane reason for putting libraries on -Xbootclasspath... FromXmlRuleSet and SetNextRule classloader issue --- Key: DIGESTER-109 URL: http://issues.apache.org/jira/browse/DIGESTER-109 Project: Commons Digester Issue Type: Bug Reporter: Anna Komaristaia When I start the application in Unix, there are 2 classes cause the problem: 1) The NullPointerException in FromXmlRuleSet class in the method addRuleInstances(Digester, String); 2) The NullPointerException in SetNextRule class in the method end(); Temporary solution --- I recompiled the commons-digester jar with the next changes and it's working fine in PC and Unix: Changes in the FromXmlRuleSet class 1) public static final String DIGESTER_DTD_PATH = digester-rules.dtd; 2) in the method addRuleInstances the line URL dtdURL = getClass().getClassLoader().getResource(DIGESTER_DTD_PATH); changed by URL dtdURL = this.getClass().getResource(DIGESTER_DTD_PATH); Changes In the SetNextRule class the line paramTypes[0] = digester.getClassLoader().loadClass( paramType); changed by if( digester.getClassLoader() == null ) paramTypes[0] = Class.forName(paramType); else paramTypes[0] = digester.getClassLoader().loadClass( paramType); Thanks, //Anna -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (DIGESTER-109) FromXmlRuleSet and SetNextRule classloader issue
[ http://issues.apache.org/jira/browse/DIGESTER-109?page=comments#action_12444275 ] Simon Kitching commented on DIGESTER-109: - I suggest trying this: cd $JAVA_HOME/jre find . -name *.jar There should *not* be any commons libraries in the list, just the libs that come standard with a JVM. Also check that your application's startup script doesn't use the -Xbootclasspath option to put commons libs on the JVM bootclasspath. FromXmlRuleSet and SetNextRule classloader issue --- Key: DIGESTER-109 URL: http://issues.apache.org/jira/browse/DIGESTER-109 Project: Commons Digester Issue Type: Bug Reporter: Anna Komaristaia When I start the application in Unix, there are 2 classes cause the problem: 1) The NullPointerException in FromXmlRuleSet class in the method addRuleInstances(Digester, String); 2) The NullPointerException in SetNextRule class in the method end(); Temporary solution --- I recompiled the commons-digester jar with the next changes and it's working fine in PC and Unix: Changes in the FromXmlRuleSet class 1) public static final String DIGESTER_DTD_PATH = digester-rules.dtd; 2) in the method addRuleInstances the line URL dtdURL = getClass().getClassLoader().getResource(DIGESTER_DTD_PATH); changed by URL dtdURL = this.getClass().getResource(DIGESTER_DTD_PATH); Changes In the SetNextRule class the line paramTypes[0] = digester.getClassLoader().loadClass( paramType); changed by if( digester.getClassLoader() == null ) paramTypes[0] = Class.forName(paramType); else paramTypes[0] = digester.getClassLoader().loadClass( paramType); Thanks, //Anna -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (DIGESTER-109) FromXmlRuleSet and SetNextRule classloader issue
[ http://issues.apache.org/jira/browse/DIGESTER-109?page=all ] Simon Kitching updated DIGESTER-109: Summary: FromXmlRuleSet and SetNextRule classloader issue (was: FromXmlRuleSet and SetNextRule classes not working in Unix enviroment) Hi Anna, Thanks very much for reporting this issue. I expect this isn't a unix issue specifically; I use Digester extensively on AIX and Linux and don't have this problem. In addition, I've not seen any classloader behaviour differences between unix and windows; anything like that would be a great surprise as Java is cross-platform. I've therefore edited the title of this bugreport. It's obviously a real problem, but is more likely triggered by the way your classloader environment is structured, eg running in a J2EE container when parent-first classloading is selected, and Digester is deployed in a shared dir of the container or something similar. Unfortunately, I'm concerned that your posted patch could break other users that have their J2EE container classloading set up in other ways; deciding what the correct change to make is will be tricky. By the way, the xmlrules module you're using has very little support; I'm the only regular Digester maintainer and I don't use it. If you can change to using the Digester API directly I can commit a fix for this quicker than for an xmlrules problem. However I will try to come up with a patch for you to test. Getting a fix into trunk will definitely need your help, as obviously I can't duplicate this bug on my local machine. Of course there's nothing wrong with you continuing to use your customised Digester version that works for you. Cheers, Simon FromXmlRuleSet and SetNextRule classloader issue --- Key: DIGESTER-109 URL: http://issues.apache.org/jira/browse/DIGESTER-109 Project: Commons Digester Issue Type: Bug Reporter: Anna Komaristaia When I start the application in Unix, there are 2 classes cause the problem: 1) The NullPointerException in FromXmlRuleSet class in the method addRuleInstances(Digester, String); 2) The NullPointerException in SetNextRule class in the method end(); Temporary solution --- I recompiled the commons-digester jar with the next changes and it's working fine in PC and Unix: Changes in the FromXmlRuleSet class 1) public static final String DIGESTER_DTD_PATH = digester-rules.dtd; 2) in the method addRuleInstances the line URL dtdURL = getClass().getClassLoader().getResource(DIGESTER_DTD_PATH); changed by URL dtdURL = this.getClass().getResource(DIGESTER_DTD_PATH); Changes In the SetNextRule class the line paramTypes[0] = digester.getClassLoader().loadClass( paramType); changed by if( digester.getClassLoader() == null ) paramTypes[0] = Class.forName(paramType); else paramTypes[0] = digester.getClassLoader().loadClass( paramType); Thanks, //Anna -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (DIGESTER-109) FromXmlRuleSet and SetNextRule classloader issue
[ http://issues.apache.org/jira/browse/DIGESTER-109?page=comments#action_12443997 ] Simon Kitching commented on DIGESTER-109: - Good point Henri. I had assumed that the NullPointerException Anna was reporting in FromXmlRuleSet was not from the actual line that was marked changed, but later on when dtdURL was being used or similar due to the resource only being locatable via the modified code - which is the sort of thing that odd J2EE configurations can experience. The second change just had me puzzled, but I was delaying comment until I had checked the implementation of Digester.getClassLoader(). However it does appear that Anna is experiencing getClass().getClassLoader() returning null; that explains both changes as Digester.getClassLoader would return null in that case. But that behaviour, as you say, is very odd indeed. This only occurs AFAIK if Digester.class were being loaded via the bootstrap classloader, or by the System classloader in a 1.1 (or earlier) JVM (the distinction between bootclassloader and system classloader was only introduced in 1.2). Loading a non-core library via the bootstrap classloader would be very weird indeed. Anna, you aren't using Digester in some kind of embedded system or antique JVM are you? And you're not putting commons-digester.jar into the install directory of your JVM for some reason? If not, can you please look into why you are getting a null value from Digester.getClass().getClassLoader() because I can't see how it's possible... Regards, Simon FromXmlRuleSet and SetNextRule classloader issue --- Key: DIGESTER-109 URL: http://issues.apache.org/jira/browse/DIGESTER-109 Project: Commons Digester Issue Type: Bug Reporter: Anna Komaristaia When I start the application in Unix, there are 2 classes cause the problem: 1) The NullPointerException in FromXmlRuleSet class in the method addRuleInstances(Digester, String); 2) The NullPointerException in SetNextRule class in the method end(); Temporary solution --- I recompiled the commons-digester jar with the next changes and it's working fine in PC and Unix: Changes in the FromXmlRuleSet class 1) public static final String DIGESTER_DTD_PATH = digester-rules.dtd; 2) in the method addRuleInstances the line URL dtdURL = getClass().getClassLoader().getResource(DIGESTER_DTD_PATH); changed by URL dtdURL = this.getClass().getResource(DIGESTER_DTD_PATH); Changes In the SetNextRule class the line paramTypes[0] = digester.getClassLoader().loadClass( paramType); changed by if( digester.getClassLoader() == null ) paramTypes[0] = Class.forName(paramType); else paramTypes[0] = digester.getClassLoader().loadClass( paramType); Thanks, //Anna -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (DIGESTER-107) Provide ability to capture namespace snapshots
[ http://issues.apache.org/jira/browse/DIGESTER-107?page=comments#action_12437643 ] Simon Kitching commented on DIGESTER-107: - Looks good to me. I´d be happy for this to be committed. I guess you'll be asking about when a new Digester release is due next? :-) It's probably a good time; a couple of minor bugfixes/enhancements have been made that deserve release (see RELEASE-NOTES.txt). I'm currently away on a trip (due back in two weeks) so can't offer to get anything done right now.. Provide ability to capture namespace snapshots -- Key: DIGESTER-107 URL: http://issues.apache.org/jira/browse/DIGESTER-107 Project: Commons Digester Issue Type: Improvement Affects Versions: Nightly Builds Reporter: Rahul Akolkar Attachments: DIGESTER-107-01.patch, DIGESTER-107-02.patch, DIGESTER-107.patch Attached patch adds the capability to snapshot current namespaces at any point during parsing. This is useful, for example, in Commons SCXML where the value of an attribute can contain an XPath expression which needs to be evaluated later. The testcase in the patch captures namespace snapshots for each object created by the digester. Feedback welcome. As an aside, does anyone mind if I bring the Digester JIRA versions up to date? Thanks. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (DIGESTER-107) Provide ability to capture namespace snapshots
[ http://issues.apache.org/jira/browse/DIGESTER-107?page=comments#action_12437190 ] Simon Kitching commented on DIGESTER-107: - Ok, let's go with the simplest patch (no caching). I don't think the code should be catching and ignoring Exception though (there aren't any checked exceptions thrown by the enclosed block are there?). It could either call createSaxException, or just let the original exception propagate. I think catching RuntimeException, logging it then rethrowing the original exception would be my preference, as this is such an odd case a checked exception doesn't seem worthwhile. Provide ability to capture namespace snapshots -- Key: DIGESTER-107 URL: http://issues.apache.org/jira/browse/DIGESTER-107 Project: Commons Digester Issue Type: Improvement Affects Versions: Nightly Builds Reporter: Rahul Akolkar Attachments: DIGESTER-107-01.patch, DIGESTER-107.patch Attached patch adds the capability to snapshot current namespaces at any point during parsing. This is useful, for example, in Commons SCXML where the value of an attribute can contain an XPath expression which needs to be evaluated later. The testcase in the patch captures namespace snapshots for each object created by the digester. Feedback welcome. As an aside, does anyone mind if I bring the Digester JIRA versions up to date? Thanks. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (DIGESTER-107) Provide ability to capture namespace snapshots
[ http://issues.apache.org/jira/browse/DIGESTER-107?page=comments#action_12437112 ] Simon Kitching commented on DIGESTER-107: - This looks pretty good to me. The only question I have is whether the new members of the Digester class should be private rather than protected. A protected member is effectively part of the public contract for the class, which restricts our ability to modify implementations later; I think I would personally prefer to see all the members made private, and only the new getCurrentNamespaces method be public. The Digester class is currently a mix of both approaches, but the more recent feature additions have used private members. I wonder whether cloning the map is necessary. Instead, can member currentNamespaces simply be an unmodifiable map, as a new instance is created if any namespace mappings change? Cheers, Simon Provide ability to capture namespace snapshots -- Key: DIGESTER-107 URL: http://issues.apache.org/jira/browse/DIGESTER-107 Project: Commons Digester Issue Type: Improvement Affects Versions: Nightly Builds Reporter: Rahul Akolkar Attachments: DIGESTER-107.patch Attached patch adds the capability to snapshot current namespaces at any point during parsing. This is useful, for example, in Commons SCXML where the value of an attribute can contain an XPath expression which needs to be evaluated later. The testcase in the patch captures namespace snapshots for each object created by the digester. Feedback welcome. As an aside, does anyone mind if I bring the Digester JIRA versions up to date? Thanks. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (BEANUTILS-245) Problem setting nested index property or combined property (with index property)
[ http://issues.apache.org/jira/browse/BEANUTILS-245?page=all ] Simon Kitching closed BEANUTILS-245. Resolution: Invalid Closing as requested by original poster. Problem setting nested index property or combined property (with index property) Key: BEANUTILS-245 URL: http://issues.apache.org/jira/browse/BEANUTILS-245 Project: Commons BeanUtils Issue Type: Bug Affects Versions: 1.7.0 Release Environment: Windows XP Professional, Java 5 Reporter: Pawan Kumar Shrivastava This is the specific problem, when you are setting a nested index property i.e. - list1[0].value Now i have initialized list1 as = new ArrayList(). Obviously the size is 0. So PropertyUtils uses List.set(index, value) method, which throws IndexOutOfBoundsException as the size and index are same. I think it should check the index and size first and then decide whether to call add(index, value) or set(index, value). Please let me know, if my understanding is wrong. One potential misuse i can see is what if someone passes index 100. But not sure if this can be resolved by somehow shrinking the list. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (LANG-276) MutableBigDecimal and MutableBigInteger
MutableBigDecimal and MutableBigInteger --- Key: LANG-276 URL: http://issues.apache.org/jira/browse/LANG-276 Project: Commons Lang Issue Type: New Feature Reporter: Simon Kitching Priority: Minor The mutable package covers most of the standard immutable data-types, but not BigDecimal or BigInteger. I actually had a need for a mutable BigDecimal today (money amount out parameter) and noticed the lack. With these two done, that would be all subclasses of java.lang.Number covered... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (COLLECTIONS-218) CollectionUtils.select() does not return passed in collection
[ http://issues.apache.org/jira/browse/COLLECTIONS-218?page=comments#action_12422391 ] Simon Kitching commented on COLLECTIONS-218: I was a little surprised by the comment that changing void-non-void was binary incompatible, so I checked - and this is indeed the case. Thought I'd just add this comment to confirm it for anyone else wondering. It's a little odd, as method selection during compilation depends only on the parameter types, but my simple test shows it clearly: Exception in thread main java.lang.NoSuchMethodError: Target.process(Ljava/lang/String;)V that V at the end indicates the void return type. There is no longer a Target.process method taking String and returning void (because it was modified to return String) so..boom. Therefore I have to agree with Steven that unfortunately this change can't be applied. CollectionUtils.select() does not return passed in collection - Key: COLLECTIONS-218 URL: http://issues.apache.org/jira/browse/COLLECTIONS-218 Project: Commons Collections Issue Type: Improvement Components: Core Affects Versions: 3.2 Reporter: Stephen Kestle Assigned To: Stephen Colebourne Attachments: CollectionUtils select return.patch collect has the following methods: Collection collect(Collection inputCollection, final Transformer transformer) Collection collect(Collection inputCollection, final Transformer transformer, final Collection outputCollection) The first creates an ArrayList(), where the second takes an outputCollection and, for convenience, returns it. Select (and selectReject) currently the following methods: Collection select(Collection inputCollection, Predicate predicate) void select(Collection inputCollection, Predicate predicate, Collection outputCollection) I propose changing the bottom method to return the passed in outputCollection. It would simplify calling code. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (LOGGING-25) [logging] call to getClassLoader() in LogFactoryImpl not checked for null
[ http://issues.apache.org/jira/browse/LOGGING-25?page=all ] Simon Kitching closed LOGGING-25. - Resolution: Fixed As there has been no response from original poster, this is being closed presumed fixed. [logging] call to getClassLoader() in LogFactoryImpl not checked for null - Key: LOGGING-25 URL: http://issues.apache.org/jira/browse/LOGGING-25 Project: Commons Logging Issue Type: Bug Affects Versions: 1.0.4 Environment: Operating System: other Platform: Other Reporter: Luke Sleeman In line 374 of LogFactoryImpl.java getClassLoader() is called: logInterface = this.getClass().getClassLoader().loadClass(LOG_INTERFACE); However, the docs for getClassLoader() state that some implementations may use null to return the system classloader. This occurs under CrEme a JVM for the PocketPC platform which some of our products run under, causing a null pointer exception. Perhaps it would be better to change line 374 to read: logClass = loadClass(LOG_INTERFACE); which seems to solve the problems I have been having. At any rate calls to getClassLoader() should be checked to ensure that they haven't returned null. In addition the error that I got: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: java.lang.NullPointerException (Caused by java.lang.NullPointerException) (Caused by org.apache.commons.logging.LogConfigurationException: java.lang.NullPointerException (Caused by java.lang.NullPointerException)) Certianly wasnt very helpfull for figuring out what is going on. - Luke -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LOGGING-108) Classloader reference leak on Tomcat 5.5.17 with log4j in webapp
[ http://issues.apache.org/jira/browse/LOGGING-108?page=comments#action_12422527 ] Simon Kitching commented on LOGGING-108: Thanks for reporting this. Your analyis is excellent, thanks. however I think this is really the responsibility of the tomcat/jasper team to fix, though. As you say, jasper classes present in the container classpath contain static references to Log objects, and this is just plain wrong: http://wiki.apache.org/jakarta-commons/Logging/StaticLog Any sane logging library is going to have problems if this is done. The fix is probably to make that Log member non-static. One solution is to remove all commons-logging libs from the webapp completely (and ensure log4j is deployed at the container level). In this setup, the only log4j adapter class (Log4JLogger) is the one loaded by the container classloader so its existence won't lock the webapp classloader. However that does mean you lose the ability to configure your logging per-webapp. Actually, log4j does have its own approach to providing per-webapp configurability, even when only one instance of log4j is in the classpath. See: http://www.qos.ch/logging/sc.jsp Here's another example using log4j's hierachy stuff: http://wiki.jboss.org/wiki/Wiki.jsp?page=Log4jRepositorySelector In both cases, the code doesn't look quite right to me; It holds a HashMap keyed by context classloader, so that will effectively lock the webapp classloader :-). A weak hashmap should do the trick though, in most cases. Or a ContextListener in your webapp that calls a method on the selector class to clear out the entry for the webapp classloader. Classloader reference leak on Tomcat 5.5.17 with log4j in webapp Key: LOGGING-108 URL: http://issues.apache.org/jira/browse/LOGGING-108 Project: Commons Logging Issue Type: Bug Affects Versions: 1.1 Final Environment: JDK 1.5.0_07, Tomcat 5.5.17 commons-logging-api-1.1.jar is configured for the Tomcat bootstrap commons-logging-adapters-1.1.jar is deployed with a webapp log4j-1.2.11 is deployed with webapp This is the configuration specifically described in the release notes for 1.1: New jar file commons-logging-adapters-xxx.jar is now provided. This can be used to resolve class cast conflicts where parts of commons-logging are deployed via different classloaders. It is not expected to be frequently used; it is only necessary in situations where a container has deployed commons-logging-api.jar and a webapp wants to bind to a third-party logging implementation such as log4j. In this case, the webapp can experience problems if it deploys commons-logging.jar as this causes duplicates of the core commons-logging classes, but commons-logging-adapters can be safely used. Reporter: Taras Tielkes Attachments: path.gif Some Tomcat Jasper implementation classes are initialized (that mean static fields and static initializer) when the current thread has the webapp classloader set as the context classloader. An example of this is org.apache.jasper.runtime.PageContextImpl If the first JSP page rendered on a freshly started Tomcat 5.5.17 is for a webapp that contains the configuration described in the Environment section above, a leak will occur: The class PageContextImpl (loader by CL above Webapp classloader in delegation chain) stays loaded for the duration of the JVM The log field in this class refers to a class loaded from a WebappClassloader. This produces a classloader reference leak to the webapp, even after undeployment. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (LOGGING-106) AccessControlException when loading LogFactory class without system properties permission
AccessControlException when loading LogFactory class without system properties permission - Key: LOGGING-106 URL: http://issues.apache.org/jira/browse/LOGGING-106 Project: Commons Logging Type: Bug Versions: 1.1.0 Reporter: Simon Kitching The LogFactory static initializer calls createFactoryStore which calls System.getProperty. If the class doesn't have access rights to see system properties (eg when in an applet) then the LogFactory class cannot load, and hence the app is completely stuffed. I think the system property access should be wrapped in a try/catch, with any access failure behaving as if the propery is not set. In addition, we might want to use an AccessController in the static block so that a signed logging jar can be granted system property access [without having to grant all its callers that permission too]. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (LOGGING-107) AccessController use
AccessController use Key: LOGGING-107 URL: http://issues.apache.org/jira/browse/LOGGING-107 Project: Commons Logging Type: Bug Versions: 1.1 Final Reporter: Simon Kitching A problem has been reported with 1.1 by Aaron Bruegl on 6/6/06. An AccessControlException is being thrown in an applet invoked from javascript even when the logging lib has been signed and granted permissions. LogFactoryImpl.java:1250 in the 1.1 release has this line: // try the parent classloader currentCL = currentCL.getParent(); which does seem to be a likely cause for the exception. This code should be executed under an AccessController, so that granting the logging jar the appropriate permissions can fix the problem; without this, all calling code also needs to have that permission. Maybe we should wrap method discoverLogImplementation in an AccessController, covering all cases like this? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-224) The parser always try to load the DTD even if validate = false
[ http://issues.apache.org/jira/browse/JELLY-224?page=comments#action_12359135 ] Simon Kitching commented on JELLY-224: -- As Paul says, loading the DTD is required, for things like entity definitions or default attribute definitions. See the xml specs for attribute standalone. However there should be some mechanism for registering a local copy of DTD to use rather than fetching the URL specified in the SYSTEM attribute. If this doesn't exist in Jelly then it should do... The parser always try to load the DTD even if validate = false -- Key: JELLY-224 URL: http://issues.apache.org/jira/browse/JELLY-224 Project: jelly Type: Bug Components: taglib.xml Environment: Working of line or behind a proxy Reporter: Philippe Kernevez The tag ixml:parse/i always try to load the DTD even if the attribut ivalidate=false/i is used. This cause an error when we use this tag without connection. See: the linked issue http://jira.codehaus.org/browse/MPDASHBOARD-34 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
