Re: REPOST [attributes 2.2] Missing optional package Extension
The manifest.mf in SVN contain a Created-By: Apache Maven but I never got maven include such Extension-List in my manifest. The one generated by the maven build don't include them. It seems the maven.jar.manifest.extensions.add option creates those entries in manifest. Maybe this property was set on the debian box used to build attributes 2.2 ? From maven jar plugin doc : maven.jar.manifest.extensions.add : Tells Maven to add extension information to the jar manifest. This can cause some applications to break, so it has been disabled by default. An Implementation-Vendor-Id attribute will be added for each dependency that has a vendorId element set in its properties section. Set to true to enable extension information. Seems using such extension is not recommended... I've used maven (not ant) to build on Windows. I can't test on a Mac. I've checked for 1.4 methods by importing api/compiler/unittest into eclipse and setting JRE to 1.3 : There is no compile requirement for Java 1.4 Maybe those compiler options have been set to allow compilation under Java5 JDK. The ant build.xml contains source=1.4 target=1.4 for the Javac task. I've trie building with source=1.3 target=1.3 and it passed Nico. 2007/1/4, Henri Yandell [EMAIL PROTECTED]: On 1/4/07, nicolas de loof [EMAIL PROTECTED] wrote: According to SVN log, the manifest has been added by bayard. The maven generated manifest is not used (why ?) These are for the Ant build - they're the ones that Maven generated for me. Seem to recall that attributes didn't like building on the Mac, so this was done on a Debian Linux box with Sun 1.4.2 and Maven 1.0.2. Unless manifest.mf is a name convention; they're not used for the Maven build. I also notice maven.compiler.target has been set to 1.4 during 2.2 (rev 410143 by leosutic) that will break backward compatibility : I'm using commons-attributes on other projects on JRE 1.3. I've tested some changes from commons-attributes trunk : change maven.compiler.source and maven.compiler.target to 1.3 in project.properties Does it compile under 1.3 for you (using Ant I presume)? I'm wondering why the move to 1.4 was done, maybe there's a call to a 1.4 only method in there somewhere. remove manifest.mf from api sub-project Should be unnecessary. remove dependencies in api/project.xml (as they are only required by compiler) +1. With those changes, my webapp launch fine and run as expected. From what I've read, Extension-List is used to allow downloading of libs at runtime when not available in classpath. As ant and qdox manifest don't declare themself as extensions, the extension resolution fails. I'd suggest a new release as compatibility with 1.3 is blocking for me to upgrade. Sounds good - once we grok why it was moved to 1.4. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons Transaction 1.2
Niall Pemberton niall.pemberton at gmail.com writes: Since RC3 was created (back in July 2006!) there is now the new Source Header and Copyright Notice Policy that needs to be complied with: http://www.apache.org/legal/src-headers.html Henri fixed this in the trunk for transaction a few weeks ago - but warrants a new RC IMO. Ok, that's an issue. Also Rahul raised the issue about dependency jars held in the repository - and it looked to me like you were going to change the build to download these automatically, rather than including them in the distro: http://tinyurl.com/yby9hd We wanted to get out the release as fast as possible. This issue can be postponed and addressed later IMO. I also think given the long time between cutting the RC and voting this makes the case for tagging the repository - initially I wondered where this had been built from as it didn't match any current source - until I releaized it had been done so long ago. The long time itself is not an issue, nothing has changed on the source code since the latest RC except the headers. The commits I did recently don't fix the issue (not buildable with JDK 1.3 due to 1.4 compiled dependencies), but only show the issue at a different during a build. This itself does not warrant a new RC IMO, but as the headers do so, it will be included in that RC as well. Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sandbox] Using commons-skin for all components
+1 here. On 1/4/07, Jörg Schaible [EMAIL PROTECTED] wrote: +1 Dennis Lundberg wrote on Thursday, January 04, 2007 10:34 PM: Hi Before I dive head-first into this I thought I'd ask first. I'd like to unify the M2 generated sites for all sandbox components, by making use of commons-skin. This would mean: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-betwixt (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-betwixt has an issue affecting its community integration. This issue affects 9 projects, and has been outstanding for 2 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-betwixt : Commons Betwixt Package - commons-jelly-tags-betwixt : Commons Jelly - commons-jelly-tags-ojb : Commons Jelly - db-ddlutils : Easy-to-use component for working with Database Definition (... - db-ojb : ObjectRelationalBridge - db-ojb-from-packages : ObjectRelationalBridge - jakarta-slide : Content Management System based on WebDAV technology - maven-bootstrap : Project Management Tools - test-ojb : ObjectRelationalBridge Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons/commons-betwixt/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-betwixt-05012007.jar] identifier set to project name -INFO- Failed with reason build failed -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons/commons-betwixt/gump_work/build_jakarta-commons_commons-betwixt.html Work Name: build_jakarta-commons_commons-betwixt (Type: Build) Work ended in a state of : Failed Elapsed: 1 min 2 secs Command Line: java -Djava.awt.headless=true -Dant.build.clonevm=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dfinal.name=commons-betwixt-05012007 -Dresourcedir=/usr/local/gump/public/workspace/jakarta-commons/betwixt jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/betwixt] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/betwixt/target/classes:/usr/local/gump/public/workspace/jakarta-commons/betwixt/target/test-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/xml-commons/java/external/build/xml-apis-ext.jar:/usr/local/gump/public/workspace/jakarta-commons/digester/dist/commons-digester.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-05012007.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-05012007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-05012007.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar - [junit] Running org.apache.commons.betwixt.TestOptions [junit] Testsuite: org.apache.commons.betwixt.TestOptions [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.32 sec [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.32 sec [junit] [junit] Testcase: testGetValue took 0.007 sec [junit] Testcase: testGetNames took 0.002 sec [junit] Testcase: testAddOptions took 0.005 sec [junit] Running org.apache.commons.betwixt.TestRSSRoundTrip [junit] Testsuite: org.apache.commons.betwixt.TestRSSRoundTrip [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 20.811 sec [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 20.811 sec [junit] [junit] Testcase: testRoundTrip took 20.545 sec [junit] Caused an ERROR [junit] my.netscape.com [junit] java.net.UnknownHostException: my.netscape.com [junit] at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:177) [junit] at java.net.Socket.connect(Socket.java:507) [junit] at java.net.Socket.connect(Socket.java:457) [junit] at sun.net.NetworkClient.doConnect(NetworkClient.java:157) [junit] at sun.net.www.http.HttpClient.openServer(HttpClient.java:365) [junit] at sun.net.www.http.HttpClient.openServer(HttpClient.java:477)
[EMAIL PROTECTED]: Project commons-betwixt (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-betwixt has an issue affecting its community integration. This issue affects 9 projects, and has been outstanding for 2 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-betwixt : Commons Betwixt Package - commons-jelly-tags-betwixt : Commons Jelly - commons-jelly-tags-ojb : Commons Jelly - db-ddlutils : Easy-to-use component for working with Database Definition (... - db-ojb : ObjectRelationalBridge - db-ojb-from-packages : ObjectRelationalBridge - jakarta-slide : Content Management System based on WebDAV technology - maven-bootstrap : Project Management Tools - test-ojb : ObjectRelationalBridge Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons/commons-betwixt/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-betwixt-05012007.jar] identifier set to project name -INFO- Failed with reason build failed -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons/commons-betwixt/gump_work/build_jakarta-commons_commons-betwixt.html Work Name: build_jakarta-commons_commons-betwixt (Type: Build) Work ended in a state of : Failed Elapsed: 1 min 2 secs Command Line: java -Djava.awt.headless=true -Dant.build.clonevm=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dfinal.name=commons-betwixt-05012007 -Dresourcedir=/usr/local/gump/public/workspace/jakarta-commons/betwixt jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/betwixt] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/betwixt/target/classes:/usr/local/gump/public/workspace/jakarta-commons/betwixt/target/test-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/xml-commons/java/external/build/xml-apis-ext.jar:/usr/local/gump/public/workspace/jakarta-commons/digester/dist/commons-digester.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-05012007.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-05012007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-05012007.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar - [junit] Running org.apache.commons.betwixt.TestOptions [junit] Testsuite: org.apache.commons.betwixt.TestOptions [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.32 sec [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.32 sec [junit] [junit] Testcase: testGetValue took 0.007 sec [junit] Testcase: testGetNames took 0.002 sec [junit] Testcase: testAddOptions took 0.005 sec [junit] Running org.apache.commons.betwixt.TestRSSRoundTrip [junit] Testsuite: org.apache.commons.betwixt.TestRSSRoundTrip [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 20.811 sec [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 20.811 sec [junit] [junit] Testcase: testRoundTrip took 20.545 sec [junit] Caused an ERROR [junit] my.netscape.com [junit] java.net.UnknownHostException: my.netscape.com [junit] at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:177) [junit] at java.net.Socket.connect(Socket.java:507) [junit] at java.net.Socket.connect(Socket.java:457) [junit] at sun.net.NetworkClient.doConnect(NetworkClient.java:157) [junit] at sun.net.www.http.HttpClient.openServer(HttpClient.java:365) [junit] at sun.net.www.http.HttpClient.openServer(HttpClient.java:477)
[nightly build] betwixt failed.
Failed build logs: http://people.apache.org/~psteitz/commons-nightlies/20070105/betwixt.log - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly-tags-soap (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-soap has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 28 runs. The current state of this project is 'Failed', with reason 'Configuration Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-soap : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-soap/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-soap-05012007.jar] identifier set to project name -ERROR- No such project [ws-jaxme] for property. -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-api on: Maven on Project:commons-jelly-tags-soap -DEBUG- Dependency on ws-axis exists, no need to add for property maven.jar.axis. -DEBUG- Dependency on ws-axis exists, no need to add for property maven.jar.jaxrpc-api. -DEBUG- Dependency on ws-axis exists, no need to add for property maven.jar.saaj-api. -DEBUG- Dependency on jakarta-servletapi-5-servlet exists, no need to add for property maven.jar.servletapi. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: ws-jaxme unknown to *this* workspace -INFO- Failed to extract fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-soap/rss.xml - Atom: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-soap/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2005012007, vmgump.apache.org:vmgump-public:2005012007 Gump E-mail Identifier (unique within run) #33. -- 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-jelly-tags-soap (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-soap has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 28 runs. The current state of this project is 'Failed', with reason 'Configuration Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-soap : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-soap/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-soap-05012007.jar] identifier set to project name -ERROR- No such project [ws-jaxme] for property. -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-api on: Maven on Project:commons-jelly-tags-soap -DEBUG- Dependency on ws-axis exists, no need to add for property maven.jar.axis. -DEBUG- Dependency on ws-axis exists, no need to add for property maven.jar.jaxrpc-api. -DEBUG- Dependency on ws-axis exists, no need to add for property maven.jar.saaj-api. -DEBUG- Dependency on jakarta-servletapi-5-servlet exists, no need to add for property maven.jar.servletapi. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: ws-jaxme unknown to *this* workspace -INFO- Failed to extract fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-soap/rss.xml - Atom: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-soap/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2005012007, vmgump.apache.org:vmgump-public:2005012007 Gump E-mail Identifier (unique within run) #33. -- 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-jelly-tags-jaxme (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-jaxme has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 28 runs. The current state of this project is 'Failed', with reason 'Configuration Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-jaxme : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-jaxme-05012007.jar] identifier set to project name -ERROR- No such project [ws-jaxme] for property. -ERROR- No such project [ws-jaxme] for property. -ERROR- No such project [ws-jaxme] for property. -ERROR- No such project [ws-jaxme] for property. -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-js on: Maven on Project:commons-jelly-tags-jaxme -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme on: Maven on Project:commons-jelly-tags-jaxme -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-api on: Maven on Project:commons-jelly-tags-jaxme -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-xs on: Maven on Project:commons-jelly-tags-jaxme -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: ws-jaxme unknown to *this* workspace -INFO- Failed to extract fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/rss.xml - Atom: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2005012007, vmgump.apache.org:vmgump-public:2005012007 Gump E-mail Identifier (unique within run) #41. -- 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-jelly-tags-jaxme (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-jaxme has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 28 runs. The current state of this project is 'Failed', with reason 'Configuration Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-jaxme : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-jaxme-05012007.jar] identifier set to project name -ERROR- No such project [ws-jaxme] for property. -ERROR- No such project [ws-jaxme] for property. -ERROR- No such project [ws-jaxme] for property. -ERROR- No such project [ws-jaxme] for property. -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-js on: Maven on Project:commons-jelly-tags-jaxme -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme on: Maven on Project:commons-jelly-tags-jaxme -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-api on: Maven on Project:commons-jelly-tags-jaxme -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-xs on: Maven on Project:commons-jelly-tags-jaxme -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: ws-jaxme unknown to *this* workspace -INFO- Failed to extract fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/rss.xml - Atom: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2005012007, vmgump.apache.org:vmgump-public:2005012007 Gump E-mail Identifier (unique within run) #41. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-312) DateFormatUtils.format with Timezone parameter CET produces wrong date in summer time 1945 to 1949
[
https://issues.apache.org/jira/browse/LANG-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462483
]
Hayo commented on LANG-312:
---
Thanks for your answer, Henri!
You are right, it is not really a bug in the DateFormatUtils. It was a lack in
understanding the Timezone concept by me and a probably misconception of
java.sql.Date by Sun. I have a proposal at the end, to avoid falling in this
trap.
TimeZone.getDefault().getID() and System.getProperty( user.timezone ) are
Europe/Berlin on all systems we use. Timezone parameter we used for
DateFormatUtils.format is CET. The summer times from 1945 to 1949 obviously
is where CET and Europe/Berlin differ.
Example:
Calendar cal = GregorianCalendar.getInstance(TimeZone.getTimeZone(CET),
Locale.GERMANY);
cal.set(1947, 7, 2);
Now cal.getTimeInMillis(); is not equal (new java.sql.Date(47, 7
,2).getTime()); for default Europe/Berlin
If the Java vm is started with parameter -Duser.timezone=Europe/Berlin,
everybody should be able to reproduce the effect with my code above. (We now
set -Duser.timezone=CET to avoid it in existing deployment).
I admit that with java.util.Date the issue is simply our fault. But, in my
opinion with java.sql.Date the function should be improved. Our buggy real life
code uses java.sql.Date that is returned from the JDBC 2.0 driver for DB2 in a
ResultSet, which is a very common thing to do.
From the documentation of java.sql.Date.
public Date(long date)
Constructs a Date object using the given milliseconds time value. If the given
milliseconds value contains time information, the driver will set the time
components to the time in the default time zone (the time zone of the Java
virtual machine running the application) that corresponds to zero GMT.
So the local time of a java.sql.Date is always 00:00:00.
My proposal for format () is:
if (date instanceof java.sql.Date) {
Calendar cal = GregorianCalendar.getInstance(timeZone, locale);
cal.set(1900 + date.getYear(), date.getMonth(), date.getDate());
} else {
// construct Calendar as already implemented
}
Then there is no way to get the wrong sql date any more. I currently do not see
any drawbacks of this solution.
Regards,
Hayo
DateFormatUtils.format with Timezone parameter CET produces wrong date in
summer time 1945 to 1949
Key: LANG-312
URL: https://issues.apache.org/jira/browse/LANG-312
Project: Commons Lang
Issue Type: Bug
Affects Versions: 2.1, 2.2
Environment: IBM Java 1.4.2, Sun Java 1.4.2, Windows XP, SuSE Linux
Enterprise 9, German systems, at winter time
Reporter: Hayo
DateFormatUtils.format(dt, dd/MM/, Timezone.getTimezone(CET),
Locale.GERMANY); returns the date of the day before during summer time of the
years 1945 to 1949. The problem was detected on a system running in
Locale.GERMANY, current time CET, JDK 1.4.2.
The problem does not occur with the call DateFormatUtils.format(dt,
dd/MM/); which presumably uses the system defaults. These are likely to
be the same as the parameters i have passed.
The following code snippet demonstrates the problem:
for (int year = 0; year 150; year ++) {
for (int month = 0; month = 11; month ++) {
for (int day = 1; day = 28; day ++) {
java.sql.Date dt = new java.sql.Date(year, month, day);
// or java.util.Date
String def = DateFormatUtils.format(dt, dd/MM/);
String cet = DateFormatUtils.format(dt, dd/MM/,
Timezone.getTimezone(CET), Locale.GERMANY);
if (!cet.equals(def)) {
System.err.println(dt.toLocaleString() + Default:
+ def + CET: + cet);
}
}
}
}
Output:
--
03.04.1945 00:00:00 Default: 03/04/1945 CET:02/04/1945
[...]
18.11.1945 00:00:00 Default: 18/11/1945 CET:17/11/1945
15.04.1946 00:00:00 Default: 15/04/1946 CET:14/04/1946
[...]
07.10.1946 00:00:00 Default: 07/10/1946 CET:06/10/1946
07.04.1947 00:00:00 Default: 07/04/1947 CET:06/04/1947
[...]
05.10.1947 00:00:00 Default: 05/10/1947 CET:04/10/1947
19.04.1948 00:00:00 Default: 19/04/1948 CET:18/04/1948
[...]
03.10.1948 00:00:00 Default: 03/10/1948 CET:02/10/1948
11.04.1949 00:00:00 Default: 11/04/1949 CET:10/04/1949
[...]
02.10.1949 00:00:00 Default: 02/10/1949 CET:01/10/1949
This seems to be during the summer time of 1949 to 1945 in Berlin, and only
in Berlin. Setting the Locale to any other value has no effect on that. So i
ask myself, what results other central european users get. Setting the
Timezone to GMT+2 extracts exactly the high summer
[jira] Updated: (LANG-312) DateFormatUtils.format with Timezone parameter CET produces wrong date in summer time 1945 to 1949
[
https://issues.apache.org/jira/browse/LANG-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hayo updated LANG-312:
--
Issue Type: Improvement (was: Bug)
DateFormatUtils.format with Timezone parameter CET produces wrong date in
summer time 1945 to 1949
Key: LANG-312
URL: https://issues.apache.org/jira/browse/LANG-312
Project: Commons Lang
Issue Type: Improvement
Affects Versions: 2.1, 2.2
Environment: IBM Java 1.4.2, Sun Java 1.4.2, Windows XP, SuSE Linux
Enterprise 9, German systems, at winter time
Reporter: Hayo
DateFormatUtils.format(dt, dd/MM/, Timezone.getTimezone(CET),
Locale.GERMANY); returns the date of the day before during summer time of the
years 1945 to 1949. The problem was detected on a system running in
Locale.GERMANY, current time CET, JDK 1.4.2.
The problem does not occur with the call DateFormatUtils.format(dt,
dd/MM/); which presumably uses the system defaults. These are likely to
be the same as the parameters i have passed.
The following code snippet demonstrates the problem:
for (int year = 0; year 150; year ++) {
for (int month = 0; month = 11; month ++) {
for (int day = 1; day = 28; day ++) {
java.sql.Date dt = new java.sql.Date(year, month, day);
// or java.util.Date
String def = DateFormatUtils.format(dt, dd/MM/);
String cet = DateFormatUtils.format(dt, dd/MM/,
Timezone.getTimezone(CET), Locale.GERMANY);
if (!cet.equals(def)) {
System.err.println(dt.toLocaleString() + Default:
+ def + CET: + cet);
}
}
}
}
Output:
--
03.04.1945 00:00:00 Default: 03/04/1945 CET:02/04/1945
[...]
18.11.1945 00:00:00 Default: 18/11/1945 CET:17/11/1945
15.04.1946 00:00:00 Default: 15/04/1946 CET:14/04/1946
[...]
07.10.1946 00:00:00 Default: 07/10/1946 CET:06/10/1946
07.04.1947 00:00:00 Default: 07/04/1947 CET:06/04/1947
[...]
05.10.1947 00:00:00 Default: 05/10/1947 CET:04/10/1947
19.04.1948 00:00:00 Default: 19/04/1948 CET:18/04/1948
[...]
03.10.1948 00:00:00 Default: 03/10/1948 CET:02/10/1948
11.04.1949 00:00:00 Default: 11/04/1949 CET:10/04/1949
[...]
02.10.1949 00:00:00 Default: 02/10/1949 CET:01/10/1949
This seems to be during the summer time of 1949 to 1945 in Berlin, and only
in Berlin. Setting the Locale to any other value has no effect on that. So i
ask myself, what results other central european users get. Setting the
Timezone to GMT+2 extracts exactly the high summer times in 1945 and 1947
(MEHSZ). (See below for list of summer times).
I could guess that some calendar calculations work with different libraries
that have different summer time maps (java.util.Date vs. Calendar). This
might depend on my environment, so this task should be tested by others (with
their local Timezone).
The API documentation does not clearly state what effect the Timezone/Locale
parameters should have.
In my strong opinion at least dates passed as java.sql.Date should not be
normalized to summer/standard time. A date is a date! For java.util.Date the
date recalculation behaviour should be mentioned in the docs, if it is really
intended this way by design.
===
These where the actual summer times in Germany
(http://www.ptb.de/de/org/4/44/441/salt.htm
http://de.wikipedia.org/wiki/Hochsommerzeit#Mitteleurop.C3.A4ische_Sommerzeit)
a) Summer time, Advance to CET (GMT+1): 1 hour (GMT+2)
1916-04-30 23:00:00 CET until 1916-10-01 1:00:00 CEST
1917-04-162:00:00 CET until 1917-09-17 3:00:00 CEST
1918-04-152:00:00 CET until 1918-09-16 3:00:00 CEST
1919 until 1939: No Summer time
1940-04-012:00:00 CET until 1942-11-02 3:00:00 CEST
1943-03-292:00:00 CET until 1943-10-04 3:00:00 CEST
1944-04-032:00:00 CET until 1944-10-02 3:00:00 CEST
1945-04-022:00:00 CET until 1945-09-16 2:00:00 CEST
Special: Berlin and sowjet occupied zone:
(1945-05-24) 2:00:00 CET until 1945-11-18 3:00:00 CEST
(1945-05-24) 3:00:00 CET until 1945-09-24 2:00:00 MEHSZ
1946-04-142:00:00 CET until 1946-10-07 3:00:00 CEST
1947-04-063:00:00 CET until 1947-10-05 3:00:00 CEST
1948-04-182:00:00 CET until 1948-10-03 3:00:00 CEST
1949-04-102:00:00 CET until 1949-10-02 3:00:00 CEST
b) High summer time, Advance to CET: 2 hours (GMT+3)
1947-05-113:00:00 CEST until
[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 2 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. -WARNING- Overriding Maven properties: [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties] -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: 15 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-05012007.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-05012007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-05012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-05012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-05012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-05012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-05012007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-05012007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-05012007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-05012007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-05012007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar - [junit] at org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:64) [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:59) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:263) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:66) [junit] at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:113) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:161) [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
[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 2 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. -WARNING- Overriding Maven properties: [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties] -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: 15 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-05012007.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-05012007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-05012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-05012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-05012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-05012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-05012007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-05012007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-05012007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-05012007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-05012007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar - [junit] at org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:64) [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:59) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:263) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:66) [junit] at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:113) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:161) [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
[EMAIL PROTECTED]: Project commons-jelly-tags-fmt-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-fmt-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 2 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-fmt-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -WARNING- Overriding Maven properties: [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/gump_work/build_commons-jelly_commons-jelly-tags-fmt-test.html Work Name: build_commons-jelly_commons-jelly-tags-fmt-test (Type: Build) Work ended in a state of : Failed Elapsed: 13 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt] 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/packages/bsh-2.0b4/bsh-commands-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-classpath-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-core-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-bsf-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-reflect-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-util-2.0b4.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-05012007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-05012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-05012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/beanshell/target/commons-jelly-tags-beanshell-05012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-05012007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-05012007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-05012007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-05012007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-05012007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/commons-jelly-tags-fmt-05012007.jar - [junit] at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) [junit] at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) [junit] at java.net.URLClassLoader.access$100(URLClassLoader.java:56) [junit] at java.net.URLClassLoader$1.run(URLClassLoader.java:195) [junit] at java.security.AccessController.doPrivileged(Native Method) [junit] at java.net.URLClassLoader.findClass(URLClassLoader.java:188) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:306) [junit] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:251) [junit] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) [junit] at org.apache.commons.jelly.tags.ant.AntTagLibrary.createProject(AntTagLibrary.java:128)
[EMAIL PROTECTED]: Project commons-jelly-tags-fmt-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-fmt-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 2 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-fmt-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -WARNING- Overriding Maven properties: [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/gump_work/build_commons-jelly_commons-jelly-tags-fmt-test.html Work Name: build_commons-jelly_commons-jelly-tags-fmt-test (Type: Build) Work ended in a state of : Failed Elapsed: 13 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt] 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/packages/bsh-2.0b4/bsh-commands-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-classpath-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-core-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-bsf-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-reflect-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-util-2.0b4.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-05012007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-05012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-05012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/beanshell/target/commons-jelly-tags-beanshell-05012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-05012007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-05012007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-05012007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-05012007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-05012007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/commons-jelly-tags-fmt-05012007.jar - [junit] at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) [junit] at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) [junit] at java.net.URLClassLoader.access$100(URLClassLoader.java:56) [junit] at java.net.URLClassLoader$1.run(URLClassLoader.java:195) [junit] at java.security.AccessController.doPrivileged(Native Method) [junit] at java.net.URLClassLoader.findClass(URLClassLoader.java:188) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:306) [junit] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:251) [junit] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) [junit] at org.apache.commons.jelly.tags.ant.AntTagLibrary.createProject(AntTagLibrary.java:128)
Re: [sandbox] Using commons-skin for all components
+1 from me (I can't remember if I'm binding or not). Do you need the individual projects to update their poms or are you going to take care of that? On 1/5/07, Henri Yandell [EMAIL PROTECTED] wrote: +1 here. On 1/4/07, Jörg Schaible [EMAIL PROTECTED] wrote: +1 Dennis Lundberg wrote on Thursday, January 04, 2007 10:34 PM: Hi Before I dive head-first into this I thought I'd ask first. I'd like to unify the M2 generated sites for all sandbox components, by making use of commons-skin. This would mean: - 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] Commented: (JXPATH-71) Ponter.asPath() return values not always correct
[
https://issues.apache.org/jira/browse/JXPATH-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462496
]
Matt Benson commented on JXPATH-71:
---
I think this is a duplicate of JXPATH-71
Ponter.asPath() return values not always correct
Key: JXPATH-71
URL: https://issues.apache.org/jira/browse/JXPATH-71
Project: Commons JXPath
Issue Type: Bug
Affects Versions: 1.2 Final
Environment: WInXP, Java 1.5, Eclipse 3.2
Reporter: John Attwood
String returned by Pointer.asPath() is incorrect when path starts with '//'
and target is a collection. The path returned always has a final subscript
equal to the size of the collection, although Pointer.getValue() still
returns the correct element in each case. Below are two classes and a JUnit
testcase which reproduce the bug and isolate it to the case where the path
starts with '//' and the target is a collection.
I found this problem whilst trying to write the equivalent of XPathExplorer
for my JXPath-based object trees. It does't affect the main app, as
getValue() always returns the correct node, but in my explorer it only ever
highlights the last element in any collection (the objects in my trees aren't
always unique so the path is only way to identify them individually and allow
the matching nodes to be highlighted).
Otherwise an excellent, easy-to-use and really useful package.
/// Parent.java
//
package test;
import java.util.ArrayList;
public class Parent {
private int id;
private ArrayListChild kids;
public Parent(int id) {
this.id = id;
this.kids = new ArrayListChild();
}
public int getId() {
return id;
}
public ArrayListChild getKids() {
return kids;
}
public void addKid(Child kid) {
kids.add(kid);
}
public void setId(int id) {
this.id = id;
}
public void setKids(ArrayListChild kids) {
this.kids = kids;
}
}
/// Child.java
/
package test;
public class Child {
private int id;
public Child(int id) {
this.id = id;
}
public int getId() {
return id;
}
public void setId(int id) {
this.id = id;
}
}
///
TestPointerToPath.java
///
package test;
import java.util.HashSet;
import java.util.Iterator;
import java.util.Set;
import junit.framework.TestCase;
import org.apache.commons.jxpath.JXPathContext;
import org.apache.commons.jxpath.Pointer;
public class TestPonterToPath extends TestCase {
private Parent parent;
private SetString expectedPaths, actualPaths;
private SetObject actualObjects, expectedObjects;
private JXPathContext ctx;
private static final int SIZE = 4;
public void setUp() {
parent = new Parent(1);
for (int i = 1; i = SIZE; i++) {
parent.addKid(new Child(i));
}
expectedPaths = new HashSetString();
expectedObjects = new HashSetObject();
actualPaths = new HashSetString();
actualObjects = new HashSetObject();
ctx = JXPathContext.newContext(parent);
}
private void doExpected(String path1, String path2) {
for (int i = 1; i = SIZE; i++) {
Pointer p = ctx.getPointer(path1 + i + path2);
expectedPaths.add(p.asPath());
expectedObjects.add(p.getValue());
}
assertEquals(SIZE, expectedPaths.size());
assertEquals(SIZE, expectedObjects.size());
}
private void doActual(String path) {
Iterator it = ctx.iteratePointers(path);
while (it.hasNext()) {
Pointer p = (Pointer) it.next();
actualPaths.add(p.asPath());
actualObjects.add(p.getValue());
}
assertEquals(SIZE, actualObjects.size());
}
public void testToPathLeafAbs() {
doExpected(/kids[, ]/id);
doActual(/kids/id);
assertEquals(expectedObjects, actualObjects);
assertEquals(expectedPaths,
[jira] Commented: (JXPATH-71) Ponter.asPath() return values not always correct
[
https://issues.apache.org/jira/browse/JXPATH-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462498
]
Matt Benson commented on JXPATH-71:
---
Grrr, make that JXPATH-5 . Sorry!
Ponter.asPath() return values not always correct
Key: JXPATH-71
URL: https://issues.apache.org/jira/browse/JXPATH-71
Project: Commons JXPath
Issue Type: Bug
Affects Versions: 1.2 Final
Environment: WInXP, Java 1.5, Eclipse 3.2
Reporter: John Attwood
String returned by Pointer.asPath() is incorrect when path starts with '//'
and target is a collection. The path returned always has a final subscript
equal to the size of the collection, although Pointer.getValue() still
returns the correct element in each case. Below are two classes and a JUnit
testcase which reproduce the bug and isolate it to the case where the path
starts with '//' and the target is a collection.
I found this problem whilst trying to write the equivalent of XPathExplorer
for my JXPath-based object trees. It does't affect the main app, as
getValue() always returns the correct node, but in my explorer it only ever
highlights the last element in any collection (the objects in my trees aren't
always unique so the path is only way to identify them individually and allow
the matching nodes to be highlighted).
Otherwise an excellent, easy-to-use and really useful package.
/// Parent.java
//
package test;
import java.util.ArrayList;
public class Parent {
private int id;
private ArrayListChild kids;
public Parent(int id) {
this.id = id;
this.kids = new ArrayListChild();
}
public int getId() {
return id;
}
public ArrayListChild getKids() {
return kids;
}
public void addKid(Child kid) {
kids.add(kid);
}
public void setId(int id) {
this.id = id;
}
public void setKids(ArrayListChild kids) {
this.kids = kids;
}
}
/// Child.java
/
package test;
public class Child {
private int id;
public Child(int id) {
this.id = id;
}
public int getId() {
return id;
}
public void setId(int id) {
this.id = id;
}
}
///
TestPointerToPath.java
///
package test;
import java.util.HashSet;
import java.util.Iterator;
import java.util.Set;
import junit.framework.TestCase;
import org.apache.commons.jxpath.JXPathContext;
import org.apache.commons.jxpath.Pointer;
public class TestPonterToPath extends TestCase {
private Parent parent;
private SetString expectedPaths, actualPaths;
private SetObject actualObjects, expectedObjects;
private JXPathContext ctx;
private static final int SIZE = 4;
public void setUp() {
parent = new Parent(1);
for (int i = 1; i = SIZE; i++) {
parent.addKid(new Child(i));
}
expectedPaths = new HashSetString();
expectedObjects = new HashSetObject();
actualPaths = new HashSetString();
actualObjects = new HashSetObject();
ctx = JXPathContext.newContext(parent);
}
private void doExpected(String path1, String path2) {
for (int i = 1; i = SIZE; i++) {
Pointer p = ctx.getPointer(path1 + i + path2);
expectedPaths.add(p.asPath());
expectedObjects.add(p.getValue());
}
assertEquals(SIZE, expectedPaths.size());
assertEquals(SIZE, expectedObjects.size());
}
private void doActual(String path) {
Iterator it = ctx.iteratePointers(path);
while (it.hasNext()) {
Pointer p = (Pointer) it.next();
actualPaths.add(p.asPath());
actualObjects.add(p.getValue());
}
assertEquals(SIZE, actualObjects.size());
}
public void testToPathLeafAbs() {
doExpected(/kids[, ]/id);
doActual(/kids/id);
assertEquals(expectedObjects, actualObjects);
assertEquals(expectedPaths, actualPaths);
[jira] Commented: (JXPATH-73) ValueUtils should catch IndexOutOfBoundsException instead of ArrayIndexOutOfBoundsException (for XmlBeans support)
[ https://issues.apache.org/jira/browse/JXPATH-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462499 ] Matt Benson commented on JXPATH-73: --- +1, this seems harmless. ValueUtils should catch IndexOutOfBoundsException instead of ArrayIndexOutOfBoundsException (for XmlBeans support) -- Key: JXPATH-73 URL: https://issues.apache.org/jira/browse/JXPATH-73 Project: Commons JXPath Issue Type: Bug Affects Versions: 1.2 Final Environment: XmlBeans with JDK 1.4.2 and JXpath 1.2 Reporter: James Schopp Basically, I want to do createPathAndSetValue on an XmlBean . But, my xpath statement inlcudes a collection (an array, actually), so the missing elements in the array need to be created. JXPath checks for this condition (ie. that array elements are missing and need to be created) by catching an ArrayIndexOutOfBoundsException. Unfortunately, XmlBeans does not throw that type of exception. It throws an IndexOutOfBoundsException exception instead. So, instead of detecting that the array is too small and needs to be grown (by calling my AbstractFactory), it just propogates the exception up the chain. The fix is quite simple: on line 423 of ValueUtils, just change the catch clause to catch a IndexOutOfBoundsException instead. This should not break any existing code since ArrayIndexOutOfBoundsException is actually a subclass of IndexOutOfBoundsException anyway. I made this fix to my local source tree, and everything works perfectly (ie. existing code did not break, but now I can also use JXPath on top of my XmlBeans beans too with my own custom AbstractFactory). Thanks! James -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JXPATH-38) [jxpath] ClassFunctions throws NPE searching for a function in null ns
[
https://issues.apache.org/jira/browse/JXPATH-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Benson updated JXPATH-38:
--
Attachment: jxpath-38.patch.txt
[jxpath] ClassFunctions throws NPE searching for a function in null ns
--
Key: JXPATH-38
URL: https://issues.apache.org/jira/browse/JXPATH-38
Project: Commons JXPath
Issue Type: Bug
Affects Versions: 1.2 Final
Environment: Operating System: other
Platform: Other
Reporter: Matt Benson
Attachments: jxpath-38.patch.txt
First thing in getFunction(...):
if (!namespace.equals(this.namespace)) {
return null;
}
In contrast PackageFunctions has null checks. I think I can work around this
by
always using a namespace, but I can't think of any reason this behavior should
persist into (theoretical) future versions of jxpath.
--
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: (JXPATH-38) [jxpath] ClassFunctions throws NPE searching for a function in null ns
[
https://issues.apache.org/jira/browse/JXPATH-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462505
]
Matt Benson commented on JXPATH-38:
---
patch added. Recommend inclusion for 1.3 .
[jxpath] ClassFunctions throws NPE searching for a function in null ns
--
Key: JXPATH-38
URL: https://issues.apache.org/jira/browse/JXPATH-38
Project: Commons JXPath
Issue Type: Bug
Affects Versions: 1.2 Final
Environment: Operating System: other
Platform: Other
Reporter: Matt Benson
Attachments: jxpath-38.patch.txt
First thing in getFunction(...):
if (!namespace.equals(this.namespace)) {
return null;
}
In contrast PackageFunctions has null checks. I think I can work around this
by
always using a namespace, but I can't think of any reason this behavior should
persist into (theoretical) future versions of jxpath.
--
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: (JXPATH-50) [jxpath] does not properly handle NodeSet returned by extension function
[
https://issues.apache.org/jira/browse/JXPATH-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462512
]
Matt Benson commented on JXPATH-50:
---
RE the use of enum as a variable name, Martin van den Bemt fixed this in SVN
revision 374128.
[jxpath] does not properly handle NodeSet returned by extension function
Key: JXPATH-50
URL: https://issues.apache.org/jira/browse/JXPATH-50
Project: Commons JXPath
Issue Type: Bug
Affects Versions: 1.2 Final
Environment: Operating System: other
Platform: All
Reporter: Keith D Gregory
Attachments: jxpath-nodeset-functions.patch
Per the documentation, my function is returning a BasicNodeSet containing zero
or more pointers:
public static NodeSet observations(ExpressionContext context) {
// the cast below shouldn't break, as this is the only pointer type that
// makes sense in this context
ListNodePointer ptrs = extractObservations(
(NodePointer)context.getContextNodePointer(),
new ArrayListNodePointer());
BasicNodeSet result = new BasicNodeSet();
for (NodePointer ptr : ptrs) {
result.add(ptr);
}
return result;
}
However, if I call JXPathContext.selectNodes(ems:observations()), I'm
getting
a single node containing the BasicNodeSet. I notice that there is a testcase
for
functions that return NodeSets, but that it uses expressions that actually
return the children of the NodeSet (test:nodeSet()/name).
There appear to be two problems. First, Expression.iterate() and
Expression.iteratePointers() do not correctly recognize a NodeSet as something
iterable. I've resolved this by reaching into the NodeSet and getting an
iterator over its pointers.
Second, Expression.PointerIterator doesn't recognize when it already has a
pointer, and instead tries to wrap it in a new pointer. This ends up treating
the pointer as a bean.
I've made these changes, and written a testcase that uses an unadorned NodeSet
function. I also found a class that used a variable named enum, and changed
this so that it would compile under 1.5.
The patch is attached. It's relative to commons-jxpath-1.2 (root of extract
directory).
--
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: [jxpath] 1.3
--- Niall Pemberton [EMAIL PROTECTED] wrote: [SNIP] I've just updated the JXPath maven1 build to bring it up to date with current commons practices (site should be available to see in a couple of hours after the next sync) http://svn.apache.org/viewvc?view=revrevision=492887 Whew! I'm glad I didn't have to do *THAT*. For obvious reasons my Maven-fu is at a level of about 0.5% . ;) Thanks for all your work so far, Niall. I think the next thing to do is review the outstanding JIRA tickets and assign those that need to be resolved to 1.3 or post 1.3 (I've created versions for both these for JXPath) My personal evaluations: Straightforward, easy fixes for 1.3: JXPATH-75 JXPATH-73 JXPATH-38 JXPATH-12 Issues that can probably be resolved by virtue of their already containing solutions in varying degrees of completeness/readiness for integration (I will try to have a look at these): JXPATH-68 JXPATH-50 JXPATH-10 Issues that should be looked at to further determine severity/simplicity to fix (again, I'll try to check into): JXPATH-20 JXPATH-69 JXPATH-71 should be marked as a duplicate of JXPATH-5. JXPATH-74 should be closed as invalid by the submitter's recommendation. Finally, JXPATH-67 should almost certainly be deferred for now. Thanks, Matt Niall __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JXPATH-71) Ponter.asPath() return values not always correct
[
https://issues.apache.org/jira/browse/JXPATH-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton resolved JXPATH-71.
---
Resolution: Duplicate
Ponter.asPath() return values not always correct
Key: JXPATH-71
URL: https://issues.apache.org/jira/browse/JXPATH-71
Project: Commons JXPath
Issue Type: Bug
Affects Versions: 1.2 Final
Environment: WInXP, Java 1.5, Eclipse 3.2
Reporter: John Attwood
String returned by Pointer.asPath() is incorrect when path starts with '//'
and target is a collection. The path returned always has a final subscript
equal to the size of the collection, although Pointer.getValue() still
returns the correct element in each case. Below are two classes and a JUnit
testcase which reproduce the bug and isolate it to the case where the path
starts with '//' and the target is a collection.
I found this problem whilst trying to write the equivalent of XPathExplorer
for my JXPath-based object trees. It does't affect the main app, as
getValue() always returns the correct node, but in my explorer it only ever
highlights the last element in any collection (the objects in my trees aren't
always unique so the path is only way to identify them individually and allow
the matching nodes to be highlighted).
Otherwise an excellent, easy-to-use and really useful package.
/// Parent.java
//
package test;
import java.util.ArrayList;
public class Parent {
private int id;
private ArrayListChild kids;
public Parent(int id) {
this.id = id;
this.kids = new ArrayListChild();
}
public int getId() {
return id;
}
public ArrayListChild getKids() {
return kids;
}
public void addKid(Child kid) {
kids.add(kid);
}
public void setId(int id) {
this.id = id;
}
public void setKids(ArrayListChild kids) {
this.kids = kids;
}
}
/// Child.java
/
package test;
public class Child {
private int id;
public Child(int id) {
this.id = id;
}
public int getId() {
return id;
}
public void setId(int id) {
this.id = id;
}
}
///
TestPointerToPath.java
///
package test;
import java.util.HashSet;
import java.util.Iterator;
import java.util.Set;
import junit.framework.TestCase;
import org.apache.commons.jxpath.JXPathContext;
import org.apache.commons.jxpath.Pointer;
public class TestPonterToPath extends TestCase {
private Parent parent;
private SetString expectedPaths, actualPaths;
private SetObject actualObjects, expectedObjects;
private JXPathContext ctx;
private static final int SIZE = 4;
public void setUp() {
parent = new Parent(1);
for (int i = 1; i = SIZE; i++) {
parent.addKid(new Child(i));
}
expectedPaths = new HashSetString();
expectedObjects = new HashSetObject();
actualPaths = new HashSetString();
actualObjects = new HashSetObject();
ctx = JXPathContext.newContext(parent);
}
private void doExpected(String path1, String path2) {
for (int i = 1; i = SIZE; i++) {
Pointer p = ctx.getPointer(path1 + i + path2);
expectedPaths.add(p.asPath());
expectedObjects.add(p.getValue());
}
assertEquals(SIZE, expectedPaths.size());
assertEquals(SIZE, expectedObjects.size());
}
private void doActual(String path) {
Iterator it = ctx.iteratePointers(path);
while (it.hasNext()) {
Pointer p = (Pointer) it.next();
actualPaths.add(p.asPath());
actualObjects.add(p.getValue());
}
assertEquals(SIZE, actualObjects.size());
}
public void testToPathLeafAbs() {
doExpected(/kids[, ]/id);
doActual(/kids/id);
assertEquals(expectedObjects, actualObjects);
assertEquals(expectedPaths, actualPaths);
}
public void
[jira] Updated: (JXPATH-73) ValueUtils should catch IndexOutOfBoundsException instead of ArrayIndexOutOfBoundsException (for XmlBeans support)
[ https://issues.apache.org/jira/browse/JXPATH-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated JXPATH-73: -- Fix Version/s: 1.3 ValueUtils should catch IndexOutOfBoundsException instead of ArrayIndexOutOfBoundsException (for XmlBeans support) -- Key: JXPATH-73 URL: https://issues.apache.org/jira/browse/JXPATH-73 Project: Commons JXPath Issue Type: Bug Affects Versions: 1.2 Final Environment: XmlBeans with JDK 1.4.2 and JXpath 1.2 Reporter: James Schopp Fix For: 1.3 Basically, I want to do createPathAndSetValue on an XmlBean . But, my xpath statement inlcudes a collection (an array, actually), so the missing elements in the array need to be created. JXPath checks for this condition (ie. that array elements are missing and need to be created) by catching an ArrayIndexOutOfBoundsException. Unfortunately, XmlBeans does not throw that type of exception. It throws an IndexOutOfBoundsException exception instead. So, instead of detecting that the array is too small and needs to be grown (by calling my AbstractFactory), it just propogates the exception up the chain. The fix is quite simple: on line 423 of ValueUtils, just change the catch clause to catch a IndexOutOfBoundsException instead. This should not break any existing code since ArrayIndexOutOfBoundsException is actually a subclass of IndexOutOfBoundsException anyway. I made this fix to my local source tree, and everything works perfectly (ie. existing code did not break, but now I can also use JXPath on top of my XmlBeans beans too with my own custom AbstractFactory). Thanks! James -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JXPATH-75) The dependency for xerces in commons-jxpath-1.2.pom is too old
[ https://issues.apache.org/jira/browse/JXPATH-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated JXPATH-75: -- Fix Version/s: 1.3 The dependency for xerces in commons-jxpath-1.2.pom is too old -- Key: JXPATH-75 URL: https://issues.apache.org/jira/browse/JXPATH-75 Project: Commons JXPath Issue Type: Improvement Affects Versions: 1.2 Final Environment: java version 1.5.0_04 maven2 commons-configuration-1.3 commons-jxpath-1.2 spring-context-2.0.1 Reporter: Dmitry Katsubo Priority: Minor Fix For: 1.3 The following dependency in commons-jxpath-1.2.pom (see http://mirrors.ibiblio.org/pub/mirrors/maven2/commons-jxpath/commons-jxpath/1.2/commons-jxpath-1.2.pom) is out-of-date: dependency groupIdxerces/groupId artifactIdxerces/artifactId version1.2.3/version /dependency The side effect from this dependency is, that some component, that implicitly uses xerces, may fail with this old xerces version. For example, I am using commons-configuration with spring framework which assumes, that XML parser is able to make XSD verification of configuration files, but xerces-1.2.3 is not able to do this. Solutions are: a) remove all dependencies from commons-jxpath.pom, related with xerces (I hope, most of the community uses at least java1.5, or one may include dependency on xerces in his .pom, as in (c) ) b) update version of xerces in commons-jxpath.pom up to 2.4.0 c) include dependency in your .pom, that overrides version of xerces -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JXPATH-38) [jxpath] ClassFunctions throws NPE searching for a function in null ns
[
https://issues.apache.org/jira/browse/JXPATH-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton updated JXPATH-38:
--
Fix Version/s: 1.3
[jxpath] ClassFunctions throws NPE searching for a function in null ns
--
Key: JXPATH-38
URL: https://issues.apache.org/jira/browse/JXPATH-38
Project: Commons JXPath
Issue Type: Bug
Affects Versions: 1.2 Final
Environment: Operating System: other
Platform: Other
Reporter: Matt Benson
Fix For: 1.3
Attachments: jxpath-38.patch.txt
First thing in getFunction(...):
if (!namespace.equals(this.namespace)) {
return null;
}
In contrast PackageFunctions has null checks. I think I can work around this
by
always using a namespace, but I can't think of any reason this behavior should
persist into (theoretical) future versions of jxpath.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JXPATH-12) [jxpath] Descendant or self axis does not work correctly at root node
[ https://issues.apache.org/jira/browse/JXPATH-12?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated JXPATH-12: -- Fix Version/s: 1.3 [jxpath] Descendant or self axis does not work correctly at root node - Key: JXPATH-12 URL: https://issues.apache.org/jira/browse/JXPATH-12 Project: Commons JXPath Issue Type: Bug Affects Versions: 1.2 Final Environment: Operating System: other Platform: Other Reporter: Simon Raess Fix For: 1.3 Attachments: DescendantOrSelfTest.java, patch.jxpath-12.txt Given the following XML document: root id=1234/ and the XPath: //root/@id/text(). JXPath returns null instead of 1234. JXPathContext context = JXPathContext.newContext(doc); assertEquals(value, context.selectSingleNode(//root/@id/text())); The attached JUnit test highlights the problem. It seems that JXPath does not find the root node if it is accessed with the axis descendant-or-self. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JXPATH-68) StackOverflow error on a call to 'JXPathContext.createPath()'
[
https://issues.apache.org/jira/browse/JXPATH-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton updated JXPATH-68:
--
Fix Version/s: 1.3
StackOverflow error on a call to 'JXPathContext.createPath()'
-
Key: JXPATH-68
URL: https://issues.apache.org/jira/browse/JXPATH-68
Project: Commons JXPath
Issue Type: Bug
Affects Versions: Nightly Builds, 1.2 Final
Environment: Windows XP Professional, Sun JDK 1.4.2
Run with JXPath v1.2 and v20060530
Reporter: Joseph Campolongo
Fix For: 1.3
I'm running into a StackOverflow error on a call to
'JXPathContext.createPath()' whenever I have a path that looks like
'a/b[1]/c'. I took a quick look at the code and it appears JXPath, when
trying to create its parent pointer, simply recreates an equivalent
pointer(???).
Here is code to reproduce the problem.
Map map = new HashMap();
map.put(a, null);
JXPathContext pathContext = JXPathContext.newContext(map);
pathContext.setFactory(new AbstractFactory() {
public boolean createObject(
JXPathContext context, Pointer pointer, Object parent, String
name, int index) {
Map parentMap = (Map)parent;
System.out.println(parent + : + name + : + index);
if (index -1) {
List list = (List)parentMap.get(name);
if (list == null) {
list = new ArrayList();
}
int size = list.size();
for (int i = size; i = index; i++) {
list.add(i, null);
}
parentMap.put(name, list);
} else {
parentMap.put(name, new HashMap());
}
return true;
}
});
pathContext.createPath(a/b[1]/c);
***
I have continued looking into this, and found that the problem is that, if
the List is created with a 'null' element, JXPath gets stuck in infinite
recursion.
To discover this, I changed my Factory to implement the following method:
public boolean createObject(
JXPathContext context, Pointer pointer, Object parent,
String name, int index) {
if (pointer instanceof NodePointer) {
index = ((NodePointer)pointer).getIndex();
}
System.out.println(parent + : + name + : + index);
Map parentMap = (Map)parent;
if (index -1) {
List list = (List)parentMap.get(name);
if (list == null) {
list = new ArrayList();
}
int size = list.size();
for (int i = size; i = index; i++) {
list.add(i, new HashMap()); // !! Don't set to 'null'
}
parentMap.put(name, list);
} else {
parentMap.put(name, new HashMap());
}
return true;
}
Then I ran the following code:
pathContext.createPath(a/b[1]/c);
pathContext.createPath(a/b[2]/c); // STACK OVERFLOW HERE
Here is the stack trace at the beginning, where
'ValueUtils.expandCollection()' is called. It puts 'null' into the list,
thus causing the stack overflow as we cycle between createPath()
createChild().
Thread [main] (Suspended (breakpoint at line 227 in DynamicPropertyPointer))
DynamicPropertyPointer.createPath(JXPathContext) line: 227
DynamicPropertyPointer(PropertyPointer).createChild(JXPathContext,
QName, int) line: 188
NullElementPointer.createPath(JXPathContext) line: 82
NullPointer.createPath(JXPathContext) line: 86
NullPropertyPointer.createPath(JXPathContext) line: 103
NullPointer.createPath(JXPathContext) line: 86
NullPropertyPointer.createPath(JXPathContext) line: 103
JXPathContextReferenceImpl.createPath(String, Expression) line: 447
JXPathContextReferenceImpl.createPath(String) line: 427
Test.test4() line: 75
Test.main(String[]) line: 38
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JXPATH-50) [jxpath] does not properly handle NodeSet returned by extension function
[
https://issues.apache.org/jira/browse/JXPATH-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton updated JXPATH-50:
--
Fix Version/s: 1.3
[jxpath] does not properly handle NodeSet returned by extension function
Key: JXPATH-50
URL: https://issues.apache.org/jira/browse/JXPATH-50
Project: Commons JXPath
Issue Type: Bug
Affects Versions: 1.2 Final
Environment: Operating System: other
Platform: All
Reporter: Keith D Gregory
Fix For: 1.3
Attachments: jxpath-nodeset-functions.patch
Per the documentation, my function is returning a BasicNodeSet containing zero
or more pointers:
public static NodeSet observations(ExpressionContext context) {
// the cast below shouldn't break, as this is the only pointer type that
// makes sense in this context
ListNodePointer ptrs = extractObservations(
(NodePointer)context.getContextNodePointer(),
new ArrayListNodePointer());
BasicNodeSet result = new BasicNodeSet();
for (NodePointer ptr : ptrs) {
result.add(ptr);
}
return result;
}
However, if I call JXPathContext.selectNodes(ems:observations()), I'm
getting
a single node containing the BasicNodeSet. I notice that there is a testcase
for
functions that return NodeSets, but that it uses expressions that actually
return the children of the NodeSet (test:nodeSet()/name).
There appear to be two problems. First, Expression.iterate() and
Expression.iteratePointers() do not correctly recognize a NodeSet as something
iterable. I've resolved this by reaching into the NodeSet and getting an
iterator over its pointers.
Second, Expression.PointerIterator doesn't recognize when it already has a
pointer, and instead tries to wrap it in a new pointer. This ends up treating
the pointer as a bean.
I've made these changes, and written a testcase that uses an unadorned NodeSet
function. I also found a class that used a variable named enum, and changed
this so that it would compile under 1.5.
The patch is attached. It's relative to commons-jxpath-1.2 (root of extract
directory).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JXPATH-10) [jxpath] JXPath 1.1 code using custom functions failing when run in 1.2 onwards
[
https://issues.apache.org/jira/browse/JXPATH-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton updated JXPATH-10:
--
Fix Version/s: 1.3
Priority: Blocker
Description:
We have recently attempted to upgrade from a 1.1 release of jxpath
to 1.2 and found a great deal of our jxpath code fails to run correctly.
We isolated the problem to relating to the use of Custom Extension
Functions and have included sample junit test case snippets that should
demonstrate the issue clearly.
The background on what we are trying to do with jxpath is as follows
(included so its clear on what we are trying to use jxpath to achieve):
Within our project, we make extensive use of Custom Extension Functions in
JXPath.
We also use JXPath variables significantly, in combination with these
functions,
that often take a JXPath variable as an argument(s) to the function.
We now rely heavily on the use of the ExpressionContext interface as the first
argument to many of our functions. The reason for this is that we need a
convienient way to obtain access to 'original' object references within the
context invoked by the function (as you would expect).
However, we have also begun using a very useful combination of features, which
the API supports in version 1.1, where the first argument always defines the
ExpressionContext interface (which isn't really part of the method signature -
from a caller perspective), and a 2nd argument as 'Object' type. Within body of
the function, we then cast the object of the 2nd argument as a NodeSet (or
define the NodeSet type within the method signature - either appears to work),
which provides us with access to the pointers for the object.
As previously mentioned, a jxpath variable is passed from the caller of the
function (received via the 2nd argument in the method signature), which is
automatically resolved, by jxpath, to the object itself.
The benefit of casting the object to NodeSet (interface) enables us to retrieve
the first pointer in the NodeSet list. The first pointer concerns us, as it
refers to the String value passed to the argument of the function which we need
access to. The object reference itself is of little concern in this case, as
once we have access to the variable name sent to the function, we can access the
object via the ExpressionContext.
This all works fine in jxpath 1.1, however, in version 1.2 this functionality is
now broken, since our objects are no longer being cast to NodeSet (previously
achieved via the internal implementation of jxpath NodeSet using a SimpleNodeSet
- as per inspecting jxpath 1.1 source code).
Note on the use of ExpressionContext: For those methods that declare the
ExpressionContext interface (which must be the first argument, if used), as part
of the argument list, the method signature from the caller perspective, excludes
it from the argument list, as it is implied by jxpath. In other words, there
will be one less argument from the caller when the interface is used. In the
case where this interface was the only argument, which is common, then the
caller would be invoking a zero-argument method. This is behaviour we expect.
Here is a simplified example of one of our functions using the techniques
discussed:-
public static void deleteSomeObject(ExpressionContext expContext, Object obj) {
// create a local jxpath context to retrieve values for jxpath variables
JXPathContext localContext = expContext.getJXPathContext();
// Nodeset of the object passed to method
NodeSet nodeset = (NodeSet)obj;
// Retrieve variable name passed to function
String declaredVariable = nodeset.getPointers().get(0).toString();
Object objectToDelete = null;
// If this method was passed the $obj1 var to delete, then retrieve 'Object Type
1' via $obj1 variable
if (declaredVariable.equals($obj1)) {
objectToDelete = (ObjectType1)localContext.getValue($obj1);
}
// If this method was passed the $obj2 var to delete, then retrieve
'Object
Type 2' via $obj2 variable
if (declaredVariable.equals($obj2)) {
objectToDelete = (ObjectType2)localContext.getValue($obj2);
}
collectionOfSomeObjects.delete(objectToDelete);
}
Which would be used (called) in the following way:-
...
// add to collection
ObjectType1 objectType1 = new ObjectType1();
ObjectType2 objectType2 = new ObjectType2();
CollectionOfSomeObjects.add(objectType1);
CollectionOfSomeObjects.add(objectType2);
// add collection to jxpath context
JXPathContext context = JXPathContext.newContext(collectionOfSomeObjects);
// define jxpath variables
context.getVariables().declareVariable(obj1, objectType1);
context.getVariables().declareVariable(obj2, objectType2);
// call jxpath Custom Extension Function
String method2Invoke;
method2Invoke = ftn:deleteSomeObject($obj1)
[jira] Resolved: (JXPATH-74) Exception trying to set value with xpath vendor/[EMAIL PROTECTED] = '100']
[ https://issues.apache.org/jira/browse/JXPATH-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved JXPATH-74. --- Resolution: Invalid Thansk for posting back, closing as INVALID Exception trying to set value with xpath vendor/[EMAIL PROTECTED] = '100'] - Key: JXPATH-74 URL: https://issues.apache.org/jira/browse/JXPATH-74 Project: Commons JXPath Issue Type: Test Affects Versions: 1.2 Final Environment: Mac OS X 10.4 plus the following packages installed (for dependencies): i commons-beanutils 1.7.0-4Jakarta Commons - BeanUtils i commons-collections 3.2-3 Jakarta Commons - Collections i commons-logging 1.1-1 Jakarta Commons - Logging i jdom1:1.0-1 Alternative DOM processing API for java i xerces-j2.8.0-1XML parser in Java Reporter: Benjamin Reed the junit tests fail on one of the jdom tests: [junit] Testcase: testGetNode took 1.287 sec [junit] Testcase: testID took 0.071 sec [junit] Testcase: testDocumentOrder took 0.121 sec [junit] Testcase: testSetValue took 0.083 sec [junit] Caused an ERROR [junit] Exception trying to set value with xpath vendor/[EMAIL PROTECTED] = '100']; org.jdom.Element.addContent(Lorg/jdom/Text;)Lorg/jdom/Element; [junit] org.apache.commons.jxpath.JXPathException: Exception trying to set value with xpath vendor/[EMAIL PROTECTED] = '100']; org.jdom.Element.addContent(Lorg/jdom/Text;)Lorg/jdom/Element; [junit] at org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.setValue(JXPathContextReferenceImpl.java:421) [junit] at org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.setValue(JXPathContextReferenceImpl.java:412) [junit] at org.apache.commons.jxpath.JXPathTestCase.assertXPathSetValue(JXPathTestCase.java:83) [junit] at org.apache.commons.jxpath.JXPathTestCase.assertXPathSetValue(JXPathTestCase.java:77) [junit] at org.apache.commons.jxpath.ri.model.XMLModelTestCase.testSetValue(XMLModelTestCase.java:129) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JXPATH-67) [jxpath] Support for XPath 2.0
[ https://issues.apache.org/jira/browse/JXPATH-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated JXPATH-67: -- Fix Version/s: post-1.3 [jxpath] Support for XPath 2.0 -- Key: JXPATH-67 URL: https://issues.apache.org/jira/browse/JXPATH-67 Project: Commons JXPath Issue Type: Improvement Environment: Operating System: other Platform: All Reporter: Chris White Priority: Minor Fix For: post-1.3 Are there any plans to add XPath 2.0 support to JXPath? -- 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: (JXPATH-73) ValueUtils should catch IndexOutOfBoundsException instead of ArrayIndexOutOfBoundsException (for XmlBeans support)
[ https://issues.apache.org/jira/browse/JXPATH-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462519 ] Matt Benson commented on JXPATH-73: --- Actually, it's not a catch; it's an instanceof check. Will attach a proper patch against svn HEAD shortly. ValueUtils should catch IndexOutOfBoundsException instead of ArrayIndexOutOfBoundsException (for XmlBeans support) -- Key: JXPATH-73 URL: https://issues.apache.org/jira/browse/JXPATH-73 Project: Commons JXPath Issue Type: Bug Affects Versions: 1.2 Final Environment: XmlBeans with JDK 1.4.2 and JXpath 1.2 Reporter: James Schopp Fix For: 1.3 Basically, I want to do createPathAndSetValue on an XmlBean . But, my xpath statement inlcudes a collection (an array, actually), so the missing elements in the array need to be created. JXPath checks for this condition (ie. that array elements are missing and need to be created) by catching an ArrayIndexOutOfBoundsException. Unfortunately, XmlBeans does not throw that type of exception. It throws an IndexOutOfBoundsException exception instead. So, instead of detecting that the array is too small and needs to be grown (by calling my AbstractFactory), it just propogates the exception up the chain. The fix is quite simple: on line 423 of ValueUtils, just change the catch clause to catch a IndexOutOfBoundsException instead. This should not break any existing code since ArrayIndexOutOfBoundsException is actually a subclass of IndexOutOfBoundsException anyway. I made this fix to my local source tree, and everything works perfectly (ie. existing code did not break, but now I can also use JXPath on top of my XmlBeans beans too with my own custom AbstractFactory). Thanks! James -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JXPATH-73) ValueUtils should catch IndexOutOfBoundsException instead of ArrayIndexOutOfBoundsException (for XmlBeans support)
[ https://issues.apache.org/jira/browse/JXPATH-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson updated JXPATH-73: -- Attachment: jxpath-73.patch.txt ValueUtils should catch IndexOutOfBoundsException instead of ArrayIndexOutOfBoundsException (for XmlBeans support) -- Key: JXPATH-73 URL: https://issues.apache.org/jira/browse/JXPATH-73 Project: Commons JXPath Issue Type: Bug Affects Versions: 1.2 Final Environment: XmlBeans with JDK 1.4.2 and JXpath 1.2 Reporter: James Schopp Fix For: 1.3 Attachments: jxpath-73.patch.txt Basically, I want to do createPathAndSetValue on an XmlBean . But, my xpath statement inlcudes a collection (an array, actually), so the missing elements in the array need to be created. JXPath checks for this condition (ie. that array elements are missing and need to be created) by catching an ArrayIndexOutOfBoundsException. Unfortunately, XmlBeans does not throw that type of exception. It throws an IndexOutOfBoundsException exception instead. So, instead of detecting that the array is too small and needs to be grown (by calling my AbstractFactory), it just propogates the exception up the chain. The fix is quite simple: on line 423 of ValueUtils, just change the catch clause to catch a IndexOutOfBoundsException instead. This should not break any existing code since ArrayIndexOutOfBoundsException is actually a subclass of IndexOutOfBoundsException anyway. I made this fix to my local source tree, and everything works perfectly (ie. existing code did not break, but now I can also use JXPath on top of my XmlBeans beans too with my own custom AbstractFactory). Thanks! James -- 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: [jxpath] 1.3
Niall, thanks again for your continued attention. I am still looking, as you can probably tell, and I see that I need to revise my evaluations below. JXPATH-68 belongs in the third group (needs patch) rather than the second (evaluate patch). br, Matt --- Matt Benson [EMAIL PROTECTED] wrote: --- Niall Pemberton [EMAIL PROTECTED] wrote: [SNIP] I've just updated the JXPath maven1 build to bring it up to date with current commons practices (site should be available to see in a couple of hours after the next sync) http://svn.apache.org/viewvc?view=revrevision=492887 Whew! I'm glad I didn't have to do *THAT*. For obvious reasons my Maven-fu is at a level of about 0.5% . ;) Thanks for all your work so far, Niall. I think the next thing to do is review the outstanding JIRA tickets and assign those that need to be resolved to 1.3 or post 1.3 (I've created versions for both these for JXPath) My personal evaluations: Straightforward, easy fixes for 1.3: JXPATH-75 JXPATH-73 JXPATH-38 JXPATH-12 Issues that can probably be resolved by virtue of their already containing solutions in varying degrees of completeness/readiness for integration (I will try to have a look at these): JXPATH-68 JXPATH-50 JXPATH-10 Issues that should be looked at to further determine severity/simplicity to fix (again, I'll try to check into): JXPATH-20 JXPATH-69 JXPATH-71 should be marked as a duplicate of JXPATH-5. JXPATH-74 should be closed as invalid by the submitter's recommendation. Finally, JXPATH-67 should almost certainly be deferred for now. Thanks, Matt Niall __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Add Matt Benson as a Jakarta committer
As you can see on the list, Matt would like to help out with JXPath. Matt's been an Ant committer since Feb 2004. He's been active on the dev/user lists over the last couple of years, so not a new face here either. [ ] +1 [ ] -1 Will end the vote on Tuesday morning. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jxpath] 1.3
On 1/5/07, Matt Benson [EMAIL PROTECTED] wrote: --- Niall Pemberton [EMAIL PROTECTED] wrote: [SNIP] I've just updated the JXPath maven1 build to bring it up to date with current commons practices (site should be available to see in a couple of hours after the next sync) http://svn.apache.org/viewvc?view=revrevision=492887 Whew! I'm glad I didn't have to do *THAT*. For obvious reasons my Maven-fu is at a level of about 0.5% . ;) Thanks for all your work so far, Niall. I think the next thing to do is review the outstanding JIRA tickets and assign those that need to be resolved to 1.3 or post 1.3 (I've created versions for both these for JXPath) My personal evaluations: Straightforward, easy fixes for 1.3: JXPATH-75 JXPATH-73 JXPATH-38 JXPATH-12 Issues that can probably be resolved by virtue of their already containing solutions in varying degrees of completeness/readiness for integration (I will try to have a look at these): JXPATH-68 JXPATH-50 JXPATH-10 Issues that should be looked at to further determine severity/simplicity to fix (again, I'll try to check into): JXPATH-20 JXPATH-69 JXPATH-71 should be marked as a duplicate of JXPATH-5. JXPATH-74 should be closed as invalid by the submitter's recommendation. Finally, JXPATH-67 should almost certainly be deferred for now. Good stuff - I've updated Jira with your initial review - which provides a plan of action - 8 issues to sort out, 3 to decide about and 1 for the future: http://issues.apache.org/jira/browse/JXPATH The other task to sort out is release notes of changes since the last release in August 2004! I uploaded a changes reports shows all commits since the last release and where the commits referenced a Bugzilla Id - I updated the Jira ticket to add 1.3 as the fix version. So Jira can give us the starting point for the release notes - except for a number of commits which didn't have an issue# http://jakarta.apache.org/commons/jxpath/changelog-report.html http://svn.apache.org/viewvc?view=revrevision=136928 http://svn.apache.org/viewvc?view=revrevision=136929 http://svn.apache.org/viewvc?view=revrevision=151301 http://svn.apache.org/viewvc?view=revrevision=156189 http://svn.apache.org/viewvc?view=revrevision=157432 http://svn.apache.org/viewvc?view=revrevision=158012 (related to r157432) http://svn.apache.org/viewvc?view=revrevision=158013 (related to r157432) http://svn.apache.org/viewvc?view=revrevision=158299 http://svn.apache.org/viewvc?view=revrevision=329481 http://svn.apache.org/viewvc?view=revrevision=329482 (related to r329481) http://svn.apache.org/viewvc?view=revrevision=329488 http://svn.apache.org/viewvc?view=revrevision=329513 http://svn.apache.org/viewvc?view=revrevision=387363 I think the first place to start is to try and see if any of the above match with existing closed tickets - I'll have a look at that. Niall P.S. I'm happy to help with getting build/site stuff fixed and the mechanics of getting a release out - but I don't know I'll actually find time to fix bugs - hopefully we'll get you doing that :-) Thanks, Matt Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JXPATH-50) [jxpath] does not properly handle NodeSet returned by extension function
[
https://issues.apache.org/jira/browse/JXPATH-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462525
]
Matt Benson commented on JXPATH-50:
---
my kingdom for a unified diff... nevertheless, I will persevere. :(
[jxpath] does not properly handle NodeSet returned by extension function
Key: JXPATH-50
URL: https://issues.apache.org/jira/browse/JXPATH-50
Project: Commons JXPath
Issue Type: Bug
Affects Versions: 1.2 Final
Environment: Operating System: other
Platform: All
Reporter: Keith D Gregory
Fix For: 1.3
Attachments: jxpath-nodeset-functions.patch
Per the documentation, my function is returning a BasicNodeSet containing zero
or more pointers:
public static NodeSet observations(ExpressionContext context) {
// the cast below shouldn't break, as this is the only pointer type that
// makes sense in this context
ListNodePointer ptrs = extractObservations(
(NodePointer)context.getContextNodePointer(),
new ArrayListNodePointer());
BasicNodeSet result = new BasicNodeSet();
for (NodePointer ptr : ptrs) {
result.add(ptr);
}
return result;
}
However, if I call JXPathContext.selectNodes(ems:observations()), I'm
getting
a single node containing the BasicNodeSet. I notice that there is a testcase
for
functions that return NodeSets, but that it uses expressions that actually
return the children of the NodeSet (test:nodeSet()/name).
There appear to be two problems. First, Expression.iterate() and
Expression.iteratePointers() do not correctly recognize a NodeSet as something
iterable. I've resolved this by reaching into the NodeSet and getting an
iterator over its pointers.
Second, Expression.PointerIterator doesn't recognize when it already has a
pointer, and instead tries to wrap it in a new pointer. This ends up treating
the pointer as a bean.
I've made these changes, and written a testcase that uses an unadorned NodeSet
function. I also found a class that used a variable named enum, and changed
this so that it would compile under 1.5.
The patch is attached. It's relative to commons-jxpath-1.2 (root of extract
directory).
--
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] Add Matt Benson as a Jakarta committer
+1 Niall On 1/5/07, Henri Yandell [EMAIL PROTECTED] wrote: As you can see on the list, Matt would like to help out with JXPath. Matt's been an Ant committer since Feb 2004. He's been active on the dev/user lists over the last couple of years, so not a new face here either. [ ] +1 [ ] -1 Will end the vote on Tuesday morning. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Add Matt Benson as a Jakarta committer
+1 Oliver Henri Yandell wrote: As you can see on the list, Matt would like to help out with JXPath. Matt's been an Ant committer since Feb 2004. He's been active on the dev/user lists over the last couple of years, so not a new face here either. [ ] +1 [ ] -1 Will end the vote on Tuesday morning. Hen - 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: [jxpath] 1.3
On 1/4/07, Matt Benson [EMAIL PROTECTED] wrote: Hi, for those of you who haven't encountered me lurking on commons-dev for the past year or two, I'm a member of the Ant PMC and a commons user. I'm also a committer to commons-openpgp in the sandbox but haven't done much there (yet?). :( Finally, I suffered a burst of commons-collections contributions last summer or sometime thereabouts. Now that I've (hopefully sufficiently) introduced myself, I'll get to the point: I see that there is some user demand for a new release of jxpath; indeed I am a user who would also benefit from a release, always preferable to explaining to your peers why you insist on using nightlies... ;) I'd like to offer to help with whatever tasks are necessary to push jxpath to a 1.3 release. I think Dmitri still lurks here but best I can tell he's got other things to do. Plus I suppose you eventually don't really feel like continuing to look at the same old code, impressive though the jxpath code is... Can somebody (Henri?) offer advice on what I and/or other members of the (user and/or Apache committer) community might do to get the ball rolling? My general spiel is that someone who isn't a committer to a project can heavily influence a release - and then I explain how unit tests and patches to the JIRA, release organization on a wiki and prodding of the mail list can be 90% of the work in getting something out. http://wiki.apache.org/jakarta-taglibs/Standard_1%2e1%2e3 is an example - bit of a limited one as I'm a Taglibs committer, but I am taking two roles in it, external user and then later committer closing issues and applying patches. In your case as an existing ASF committer - I'm +1 to your being a Jakarta committer and getting stuck in on getting a jxpath release out. If Ant hadn't have left Jakarta right at the beginning of the TLP migration you'd have been a Jakarta committer anyway. [See vote thread :) ]. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (JXPATH-36) Variable evaluation problem ?
[ https://issues.apache.org/jira/browse/JXPATH-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton reopened JXPATH-36: --- Re-opening - has a status of resolved, but no resolution Variable evaluation problem ? - Key: JXPATH-36 URL: https://issues.apache.org/jira/browse/JXPATH-36 Project: Commons JXPath Issue Type: Bug Affects Versions: 1.0 Beta 1 Environment: Operating System: All Platform: All Reporter: Jérôme Pochat Priority: Critical We get a strange result with variable and/or pointer using. Work well : context.getVariables().declareVariable(v1, Dmitri); Pointer pointer1 = context.getPointer(/employees [firstName=$v1]/lastName); Pointer pointer2 = context.getPointer(/employees[firstName=$v1]); Doesn't seem to work : context.getVariables().declareVariable(v1, Dmitri); Pointer pointer1 = context.getPointer(/employees[firstName=$v1]); Pointer pointer2 = context.getPointer(/employees[firstName=$v1]); Reference pointer1 is a BeanPointer. Reference pointer2 is a NullPointer, so its getValue method return always null. We can obtain only one pointer corresponding to a given expression. This problem appears only with path containing variables. -- 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] Add Matt Benson as a Jakarta committer
+1 - welcome, Matt! Phil
[jira] Resolved: (JXPATH-36) Variable evaluation problem ?
[ https://issues.apache.org/jira/browse/JXPATH-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved JXPATH-36. --- Resolution: Fixed Fix Version/s: 1.0 Final Variable evaluation problem ? - Key: JXPATH-36 URL: https://issues.apache.org/jira/browse/JXPATH-36 Project: Commons JXPath Issue Type: Bug Affects Versions: 1.0 Beta 1 Environment: Operating System: All Platform: All Reporter: Jérôme Pochat Priority: Critical Fix For: 1.0 Final We get a strange result with variable and/or pointer using. Work well : context.getVariables().declareVariable(v1, Dmitri); Pointer pointer1 = context.getPointer(/employees [firstName=$v1]/lastName); Pointer pointer2 = context.getPointer(/employees[firstName=$v1]); Doesn't seem to work : context.getVariables().declareVariable(v1, Dmitri); Pointer pointer1 = context.getPointer(/employees[firstName=$v1]); Pointer pointer2 = context.getPointer(/employees[firstName=$v1]); Reference pointer1 is a BeanPointer. Reference pointer2 is a NullPointer, so its getValue method return always null. We can obtain only one pointer corresponding to a given expression. This problem appears only with path containing variables. -- 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: (JXPATH-50) [jxpath] does not properly handle NodeSet returned by extension function
[
https://issues.apache.org/jira/browse/JXPATH-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462532
]
Keith D Gregory commented on JXPATH-50:
---
Sorry 'bout that :-) I think there were only 1 or 2 files that got changed,
particularly if you delete the enum patch.
Glad to see that JxPath development seems to be moving again.
[jxpath] does not properly handle NodeSet returned by extension function
Key: JXPATH-50
URL: https://issues.apache.org/jira/browse/JXPATH-50
Project: Commons JXPath
Issue Type: Bug
Affects Versions: 1.2 Final
Environment: Operating System: other
Platform: All
Reporter: Keith D Gregory
Fix For: 1.3
Attachments: jxpath-50.patch.txt, jxpath-nodeset-functions.patch
Per the documentation, my function is returning a BasicNodeSet containing zero
or more pointers:
public static NodeSet observations(ExpressionContext context) {
// the cast below shouldn't break, as this is the only pointer type that
// makes sense in this context
ListNodePointer ptrs = extractObservations(
(NodePointer)context.getContextNodePointer(),
new ArrayListNodePointer());
BasicNodeSet result = new BasicNodeSet();
for (NodePointer ptr : ptrs) {
result.add(ptr);
}
return result;
}
However, if I call JXPathContext.selectNodes(ems:observations()), I'm
getting
a single node containing the BasicNodeSet. I notice that there is a testcase
for
functions that return NodeSets, but that it uses expressions that actually
return the children of the NodeSet (test:nodeSet()/name).
There appear to be two problems. First, Expression.iterate() and
Expression.iteratePointers() do not correctly recognize a NodeSet as something
iterable. I've resolved this by reaching into the NodeSet and getting an
iterator over its pointers.
Second, Expression.PointerIterator doesn't recognize when it already has a
pointer, and instead tries to wrap it in a new pointer. This ends up treating
the pointer as a bean.
I've made these changes, and written a testcase that uses an unadorned NodeSet
function. I also found a class that used a variable named enum, and changed
this so that it would compile under 1.5.
The patch is attached. It's relative to commons-jxpath-1.2 (root of extract
directory).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JXPATH-50) [jxpath] does not properly handle NodeSet returned by extension function
[
https://issues.apache.org/jira/browse/JXPATH-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Benson updated JXPATH-50:
--
Attachment: jxpath-50.patch.txt
[jxpath] does not properly handle NodeSet returned by extension function
Key: JXPATH-50
URL: https://issues.apache.org/jira/browse/JXPATH-50
Project: Commons JXPath
Issue Type: Bug
Affects Versions: 1.2 Final
Environment: Operating System: other
Platform: All
Reporter: Keith D Gregory
Fix For: 1.3
Attachments: jxpath-50.patch.txt, jxpath-nodeset-functions.patch
Per the documentation, my function is returning a BasicNodeSet containing zero
or more pointers:
public static NodeSet observations(ExpressionContext context) {
// the cast below shouldn't break, as this is the only pointer type that
// makes sense in this context
ListNodePointer ptrs = extractObservations(
(NodePointer)context.getContextNodePointer(),
new ArrayListNodePointer());
BasicNodeSet result = new BasicNodeSet();
for (NodePointer ptr : ptrs) {
result.add(ptr);
}
return result;
}
However, if I call JXPathContext.selectNodes(ems:observations()), I'm
getting
a single node containing the BasicNodeSet. I notice that there is a testcase
for
functions that return NodeSets, but that it uses expressions that actually
return the children of the NodeSet (test:nodeSet()/name).
There appear to be two problems. First, Expression.iterate() and
Expression.iteratePointers() do not correctly recognize a NodeSet as something
iterable. I've resolved this by reaching into the NodeSet and getting an
iterator over its pointers.
Second, Expression.PointerIterator doesn't recognize when it already has a
pointer, and instead tries to wrap it in a new pointer. This ends up treating
the pointer as a bean.
I've made these changes, and written a testcase that uses an unadorned NodeSet
function. I also found a class that used a variable named enum, and changed
this so that it would compile under 1.5.
The patch is attached. It's relative to commons-jxpath-1.2 (root of extract
directory).
--
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: (JXPATH-50) [jxpath] does not properly handle NodeSet returned by extension function
[
https://issues.apache.org/jira/browse/JXPATH-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462535
]
Matt Benson commented on JXPATH-50:
---
Keith, since you're watching... right, only 2 files. Apparently there was no
licensing at the time you submitted your original patch. When I just submitted
my rework, I mistakenly selected the grant option, but since the work is
actually yours for the most part that was wrong. Probably if you clarify your
intent that the original patch be incorporated (sounds silly, huh?) it would be
for the best here.
-Matt
[jxpath] does not properly handle NodeSet returned by extension function
Key: JXPATH-50
URL: https://issues.apache.org/jira/browse/JXPATH-50
Project: Commons JXPath
Issue Type: Bug
Affects Versions: 1.2 Final
Environment: Operating System: other
Platform: All
Reporter: Keith D Gregory
Fix For: 1.3
Attachments: jxpath-50.patch.txt, jxpath-nodeset-functions.patch
Per the documentation, my function is returning a BasicNodeSet containing zero
or more pointers:
public static NodeSet observations(ExpressionContext context) {
// the cast below shouldn't break, as this is the only pointer type that
// makes sense in this context
ListNodePointer ptrs = extractObservations(
(NodePointer)context.getContextNodePointer(),
new ArrayListNodePointer());
BasicNodeSet result = new BasicNodeSet();
for (NodePointer ptr : ptrs) {
result.add(ptr);
}
return result;
}
However, if I call JXPathContext.selectNodes(ems:observations()), I'm
getting
a single node containing the BasicNodeSet. I notice that there is a testcase
for
functions that return NodeSets, but that it uses expressions that actually
return the children of the NodeSet (test:nodeSet()/name).
There appear to be two problems. First, Expression.iterate() and
Expression.iteratePointers() do not correctly recognize a NodeSet as something
iterable. I've resolved this by reaching into the NodeSet and getting an
iterator over its pointers.
Second, Expression.PointerIterator doesn't recognize when it already has a
pointer, and instead tries to wrap it in a new pointer. This ends up treating
the pointer as a bean.
I've made these changes, and written a testcase that uses an unadorned NodeSet
function. I also found a class that used a variable named enum, and changed
this so that it would compile under 1.5.
The patch is attached. It's relative to commons-jxpath-1.2 (root of extract
directory).
--
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] Add Matt Benson as a Jakarta committer
On 1/5/07, Henri Yandell [EMAIL PROTECTED] wrote: snip/ [X] +1 [ ] -1 -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JXPATH-40) [JXPath] Problem in namespace handling
[ https://issues.apache.org/jira/browse/JXPATH-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated JXPATH-40: -- Fix Version/s: 1.3 Fixed in http://svn.apache.org/viewvc?view=revrevision=136929 [JXPath] Problem in namespace handling -- Key: JXPATH-40 URL: https://issues.apache.org/jira/browse/JXPATH-40 Project: Commons JXPath Issue Type: Bug Affects Versions: 1.2 Final Environment: Operating System: other Platform: Other Reporter: Gianugo Rabellino Fix For: 1.3 Attachments: NotPropagatingRegisteredNSDeclarationsTest.java The Cocoon forms framework relies heavily in JXPath for binding forms data to business objects and/or XML. One of the newest requirements is being able to use XML namespaces as well, so we tried to integrate the latest JXPath version but went through a blocker because of what seems to be a problem in namespace inheritance. Attached is a test case which reproduces the issue, just drop to src/test/org/apache/commons/jxpath and run the test suite (sorry for the messy XML as an internal string, but it was the easiest way to send y'all some stuff to test right away). -- 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: (JXPATH-50) [jxpath] does not properly handle NodeSet returned by extension function
[
https://issues.apache.org/jira/browse/JXPATH-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462541
]
Keith D Gregory commented on JXPATH-50:
---
No problem. I hereby grant the Apache Software Foundation rights to this patch
as described by Individual Contributor License Agreement V2.0 (
http://www.apache.org/licenses/icla.txt ), submitted separately.
[jxpath] does not properly handle NodeSet returned by extension function
Key: JXPATH-50
URL: https://issues.apache.org/jira/browse/JXPATH-50
Project: Commons JXPath
Issue Type: Bug
Affects Versions: 1.2 Final
Environment: Operating System: other
Platform: All
Reporter: Keith D Gregory
Fix For: 1.3
Attachments: jxpath-50.patch.txt, jxpath-nodeset-functions.patch
Per the documentation, my function is returning a BasicNodeSet containing zero
or more pointers:
public static NodeSet observations(ExpressionContext context) {
// the cast below shouldn't break, as this is the only pointer type that
// makes sense in this context
ListNodePointer ptrs = extractObservations(
(NodePointer)context.getContextNodePointer(),
new ArrayListNodePointer());
BasicNodeSet result = new BasicNodeSet();
for (NodePointer ptr : ptrs) {
result.add(ptr);
}
return result;
}
However, if I call JXPathContext.selectNodes(ems:observations()), I'm
getting
a single node containing the BasicNodeSet. I notice that there is a testcase
for
functions that return NodeSets, but that it uses expressions that actually
return the children of the NodeSet (test:nodeSet()/name).
There appear to be two problems. First, Expression.iterate() and
Expression.iteratePointers() do not correctly recognize a NodeSet as something
iterable. I've resolved this by reaching into the NodeSet and getting an
iterator over its pointers.
Second, Expression.PointerIterator doesn't recognize when it already has a
pointer, and instead tries to wrap it in a new pointer. This ends up treating
the pointer as a bean.
I've made these changes, and written a testcase that uses an unadorned NodeSet
function. I also found a class that used a variable named enum, and changed
this so that it would compile under 1.5.
The patch is attached. It's relative to commons-jxpath-1.2 (root of extract
directory).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JXPATH-37) [jxpath] JXPathException cause
[ https://issues.apache.org/jira/browse/JXPATH-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated JXPATH-37: -- Fix Version/s: 1.3 Fixed in http://svn.apache.org/viewvc?view=revrevision=329481 [jxpath] JXPathException cause -- Key: JXPATH-37 URL: https://issues.apache.org/jira/browse/JXPATH-37 Project: Commons JXPath Issue Type: Bug Environment: Operating System: All Platform: All Reporter: Vadim Gritsenko Fix For: 1.3 Attachments: JXPathException.diff Simple patch to JXPathException - guarantees better stacktraces under jdk 1.4, reduces developer's headaches (what is this InvocationTargetException???), does not harm anyone else. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JXPATH-30) [jxpath] Source instructions on web site are wrong
[ https://issues.apache.org/jira/browse/JXPATH-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated JXPATH-30: -- Fix Version/s: 1.3 Fixed in http://svn.apache.org/viewvc?view=revrevision=374140 [jxpath] Source instructions on web site are wrong -- Key: JXPATH-30 URL: https://issues.apache.org/jira/browse/JXPATH-30 Project: Commons JXPath Issue Type: Bug Affects Versions: 1.2 Final Environment: Operating System: All Platform: All Reporter: elharo Fix For: 1.3 The web site at http://jakarta.apache.org/commons/jxpath/ refers to the CVS repository at least twice and links to the CVS repository. Apparently JXPath has switched to Subversion. The web site should be updated so it links to the current SVN repository instead. This needs to be pushed out even in advance of an actual release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LANG-312) DateFormatUtils.format with Timezone parameter CET produces wrong date in summer time 1945 to 1949
[
https://issues.apache.org/jira/browse/LANG-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-312:
---
Fix Version/s: 3.0
Assigning to 3.0 for consideration once we've got the 2.3 release out.
Hopefully won't be too long a delay before that's done and we can look at this
from an enhancement point of view.
DateFormatUtils.format with Timezone parameter CET produces wrong date in
summer time 1945 to 1949
Key: LANG-312
URL: https://issues.apache.org/jira/browse/LANG-312
Project: Commons Lang
Issue Type: Improvement
Affects Versions: 2.1, 2.2
Environment: IBM Java 1.4.2, Sun Java 1.4.2, Windows XP, SuSE Linux
Enterprise 9, German systems, at winter time
Reporter: Hayo
Fix For: 3.0
DateFormatUtils.format(dt, dd/MM/, Timezone.getTimezone(CET),
Locale.GERMANY); returns the date of the day before during summer time of the
years 1945 to 1949. The problem was detected on a system running in
Locale.GERMANY, current time CET, JDK 1.4.2.
The problem does not occur with the call DateFormatUtils.format(dt,
dd/MM/); which presumably uses the system defaults. These are likely to
be the same as the parameters i have passed.
The following code snippet demonstrates the problem:
for (int year = 0; year 150; year ++) {
for (int month = 0; month = 11; month ++) {
for (int day = 1; day = 28; day ++) {
java.sql.Date dt = new java.sql.Date(year, month, day);
// or java.util.Date
String def = DateFormatUtils.format(dt, dd/MM/);
String cet = DateFormatUtils.format(dt, dd/MM/,
Timezone.getTimezone(CET), Locale.GERMANY);
if (!cet.equals(def)) {
System.err.println(dt.toLocaleString() + Default:
+ def + CET: + cet);
}
}
}
}
Output:
--
03.04.1945 00:00:00 Default: 03/04/1945 CET:02/04/1945
[...]
18.11.1945 00:00:00 Default: 18/11/1945 CET:17/11/1945
15.04.1946 00:00:00 Default: 15/04/1946 CET:14/04/1946
[...]
07.10.1946 00:00:00 Default: 07/10/1946 CET:06/10/1946
07.04.1947 00:00:00 Default: 07/04/1947 CET:06/04/1947
[...]
05.10.1947 00:00:00 Default: 05/10/1947 CET:04/10/1947
19.04.1948 00:00:00 Default: 19/04/1948 CET:18/04/1948
[...]
03.10.1948 00:00:00 Default: 03/10/1948 CET:02/10/1948
11.04.1949 00:00:00 Default: 11/04/1949 CET:10/04/1949
[...]
02.10.1949 00:00:00 Default: 02/10/1949 CET:01/10/1949
This seems to be during the summer time of 1949 to 1945 in Berlin, and only
in Berlin. Setting the Locale to any other value has no effect on that. So i
ask myself, what results other central european users get. Setting the
Timezone to GMT+2 extracts exactly the high summer times in 1945 and 1947
(MEHSZ). (See below for list of summer times).
I could guess that some calendar calculations work with different libraries
that have different summer time maps (java.util.Date vs. Calendar). This
might depend on my environment, so this task should be tested by others (with
their local Timezone).
The API documentation does not clearly state what effect the Timezone/Locale
parameters should have.
In my strong opinion at least dates passed as java.sql.Date should not be
normalized to summer/standard time. A date is a date! For java.util.Date the
date recalculation behaviour should be mentioned in the docs, if it is really
intended this way by design.
===
These where the actual summer times in Germany
(http://www.ptb.de/de/org/4/44/441/salt.htm
http://de.wikipedia.org/wiki/Hochsommerzeit#Mitteleurop.C3.A4ische_Sommerzeit)
a) Summer time, Advance to CET (GMT+1): 1 hour (GMT+2)
1916-04-30 23:00:00 CET until 1916-10-01 1:00:00 CEST
1917-04-162:00:00 CET until 1917-09-17 3:00:00 CEST
1918-04-152:00:00 CET until 1918-09-16 3:00:00 CEST
1919 until 1939: No Summer time
1940-04-012:00:00 CET until 1942-11-02 3:00:00 CEST
1943-03-292:00:00 CET until 1943-10-04 3:00:00 CEST
1944-04-032:00:00 CET until 1944-10-02 3:00:00 CEST
1945-04-022:00:00 CET until 1945-09-16 2:00:00 CEST
Special: Berlin and sowjet occupied zone:
(1945-05-24) 2:00:00 CET until 1945-11-18 3:00:00 CEST
(1945-05-24) 3:00:00 CET until 1945-09-24 2:00:00 MEHSZ
1946-04-142:00:00 CET until 1946-10-07 3:00:00 CEST
1947-04-063:00:00 CET until 1947-10-05 3:00:00 CEST
1948-04-18
RE: [VOTE] Add Matt Benson as a Jakarta committer
Henri Yandell wrote on Friday, January 05, 2007 5:40 PM: As you can see on the list, Matt would like to help out with JXPath. Matt's been an Ant committer since Feb 2004. He's been active on the dev/user lists over the last couple of years, so not a new face here either. [X] +1 [ ] -1 Will end the vote on Tuesday morning. Hen - 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] Commented: (CONFIGURATION-247) recognize changes in included Propertiefiles
[ https://issues.apache.org/jira/browse/CONFIGURATION-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462549 ] Oliver Heger commented on CONFIGURATION-247: Implementing this feature is problematic because of the way include files in PropertiesConfiguration are currently handled: The properties found in included files are simply added to the current configuration object, and the connection to the source files is lost. One consequence of this is that if you save such a PropertiesConfiguration, the properties loaded from included files will be stored in the main properties file (rather than being written back to the original files). Support for include files is specific to PropertiesConfiguration and no general feature of (file-based) Configuration classes. With DefaultConfigurationBuilder and ConfigurationFactory Commons Configuration provides a more generic means of combining properties from different sources. The former allows defining reloading strategies for configurations that are to be combined together. Using this class you should be able to solve your problem. So I tend to close this issue as WON'T FIX unless you can give good reasons why you cannot use this alternative. recognize changes in included Propertiefiles Key: CONFIGURATION-247 URL: https://issues.apache.org/jira/browse/CONFIGURATION-247 Project: Commons Configuration Issue Type: New Feature Reporter: Mirko Wolf Properties-Files included in other properties-Files should be recognized by the event-listener / reloading-strategie set on the main properties-File. This is necessary in case of modifications in these included Files. for instance: main.properties include=sample.properties sample.properties [EMAIL PROTECTED] ... when i change the value of mail.address i definitly need a restart of my application. -- 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: (JXPATH-10) [jxpath] JXPath 1.1 code using custom functions failing when run in 1.2 onwards
[
https://issues.apache.org/jira/browse/JXPATH-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462553
]
Matt Benson commented on JXPATH-10:
---
Okay... this bug is a little more than a year old, so I'm not sure how the
original reporter has fared since its origination, but anyway:
As you may have realized, this regression is an artifact of the feature added
with JXPath 1.2 whereby an Object argument signifies that Pointers and NodeSets
should be decoded to the objects they represent. I hope to have a fairly easy
workaround completed soon. More later...
[jxpath] JXPath 1.1 code using custom functions failing when run in 1.2
onwards
---
Key: JXPATH-10
URL: https://issues.apache.org/jira/browse/JXPATH-10
Project: Commons JXPath
Issue Type: Bug
Affects Versions: 1.2 Final
Environment: Operating System: other
Platform: PC
Reporter: Paul Parisi
Priority: Blocker
Fix For: 1.3
We have recently attempted to upgrade from a 1.1 release of jxpath
to 1.2 and found a great deal of our jxpath code fails to run correctly.
We isolated the problem to relating to the use of Custom Extension
Functions and have included sample junit test case snippets that should
demonstrate the issue clearly.
The background on what we are trying to do with jxpath is as follows
(included so its clear on what we are trying to use jxpath to achieve):
Within our project, we make extensive use of Custom Extension Functions in
JXPath.
We also use JXPath variables significantly, in combination with these
functions,
that often take a JXPath variable as an argument(s) to the function.
We now rely heavily on the use of the ExpressionContext interface as the
first
argument to many of our functions. The reason for this is that we need a
convienient way to obtain access to 'original' object references within the
context invoked by the function (as you would expect).
However, we have also begun using a very useful combination of features, which
the API supports in version 1.1, where the first argument always defines the
ExpressionContext interface (which isn't really part of the method signature -
from a caller perspective), and a 2nd argument as 'Object' type. Within body
of
the function, we then cast the object of the 2nd argument as a NodeSet (or
define the NodeSet type within the method signature - either appears to work),
which provides us with access to the pointers for the object.
As previously mentioned, a jxpath variable is passed from the caller of the
function (received via the 2nd argument in the method signature), which is
automatically resolved, by jxpath, to the object itself.
The benefit of casting the object to NodeSet (interface) enables us to
retrieve
the first pointer in the NodeSet list. The first pointer concerns us, as it
refers to the String value passed to the argument of the function which we
need
access to. The object reference itself is of little concern in this case, as
once we have access to the variable name sent to the function, we can access
the
object via the ExpressionContext.
This all works fine in jxpath 1.1, however, in version 1.2 this functionality
is
now broken, since our objects are no longer being cast to NodeSet (previously
achieved via the internal implementation of jxpath NodeSet using a
SimpleNodeSet
- as per inspecting jxpath 1.1 source code).
Note on the use of ExpressionContext: For those methods that declare the
ExpressionContext interface (which must be the first argument, if used), as
part
of the argument list, the method signature from the caller perspective,
excludes
it from the argument list, as it is implied by jxpath. In other words, there
will be one less argument from the caller when the interface is used. In the
case where this interface was the only argument, which is common, then the
caller would be invoking a zero-argument method. This is behaviour we expect.
Here is a simplified example of one of our functions using the techniques
discussed:-
public static void deleteSomeObject(ExpressionContext expContext, Object obj)
{
// create a local jxpath context to retrieve values for jxpath variables
JXPathContext localContext = expContext.getJXPathContext();
// Nodeset of the object passed to method
NodeSet nodeset = (NodeSet)obj;
// Retrieve variable name passed to function
String declaredVariable = nodeset.getPointers().get(0).toString();
Object objectToDelete = null;
// If this method was passed the $obj1 var to delete, then retrieve 'Object
Type
1' via $obj1 variable
if (declaredVariable.equals($obj1)) {
objectToDelete = (ObjectType1)localContext.getValue($obj1);
}
// If this method
RE: [sandbox] Using commons-skin for all components
Good idea, +1 here. Gary Dennis Lundberg wrote on Thursday, January 04, 2007 10:34 PM: Hi Before I dive head-first into this I thought I'd ask first. I'd like to unify the M2 generated sites for all sandbox components, by making use of commons-skin. This would mean: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sandbox] Using commons-skin for all components
+1 - go for it! Phil
Re: [sandbox] Using commons-skin for all components
On 1/4/07, Dennis Lundberg [EMAIL PROTECTED] wrote: Hi Before I dive head-first into this I thought I'd ask first. I'd like to unify the M2 generated sites for all sandbox components, by making use of commons-skin. This would mean: 1. Make various changes to the sandbox-parent, which is currently located in sandbox-trunk: - Remove local style rules - Remove stuff that is inherited from commons-parent, most notably maven-classic-skin 2. Change pom.xml and site.xml for many sandbox components - Make sure inheritance is correct - Align navigation structure - Remove stuff that is inherited from sandbox-parent 3. Re-publish the sites for all sandbox components - Do mvn site:deploy for all sandbox components - Would like to move sandbox-parent to its own directory in SVN - If we feel that it's necessary at this time: release commons-skin, commons-parent and sandbox-parent Does this sound OK to you? +1, thanks for doing this m2 stuff. Niall -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Add Matt Benson as a Jakarta committer
+1.. Mvgr, Martin Henri Yandell wrote: As you can see on the list, Matt would like to help out with JXPath. Matt's been an Ant committer since Feb 2004. He's been active on the dev/user lists over the last couple of years, so not a new face here either. [ ] +1 [ ] -1 Will end the vote on Tuesday morning. Hen - 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: [all] Jira reporting
Martin Cooper martinc at apache.org writes: Any exact targetting for unresolved issues will lead to this issues hasn't made it into the latest release, we try to get it into the next one mails polluting the mailing lists without nearly any additional value. I think that is a good thing as it means someone is looking at that issue each release and deciding that it won't go in that release. If it keeps getting punted all the time then someone can ask if it's ever going to happen. This is exactly why we moved to something like what Hen is proposing for Struts. We had oodles of issues just sitting there with no indication of when, if ever, they were likely to be fixed, and no indication of whether anyone was committed to looking at them. Once you start versioning the issues, you get the beginnings of a roadmap rather than just a bucket of issues. Ok, that's a point. Cocoon does indeed suffer from this as well. But I guess in Cocoon changing this would just not work (or end in 300 issue version re-addressed mails per release). For the maintenance branch the development is much less targeted as it is more or less only project-driven, i.e. an issues that a committer needs on his current project gets handled rapidly. Other issues are mostly done on demand or on request. For littler projects or projects with less chaotic project management (which I like much though :)) the above might indeed be useful. Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Add Matt Benson as a Jakarta committer
+1 welcome! Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Add Matt Benson as a Jakarta committer
Henri Yandell schrieb: As you can see on the list, Matt would like to help out with JXPath. Matt's been an Ant committer since Feb 2004. He's been active on the dev/user lists over the last couple of years, so not a new face here either. [X ] +1 [ ] -1 Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (EMAIL-6) [email] Errors when sending MultiPartEmail with another email as an attachment
[
https://issues.apache.org/jira/browse/EMAIL-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462626
]
Ben Speakmon commented on EMAIL-6:
--
I'm pretty sure that:
debugEmail.addPart( new MimeMultipart(new MimePartDataSource(
email.getMimeMessage() ) ) );
isn't what you want; even if that worked correctly (which it doesn't, of which
more below), it would only add the content of the HTML message. It looks like
you're trying to send the entire HtmlEmail complete with header information, so
I figured I'd try using attach():
debugEmail.attach(new MimePartDataSource(email.getMimeMessage()), name,
desc);
but that doesn't work either as the MimePartDataSource constructor throws an
IOException complaining no content in the MimeMessage's input stream. So
something in the assumption that we can build a MimePartDataSource from a
HtmlEmail's MimeMessage is incorrect. I'll look into it further.
[email] Errors when sending MultiPartEmail with another email as an attachment
--
Key: EMAIL-6
URL: https://issues.apache.org/jira/browse/EMAIL-6
Project: Commons Email
Issue Type: Bug
Affects Versions: 1.0
Environment: Operating System: other
Platform: Other
Reporter: Dave Cherkassky
Attachments: MultiPartEmailTest.java.patch
Take a look at the code below:
if( debugMode ) {
if( logger.isInfoEnabled() ) {
logger.info( DEBUG mode is on. Sending email to + debugEmailAddress );
}
MultiPartEmail debugEmail = new MultiPartEmail();
if( logger.isDebugEnabled() ) {
debugEmail.setDebug( true );
}
debugEmail.setBounceAddress( debugEmailAddress );
debugEmail.setFrom( debugEmailAddress );
debugEmail.addReplyTo( debugEmailAddress );
debugEmail.addTo( debugEmailAddress );
debugEmail.setSubject( Test Message: + email.getSubject() );
debugEmail.setMsg( The email manager is operating in test mode. +
Attached is a message it would have sent had it been running for real.
);
debugEmail.addPart( new MimeMultipart(
new MimePartDataSource( email.getMimeMessage() ) ) );
debugEmail.setMailSession( emailSession );
messageId = debugEmail.send();
}
I get the following exception when I call debugEmail.send():
2006-03-12 09:07:01,140 [ main] INFO
com.djinnsoft.jade.email.EmailManager: DEBUG mode is on. Sending email to
[EMAIL PROTECTED]
2006-03-12 09:07:01,640 [ main] WARN
com.djinnsoft.jade.email.EmailManager: Error emailing sent item 235:
Sending
the email to the following server failed : null:25
javax.mail.SendFailedException: Sending failed;
nested exception is:
javax.mail.MessagingException: IOException while sending message;
nested exception is:
java.io.IOException: text/plain DataContentHandler requires String object,
was given object of type class javax.mail.internet.MimeMultipart
at javax.mail.Transport.send0(Transport.java:219)
at javax.mail.Transport.send(Transport.java:81)
at org.apache.commons.mail.Email.sendMimeMessage(Email.java:863)
at org.apache.commons.mail.Email.send(Email.java:898)
at
com.djinnsoft.jade.email.EmailManager.processMailing(EmailManager.java:1205)
(line 1205 corresponds to messageId = debugEmail.send(); in my code)
--
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: [sandbox] Using commons-skin for all components
I plan on doing all of the necessary changes myself. When all is done I'll ask for feedback on the results. So if you have a project in the sandbox you're involved in - stay tuned :) James Carman wrote: +1 from me (I can't remember if I'm binding or not). Do you need the individual projects to update their poms or are you going to take care of that? On 1/5/07, Henri Yandell [EMAIL PROTECTED] wrote: +1 here. On 1/4/07, Jörg Schaible [EMAIL PROTECTED] wrote: +1 Dennis Lundberg wrote on Thursday, January 04, 2007 10:34 PM: Hi Before I dive head-first into this I thought I'd ask first. I'd like to unify the M2 generated sites for all sandbox components, by making use of commons-skin. This would mean: - 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] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Add Matt Benson as a Jakarta committer
+1 Henri Yandell wrote: As you can see on the list, Matt would like to help out with JXPath. Matt's been an Ant committer since Feb 2004. He's been active on the dev/user lists over the last couple of years, so not a new face here either. [ ] +1 [ ] -1 Will end the vote on Tuesday morning. Hen - 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: [all] Jira reporting
On 1/5/07, Joerg Heinicke [EMAIL PROTECTED] wrote: Martin Cooper martinc at apache.org writes: Any exact targetting for unresolved issues will lead to this issues hasn't made it into the latest release, we try to get it into the next one mails polluting the mailing lists without nearly any additional value. I think that is a good thing as it means someone is looking at that issue each release and deciding that it won't go in that release. If it keeps getting punted all the time then someone can ask if it's ever going to happen. This is exactly why we moved to something like what Hen is proposing for Struts. We had oodles of issues just sitting there with no indication of when, if ever, they were likely to be fixed, and no indication of whether anyone was committed to looking at them. Once you start versioning the issues, you get the beginnings of a roadmap rather than just a bucket of issues. Ok, that's a point. Cocoon does indeed suffer from this as well. But I guess in Cocoon changing this would just not work (or end in 300 issue version re-addressed mails per release). For the maintenance branch the development is much less targeted as it is more or less only project-driven, i.e. an issues that a committer needs on his current project gets handled rapidly. Other issues are mostly done on demand or on request. For littler projects or projects with less chaotic project management (which I like much though :)) the above might indeed be useful. Yeah, for a larger project it'd be more painful. I think you'd want to be thinking about more defined process - this one is an intentionally lightweight hack that seems to work with little buy in. The spam issue is a tricky decision. Sometimes I turn off the notifications to then do a lot of changes, other times I let the spam hit the list because moving an issue into a version is a decision. If there were a lot of them, I'd be tempted to send an email to the list saying Moving these issues into XXX and then do a bulk move with the send-email option turned off. That'd be a nice JIRA feature - bulk-email notification rather than individual notification for each issue. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (EMAIL-6) [email] Errors when sending MultiPartEmail with another email as an attachment
[
https://issues.apache.org/jira/browse/EMAIL-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462662
]
Ben Speakmon commented on EMAIL-6:
--
I was only able to get this to work by writing out the HtmlEmail as raw RFC822
to a file and then using the existing attach() method. Ick.
I can tell that what Dave's trying to do will definitely not work for a number
of reasons, but going into detail on each is probably unnecessary noise.
My judgment is that there's no way in the current MultiPartEmail API to do what
Dave wants to do; maybe an attach(Email email) method is called for. In any
case, it seems within the scope of commons-email to simplify attaching mails to
other mails, and it's something the current API cannot handle.
[email] Errors when sending MultiPartEmail with another email as an attachment
--
Key: EMAIL-6
URL: https://issues.apache.org/jira/browse/EMAIL-6
Project: Commons Email
Issue Type: Bug
Affects Versions: 1.0
Environment: Operating System: other
Platform: Other
Reporter: Dave Cherkassky
Attachments: MultiPartEmailTest.java.patch
Take a look at the code below:
if( debugMode ) {
if( logger.isInfoEnabled() ) {
logger.info( DEBUG mode is on. Sending email to + debugEmailAddress );
}
MultiPartEmail debugEmail = new MultiPartEmail();
if( logger.isDebugEnabled() ) {
debugEmail.setDebug( true );
}
debugEmail.setBounceAddress( debugEmailAddress );
debugEmail.setFrom( debugEmailAddress );
debugEmail.addReplyTo( debugEmailAddress );
debugEmail.addTo( debugEmailAddress );
debugEmail.setSubject( Test Message: + email.getSubject() );
debugEmail.setMsg( The email manager is operating in test mode. +
Attached is a message it would have sent had it been running for real.
);
debugEmail.addPart( new MimeMultipart(
new MimePartDataSource( email.getMimeMessage() ) ) );
debugEmail.setMailSession( emailSession );
messageId = debugEmail.send();
}
I get the following exception when I call debugEmail.send():
2006-03-12 09:07:01,140 [ main] INFO
com.djinnsoft.jade.email.EmailManager: DEBUG mode is on. Sending email to
[EMAIL PROTECTED]
2006-03-12 09:07:01,640 [ main] WARN
com.djinnsoft.jade.email.EmailManager: Error emailing sent item 235:
Sending
the email to the following server failed : null:25
javax.mail.SendFailedException: Sending failed;
nested exception is:
javax.mail.MessagingException: IOException while sending message;
nested exception is:
java.io.IOException: text/plain DataContentHandler requires String object,
was given object of type class javax.mail.internet.MimeMultipart
at javax.mail.Transport.send0(Transport.java:219)
at javax.mail.Transport.send(Transport.java:81)
at org.apache.commons.mail.Email.sendMimeMessage(Email.java:863)
at org.apache.commons.mail.Email.send(Email.java:898)
at
com.djinnsoft.jade.email.EmailManager.processMailing(EmailManager.java:1205)
(line 1205 corresponds to messageId = debugEmail.send(); in my code)
--
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] Release Commons Transaction 1.2
On 1/5/07, Joerg Heinicke [EMAIL PROTECTED] wrote: Niall Pemberton niall.pemberton at gmail.com writes: Since RC3 was created (back in July 2006!) there is now the new Source Header and Copyright Notice Policy that needs to be complied with: http://www.apache.org/legal/src-headers.html Henri fixed this in the trunk for transaction a few weeks ago - but warrants a new RC IMO. Ok, that's an issue. Also Rahul raised the issue about dependency jars held in the repository - and it looked to me like you were going to change the build to download these automatically, rather than including them in the distro: http://tinyurl.com/yby9hd We wanted to get out the release as fast as possible. This issue can be postponed and addressed later IMO. The ant build only seems to work for JDK 1.3 when the geronimo jars are overriden with the sun ones and doesn't work for me for JDK 1.4 (tests fail because it can't find junit). So it seems a waste of time having them in the repo. I can update the ant build to download the other jars (or allow them to be specified in a build.properties) if its important to have a working ant build for 1.3. I also think given the long time between cutting the RC and voting this makes the case for tagging the repository - initially I wondered where this had been built from as it didn't match any current source - until I releaized it had been done so long ago. The long time itself is not an issue, nothing has changed on the source code since the latest RC except the headers. The commits I did recently don't fix the issue (not buildable with JDK 1.3 due to 1.4 compiled dependencies), but only show the issue at a different during a build. This itself does not warrant a new RC IMO, but as the headers do so, it will be included in that RC as well. I'm wondering how the RC was created since neither the ant or maven builds seem to currently produce what RC3 contained. Maybe a combination of the two was used with some manual intervention? IMO its important for the release to be easily re-created and the maven1 build should be used since the ant build seems to have too many problems. If it helps I can tag and produce another RC (using the maven build). Niall Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
