[net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
Hi Steve, What I think you're missing is that if you put jsse.jar on your classpath, you can use javax.net.ssl with java 1.3. maybe i don't explain well, sorry. The three classes of com.sun.net.ssl that are used for implement FTPS (in the way that Paul did and I modified, maybe there is another...) are... com.sun.net.ssl.KeyManagerFactory (http://java.sun.com/products/jsse/doc/apidoc/com/sun/net/ssl/KeyManagerFactory.html) com.sun.net.ssl.SSLContext (http://java.sun.com/products/jsse/doc/apidoc/com/sun/net/ssl/SSLContext.html) com.sun.net.ssl.TrustManager (http://java.sun.com/products/jsse/doc/apidoc/com/sun/net/ssl/TrustManager.html) This classes in JSSE are only in the package com.sun.net.ssl, and although in JSSE 1.0.3 there are a packege javax.net.ssl, it doesn't contain this classes, it contains javax.net.ssl.SSLSocket, a classes soon used, to implement FTPS. And the commons-net team would prefer to go that way because Sun says that com.sun.net may go away with some future release, but not javax.net. Yes, this would be a small inconvenience for java 1.3 users, but the stability is worth it. This three classes in JDK 1.4.2, were move to javax.net.ssl.KeyManagerFactory (http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/KeyManagerFactory.html) javax.net.ssl.SSLContext (http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/SSLContext.html) javax.net.ssl.TrustManager (http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/TrustManager.html) But if you download for example JDK 1.4.2 and look inside of (jre/lib) you'll find jsse.jar, the jar where still are com.sun.net.ssl. Sun, still mantain compatiblity with JDK 1.3. And still in JDK 1.5, you'll find jre/lib/jsse.jar. But when jsse.jar desapear, i offer to modified code... In other way if use javax.net.ssl.KeyManagerFactory , javax.net.ssl.SSLContext, javax.net.ssl.TrustManager, ftps don't work under JDK 1.3. I hope explain better, this time. Then, make that you consider appropiate... Thanks all, for your time. -- The whole purpose of places like Starbucks is for people with no decision-making ability whatsoever to make six decisions just to buy one cup of coffee. Short, tall, light, dark, caf, decaf, low-fat, non-fat, etc. So people who don't know what the hell they're doing or who on earth they are can, for only $2.95, get not just a cup of coffee but an absolutely defining sense of self: Tall. Decaf. Cappuccino. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[net] JDK 1.4+ Branch?
Hi Rory, i have not sufficient experience in Jakarta Commons Net, to decide or even to talk about of this, but i would said a few things about your reasoning... * FTPS support would not necessitate a separate (JSSE) jar dependency; About dependency, i hope explain well in thread JSSE and FTPS functionality. * It also may be easier to incrementally add new functionality, such as Proxy support If when you said Proxy support, you talk about the problem/bug URLConnection, in JDK 1.3, that don't send user and password in HttpURLConnection. i.e. URL url = new URL(ftp://user:[EMAIL PROTECTED]:port/path); URLConnection conexion = (url).openConnection(); conexion.connect(); InputStream in = clientHttp.getInputStream(); To the proxy it send ftp://host:port/path... Because of this, its imposible to implement FtpHttpProxyClient... (its only works with anonymous client). If you talk of this, i have a solution, 2 classes that extends and modifie 2 classes of JDK 1.3 (sun.net.www.protocol.http.HttpURLConnection, sun.net.www.http.HttpClient) and solve this problem... If you want, i could colaborate... And Steve, The only negative I can find is that our contributor of the FTPS stuff badly wants 1.3 compatibility. And I have a feeling that he's not the only one. 1.3 is not yet End of Life according to Sun, although it will be soon. I'm not negative :) only i would like use Jakarta Commons Net with my JDK 1.3 proyects... If remember i don't ask colaborate, i only want 2 variables protected... :) But, i don't mind colaborate with yours to make Jakarta Commons Net better (and if possible JDK 1.3 compilant) I guess I'm okay with it but I'm not quite a +1 yet until I understand how much work is involved. I notice a couple of the Jakarta Commons projects do separate branches: About this, i offer my time, to mantain FTPS under 1.3 or ever 1.4 :) If you want... Thank for your time. -- The whole purpose of places like Starbucks is for people with no decision-making ability whatsoever to make six decisions just to buy one cup of coffee. Short, tall, light, dark, caf, decaf, low-fat, non-fat, etc. So people who don't know what the hell they're doing or who on earth they are can, for only $2.95, get not just a cup of coffee but an absolutely defining sense of self: Tall. Decaf. Cappuccino. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [IO][PATCH] - RegexFilter support
Oliver Siegmar wrote: On Saturday 28 January 2006 21:37, Stephen Colebourne wrote: However, commons-io is JDK1.2 compatible, so unless we create a 1.4 or 1.5 branch we'll be unable to include a Regexp filter. Couldn't Jakarta's ORO be used until there's a JDK 1.4+ branch? Sadly, no, as commons-io is a no-dependency library. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly-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-test has an issue affecting its community integration.
This issue affects 1 projects,
and has been outstanding for 9 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-test : Commons Jelly
Full details are available at:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-test/index.html
That said, some information snippets are provided here.
The following annotations (debug/informational/warning/error messages) were
provided:
-DEBUG- Dependency on jakarta-servletapi-5-servlet exists, no need to add for
property maven.jar.servletapi.
-DEBUG- Dependency on jakarta-taglibs-standard exists, no need to add for
property maven.jar.jstl.
-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/build.properties]
-DEBUG- (Gump generated) Maven Properties in:
/usr/local/gump/public/workspace/commons-jelly/build.properties
-INFO- Failed with reason build failed
-DEBUG- Maven POM in:
/usr/local/gump/public/workspace/commons-jelly/project.xml
-DEBUG- Maven project properties in:
/usr/local/gump/public/workspace/commons-jelly/project.properties
-INFO- Project Reports in:
/usr/local/gump/public/workspace/commons-jelly/target/test-reports
The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-test/gump_work/build_commons-jelly_commons-jelly-test.html
Work Name: build_commons-jelly_commons-jelly-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 54 secs
Command Line: maven --offline jar
[Working Directory: /usr/local/gump/public/workspace/commons-jelly]
CLASSPATH:
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-29012006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/forehead/forehead-1.0-beta-5.jar:/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr154/dist/lib/servlet-api.jar:/usr/local/gump/public/workspace/jakarta-taglibs/dist/standard/lib/jstl.jar:/usr/local/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar
-
[junit] Expected expression: ${singleSize*2}
[junit] Actual expression: ${doubleSize} File:
file:/x1/gump/public/workspace/commons-jelly/target/test-classes/org/apache/commons/jelly/suite.jelly
At tag test:assertEquals: line: 359 column: 75
[junit] org.apache.commons.jelly.JellyTagException:
file:/x1/gump/public/workspace/commons-jelly/target/test-classes/org/apache/commons/jelly/suite.jelly:359:75:
test:assertEquals expected:[22] but was:[22]
[junit] Expected expression: ${singleSize*2}
[junit] Actual expression: ${doubleSize} File:
file:/x1/gump/public/workspace/commons-jelly/target/test-classes/org/apache/commons/jelly/suite.jelly
At tag test:assertEquals: line: 359 column: 75
[junit] at
org.apache.commons.jelly.impl.TagScript.handleException(TagScript.java:712)
[junit] at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:282)
[junit] at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
[junit] at
org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59)
[junit] Caused by:
org.apache.commons.jelly.tags.junit.JellyAssertionFailedError: expected:[22]
but was:[22]
[junit] Expected expression: ${singleSize*2}
[junit] Actual expression: ${doubleSize} File:
file:/x1/gump/public/workspace/commons-jelly/target/test-classes/org/apache/commons/jelly/suite.jelly
At tag test:assertEquals: line: 359 column: 75
[junit] at
org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:39)
[junit] at
org.apache.commons.jelly.tags.junit.AssertTagSupport.failNotEquals(AssertTagSupport.java:62)
[junit] at
org.apache.commons.jelly.tags.junit.AssertEqualsTag.doTag(AssertEqualsTag.java:55)
[junit]
[EMAIL PROTECTED]: Project commons-jelly-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-test has an issue affecting its community integration.
This issue affects 1 projects,
and has been outstanding for 9 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-test : Commons Jelly
Full details are available at:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-test/index.html
That said, some information snippets are provided here.
The following annotations (debug/informational/warning/error messages) were
provided:
-DEBUG- Dependency on jakarta-servletapi-5-servlet exists, no need to add for
property maven.jar.servletapi.
-DEBUG- Dependency on jakarta-taglibs-standard exists, no need to add for
property maven.jar.jstl.
-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/build.properties]
-DEBUG- (Gump generated) Maven Properties in:
/usr/local/gump/public/workspace/commons-jelly/build.properties
-INFO- Failed with reason build failed
-DEBUG- Maven POM in:
/usr/local/gump/public/workspace/commons-jelly/project.xml
-DEBUG- Maven project properties in:
/usr/local/gump/public/workspace/commons-jelly/project.properties
-INFO- Project Reports in:
/usr/local/gump/public/workspace/commons-jelly/target/test-reports
The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-test/gump_work/build_commons-jelly_commons-jelly-test.html
Work Name: build_commons-jelly_commons-jelly-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 54 secs
Command Line: maven --offline jar
[Working Directory: /usr/local/gump/public/workspace/commons-jelly]
CLASSPATH:
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-29012006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/forehead/forehead-1.0-beta-5.jar:/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr154/dist/lib/servlet-api.jar:/usr/local/gump/public/workspace/jakarta-taglibs/dist/standard/lib/jstl.jar:/usr/local/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar
-
[junit] Expected expression: ${singleSize*2}
[junit] Actual expression: ${doubleSize} File:
file:/x1/gump/public/workspace/commons-jelly/target/test-classes/org/apache/commons/jelly/suite.jelly
At tag test:assertEquals: line: 359 column: 75
[junit] org.apache.commons.jelly.JellyTagException:
file:/x1/gump/public/workspace/commons-jelly/target/test-classes/org/apache/commons/jelly/suite.jelly:359:75:
test:assertEquals expected:[22] but was:[22]
[junit] Expected expression: ${singleSize*2}
[junit] Actual expression: ${doubleSize} File:
file:/x1/gump/public/workspace/commons-jelly/target/test-classes/org/apache/commons/jelly/suite.jelly
At tag test:assertEquals: line: 359 column: 75
[junit] at
org.apache.commons.jelly.impl.TagScript.handleException(TagScript.java:712)
[junit] at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:282)
[junit] at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
[junit] at
org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59)
[junit] Caused by:
org.apache.commons.jelly.tags.junit.JellyAssertionFailedError: expected:[22]
but was:[22]
[junit] Expected expression: ${singleSize*2}
[junit] Actual expression: ${doubleSize} File:
file:/x1/gump/public/workspace/commons-jelly/target/test-classes/org/apache/commons/jelly/suite.jelly
At tag test:assertEquals: line: 359 column: 75
[junit] at
org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:39)
[junit] at
org.apache.commons.jelly.tags.junit.AssertTagSupport.failNotEquals(AssertTagSupport.java:62)
[junit] at
org.apache.commons.jelly.tags.junit.AssertEqualsTag.doTag(AssertEqualsTag.java:55)
[junit]
[EMAIL PROTECTED]: Project commons-jelly-tags-xml-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-xml-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 9 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-xml-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-xml-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/xml/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-xml-test/gump_work/build_commons-jelly_commons-jelly-tags-xml-test.html Work Name: build_commons-jelly_commons-jelly-tags-xml-test (Type: Build) Work ended in a state of : Failed Elapsed: 41 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml] CLASSPATH: /opt/jdk1.4/lib/tools.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-29012006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-29012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-29012006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar - [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] [junit] [junit] Testcase: testSetSingleNodeAndAsString(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an ERROR [junit] file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:294:81: x:set You must define an attribute called 'select' for this tag. [junit] org.apache.commons.jelly.MissingAttributeException: file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:294:81: x:set You must define an attribute called 'select' for this tag. [junit] at org.apache.commons.jelly.tags.xml.SetTag.doTag(SetTag.java:86) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] [junit] [junit] Testcase: testSetStringLists(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an ERROR [junit] file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:339:82: x:set You must define an attribute called 'select' for this tag. [junit] org.apache.commons.jelly.MissingAttributeException: file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:339:82: x:set You must define an attribute called 'select' for this tag. [junit] at org.apache.commons.jelly.tags.xml.SetTag.doTag(SetTag.java:86) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] [junit] [junit] Testcase: testEntities(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an ERROR [junit]
[EMAIL PROTECTED]: Project commons-jelly-tags-xml-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-xml-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 9 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-xml-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-xml-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/xml/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-xml-test/gump_work/build_commons-jelly_commons-jelly-tags-xml-test.html Work Name: build_commons-jelly_commons-jelly-tags-xml-test (Type: Build) Work ended in a state of : Failed Elapsed: 41 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml] CLASSPATH: /opt/jdk1.4/lib/tools.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-29012006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-29012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-29012006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar - [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] [junit] [junit] Testcase: testSetSingleNodeAndAsString(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an ERROR [junit] file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:294:81: x:set You must define an attribute called 'select' for this tag. [junit] org.apache.commons.jelly.MissingAttributeException: file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:294:81: x:set You must define an attribute called 'select' for this tag. [junit] at org.apache.commons.jelly.tags.xml.SetTag.doTag(SetTag.java:86) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] [junit] [junit] Testcase: testSetStringLists(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an ERROR [junit] file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:339:82: x:set You must define an attribute called 'select' for this tag. [junit] org.apache.commons.jelly.MissingAttributeException: file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:339:82: x:set You must define an attribute called 'select' for this tag. [junit] at org.apache.commons.jelly.tags.xml.SetTag.doTag(SetTag.java:86) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] [junit] [junit] Testcase: testEntities(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an ERROR [junit]
[EMAIL PROTECTED]: Project commons-jelly-tags-swing (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-swing has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 9 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-swing : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-swing/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-swing-29012006.jar] identifier set to project name -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/swing/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/swing/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/swing/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/swing/target/test-reports -WARNING- No directory [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/swing/target/test-reports] -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-swing/gump_work/build_commons-jelly_commons-jelly-tags-swing.html Work Name: build_commons-jelly_commons-jelly-tags-swing (Type: Build) Work ended in a state of : Failed Elapsed: 4 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/swing] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-29012006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-29012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/target/commons-jelly-tags-define-29012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/interaction/target/commons-jelly-tags-interaction-29012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-29012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-29012006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar - at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:274) at java.lang.Class.newInstance0(Class.java:308) at java.lang.Class.newInstance(Class.java:261) at org.apache.commons.jelly.JellyContext.getTagLibrary(JellyContext.java:432) at org.apache.maven.jelly.MavenJellyContext.getTagLibrary(MavenJellyContext.java:171) at org.apache.commons.jelly.parser.XMLParser.createTag(XMLParser.java:1033) at org.apache.commons.jelly.parser.XMLParser.startElement(XMLParser.java:647) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source) at
[EMAIL PROTECTED]: Project commons-jelly-tags-swing (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-swing has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 9 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-swing : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-swing/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-swing-29012006.jar] identifier set to project name -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/swing/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/swing/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/swing/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/swing/target/test-reports -WARNING- No directory [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/swing/target/test-reports] -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-swing/gump_work/build_commons-jelly_commons-jelly-tags-swing.html Work Name: build_commons-jelly_commons-jelly-tags-swing (Type: Build) Work ended in a state of : Failed Elapsed: 4 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/swing] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-29012006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-29012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/target/commons-jelly-tags-define-29012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/interaction/target/commons-jelly-tags-interaction-29012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-29012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-29012006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar - at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:274) at java.lang.Class.newInstance0(Class.java:308) at java.lang.Class.newInstance(Class.java:261) at org.apache.commons.jelly.JellyContext.getTagLibrary(JellyContext.java:432) at org.apache.maven.jelly.MavenJellyContext.getTagLibrary(MavenJellyContext.java:171) at org.apache.commons.jelly.parser.XMLParser.createTag(XMLParser.java:1033) at org.apache.commons.jelly.parser.XMLParser.startElement(XMLParser.java:647) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source) at
[EMAIL PROTECTED]: Project commons-jelly-tags-html (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-html has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 9 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-html : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-html/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-html-29012006.jar] identifier set to project name -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-reports -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-html/gump_work/build_commons-jelly_commons-jelly-tags-html.html Work Name: build_commons-jelly_commons-jelly-tags-html (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/html] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-29012006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-29012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/commons-jelly-tags-jsl-29012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-29012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-29012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-29012006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar:/usr/local/gump/packages/nekohtml-0.9.5/nekohtml.jar - [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] [junit] [junit] Testcase: testLowerCase(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an ERROR [junit] file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:40:48: test:assert You must define an attribute called 'test' for this tag. [junit] org.apache.commons.jelly.MissingAttributeException: file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:40:48: test:assert You must define an attribute called 'test' for this tag. [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:54) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] [junit] [junit] Testcase: testMixedCase(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an ERROR [junit] file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:47:48: test:assert You must define an attribute called 'test' for this tag. [junit] org.apache.commons.jelly.MissingAttributeException: file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:47:48: test:assert You must define an attribute called 'test' for this tag. [junit] at
[EMAIL PROTECTED]: Project commons-jelly-tags-html (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-html has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 9 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-html : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-html/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-html-29012006.jar] identifier set to project name -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-reports -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-html/gump_work/build_commons-jelly_commons-jelly-tags-html.html Work Name: build_commons-jelly_commons-jelly-tags-html (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/html] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-29012006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-29012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/commons-jelly-tags-jsl-29012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-29012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-29012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-29012006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar:/usr/local/gump/packages/nekohtml-0.9.5/nekohtml.jar - [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] [junit] [junit] Testcase: testLowerCase(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an ERROR [junit] file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:40:48: test:assert You must define an attribute called 'test' for this tag. [junit] org.apache.commons.jelly.MissingAttributeException: file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:40:48: test:assert You must define an attribute called 'test' for this tag. [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:54) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] [junit] [junit] Testcase: testMixedCase(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an ERROR [junit] file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:47:48: test:assert You must define an attribute called 'test' for this tag. [junit] org.apache.commons.jelly.MissingAttributeException: file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:47:48: test:assert You must define an attribute called 'test' for this tag. [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 9 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: 17 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl] CLASSPATH: /opt/jdk1.4/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/jakarta-commons/cli/target/commons-cli-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-29012006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-29012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-29012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-29012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-29012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-29012006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar - [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.TagSupport.getBodyText(TagSupport.java:234) [junit] at org.apache.commons.jelly.tags.core.SetTag.doTag(SetTag.java:90) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:160) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:58) [junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:79) [junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:58) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:102) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:91) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:78) [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 9 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: 17 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl] CLASSPATH: /opt/jdk1.4/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/jakarta-commons/cli/target/commons-cli-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-29012006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-29012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-29012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-29012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-29012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-29012006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar - [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.TagSupport.getBodyText(TagSupport.java:234) [junit] at org.apache.commons.jelly.tags.core.SetTag.doTag(SetTag.java:90) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:160) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:58) [junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:79) [junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:58) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:102) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:91) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:78) [junit] at
[EMAIL PROTECTED]: Project commons-logging-dist (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-logging-dist has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 9 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-logging-dist : Logging Library Package Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons/commons-logging-dist/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on logging-log4j exists, no need to add for property log4j13.jar. -DEBUG- Dependency on excalibur-logkit exists, no need to add for property logkit.jar. -DEBUG- Dependency on excalibur-framework-api exists, no need to add for property avalon-framework.jar. -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-logging-dist/gump_work/build_jakarta-commons_commons-logging-dist.html Work Name: build_jakarta-commons_commons-logging-dist (Type: Build) Work ended in a state of : Failed Elapsed: 11 secs Command Line: java -Djava.awt.headless=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 -Dlog4j13.jar=/usr/local/gump/public/workspace/logging-log4j/dist/lib/log4j-29012006.jar -Davalon-framework.jar=/usr/local/gump/public/workspace/excalibur/framework/api/target/excalibur-framework-api-29012006.jar -Dlogkit.jar=/usr/local/gump/public/workspace/excalibur/containerkit/logkit/target/excalibur-logkit-29012006.jar -Dcomponent.version=29012006 dist [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/logging] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/classes:/usr/local/gump/public/workspace/jakarta-commons/logging/target/tests:/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/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/logging-log4j/dist/lib/log4j-29012006.jar:/usr/local/gump/public/workspace/excalibur/containerkit/logkit/target/excalibur-logkit-29012006.jar:/usr/local/gump/public/workspace/excalibur/framework/api/target/excalibur-framework-api-29012006.jar:/usr/local/gump/public/workspace/excalibur/framework/impl/target/excalibur-framework-impl-29012006.jar:/usr/local/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar - [junit] at junit.framework.TestResult.runProtected(TestResult.java:124) [junit] at junit.framework.TestResult.run(TestResult.java:109) [junit] at junit.framework.TestCase.run(TestCase.java:120) [junit] at org.apache.commons.logging.PathableTestSuite.runTest(PathableTestSuite.java:141) [junit] at junit.framework.TestSuite.run(TestSuite.java:225) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:328) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:736) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:605) [junit] 29.53.2006 [FATAL] DecoratedLogger - fatal java.lang.IndexOutOfBoundsExceptionjava.lang.IndexOutOfBoundsException [junit] at org.apache.commons.logging.simple.CustomConfigTestCase.logExceptionMessages(CustomConfigTestCase.java:236) [junit] at org.apache.commons.logging.simple.CustomConfigTestCase.testSerializable(CustomConfigTestCase.java:157) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [junit] at java.lang.reflect.Method.invoke(Method.java:324) [junit]
[EMAIL PROTECTED]: Project commons-logging-dist (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-logging-dist has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 9 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-logging-dist : Logging Library Package Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons/commons-logging-dist/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on logging-log4j exists, no need to add for property log4j13.jar. -DEBUG- Dependency on excalibur-logkit exists, no need to add for property logkit.jar. -DEBUG- Dependency on excalibur-framework-api exists, no need to add for property avalon-framework.jar. -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-logging-dist/gump_work/build_jakarta-commons_commons-logging-dist.html Work Name: build_jakarta-commons_commons-logging-dist (Type: Build) Work ended in a state of : Failed Elapsed: 11 secs Command Line: java -Djava.awt.headless=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 -Dlog4j13.jar=/usr/local/gump/public/workspace/logging-log4j/dist/lib/log4j-29012006.jar -Davalon-framework.jar=/usr/local/gump/public/workspace/excalibur/framework/api/target/excalibur-framework-api-29012006.jar -Dlogkit.jar=/usr/local/gump/public/workspace/excalibur/containerkit/logkit/target/excalibur-logkit-29012006.jar -Dcomponent.version=29012006 dist [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/logging] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/classes:/usr/local/gump/public/workspace/jakarta-commons/logging/target/tests:/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/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/logging-log4j/dist/lib/log4j-29012006.jar:/usr/local/gump/public/workspace/excalibur/containerkit/logkit/target/excalibur-logkit-29012006.jar:/usr/local/gump/public/workspace/excalibur/framework/api/target/excalibur-framework-api-29012006.jar:/usr/local/gump/public/workspace/excalibur/framework/impl/target/excalibur-framework-impl-29012006.jar:/usr/local/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar - [junit] at junit.framework.TestResult.runProtected(TestResult.java:124) [junit] at junit.framework.TestResult.run(TestResult.java:109) [junit] at junit.framework.TestCase.run(TestCase.java:120) [junit] at org.apache.commons.logging.PathableTestSuite.runTest(PathableTestSuite.java:141) [junit] at junit.framework.TestSuite.run(TestSuite.java:225) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:328) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:736) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:605) [junit] 29.53.2006 [FATAL] DecoratedLogger - fatal java.lang.IndexOutOfBoundsExceptionjava.lang.IndexOutOfBoundsException [junit] at org.apache.commons.logging.simple.CustomConfigTestCase.logExceptionMessages(CustomConfigTestCase.java:236) [junit] at org.apache.commons.logging.simple.CustomConfigTestCase.testSerializable(CustomConfigTestCase.java:157) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [junit] at java.lang.reflect.Method.invoke(Method.java:324) [junit]
[EMAIL PROTECTED]: Project commons-jelly-tags-define-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-define-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 9 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-define-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-define-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/define/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-define-test/gump_work/build_commons-jelly_commons-jelly-tags-define-test.html Work Name: build_commons-jelly_commons-jelly-tags-define-test (Type: Build) Work ended in a state of : Failed Elapsed: 17 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-29012006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-29012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/dynabean/target/commons-jelly-tags-dynabean-29012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-29012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-29012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-29012006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar - [junit] at org.jaxen.saxpath.base.XPathReader.unionExpr(XPathReader.java:1129) [junit] at org.jaxen.saxpath.base.XPathReader.unaryExpr(XPathReader.java:1117) [junit] at org.jaxen.saxpath.base.XPathReader.multiplicativeExpr(XPathReader.java:1039) [junit] at org.jaxen.saxpath.base.XPathReader.additiveExpr(XPathReader.java:982) [junit] at org.jaxen.saxpath.base.XPathReader.relationalExpr(XPathReader.java:902) [junit] at org.jaxen.saxpath.base.XPathReader.equalityExpr(XPathReader.java:850) [junit] at org.jaxen.saxpath.base.XPathReader.andExpr(XPathReader.java:826) [junit] at org.jaxen.saxpath.base.XPathReader.orExpr(XPathReader.java:804) [junit] at org.jaxen.saxpath.base.XPathReader.expr(XPathReader.java:797) [junit] at org.jaxen.saxpath.base.XPathReader.parse(XPathReader.java:105) [junit] at org.jaxen.BaseXPath.init(BaseXPath.java:126) [junit] at org.jaxen.BaseXPath.init(BaseXPath.java:152) [junit] at org.jaxen.dom4j.Dom4jXPath.init(Dom4jXPath.java:101) [junit] at org.apache.commons.jelly.expression.xpath.XPathExpression.evaluate(XPathExpression.java:78) [junit] at org.apache.commons.jelly.expression.ExpressionSupport.evaluateRecurse(ExpressionSupport.java:61) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:256) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] at junit.framework.TestCase.runBare(TestCase.java:127) [junit] at junit.framework.TestResult$1.protect(TestResult.java:106) [junit] at
[EMAIL PROTECTED]: Project commons-jelly-tags-define-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-define-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 9 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-define-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-define-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/define/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-define-test/gump_work/build_commons-jelly_commons-jelly-tags-define-test.html Work Name: build_commons-jelly_commons-jelly-tags-define-test (Type: Build) Work ended in a state of : Failed Elapsed: 17 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-29012006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-29012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/dynabean/target/commons-jelly-tags-dynabean-29012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-29012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-29012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-29012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-29012006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar - [junit] at org.jaxen.saxpath.base.XPathReader.unionExpr(XPathReader.java:1129) [junit] at org.jaxen.saxpath.base.XPathReader.unaryExpr(XPathReader.java:1117) [junit] at org.jaxen.saxpath.base.XPathReader.multiplicativeExpr(XPathReader.java:1039) [junit] at org.jaxen.saxpath.base.XPathReader.additiveExpr(XPathReader.java:982) [junit] at org.jaxen.saxpath.base.XPathReader.relationalExpr(XPathReader.java:902) [junit] at org.jaxen.saxpath.base.XPathReader.equalityExpr(XPathReader.java:850) [junit] at org.jaxen.saxpath.base.XPathReader.andExpr(XPathReader.java:826) [junit] at org.jaxen.saxpath.base.XPathReader.orExpr(XPathReader.java:804) [junit] at org.jaxen.saxpath.base.XPathReader.expr(XPathReader.java:797) [junit] at org.jaxen.saxpath.base.XPathReader.parse(XPathReader.java:105) [junit] at org.jaxen.BaseXPath.init(BaseXPath.java:126) [junit] at org.jaxen.BaseXPath.init(BaseXPath.java:152) [junit] at org.jaxen.dom4j.Dom4jXPath.init(Dom4jXPath.java:101) [junit] at org.apache.commons.jelly.expression.xpath.XPathExpression.evaluate(XPathExpression.java:78) [junit] at org.apache.commons.jelly.expression.ExpressionSupport.evaluateRecurse(ExpressionSupport.java:61) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:256) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] at junit.framework.TestCase.runBare(TestCase.java:127) [junit] at junit.framework.TestResult$1.protect(TestResult.java:106) [junit] at
DO NOT REPLY [Bug 33221] - [logging] null pointer exception in LogFactory.getLog
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33221. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33221 --- Additional Comments From [EMAIL PROTECTED] 2006-01-29 14:27 --- This was fixed by the patch for issue 31710. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
Thank you for this explanation. It is good to actually look at the code instead of making assumptions, which is what I have been doing. The JSSE's jar does not provide javax.net.ssl versions of the com.sun.net.ssl interfaces And, after doing a little research, I find that there are differences between JSSE 1.0.3 and the packages in JDK 1.4, such that there is no backward compatibility. Basically, JSSE 1.0.x is a prototype, a hack through which Sun worked out the bugs, culminating in the better implementation that they released in 1.4. They did not just move the JSSE.jar code into JDK 1.4. They also improved it. Since these are new classes for us, I think it makes little sense to tie into backward compatibility from the start, when that backward compatibility is already out of date. I don't think there is a clean way to have one code base that will work the way we'd like it for both cases. Therefore, I think the solution for this is for Jakarta Commons Net to take Rory Winston's suggestion and start a new branch of Commons Net for JDK 1.4 only (for this and other reasons) and maintain two branches for awhile, the current HEAD branch for 1.3 compatibility and the new branch for 1.4. The new branch can use the javax.ssl.net classes, the old one can use com.sun.net. Jose Juan Montiel wrote: Hi Steve, What I think you're missing is that if you put jsse.jar on your classpath, you can use javax.net.ssl with java 1.3. maybe i don't explain well, sorry. The three classes of com.sun.net.ssl that are used for implement FTPS (in the way that Paul did and I modified, maybe there is another...) are... com.sun.net.ssl.KeyManagerFactory (http://java.sun.com/products/jsse/doc/apidoc/com/sun/net/ssl/KeyManagerFactory.html) com.sun.net.ssl.SSLContext (http://java.sun.com/products/jsse/doc/apidoc/com/sun/net/ssl/SSLContext.html) com.sun.net.ssl.TrustManager (http://java.sun.com/products/jsse/doc/apidoc/com/sun/net/ssl/TrustManager.html) This classes in JSSE are only in the package com.sun.net.ssl, and although in JSSE 1.0.3 there are a packege javax.net.ssl, it doesn't contain this classes, it contains javax.net.ssl.SSLSocket, a classes soon used, to implement FTPS. And the commons-net team would prefer to go that way because Sun says that com.sun.net may go away with some future release, but not javax.net. Yes, this would be a small inconvenience for java 1.3 users, but the stability is worth it. This three classes in JDK 1.4.2, were move to javax.net.ssl.KeyManagerFactory (http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/KeyManagerFactory.html) javax.net.ssl.SSLContext (http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/SSLContext.html) javax.net.ssl.TrustManager (http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/TrustManager.html) But if you download for example JDK 1.4.2 and look inside of (jre/lib) you'll find jsse.jar, the jar where still are com.sun.net.ssl. Sun, still mantain compatiblity with JDK 1.3. And still in JDK 1.5, you'll find jre/lib/jsse.jar. But when jsse.jar desapear, i offer to modified code... In other way if use javax.net.ssl.KeyManagerFactory , javax.net.ssl.SSLContext, javax.net.ssl.TrustManager, ftps don't work under JDK 1.3. I hope explain better, this time. Then, make that you consider appropiate... Thanks all, for your time. -- The whole purpose of places like Starbucks is for people with no decision-making ability whatsoever to make six decisions just to buy one cup of coffee. Short, tall, light, dark, caf, decaf, low-fat, non-fat, etc. So people who don't know what the hell they're doing or who on earth they are can, for only $2.95, get not just a cup of coffee but an absolutely defining sense of self: Tall. Decaf. Cappuccino. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] documentation updates
Dennis Lundberg wrote: robert burrell donkin wrote: On Sun, 2006-01-22 at 09:59 +, robert burrell donkin wrote: snip i have to go out in about an hour (i've promised that i'll fix a mate's network and internet which he needs for university work next week). if you are around now, feel free to roll a RC1 release for public evaluation. otherwise, i'll cut one this afternoon (GMT) had a bit of a nightmare day today. to cut a long story short lost all my development time today. just don't ask how a 30 minute job ends up taking up 8 hours door-to-door :- so, i don't have that document in a coherent state yet :-( shall i start preparing to cut an RC1 now or does anyone have anything else they want to get in first? The only thing I have left on my list is the changes.xml document. However that is not a show stopper, it could even wait until the next release. Having had a go at a changes.xml file, using the resolved issues from Bugzilla, I realize that it will not make a good and useful document. I compared it to those from other commons components, and think that a changes.xml file really needs to be updated incrementally between two releases. So I will not be checking this in for the 1.1 release. snip -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r373312 - in /jakarta/commons/proper/logging/trunk: build.properties.sample build.xml
Author: dennisl
Date: Sun Jan 29 06:51:18 2006
New Revision: 373312
URL: http://svn.apache.org/viewcvs?rev=373312view=rev
Log:
Comment out some remains from the log4j 1.3 build. Add notes to put them back
again if/when the build uses log4j 1.3.
Modified:
jakarta/commons/proper/logging/trunk/build.properties.sample
jakarta/commons/proper/logging/trunk/build.xml
Modified: jakarta/commons/proper/logging/trunk/build.properties.sample
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/build.properties.sample?rev=373312r1=373311r2=373312view=diff
==
--- jakarta/commons/proper/logging/trunk/build.properties.sample (original)
+++ jakarta/commons/proper/logging/trunk/build.properties.sample Sun Jan 29
06:51:18 2006
@@ -16,7 +16,8 @@
log4j12.jar=lib/log4j-1.2.12.jar
# Apache Log4j 1.3.x series
-log4j13.jar=lib/log4j-1.3.0.jar
+# Note: Log4j 1.3 support not available in the 1.1 release
+#log4j13.jar=lib/log4j-1.3.0.jar
# logkit.jar - Avalon LogKit classes (see http://jakarta.apache.org/avalon)
logkit.jar=lib/logkit-1.0.1.jar
Modified: jakarta/commons/proper/logging/trunk/build.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/build.xml?rev=373312r1=373311r2=373312view=diff
==
--- jakarta/commons/proper/logging/trunk/build.xml (original)
+++ jakarta/commons/proper/logging/trunk/build.xml Sun Jan 29 06:51:18 2006
@@ -241,7 +241,8 @@
echo
Log4j12: ${log4j12.jar}
-Log4j13: ${log4j13.jar}
+!-- Note: log4j13 support is not available in the 1.1 release. --
+!--Log4j13: ${log4j13.jar}--
LogKit: ${logkit.jar}
Avalon-Framework: ${avalon-framework.jar}
/echo
@@ -290,10 +291,16 @@
/target
target name=log4j13-warning unless='log4j13.present'
depends='init,discovery'
+!--
+ - Note: log4j13 support is not available in the 1.1 release.
+ - If we add it in a future release, the code below should be uncommented.
+ --
+!--
echo
*** WARNING ***
Log4j 1.3 not found: Cannot Build Log4J13Logger
/echo
+--
/target
target name=logkit-warning unless='logkit.present'
depends='init,discovery'
@@ -333,7 +340,8 @@
target name=show-lib-presence
echo message=jdk.1.4.present=${jdk.1.4.present}/
echo message=log4j12.present=${log4j12.present}/
-echo message=log4j13.present=${log4j13.present}/
+!-- Note: log4j13 support is not available in the 1.1 release. --
+!--echo message=log4j13.present=${log4j13.present}/--
echo message=logkit.present=${logkit.present}/
echo message=avalon-framework.present=${avalon-framework.present}/
/target
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
Stevw
I think that's a great suggestion. It moves us forward without
necessarily sacrificing backwards compatability.
I have had a look at the classes written by Jose and Paul, and
incorporated them into my local branch copy. I had to make one minor
change to get them to work, but other than that they seem to work well.
I set up a test FTPS server using FileZilla on my local machine and
wrote some client code:
FtpsClient client = new FtpsClient();
client.connect(127.0.0.1);
client.addProtocolCommandListener(new
PrintCommandListener(new PrintWriter(System.out)));
client.login(user, pass);
client.cwd(test);
for (FTPFile file : client.listFiles()) {
System.out.println(file.getName());
}
OutputStream out = new FileOutputStream(c:\\temp\\test.war);
client.retrieveFile(test.war, out);
client.disconnect();
and it seems to work a treat. If we are agreed that we should go down
this parallel branch route, then I can move the JDK_1_4_BRANCH to
something more sensible (i.e. Daniel's suggestion a while back to make
the 1.4+ branch version 2), maybe NET_2_0_0. We can use the com.sun.*
stuff for the 1.3 branch (which will probably be our 1.5.0 release)?
Rory
Steve Cohen wrote:
Thank you for this explanation. It is good to actually look at the
code instead of making assumptions, which is what I have been doing.
The JSSE's jar does not provide javax.net.ssl versions of the
com.sun.net.ssl interfaces And, after doing a little research, I find
that there are differences between JSSE 1.0.3 and the packages in JDK
1.4, such that there is no backward compatibility. Basically, JSSE
1.0.x is a prototype, a hack through which Sun worked out the bugs,
culminating in the better implementation that they released in 1.4.
They did not just move the JSSE.jar code into JDK 1.4. They also
improved it.
Since these are new classes for us, I think it makes little sense to
tie into backward compatibility from the start, when that backward
compatibility is already out of date. I don't think there is a clean
way to have one code base that will work the way we'd like it for both
cases.
Therefore, I think the solution for this is for Jakarta Commons Net to
take Rory Winston's suggestion and start a new branch of Commons Net
for JDK 1.4 only (for this and other reasons) and maintain two
branches for awhile, the current HEAD branch for 1.3 compatibility and
the new branch for 1.4. The new branch can use the javax.ssl.net
classes, the old one can use com.sun.net.
Jose Juan Montiel wrote:
Hi Steve,
What I think you're missing is that if you put jsse.jar on your
classpath, you can use javax.net.ssl with java 1.3.
maybe i don't explain well, sorry.
The three classes of com.sun.net.ssl that are used for implement FTPS
(in the way that Paul did and I modified, maybe there is another...)
are...
com.sun.net.ssl.KeyManagerFactory
(http://java.sun.com/products/jsse/doc/apidoc/com/sun/net/ssl/KeyManagerFactory.html)
com.sun.net.ssl.SSLContext
(http://java.sun.com/products/jsse/doc/apidoc/com/sun/net/ssl/SSLContext.html)
com.sun.net.ssl.TrustManager
(http://java.sun.com/products/jsse/doc/apidoc/com/sun/net/ssl/TrustManager.html)
This classes in JSSE are only in the package com.sun.net.ssl, and
although in JSSE 1.0.3 there are a packege javax.net.ssl, it doesn't
contain this classes, it contains javax.net.ssl.SSLSocket, a classes
soon used, to implement FTPS.
And the commons-net team would prefer to go that way because Sun
says that
com.sun.net may go away with some future release, but not
javax.net. Yes, this
would be a small inconvenience for java 1.3 users, but the stability
is worth it.
This three classes in JDK 1.4.2, were move to
javax.net.ssl.KeyManagerFactory
(http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/KeyManagerFactory.html)
javax.net.ssl.SSLContext
(http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/SSLContext.html)
javax.net.ssl.TrustManager
(http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/TrustManager.html)
But if you download for example JDK 1.4.2 and look inside of (jre/lib)
you'll find jsse.jar, the jar where still are com.sun.net.ssl. Sun,
still mantain compatiblity with JDK 1.3.
And still in JDK 1.5, you'll find jre/lib/jsse.jar.
But when jsse.jar desapear, i offer to modified code...
In other way if use javax.net.ssl.KeyManagerFactory ,
javax.net.ssl.SSLContext, javax.net.ssl.TrustManager, ftps don't work
under JDK 1.3.
I hope explain better, this time.
Then, make that you consider appropiate...
Thanks all, for your time.
--
The whole purpose of places like Starbucks is
for people with no decision-making ability
whatsoever to make six decisions just to buy
one cup of coffee. Short, tall, light, dark, caf,
decaf, low-fat, non-fat, etc. So people who
don't
[VOTE] New Committer - Jörg Heinicke
I would like to nominate Jörg Heinicke [EMAIL PROTECTED] as an Apache Jakarta Commons Committer. Jörg has provided patches and has participated in discussions about [jci] and mainly [transaction]. Especially in the field of [transaction] he has shown deep insight and endurance. Additionally, it seems I am the only remaining active committer for [transaction] and could need some help and support. I thus think he would be very valuable as a committer. Oliver [ ] +1, let him commit! [ ] +0 [ ] -0 [ ] -1, no, because - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] New Committer - Jörg Heinicke
Ooops, forgot my own vote again: [x] +1, let him commit! Oliver 2006/1/29, Oliver Zeigermann [EMAIL PROTECTED]: I would like to nominate Jörg Heinicke [EMAIL PROTECTED] as an Apache Jakarta Commons Committer. Jörg has provided patches and has participated in discussions about [jci] and mainly [transaction]. Especially in the field of [transaction] he has shown deep insight and endurance. Additionally, it seems I am the only remaining active committer for [transaction] and could need some help and support. I thus think he would be very valuable as a committer. Oliver [ ] +1, let him commit! [ ] +0 [ ] -0 [ ] -1, no, because - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r373323 - in /jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/src/main/java/org/apache/commons/scxml: Observable.java model/History.java model/SCXML.java model/State.java model/Tran
Author: rahul
Date: Sun Jan 29 08:35:02 2006
New Revision: 373323
URL: http://svn.apache.org/viewcvs?rev=373323view=rev
Log:
Clean the Commons SCXML object model of any stateful properties.
* Remove last known configurations from History objects
* Remove NotificationRegistry and RootContext from SCXML objects
* Remove Context from State objects
* Remove NotificationRegistry from Transition objects
* Remove NotificationRegistry from TransitionTarget objects
Also remove the Observable interface. Implementing it ties the model elements
to a particular NotificationRegistry.
Removed:
jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/src/main/java/org/apache/commons/scxml/Observable.java
Modified:
jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/src/main/java/org/apache/commons/scxml/model/History.java
jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/src/main/java/org/apache/commons/scxml/model/SCXML.java
jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/src/main/java/org/apache/commons/scxml/model/State.java
jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/src/main/java/org/apache/commons/scxml/model/Transition.java
jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/src/main/java/org/apache/commons/scxml/model/TransitionTarget.java
Modified:
jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/src/main/java/org/apache/commons/scxml/model/History.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/src/main/java/org/apache/commons/scxml/model/History.java?rev=373323r1=373322r2=373323view=diff
==
---
jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/src/main/java/org/apache/commons/scxml/model/History.java
(original)
+++
jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/src/main/java/org/apache/commons/scxml/model/History.java
Sun Jan 29 08:35:02 2006
@@ -1,6 +1,6 @@
/*
*
- * Copyright 2005 The Apache Software Foundation.
+ * Copyright 2005-2006 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
@@ -17,9 +17,6 @@
*/
package org.apache.commons.scxml.model;
-import java.util.HashSet;
-import java.util.Set;
-
/**
* The class in this SCXML object model that corresponds to the
* lt;historygt; SCXML pseudo state element.
@@ -40,12 +37,6 @@
private Transition transition;
/**
- * The configuration when the parent of this pseudo state was last
- * exited.
- */
-private Set lastConfiguration;
-
-/**
* Default no-args constructor for XML Digester.
*/
public History() {
@@ -90,52 +81,6 @@
isDeep = true;
}
//shallow is by default
-}
-
-/**
- * Get the last configuration for this history.
- *
- * @return Returns the lastConfiguration.
- */
-public final Set getLastConfiguration() {
-return lastConfiguration;
-}
-
-/**
- * Set the last configuration for this history.
- *
- * @param lc The lastConfiguration to set.
- */
-public final void setLastConfiguration(final Set lc) {
-if (lastConfiguration == null) {
-lastConfiguration = new HashSet(lc.size());
-} else {
-lastConfiguration.clear();
-}
-lastConfiguration.addAll(lc);
-}
-
-/**
- * Check whether we have prior history.
- *
- * @return Whether we have a non-empty last configuration
- */
-public final boolean isEmpty() {
-if (lastConfiguration == null || lastConfiguration.isEmpty()) {
-return true;
-}
-return false;
-}
-
-/**
- * Resets the history state.
- *
- * @see org.apache.commons.scxml.SCXMLExecutor#reset()
- */
-public final void reset() {
-if (lastConfiguration != null) {
-lastConfiguration.clear();
-}
}
}
Modified:
jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/src/main/java/org/apache/commons/scxml/model/SCXML.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/src/main/java/org/apache/commons/scxml/model/SCXML.java?rev=373323r1=373322r2=373323view=diff
==
---
jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/src/main/java/org/apache/commons/scxml/model/SCXML.java
(original)
+++
jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/src/main/java/org/apache/commons/scxml/model/SCXML.java
Sun Jan 29 08:35:02 2006
@@ -1,6 +1,6 @@
/*
*
- * Copyright 2005 The Apache Software Foundation.
+ * Copyright 2005-2006 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance
svn commit: r373325 - /jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/src/main/java/org/apache/commons/scxml/io/SCXMLDigester.java
Author: rahul
Date: Sun Jan 29 08:48:35 2006
New Revision: 373325
URL: http://svn.apache.org/viewcvs?rev=373325view=rev
Log:
In a stateless model, the Context, Evaluator and NotificationRegistry have no
role to play in SCXML IO. Update the Digester to match the changes made to the
object model in r373323.
The imports for o.a.c.s.{Context,Evaluator,NotificationRegistry} are no longer
needed, which is a fair indication that we have the desired separation of
concerns.
Changes make BZ # 38275 ([scxml] More Explicit Instructions on
core-digester.html) mostly obsolete.
Modified:
jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/src/main/java/org/apache/commons/scxml/io/SCXMLDigester.java
Modified:
jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/src/main/java/org/apache/commons/scxml/io/SCXMLDigester.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/src/main/java/org/apache/commons/scxml/io/SCXMLDigester.java?rev=373325r1=373324r2=373325view=diff
==
---
jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/src/main/java/org/apache/commons/scxml/io/SCXMLDigester.java
(original)
+++
jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/src/main/java/org/apache/commons/scxml/io/SCXMLDigester.java
Sun Jan 29 08:48:35 2006
@@ -35,9 +35,6 @@
import org.apache.commons.digester.SetPropertiesRule;
import org.apache.commons.logging.LogFactory;
-import org.apache.commons.scxml.Context;
-import org.apache.commons.scxml.Evaluator;
-import org.apache.commons.scxml.NotificationRegistry;
import org.apache.commons.scxml.PathResolver;
import org.apache.commons.scxml.SCXMLHelper;
import org.apache.commons.scxml.env.URLResolver;
@@ -91,27 +88,17 @@
*top level document are to be resovled against this URL).
* @param errHandler
*The SAX ErrorHandler
- * @param evalCtx
- *the document-level variable context for guard condition
- *evaluation
- * @param evalEngine
- *the scripting/expression language engine for creating local
- *state-level variable contexts (if supported by a given
- *scripting engine)
*
* @return SCXML The SCXML object corresponding to the file argument
*
* @throws IOException Underlying Digester parsing threw an IOException
* @throws SAXException Underlying Digester parsing threw a SAXException
*
- * @see Context
* @see ErrorHandler
- * @see Evaluator
* @see PathResolver
*/
public static SCXML digest(final URL scxmlURL,
-final ErrorHandler errHandler, final Context evalCtx,
-final Evaluator evalEngine)
+final ErrorHandler errHandler)
throws IOException, SAXException {
SCXML scxml = null;
@@ -133,7 +120,7 @@
}
if (scxml != null) {
-updateSCXML(scxml, evalCtx, evalEngine);
+updateSCXML(scxml);
}
return scxml;
@@ -151,27 +138,17 @@
*SCXML document
* @param errHandler
*The SAX ErrorHandler
- * @param evalCtx
- *the document-level variable context for guard condition
- *evaluation
- * @param evalEngine
- *the scripting/expression language engine for creating local
- *state-level variable contexts (if supported by a given
- *scripting engine)
*
* @return SCXML The SCXML object corresponding to the file argument
*
* @throws IOException Underlying Digester parsing threw an IOException
* @throws SAXException Underlying Digester parsing threw a SAXException
*
- * @see Context
* @see ErrorHandler
- * @see Evaluator
* @see PathResolver
*/
public static SCXML digest(final String documentRealPath,
-final ErrorHandler errHandler, final Context evalCtx,
-final Evaluator evalEngine, final PathResolver pathResolver)
+final ErrorHandler errHandler, final PathResolver pathResolver)
throws IOException, SAXException {
SCXML scxml = null;
@@ -192,7 +169,7 @@
}
if (scxml != null) {
-updateSCXML(scxml, evalCtx, evalEngine);
+updateSCXML(scxml);
}
return scxml;
@@ -214,26 +191,16 @@
*The InputSource for the SCXML document
* @param errHandler
*The SAX ErrorHandler
- * @param evalCtx
- *the document-level variable context for guard condition
- *evaluation
- * @param evalEngine
- *the scripting/expression language engine for creating local
- *state-level variable contexts (if supported by a given
- *scripting engine)
*
* @return
Re: [logging] please check release candidate 1
On 1/24/06, robert burrell donkin [EMAIL PROTECTED] wrote: On Tue, 2006-01-24 at 22:35 +0100, Dennis Lundberg wrote: robert burrell donkin wrote: On Wed, 2006-01-25 at 09:35 +1300, Simon Kitching wrote: On Tue, 2006-01-24 at 18:39 +, robert burrell donkin wrote: On Tue, 2006-01-24 at 12:14 +1300, Simon Kitching wrote: Why is it necessary to use two different JVMs? need a 1.4 JVM to compile the java.util stuff but the rest of the code needs to run fine on earlier JVMs. javac settings will care of the differences in class formats but changes to the system libraries mean that you should compile against the 1.2 java system libraries. this can be done either by using a 1.2 JSDK or by using a later JSDK and setting bootclasspath appropriately. if we were confident that our unit tests had 100% code coverage then compiling with a 1.4 JSDK would probably be safe enough. i'm not that confident and every other JCL release i've cut has used 2 JSDKs. so, i'm more confident to use the system i know works. Ok, sounds entirely reasonable. I agree there are corner cases where target doesn't solve the problem (eg the new StringBuffer overloaded methods in more recent JVMs). It might be nice to note this somewhere, eg as a comment in the build.xml file or similar. the latest build.xml now supports dual compilation (1.2 and 1.4). the ant task should be run by a 1.2 JDK and a build.property set the a 1.4 compiler. there's some documentation but i hope to return to this later (unless anyone else beats me to it). i'm now trying to think about whether to add a task to build the source distributions. one advantage is that it would automatically standardise the EOLs. one disadvantage is that it would require using exec to call svn directly. another is that it should really be loaded from a tag which would mean another build property. Robert, why would you need to use svn? If you are adding this to easy the creating of RC:s and releases, then I would imagine that the release manager has already checked out the correct tag from svn. If that is the case then the source is already checked out as well, you just need to package it. it's best to export a fresh copy from the tag. a couple of reasons: 1 this ensures that no svn meta-data is present 2 it ensure that no temporary files used when building the release are left in the source distribution i'll probably just use svn, i think. svn export --native-eols=XXX should do the line ending conversions automatically. This is better, IMHO than applying conversion in scripts, since it will make the distros independent of the OS platform used to do the build. It would be nice if maven did this by default when creating source distros. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [wiki] Proposed changes
Sorry for the late response. I have had connectivity problems this week. My one comment is that most of the content described below belongs on the main commons web pages. Could be I am odd man out, in which case I will shut up and accept the chaos, but I don't think we should be using the Wiki for developer documentation, at least not as a permanent home for it. Phil On 1/24/06, Rahul Akolkar [EMAIL PROTECTED] wrote: I'm proposing to move some content around on the Commons wiki. Motivating factors are: * Discourage amorphous growth on one or two pages * Distribute content over already existing pages (some of which are mostly abandoned) * Reduce the number of orphaned pages, aim for better wiki navigation (... over time, not that I expect any of my changes to be revolutionary ;-) If you don't like one or more of the changes below, reply with a -1 underneath the change. I will make all changes that do *not* receive a -1 in a few days (Friday at the earliest). 1) Move articles and third party resources to this orphaned page: http://wiki.apache.org/jakarta-commons/ArticlesAndTutorials 2) Create a DeveloperDocumentation page and move the related links from the FrontPage to that one. 3) Create a menu/navigation bar on the top (currently it has three entries). More entries will wrap in your browser, depending on your resolution. 4) Lose the description for the links on top of the page, they should do OK without it as well, and add them to (3). For example: GettingInvolved has information for people interested in helping out with commons development. will just become a GettingInvolved link in the nav bar. 5) Add a FrequentlyAskedQuestions page for Commons as a whole (for generic questions such as which why does my maven site fail) Stephen- Can we post your Javapolis pdf on the wiki? I remember someone suggesting it. -Rahul - 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: [wiki] Proposed changes
On 1/29/06, Phil Steitz [EMAIL PROTECTED] wrote: Sorry for the late response. I have had connectivity problems this week. My one comment is that most of the content described below belongs on the main commons web pages. Could be I am odd man out, in which case I will shut up and accept the chaos, but I don't think we should be using the Wiki for developer documentation, at least not as a permanent home for it. snip/ I think this is probably orthogonal to tidying up the wiki per plan below, so I'll go ahead with that bit later today. IMO, the wiki is good as a staging area for developer documentation and if the Commons Manual or any of the other documents ever reach a website-worthy status, we can turn them into (non-wiki) web pages. -Rahul Phil On 1/24/06, Rahul Akolkar [EMAIL PROTECTED] wrote: I'm proposing to move some content around on the Commons wiki. Motivating factors are: * Discourage amorphous growth on one or two pages * Distribute content over already existing pages (some of which are mostly abandoned) * Reduce the number of orphaned pages, aim for better wiki navigation (... over time, not that I expect any of my changes to be revolutionary ;-) If you don't like one or more of the changes below, reply with a -1 underneath the change. I will make all changes that do *not* receive a -1 in a few days (Friday at the earliest). 1) Move articles and third party resources to this orphaned page: http://wiki.apache.org/jakarta-commons/ArticlesAndTutorials 2) Create a DeveloperDocumentation page and move the related links from the FrontPage to that one. 3) Create a menu/navigation bar on the top (currently it has three entries). More entries will wrap in your browser, depending on your resolution. 4) Lose the description for the links on top of the page, they should do OK without it as well, and add them to (3). For example: GettingInvolved has information for people interested in helping out with commons development. will just become a GettingInvolved link in the nav bar. 5) Add a FrequentlyAskedQuestions page for Commons as a whole (for generic questions such as which why does my maven site fail) Stephen- Can we post your Javapolis pdf on the wiki? I remember someone suggesting it. -Rahul snap/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] New Committer - Jörg Heinicke
[X] +1, let him commit! [ ] +0 [ ] -0 [ ] -1, no, because - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r373328 - in /jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/src/main/java/org/apache/commons/scxml: NotificationRegistry.java Registry.java SCXMLExecutor.java SCXMLSemantics.java
Author: rahul
Date: Sun Jan 29 09:39:39 2006
New Revision: 373328
URL: http://svn.apache.org/viewcvs?rev=373328view=rev
Log:
In a stateless model, the state of execution focuses around a registry
maintained by the SCXMLExecutor, which performs book-keeping functions
concerning a particular execution instance of the state machine.
The NotificationRegistry and SCXMLExecutor have to deal with the absence of the
Observable interface in the Commons SCXML object model, and therefore, what was
earlier effectively:
addListener(Observable, SCXMLListener)
now becomes (effectively):
* addListener(SCXML, SCXMLListener)
* addListener(TransitionTarget, SCXMLListener)
* addListener(Transition, SCXMLListener)
since listeners may be attached to
o.a.c.s.m.{SCXML,TransitionTarget,Transition} which are the interesting
elements for tracking execution.
Some qualifiers and access modifiers have been appropriately constrained in
this commit.
Added:
jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/src/main/java/org/apache/commons/scxml/Registry.java
(with props)
Modified:
jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/src/main/java/org/apache/commons/scxml/NotificationRegistry.java
jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/src/main/java/org/apache/commons/scxml/SCXMLExecutor.java
jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/src/main/java/org/apache/commons/scxml/SCXMLSemantics.java
jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/src/main/java/org/apache/commons/scxml/semantics/SCXMLSemanticsImpl.java
Modified:
jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/src/main/java/org/apache/commons/scxml/NotificationRegistry.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/src/main/java/org/apache/commons/scxml/NotificationRegistry.java?rev=373328r1=373327r2=373328view=diff
==
---
jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/src/main/java/org/apache/commons/scxml/NotificationRegistry.java
(original)
+++
jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/src/main/java/org/apache/commons/scxml/NotificationRegistry.java
Sun Jan 29 09:39:39 2006
@@ -1,6 +1,6 @@
/*
*
- * Copyright 2005 The Apache Software Foundation.
+ * Copyright 2005-2006 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
@@ -23,6 +23,7 @@
import java.util.Map;
import java.util.Set;
+import org.apache.commons.scxml.model.SCXML;
import org.apache.commons.scxml.model.Transition;
import org.apache.commons.scxml.model.TransitionTarget;
@@ -32,7 +33,7 @@
* all listeners of the events of interest.
*
*/
-public class NotificationRegistry {
+public final class NotificationRegistry {
/**
* The Map of all listeners keyed by Observable.
@@ -52,7 +53,7 @@
* @param source The observable this listener wants to listen to
* @param lst The listener
*/
-public final void addListener(final Observable source,
+void addListener(final Object source,
final SCXMLListener lst) {
Set entries = (Set) regs.get(source);
if (entries == null) {
@@ -68,7 +69,7 @@
* @param source The observable this listener wants to stop listening to
* @param lst The listener
*/
-public final void removeListener(final Observable source,
+void removeListener(final Object source,
final SCXMLListener lst) {
Set entries = (Set) regs.get(source);
if (entries != null) {
@@ -83,10 +84,36 @@
* Inform all relevant listeners that a TransitionTarget has been
* entered.
*
+ * @param observable The Observable
+ * @param state The TransitionTarget that was entered
+ */
+public void fireOnEntry(final TransitionTarget observable,
+final TransitionTarget state) {
+Object source = observable;
+fireOnEntry(source, state);
+}
+
+/**
+ * Inform all relevant listeners that a TransitionTarget has been
+ * entered.
+ *
+ * @param observable The Observable
+ * @param state The TransitionTarget that was entered
+ */
+public void fireOnEntry(final SCXML observable,
+final TransitionTarget state) {
+Object source = observable;
+fireOnEntry(source, state);
+}
+
+/**
+ * Inform all relevant listeners that a TransitionTarget has been
+ * entered.
+ *
* @param source The Observable
* @param state The TransitionTarget that was entered
*/
-public final void fireOnEntry(final Observable source,
+private void fireOnEntry(final Object source,
final TransitionTarget state) {
Set entries = (Set) regs.get(source);
if (entries != null) {
@@ -101,10 +128,36 @@
svn commit: r373329 - /jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/src/main/java/org/apache/commons/scxml/test/StandaloneUtils.java
Author: rahul
Date: Sun Jan 29 09:43:14 2006
New Revision: 373329
URL: http://svn.apache.org/viewcvs?rev=373329view=rev
Log:
Update command-line utility class to match changes to SCXML IO and execution.
Modified:
jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/src/main/java/org/apache/commons/scxml/test/StandaloneUtils.java
Modified:
jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/src/main/java/org/apache/commons/scxml/test/StandaloneUtils.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/src/main/java/org/apache/commons/scxml/test/StandaloneUtils.java?rev=373329r1=373328r2=373329view=diff
==
---
jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/src/main/java/org/apache/commons/scxml/test/StandaloneUtils.java
(original)
+++
jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/src/main/java/org/apache/commons/scxml/test/StandaloneUtils.java
Sun Jan 29 09:43:14 2006
@@ -77,8 +77,7 @@
Context rootCtx = evaluator.newContext(null);
EventDispatcher ed = new SimpleDispatcher();
Tracer trc = new Tracer();
-SCXML doc = SCXMLDigester.digest(new URL(documentURI), trc,
-rootCtx, evaluator);
+SCXML doc = SCXMLDigester.digest(new URL(documentURI), trc);
if (doc == null) {
System.err.println(The SCXML document + uri
+ can not be parsed!);
@@ -86,9 +85,11 @@
}
System.out.println(SCXMLSerializer.serialize(doc));
SCXMLExecutor exec = new SCXMLExecutor(evaluator, ed, trc);
-doc.addListener(trc);
+exec.addListener(doc, trc);
exec.setSuperStep(true);
+exec.setRootContext(rootCtx);
exec.setStateMachine(doc);
+exec.go();
BufferedReader br = new BufferedReader(new
InputStreamReader(System.in));
String event = null;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r373330 - /jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/src/test/java/org/apache/commons/scxml/SCXMLTestHelper.java
Author: rahul
Date: Sun Jan 29 09:45:28 2006
New Revision: 373330
URL: http://svn.apache.org/viewcvs?rev=373330view=rev
Log:
Update the testing helper class to match changes to SCXML IO and execution.
Modified:
jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/src/test/java/org/apache/commons/scxml/SCXMLTestHelper.java
Modified:
jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/src/test/java/org/apache/commons/scxml/SCXMLTestHelper.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/src/test/java/org/apache/commons/scxml/SCXMLTestHelper.java?rev=373330r1=373329r2=373330view=diff
==
---
jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/src/test/java/org/apache/commons/scxml/SCXMLTestHelper.java
(original)
+++
jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/src/test/java/org/apache/commons/scxml/SCXMLTestHelper.java
Sun Jan 29 09:45:28 2006
@@ -19,10 +19,10 @@
import junit.framework.Assert;
-import org.apache.commons.scxml.env.jsp.ELEvaluator;
-import org.apache.commons.scxml.env.jsp.ELContext;
import org.apache.commons.scxml.env.SimpleDispatcher;
import org.apache.commons.scxml.env.Tracer;
+import org.apache.commons.scxml.env.jexl.JexlContext;
+import org.apache.commons.scxml.env.jexl.JexlEvaluator;
import org.apache.commons.scxml.io.SCXMLDigester;
import org.apache.commons.scxml.model.SCXML;
@@ -33,25 +33,15 @@
public class SCXMLTestHelper {
public static SCXML digest(final URL url) {
-Evaluator evaluator = new ELEvaluator();
-Context ctx = new ELContext();
-return digest(url, null, ctx, evaluator);
+return digest(url, null);
}
-public static SCXML digest(final URL url, final Context ctx,
-final Evaluator evaluator) {
-return digest(url, null, ctx, evaluator);
-}
-
-public static SCXML digest(final URL url, final ErrorHandler errHandler,
-final Context ctx, final Evaluator evaluator) {
+public static SCXML digest(final URL url, final ErrorHandler errHandler) {
Assert.assertNotNull(url);
-Assert.assertNotNull(ctx);
// SAX ErrorHandler may be null
-Assert.assertNotNull(evaluator);
SCXML scxml = null;
try {
-scxml = SCXMLDigester.digest(url, errHandler, ctx, evaluator);
+scxml = SCXMLDigester.digest(url, errHandler);
} catch (Exception e) {
Assert.fail(e.getMessage());
}
@@ -60,43 +50,54 @@
}
public static SCXMLExecutor getExecutor(final URL url) {
-Evaluator evaluator = new ELEvaluator();
-Context ctx = new ELContext();
-SCXML scxml = digest(url, null, ctx, evaluator);
+SCXML scxml = digest(url, null);
+Evaluator evaluator = new JexlEvaluator();
return getExecutor(evaluator, scxml);
}
-public static SCXMLExecutor getExecutor(final URL url, final Context ctx,
+public static SCXMLExecutor getExecutor(final URL url,
final Evaluator evaluator) {
-SCXML scxml = digest(url, null, ctx, evaluator);
+SCXML scxml = digest(url, null);
return getExecutor(evaluator, scxml);
}
public static SCXMLExecutor getExecutor(final URL url,
-final ErrorHandler errHandler,final Context ctx,
-final Evaluator evaluator) {
-SCXML scxml = digest(url, errHandler, ctx, evaluator);
+final ErrorHandler errHandler) {
+SCXML scxml = digest(url, errHandler);
+Evaluator evaluator = new JexlEvaluator();
return getExecutor(evaluator, scxml);
}
public static SCXMLExecutor getExecutor(Evaluator evaluator, SCXML scxml) {
EventDispatcher ed = new SimpleDispatcher();
Tracer trc = new Tracer();
-return getExecutor(evaluator, scxml, ed, trc);
+Context context = new JexlContext();
+return getExecutor(context, evaluator, scxml, ed, trc);
+}
+
+public static SCXMLExecutor getExecutor(final URL url, final Context ctx,
+final Evaluator evaluator) {
+SCXML scxml = digest(url, null);
+EventDispatcher ed = new SimpleDispatcher();
+Tracer trc = new Tracer();
+return getExecutor(ctx, evaluator, scxml, ed, trc);
}
-public static SCXMLExecutor getExecutor(Evaluator evaluator, SCXML scxml,
-EventDispatcher ed, Tracer trc) {
+public static SCXMLExecutor getExecutor(Context context,
+Evaluator evaluator, SCXML scxml, EventDispatcher ed, Tracer trc) {
Assert.assertNotNull(evaluator);
+Assert.assertNotNull(context);
Assert.assertNotNull(scxml);
Assert.assertNotNull(ed);
Assert.assertNotNull(trc);
SCXMLExecutor exec = null;
try {
exec = new SCXMLExecutor(evaluator, ed, trc);
-
svn commit: r373331 - /jakarta/commons/sandbox/scxml/trunk/project.xml
Author: rahul Date: Sun Jan 29 09:48:38 2006 New Revision: 373331 URL: http://svn.apache.org/viewcvs?rev=373331view=rev Log: Start publishing checkstyle reports, we will always strive to keep genuine checkstyle complaints to zero, as it is today. Modified: jakarta/commons/sandbox/scxml/trunk/project.xml Modified: jakarta/commons/sandbox/scxml/trunk/project.xml URL: http://svn.apache.org/viewcvs/jakarta/commons/sandbox/scxml/trunk/project.xml?rev=373331r1=373330r2=373331view=diff == --- jakarta/commons/sandbox/scxml/trunk/project.xml (original) +++ jakarta/commons/sandbox/scxml/trunk/project.xml Sun Jan 29 09:48:38 2006 @@ -225,7 +225,7 @@ reports !--reportmaven-changelog-plugin/report-- reportmaven-changes-plugin/report - !--reportmaven-checkstyle-plugin/report-- + reportmaven-checkstyle-plugin/report !--reportmaven-clover-plugin/report-- !--reportmaven-developer-activity-plugin/report-- !--reportmaven-file-activity-plugin/report-- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r373332 - /jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/project.xml
Author: rahul Date: Sun Jan 29 09:51:10 2006 New Revision: 373332 URL: http://svn.apache.org/viewcvs?rev=373332view=rev Log: Same change as trunk. Modified: jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/project.xml Modified: jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/project.xml URL: http://svn.apache.org/viewcvs/jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/project.xml?rev=373332r1=373331r2=373332view=diff == --- jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/project.xml (original) +++ jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/project.xml Sun Jan 29 09:51:10 2006 @@ -225,7 +225,7 @@ reports !--reportmaven-changelog-plugin/report-- reportmaven-changes-plugin/report - !--reportmaven-checkstyle-plugin/report-- + reportmaven-checkstyle-plugin/report !--reportmaven-clover-plugin/report-- !--reportmaven-developer-activity-plugin/report-- !--reportmaven-file-activity-plugin/report-- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r373334 - in /jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/xdocs/api-notes: core-digester.xml core-engine.xml
Author: rahul
Date: Sun Jan 29 10:18:03 2006
New Revision: 373334
URL: http://svn.apache.org/viewcvs?rev=373334view=rev
Log:
Update API docs to match changes to the branch.
Modified:
jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/xdocs/api-notes/core-digester.xml
jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/xdocs/api-notes/core-engine.xml
Modified:
jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/xdocs/api-notes/core-digester.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/xdocs/api-notes/core-digester.xml?rev=373334r1=37r2=373334view=diff
==
---
jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/xdocs/api-notes/core-digester.xml
(original)
+++
jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/xdocs/api-notes/core-digester.xml
Sun Jan 29 10:18:03 2006
@@ -37,8 +37,6 @@
pre
//import java.io.IOException;
//import java.net.URL;
-//import org.apache.commons.scxml.Context;
-//import org.apache.commons.scxml.Evaluator;
//import org.apache.commons.scxml.io.SCXMLDigester;
//import org.apache.commons.scxml.model.SCXML;
//import org.xml.sax.ErrorHandler;
@@ -47,8 +45,7 @@
SCXML scxml = null;
try {
- scxml = SCXMLDigester.digest(lt;URLgt;, lt;ErroHandlergt;,
-lt;Contextgt;, lt;Evaluatorgt;);
+ scxml = SCXMLDigester.digest(lt;URLgt;, lt;ErroHandlergt;);
} catch (IOException ioe) {
// IOException while parsing
} catch (SAXException se) {
@@ -68,19 +65,15 @@
attributes of codeState/code SCXML elements./p
pCommons SCXML provides convenience implementations of most of the
- interfaces such as codeErrorHandler/code. The SCXML specification
- allows implementations to support multiple expression languages so SCXML
- documents can be used in varying environments. The codeContext/code
- and codeEvaluator/code interfaces serve as adapters to the
- particular expression language APIs. Commons SCXML currently supports
- JEXL and JSP 2.0 EL expressions./p
+ interfaces such as codeErrorHandler/code./p
- pThe SCXMLDigester exposes another convenience method which can handle
+ pThe SCXMLDigester exposes other convenience methods which can handle
a SCXML document specified using its quot;real pathquot; on the local
system, in which case an additional
codeorg.apache.commons.SCXML.PathResolver/codeparameter needs to be
- supplied for resolving relative document references. A serialization
- method is also available, primarily for debugging./p
+ supplied for resolving relative document references or as an
+ codeInputSource/code, in which case there is no path resolution,
+ so the document must be a standalone document./p
pThe codeSCXMLDigester/code Javadoc is available
a href=../apidocs/org/apache/commons/scxml/SCXMLDigester.html
Modified:
jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/xdocs/api-notes/core-engine.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/xdocs/api-notes/core-engine.xml?rev=373334r1=37r2=373334view=diff
==
---
jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/xdocs/api-notes/core-engine.xml
(original)
+++
jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/xdocs/api-notes/core-engine.xml
Sun Jan 29 10:18:03 2006
@@ -36,10 +36,11 @@
subsection name=Usage
pThe codeSCXMLExecutor/code is usually initialized as follows:/p
pre
-//import org.apache.commons.scxml.SCXMLExecutor;
+//import org.apache.commons.scxml.Context;
+//import org.apache.commons.scxml.ErrorReporter;
//import org.apache.commons.scxml.Evaluator;
//import org.apache.commons.scxml.EventDispatcher;
-//import org.apache.commons.scxml.ErrorReporter;
+//import org.apache.commons.scxml.SCXMLExecutor;
//import org.apache.commons.scxml.SCXMLListener;
//import org.apache.commons.scxml.model.SCXML;
//import org.apache.commons.scxml.model.ModelException;
@@ -48,11 +49,13 @@
try {
exec = new SCXMLExecutor(lt;Evaluatorgt;,
lt;EventDispatchergt;, lt;ErrorReportergt;);
-scxml.addListener(lt;SCXMLListenergt;);
-exec.setSuperStep(true);
exec.setStateMachine(lt;SCXMLgt;);
+exec.addListener(lt;SCXMLgt;, lt;SCXMLListenergt;);
+exec.setRootContext(lt;Contextgt;);
+exec.setSuperStep(true);
+exec.go();
} catch (ModelException me) {
- // Executor initialization failed, because the
+// Executor initialization failed, because
[collections] New utility methods for CollectionUtils ListUtils
I'm new to the commons-dev list, but I've participated a bit in the MyFaces list and, a while ago, in the Struts list. I have several methods that I think would make good additions to the Commons Collections CollectionUtils and ListUtils classes, and I wanted to find out: 1. Whether there was interest in them; 2. If so, how I go about submitting a patch. The proposed CollectionUtils method is currently called cloneCollection, but could be called deepClone. It takes any Collection as a parameter, and attempts to create a clone of it and every object contained within it. It tries a couple of different processes to do this, starting with using reflection to find the objects' clone method; if they don't have such a method but are Serializable, it uses Commons Lang SerializationUtils' clone method to clone them. If it can't do that, either, it will just copy by reference. It will recursively iterate through any sub-Collections as well, meaning that circular references will cause it to generate a stack overflow. I've found it to be very useful. The main proposed ListUtils method is simply called move, and takes a List, an index, and a distance as parameters. It will move the element in the List at the specified index the specified distance, which can either be positive or negative. It will wrap around, so that, in a List of length three (say), moving an element a distance of -2 would have the same effect as moving it 1. It will throw IndexOutOfBoundsException, as you'd expect, if the specified index is out of range. I have another proposed ListUtils method, called removeNulls, which as you'd expect simply removes nulls from a list. If there's interest, please let me know, and if someone who knows more than I do about the process could also please let me know what the best way is to submit a patch. Thanks! -Matt
svn commit: r373335 - /jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/BRANCHINFO.txt
Author: rahul Date: Sun Jan 29 10:34:40 2006 New Revision: 373335 URL: http://svn.apache.org/viewcvs?rev=373335view=rev Log: Update branch status, bulk of the work should be done here. Modified: jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/BRANCHINFO.txt Modified: jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/BRANCHINFO.txt URL: http://svn.apache.org/viewcvs/jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/BRANCHINFO.txt?rev=373335r1=373334r2=373335view=diff == --- jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/BRANCHINFO.txt (original) +++ jakarta/commons/sandbox/scxml/branches/STATELESS_MODEL/BRANCHINFO.txt Sun Jan 29 10:34:40 2006 @@ -24,7 +24,9 @@ -- STATUS -- -Under active development. +The chosen approach discussed below has been implemented, and lightly +tested. I expect the bulk of the work to be done. Pending a few days for +comments, it will be ported back to trunk. -- DETAILS -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38311] - [scxml] explore strategies for decoupling execution context from representation
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38311. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38311 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2006-01-29 19:48 --- Thanks for highlighting the issue. A proposed solution is available in the STATELESS_MODEL branch. Comments welcome. If there are no comments in a few days, I intend to merge changes to trunk. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] New Committer - Jörg Heinicke
+1 Oliver Zeigermann wrote: I would like to nominate Jörg Heinicke [EMAIL PROTECTED] as an Apache Jakarta Commons Committer. Jörg has provided patches and has participated in discussions about [jci] and mainly [transaction]. Especially in the field of [transaction] he has shown deep insight and endurance. Additionally, it seems I am the only remaining active committer for [transaction] and could need some help and support. I thus think he would be very valuable as a committer. Oliver [ ] +1, let him commit! [ ] +0 [ ] -0 [ ] -1, no, because - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r373337 - /jakarta/commons/sandbox/scxml/branches/BETWIXT_IO/
Author: rahul Date: Sun Jan 29 11:03:19 2006 New Revision: 373337 URL: http://svn.apache.org/viewcvs?rev=373337view=rev Log: New branch for setting up betwixt to do the SCXML IO for Commons SCXML Added: jakarta/commons/sandbox/scxml/branches/BETWIXT_IO/ - copied from r373336, jakarta/commons/sandbox/scxml/trunk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] New Committer - Jörg Heinicke
Hi! Additionally, it seems I am the only remaining active committer for [transaction] and could need some help and support. I know exactly what you mean ;-) [X] +1, let him commit! [ ] +0 [ ] -0 [ ] -1, no, because Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r373338 - /jakarta/commons/sandbox/scxml/branches/BETWIXT_IO/BRANCHINFO.txt
Author: rahul Date: Sun Jan 29 11:12:08 2006 New Revision: 373338 URL: http://svn.apache.org/viewcvs?rev=373338view=rev Log: The obligatory BRANCHINFO.txt Commons SCXML tradition. Added: jakarta/commons/sandbox/scxml/branches/BETWIXT_IO/BRANCHINFO.txt (with props) Added: jakarta/commons/sandbox/scxml/branches/BETWIXT_IO/BRANCHINFO.txt URL: http://svn.apache.org/viewcvs/jakarta/commons/sandbox/scxml/branches/BETWIXT_IO/BRANCHINFO.txt?rev=373338view=auto == --- jakarta/commons/sandbox/scxml/branches/BETWIXT_IO/BRANCHINFO.txt (added) +++ jakarta/commons/sandbox/scxml/branches/BETWIXT_IO/BRANCHINFO.txt Sun Jan 29 11:12:08 2006 @@ -0,0 +1,62 @@ +!-- + Copyright 2006 The Apache Software Foundation + + Licensed under the Apache License, Version 2.0 (the License); + you may not use this file except in compliance with the License. + You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an AS IS BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. +-- +$Id$ + + COMMONS SCXML + BETWIXT_IO BRANCH + +-- PURPOSE -- + +To set up the Commons SCXML IO using betwixt. + +-- STATUS -- + +Under active development. + +-- DETAILS -- + +Tim O'Brien suggested on the commons-dev mailing list that Commons SCXML +might be better served using betwixt rather than raw digester. + +TIM-QUOTE + +1. SCXMLSerializer + +Right now the code to serialize an SCXML object is a Visitor pattern +that constructs XML using a series of StringBuffers. The code to read +this XML document alrady uses a straightforward set of Digester rules +and the project already depends on commons-digester. + +*Alternative: Add a dependency to commons-betwixt, map the model package +to XML. Instead of writing Digester rules for reading and constructing +Strings for writing, use the betwixt mapping files as a single point of +translation. + +The current SCXMLDigester isn't trivial by any means, but I think it would +be easy to implement the external source rule. The current SCXMLDigester +plays two roles, first it sets up the Digester rules and Digests the XML, +but it also does a bit of post-processing in updateSCXML. I think the +component would be well served to separate everything that has to do with +serialization to/from XML into a separate package and to move some of this +postProcess that happens in updateSCXML somewhere else. + + +/TIM-QUOTE + + -- CHOSEN APPROACH -- + +Let us attempt to set up a betwixt mapping for Commons SCXML IO. + Propchange: jakarta/commons/sandbox/scxml/branches/BETWIXT_IO/BRANCHINFO.txt -- svn:eol-style = native Propchange: jakarta/commons/sandbox/scxml/branches/BETWIXT_IO/BRANCHINFO.txt -- svn:keywords = Date Author Id Revision HeadURL - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r373340 - /jakarta/commons/sandbox/scxml/tags/PRE_BRANCHING/
Author: rahul Date: Sun Jan 29 11:23:20 2006 New Revision: 373340 URL: http://svn.apache.org/viewcvs?rev=373340view=rev Log: Tag the pristine trunk, before we start merging any content from the branches Added: jakarta/commons/sandbox/scxml/tags/PRE_BRANCHING/ - copied from r373339, jakarta/commons/sandbox/scxml/trunk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38117] - [configuration] XMLConfiguration contructor not loading the resource
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38117. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38117 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |NEEDINFO --- Additional Comments From [EMAIL PROTECTED] 2006-01-29 20:23 --- Does the problem still persist, even with the newest version of Commons Configuration? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] New Committer - Jörg Heinicke
On Sun, 2006-01-29 at 17:14 +0100, Oliver Zeigermann wrote: [X] +1, let him commit! [ ] +0 [ ] -0 [ ] -1, no, because - - robert signature.asc Description: This is a digitally signed message part
svn commit: r373345 - /jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/FTPClient.java
Author: dfs
Date: Sun Jan 29 12:12:22 2006
New Revision: 373345
URL: http://svn.apache.org/viewcvs?rev=373345view=rev
Log:
Simplified try/catch/rethrow to try/finally in _openDataConnection_
Modified:
jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/FTPClient.java
Modified:
jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/FTPClient.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/FTPClient.java?rev=373345r1=373344r2=373345view=diff
==
---
jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/FTPClient.java
(original)
+++
jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/FTPClient.java
Sun Jan 29 12:12:22 2006
@@ -500,12 +500,10 @@
if (__dataTimeout = 0)
server.setSoTimeout(__dataTimeout);
try {
- socket = server.accept();
- } catch (IOException ioe) {
- server.close();
- throw ioe;
- }
-server.close();
+socket = server.accept();
+} finally {
+server.close();
+}
}
else
{ // We must be in PASSIVE_LOCAL_DATA_CONNECTION_MODE
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r373349 - in /jakarta/commons/sandbox/id/trunk/src: java/org/apache/commons/id/CompositeIdentifierGenerator.java test/org/apache/commons/id/CompositeIdentifierGeneratorTest.java
Author: psteitz
Date: Sun Jan 29 12:16:37 2006
New Revision: 373349
URL: http://svn.apache.org/viewcvs?rev=373349view=rev
Log:
Added CompositeIdentifierGenerator.
Added:
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/CompositeIdentifierGenerator.java
jakarta/commons/sandbox/id/trunk/src/test/org/apache/commons/id/CompositeIdentifierGeneratorTest.java
Added:
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/CompositeIdentifierGenerator.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/CompositeIdentifierGenerator.java?rev=373349view=auto
==
---
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/CompositeIdentifierGenerator.java
(added)
+++
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/CompositeIdentifierGenerator.java
Sun Jan 29 12:16:37 2006
@@ -0,0 +1,140 @@
+/*
+ * Copyright 2006 The Apache Software Foundation
+ *
+ * Licensed under the Apache License, Version 2.0 (the License);
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.id;
+
+import java.util.Collection;
+import java.util.Iterator;
+
+/**
+ * Identifier generator that concatenates the results of a list of string
+ * identifier generators.
+ *
+ * @since 1.0
+ * @version $Revision$ $Date$
+ *
+ */
+public class CompositeIdentifierGenerator extends
AbstractStringIdentifierGenerator {
+
+/** The identifier generators to concatenate */
+private final StringIdentifierGenerator[] identifierGenerators;
+
+/**
+ * Factory method to create a new codeCompositeIdentifierGenerator/code
+ * from an input array of codeStringIdentifierGenerator/code instances.
+ * p
+ * The input array is (shallow) copied - i.e., the object references in the
+ * input array are copied into a new array used internally. The array is
+ * expected to be non-empty and not to contain nulls.
+ *
+ * @param generators the identifiers to concatenate, copied by reference
+ * @return the composite identifier generator
+ * @throws IllegalArgumentException if the generators array is null
+ * @throws IllegalArgumentException if any generator in the array is null
+ */
+public static StringIdentifierGenerator getInstance(
+StringIdentifierGenerator[] generators) {
+if (generators == null) {
+throw new IllegalArgumentException(
+Generator array must not be null);
+}
+if (generators.length == 0) {
+throw new IllegalArgumentException(
+Generator array must not be empty);
+}
+StringIdentifierGenerator[] generatorsCopy =
+new StringIdentifierGenerator[generators.length];
+for (int i = 0; i generators.length; i++) {
+if (generators[i] == null) {
+throw new IllegalArgumentException(
+Generators must not be null);
+}
+generatorsCopy[i] = generators[i];
+}
+return new CompositeIdentifierGenerator(generatorsCopy);
+}
+
+/**
+ * Create a new codeCompositeIdentifierGenerator/code that concatenates
+ * the results of the provided collection of generators. Order is
+ * determined by the codeiterator()/code method on the collection.
+ *
+ * @param generators a collection of string identifier generators to
+ * concatenate
+ * @return the composite identifier generator
+ * @throws IllegalArgumentException if the generators collection is null,
+ * empty, or contains nulls
+ */
+public static StringIdentifierGenerator getInstance(Collection generators)
{
+if (generators == null) {
+throw new IllegalArgumentException(
+Generator collection must not be null);
+}
+if (generators.size() == 0) {
+throw new IllegalArgumentException(
+Generator collection must not be empty);
+}
+StringIdentifierGenerator[] generatorsCopy =
+new StringIdentifierGenerator[generators.size()];
+int i = 0;
+Iterator it = generators.iterator();
+while (it.hasNext()) {
+generatorsCopy[i] = (StringIdentifierGenerator) it.next();
+if (generatorsCopy[i] == null) {
+throw new IllegalArgumentException(
+
Re: svn commit: r373207 - /jakarta/commons/proper/net/branches/JDK_1_4_BRANCH/src/java/org/apache/commons/net/ftp/parser/RegexFTPFileEntryParserImpl.java
In message [EMAIL PROTECTED], [EMAIL PROTECTED] g writes: ... URL: http://svn.apache.org/viewcvs?rev=373207view=rev Log: Changed to JD 1.4 regex package ... +import java.util.regex.MatchResult; There is no MatchResult interface in JDK 1.4. It was added in JDK 1.5. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[id] Composite identifiers
I just committed a first cut at a CompositeIdentifierGenerator along the lines of what we have discussed. To replace the prefix generators with this, we either have to modify the factories or introduce a ConstantIdentifierGenerator. If others (Michael?) have better / different ideas on how to handle this, I am happy to review patches or replace this implementation. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r373242 - /jakarta/commons/proper/net/branches/JDK_1_4_BRANCH/src/java/org/apache/commons/net/ftp/FTP.java
In message [EMAIL PROTECTED], [EMAIL PROTECTED] g writes: Removed dependency on TelnetClient ... -public class FTP extends TelnetClient +public class FTP extends SocketClient From RFC 959: control connection The communication path between the USER-PI and SERVER-PI for the exchange of commands and replies. This connection follows the Telnet Protocol. You can't remove the dependency on TelnetClient without implementing the subset of telnet used by the FTP connection. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta-commons Wiki] Update of id/1.0ReleasePlan by PhilSteitz
Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta-commons Wiki for change notification. The following page has been changed by PhilSteitz: http://wiki.apache.org/jakarta-commons/id/1%2e0ReleasePlan The comment on the change is: Add reminder to fix checkstyle.xml -- Most of the generator implementations could be made serializable without any problem. Serialization should be ensured by appropriate unit tests though. The serializable implementation should also support a serialVersionUID. We might either use just 1L or the date we added this UID in form of MMDDL. Setup test code to ensure binary compatibility with future versions. * Clean-up exception handling Some methods have currently signatures for exceptions they do not throw. Some code throws a simple RuntimeException instead of introducing a derived exception for the commons-id components. A lot of internally runtime exceptions are not mentioned in the javadoc. - * Improve test path coverage and fix remaining style issues + * Improve test path coverage and fix remaining style issues (decide what we care about and fix Checkstyle.xml to ignore things we dont care about) * Unify initialization of unit tests (./) A lot of unit tests use a suite method, have a constructor to parametrise the name and have a main method. All of this is normally not necessary in modern IDEs. In Eclipse this is even worse, since you cannot click on the run tests to switch to the test's source. * Check year of copyright in touched files - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r373243 - /jakarta/commons/proper/net/branches/JDK_1_4_BRANCH/src/java/org/apache/commons/net/SocketClient.java
In message [EMAIL PROTECTED], [EMAIL PROTECTED]
g writes:
Added getter/setter for Input/OutputStream
+ public InputStream getInputStream() {
+ return _input_;
+ }
I really don't think these should be public. Otherwise, one might as well
work directly with the Socket class. Callers of SocketClient
implementations shouldn't be able to mess directly with the input and
output streams unless the specific implementation chooses to permit
it (e.g., SMTPClient.sendMessageData). Even in those cases, the streams
are usually wrapped by other i/o classes. To access the streams directly
will bypass the wrappers. I think the methods should be protected,
but since the members are already protected, I don't think there's a
reason to have the methods. At least that's the explanation for why those
methods didn't exist.
As an unrelated side note, the primary motivator for SocketClient was the
lack of support for connection-specific socket factories in JDK 1.1. The
secondary motivator was to put common client operations in one class and
establish a library-wide convention for using clients (e.g., connect,
disconnect) instead of reimplementing them in each class. Now that
there are socket factories in javax.net, there's probably no longer a
need for SocketFactory, but there's probably still a need for SocketClient.
Unfortunately, the NIO stuff doesn't appear to support hooks for
socket factories, so I'm afraid there will have to be some awkwardness
in supporting selectable i/o with SocketChannel and pluggable socket
implementations.
daniel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] JDK 1.4+ Branch?
In message [EMAIL PROTECTED], Rory Winston writes: I think that this might be a good point to consider introducing a version of Commons-Net that uses JDK 1.4+ as a baseline. My reasoning is I've long advocated branching to take advantage of JDK 1.4, but I had a more radical agenda. I believe the underpinnings of Commons Net need to be redesigned without being afraid to break compatibility. My suggestion was for this new Commons Net 2.0 to be in a new package: org.apache.commons.net2. At the time, the incremental evolution path was preferred. * We could remove the (oro) jar dependency; I think that's a side-effect of moving to JDK 1.4, not a reason in and of itself for JDK 1.4. There are no benefits to java.util.regex over oro in the context used by Commons Net. * It could be a good opportunity to clean up the threading code and socket handling, and make use of NIO; I believe that's the main reason to make the move. Of course, JDK-1.3-compatible releases could still continue on HEAD, or we could move the 1.4+ branch to HEAD and the 1.3 code to a maintenance branch. Assuming we're talking about continuing incremental evolution, I believe we should cut a 1.4.2 release with all the current bug fixes included and branch from there. JDK 1.3 would be supported in maintenance releases based off of 1.4.2 (e.g., 1.4.3, 1.4.4, etc.) that would only include bug fixes. New development based on JDK 1.4 would continue on the main trunk. Taking the FTPS code contribution into account, I'd change that to releasing a 1.4.2, then incorporating the FTPS code in a 1.5 release compatible with JDK 1.3, and branching from there as per the original scenario. The only situation in which I'd suggest doing it differently is if someone was really itching to write NIO or other JDK 1.4 stuff in the near term, in which case I think we'd have to let that happen on a separate branch until the FTPS code was incorporated into the trunk. Then after the 1.5 release off of the trunk, we'd merge changes from the JDK 1.4 branch into the main trunk and only do JDK 1.3 releases off of the 1.5 tree. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
I'm living in the timewarp of digest mode subscription, so please forgive me for having made obsoleted comments. In message [EMAIL PROTECTED], Rory Winston writes: I think that's a great suggestion. It moves us forward without necessarily sacrificing backwards compatability. ... Steve Cohen wrote: Thank you for this explanation. It is good to actually look at the code instead of making assumptions, which is what I have been doing. ... Therefore, I think the solution for this is for Jakarta Commons Net to take Rory Winston's suggestion and start a new branch of Commons Net for JDK 1.4 only (for this and other reasons) and maintain two branches for awhile, the current HEAD branch for 1.3 compatibility and the new branch for 1.4. The new branch can use the javax.ssl.net classes, the old one can use com.sun.net. +1 Since we're going to branch anyway and in light of Steve's discoveries about JSSE 1.0.3, this seems like the easiest way to handle the situation. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
Daniel F. Savarese wrote: I'm living in the timewarp of digest mode subscription, so please forgive me for having made obsoleted comments. In message [EMAIL PROTECTED], Rory Winston writes: I think that's a great suggestion. It moves us forward without necessarily sacrificing backwards compatability. ... Steve Cohen wrote: Thank you for this explanation. It is good to actually look at the code instead of making assumptions, which is what I have been doing. ... Therefore, I think the solution for this is for Jakarta Commons Net to take Rory Winston's suggestion and start a new branch of Commons Net for JDK 1.4 only (for this and other reasons) and maintain two branches for awhile, the current HEAD branch for 1.3 compatibility and the new branch for 1.4. The new branch can use the javax.ssl.net classes, the old one can use com.sun.net. +1 Since we're going to branch anyway and in light of Steve's discoveries about JSSE 1.0.3, this seems like the easiest way to handle the situation. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Daniel, before we vote, I think we need a formal motion to vote on, especially in light of your obsoleted comments in the other thread. I think the proposal on the floor is to do two things A) a commons-net 1.5 containing fixes for any outstanding bugs and incorporating Josejuan Montiel and Paul Ferraro's FTPS code. This code would depend on com.sun.ssl.net classes. It would be the last release supporting JDKs 1.4 B) a commons-net 2.0 (possibly a different project) that would require jdk 1.4 compatibility, including modifying the FTPS code to use javax.ssl.net, the nio extensions, and using java 1.4's regex which would have the one small advantage of reducing dependency on other jars which periodically rears its head as an issue. While I'm generally in favor of this, I still don't think its ready for a vote because of possibly a different project, which is too vague. One more thing, we would need Paul Ferraro to sign a Software Grant which was mentioned about a week ago by Cliff Schmidt. I am trying to get details on this. Steve Cohen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta-commons Wiki] Update of FrontPage by RahulAkolkar
Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta-commons Wiki for change notification. The following page has been changed by RahulAkolkar: http://wiki.apache.org/jakarta-commons/FrontPage The comment on the change is: Add menu bars -- = Welcome to the Jakarta Commons Wiki = || http://jakarta.apache.org/commons/images/logo.png || This is the [wiki:ApacheGeneral/FrontPage Apache Wiki] for the [http://jakarta.apache.org/commons Jakarta Commons] project and is maintained by the [wiki:Jakarta/FrontPage Jakarta] community. To edit pages, visit [wiki:UserPreferences login] near the top right corner of any page to create a user profile or to login. Notifications of all changes you make will be sent to the [EMAIL PROTECTED] mailing list, so we will be aware of your changes and we will happily correct any small mistakes that you might make. || - We're a [http://wiki.apache.org/jakarta/FrontPage Jakarta] community, dedicated to creating reusable library components in Java. + We're a [http://wiki.apache.org/jakarta/FrontPage Jakarta] community, dedicated to creating reusable library components in Java. Jakarta Commons is now using [http://subversion.tigris.org/ Subversion] as the version control system. - JakartaCommonsEtiquette contains observations and opinions aimed at explaining some of the peculiarities of Jakarta Commons. + Welcome: JakartaCommonsEtiquette | JakartaCommonsResources | ArticlesAndTutorials - GettingInvolved has information for people interested in helping out with commons development. + Developers: GettingInvolved | [:UsingSVN] - Jakarta Commons is now using [http://subversion.tigris.org/ Subversion] as version control system, more information can be found on the [:UsingSVN] page. - - [CommonsPeople] [ComponentPlans] [CommonsCommitters] + Committers: CommonsPeople | ComponentPlans | CommonsCommitters = Components = - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta-commons Wiki] Update of ArticlesAndTutorials by RahulAkolkar
Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta-commons Wiki for change notification. The following page has been changed by RahulAkolkar: http://wiki.apache.org/jakarta-commons/ArticlesAndTutorials The comment on the change is: Add articles listed on front page to this more appropriate articles page. -- - This page not currently in use + == Articles == + * [http://www.devx.com/Java/Article/29392 Extend the JDK Classes with Jakarta Commons, Part I] - Explore the components in the Jakarta Commons set of reusable classes and you'll be convinced that most of them should be part of the JDK. Learn which ones you should use in your projects. - [http://www.narayanan.co.in/aboutme.html Narayanan A R] + * [http://www.devx.com/Java/Article/29795 Extend the JDK Classes with Jakarta Commons, Part II] - This second installment of a three-part series further explores components in Jakarta Commons and presents real world examples to demonstrate how you can use them in your projects. - [http://www.narayanan.co.in/aboutme.html Narayanan A R] + * [http://www.devx.com/Java/Article/30117 Extend the JDK Classes with Jakarta Commons, Part III] - Explore Jakarta Commons components that enable you to parse arguments in a command-line application, connect to various file systems at the same time, allow an application to uniformly access configurations loaded from various sources, and pool any object. - [http://www.narayanan.co.in/aboutme.html Narayanan A R] + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta-commons Wiki] Update of FrontPage by RahulAkolkar
Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta-commons Wiki for change notification. The following page has been changed by RahulAkolkar: http://wiki.apache.org/jakarta-commons/FrontPage The comment on the change is: Articles have been moved to ArticlesAndTutorials page -- * [http://morph.sourceforge.net Morph] - alpha framework based on ideas from BeanUtils ([http://morph.sourceforge.net/alternatives/beanutils.html read comparison to Morph]), CommonsConvert and CommonsChain. Also will support functionality in [:JEXL] ([http://morph.sourceforge.net/alternatives/jexl.html read comparison to Morph]). * [http://www.nabble.com/Jakarta-Commons-f292.html Mailing list archive] - [http://www.nabble.com/ Nabble] hosts a combined user/dev archive of the commons' lists. The archvie has a clean UI for cross browsing and also a fast search. Users can search here before posting questions to the mailing lists. - == Articles == - - * [http://www.devx.com/Java/Article/29392 Extend the JDK Classes with Jakarta Commons, Part I] - Explore the components in the Jakarta Commons set of reusable classes and you'll be convinced that most of them should be part of the JDK. Learn which ones you should use in your projects. - [http://www.narayanan.co.in/aboutme.html Narayanan A R] - * [http://www.devx.com/Java/Article/29795 Extend the JDK Classes with Jakarta Commons, Part II] - This second installment of a three-part series further explores components in Jakarta Commons and presents real world examples to demonstrate how you can use them in your projects. - [http://www.narayanan.co.in/aboutme.html Narayanan A R] - * [http://www.devx.com/Java/Article/30117 Extend the JDK Classes with Jakarta Commons, Part III] - Explore Jakarta Commons components that enable you to parse arguments in a command-line application, connect to various file systems at the same time, allow an application to uniformly access configurations loaded from various sources, and pool any object. - [http://www.narayanan.co.in/aboutme.html Narayanan A R] - - == Developer Documentation == * A CommonsManual. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta-commons Wiki] Update of JakartaCommonsResources by RahulAkolkar
Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta-commons Wiki for change notification. The following page has been changed by RahulAkolkar: http://wiki.apache.org/jakarta-commons/JakartaCommonsResources The comment on the change is: Add third party resources content from front page. -- Extend the JDK Classes with Jakarta Commons, Part I - Explore the components in the Jakarta Commons set of reusable classes and you'll be convinced that most of them should be part of the JDK. Learn which ones you should use in your projects. Complete article can be found here. http://www.devx.com/Java/Article/29392/ Extend the JDK Classes with Jakarta Commons, Part II - This second installment of a three-part series further explores components in Jakarta Commons and presents real world examples to demonstrate how you can use them in your projects. Complete article can be found here. http://www.devx.com/Java/Article/29795/ + + == Books == There are currently 7 known books on Jakarta Commons. In order of publication: @@ -22, +24 @@ An important part of the books and articles from the community's point of view, is which versions of the components they cover. Hopefully we can outline these here. - - == Opinion of HenriYandell == + === Opinion of HenriYandell === As a fervent buyer of technical books, especially open-source ones, I have a lot of opinions when it comes down to these books. Take the following with a grain of salt, especially as they are based on memory and personal view: * Christian's book is not solely focused on Commons, but is instead about programming in general, with Commons as a focused set of examples. This book came out quietly and seems academic in nature; useful for teaching a class I'd suspect. @@ -46, +47 @@ (/End of Opinion) + == Third Party Resources == + + * [http://morph.sourceforge.net Morph] - alpha framework based on ideas from BeanUtils ([http://morph.sourceforge.net/alternatives/beanutils.html read comparison to Morph]), CommonsConvert and CommonsChain. Also will support functionality in [:JEXL] ([http://morph.sourceforge.net/alternatives/jexl.html read comparison to Morph]). + * [http://www.nabble.com/Jakarta-Commons-f292.html Mailing list archive] - [http://www.nabble.com/ Nabble] hosts a combined user/dev archive of the commons' lists. The archvie has a clean UI for cross browsing and also a fast search. Users can search here before posting questions to the mailing lists. + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta-commons Wiki] Update of FrontPage by RahulAkolkar
Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta-commons Wiki for change notification. The following page has been changed by RahulAkolkar: http://wiki.apache.org/jakarta-commons/FrontPage The comment on the change is: Moved third party resources to JakartaCommonsResources -- - == Third Party Resources == - - * [JakartaCommonsResources] - * [http://morph.sourceforge.net Morph] - alpha framework based on ideas from BeanUtils ([http://morph.sourceforge.net/alternatives/beanutils.html read comparison to Morph]), CommonsConvert and CommonsChain. Also will support functionality in [:JEXL] ([http://morph.sourceforge.net/alternatives/jexl.html read comparison to Morph]). - * [http://www.nabble.com/Jakarta-Commons-f292.html Mailing list archive] - [http://www.nabble.com/ Nabble] hosts a combined user/dev archive of the commons' lists. The archvie has a clean UI for cross browsing and also a fast search. Users can search here before posting questions to the mailing lists. - == Developer Documentation == * A CommonsManual. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta-commons Wiki] Update of ArticlesAndTutorials by RahulAkolkar
Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta-commons Wiki for change notification. The following page has been changed by RahulAkolkar: http://wiki.apache.org/jakarta-commons/ArticlesAndTutorials The comment on the change is: Add summary of articles link from JakartaCommonsResources -- == Articles == + + A very useful summary of articles and resources available for Jakarta Commons may be found at [http://www.java201.com/resources/browse/70-all.html Java201]. * [http://www.devx.com/Java/Article/29392 Extend the JDK Classes with Jakarta Commons, Part I] - Explore the components in the Jakarta Commons set of reusable classes and you'll be convinced that most of them should be part of the JDK. Learn which ones you should use in your projects. - [http://www.narayanan.co.in/aboutme.html Narayanan A R] * [http://www.devx.com/Java/Article/29795 Extend the JDK Classes with Jakarta Commons, Part II] - This second installment of a three-part series further explores components in Jakarta Commons and presents real world examples to demonstrate how you can use them in your projects. - [http://www.narayanan.co.in/aboutme.html Narayanan A R] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta-commons Wiki] Update of JakartaCommonsResources by RahulAkolkar
Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta-commons Wiki for change notification. The following page has been changed by RahulAkolkar: http://wiki.apache.org/jakarta-commons/JakartaCommonsResources The comment on the change is: Move articles links to a more appropriate page. -- = Resources for Jakarta Commons = == Articles == - A very useful summary of articles and resources available for Jakarta Commons may be found at [http://www.java201.com/resources/browse/70-all.html Java201]. + Articles are listed on the ArticlesAndTutorials page. - Extend the JDK Classes with Jakarta Commons, Part I - Explore the components in the Jakarta Commons set of reusable classes and you'll be convinced that most of them should be part of the JDK. Learn which ones you should use in your projects. Complete article can be found here. http://www.devx.com/Java/Article/29392/ - - Extend the JDK Classes with Jakarta Commons, Part II - This second installment of a three-part series further explores components in Jakarta Commons and presents real world examples to demonstrate how you can use them in your projects. Complete article can be found here. http://www.devx.com/Java/Article/29795/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] New Committer - Jörg Heinicke
+1.. Mvgr, Martin Oliver Zeigermann wrote: I would like to nominate Jörg Heinicke [EMAIL PROTECTED] as an Apache Jakarta Commons Committer. Jörg has provided patches and has participated in discussions about [jci] and mainly [transaction]. Especially in the field of [transaction] he has shown deep insight and endurance. Additionally, it seems I am the only remaining active committer for [transaction] and could need some help and support. I thus think he would be very valuable as a committer. Oliver [ ] +1, let him commit! [ ] +0 [ ] -0 [ ] -1, no, because - 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]
[Jakarta-commons Wiki] Update of Mirroring by RahulAkolkar
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Jakarta-commons Wiki
for change notification.
The following page has been changed by RahulAkolkar:
http://wiki.apache.org/jakarta-commons/Mirroring
The comment on the change is:
Remove nonsensical post, leave page blank. Mirroring stuff, anyone?
--
##language:en
- == Template for Help Pages ==
- Text.
+ Blank.
- === Example ===
- {{{
- xxx
- }}}
- === Display ===
- xxx
-
- CategoryCategory
-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Bug report for Commons [2006/01/29]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=CriticalMAJ=Major | | | | MIN=Minor NOR=Normal ENH=Enhancement | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 6508|Ass|Enh|2002-02-17|[lakta] HttpClient now supports proxyHost and prox| | 6826|Ass|Enh|2002-03-04|[lakta] Need to have xml files validated against D| | 6829|Ass|Enh|2002-03-04|[lakta] Allow easier way of user specified tests | | 7069|Ass|Enh|2002-03-13|[lakta] DTD and DOM Validators| | 7226|Opn|Enh|2002-03-19|[beanutils] Nested Bean Collection| | 7367|New|Nor|2002-03-22|[services] ServiceManager not actually serializabl| | 7465|New|Nor|2002-03-25|[lakta] Need better 'dist' build | | 7981|Ver|Nor|2002-04-11|[codec][PATCH] add 2 new methods for encoding stri| |10319|New|Enh|2002-06-28|[beanutils] Instantiate property if null in form b| |12807|New|Nor|2002-09-19|[lakta][PATCH] Update build.xml to use commons-log| |13390|New|Nor|2002-10-07|[lakta] ResponseHeaderHandler and ResponseHeaderVa| |13426|New|Enh|2002-10-08|[lakta][PATCH] xml-reference.xml responseHeader ad| |13743|Opn|Enh|2002-10-17|[beanutils] Need getPropertyType(Class theClass, S| |14394|Ver|Nor|2002-11-08|[beanutils] Excessive exceptions log under securit| |14667|Ver|Maj|2002-11-19|[beanutils] PropertyUtils.copyProperties does not | |15451|Opn|Enh|2002-12-17|[beanutils] Multiple mapped properties not possibl| |15519|Ver|Maj|2002-12-19|[beanutils] PropertyUtils.getPropertyType() for ja| |15744|New|Nor|2002-12-31|[scaffold] Scaffold ResultSet used after statement| |16038|Opn|Enh|2003-01-13|[beanutils] LocaleBeanUtils.copyProperties() does | |16394|Inf|Enh|2003-01-24|[validator] Enhance the IndexedListProperty to han| |16525|Opn|Enh|2003-01-29|[beanutils] BeanUtils.setProperty is over-zealous | |16600|New|Nor|2003-01-30|[lakta] JUnitTestAdapter throws SAXException becau| |16634|New|Enh|2003-01-31|[validator] Change ValidatorUtils.getValueAsString| |16873|New|Enh|2003-02-07|[lakta] Specifying a different latka.properties fi| |17002|New|Enh|2003-02-12|[beanutils] Problem with index property | |17102|New|Enh|2003-02-15|[lakta] Can't embed characters in paramValue | |17501|New|Enh|2003-02-27|[beanutils] Add dynamic discovery of mapped proper| |17662|New|Nor|2003-03-05|[cli] Unknown options are ignored instead of throw| |17682|New|Nor|2003-03-05|[cli] HelpFormatter does not wrap lines correctly | |17769|New|Blk|2003-03-07|[scaffold] pre-mature closing of Statement and Pre| |17957|New|Cri|2003-03-13|[launcher] - on OutOfMemoryError no message | |18087|New|Enh|2003-03-18|[beanutils] Add BeanFactory class for dynamic fact| |18773|New|Enh|2003-04-07|[reflect] Can add a method cache in MethodUtils | |18942|New|Enh|2003-04-11|[beanutils] Add t/f to BooleanConverter | |19781|New|Min|2003-05-08|[beanutils] PropertyUtils.copyProperties throws ex| |19857|New|Enh|2003-05-12|[beanutils] Methods ConvertUtilsBean.convert could| |20015|Ass|Nor|2003-05-18|[lang] Make Entities public and unit test | |20027|New|Enh|2003-05-19|[beanutils] ConvertUtils enhancements | |20057|New|Nor|2003-05-20|[lakta] Difficulty to download sample Latka test| |20067|New|Nor|2003-05-20|[lakta] sample Latka test suite SUITE FAILED - c| |20520|New|Enh|2003-06-05|[beanutils] MethodUtils: Need easy way to invoke s| |20523|New|Enh|2003-06-05|[fileupload] Model FileUpload model to mimic javax| |20549|New|Enh|2003-06-06|[beanutils] Handling of exceptions thrown during B| |20686|New|Enh|2003-06-11|[beanutils] Register converters by both target cla| |20836|New|Enh|2003-06-17|[beanutils] Localizing beanutils | |20838|New|Enh|2003-06-17|[fileupload] Add a new property maxFileSize to con| |20968|New|Enh|2003-06-20|[beanutils][PATCH] Include bean getClass in Proper| |21076|New|Enh|2003-06-25|[beanutils] Add aggressive mode for BeanUtils.co| |21304|New|Min|2003-07-03|[cli] Broken link report (13 404s)| |21433|New|Enh|2003-07-09|[scaffold] StorageBeanBase should use a resource n| |21483|New|Enh|2003-07-10|[beanutils] BeanUtils and PropertyUtils toString f|
DO NOT REPLY [Bug 38435] New: - [id] Composite identifiers
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38435 Summary: [id] Composite identifiers Product: Commons Version: unspecified Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Sandbox AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Creating an issue to track composite identifier support. --- Date: Sun, 29 Jan 2006 13:20:50 -0700 From: Phil Steitz [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List commons-dev@jakarta.apache.org To: Jakarta Commons Developers List commons-dev@jakarta.apache.org Subject: [id] Composite identifiers I just committed a first cut at a CompositeIdentifierGenerator along the lines of what we have discussed. To replace the prefix generators with this, we either have to modify the factories or introduce a ConstantIdentifierGenerator. If others (Michael?) have better / different ideas on how to handle this, I am happy to review patches or replace this implementation. Phil -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta-commons Wiki] Update of CommonsCommitters by RahulAkolkar
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Jakarta-commons Wiki
for change notification.
The following page has been changed by RahulAkolkar:
http://wiki.apache.org/jakarta-commons/CommonsCommitters
The comment on the change is:
Add links to developer documentation pages, previously on the front page
--
* /ReleasesInProgress is a document to help people keep track of what
releases are currently happening and where they've got to
+ * A CommonsManual.
+
+ * MovingComponents (sandbox graduations have additional requirements - also
see related links below)
+
+ * MovingFromSandboxToProper
+ * [:MovingFromSandboxToProperSVN]
+
+ * CreatingStandardWebPresence
+
+ * SigningReleases and [:Mirroring]
+
+ * ComponentTemplate - Use this template when creating the main wiki page for
a component.
+
+ * AutomatedIdeas - some ideas on how increased automation could help us
(!HenriYandell)
+
+ * SubversionConversion - a proposed set of svn instructions for
infrastructure.
+
+ * CreatingSiteWithMaven2 - a trial to see if it is possible to use Maven 2
to build commons sites.
+
+
+
+ {{{
+ *Q:* Little request: Can we PLEASE have a single javadoc tree for all commons
components?
+ I am getting tired of switching between dbcp, loggin, and pool.
+ Especially when I am following one line of calls or inheritance.
+ Thanks, Angus
+
+ *A:* Sure, it should be relatively easy, why not take some initiative and do
it yourself?
+ }}}
+ Proposed solution: [http://www.apache.org/~bayard/multidoc/commons-multidoc/
Multidoc]
+
+
+
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta-commons Wiki] Update of FrontPage by RahulAkolkar
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Jakarta-commons Wiki
for change notification.
The following page has been changed by RahulAkolkar:
http://wiki.apache.org/jakarta-commons/FrontPage
The comment on the change is:
Moved informal developer documentation links to the CommonsCommitters page.
--
- == Developer Documentation ==
-
- * A CommonsManual.
-
- * MovingComponents (sandbox graduations have additional requirements - also
see related links below)
-
- * MovingFromSandboxToProper
- * [:MovingFromSandboxToProperSVN]
-
- * CreatingStandardWebPresence
-
- * GettingInvolved - General Documentation for all Apache Commiters and
ReleaseManager concerning various subjects (like SigningReleases,
MavenRepository, and [:Mirroring])
-
- * ComponentTemplate - Use this template when creating the main wiki page for
a component.
-
- * AutomatedIdeas - some ideas on how increased automation could help us
(HenriYandell)
-
- * SubversionConversion - a proposed set of svn instructions for
infrastructure.
-
- * CreatingSiteWithMaven2 - a trial to see if it is possible to use Maven 2
to build commons sites.
-
- {{{
- *Q:* Little request: Can we PLEASE have a single javadoc tree for all commons
components?
- I am getting tired of switching between dbcp, loggin, and pool.
- Especially when I am following one line of calls or inheritance.
- Thanks, Angus
-
- *A:* Sure, it should be relatively easy, why not take some initiative and do
it yourself?
- }}}
- Proposed solution: [http://www.apache.org/~bayard/multidoc/commons-multidoc/
Multidoc]
-
-
= 'Special' Wiki pages =
See SpecialWikiPages for a basic guide to using this wiki, a full-text search
of this wiki, a title index, orphaned and random pages, stats, and information
about this wiki installation and available extensions.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38435] - [id] Composite identifiers
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38435 --- Additional Comments From [EMAIL PROTECTED] 2006-01-29 23:20 --- Created an attachment (id=17531) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=17531action=view) CompoundGenerator.java source Phil, I guess I was of thinking something less extensible than your composite implementation. Please find the attached CompoundGenerator as my idea for a general replacement for the Prefixed Xxx generators. Maybe there is a place for both? michael -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta-commons Wiki] Update of CommonsCommitters by RahulAkolkar
Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta-commons Wiki for change notification. The following page has been changed by RahulAkolkar: http://wiki.apache.org/jakarta-commons/CommonsCommitters The comment on the change is: List ReleaseShoppingList page -- Informal documentation for commons committers. * /ReleasesInProgress is a document to help people keep track of what releases are currently happening and where they've got to + + * ReleaseShoppingList has lots of little things that good Jakarta Commons releases should have that maven 1 doesn't do by default * A CommonsManual. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta-commons Wiki] Update of suljaegu by RahulAkolkar
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Jakarta-commons Wiki
for change notification.
The following page has been changed by RahulAkolkar:
http://wiki.apache.org/jakarta-commons/suljaegu
The comment on the change is:
Spam.
--
+ Blank.
- ##language:en
- == Template for Help Pages ==
- Text.
- === Example ===
- {{{
- xxx
- }}}
-
- === Display ===
- xxx
-
- CategoryCategory
-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] JDK 1.4+ Branch?
Daniel Thanks for the comments. A few thoughts: * I didnt realise until you mentioned it that MatchResult was a JDK 1.5+ feature. It seems a bit short-sighted of the Sun engineers concerned not to have included it in 1.4, especially as the rest of java.util.regex seems to mimic ORO/Jakarta Regexp uncannily in most regards. I guess one approach would be to build a custom MatchResult interface, but this would also have to handle the JDK 1.5 scenario. * You're correct that there is no inherent advantage, at least functionality-wise, in removing the ORO dependency. I think the major boost is that it makes [net] free of all other dependencies - i.e. it becomes just a single jar download. A lot of new users seem to get bitten by the ClassNotFoundException they get if ORO is not in the CLASSPATH. * The FTPClient/TelnetClient area: actually, I may have misremembered a comment you made some time back, in which I think you may have expressed a desire to break the dependeny here. I think at least what we should look at is making any incremental changes to the threading code that may be required. * I dont know how much has been added since 1.4.1 to merit a 1.4.2 release - maybe we should just go for a 1.5.0 (with FTPS)? Thanks Rory Daniel F. Savarese wrote: In message [EMAIL PROTECTED], Rory Winston writes: I think that this might be a good point to consider introducing a version of Commons-Net that uses JDK 1.4+ as a baseline. My reasoning is I've long advocated branching to take advantage of JDK 1.4, but I had a more radical agenda. I believe the underpinnings of Commons Net need to be redesigned without being afraid to break compatibility. My suggestion was for this new Commons Net 2.0 to be in a new package: org.apache.commons.net2. At the time, the incremental evolution path was preferred. * We could remove the (oro) jar dependency; I think that's a side-effect of moving to JDK 1.4, not a reason in and of itself for JDK 1.4. There are no benefits to java.util.regex over oro in the context used by Commons Net. * It could be a good opportunity to clean up the threading code and socket handling, and make use of NIO; I believe that's the main reason to make the move. Of course, JDK-1.3-compatible releases could still continue on HEAD, or we could move the 1.4+ branch to HEAD and the 1.3 code to a maintenance branch. Assuming we're talking about continuing incremental evolution, I believe we should cut a 1.4.2 release with all the current bug fixes included and branch from there. JDK 1.3 would be supported in maintenance releases based off of 1.4.2 (e.g., 1.4.3, 1.4.4, etc.) that would only include bug fixes. New development based on JDK 1.4 would continue on the main trunk. Taking the FTPS code contribution into account, I'd change that to releasing a 1.4.2, then incorporating the FTPS code in a 1.5 release compatible with JDK 1.3, and branching from there as per the original scenario. The only situation in which I'd suggest doing it differently is if someone was really itching to write NIO or other JDK 1.4 stuff in the near term, in which case I think we'd have to let that happen on a separate branch until the FTPS code was incorporated into the trunk. Then after the 1.5 release off of the trunk, we'd merge changes from the JDK 1.4 branch into the main trunk and only do JDK 1.3 releases off of the 1.5 tree. daniel - 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]
[Jakarta-commons Wiki] Update of CommonsPeople by RoryWinston
Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta-commons Wiki for change notification. The following page has been changed by RoryWinston: http://wiki.apache.org/jakarta-commons/CommonsPeople -- * '''Interested''': IO, Collections, Math, DbUtils * '''Future''': Email, CLI + === Rory Winston === + * '''Active''': Net + * '''Interested''': Validator, SCXML, DBCP + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [wiki] Proposed changes
On 1/24/06, Rahul Akolkar [EMAIL PROTECTED] wrote: I'm proposing to move some content around on the Commons wiki. snip/ Done. -Rahul Motivating factors are: * Discourage amorphous growth on one or two pages * Distribute content over already existing pages (some of which are mostly abandoned) * Reduce the number of orphaned pages, aim for better wiki navigation (... over time, not that I expect any of my changes to be revolutionary ;-) If you don't like one or more of the changes below, reply with a -1 underneath the change. I will make all changes that do *not* receive a -1 in a few days (Friday at the earliest). 1) Move articles and third party resources to this orphaned page: http://wiki.apache.org/jakarta-commons/ArticlesAndTutorials 2) Create a DeveloperDocumentation page and move the related links from the FrontPage to that one. 3) Create a menu/navigation bar on the top (currently it has three entries). More entries will wrap in your browser, depending on your resolution. 4) Lose the description for the links on top of the page, they should do OK without it as well, and add them to (3). For example: GettingInvolved has information for people interested in helping out with commons development. will just become a GettingInvolved link in the nav bar. 5) Add a FrequentlyAskedQuestions page for Commons as a whole (for generic questions such as which why does my maven site fail) Stephen- Can we post your Javapolis pdf on the wiki? I remember someone suggesting it. -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jakarta-commons Wiki] Update of Mirroring by RahulAkolkar
On 1/29/06, Apache Wiki [EMAIL PROTECTED] wrote: Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta-commons Wiki for change notification. The following page has been changed by RahulAkolkar: http://wiki.apache.org/jakarta-commons/Mirroring The comment on the change is: Remove nonsensical post, leave page blank. Mirroring stuff, anyone? This is covered fully in sections 5-7 of http://jakarta.apache.org/commons/releases/release.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jakarta-commons Wiki] Update of Mirroring by RahulAkolkar
On 1/29/06, Phil Steitz [EMAIL PROTECTED] wrote: On 1/29/06, Apache Wiki [EMAIL PROTECTED] wrote: snip/ The following page has been changed by RahulAkolkar: http://wiki.apache.org/jakarta-commons/Mirroring The comment on the change is: Remove nonsensical post, leave page blank. Mirroring stuff, anyone? This is covered fully in sections 5-7 of http://jakarta.apache.org/commons/releases/release.html snap/ Thats a good point, I'll just link to the website from that wiki page. I would have liked to delete that wiki page altogether (along with a couple of others), but I think it requires some MoinMoin / infra admin privileges? -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta-commons Wiki] Update of Mirroring by RahulAkolkar
Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta-commons Wiki for change notification. The following page has been changed by RahulAkolkar: http://wiki.apache.org/jakarta-commons/Mirroring The comment on the change is: Link to mirroring bits in website docs(thanks to Phil Steitz for the suggestion) -- ##language:en - Blank. + See steps 5 to 7 in the [http://jakarta.apache.org/commons/releases/release.html Cutting The Release - Step By Step] recipe on the Commons website. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[all] The JDK1.5 issue [was: [net] JDK 1.4+ Branch?]
I'd like to broaden the original [net] thread and ask how is commons going to handle JDK1.5? Or in the case of [net], is a JDK1.4 branch worthwhile? So far, commons has stuck with JDK 1.2/1.3 pretty much across the board. This is because a) JDK1.4 doesn't give that many benefits over 1.3 b) a lot of people use 1.3 still (Websphere etc) c) limited developer resource to manage multiple branches So, my proposal is that [net], and other commons projects jump from a 1.2/1.3 base now, to a 1.5 base for the future. I believe that we are now starting to see 1.5 move forwards, perhaps towards the tipping point of much wider adoption. JDK1.5 can change radically the API design through generic and enums and this gives the opportunity for new development and new life to some of these projects. (New development often attracts new committers) I can't comment on the specifics of the [net] case, but I'd like commons as a whole to think seriously about how to handle the JDK1.5 issue. (As you may guess, my opinion is to skip 1.4 and go for 1.5 branches.) Stephen Rory Winston wrote: Daniel Thanks for the comments. A few thoughts: * I didnt realise until you mentioned it that MatchResult was a JDK 1.5+ feature. It seems a bit short-sighted of the Sun engineers concerned not to have included it in 1.4, especially as the rest of java.util.regex seems to mimic ORO/Jakarta Regexp uncannily in most regards. I guess one approach would be to build a custom MatchResult interface, but this would also have to handle the JDK 1.5 scenario. * You're correct that there is no inherent advantage, at least functionality-wise, in removing the ORO dependency. I think the major boost is that it makes [net] free of all other dependencies - i.e. it becomes just a single jar download. A lot of new users seem to get bitten by the ClassNotFoundException they get if ORO is not in the CLASSPATH. * The FTPClient/TelnetClient area: actually, I may have misremembered a comment you made some time back, in which I think you may have expressed a desire to break the dependeny here. I think at least what we should look at is making any incremental changes to the threading code that may be required. * I dont know how much has been added since 1.4.1 to merit a 1.4.2 release - maybe we should just go for a 1.5.0 (with FTPS)? Thanks Rory Daniel F. Savarese wrote: In message [EMAIL PROTECTED], Rory Winston writes: I think that this might be a good point to consider introducing a version of Commons-Net that uses JDK 1.4+ as a baseline. My reasoning is I've long advocated branching to take advantage of JDK 1.4, but I had a more radical agenda. I believe the underpinnings of Commons Net need to be redesigned without being afraid to break compatibility. My suggestion was for this new Commons Net 2.0 to be in a new package: org.apache.commons.net2. At the time, the incremental evolution path was preferred. * We could remove the (oro) jar dependency; I think that's a side-effect of moving to JDK 1.4, not a reason in and of itself for JDK 1.4. There are no benefits to java.util.regex over oro in the context used by Commons Net. * It could be a good opportunity to clean up the threading code and socket handling, and make use of NIO; I believe that's the main reason to make the move. Of course, JDK-1.3-compatible releases could still continue on HEAD, or we could move the 1.4+ branch to HEAD and the 1.3 code to a maintenance branch. Assuming we're talking about continuing incremental evolution, I believe we should cut a 1.4.2 release with all the current bug fixes included and branch from there. JDK 1.3 would be supported in maintenance releases based off of 1.4.2 (e.g., 1.4.3, 1.4.4, etc.) that would only include bug fixes. New development based on JDK 1.4 would continue on the main trunk. Taking the FTPS code contribution into account, I'd change that to releasing a 1.4.2, then incorporating the FTPS code in a 1.5 release compatible with JDK 1.3, and branching from there as per the original scenario. The only situation in which I'd suggest doing it differently is if someone was really itching to write NIO or other JDK 1.4 stuff in the near term, in which case I think we'd have to let that happen on a separate branch until the FTPS code was incorporated into the trunk. Then after the 1.5 release off of the trunk, we'd merge changes from the JDK 1.4 branch into the main trunk and only do JDK 1.3 releases off of the 1.5 tree. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL
DO NOT REPLY [Bug 38435] - [id] Composite identifiers
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38435 --- Additional Comments From [EMAIL PROTECTED] 2006-01-30 01:29 --- Could be room for both; or I am OK replacing the CompositeIdentifierGenerator with this. The use cases that I have run into have involved a random part and a sequential part; or a date/time plus sequential, which could not be done this way; or (not covered by either of these) a random part followed by a hash (with salt) of the first part so the id could be verified to be authentic. It is a little awkward to introduce a ConstantIdentifierGenerator to make the Composite setup work for the special case of prefix / suffix. What do others think about these? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] The JDK1.5 issue [was: [net] JDK 1.4+ Branch?]
On 1/29/06, Stephen Colebourne [EMAIL PROTECTED] wrote: I'd like to broaden the original [net] thread and ask how is commons going to handle JDK1.5? Or in the case of [net], is a JDK1.4 branch worthwhile? So far, commons has stuck with JDK 1.2/1.3 pretty much across the board. This is because a) JDK1.4 doesn't give that many benefits over 1.3 b) a lot of people use 1.3 still (Websphere etc) c) limited developer resource to manage multiple branches So, my proposal is that [net], and other commons projects jump from a 1.2/1.3 base now, to a 1.5 base for the future. I believe that we are now starting to see 1.5 move forwards, perhaps towards the tipping point of much wider adoption. JDK1.5 can change radically the API design through generic and enums and this gives the opportunity for new development and new life to some of these projects. (New development often attracts new committers) I can't comment on the specifics of the [net] case, but I'd like commons as a whole to think seriously about how to handle the JDK1.5 issue. (As you may guess, my opinion is to skip 1.4 and go for 1.5 branches.) snip/ As I indicated briefly before, IMO, we need to encourage 1.4 or Tiger branches. Its an indication that we are moving forward as a community rather than stagnating. We understand there are many people who have to use = 1.3, many times for reasons beyond their control -- thats why so many of our components support those JDKs. While creating a branch to push up the JDK version, which version is chosen should be upto the developers creating the branch, I wouldn't want to rule out 1.4 if anyone sees value in it or is not ready to go to Tiger yet. I also think we shouldn't worry as much about the lack of developer resources. Its takes one developer to start a branch, and time will tell if it becomes successful and gets incorporated in a future (presumably major version) release of the component. If developers are willing, the fact that new ideas within a component require a higher JDK version should never be the *only* limiting factor for the introduction of these ideas. -Rahul Stephen snap/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38439] New: - [id] URI generators
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38439. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38439 Summary: [id] URI generators Product: Commons Version: unspecified Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Sandbox AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Attached are an initial implementation and weak unit tests for URI generator(s), another example of a composite identifier generator. Any String identifier generator may be used to generate the path part urn:foo:bar/baz/0 urn:foo:bar/baz/1 urn:foo:bar/baz/2 urn:foo:bar/baz/3 or the fragment part urn:foo:bar/baz#0 urn:foo:bar/baz#1 urn:foo:bar/baz#2 urn:foo:bar/baz#3 of URIs. A similar set of classes might be created for URL and javax.xml.namespace.QName generators. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38439] - [id] URI generators
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38439. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38439 --- Additional Comments From [EMAIL PROTECTED] 2006-01-30 04:19 --- Created an attachment (id=17532) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=17532action=view) src tarball contents include src/java/org/apache/commons/id/URIGenerator.java src/java/org/apache/commons/id/uri/PathURIGenerator.java src/java/org/apache/commons/id/uri/FragmentURIGenerator.java src/test/org/apache/commons/id/uri/PathURIGeneratorTest.java src/test/org/apache/commons/id/uri/FragmentURIGeneratorTest.java -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
In message [EMAIL PROTECTED], Steve Cohen writes: Daniel, before we vote, I think we need a formal motion to vote on, especially in light of your obsoleted comments in the other thread. My +1 wasn't intended to reflect a vote. It was just shorthand for I concur. While I'm generally in favor of this, I still don't think its ready for a vote because of possibly a different project, which is too vague. +1 :) daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] JDK 1.4+ Branch?
In message [EMAIL PROTECTED], Rory Winston writes: * You're correct that there is no inherent advantage, at least functionality-wise, in removing the ORO dependency. I think the major I didn't mean to suggest that the dependency shouldn't be removed. I was just being nitpicky and saying that it should be removed because we're using JDK 1.4 rather than we should move to JDK 1.4 so we can remove it. * The FTPClient/TelnetClient area: actually, I may have misremembered a comment you made some time back, in which I think you may have expressed a desire to break the dependeny here. I think at least what we should look at is making any incremental changes to the threading code that may be required. I'd have to look back through the archives to see what we talked about before. All I know for sure at the moment is that I am extremely disenchanted with the current TelnetClient implementation. I think my previous comments may have been that the subset of telnet used by FTP didn't require asynchrony and could be implemented in the FTP class to remove the dependency on TelnetClient. However, if TelnetClient is reimplemented with NIO without threads, then there's no need to remove the dependency. The bad thing about the dependency on TelnetClient as currently implemented is that if you want/need to use many FTPClient instances at the same time, you end up with a bunch of extra threads that hog up resources. * I dont know how much has been added since 1.4.1 to merit a 1.4.2 release - maybe we should just go for a 1.5.0 (with FTPS)? There's that TFTP regression, the fix to which at least two people on commons-user are waiting for. I don't know what else users are waiting for, but if the time frame for a 1.5.0 release with FTPS isn't far off, then I also don't see any reason for a 1.4.2. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Encryption - Common HTTP client
Hello Oleg, This means Commons HTTPClient does not include any encryption algo of its own. Please confirm. Regards, Parveen On Wed, 2006-01-25 at 10:50 +0530, PARVEEN GARG (GR/EIL) wrote: Hello all, I have a question regarding encryption and export control. Does Apache, Commons HTTPclient include any SW encryption that restricts export (i.e. special ECCN code)? Best Regards, Parveen Garg Parveen, Commons HttpClient relies on standard java extensions JCE and JSSE to perform all its encryption/decryption operations. Hope this answers your question. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ From: PARVEEN GARG (GR/EIL) Sent: Wednesday, January 25, 2006 10:50 AM To: 'commons-dev@jakarta.apache.org' Subject:Encryption - Common HTTP client Hello all, I have a question regarding encryption and export control. Does Apache, Commons HTTPclient include any SW encryption that restricts export (i.e. special ECCN code)? Best Regards, Parveen Garg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
