[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]
Re: [logging] JCL in SLF4J flavour - a demo for discussion
On Mon, 2007-03-26 at 15:51 +0200, Oleg Kalnichevski wrote: On Fri, 2007-03-23 at 19:56 +0100, Boris Unckel wrote: Hello, I have seen the recent discussions on JCL 2.0.0 and a version without autodiscovery. Someone stated to stop any further development (with good reasons behind) but I am thinking different. Please have a look at the (working) code: https://issues.apache.org/jira/browse/LOGGING-112 It has a static binding, some improvements in the logfactories (recognizes native implementations). API and implementations are cleanly separated, the 1.1.x diagnostic function is still used. What are your thoughts? Is this a possible direction? Hi Boris, I think this patch represents the way I personally would like to see JCL evolve in the future. If JCL 2.0 were being developed along these lines, I (personally) would be very inclined to continue using JCL for the next major version of HttpClient. Would you both mind explaining what benefits you see in a new JCL implementation that cannot be obtained via java.util.logging? I'm no fan of the j.u.l design, but it seems to me less effort to use it than to fight it. What have I not understood? And what would a new JCL do for anyone that they could not do by just using SLF4J via its JCL API? The SLF4J team have already done a lot of hard work; what benefit would there be to duplicating that? Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] New committer - Stephen Kestle
+1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] JCL sans auto-discovery?
On Sat, 2007-03-17 at 16:23 +0100, Torsten Curdt wrote: On 17.03.2007, at 15:20, Oleg Kalnichevski wrote: Folks, Please correct me if I am wrong, but the auto-discovery mechanism in Commons Logging is believed to be the only major gripe about JCL. What happened to the idea of releasing a version of JCL that retains the full API compatibility with JCL 1.0.x and 1.1.x but with the auto-discovery mechanism removed / disabled per default? Good question I also really liked that idea. But I guess someone just have to do it. ...but you don't have to wait for that - write your own LogFactory implementation. At least that's what we did. To disable auto-discovery, just use an environment variable to specify which system you want, eg org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JLogger This is described in the user guide: http://jakarta.apache.org/commons/logging/guide.html However writing your own LogFactory is also a reasonable solution; it's only a handful of methods, all with trivial implementations. What was being considered for JCL was distributing one JCL version for each supported logging lib, in a way similar to SLF4J. However that requires a fair amount of work and it doesn't appear that anyone is particularly interested in tackling this. Or you could use SLF4J which (I believe) does provide one-jar-per-supported-lib and provides commons-logging compatibility. Possibly it would be a good idea to provide a simple JCL-to-java.util.logging mapping, as most apps should probably be using java.util.logging now. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] 1.1.1 release?
On Sat, 2007-03-10 at 03:38 +0100, Torsten Curdt wrote: Definitely happy to give M2 a try; but I'd rather not change the groupId on a bugfix release. We already have an M2 release in FileUpload that didn't change the groupid so that's not a worry. Plus I want to get it done quickly :) Ah ...my +1 for changing the groupId was not meant for this bugfix release. It would be good to change it for new major releases though. I expect that this will be the last ever release of commons-logging. There are no features missing, no known bugs, and as support for java 1.4 is now generally universal there is no reason for applications not to use the java.util.logging API directly. Note that java.util.logging is an *API*, and the implementation bundled in Sun's jdk is not the only choice (see JULI for example). Changing the group-id is something that can only be done on a release, so it seems sensible to do it for 1.1.1 even if this is just a bugfix release. Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] 1.1.1 release?
On Fri, 2007-03-09 at 17:51 -0800, Henri Yandell wrote: On 3/9/07, Dennis Lundberg [EMAIL PROTECTED] wrote: Henri Yandell wrote: Anyone mind if I kick off a 1.1.1 release? It looks like it's utterly ready and just needs to be rolled and voted on. Hen I've been meaning to do this for a long time. There are a couple of questions to consider before rolling the release: 1. How should it be built? Ant, Maven 1 or Maven 2. I've been working on the Maven 2 build and feel confident about in it now. Was kind of hoping that logging-1.1.1 would be the first commons release to use Maven 2, but I can be persuaded. 2. If we decide to use Maven 2 we should really change the groupId. This needs to be carefully thought through. Anyway, I'm here to assist in any way can, if you want to be release manager for this. Definitely happy to give M2 a try; but I'd rather not change the groupId on a bugfix release. We already have an M2 release in FileUpload that didn't change the groupid so that's not a worry. Plus I want to get it done quickly :) I'm keen to see it built using maven2. However the problem is that maven2 requires java1.4 to run while we want the resulting binary to work in java1.2. Option 1 is for the maven buildfile to ensure that all compilation and unit tests are done with an external jdk of version 1.2. That's tricky though. Option 2 is to build the release with whatever version you want (eg 1.6) but use target=1.2, then test with 1.2 to ensure that there are no dependencies on methods not available in earlier jdks. This sounds better to me. I think it would be possible to create a very simple ant file that can be run with java 1.2 (on windows probably, as java1.2 is a pain to install on linux). This ant file would use an existing jar and precompiled unit tests, and just re-execute those unit tests with the old jdk. I have been meaning to set this up for a long while now but just cannot find the time.. Cheers, Simon - 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]
Re: [io] Inner class exception
On Thu, 2007-01-11 at 21:37 -0800, Henri Yandell wrote: Yeah, I'm quite interested in what the response is to having this in the API. It's novel (for me), but could be interesting to release IO as is and see what feedback we get from users on the feature. My $0.02: I'm quite happy with an Exception being a (presumably static) inner class. It's just a mechanism for namespacing, like java packages, nothing very unusual. All java programmers should be familiar with inner classes; if not, it's time they learnt :-). - 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]
Re: [VOTE] Promote commons-site to proper and release it
On Sat, 2007-01-13 at 02:16 +0100, Dennis Lundberg wrote: I have laid the finishing touches to commons-skin and feel that it is ready for prime time. Therefor I would like to propose two votes: 1. Promote commons-skin from commons sandbox to commons proper. +1 2. Release commons-skin 1.0 based on revision 495809. I have not created an RC for it, since it is in the sandbox. If that is needed, I'll do it once the move to commons proper has been completed. +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction] svn commit: r494203 - in /jakarta/commons/proper/transaction/trunk: RELEASE-NOTES.txt src/java/org/apache/commons/transaction/file/ResourceManager.java
On Wed, 2007-01-10 at 14:12 -0500, Rahul Akolkar wrote: On 1/10/07, Joerg Heinicke [EMAIL PROTECTED] wrote: Rahul Akolkar rahul.akolkar at gmail.com writes: Generally speaking, an interface-compatible change will at most change the private interface of a component, or simply add classes, methods and attributes whose use is optional to both internal and external interface clients. And this is not. In which way is it different from simply add [..] methods [..] whose use is optional to both internal and external interface clients. ?? Even simply replacing the former jar with the next version should work as the client does not know about the new methods. Only recompilation of implementations need adaptions before but that's not what I consider a use or a client. snip/ I suspect that bit is talking about Java classes (rather than interfaces), though I haven't tried to hunt it down in the guide. I flagged what I thought would lead to a versioning discussion at 1.2 voting time. There is a section in the java specification that defines precisely what binary compatibility involves, and adding a method to an interface definitely breaks it. This is an *object oriented* library we are talking about here, so use includes implementing any public interfaces, subclassing any non-final classes and overriding any public or protected methods. Unless explicitly documented, we cannot assume that users of an open-source library restrict themselves to just calling the existing classes. If the interfaces had been explicitly documented as being not intended for user implementation then this might be ok. Or if they had been placed in a special package, as Eclipse does, to explicitly separate internal from external apis. However if neither of these have been done, then I would personally expect these APIs to be binary-compatible, *at least* without a major version number update. In the branch for digester 2.x, I explicitly indicated the binary stability expectations for the Action interface: http://svn.apache.org/repos/asf/jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/Action.java Note that this is still experimental work, and I haven't received feedback from the commons community on whether this sort of comment would be considered adequate to allow an interface change in a minor release, but IMO without an indication of this sort an API really shouldn't change (without a major release at least). Ideally, existing public interfaces should not be changed *at all*, eg by introducing a new interface rather than changing the existing one. In cases where an application uses two different libraries that both depend on a commons lib, the existence of different versions of the commons lib with the same package names but different APIs can cause major headaches. As Rahul says this situation may well draw -1 votes at release time. We all want commons projects to have a good reputation for API stability. There have been mistakes made in the past, causing a lot of negative user feedback. Yes, it can be a hassle for development. However the reason that commons is a good place to host libraries is because commons is trusted, and that's because the software development processes here are reasonably strict. Writing libraries is hard - and quite different from writing full applications (eg tomcat, ant) or frameworks. Regards, Simon - 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]
Re: [all] jarfiles in svn
On Sun, 2007-01-07 at 17:08 +, Joerg Heinicke wrote: Martin Cooper martinc at apache.org writes: In general I don't like the need for internet access on build time. This is a red herring. One way or another, you're going to have to get the jars from the network, whether it's getting them from SVN, or having Maven or Ant retrieve them. And in all of those three cases, once you have them on your local machine, you don't need the network to build the next time. There is one big difference: With everything in the src jar or at least in the svn checkout your requirements are less sophisticated than with the build system. For src jar I only need a browser, for svn checkout I need a svn client, but for Ant and Maven I need additionally Java and the build environment itself. And this is a big difference if the machine with internet access is not your local machine. I've got no objection to commons-transaction providing a custom download, eg commons-transactions-6.7-src-all.tgz which contains jars if you feel this would make users happy. However no other commons project has done this AFAIK, and I don't see any complaints on the user lists. When using maven, only the first run needs to download the jars; thereafter they are cached locally. So, no need for internet access at build time. For ant, have a look at the build.xml file in logging that I provided a link to; it defines a separate getlibs task to download the jars. This can be run *once* to download the jars, but is not part of the main build task, so there is no need for internet access at build time. Re your maven issues: it's not mandatory to use maven to create builds; ant is fine. Providing both is even better. It's only the jars issue that is being discussed. (I speak from experience. In my company I get access to the internet only via a terminal server. There is no build environment. For proposed changes in the build I need to download all dependencies by hand.) A poor corporate internet access policy at one company is *NOT* a good justification for misusing the Apache SVN repository. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[all] jarfiles in svn
Hi, I noticed (due to a recent commit message) that commons-transaction has jarfiles checked in to svn, eg http://svn.apache.org/repos/asf/jakarta/commons/proper/transaction/trunk/lib/ What's the general policy on this? Sorry if this has been discussed before; I don't remember it. Personally, I really really dislike jarfiles in the version control system. For a start, if every project were to do this, the impact on the Apache SVN repository would be huge. I would instead prefer to see ant builds using get to download jars as needed. The maven repositories can be used as a convenient source for the jars, eg http://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk/build.xml BTW, note that there is *no* way to remove a file from SVN once it is committed short of a repo dump/restore (which is a major effort on a repo the size of Apache). A svnadmin obliterate command is about the oldest outstanding feature request... Regards, Simon - 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]
Re: [logging] Using Maven 2 for everything
On Sat, 2006-12-30 at 02:27 +0100, Dennis Lundberg wrote: Hi all I've spent some time going over the pom.xml file and using Maven 2 to build all the jars. These jars were then compared to the ones created with the ant build. Here's a rundown on the differences I found: 1. The M2 jars is missing parts of the manifest. As you might have seen in the commits I have now added the missing manifest parts to the jars. Yep, thanks! 2. The manifests have a couple of other lines that are different. Where ant has: Ant-Version: Apache Ant 1.6.5 Created-By: 1.4.2_13-b06 (Sun Microsystems Inc.) M2 has: Archiver-Version: Plexus Archiver Created-By: Apache Maven Built-By: dlg01 Build-Jdk: 1.4.2_13 This has to do with what program is used to create the jar, and doesn't seem that important. Agreed. 3. The class files in the test jars are different. It turned out that the ant build does not set source.version and target.version when compiling the test classes. After adding that to the ant build, the class files are equal. Should I commit my patched build.xml file? Yes. 4. The M2 jars has the files pom.properties and pom.xml in the /META_INF/maven/commons-logging/commons-logging/ directory. To summarize: I feel confident that the jars produced by Maven 2 are equivalent to the ones produced by Ant. So Maven 2 could be used to produce the jars for the next release of commons-logging. That's great. Still to check: A. The site. To enable the M2 site build all it takes is a src/site/site.xml file and to bump the version of commons-parent to 2-SNAPSHOT. I have these changes made locally. Commons-skin is not perfect yet, but it's getting there. It shouldn't be that long. I'm still trying to solve Phil's rendering problem. Should I commit the site.xml file? Yes please. I guess this would mean that a logging release is now blocked on a commons-parent 2.0 release, but that seems ok to me. At least now we can switch to maven2 for nightlies and get the user community testing what is pretty close to a release candidate.. B. Distributions. As far as I can see we need to have source and binary distros as well. I'll have a look at producing these with M2 as well. That would be cool. Having a -src jarfile for the next JCL release would be great. Cheers, Simon - 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]
Re: [VOTE] Release Digester 1.8
On Wed, 2006-11-29 at 15:20 -0500, Rahul Akolkar wrote: Towards RC3 as 1.8: http://people.apache.org/~rahul/commons/digester/rc3/ [ ] +1 I support this release [ ] +0 [ ] -0 [ ] -1 I do not support this release because... Vote closes no sooner than Saturday, Dec 2nd (ping if you need more time). +0 The process followed seems to be fine, and I'm not aware of any issues, but unfortunately don't have enough time to check the RC myself, so don't feel I can contribute a +1. Regards, Simon - 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:
http://issues.apache.org/jira
[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]
Re: [logging] 1.1.1? (was Re: Digester 1.8-RC1 available)
On Sat, 2006-11-18 at 13:58 +0100, Dennis Lundberg wrote: I can help with preparing a 1.1.1 release. Great! I'm currently cleaning up JIRA for LOGGING. So far I've gone through Versions and have removed the non-JCL versions that came over in the transition from Bugzilla. A bunch of issues that had not been resolved have now been Resolved. Issues that had a Fix for: 1.1.0 have been closed. The issues for earlier releases that have been Resolved but not Closed, I have left untouched. Simon, would you mind adding Fix for and Resolution on the issues that you have solved? This would help us get a feel for what is left to do. LOGGING-106 and LOGGING-107 have now been marked as fixed for 1.1.1. LOGGING-111 will hopefully be included; waiting for confirmation from the original poster that the patch works for her. LOGGING-110 is probably not for this release (if ever). All the others are not for this release (probably not for any release, but IMO they are worth keeping open). Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] 1.1.1? (was Re: Digester 1.8-RC1 available)
On Fri, 2006-11-17 at 19:36 -0500, Rahul Akolkar wrote: What work are you referring to? As a point release, we should focus on things fixed + pom update (also fixed). What else? I'm not aware of anything that's outstanding (exception LOGGING-111, awaiting feedback from original poster). Oh, and we should move logging to the maven2 nightly build list. I'm surprised that logging builds with maven1 at all, but it certainly doesn't run the unit tests. Either ant or maven2 should be used for building nightlies. The problem with JCL releases is that they are hard to do and hard to test, so take quite a bit of time to get done. snip/ Yup, it will help if someone familiar with logging RMs it. Robert Yoohoo. If Robert Donkin is not available I guess I could do it, but I know how awkward the release is; not sure when I could find time to do this. Getting java 1.2 running on my machine would be the first goal.. Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[logging] Re: svn commit: r476429 - /jakarta/commons/proper/logging/trunk/pom.xml
On Fri, 2006-11-17 at 21:19 -0700, Wendy Smoak wrote: On 11/17/06, Simon Kitching [EMAIL PROTECTED] wrote: Are you saying that if you mark the dependencies optional, you get compilation errors? That doesn't sound right. Well, that's exactly what happens. Found it. Optional is not a scope, it's a separate element. Instead of scopeoptional/scope, use optionaltrue/optional. Thank you Wendy! That makes a whole lot more sense. It would be really nice if Maven would report an error if the scope value is invalid rather than silently ignoring the dependency completely (as 2.0.4 evidently does). I'll try to check with mvn trunk and request an enhancement if this behaviour is still the same (unless someone has the latest maven trunk checked out and can check more easily?). Regards, Simon - 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]
Re: [all] Digester 1.8-RC1 available
On Fri, 2006-11-17 at 17:39 -0500, Rahul Akolkar wrote: On 11/17/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 11/17/06, Rahul Akolkar [EMAIL PROTECTED] wrote: http://people.apache.org/~rahul/commons/digester/ Notes: * The site requires manual installation of the 1.8 directory on the webserver; since this can't/shouldn't be done until the release vote actually passes, there are several 404s on the site home page (that will get filled in) * Going to JCL 1.1 we should be aware of MEV-392 [1], and whether that warrants staying at 1.0.4 Or maybe just do a C-L 1.1.1 that fixes this, and depend on that instead? Digester is certainly not the only downstream C-L user this would affect. snip/ Correct, though that needs a separate discussion (which we should probably be having anyway) and a release. What do others think? I'm keen to see a JCL 1.1.1 release out if there is enthusiasm for others to work on this. There are a couple of minor bugfixes since 1.1 that are also worth pushing out (see the release notes). The problem with JCL releases is that they are hard to do and hard to test, so take quite a bit of time to get done. http://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk/RELEASE-NOTES.txt Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sorry to bother - can't build Jelly
Hi Darryl, In future, please send emails to the user list rather than this one (see the jelly home page for mailing list details): http://jakarta.apache.org/commons/jelly/ ie please don't reply to this; if you have any further questions start an email on the user list. When posting to that list, please put the commons component in the subject line, eg [jelly] need help building from source Jelly doesn't support maven 2.x yet (pom.xml file), just maven 1.x (project.xml). And the command you want is: maven package or maven install not maven jar Regards, Simon On Wed, 2006-11-15 at 15:16 -0800, Darryl Fenwick wrote: I'm writing to the nag e-mail address with the (perhaps vain) hope that someone can help me. I have followed the instructions for building Jelly on the web page but can't get anywhere. I am completely inexperienced with maven so perhaps I am doing something wrong. (1) I downloaded maven-2.0.4 binary distribution (2) I downloaded with svn the latest code from the cvs repository (3) I cd'd to the Jelly directory, where there is a project.xml (4) I set MAVEN_HOME to where I installed maven (5) I call %MAVEN_HOME%\bin\mvn jar I get the following message [INFO] Scanning for projects... [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Invalid task 'jar': you must specify a valid lifecycle phase, or a goal in the format plugin:goal or pluginGroupI d:pluginArtifactId:pluginVersion:goal [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 second [INFO] Finished at: Wed Nov 15 15:14:51 PST 2006 [INFO] Final Memory: 1M/2M [INFO] what am I doing wrong? I'd love to start testing out Jelly because I think it is an answer to a very specific problem I am having. Many thanks, Darryl Darryl Fenwick Senior Product Manager Streamsim Technologies, Inc 204 Ramona St Palo Alto, CA 94301 +1 650 557 2196 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Maven2 POM Question
On Fri, 2006-11-17 at 18:52 -0800, Craig McClanahan wrote: The pom.xml file for Commons Logging in the trunk has an interesting approach to declaring dependencies, based on the existence or non-existence of a file named commons-logging-README.txt. AFAICT, the purpose for this is to make the dependencies non-optional when you are building Commons Logging itself, but optional for downstream users. Is that a correct understanding of the purpose? If so, we should really document this in the pom.xml file, so others don't have to puzzle out the thinking. Sorry :-). That's exactly the purpose. I'll add a comment now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r476429 - /jakarta/commons/proper/logging/trunk/pom.xml
On Fri, 2006-11-17 at 20:53 -0700, Wendy Smoak wrote: On 11/17/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: skitching Date: Fri Nov 17 19:41:32 2006 New Revision: 476429 URL: http://svn.apache.org/viewvc?view=revrev=476429 Log: Add comments about unusual dependency-handling approach. ... if we declare them optional then +- when JCL is *compiled* we get none of them in the classpath. Are you saying that if you mark the dependencies optional, you get compilation errors? That doesn't sound right. Well, that's exactly what happens. [INFO] Compilation failure /home/simon/apache/commons-svn/proper/logging/trunk/src/java/org/apache/commons/logging/impl/Log4JLogger.java:[23,24] package org.apache.log4j does not exist etc If you mark it optional, it will be excluded from transitive dependency resolution when a project depends on commons-logging. But it should be on the compile-time classpath. That's what I'd like to see happen, but it doesn't appear to (using maven 2.0.4 on Linux). Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Digester] Maven2 POM Questions and Proposals
On Wed, 2006-11-15 at 22:20 -0500, Rahul Akolkar wrote: On 11/14/06, Dennis Lundberg [EMAIL PROTECTED] wrote: I was going to try it myself but I get a test failure, see below, so I haven't been able to try it myself. --- Test set: org.apache.commons.digester.NodeCreateRuleTestCase --- Tests run: 9, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.062 sec FAILURE! testNonNamespacedAttribute(org.apache.commons.digester.NodeCreateRuleTestCase) Time elapsed: 0 sec FAILURE! junit.framework.AssertionFailedError at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at junit.framework.Assert.assertNotNull(Assert.java:220) at junit.framework.Assert.assertNotNull(Assert.java:213) at org.apache.commons.digester.NodeCreateRuleTestCase.testNonNamespacedAttribute(NodeCreateRuleTestCase.java:437) snip/ Hmm, cannot reproduce the failure locally. The nightlies seem to be happy too (though they're running the test under m1). Any more details about your setup or other clues? Works for me too (Sun java 1.5.0 on Linux). Initially it would look like the xml parser in use is behaving differently from what most people get. What JVM are you using - not gcj by any chance? Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] Time for 1.8? (was: DIGESTER-107)
Hi Rahul, On Thu, 2006-11-09 at 13:44 -0500, Rahul Akolkar wrote: On 9/25/06, Simon Kitching (JIRA) [EMAIL PROTECTED] wrote: snip/ It's probably a good time; a couple of minor bugfixes/enhancements have been made that deserve release (see RELEASE-NOTES.txt). snap/ Coming back to this thread, couple of quick comments before we hit an RC (no rush, but wanted to get to this before a RC was cut): a) Lets wean digester off of collections (and upgrade beanutils to 1.7) Not sure. If you're talking about the dependency declarations in the pom.xml, it's the way it is at the moment because I just based the maven2 pom on the maven1 stuff; I'm more focused at the moment on getting the maven2 build working than updating the maven1 stuff. Historical note: Digester doesn't have a dependency on Collections directly. Unfortunately, Digester does need Beanutils, and Beanutils has a collections class in its public API. What Robert Donkin did in the 1.7 release of Beanutils was bundle the necessary collections class in the Beanutils library. It's a little ugly but it was a very stable class and breaks the dependency from BeanUtils on Collections. That's why the release notes state that Digester's dependency is *either* beanutils1.6 + collections or beanutils1.7 (no collections). Unfortunately maven has no way of expressing this either/or dependency, so we have to choose one or the other. If we go for the beanutils1.7 option, then people wanting to use Digester in an app that needs beanutils 1.6 are out of luck. However if we leave things as they are (collections+beanutils) they can just use a maven2 dependency exclusion to suppress the collections dependency and all will be well, no? On the other hand, declaring both deps makes everyone's app larger than it needs to be if they don't otherwise need collections. b) We're missing a few serial version UIDs (adding those might unnecessarily break some serialization contracts though) I would lean towards adding the UID on any class we change, and leaving it alone on anything we haven't modified. I'll look to see if any of the classes changed since 1.7 have a missing UID. And of course we should check that the UID on any changed class has been updated! WDYT? If theres anything I can help with for the release, let me know. If you want to get stuck in to the pom.xml file, please go ahead. What I've committed so far is just an initial stab; there is still 1 unit test failure when running under surefire and I haven't got to testing the distribution step yet. Or you could look at the UID stuff, if you agree with my comments above. Otherwise I think things are pretty good to go. Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-parent pom
On Mon, 2006-11-06 at 18:47 +0100, Dennis Lundberg wrote: Hello This is a new vote following up on the failed vote [1] that was held previously. As far as I can tell, all the issues that were raised in the earlier vote has been addressed. So please cast your votes. This vote will be open for 72 hours and I will tally the votes no earlier than 19:00 GMT+1 on November 9th. +1 (pmc member) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r472006 - /jakarta/commons/proper/commons-parent/trunk/pom.xml
This is the old-style license header. The new style is as shown at the top of this file: http://svn.apache.org/repos/asf/jakarta/commons/proper/digester/trunk/build.xml Regards, Simon On Tue, 2006-11-07 at 06:39 +, [EMAIL PROTECTED] wrote: Author: jochen Date: Mon Nov 6 22:39:17 2006 New Revision: 472006 URL: http://svn.apache.org/viewvc?view=revrev=472006 Log: Adding the ASLv2 header. Modified: jakarta/commons/proper/commons-parent/trunk/pom.xml Modified: jakarta/commons/proper/commons-parent/trunk/pom.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/commons-parent/trunk/pom.xml?view=diffrev=472006r1=472005r2=472006 == --- jakarta/commons/proper/commons-parent/trunk/pom.xml (original) +++ jakarta/commons/proper/commons-parent/trunk/pom.xml Mon Nov 6 22:39:17 2006 @@ -1,3 +1,20 @@ +!-- + + Copyright 1999,2005 The Apache Software Foundation. + + Licensed under the Apache License, Version 2.0 (the License); + you may not use this file except in compliance with the License. + You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an AS IS BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. + +-- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-parent pom
On Tue, 2006-11-07 at 07:43 +0100, Jochen Wiedmann wrote: On 11/7/06, Rahul Akolkar [EMAIL PROTECTED] wrote: c) The svn log is confident [1] the antrun bit is needed due to a bug in the source plugin, but subsequent conversations not so [2]. What is it, IYO? Figure you're as good a resource for this question. Sorry, but my english language parser (an ancient german model from 1963, so please bear with me) can't understand your question? My reading of the email referred to at [2] is confirmation that the antrun bit *is* needed. P.S: I never experienced votes with so much considerations. Perhaps we should hide the POM in a zip file and add thousands of .java files, so that people don't look so much ... ;-) Releases of other projects have gone through quite a few cycles too. It's just fortunate that in this case we don't need to build RC bundles each time :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-proper POM 1
On Thu, 2006-10-12 at 22:02 +0200, Jochen Wiedmann wrote: Currently there is only a SNAPSHOT POM for commons proper: In other words, a release of commons-fileupload can only choose to ignore the hierarchy and derive from the Apache POM directly or it can wait for an official release of the commons-proper POM, it's natural parent. The latter is what we vote about. This thread from 12 October 2006 appears to have tailed off without conclusion: http://marc.theaimsgroup.com/?t=11606631873r=1w=2 As far as I can see, all the issues that were raised were fixed thanks to hard work by Jochen Wiedmann. People were sounding pretty positive about the final state of this file. Rahul suggested starting a new Vote thread for clarity as the first one had a lot of discussion happening but I can't see that one occurred. See also: http://svn.apache.org/repos/asf/jakarta/commons/proper/commons-parent/trunk/ I'm hoping to get a release of commons-digester out sometime soon, and it would be good to have maven2 support. However it's pretty ugly to point at a parent pom with SNAPSHOT version, as builds of that release aren't repeatable; the parent pom can change. There is also work currently going on for a Betwixt release. It would be nice to have maven2 support for that too... Cheers, Simon - 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]
[general] good maven2 pom.xml to copy?
Hi, I'd like to enable building of digester with maven2. Any suggestions as to which commons project's pom.xml I should base it on? I know some work has been going on for maven2 support recently.. Thanks, Simon - 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]
Re: Three votes of PMC members required
+1 On Sun, 2006-10-15 at 15:44 +0200, Jochen Wiedmann wrote: Hi, AFAIK the policy is still that three votes of PMC members are required. In other words, may I point you to http://marc.theaimsgroup.com/?t=11606631873 and ask kindly for positive votes? (Unless you have reason for negative votes, of course.) Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Logging: SimpleLog not thread-safe
HI, On Fri, 2006-10-13 at 00:10 -0400, Kenneth Xu wrote: Yes, it'll be GC'ed when thread is. And initialized when first use in a new thread. Here is the test code: But if an application has long-running threads then the object won't be recycled until the thread dies. So an app with 100 threads has 100 SimpleDateFormat objects long-term. And as James noted, when using frameworks like Application Servers, threads could be pooled in unexpected ways. I also suspect that in order to fetch data from a ThreadLocal, the JVM effectively performs a get on a synchronised map, ie that ThreadLocal is not much more efficient than having a synchronised static DateFormat on SimpleLog (nb: I have no proof of this, just a hunch). I think the easiest most reliable solution is to simply create a SimpleDateFormat object in the method that needs it. Note that this is only done after it has been determined that a message *will* be output, which in most cases means that there will be disk io that will have far more impact on the system than creating a simple object. Optimising the path in commons-logging that determines *if* a message is to be logged is important; optimising the actual logging operation is much less critical. Of course I'm open to persuasion on this (eg performance stats).. Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Logging: SimpleLog not thread-safe
On Sat, 2006-10-14 at 08:07 -0400, James Carman wrote: Tomcat had this same issue a while back. It was trying to use a single SimpleDateFormat object to parse/format date-valued HTTP headers. I submitted the patch for it and I think we decided to just instantiate as needed. Local variables are garbage collected much more reliably from what I understand. And, as Simon pointed out, the probable disk i/o would be the big bottleneck, not the object instantiation. Ok, so next issue: this member is declared protected: static protected DateFormat dateFormatter = null; (and initialised via a static block on the class). This means that removing it is a binary-incompatible change; any subclasses will be broken. Sigh. Once again we learn the lesson that protected members should be avoided just like public ones, as the binary-compatibility issue they cause are exactly the same. I'd be willing to bet money that no-one in the world has ever subclassed SimpleLog, but the issue is there. And of course binary compatibility is a very big issue for such a core lib as logging. Options: (1) leave this member here, but don't use it. (2) remove it, and release as 1.1.1 (3) remove it, and increment logging version to 1.2 This option does mean that code will continue to run, but if anyone *had* subclassed SimpleLog then they would get output in the default format, not their customised format. As they presumably had a good reason for customising the output, their app may misbehave due to a bugfix-level change. Option 2 could potentially cause an existing application to throw an exception when the SimpleLog subclass tries to access member dateFormatter. Option 3 is the theoretically correct one, but is rather overkill for such a small change. I'm tempted to choose (1), though none of the options are terribly appealing. Comments anyone? Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Logging: SimpleLog not thread-safe
After some thought, I've changed my mind about the solution.
I think the best choice is instead to use a synchronized block:
// Append date-time if so configured
if(showDateTime) {
Date now = new Date();
String dateText;
synchronized(dateFormatter) {
dateText = dateFormatter.format(now);
}
buf.append(dateText);
buf.append( );
}
This:
(a) Avoids any binary-compatibility issues, as the member is still
present and still used. There is a potential race condition in that
subclasses of SimpleLog theoretically need to synchronize on the object
if they access it, which is a new requirement. However as there is
*currently* a thread race condition I don't feel we've made anything
worse in that area.
(b) works correctly if a subclass replaces the dateFormatter with some
other object; creating the SimpleDateFormat object in the log method
would break that.
(c) Avoids creating the SimpleDateFormat object. In cases where the
format string is complicated, this construction might actually take some
significant time. Performing synchronization should actually be faster.
I've committed R464108 which implements the synchronized fix.
All comments welcome.
Regards,
Simon
On Sun, 2006-10-15 at 15:50 +1300, Simon Kitching wrote:
On Sat, 2006-10-14 at 08:07 -0400, James Carman wrote:
Tomcat had this same issue a while back. It was trying to use a single
SimpleDateFormat object to parse/format date-valued HTTP headers. I
submitted the patch for it and I think we decided to just instantiate as
needed. Local variables are garbage collected much more reliably from
what I understand. And, as Simon pointed out, the probable disk i/o would
be the big bottleneck, not the object instantiation.
Ok, so next issue: this member is declared protected:
static protected DateFormat dateFormatter = null;
(and initialised via a static block on the class).
This means that removing it is a binary-incompatible change; any
subclasses will be broken. Sigh. Once again we learn the lesson that
protected members should be avoided just like public ones, as the
binary-compatibility issue they cause are exactly the same.
I'd be willing to bet money that no-one in the world has ever subclassed
SimpleLog, but the issue is there. And of course binary compatibility is
a very big issue for such a core lib as logging.
Options:
(1) leave this member here, but don't use it.
(2) remove it, and release as 1.1.1
(3) remove it, and increment logging version to 1.2
This option does mean that code will continue to run, but if anyone
*had* subclassed SimpleLog then they would get output in the default
format, not their customised format. As they presumably had a good
reason for customising the output, their app may misbehave due to a
bugfix-level change.
Option 2 could potentially cause an existing application to throw an
exception when the SimpleLog subclass tries to access member
dateFormatter.
Option 3 is the theoretically correct one, but is rather overkill for
such a small change.
I'm tempted to choose (1), though none of the options are terribly
appealing.
Comments anyone?
Cheers,
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Logging: SimpleLog not thread-safe
It might do; not sure what the performance of ThreadLocal is. However
the price is extra memory usage: a DateFormatter for every thread in the
system that ever logs a message.
On Wed, 2006-10-11 at 17:42 -0400, Kenneth Xu wrote:
Hi,
I think a thread local formatter will give us better performance than
creating one new in every log invocation.
Just my 2 cents,
Thanks,
Ken
-Original Message-
From: Simon Kitching [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 11, 2006 5:05 AM
To: Jakarta Commons Developers List
Subject: Re: Logging: SimpleLog not thread-safe
Hi Martin,
Thanks very much for letting us know about this. I think you're right
about there being a thread-safety issue.
SimpleLog is definitely in use, but obviously this bug will only be
triggered under pretty rare conditions, and I expect would usually just
result in a malformed date string which may not be noticed anyway.
But it should be fixed; I'll try to do that this weekend.
Regards,
Simon
On Fri, 2006-10-06 at 17:15 +0100, Martin Wilson wrote:
Hi,
I'm not sure if anyone else uses the SimpleLog class - anyway I've
noticed that SimpleLog.log is not thread-safe. The following code
(starting on line 282):
if(showDateTime) {
buf.append(dateFormatter.format(new Date()));
buf.append( );
}
makes an unsynchronized call to dateFormatter.format. As dateFormatter
is an instance variable, and DateFormat.format is not thread-safe, this
will cause problems if more than one thread tried to log at the same
time.
Solution: remove the dateFormatter instance variable and instantiate a
new DateFormat each time in the log method, e.g.
DateFormat dateFormatter = null;
try {
dateFormatter = new
SimpleDateFormat(dateTimeFormat);
}
catch(IllegalArgumentException e) {
dateFormatter = new
SimpleDateFormat(DEFAULT_DATE_TIME_FORMAT);
}
Is anyone available who could make this change?
Thanks,
Martin
___
Martin Wilson
[EMAIL PROTECTED]
Bright Interactive: successfully delivering interactive websites and
business applications
http://www.bright-interactive.com/ http://www.bright-interactive.com
0870 240 6520
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Logging: SimpleLog not thread-safe
Hi Martin,
Thanks very much for letting us know about this. I think you're right
about there being a thread-safety issue.
SimpleLog is definitely in use, but obviously this bug will only be
triggered under pretty rare conditions, and I expect would usually just
result in a malformed date string which may not be noticed anyway.
But it should be fixed; I'll try to do that this weekend.
Regards,
Simon
On Fri, 2006-10-06 at 17:15 +0100, Martin Wilson wrote:
Hi,
I'm not sure if anyone else uses the SimpleLog class - anyway I've
noticed that SimpleLog.log is not thread-safe. The following code
(starting on line 282):
if(showDateTime) {
buf.append(dateFormatter.format(new Date()));
buf.append( );
}
makes an unsynchronized call to dateFormatter.format. As dateFormatter
is an instance variable, and DateFormat.format is not thread-safe, this
will cause problems if more than one thread tried to log at the same
time.
Solution: remove the dateFormatter instance variable and instantiate a
new DateFormat each time in the log method, e.g.
DateFormat dateFormatter = null;
try {
dateFormatter = new
SimpleDateFormat(dateTimeFormat);
}
catch(IllegalArgumentException e) {
dateFormatter = new
SimpleDateFormat(DEFAULT_DATE_TIME_FORMAT);
}
Is anyone available who could make this change?
Thanks,
Martin
___
Martin Wilson
[EMAIL PROTECTED]
Bright Interactive: successfully delivering interactive websites and
business applications
http://www.bright-interactive.com/ http://www.bright-interactive.com
0870 240 6520
-
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]
Re: [VOTE] Release [net] version 2.0
Sorry, text and xml are the only clirr formats supported as far as I know (last time I looked). The text output is fairly readable though not pretty I agree. I'm not sure how well clirr handles java 1.5. Cheers, Simon On Wed, 2006-09-13 at 11:14 +0100, Rory Winston wrote: Sure, I can output a clirr report in text or xml, is there any predefined templates to convert it to a more readable format (i.e. HTML)? Rory Stephen Colebourne wrote: Perhaps you could run a clirr report, and publish the result? That way we can all see what the amount of change in the API is. And yes, this cold potentially be a problem with any non backwards-compatible release. As I said before, I'm driving to find out how this release will sit within the wider OSS and user community, and to try and avoid jar-hell. Stephen - Original Message From: Rory Winston [EMAIL PROTECTED] To: Jakarta Commons Developers List commons-dev@jakarta.apache.org Sent: Wednesday, 13 September, 2006 8:53:27 AM Subject: Re: [VOTE] Release [net] version 2.0 Stephen I'm afraid I dont really get waht you're asking? Surely this would be a problem with any project that produces a non-backwards-compatible release? As for the API, it is 99% backwards compatible - so far, there are little changes to the public interface. Stephen Colebourne wrote: My question is whether 2.0 is backwards compatible with 1.0. If it isn't, then how are we going to handle the situation where two different OSS projects refer to two different versions of [net] - jar-hell. Stephen Rory Winston wrote: Steve Sorry, I should have been more specific 1) Yes, there will be two separate branches of development. At the moment, the trunk is the 1.x branch, whereas there is a separate branch for JDK 5.0 dev. We can keep this the way it is, or swap the trunk and branch at some stage. 2) We need two sites, for sure. I think an easy way would be to do the separate Maven 1 (1.x codebase) and Maven 2.0 (2.x codebase) builds, and just put a link from one site to the other in the Maven menus. Otherwise, if Maven 2 can handle this kind of situation out of the box, we should move the 1.x build over to Maven 2 as well.What do you think? Hope this helps Rory Steve Cohen wrote: Rory Winston wrote: OK, seeing as we have reached some kind of consensus on how to handle backards-incompatible JDK releases, I'm restarting the vote for a release of Commons::Net 2.0 (the JDK 5.0 branch). As per usual, just respond with +1 +0 -0 -1 Thanks Rory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Sorry, Rory, but I think you need to express the consensus that you think we are voting on. You haven't done that. release of Commons::Net 2.0 (the JDK 5.0 branch) doesn't get to the heart of all the issues. 1: Are there two official branches or is 1.4.x relegated to backward compatibility mode? I would insist that there be two branches until Sun puts 1.4.x into EndOfLife mode. 2. Is the site going to be organized to reflect the two branches? If those two points are part of your motion, I'm +1. Otherwise, I'm -1. Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Commons and JDK5, was VOTE Release [net] version 2.0
On Sun, 2006-09-10 at 00:39 +0100, Stephen Colebourne wrote: Steve Cohen wrote: [PROPOSAL] As such, I would like to propose that projects creating a JDK1.5 only release should use a new package name. Thus, in this case, the release would use the package org.apache.commons.net5.*. With this change, a user can have both the old and the new commons-net jars in their classpath without any conflicts. Note that these users may be different OSS projects, which may upgrade at different times. As Steve Cohen notes, I'd also be interested to see what features of commons-net really benefit from a 1.5-compatible release. However in general it seems a good time for commons to start releasing code using 1.5 features where there is a benefit to the user. Java 1.5 is now well-established and the features are truly useful. And I'm +1 to a new package name when doing so (as steve Colebourne suggests) , to allow the old and new versions to co-exist. I agree that requiring all apps to have *either* net 1.x or net 2.x in the path, but not both, will cause a great deal of pain, and will probably slow the adoption of the new net version. BTW, It would be great if Java had some other mechanism for handling multiple versions of the same library (as Microsoft's CLR has I believe).. Cheers, Simon - 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]
Re: svn commit: r437237 [1/2] - in /jakarta/commons/proper/lang/trunk: src/java/org/apache/commons/lang/ src/java/org/apache/commons/lang/builder/ src/java/org/apache/commons/lang/enum/ src/java/org/a
Hi, On Sat, 2006-08-26 at 21:52 +, [EMAIL PROTECTED] wrote: Author: ggregory Date: Sat Aug 26 14:52:47 2006 New Revision: 437237 URL: http://svn.apache.org/viewvc?rev=437237view=rev Log: Change Copyright -2005 to Copyright -2006 What is the motivation for this change? As far as I know, the copyright date can only include 2006 if there is some copyrightable contribution added in 2006. Is this really the case for all these files? Claiming copyright of 2006 in a file that has not been modified in 2006 would seem to me to be wrong (IANAL). There is also a copyright over the whole combined work, but that doesn't necessarily correspond to copyright on any particular part. That means that there is no need to update the copyright in files before a release. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [beanutils] [logging] Webapp using commons-logging fails to start in Tomcat 4.1.x when beanutils 1.7.0 is used by Tomcat
Hi Mark, Your report is very interesting. I do quite a bit of maintenance on logging and digester, and a little on beanutils, so would definitely be keen to figure out what's going on here. It would help if you could provide more details on exactly what behaviour you are seeing. In particular, are you seeing this exception immediately on startup of a fresh Tomcat install, or is it *any* webapp that triggers this, or a specific one? It will be easiest to investigate if there is enough info to be able to duplicate the problem. You say you've tried commons-logging 1.1.0. Can you please confirm for me that you replaced the commons-logging.jar file in $TOMCAT_HOME/lib with the commons-logging-api.jar from the binary download of commons-logging 1.1? You might want to try setting the following environment variable: -Dorg.apache.commons.logging.diagnostics.dest=/some/log/file.txt then trigger the problem exception. The diagnostics feature was added to JCL 1.1 to investigate just this sort of problem. I unfortunately don't have a lot of spare time at the moment, but will try to find time to look into this once there is sufficent info to duplicate the problem locally. Regards, Simon On Mon, 2006-08-21 at 07:26 -0400, Mark Thomas wrote: Simon Kitching wrote: Firstly, the 1.1.0 release of commons-logging will hopefully not have this problem; you don't indicate what version of commons-logging is present when this problem occurs. Could you try upgrading the JCL implementation in the tomcat path to the latest version and see what happens? Tomcat currently uses commons-logging 1.0.4 but sees the same issue with 1.1.0. If beanutils is using static loggers then that really should be fixed. It has been fixed in 1.7.0 but this causes issues for Tomcat. Actually, beanutil's liberal use of static members and methods has always struck me as being incredibly dangerous. I certainly don't want a datatype converter registered by one webapp to be visible in another! I would therefore suggest that tomcat (and all other apps) completely avoid using any static beanutils methods, and instead always access specific *instances* of the beanutils classes for beanutils functionality; that might avoid the logging issue completely. Or dump BeanUtils; there is some useful stuff in there but a lot of pretty scary stuff too.. Beanutils is only used directly in a few places but where we are seeing problems is when we use commons-digester of which beanutils is a dependency. I can't see why beanutils 1.6.1 would be better than 1.7.0. Generally, I am sure it isn't. However, in this particular situation 1.6.1 works and 1.7.0 does not. Your statement that because BeanUtils/ConvertUtils were static, the objects were created by the Tomcat classloader doesn't seem right to me. Tomcat uses digester internally. First to configure itself (objects loaded with common classloader) and then to configure webapps (objects loaded with webapp classloader). Since in the static case the logs are created once when the static is created then all objects are created in the common classloader and there are no complaints from commons-logging. If the jar is bundled in a webapp, and the webapp has child-first classloading then the webapp's classloader will load those classes and hold its own copy of those statics, no? Agreed. The problem occurs when commons-logging is present in the webapp loader and in the common-loader. A singleton object having the same object types held as members instead of statics should have exactly the same behaviour as far as I can see, because the singleton reference is a static. These are pseudo singletons (commons-beanutils terminology). They are not statics but one per classloader instances. There is one exception: the members will be initialised when the first singleton instance is created, not at class load time. Maybe it is that delayed member initialisation that is responsible for any behaviour difference you see? Indeed. When commons-digester is configuring the webapp, it creates a ConvertUtilsBean for that classloader which in turn creates a log instance. If commons-logging is present in the webapp classloader and the common classloader it all goes horribly wrong. The blog entry referenced is interesting, but I can't for the moment see why it would have any effect at all. If child-first lookup is in action, and the class is available to the child classloader then that should take precedence over the parent classloader's version. And if parent-first lookup is in action, then the code shown is the default behaviour anyway isn't it? I must be missing something..will think about it some more. It gets around the commons-logging requirement that only one instance of commons-logging can exist in the classloader hierarchy. If the container provides it, the webapp uses it it. If it doesn't, the webapp uses its own
Re: [beanutils] [logging] Webapp using commons-logging fails to start in Tomcat 4.1.x when beanutils 1.7.0 is used by Tomcat
Hi Mark, Firstly, the 1.1.0 release of commons-logging will hopefully not have this problem; you don't indicate what version of commons-logging is present when this problem occurs. Could you try upgrading the JCL implementation in the tomcat path to the latest version and see what happens? Regarding static log instances, this is really a bad idea for a number of reasons, and this is NOT specific to commons-logging but common to any logging library that allows per-webapp logging configuration. This includes log4j, slf4j and JULI. See: http://wiki.apache.org/jakarta-commons/Logging/StaticLog If beanutils is using static loggers then that really should be fixed. Actually, beanutil's liberal use of static members and methods has always struck me as being incredibly dangerous. I certainly don't want a datatype converter registered by one webapp to be visible in another! I would therefore suggest that tomcat (and all other apps) completely avoid using any static beanutils methods, and instead always access specific *instances* of the beanutils classes for beanutils functionality; that might avoid the logging issue completely. Or dump BeanUtils; there is some useful stuff in there but a lot of pretty scary stuff too.. I can't see why beanutils 1.6.1 would be better than 1.7.0. Your statement that because BeanUtils/ConvertUtils were static, the objects were created by the Tomcat classloader doesn't seem right to me. If the jar is bundled in a webapp, and the webapp has child-first classloading then the webapp's classloader will load those classes and hold its own copy of those statics, no? A singleton object having the same object types held as members instead of statics should have exactly the same behaviour as far as I can see, because the singleton reference is a static. There is one exception: the members will be initialised when the first singleton instance is created, not at class load time. Maybe it is that delayed member initialisation that is responsible for any behaviour difference you see? The blog entry referenced is interesting, but I can't for the moment see why it would have any effect at all. If child-first lookup is in action, and the class is available to the child classloader then that should take precedence over the parent classloader's version. And if parent-first lookup is in action, then the code shown is the default behaviour anyway isn't it? I must be missing something..will think about it some more. Mark, what specifically is your issue here? Are you a tomcat developer, or trying to write webapps to run on tomcat, or something else? Regards, Simon On Sun, 2006-08-20 at 19:36 -0400, Mark Thomas wrote: Hi, The most recent Tomcat 4 release upgraded from beanutils 1.6.1 to 1.7.0 and this introduced a conflict with commons-logging (see http://issues.apache.org/bugzilla/show_bug.cgi?id=40252). As the issues boils down to fun and games with containers and classloader hierarchies, this might not be a beanutils issue at all but given the issue became apparent after a change in beanutils this seems like the right place to start. Since this discussion revolves around changes in the beanutils code, I am posting this to the dev list. If it is felt the users list is more appropriate, I am happy to move this thread to that list instead. With beanutils 1.6.1 utility classes such as BeanUtils and ConvertUtils were static and hence the associated Log instances were also static. All these objects were created by the Tomcat common classloader and all was well. In beanutils 1.7.0 the BeanUtilsBean class was introduced as per-context-classloader pseudo singletons. Providing commons-logging is not present in the webapp classloader then all is well. As soon as commons-logging is present in the webapp classloader, when the per context classloader instance of ConvertUtilsBean creates a logger it uses the Log class from the webapp classloader which conflicts with that in the common classloader and Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed. results. The only option for the webapp developer is not to include commons-logging but this does make for portable webapps - not all containers use commons-logging internally and a webapp may require this library. For now, my short-term solution is to revert to beanutils 1.6.1 for a TC4.1.33 release. Longer term, I wonder if the same sort of trick the OP for the above bug uses in webapps (see http://rbodkin.blogs.com/ron_bodkins_blog/2006/07/stupid_log_tric.html) could be used in beanutils. I would be happy to work on a patch in this direction if it was thought to be useful. However, I would value the insight of those more familiar with the beanutils code before starting since I don't want to waste time on a pointless exercise. Regards, Mark - To
Re: [logging] pom for commons-logging-api and building/testing JCL with Maven 1
Hi, I'm a little puzzled by this. I have recently created a completely functional pom.xml file for logging, which is checked in in trunk. This pom declares all dependencies as optional (except when compiling a checked-out svn release), so I think the same file is suitable for use as a pom for commons-logging-api.jar without modifications. Regards, Simon On Fri, 2006-08-11 at 21:03 +0200, Dennis Lundberg wrote: Carlos Sanchez wrote: If it's this one http://svn.apache.org/viewvc/jakarta/commons/proper/logging/trunk/commons-logging-api.pom?view=markup Yes, that's the one. I'd remove optional from both dependencies, it's not needed being scope test or plugins. Done. Thanks for reviewing. So it has no dependencies at all, isn't it? Yes, it doesn't have any dependencies. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r427459 - in /jakarta/commons/proper/attributes/trunk: api/manifest.mf build.xml compiler/manifest.mf
On Tue, 2006-08-01 at 06:17 +, [EMAIL PROTECTED] wrote: URL: http://svn.apache.org/viewvc/jakarta/commons/proper/attributes/trunk/api/manifest.mf?rev=427459view=auto == +X-Compile-Source-JDK: 1.4 +X-Compile-Target-JDK: 1.4 Attributes (and compiler) are java 1.4-only projects? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[build] nightly build support for maven2?
Hi, Currently the nightly build stuff supports either ant or maven1.x. I've just got logging building/testing successfully with maven2 (though building the dist bundles is still to do). Is there any chance someone could update the nightly build stuff to support maven2 as well? It would be a lot quicker/safer for someone already familiar with these scripts to add this than me.. Currently, logging is listed in the maven1.x list, but that only builds the site for logging, not the code so logging needs to move to either the ant list or a maven2 list... BTW, maven2 is a mile better than maven1. I'm planning on creating a maven2 buildfile for Digester soon, and maybe a few others. Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Tapestry and JCL
On Mon, 2006-07-31 at 13:08 -0700, Henri Yandell wrote: On 7/28/06, James Carman [EMAIL PROTECTED] wrote: Tapestry is thinking of switching to SL4J instead of Jakarta Commons Logging: I've been meaning to ask... is there really much reason for a JDK 1.4+ application/library to depend on commons-logging? Sure you could argue that log4j is more powerful, but the same could be said of ORO. Increasingly people just aren't going to care. We're starting to talk about moving to 1.3 so we can get the regexp support without a dependency ([io] for example), when do we start talking about 1.4 so we can drop the commons-logging dependencies? If I were writing a 1.4+ library or app, I'd just use java.util.logging directly. Which reminds me: is the JULI implementation of the java.util.logging API (used in tomcat) available as an independent library? If not, maybe it is worth extracting it as a project of the logging.apache.org group? Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [logging] Tapestry and JCL
I think projects should use the best tool for the job (as long as its license is ASL compatible). Apache doesn't have a monopoly on good ideas. If the Tapestry developers really feel SLF4J is better, then that's their choice and all power to them. Although I contribute patches to JCL, I'm certainly not claiming it is perfect - or even terribly good. Having said that, the 1.1 release of JCL is expected to resolve the vast majority of problems previously experienced by users; it now does its best to avoid throwing exceptions even when this means that output may not be generated, or not generated in the expected way. However JCL is definitely hampered by its history, and is now quite a complex beast. That means a greater risk of bugs/issues of course. A new 2.x version really is needed to get rid of all the old cruft but working on commons-logging is not glamorous or terribly rewarding so this may be a while off yet. SLF4J is a good project. It does have some differences from commons-logging. They are: * if using parent-first classloading, and SLF4J is in an ancestor classpath then there is no way for a webapp to configure its own logging library. And if that library doesn't internally support per-webapp configuration, then logging *config* is global across all webapps. This is a direct consequence of the decision in SLF4J not to use classloader tricks. Thus SLF4J is more predictable but less flexible. * SLF4J is far less widely used. Many of the issues with JCL only became known as it was used in various containers with weird classloading approaches. SLF4J's simplicity means that it is *less* likely to strike problems that JCL did, but then again there are some truly odd situations out there (that we worked through while creating the 1.1 JCL release). * I'm personally unconvinced by its approach to i18n. Of course JCL doesn't try to support i18n in its api at all, but I would suggest thinking carefully before using the i18n methods in SLF4J. There are some other options. I believe tomcat 6.x currently includes a statically-bound implementation of the JCL API (probably bound to JULI, which is a java.util.logging implementation). I think SLF4J even offers an implementation of the JCL api that maps to SLF4J adapters. Regards, Simon On Fri, 2006-07-28 at 10:14 -0400, James Carman wrote: Regardless, it's still not an ASF project. We should try to eat our own dog food IMHO. If we don't use our own libraries because we think they're sub-par, then why should anyone else? -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Friday, July 28, 2006 9:44 AM To: Jakarta Commons Developers List Subject: Re: [logging] Tapestry and JCL From: James Carman [EMAIL PROTECTED] Thoughts? I would really hate to see an Apache TLP, java-based project switch off JCL in favor of a non-ASF logging API. Unless I'm mistaken, SLF4J comes from Ceki, creator of Log4J. Thus the SLF4J website and separation is as much for political reasons as anything else. (ie, if it was release as part of Log4J, people wouldn't see it as truly independent of Log4J) Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] Minimal first release
On Fri, 2006-07-28 at 00:12 +0100, Stephen Colebourne wrote: Simple question - can [vfs] be released *now*, with a minimal set of code? I presume that the first release might thus consist only of the core plus standard java File and ram? No compress, ftp, http, ... I emphasise, think small. Subsequent releases could then add these features in, and potentially provide the split jar files (if someone, eg a maven expert, wants to set up the multi jar solution) I've done a reasonable amount of work with maven2 now, and can probably help out with maven config for vfs. However I agree that a minimal first release is a good idea. BTW, I generally like maven2. For certain special projects (eg logging) it can be awkward but for most projects the rewards are well worth the learning curve. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r425343 - /jakarta/commons/proper/logging/trunk/project.xml
On Tue, 2006-07-25 at 09:13 +, [EMAIL PROTECTED] wrote: Author: dennisl Date: Tue Jul 25 02:13:44 2006 New Revision: 425343 URL: http://svn.apache.org/viewvc?rev=425343view=rev Log: Add trailing slashes to URLs. - urlhttp://jakarta.apache.org/commons/logging/url + urlhttp://jakarta.apache.org/commons/logging//url Is the trailing slash on the url important? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: old style html in javadoc Was: [jira] Commented: (IO-86) Add FileFinder back into Commons IO
On Sun, 2006-07-23 at 21:30 -0700, Henri Yandell wrote: On 7/23/06, Stephen Colebourne [EMAIL PROTECTED] wrote: The concept that XML (XHTML in this case) is human readable is highly dubious, and has become accepted wisdom far too easily. Agreed, a .properties file is far more readable but that's not in question here. Bad HTML is less readable than good HTML because the eye is used to precompiling what's being typed. The first point is that it isn't 'bad' HTML, its just normal HTML. Every HTML tool going has to be able to cope with this sort of layout so any tool arguments fail pretty quickly. I don't agree - it was bad HTML in the mid 90s and it's bad HTML now. A decade of misuse doesn't make it right. So it comes down to readability, which is much more of a stylistic choice. Personally, I strive to avoid unecessary clutter, only including unecessary things (eg. additionl brackets) if I judge it aids understanding. +1. I'm with Stephen here; simple is good. Javadoc isn't expected to be processed by anything other than the javadoc tool, and that handles p as a separator fine, so why clutter things with /p? Javadoc isn't really html. It's a java-specific doc format (like perl POD etc) that happens to resemble html. There are many markup formats that use the separator approach rather than the container approach. In practice, I think that either is bearable, so new files should follow whatever convention the project already has. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Splitting the mailing list
On Sat, 2006-07-22 at 21:53 -0700, Henri Yandell wrote: I had a thought just now on the multiple list concept - and a positive reason for splitting the lists in general. By having lists for commits, jira, wiki, ci etc filters become a lot, lot easier. Much easier for someone to come up with a list of commits they're interested in and we can have people who are interested in their own defined groupings while having to still see the general dev discussions as they come through. One problem is that of temporarily unsubscribing. We've all regularly seen what happens when someone goes on holiday for a few weeks and sets their email to auto-respond out of office without unsubscribing from these lists first. When there are 4 commons lists, how are people going to manage this? I believe one commonly used mailing list system provides a web page where you can suspend your subscriptions to all lists in one go. As far as I know, though, the apache system doesn't provide this. Regards, Simon - 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] admin access for DIGESTER, LOGGING
Hi, I don't appear to be able to close JIRA issues for LOGGING. Do I need to explicitly be granted privileges for this? If so, could someone please do so? Thanks, Simon - 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]
Re: [all] Splitting the mailing list
On Thu, 2006-07-20 at 20:34 -0700, Martin Cooper wrote: On 7/20/06, Phil Steitz [EMAIL PROTECTED] wrote: On 7/20/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 7/20/06, Henri Yandell [EMAIL PROTECTED] wrote: Is it as important for contributors? If I understand it correctly, the idea of this change (a bunch of projects seem to be moving this way) is that the developers see exactly what they used to see and the contributors get a less spammy list and thus get more involved. Commit diffs are not spam, IMO, nor are issue reports / comments. This is core to what is happening on a project. I agree with Phil. And I don't buy that more people would get involved if they didn't see the commit messages. How can they be properly involved if they're not watching what's happening to the code and the issues? I'm also -0 on splitting the list into dev/commit (though open to persuasion). As noted, JIRA comments are as valid as emails for discussing an issue. And I think any contributor to a project (someone who is submitting patches) needs to keep an eye on patches even if not a committer, to see if their area of interest is being modified and how. Allowing people to subscribe to (mail+jira+commit) for a specific commons component seems to be to me what casual contributors would really need, but we have no easy way to do that without causing major damage to the whole commons community. As far as the arguments about getting new contributors in, I would like to hear from them. That's an excellent idea.. Brett, what's the feedback on the split of the Maven list? Why do you think it was a good idea? Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[all] [logging] AccessController and security
Hi,
While looking into the use of AccessController by commons-logging (JCL),
I think I've found a minor security issue.
There is currently code in LogFactory like:
protected static ClassLoader getContextClassLoader() {
return (ClassLoader) AccessController.doPrivileged() {...}
}
In a situation where untrusted code is calling into a JCL library that
is signed and has been granted access to the context classloader,
doesn't this mean that the untrusted code can subclass LogFactory, call
the protected method, and obtain a reference to an object it may be
forbidden to access?
It would seem to me that secure data obtained via an AccessController
should never be permitted to propagate out of any non-private method.
Comments anyone?
Regards,
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Re: SingularValueDecomposition
On Mon, 2006-07-17 at 06:50 +0200, Luc Maisonobe wrote: Tyler Ward wrote : Hi guys, I haven't sent mail to this list before. I've noticed that apache doesn't have an SVD algorithm, so I put one together. Are you guys interested? By the way, could you add [math] as a marker in your subject for this list (I forgot to fix it in my previous mail, sorry). The list is shared among a lot of projects, so these markers help filtering the messages for all subscribers. And just as a reminder, the Apache Software Foundation is very careful to respect copyrights, so any contribution of this sort cannot be based on code published under another license. Hopefully most core math algorithm can be implemented from the theory without great problems, but copying code fragments from a textbook, etc. can be problematic I believe. I'll leave it up to the core maths people to determine what's ok. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Logging related problem with HttpClient
Hi Neelesh/Ortwin, While the library being used is HttpClient, the problem does seem to really be a commons-logging(JCL)issue, and therefore belongs on this list. I've changed the subject of this email to indicate this. The httpclient 3.0.1 dependencies do specify commons-logging 1.0.3, but the latest version (1.1) should be 100% backwards compatible while having a lot less bugs, so logging 1.1 should be the right version to use in this case. In general, the commons-logging-api jar is intended only for use by Apache Tomcat (and maybe other container frameworks). You might want to use the full jar, or possibly the -adapters one if you're running this code in a container that already deploys JCL. From the exception stacktrace it looks like you're writing some sort of webapp, running in some sort of container: org/apache/commons/logging/LogFactory org.apache.commons.httpclient.HttpClient.clinit(HttpClient.java:65) src.com.example.web.Sample.main(Sample.java:12) This page might be helpful: http://jakarta.apache.org/commons/logging/troubleshooting.html If this doesn't solve your problem, then please post further details of the environment you're actually running this code in. Regards, Simon On Thu, 2006-06-22 at 19:47 +0200, Ortwin Glück wrote: Neelesh, Please see http://jakarta.apache.org/commons/httpclient/dependencies.html for the correct version of the dependencies. Note: HttpClient is no longer in Jakarta Commons. Our mailing lists are these: http://jakarta.apache.org/commons/httpclient/mail-lists.html Cheers Ortwin Neelesh Bodas wrote: I have made sure that following jars are in the classpath : commons-codec-1.3.jar commons-logging-1.1.jar commons-logging-adapters-1.1.jar commons-logging-api-1.1.jar junit-4.1.jar commons-httpclient-3.0.1.jar I am getting the following runtime error: Exception in thread main java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory at org.apache.commons.httpclient.HttpClient.clinit(HttpClient.java:65) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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]
Re: How can I search the mailing list archive
On Sun, 2006-06-18 at 13:54 +1000, Torsten Curdt wrote: try this http://marc.theaimsgroup.com/?l=jakarta-commons-devr=1w=2 Why do we feature our own archive (in most of the project info reports) if it is not even searchable? Instead people have to be pointed to other searchable archives ...or find them on their own. Not really user-friendly. It's an archive that is stable, long-term and trustable. That means it's a great historical resource, and that when providing URLs referencing past discussions, a URL to the Apache email archives is a very good way to do that. I agree that it's a shame there is no decent search facility though. I thought that last year's Google Summer of Code included a project to enhance the apache http mod_mbox to provide search functionality. Do I remember wrong, or did that project not work out? Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release FileUpload 1.1.1-RC1
On Sun, 2006-05-28 at 00:03 -0700, Henri Yandell wrote: [I haven't created an SVN tag for the RC1. Is there any particular reason the release info says to create a tag?] Well, in a busier project there is the danger that others may make commits to the trunk while the RC is still being voted on. If it passes, it's somewhat tricky to then make the tag. Actually, some of the maven and site-build cleanups going around at the moment are good examples of how a project's trunk might get patched even when a project has a small developer pool that have agreed to hold back their patches until the release happens. Making a tag in subversion has exactly the same price as checking in one new file, ie is trivial. I think the existing release advice is therefore good; creating a tag for an RC should be the regular practice. Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Release tags, was VOTE Release FileUpload 1.1.1-RC1
On Mon, 2006-05-29 at 12:35 +0100, Stephen Colebourne wrote: Simon Kitching wrote: On Sun, 2006-05-28 at 00:03 -0700, Henri Yandell wrote: [I haven't created an SVN tag for the RC1. Is there any particular reason the release info says to create a tag?] Making a tag in subversion has exactly the same price as checking in one new file, ie is trivial. I think the existing release advice is therefore good; creating a tag for an RC should be the regular practice. Personally I don't like the resulting 'tag clutter'. Is there any way in SVN to remove dead tags? Sure; svn rm. A tag is just a directory (well, actually, just an entry in the parent directory that points to a specific inode). For RCs from releases before the current one, I think deleting them seems reasonable (eg when 1.2 is released, remove 1.0 RC tags). I'd prefer to keep RC tags for at least one release though. If you don't like them in the main tags directory, they could be pushed down into a special RC directory Of course delete just makes them not visible in the head revision; the tag directory is still there if you look for it. Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Maven 2 POM(s) for commons-logging [Was: RE : [ANNOUNCEMENT] Apache Jakarta Commons Logging 1.1 Released]
On Mon, 2006-05-15 at 21:11 +0100, robert burrell donkin wrote: or should we try to create a POM for commons-logging-api or perhaps both? not sure the API works best as a virtual dependency. it can be satisfied by JCL 1.0.x, 1.1.x, by ceki's adapter or by Torsten's null implementation. not sure whether maven 2 handles this ATM. Not sure what you mean by a virtual dependency. I think the api jar should never be used as a dependency by anyone; it's really only for the use of tomcat. If other people provide jars that define classes o.a.c.l.Log and LogFactory, then that can be used as a dependency *instead* of depending on anything from the commons-logging group. Is that what you meant? but the API jar contains more than is necessary for this purpose. probably carlos is right that all the dependencies need to be marked as optional but the full JCL jar shipped. not sure... I'd agree with this. Just mark all dependencies as optional. I've put the same comments on the original JIRA issue: http://jira.codehaus.org/browse/MEV-392 Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
On Sat, 2006-05-13 at 11:30 -0700, Martin Cooper wrote: On 5/13/06, robert burrell donkin [EMAIL PROTECTED] wrote: On Thu, 2006-04-06 at 08:51 +0200, Nicolas De Loof wrote: I agree about NOT making non-final jars available on ibiblio (httpclient beeing an exception) So could the next RC be uploaded to http://cvs.apache.org/maven-snapshot-repository/ ? Please also consider using the new groupId recommandation for apache commons-X : org.apache.commons.X should we make this change for the whole of the commons? I would be in favour of that. The sooner all ASF projects use a consistent groupId scheme, the better. how much hassle would this change be for downstream consumers? Virtually none, as long as we make the change obvious, e.g. by including the groupId and artifactId in release announcements and download pages, or somewhere of that sort. What happens if someone has a project that has the following dependencies: project depends on A, B A depends on group=commons-lang, artifact=commons-lang B depends on group=org.apache.commons.lang, artifact=commons-lang Is maven smart enough to avoid putting lang in the dependencies twice? There is a special POM entry that can indicate a relocation of the target. I don't know the details of how this works though. http://maven.apache.org/ref/current/maven-model/maven.html#class_relocation In general, though, I'm in favour of the move to a properly structured group-id. As maven gets more popular (the repo gains more entries), the existing flattish structure becomes harder to manage. And from the volume of messages on the maven lists, its popularity is growing fast.. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release collections v3.2
On Fri, 2006-05-12 at 09:41 +0100, robert burrell donkin wrote: i note that commons collections binary distribution now ships with just API documentation. AFAIK this means that the user guide isn't distributed. assuming that this isn't an oversight, i'd like a full cut of the maven generated website to be made available on line. From the original posting: RC1 is here: http://people.apache.org/~scolebourne/commons-collections/ Site here: http://people.apache.org/~scolebourne/commons-collections/site/ Release notes here: http://people.apache.org/~scolebourne/commons-collections/site/release_3_2.html The site link appears to me to have everything necessary. What's missing? Good point about the manifest... One other thing I spotted: on the overview page of the site, the Documentation section lists previous version 2.1.1. Surely the previous version is 3.1; is this meant to be a link to most recent release of the 2.x series? Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] 3.2 RC1 feedback
On Thu, 2006-05-11 at 20:55 +0100, Stephen Colebourne wrote: Thanks for the feedback, I'll fix the stuff mentioned before release. The clirr report is available from an 'ant clirr'. It shows no issues: INFO: 7011: org.apache.commons.collections.BufferUtils: Method 'public org.apache.commons.collections.Buffer blockingBuffer(org.apache.commons.collections.Buffer, long)' has been added INFO: 7011: org.apache.commons.collections.BufferUtils: Method 'public org.apache.commons.collections.Buffer boundedBuffer(org.apache.commons.collections.Buffer, int)' has been added INFO: 7011: org.apache.commons.collections.BufferUtils: Method 'public org.apache.commons.collections.Buffer boundedBuffer(org.apache.commons.collections.Buffer, int, long)' has been added None of these changes are in the release notes (though all are correctly documented with @since 1.2). Admittedly, they are implied by the addition of the new constructors on BlockingBuffer and BoundedBuffer which are documented. Still, I think a one-line entry in the release notes saying that the BufferUtils class has been extended to match the new constructors would be nice. INFO: 7011: org.apache.commons.collections.ClosureUtils: Method 'public org.apache.commons.collections.Closure ifClosure(org.apache.commons.collections.Predicate, org.apache.commons.collections.Closure)' has been added As for BufferUtils above. INFO: 7011: org.apache.commons.collections.IteratorUtils: Method 'public org.apache.commons.collections.ResettableIterator loopingListIterator(java.util.List)' has been added As for BufferUtils INFO: 7011: org.apache.commons.collections.MapUtils: Method 'public java.util.Map multiValueMap(java.util.Map)' has been added INFO: 7011: org.apache.commons.collections.MapUtils: Method 'public java.util.Map multiValueMap(java.util.Map, java.lang.Class)' has been added INFO: 7011: org.apache.commons.collections.MapUtils: Method 'public java.util.Map multiValueMap(java.util.Map, org.apache.commons.collections.Factory)' has been added As for BufferUtils INFO: 7011: org.apache.commons.collections.buffer.BlockingBuffer: Method 'public org.apache.commons.collections.Buffer decorate(org.apache.commons.collections.Buffer, long)' has been added Not mentioned in release notes. These are pretty trivial points. All the methods above *do* have the correct @since info. More importantly, there seem to be no backwards compatibility issues. So as long as the Manifest issue raised by Robert is dealt with, I'm +1 on this release. Congrats to all the contributors to the 3.2 fixes and features; this all looks like good stuff. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r405927 - in /jakarta/commons/proper/collections/trunk/src/java/org/apache/commons/collections: ./ buffer/ functors/ keyvalue/ list/
On Fri, 2006-05-12 at 22:57 +, [EMAIL PROTECTED] wrote: --- jakarta/commons/proper/collections/trunk/src/java/org/apache/commons/collections/functors/OnePredicate.java (original) +++ jakarta/commons/proper/collections/trunk/src/java/org/apache/commons/collections/functors/OnePredicate.java Fri May 12 15:57:03 2006 @@ -41,7 +41,10 @@ /** * Factory to create the predicate. - * + * p + * If the array is size zero, the predicate always returns false. + * If the array is size one, then that predicate is returned. + * I believe this behaviour is different from that in previous releases; prior releases would throw an IllegalArgumentException if an array of size 0 or 1 was passed. In this case, should there be a note that any code taking advantage of this new behaviour is not backwards-compatible with pre-3.2 versions? It's not a backwards incompatibility, because old code will work with this new version. However code that works with this lib work with older versions. When a new method is added, we use @since to let users know that code using this method can't run on earlier versions. However when functionality of an existing method is enhanced, what is the general convention? Is it worth noting or not? Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release collections v3.2
On Sat, 2006-05-13 at 00:15 +0100, Stephen Colebourne wrote: Stephen Colebourne wrote: Simon Kitching indicated +1, but not in the vote thread. Then here's my official vote ;-) +1 Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release collections v3.2
On Thu, 2006-05-11 at 09:15 +0100, Stephen Colebourne wrote: Stephen Colebourne wrote: [X] +1 I support this release [ ] +0 [ ] -0 [ ] -1 I do not support this release because... I support the release, but I'm missing at least one more vote at this point... Is there a Clirr report available? Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[collections] 3.2 RC1 feedback
Hi, There doesn't seem to be an svn tag for this RC1 release. I'm presuming nothing has changed on trunk since this RC was created. MultiValueMap was supposedly added in the 3.2 release, but has a copyright statement listing 2001-2005. Javadoc for GrowthList: seemlessly grow -- seamlessly grow invalid inde -- invalid index and a suggestion: could easily be used together -- can be used together The ReverseListIterator class doesn't have an @since annotation. The javadoc for the BoundedBuffer class looks a bit rough. There are some visual problems, and more importantly documentation on the timeout behaviour seems a little lacking. What do the release notes mean by Transformed*Map. Is this just TransformedMap and TransformedSortedMap? The PriorityBuffer javadocs should perhaps note that the class was made Serializable in release 3.2. Class ListIteratorWrapper should perhaps note that it implements ResettableListIterator since 3.2. What does this mean in the release notes? quote All/Any/One/None Predicate - allow construction with zero or one predicates [37979] /quote I can't see any info in the javadocs for this class that suggest any changes here. Trivial notes: Javadoc for ExtendedProperties: appended like if -- appended as if Otherwise, docs and design all looks really nice. New features are nicely described, and the APIs seem clean. These are some interesting new features. I would like to see the major points above addressed, but don't think anything here requires a new release candidate. If a clirr report shows that there are no backwards-compatibility issues then I'd be happy to vote +1. Unfortunately I don't have time to do that check tonight, so if you need my vote it will have to be in about 24 hours from now... Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] JCL 1.1 FC available for final checks
On Tue, 2006-05-09 at 17:44 -0700, Wendy Smoak wrote: On 5/9/06, Wendy Smoak [EMAIL PROTECTED] wrote: The Log4jFactory class appears to be missing. Never mind, it's in the release notes. Sorry, I expected 1.1 to be a drop-in replacement and was surprised by the error. I don't recall any deprecation warnings, though. I've had this in commons-logging.properties for as long as I can remember: org.apache.commons.logging.LogFactory=org.apache.commons.logging.impl.Log4jFactory Off to read the documentation for 1.0.4 to see what I missed. :) The deprecation info is indeed in the release notes, starting with the 1.0.3 release (April 2003). Three years seems a reasonable phase-out period. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release RC11 As Jakarta Commons Logging 1.1
On Fri, 2006-05-05 at 12:59 -0700, Henri Yandell wrote: On 5/4/06, robert burrell donkin [EMAIL PROTECTED] wrote: --8--- [X] +1 Release Candidate 11 As JCL 1.1 [ ] +0 Positive but have not had time to check release [ ] -0 Negative [ ] -1 Do not release Candidate 11 AS JCL - * Sigs and md5's both verified. * tar.gz's appear to match zips in content. * src zip allows the jar to be built using Maven and Ant (once you figure out how to build under Ant). Lots of Exceptions when running tests (they run in Ant), but it doesn't seem to make it fail - and I get them in SVN trunk anyway. Those exception messages are expected; they are just tests of calls to log.error(some msg, new IndexOutOfBoundsException(..)); when using the simple logger (which always outputs to stdout). So no problems there. +1 for RC11 from me too. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release RC10 As Commons Logging 1.1
On Wed, 2006-05-03 at 22:08 +0100, robert burrell donkin wrote: please check my commits All looks good to me. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
