[jira] Commented: (CONFIGURATION-237) Contrib : managed reloading strategy
[ http://issues.apache.org/jira/browse/CONFIGURATION-237?page=comments#action_12449598 ] nicolas de loof commented on CONFIGURATION-237: --- JMX has multiple way to expose application datas/features. This pacth only includes a static MBean, this means the Class implements an interface with the same name + MBean. Exported into a JMX Server, such a class will automagically expose to JMX management methods (and/or javabean properties) defines by the MBean interface. I myself use Spring MBeanExporter to do the work : bean id=mbeanExporter class=org.springframework.jmx.export.MBeanExporter property name=beans map entry key=myApp:name=configuration bean class=org.apache.commons.configuration.reloading.ManagedReloadingStrategy/ /entry /map /property property name=server ref=mbeanServer/ /bean In fact, I don't know another way to expose a bean to a JMX MBeanServer, as I did never had to do it programmaticaly... Hope it make this more comprehensible. Contrib : managed reloading strategy Key: CONFIGURATION-237 URL: http://issues.apache.org/jira/browse/CONFIGURATION-237 Project: Commons Configuration Issue Type: New Feature Affects Versions: Nightly Builds Reporter: nicolas de loof Priority: Minor Attachments: CONFIGURATION-237.patch This patch adds a reloading strategy based on management request, typically from a JMX console. The Strategy implements a MBean interface so can be exported as a JMX Managed bean with no code change. -- 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: (CONFIGURATION-237) Contrib : managed reloading strategy
[ http://issues.apache.org/jira/browse/CONFIGURATION-237?page=all ] nicolas de loof updated CONFIGURATION-237: -- Attachment: ManagedReloadingStrategyTest.java A simple testcase. Some code may be shared with TestFileChangedReloadingStrategy... Contrib : managed reloading strategy Key: CONFIGURATION-237 URL: http://issues.apache.org/jira/browse/CONFIGURATION-237 Project: Commons Configuration Issue Type: New Feature Affects Versions: Nightly Builds Reporter: nicolas de loof Priority: Minor Attachments: CONFIGURATION-237.patch, ManagedReloadingStrategyTest.java This patch adds a reloading strategy based on management request, typically from a JMX console. The Strategy implements a MBean interface so can be exported as a JMX Managed bean with no code change. -- 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]
[EMAIL PROTECTED]: Project commons-email (in module jakarta-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-email has an issue affecting its community integration. This issue affects 2 projects, and has been outstanding for 17 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-email : Commons Email Package - fulcrum-template : Services Framework Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons/commons-email/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-email-14112006.jar] identifier set to project name -ERROR- Output with id mail.jar was not found in project javamail -ERROR- Unhandled Property: maven.jar.mail on: Maven on Project:commons-email -WARNING- Invalid ID [mail.jar] for dependency on [javamail] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/jakarta-commons/email/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/jakarta-commons/email/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/jakarta-commons/email/project.properties -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons/commons-email/gump_work/build_jakarta-commons_commons-email.html Work Name: build_jakarta-commons_commons-email (Type: Build) Work ended in a state of : Failed Elapsed: 3 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/email] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/target/classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/junit3.8.1/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-14112006.jar:/usr/local/gump/public/workspace/dumbster/build/dumbster.jar:/usr/local/gump/packages/maven-findbugs-plugin/maven-findbugs-plugin-0.9.1.jar:/usr/local/gump/packages/maven-cobertura-plugin/maven-cobertura-plugin-1.1.jar:/usr/local/gump/packages/jaf-1.1ea/activation.jar - __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0.2 You are working offline so the build will continue, but dumbster-SNAPSHOT.jar may be out of date! The build cannot continue because of the following unsatisfied dependency: mail-1.4.jar; path override doesn't exist: /x1/gump/public/workspace/jakarta-commons/email/*Unset* (try downloading from http://java.sun.com/products/javamail/) Total time: 2 seconds Finished at: Tue Nov 14 01:43:54 PST 2006 - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/jakarta-commons/commons-email/rss.xml - Atom: http://vmgump.apache.org/gump/public/jakarta-commons/commons-email/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2214112006, vmgump.apache.org:vmgump-public:2214112006 Gump E-mail Identifier (unique within run) #12. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-email (in module jakarta-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-email has an issue affecting its community integration. This issue affects 2 projects, and has been outstanding for 17 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-email : Commons Email Package - fulcrum-template : Services Framework Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons/commons-email/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-email-14112006.jar] identifier set to project name -ERROR- Output with id mail.jar was not found in project javamail -ERROR- Unhandled Property: maven.jar.mail on: Maven on Project:commons-email -WARNING- Invalid ID [mail.jar] for dependency on [javamail] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/jakarta-commons/email/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/jakarta-commons/email/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/jakarta-commons/email/project.properties -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons/commons-email/gump_work/build_jakarta-commons_commons-email.html Work Name: build_jakarta-commons_commons-email (Type: Build) Work ended in a state of : Failed Elapsed: 3 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/email] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/target/classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/junit3.8.1/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-14112006.jar:/usr/local/gump/public/workspace/dumbster/build/dumbster.jar:/usr/local/gump/packages/maven-findbugs-plugin/maven-findbugs-plugin-0.9.1.jar:/usr/local/gump/packages/maven-cobertura-plugin/maven-cobertura-plugin-1.1.jar:/usr/local/gump/packages/jaf-1.1ea/activation.jar - __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0.2 You are working offline so the build will continue, but dumbster-SNAPSHOT.jar may be out of date! The build cannot continue because of the following unsatisfied dependency: mail-1.4.jar; path override doesn't exist: /x1/gump/public/workspace/jakarta-commons/email/*Unset* (try downloading from http://java.sun.com/products/javamail/) Total time: 2 seconds Finished at: Tue Nov 14 01:43:54 PST 2006 - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/jakarta-commons/commons-email/rss.xml - Atom: http://vmgump.apache.org/gump/public/jakarta-commons/commons-email/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2214112006, vmgump.apache.org:vmgump-public:2214112006 Gump E-mail Identifier (unique within run) #12. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r474786 - /jakarta/commons/proper/commons-build/trunk/nightly_wrapper.sh
Author: psteitz Date: Tue Nov 14 05:50:58 2006 New Revision: 474786 URL: http://svn.apache.org/viewvc?view=revrev=474786 Log: Modified wrapper to up and copy conf file. Modified: jakarta/commons/proper/commons-build/trunk/nightly_wrapper.sh Modified: jakarta/commons/proper/commons-build/trunk/nightly_wrapper.sh URL: http://svn.apache.org/viewvc/jakarta/commons/proper/commons-build/trunk/nightly_wrapper.sh?view=diffrev=474786r1=474785r2=474786 == --- jakarta/commons/proper/commons-build/trunk/nightly_wrapper.sh (original) +++ jakarta/commons/proper/commons-build/trunk/nightly_wrapper.sh Tue Nov 14 05:50:58 2006 @@ -15,8 +15,8 @@ # Update script before executing cd /home/psteitz/trunks-proper/commons-build -svn up commons_nightly.sh -cp commons_nightly.sh /home/psteitz/bin +svn up commons_nightly.sh vmbuild.conf +cp commons_nightly.sh vmbuild.conf /home/psteitz/bin chmod +x /home/psteitz/bin/commons_nightly.sh cd /home/psteitz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-jsl-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 83 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-jsl-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on ant exists, no need to add for property maven.jar.ant-optional. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/gump_work/build_commons-jelly_commons-jelly-tags-jsl-test.html Work Name: build_commons-jelly_commons-jelly-tags-jsl-test (Type: Build) Work ended in a state of : Failed Elapsed: 17 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/commons-cli-1.0.x/target/commons-cli-14112006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-14112006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-14112006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-14112006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-14112006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-14112006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-14112006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-14112006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-14112006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-14112006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-14112006.jar - [junit] at org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:63) [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:58) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:65) [junit] at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:112) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:160) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:80) [junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:102) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:91) [junit] at
svn commit: r474792 - /jakarta/commons/proper/commons-build/trunk/commons_nightly.sh
Author: psteitz Date: Tue Nov 14 06:00:14 2006 New Revision: 474792 URL: http://svn.apache.org/viewvc?view=revrev=474792 Log: Documented fact that config was externalized. TODO: die if no valid config found. Modified: jakarta/commons/proper/commons-build/trunk/commons_nightly.sh Modified: jakarta/commons/proper/commons-build/trunk/commons_nightly.sh URL: http://svn.apache.org/viewvc/jakarta/commons/proper/commons-build/trunk/commons_nightly.sh?view=diffrev=474792r1=474791r2=474792 == --- jakarta/commons/proper/commons-build/trunk/commons_nightly.sh (original) +++ jakarta/commons/proper/commons-build/trunk/commons_nightly.sh Tue Nov 14 06:00:14 2006 @@ -26,6 +26,14 @@ # # Assumes $proper_root points to a checkout of commons proper trunks # and similarly for $sandbox_root +# +# Sources configuration from a file specified on the command line: +# +# Usage: commons_nightly.sh config +# +# Default is vmbuild.conf. See vmbuild.conf for sample config and +# documentation of config parameters. +#=== if [ $# -eq 0 ] then - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (SANDBOX-181) CSVStrategy.clone()
[ http://issues.apache.org/jira/browse/SANDBOX-181?page=all ] Yonik Seeley updated SANDBOX-181: - Attachment: strategy_clone.patch CSVStrategy.clone() --- Key: SANDBOX-181 URL: http://issues.apache.org/jira/browse/SANDBOX-181 Project: Commons Sandbox Issue Type: Improvement Components: CSV Affects Versions: Nightly Builds Reporter: Yonik Seeley Priority: Minor Attachments: strategy_clone.patch Implementing clone for CSVStrategy allows one to start with a known strategy (like excel) and tweak it. -- 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]
svn commit: r474897 - /jakarta/commons/proper/digester/trunk/pom.xml
Author: craigmcc Date: Tue Nov 14 10:06:55 2006 New Revision: 474897 URL: http://svn.apache.org/viewvc?view=revrev=474897 Log: Change my email address to my Apache one. Modified: jakarta/commons/proper/digester/trunk/pom.xml Modified: jakarta/commons/proper/digester/trunk/pom.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/digester/trunk/pom.xml?view=diffrev=474897r1=474896r2=474897 == --- jakarta/commons/proper/digester/trunk/pom.xml (original) +++ jakarta/commons/proper/digester/trunk/pom.xml Tue Nov 14 10:06:55 2006 @@ -68,8 +68,7 @@ developer nameCraig McClanahan/name idcraigmcc/id - email[EMAIL PROTECTED]/email - organizationSun Microsystems/organization + email[EMAIL PROTECTED]/email /developer developer nameRobert Burrell Donkin/name - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Digester] Maven2 POM Questions and Proposals
I've been reviewing the pom.xml for Digester's Maven2 build, and have a combination of questions and proposals to make. I want to run this by the list before doing anything ... I've been out of the loop on Digester for quite a while, so it's unreasonable to just barge back in without coordinating. * The POM declares we are targeting JDK 1.3 (or later). I presume that this is still accurate? * I'd like to update the Commons BeanUtils dependency from 1.6 to 1.7, to pick up the decoupling from Commons Collections (removing the need to explicitly declare this as a dependency), plus the bugfixes in the later release. Any given application can override this in their own application's POM, but my belief is that library releases should encourage updates of their own dependencies to the latest versions we have tested with. (We can document that we've also tested with earlier versions, if desired, but Maven doesn't know how to do things like the either/or dependency on BeanUtils plus Collections). * For similar reasons, I'd like to update the Commons Logging dependency to 1.1 (but we should test against 1.0.4 too). * The currently declared dependency on xml-apis is problematic for downstream users, because it leaves the scope at its default setting (compile). If you build a webapp with Maven2, for example, this causes the XML parser to be included in the WEB-INF/lib directory, even though the servlet containers will essentially always provide a parser for you. I propose to change this dependency to be scope provided, which means it will be on the compile classpath for Digester, but *not* included as a runtime dependency. The implication is that the webapp (or standalone app) you are building will provide a JAXP parser for you, if you're running on 1.3 (not an issue on 1.4 or later, since JAXP is included). * The unit tests don't currently succeed when run from Maven2. I presume that's a bad thing :-), and will dig in to see what is going on. * I'm not going to worry about the site generation, reports, or the assembly stuff at the moment, but I'm sure we will need to address those questions before we can actually do a release. What do you thinK? Craig
Re: [Digester] Maven2 POM Questions and Proposals
Craig McClanahan wrote: I've been reviewing the pom.xml for Digester's Maven2 build, and have a combination of questions and proposals to make. I want to run this by the list before doing anything ... I've been out of the loop on Digester for quite a while, so it's unreasonable to just barge back in without coordinating. * The POM declares we are targeting JDK 1.3 (or later). I presume that this is still accurate? * I'd like to update the Commons BeanUtils dependency from 1.6 to 1.7, to pick up the decoupling from Commons Collections (removing the need to explicitly declare this as a dependency), plus the bugfixes in the later release. Any given application can override this in their own application's POM, but my belief is that library releases should encourage updates of their own dependencies to the latest versions we have tested with. (We can document that we've also tested with earlier versions, if desired, but Maven doesn't know how to do things like the either/or dependency on BeanUtils plus Collections). * For similar reasons, I'd like to update the Commons Logging dependency to 1.1 (but we should test against 1.0.4 too). * The currently declared dependency on xml-apis is problematic for downstream users, because it leaves the scope at its default setting (compile). If you build a webapp with Maven2, for example, this causes the XML parser to be included in the WEB-INF/lib directory, even though the servlet containers will essentially always provide a parser for you. I propose to change this dependency to be scope provided, which means it will be on the compile classpath for Digester, but *not* included as a runtime dependency. The implication is that the webapp (or standalone app) you are building will provide a JAXP parser for you, if you're running on 1.3 (not an issue on 1.4 or later, since JAXP is included). * The unit tests don't currently succeed when run from Maven2. I presume that's a bad thing :-), and will dig in to see what is going on. * I'm not going to worry about the site generation, reports, or the assembly stuff at the moment, but I'm sure we will need to address those questions before we can actually do a release. What do you thinK? Craig Sounds good. Let me know if I can help out with anything Maven related. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Commons-logging] Small patch to make debugging easier
Why the complete lack of response?
If something like that was in the code earlier, it would save me a good
couple of hours, so I believe it is useful enough to be included. I
can't be the only one who encountered this problem.
Or is it the wrong list?
Greetings, Lilianne E. Blaze
Lilianne E. Blaze wrote:
Hello,
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;
}
-
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: [Digester] Maven2 POM Questions and Proposals
On 11/14/06, Dennis Lundberg [EMAIL PROTECTED] wrote: snip/ Let me know if I can help out with anything Maven related. snap/ If you get a chance, can you please indicate your opinions/solutions for the TODOs in this file (right under the ASLv2): http://svn.apache.org/repos/asf/jakarta/commons/proper/digester/trunk/src/assembly/bin.xml -Rahul -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Commons-logging] Small patch to make debugging easier
You're best bet is to attach your patch to a issue at
https://issues.apache.org/jira/browse/LOGGING and then either be
patient or try to get a committer to take interests in your submission
and consider it.
Posting to the mailing list means you're taking a chance that it won't
get noticed by someone who chooses to work on commons logging. Also,
since no one I know around here is paid to work at Apache, things can
seem to be ignored for a long while until someone finds the time and
energy to address your issue.
On 11/14/06, Lilianne E. Blaze [EMAIL PROTECTED] wrote:
Why the complete lack of response?
If something like that was in the code earlier, it would save me a good
couple of hours, so I believe it is useful enough to be included. I
can't be the only one who encountered this problem.
Or is it the wrong list?
Greetings, Lilianne E. Blaze
Lilianne E. Blaze wrote:
Hello,
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
svn commit: r474945 - /jakarta/commons/proper/digester/trunk/src/assembly/bin.xml
Author: rahul Date: Tue Nov 14 12:18:48 2006 New Revision: 474945 URL: http://svn.apache.org/viewvc?view=revrev=474945 Log: We don't have '-bin' suffixes for binary distros in Commons releases. Remove related TODO. Thanks to Wendy Smoak wsmoak AT gmail DOT com Modified: jakarta/commons/proper/digester/trunk/src/assembly/bin.xml Modified: jakarta/commons/proper/digester/trunk/src/assembly/bin.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/digester/trunk/src/assembly/bin.xml?view=diffrev=474945r1=474944r2=474945 == --- jakarta/commons/proper/digester/trunk/src/assembly/bin.xml (original) +++ jakarta/commons/proper/digester/trunk/src/assembly/bin.xml Tue Nov 14 12:18:48 2006 @@ -20,13 +20,12 @@ TODO: 1. Site isn't getting included in binary distro (check includeSiteDirectory usage) - 2. Would like binary distros to be *.zip rather than *-bin.zip, for example - 3. Make source and binary distros unpack in separate directories + 2. Make source and binary distros unpack in separate directories (*-src for source distro is conventional in our distros) -- assembly - idbin/id + id/id formats formattar.gz/format formatzip/format - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (DISCOVERY-8) Discovery fails to build under JDK 1.6
[ http://issues.apache.org/jira/browse/DISCOVERY-8?page=all ] Henri Yandell resolved DISCOVERY-8. --- Fix Version/s: 0.4 Resolution: Fixed Changed to output 1.2 compliant jars - 'maven clean jar' works under 1.6 now. Discovery fails to build under JDK 1.6 -- Key: DISCOVERY-8 URL: http://issues.apache.org/jira/browse/DISCOVERY-8 Project: Commons Discovery Issue Type: Bug Environment: JDK 1.6 on Linux Reporter: Henri Yandell Fix For: 0.4 java:compile: [echo] Compiling to /home/hen/apache/jakarta/commons-proper/discovery/target/classes [javac] Compiling 40 source files to /home/hen/apache/jakarta/commons-proper/discovery/target/classes javac: target release 1.1 conflicts with default source release 1.5 BUILD FAILED File.. /home/hen/.maven/cache/maven-java-plugin-1.5/plugin.jelly Element... ant:javac Line.. 63 Column 48 Compile failed; see the compiler error output for details. Total time: 15 seconds Finished at: Sat Jul 08 13:13:03 EDT 2006 -- 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: [Digester] Maven2 POM Questions and Proposals
Rahul Akolkar wrote: On 11/14/06, Dennis Lundberg [EMAIL PROTECTED] wrote: snip/ Let me know if I can help out with anything Maven related. snap/ If you get a chance, can you please indicate your opinions/solutions for the TODOs in this file (right under the ASLv2): http://svn.apache.org/repos/asf/jakarta/commons/proper/digester/trunk/src/assembly/bin.xml -Rahul 1. Site isn't getting included in binary distro (check includeSiteDirectory usage) According to the assembly descriptor documentation [1] I believe that you should be using: includeSiteDirectorytrue/includeSiteDirectory 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) [1] http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html#class_assembly -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[discovery] 0.4 release
So... things for a 0.4 release: 1) Add apology+info to release notes/sites concerning 0.3. 2) Fix source headers to match new policy. 3) Update to logging 1.1. 4) Build under 1.3 using ant, and the site using maven. 5) Add a pom.xml. 6) Rule out the 4 issues in JIRA for the 0.4 release (or resolve them). 7) Build rc1. 8) Call a vote. That sound about right? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r474995 - /jakarta/commons/proper/discovery/trunk/build.xml
Author: bayard Date: Tue Nov 14 13:37:54 2006 New Revision: 474995 URL: http://svn.apache.org/viewvc?view=revrev=474995 Log: Simplified the location of the junit and logging jars; changed the ant build to build 0.4 Modified: jakarta/commons/proper/discovery/trunk/build.xml Modified: jakarta/commons/proper/discovery/trunk/build.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/discovery/trunk/build.xml?view=diffrev=474995r1=474994r2=474995 == --- jakarta/commons/proper/discovery/trunk/build.xml (original) +++ jakarta/commons/proper/discovery/trunk/build.xml Tue Nov 14 13:37:54 2006 @@ -34,8 +34,8 @@ !-- The directories corresponding to your necessary dependencies -- - property name=junit.jar value=../../junit3.7/junit.jar/ - property name=logger.jar value=../../jakarta-commons/logging/target/commons-logging.jar/ + property name=junit.jar value=lib/junit-3.8.1.jar/ + property name=logger.jar value=lib/commons-logging-1.1.jar/ !-- == Component Declarations -- @@ -51,7 +51,7 @@ property name=component.title value=Commons Discovery/ !-- The current version number of this component -- - property name=component.version value=0.3/ + property name=component.version value=0.4/ !-- The base directory for compilation targets -- property name=build.home value=target/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r474997 - in /jakarta/commons/proper/dbutils/trunk: build.xml project.xml
Author: bayard
Date: Tue Nov 14 13:39:17 2006
New Revision: 474997
URL: http://svn.apache.org/viewvc?view=revrev=474997
Log:
Updated version from 1.1-dev to 1.1-RC1
Modified:
jakarta/commons/proper/dbutils/trunk/build.xml
jakarta/commons/proper/dbutils/trunk/project.xml
Modified: jakarta/commons/proper/dbutils/trunk/build.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/dbutils/trunk/build.xml?view=diffrev=474997r1=474996r2=474997
==
--- jakarta/commons/proper/dbutils/trunk/build.xml (original)
+++ jakarta/commons/proper/dbutils/trunk/build.xml Tue Nov 14 13:39:17 2006
@@ -35,7 +35,7 @@
/property
property name=javadocdir value=dist/docs/api
/property
- property name=final.name value=commons-dbutils-1.1-dev
+ property name=final.name value=commons-dbutils-1.1-RC1
/property
target name=init description=o Initializes some properties
mkdir dir=${libdir}
@@ -138,7 +138,7 @@
/tstamp
property name=copyright value=Copyright amp;copy; Apache Software
Foundation. All Rights Reserved.
/property
-property name=title value=commons-dbutils 1.1-dev API
+property name=title value=commons-dbutils 1.1-RC1 API
/property
javadoc use=true private=true destdir=${javadocdir} author=true
version=true sourcepath=src/java
packagenames=org.apache.commons.dbutils.*
classpath
Modified: jakarta/commons/proper/dbutils/trunk/project.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/dbutils/trunk/project.xml?view=diffrev=474997r1=474996r2=474997
==
--- jakarta/commons/proper/dbutils/trunk/project.xml (original)
+++ jakarta/commons/proper/dbutils/trunk/project.xml Tue Nov 14 13:39:17 2006
@@ -20,7 +20,7 @@
groupIdorg.apache.commons/groupId
artifactIdcommons-dbutils/artifactId
inceptionYear2002/inceptionYear
- currentVersion1.1-SNAPSHOT/currentVersion
+ currentVersion1.1-RC1/currentVersion
nameDbUtils/name
shortDescriptionCommons DbUtils/shortDescription
descriptionA package of Java utility classes for easing JDBC
development/description
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r475011 - /jakarta/commons/proper/discovery/trunk/src/java/org/apache/commons/discovery/tools/ResourceUtils.java
Author: bayard Date: Tue Nov 14 13:51:55 2006 New Revision: 475011 URL: http://svn.apache.org/viewvc?view=revrev=475011 Log: Removed bad javadoc Modified: jakarta/commons/proper/discovery/trunk/src/java/org/apache/commons/discovery/tools/ResourceUtils.java Modified: jakarta/commons/proper/discovery/trunk/src/java/org/apache/commons/discovery/tools/ResourceUtils.java URL: http://svn.apache.org/viewvc/jakarta/commons/proper/discovery/trunk/src/java/org/apache/commons/discovery/tools/ResourceUtils.java?view=diffrev=475011r1=475010r2=475011 == --- jakarta/commons/proper/discovery/trunk/src/java/org/apache/commons/discovery/tools/ResourceUtils.java (original) +++ jakarta/commons/proper/discovery/trunk/src/java/org/apache/commons/discovery/tools/ResourceUtils.java Tue Nov 14 13:51:55 2006 @@ -107,7 +107,6 @@ * liSystem Class Loader/li * /ul * - * @param * @param propertiesFileName The property file name. * * @return Instance of a class implementing the SPI. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discovery] 0.4 release
Discovery has the same issue as dbutils by the way - the build.xml is limited and I guess the previous releases were done from Maven under JDK 1.4. I would be hoping to do the same again. Hen On 11/14/06, Henri Yandell [EMAIL PROTECTED] wrote: So... things for a 0.4 release: 1) Add apology+info to release notes/sites concerning 0.3. 2) Fix source headers to match new policy. 3) Update to logging 1.1. 4) Build under 1.3 using ant, and the site using maven. 5) Add a pom.xml. 6) Rule out the 4 issues in JIRA for the 0.4 release (or resolve them). 7) Build rc1. 8) Call a vote. That sound about right? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (DISCOVERY-1) [discovery] ClassLoader Problem with AXIS in Servlet Container WebSphere
[ http://issues.apache.org/jira/browse/DISCOVERY-1?page=all ]
Henri Yandell updated DISCOVERY-1:
--
Bugzilla Id: (was: 36913)
Fix Version/s: 0.4
Asking on IRC, Dims thinks this one is probably fixed in the current trunk.
[discovery] ClassLoader Problem with AXIS in Servlet Container WebSphere
Key: DISCOVERY-1
URL: http://issues.apache.org/jira/browse/DISCOVERY-1
Project: Commons Discovery
Issue Type: Bug
Environment: Operating System: Windows XP
Platform: PC
Reporter: Torge Harbig
Fix For: 0.4
please excuse bad englisch
Szenario: (ClassLoader)
WebSphere
OurServlet
AXIS
We redirect AXIS Logging (org.apache.commons.logging.LogFactory) to our own
logFactory so that we can output messages of AXIS in our own logFiles.
And we need to prepare service calls for AXIS so all access to AXIS is
indirected over our own Servlet (OurServlet) which loads AXIS using
Class.forName().newInstance()
In WebSphere we get an Exception that AXIS can not load our Logger (AXIS uses
Commons Discovery)
The Problem:
a) WebSphere itself uses Commons Discovery and loads Commons Discovery in the
?WebContainer?-ClassLoader. OurServlet and AXIS are loaded in a
?Servlet?-ClassLoader ...
b) Initializing AXIS / AXIS calls DiscoverSingleton.find() which searches for
the configured logger / but can not find it in the ?WebContainer?-ClassLoader.
It follows a short java file for testing/demonstrating the problem.
Additionally
needed for Test is a Logger Implementation in a single jar File myLogger.jar
(look at the following source)
In the code the exception from commons Discovery is given and a solution we
use
to solve this problem (but perhaps it is not the recommended way) /
Can someone who understands the problem tell me how it should bo solved?
Thanks.
import java.net.URL;
import java.net.URLClassLoader;
import org.apache.commons.discovery.resource.ClassLoaders;
import org.apache.commons.discovery.tools.DefaultClassHolder;
import org.apache.commons.discovery.tools.DiscoverSingleton;
import org.apache.commons.discovery.tools.SPInterface;
public class ClassLoaderTest
{
public static void main( String args[] )throws Exception
{ ClassLoaderTest clt = new ClassLoaderTest();
clt.problem2();
}
static String libPath = file:// **path** ; // set correct path here !!
public void problem1()throws Exception
{ URL url1[] = new URL[]
{ new URL( libPath+commons-discovery.jar),
new URL( libPath+commons-logging.jar),
new URL( libPath+servlet.jar)
};
ClassLoader parentClassLoader
= new URLClassLoader( url1, getClass().getClassLoader() );
URL url2[] = new URL[]
{ new URL( libPath+axis.jar),
new URL( libPath+axis-ant.jar),
new URL( libPath+commons-logging.jar),
new URL( libPath+commons-discovery.jar),
new URL( libPath+log4j-1.2.8.jar),
new URL( libPath+wsdl4j.jar),
new URL( libPath+jaxrpc.jar),
new URL( libPath+xerces.jar),
new URL( libPath+saaj.jar),
new URL( libPath+mylog.jar) // jar with my logger class ...
};
ClassLoader childClassLoader = new URLClassLoader( url2,
parentClassLoader );
System.setProperty
( org.apache.commons.logging.LogFactory
, mylog.MyLogger
);
Class axisServletClass = childClassLoader.loadClass(
org.apache.axis.transport.http.AxisServlet );
Object axisServlet = axisServletClass.newInstance();
/*
* Problem: discovery can not load class mylog.MyLogger in mylog.jar
because
* it is in another class loader ...
*
* AXIS uses DiscoverSingleton.find Method ...
*/
/*
java.lang.ExceptionInInitializerError
at
org.apache.axis.transport.http.AxisServletBase.clinit(AxisServletBase.java:94)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
at java.lang.Class.newInstance0(Class.java:308)
at java.lang.Class.newInstance(Class.java:261)
at ClassLoaderTest.problem(ClassLoaderTest.java:49)
at ClassLoaderTest.main(ClassLoaderTest.java:13)
Caused by: org.apache.commons.discovery.DiscoveryException: No
implementation defined for org.apache.commons.logging.LogFactory
at
org.apache.commons.discovery.tools.DiscoverClass.find(DiscoverClass.java:407)
at
org.apache.commons.discovery.tools.DiscoverClass.newInstance(DiscoverClass.java:582)
at
[jira] Commented: (BEANUTILS-41) [beanutils] Provide better error message for No value specified
[ http://issues.apache.org/jira/browse/BEANUTILS-41?page=comments#action_12449862 ] Henri Yandell commented on BEANUTILS-41: 1) -1 to the API change. I think it would be better for the copyProperties method to catch the ConversionException and then log.error something with more context and throw a BeanUtilsCopyException that wraps it. 2) This code has been overhauled and the new code (DateTimeConverter) seems to do a better job about mentioning the types it is trying for (I've added a bit more). 3) I think this would overload the error. So in terms of work needing to be done; I think there should be code where Converters are called that catch ConversionExceptions and apply knowledge about the bean specific context. [beanutils] Provide better error message for No value specified - Key: BEANUTILS-41 URL: http://issues.apache.org/jira/browse/BEANUTILS-41 Project: Commons BeanUtils Issue Type: Bug Components: ConvertUtils Converters Environment: Operating System: other Platform: Other Reporter: Ralf Hauser Fix For: 1.8.0 Got org.apache.commons.beanutils.ConversionException: No value specified at org.apache.commons.beanutils.converters.SqlDateConverter.convert(SqlDateConverter.java:103) at org.apache.commons.beanutils.BeanUtilsBean.copyProperty(BeanUtilsBean.java:444) at org.apache.commons.beanutils.BeanUtilsBean.copyProperties(BeanUtilsBean.java:261) at org.apache.commons.beanutils.BeanUtils.copyProperties(BeanUtils.java:114) Suggestion: 1) cite the propName and the bean className this probably implies that the interface org.apache.commons.beanutils.Converter.convert(Class type, Object value) is extended to org.apache.commons.beanutils.Converter.convert(Class type, Object value, String propName, String beanClassName) 2) also cite the concerned class name (probably java.sql.Date) 3) mention that there is the possibility to use a default value -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BEANUTILS-64) [beanutils] ConvertUtils.convert returns 0 for Strings with leading blanks at converting String arrays to Integer arrays
[ http://issues.apache.org/jira/browse/BEANUTILS-64?page=comments#action_12449863 ] Henri Yandell commented on BEANUTILS-64: I think this issue is ready for FIXED then? [beanutils] ConvertUtils.convert returns 0 for Strings with leading blanks at converting String arrays to Integer arrays Key: BEANUTILS-64 URL: http://issues.apache.org/jira/browse/BEANUTILS-64 Project: Commons BeanUtils Issue Type: Bug Components: ConvertUtils Converters Environment: Operating System: Windows XP Platform: PC Reporter: Rainer Dollinger Priority: Minor Fix For: 1.8.0 When using ConvertUtils.convert(String[], Class) with Integer as element type to convert an Array of number Strings to Integer, it returns Integers with value 0, if there is a blank at the start of the number. If the method ConvertUtils.convert would do a String.trim() internally on the elements of the String array this could be avoided. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BEANUTILS-233) [beanutils] DynaProperty doesn't override equals or hashCode
[ http://issues.apache.org/jira/browse/BEANUTILS-233?page=comments#action_12449864 ] Henri Yandell commented on BEANUTILS-233: - +1, Dynas are in a loose world, so I think it's okay for the comparison to be loose. COM-1785 became BEANUTILS-212 I think. [beanutils] DynaProperty doesn't override equals or hashCode Key: BEANUTILS-233 URL: http://issues.apache.org/jira/browse/BEANUTILS-233 Project: Commons BeanUtils Issue Type: Improvement Components: DynaBean Affects Versions: Nightly Builds Environment: Operating System: All Platform: All Reporter: Russell Priority: Minor Fix For: 1.8.0 Attachments: DynaPropertyTestCase.java, patchfile.txt Meaningful implementations of these methods are necessary for implementing the same methods in classes that use DynaProperty. The reference equality test provided by Object is not useful in most cases. I have a patch and a new TestCase, but don't see a way to attach it on this form. I wasn't sure about the build number either. I got the source from anonymous svn. -- 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: (BEANUTILS-215) BeanUtilsBean: Set a mapped/indexed property, for example property(time)[0]
[ http://issues.apache.org/jira/browse/BEANUTILS-215?page=all ]
Henri Yandell updated BEANUTILS-215:
Attachment: BEANUTILS-215.patch
I'm not sure if this is a correct reproduction of this bug, but thought I'd
share it as it does seem to try to do what the poster is asking for and fails.
BeanUtilsBean: Set a mapped/indexed property, for example property(time)[0]
-
Key: BEANUTILS-215
URL: http://issues.apache.org/jira/browse/BEANUTILS-215
Project: Commons BeanUtils
Issue Type: Improvement
Components: Expression Syntax
Environment: Operating System: other
Platform: Other
Reporter: Ludwig Wensauer
Priority: Minor
Fix For: 1.8.0
Attachments: BEANUTILS-215.patch
From line 1014 ff there is the following piece of code:
try {
if (index = 0) {
getPropertyUtils().setIndexedProperty(target, propName,
index, newValue);
} else if (key != null) {
getPropertyUtils().setMappedProperty(target, propName,
key, newValue);
} else {
getPropertyUtils().setProperty(target, propName, newValue);
}
...
That's good for mapped OR indexed properties, but unfortunatly i have both at
the same time. So index is = 0 and key is also != null.
My property-name looks like this one here:
property(time)[0]
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BEANUTILS-228) [beanutils] ConvertUtilsBean: register converter for specific property
[ http://issues.apache.org/jira/browse/BEANUTILS-228?page=comments#action_12449880 ] Henri Yandell commented on BEANUTILS-228: - I wonder if the destinationClass is necessary in this API. It seems that the user will get all they need with: register(Converter, Class beanClass, String propertyName). Thoughts? [beanutils] ConvertUtilsBean: register converter for specific property -- Key: BEANUTILS-228 URL: http://issues.apache.org/jira/browse/BEANUTILS-228 Project: Commons BeanUtils Issue Type: Improvement Components: ConvertUtils Converters Affects Versions: 1.5 Environment: Operating System: other Platform: Other Reporter: Michael Schuerig Priority: Minor Fix For: 1.8.0 Currently, converters are selected only based on the class to which they convert objects. In general this works pretty well, but I've encountered cases, where this doesn't work out. For example, I'm using java.util.Date objects to represent points and intervals in time that are not completely specific, such as day of the week and month. Now I can easily write a Converter that uses SimpleDateFormat to convert string representations of these dates (Mon, Feb) to Date objects. When I register one of these converters with ConvertUtils(Bean), though, it preempts any conversion to Date. Something I clearly don't want as I have to deal with different kinds of dates. As a solution, I'd like to be able to register a converter for a specific property of a bean class, with a method this ConvertUtilsBean#register(Converter converter, java.lang.Class destinationClass, java.lang.Class beanClass, java.lang.String propertyName) Michael -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BEANUTILS-210) [beanutils] copyProperties should have optional flag for including transient member variables
[ http://issues.apache.org/jira/browse/BEANUTILS-210?page=comments#action_12449881 ] Henri Yandell commented on BEANUTILS-210: - Having a copyNotTransients seems of value, but unless someone has an actual itch for such a thing I think we should move this out of 1.8.0 and record it as Will apply if someone patches. [beanutils] copyProperties should have optional flag for including transient member variables - Key: BEANUTILS-210 URL: http://issues.apache.org/jira/browse/BEANUTILS-210 Project: Commons BeanUtils Issue Type: Improvement Components: Bean / Property Utils Environment: Operating System: other Platform: Other Reporter: Nathan Egge Priority: Minor Fix For: 1.8.0 The EqualsBuilder, HashCodeBuilder, and ToStringBuilder all have a flag for allowing you to use only the non-transient member variables on an object. The BeanUtils.copyProperties method should have a similar such variable (which can default to false) so you can designate only some variables to copy across domains. -- 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: (BEANUTILS-193) [beanutils] MethodUtils.invoke for static methods
[ http://issues.apache.org/jira/browse/BEANUTILS-193?page=all ] Henri Yandell updated BEANUTILS-193: Attachment: BEANUTILS-193-impl.patch Patch modified to be invokeStaticMethod and invokeExactStaticMethod. Need to write tests. [beanutils] MethodUtils.invoke for static methods - Key: BEANUTILS-193 URL: http://issues.apache.org/jira/browse/BEANUTILS-193 Project: Commons BeanUtils Issue Type: Improvement Components: Bean / Property Utils Affects Versions: 1.6 Environment: Operating System: Windows XP Platform: PC Reporter: Nestor Boscan Priority: Minor Fix For: 1.8.0 Attachments: BEANUTILS-193-impl.patch, MethodUtils.java I modified the MethodUtils class and added 6 new methods to invoke static methods. invokeExactMethod (Class, String, Object []) invokeExactMethod (Class, String, Object [], Class []) invokeExactMethod (Class, String, Object) invokeMethod (Class, String, Object []) invokeMethod (Class, String, Object [], Class []) invokeMethod (Class, String, Object) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BEANUTILS-248) Code to create a JavaBean and set its properties from a Java Properties instance
[ http://issues.apache.org/jira/browse/BEANUTILS-248?page=comments#action_12449891 ] Henri Yandell commented on BEANUTILS-248: - Easy enough, means adding a populateNewInstance(Class beanClass, Map values) to BeanUtils and BeanUtilsBean. Code to create a JavaBean and set its properties from a Java Properties instance Key: BEANUTILS-248 URL: http://issues.apache.org/jira/browse/BEANUTILS-248 Project: Commons BeanUtils Issue Type: Improvement Components: Bean / Property Utils Environment: Coded on Windows XP professional with Netbean 5.5 Beta 2 using JDK 1.5.0 Reporter: Trevor Charles Miller Priority: Minor Fix For: 1.8.0 Attachments: BeanCreator.java The idea is simple and I've seen this done in Log4J and had a use case for it myself in another project. Given a set of properties, create an instance of a specified class and set properties on it. I think this could be very useful for runtime configuration. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BEANUTILS-248) Code to create a JavaBean and set its properties from a Java Properties instance
[
http://issues.apache.org/jira/browse/BEANUTILS-248?page=comments#action_12449893
]
Henri Yandell commented on BEANUTILS-248:
-
public Object populateNewInstance(Class beanClass, Map properties) {
Class beanClass = Class.forName(className); // TODO:
ContextClassLoader?
Object bean = beanClass.newInstance();
populate(bean, properties);
return bean;
}
Code to create a JavaBean and set its properties from a Java Properties
instance
Key: BEANUTILS-248
URL: http://issues.apache.org/jira/browse/BEANUTILS-248
Project: Commons BeanUtils
Issue Type: Improvement
Components: Bean / Property Utils
Environment: Coded on Windows XP professional with Netbean 5.5 Beta 2
using JDK 1.5.0
Reporter: Trevor Charles Miller
Priority: Minor
Fix For: 1.8.0
Attachments: BeanCreator.java
The idea is simple and I've seen this done in Log4J and had a use case for it
myself in another project. Given a set of properties, create an instance of a
specified class and set properties on it. I think this could be very useful
for runtime configuration.
--
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: (BEANUTILS-208) [beanutils] MethodUtils: Need easy way to invoke static methods
[ http://issues.apache.org/jira/browse/BEANUTILS-208?page=all ] Henri Yandell resolved BEANUTILS-208. - Resolution: Duplicate Okay, I know this one is older than the dupe (BEANUTILS-193), but that one has a patch :) [beanutils] MethodUtils: Need easy way to invoke static methods --- Key: BEANUTILS-208 URL: http://issues.apache.org/jira/browse/BEANUTILS-208 Project: Commons BeanUtils Issue Type: Improvement Components: Bean / Property Utils Affects Versions: Nightly Builds Environment: Operating System: other Platform: Other Reporter: analogue Priority: Minor Fix For: 1.8.0 May I suggest: public static Object invokeStaticMethod(Class clazz, String methodName, Class[] args); -- 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: (LANG-291) Null-safe comparison methods for finding most recent / least recent dates.
[ http://issues.apache.org/jira/browse/LANG-291?page=comments#action_12449906 ] Henri Yandell commented on LANG-291: Quite likely - the 2.3 Enum issues haven't played out as I thought they would - very little change to Lang; so I'm just chugging along and adding things that won't break backwards compat. I figured I shouldn't be releasing 2.3 too soon, so BeanUtils, DbUtils and Discovery have been jumping ahead in my queue. I'll go ahead and look at applying this if no one else does soon. Null-safe comparison methods for finding most recent / least recent dates. -- Key: LANG-291 URL: http://issues.apache.org/jira/browse/LANG-291 Project: Commons Lang Issue Type: Improvement Environment: N/A Reporter: David J. M. Karlsen Fix For: 3.0 Attachments: DateUtils-patch-rev468924.txt, ObjectUtils-patch-rev470351.txt /** * p * Null-safe date comparison. * Returnes the most recent date if date1 and date2 is non-null. * If one of the dates are null, the non-null will be returned. * If both are null, null will be returned. * /p * @param date1 * @param date2 * @return */ public static Date mostRecent( Date date1, Date date2 ) /** * p * Null-safe date comparison. * Returnes the least recent (oldest) date if date1 and date2 is non-null. * If one of the dates are null, the non-null will be returned. * If both are null, null will be returned. * /p * @param date1 * @param date2 * @return */ public static Date leastRecent( Date date1, Date date2 ) -- 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]
svn commit: r475111 - /jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/mutable/MutableTestSuite.java
Author: bayard
Date: Tue Nov 14 20:11:55 2006
New Revision: 475111
URL: http://svn.apache.org/viewvc?view=revrev=475111
Log:
Bit of an odd unit test, causes trouble under maven-2. So fixing it to make it
more like the other tests
Modified:
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/mutable/MutableTestSuite.java
Modified:
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/mutable/MutableTestSuite.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/mutable/MutableTestSuite.java?view=diffrev=475111r1=475110r2=475111
==
---
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/mutable/MutableTestSuite.java
(original)
+++
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/mutable/MutableTestSuite.java
Tue Nov 14 20:11:55 2006
@@ -18,6 +18,7 @@
package org.apache.commons.lang.mutable;
import junit.framework.Test;
+import junit.framework.TestCase;
import junit.framework.TestSuite;
import junit.textui.TestRunner;
@@ -26,12 +27,16 @@
*
* @version $Id$
*/
-public class MutableTestSuite {
+public class MutableTestSuite extends TestCase {
public static void main(String[] args) {
TestRunner.run(suite());
}
+public MutableTestSuite(String name) {
+super(name);
+}
+
public static Test suite() {
final TestSuite suite = new TestSuite();
@@ -45,9 +50,6 @@
suite.addTest(MutableObjectTest.suite());
return suite;
-}
-
-private MutableTestSuite() {
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r475113 - in /jakarta/commons/proper/lang/trunk/src: java/org/apache/commons/lang/ObjectUtils.java test/org/apache/commons/lang/ObjectUtilsTest.java
Author: bayard
Date: Tue Nov 14 20:14:42 2006
New Revision: 475113
URL: http://svn.apache.org/viewvc?view=revrev=475113
Log:
Applying max/min for Comparables as supplied by David Karlsen in LANG-291
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/ObjectUtils.java
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/ObjectUtilsTest.java
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/ObjectUtils.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/ObjectUtils.java?view=diffrev=475113r1=475112r2=475113
==
---
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/ObjectUtils.java
(original)
+++
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/ObjectUtils.java
Tue Nov 14 20:14:42 2006
@@ -31,6 +31,7 @@
* @author Stephen Colebourne
* @author Gary Gregory
* @author Mario Winterer
+ * @author a href=mailto:[EMAIL PROTECTED]David J. M. Karlsen/a
* @since 1.0
* @version $Id$
*/
@@ -276,5 +277,52 @@
return ObjectUtils.NULL;
}
}
+
+
+/**
+ * Null safe comparison of Comparables.
+ *
+ * @param c1
+ * @param c2
+ * @return
+ * ul
+ * liIf both objects are non-null and unequal, the lesser object.
+ * liIf both objects are non-null and equal, c1.
+ * liIf one of the comparables is null, the non-null object.
+ * liIf both the comparables are null, null is returned.
+ * /ul
+ */
+public static Object min( Comparable c1, Comparable c2 ) {
+if ( c1 != null c2 != null ) {
+return c1.compareTo( c2 ) 1 ? c1 : c2;
+}
+else {
+return c1 != null ? c1 : c2;
+}
+}
+
+/**
+ * Null safe comparison of Comparables.
+ *
+ * @param c1
+ * @param c2
+ * @return
+ * ul
+ * liIf both objects are non-null and unequal, the greater object.
+ * liIf both objects are non-null and equal, c1.
+ * liIf one of the comparables is null, the non-null object.
+ * liIf both the comparables are null, null is returned.
+ * /ul
+ */
+public static Object max( Comparable c1, Comparable c2 ) {
+if ( c1 != null c2 != null ) {
+return c1.compareTo( c2 ) = 0 ? c1 : c2;
+}
+else {
+return c1 != null ? c1 : c2;
+}
+}
+
+
}
Modified:
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/ObjectUtilsTest.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/ObjectUtilsTest.java?view=diffrev=475113r1=475112r2=475113
==
---
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/ObjectUtilsTest.java
(original)
+++
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/ObjectUtilsTest.java
Tue Nov 14 20:14:42 2006
@@ -18,6 +18,8 @@
import java.lang.reflect.Constructor;
import java.lang.reflect.Modifier;
+import java.util.Calendar;
+import java.util.Date;
import junit.framework.Test;
import junit.framework.TestCase;
@@ -175,5 +177,40 @@
assertTrue(ObjectUtils.NULL instanceof ObjectUtils.Null);
assertSame(ObjectUtils.NULL,
SerializationUtils.clone(ObjectUtils.NULL));
}
-
+
+
+
+public void testMax() {
+Calendar calendar = Calendar.getInstance();
+Comparable nonNullComparable1 = calendar.getTime();
+Comparable nonNullComparable2 = calendar.getTime();
+
+calendar.set( Calendar.YEAR, calendar.get( Calendar.YEAR ) -1 );
+Comparable minComparable = calendar.getTime();
+
+assertNotSame( nonNullComparable1, nonNullComparable2 );
+
+assertSame( nonNullComparable1, ObjectUtils.max( null,
nonNullComparable1 ) );
+assertSame( nonNullComparable1, ObjectUtils.max( nonNullComparable1,
null ) );
+assertSame( nonNullComparable1, ObjectUtils.max( nonNullComparable1,
nonNullComparable2 ) );
+assertSame( nonNullComparable1, ObjectUtils.max( nonNullComparable1,
minComparable ) );
+assertSame( nonNullComparable1, ObjectUtils.max( minComparable,
nonNullComparable1 ) );
+}
+
+public void testMin() {
+Calendar calendar = Calendar.getInstance();
+Comparable nonNullComparable1 = calendar.getTime();
+Comparable nonNullComparable2 = calendar.getTime();
+
+calendar.set( Calendar.YEAR, calendar.get( Calendar.YEAR ) -1 );
+Comparable minComparable = calendar.getTime();
+
+assertNotSame( nonNullComparable1, nonNullComparable2 );
+
+assertSame(
[jira] Resolved: (LANG-291) Null-safe comparison methods for finding most recent / least recent dates.
[ http://issues.apache.org/jira/browse/LANG-291?page=all ] Henri Yandell resolved LANG-291. Fix Version/s: 2.3 (was: 3.0) Resolution: Fixed Bit sooner than I thought: svn ci -m Applying max/min for Comparables as supplied by David Karlsen in LANG-291 src/ Sendingsrc/java/org/apache/commons/lang/ObjectUtils.java Sendingsrc/test/org/apache/commons/lang/ObjectUtilsTest.java Transmitting file data .. Committed revision 475113. Null-safe comparison methods for finding most recent / least recent dates. -- Key: LANG-291 URL: http://issues.apache.org/jira/browse/LANG-291 Project: Commons Lang Issue Type: Improvement Environment: N/A Reporter: David J. M. Karlsen Fix For: 2.3 Attachments: DateUtils-patch-rev468924.txt, ObjectUtils-patch-rev470351.txt /** * p * Null-safe date comparison. * Returnes the most recent date if date1 and date2 is non-null. * If one of the dates are null, the non-null will be returned. * If both are null, null will be returned. * /p * @param date1 * @param date2 * @return */ public static Date mostRecent( Date date1, Date date2 ) /** * p * Null-safe date comparison. * Returnes the least recent (oldest) date if date1 and date2 is non-null. * If one of the dates are null, the non-null will be returned. * If both are null, null will be returned. * /p * @param date1 * @param date2 * @return */ public static Date leastRecent( Date date1, Date date2 ) -- 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: [dbutils] Preparing the 1.1 release
Henri Yandell wrote: Ideally I'd want to use Ant to build the dist under 1.3 and then use Maven to generate the site under 1.5. I'd use 1.2, but I'm not setup for that at the moment. In this case, I want to use Maven to do everything under 1.4 and point to the fact that Ant works under 1.3 to build a jar/test as justification that it's okay to do it under 1.4. My personal justifcation for the Ant files is that Maven-1 doesn't work under 1.2/1.3, so I'm a bit low personal itch-wise for implementing lots of stuff in the Ant files. +1 -- Dennis Lundberg If the above is okay, I'll probably rm the javadoc parts of the build files as unnecessary. Hen On 11/14/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Henri Yandell wrote: On 11/14/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Henri Yandell wrote: While starting to prepare the 1.1 release I noticed that the build.xml lacks some of the stuff (and the javadoc xml that is there isn't too hot). The previous dbutils 1.0 release was done via Maven in JDK 1.4 (with JDK 1.2 as a target). The Ant build works fine under 1.3 - is there any reason to work on the build.xml, or can the JDK 1.4 release be used (given that the 1.3 builds happily)? Hen Did you try to rebuild the build.xml using Maven? The build.xml file in SVN states that it was generated by Maven and then hand edited. If the changes are limited we might be able to merge those into a freshly Maven-generated build.xml. Good point, but doing that doesn't help. No zip/tar.gz style bits get created. Hen Ah, now I see what you meant. You want to use Maven to build the release distro, but keep a build.xml around for people who want to build the jar themselves using Ant. Need ... sleep ... now ... -- Dennis Lundberg - 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: [dbutils] Preparing the 1.1 release
Sorry, I didn't read the beginning of this thread. Do you want to create an Ant build only to ensure compilation for Java 1.3 runtime ? I'm doing the same with maven by setting the compiler plugin to use JRE 1.3 rt.jar as bootclasspath. I've made some tests to ensure this produces java 1.3 compliant code and doesn't link classes to methods introduced in Java 1.4/Java5. Nico. Dennis Lundberg a écrit : Henri Yandell wrote: Ideally I'd want to use Ant to build the dist under 1.3 and then use Maven to generate the site under 1.5. I'd use 1.2, but I'm not setup for that at the moment. In this case, I want to use Maven to do everything under 1.4 and point to the fact that Ant works under 1.3 to build a jar/test as justification that it's okay to do it under 1.4. My personal justifcation for the Ant files is that Maven-1 doesn't work under 1.2/1.3, so I'm a bit low personal itch-wise for implementing lots of stuff in the Ant files. +1 This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
