Re: [jxpath] optimize xpath query on xpath enabled containers
Dmitri, I'm still looking at the code, so I can't comment on a fix yet. What I had in mind in implementing an interface that signals the jxpath implementation that a context (or pointer or something) is able of evaluating queries which result in the parsed query structure to be passed to the context. HTH, Michael Michael, I believe, adding this type of delegation for query evaluation would require quite significant refactoring of JXPath. However, I could be wrong. Do you have a particular fix in mind? Thank you, - Dmitri - Original Message - From: Michael Homeijer [EMAIL PROTECTED] To: Jakarta Commons Developers List commons-dev@jakarta.apache.org Sent: Monday, January 31, 2005 2:43 PM Subject: [jxpath] optimize xpath query on xpath enabled containers Hi, Im am looking at executing jxpath queries against a model that supports lazy loading and queries. Queries like [EMAIL PROTECTED] = ''test'] will be executed by looping through all nodes and testing if the expression is true for a node. Because my model supports queries itself, It would be much faster to query the model and have the model itself execute the query that will load only the nodes for which the expression is true. I saw a xalan integration in the code, possibly for the same purpose. Is there a way to extend jxpath with functionality that uses the model (or the nodepointer) itself to execute the rest of the query? TIA, Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
Simon Kitching wrote: BTW, should we contact the car companies, and tell them their customers prefer suffixes? Focus Ford Mustang Ford Thunderbird Ford (I'm mostly kidding...) I think the analogy is incomplete, you forgot the objet being qualified by the brand. Would you say Car Ford Focus Car Ford Mustang Car Ford Thunderbird rd or Ford Focus Car Ford Mustang Car Ford Thunderbird Car ? :) Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33323] - [logging] Ant build script does not create commons-logging-optional.jar
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=33323. 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=33323 [EMAIL PROTECTED] changed: What|Removed |Added OS/Version|Windows XP |All Platform|PC |All Summary|Ant build script does not |[logging] Ant build script |create commons-logging- |does not create commons- |optional.jar|logging-optional.jar -- 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]
[GUMP@brutus]: Project commons-id (in module jakarta-commons-sandbox) 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-id has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 3 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-id : Commons Identifier Package Full details are available at: http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-id/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-id-01022005.jar] identifier set to project name -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id/project.properties -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-id/gump_work/build_jakarta-commons-sandbox_commons-id.html Work Name: build_jakarta-commons-sandbox_commons-id (Type: Build) Work ended in a state of : Failed Elapsed: 1 sec Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id] 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/discovery/dist/commons-discovery.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/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar - __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0.2 org.apache.maven.MavenException: Error reading XML or initializing at org.apache.maven.MavenUtils.getProject(MavenUtils.java:156) at org.apache.maven.MavenUtils.getProject(MavenUtils.java:122) at org.apache.maven.MavenSession.initializeRootProject(MavenSession.java:232) at org.apache.maven.MavenSession.initialize(MavenSession.java:172) at org.apache.maven.cli.App.doMain(App.java:475) at org.apache.maven.cli.App.main(App.java:1239) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) --- Nested Exception --- java.io.FileNotFoundException: Parent POM not found: /home/gump/workspaces2/public/workspace/jakarta-commons-sandbox/sandbox-build/project.xml at org.apache.maven.MavenUtils.getNonJellyProject(MavenUtils.java:230) at org.apache.maven.MavenUtils.getProject(MavenUtils.java:143) at org.apache.maven.MavenUtils.getProject(MavenUtils.java:122) at org.apache.maven.MavenSession.initializeRootProject(MavenSession.java:232) at org.apache.maven.MavenSession.initialize(MavenSession.java:172) at org.apache.maven.cli.App.doMain(App.java:475) at org.apache.maven.cli.App.main(App.java:1239) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) You have encountered an unknown error
svn commit: r149381 - in jakarta/commons/proper/jelly/trunk/jelly-tags/interaction: maven.xml project.xml xdocs/changes.xml
Author: brett
Date: Tue Feb 1 01:56:13 2005
New Revision: 149381
URL: http://svn.apache.org/viewcvs?view=revrev=149381
Log:
correct formatting, demo execution
Modified:
jakarta/commons/proper/jelly/trunk/jelly-tags/interaction/maven.xml
jakarta/commons/proper/jelly/trunk/jelly-tags/interaction/project.xml
jakarta/commons/proper/jelly/trunk/jelly-tags/interaction/xdocs/changes.xml
Modified: jakarta/commons/proper/jelly/trunk/jelly-tags/interaction/maven.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/jelly/trunk/jelly-tags/interaction/maven.xml?view=diffr1=149380r2=149381
==
--- jakarta/commons/proper/jelly/trunk/jelly-tags/interaction/maven.xml
(original)
+++ jakarta/commons/proper/jelly/trunk/jelly-tags/interaction/maven.xml Tue Feb
1 01:56:13 2005
@@ -14,16 +14,18 @@
limitations under the License.
--
project default=jar:jar
-
- goal name=demo prereqs=
- description=Non-functioning demo yet.
- echoUsing classpath:/echo
-
echo${pom.getDependencyClasspath()}:target/${pom.name}-${pom.currentVersion}.jar/echo
-java
classpath=${pom.getDependencyClasspath()}:target/${pom.name}-${pom.currentVersion}.jar
- classname=org.apache.commons.jelly.Jelly fork=true
- arg
file=src/test/org/apache/commons/jelly/tags/interaction/sample.jelly/
- /java
-/goal
-
+ goal name=demo prereqs=jar:jar
+ description=Non-functioning demo yet.
+java classname=org.apache.commons.jelly.Jelly fork=yes
+ !-- This does not currently work due to a bug in jline - it extracts
+ a DLL into %TEMP% on Windows, but both the parent and forked process
+ use it --
+ classpath
+path refid=maven.dependency.classpath/
+pathelement location=${maven.build.dest} /
+ /classpath
+ arg
value=src/test/org/apache/commons/jelly/tags/interaction/sample.jelly/
+/java
+ /goal
/project
Modified: jakarta/commons/proper/jelly/trunk/jelly-tags/interaction/project.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/jelly/trunk/jelly-tags/interaction/project.xml?view=diffr1=149380r2=149381
==
--- jakarta/commons/proper/jelly/trunk/jelly-tags/interaction/project.xml
(original)
+++ jakarta/commons/proper/jelly/trunk/jelly-tags/interaction/project.xml Tue
Feb 1 01:56:13 2005
@@ -1,7 +1,7 @@
?xml version=1.0 encoding=UTF-8?
!--
- Copyright 2002,2004 The Apache Software Foundation.
+ Copyright 2002-2005 The Apache Software Foundation.
Licensed under the Apache License, Version 2.0 (the License);
you may not use this file except in compliance with the License.
@@ -20,7 +20,7 @@
extend${basedir}/../tag-project.xml/extend
idcommons-jelly-tags-interaction/id
namecommons-jelly-tags-interaction/name
- currentVersion1.1/currentVersion
+ currentVersion1.1-SNAPSHOT/currentVersion
packageorg.apache.commons.jelly.tags.interaction/package
descriptionThis is a Jelly interface to the user./description
shortDescriptionCommons Jelly Interaction Tag Library/shortDescription
@@ -33,12 +33,11 @@
/versions
dependencies
- dependency
-groupIdjline/groupId
-artifactIdjline/artifactId
-version0.9.0/version
-typejar/type
- /dependency
+dependency
+ groupIdjline/groupId
+ artifactIdjline/artifactId
+ version0.9.0/version
+/dependency
dependency
idcommons-cli/id
version1.0/version
@@ -57,6 +56,6 @@
version20030211.213356/version
/dependency
- /dependencies
+ /dependencies
/project
Modified:
jakarta/commons/proper/jelly/trunk/jelly-tags/interaction/xdocs/changes.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/jelly/trunk/jelly-tags/interaction/xdocs/changes.xml?view=diffr1=149380r2=149381
==
--- jakarta/commons/proper/jelly/trunk/jelly-tags/interaction/xdocs/changes.xml
(original)
+++ jakarta/commons/proper/jelly/trunk/jelly-tags/interaction/xdocs/changes.xml
Tue Feb 1 01:56:13 2005
@@ -24,9 +24,9 @@
author email=[EMAIL PROTECTED]dIon Gillard/author
/properties
body
- action dev=polx type=add issue=JELLY-175 due-to=Ryan
Christianson
- AskTag now uses JLine which allows history,
auto-completion,
- and edition of answers./action
+release version=1.1-SNAPSHOT date=in SVN
+ action dev=polx type=add issue=JELLY-175 due-to=Ryan
ChristiansonAskTag now uses JLine which allows history, auto-completion, and
edition of answers./action
+/release
release version=1.0 date=2004-09-12/release
/body
/document
[GUMP@brutus]: Project commons-jelly-tags-velocity (in module commons-jelly) success, but with warnings.
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-velocity contains errors. The current state of this project is 'Success'. Full details are available at: http://brutus.apache.org/gump/public/commons-jelly/commons-jelly-tags-velocity/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-velocity-01022005.jar] identifier set to project name -ERROR- Multiple outputs defined by project jakarta-velocity; an id attribute is required to select the one you want -ERROR- Unhandled Property: maven.jar.velocity on: Maven on Project:commons-jelly-tags-velocity -DEBUG- Dependency on jakarta-velocity exists, no need to add for property maven.jar.velocity. -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/velocity/build.properties -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/velocity/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/velocity/project.properties -INFO- No license on redistributable project with outputs. -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/velocity/target/test-reports The following work was performed: http://brutus.apache.org/gump/public/commons-jelly/commons-jelly-tags-velocity/gump_work/build_commons-jelly_commons-jelly-tags-velocity.html Work Name: build_commons-jelly_commons-jelly-tags-velocity (Type: Build) Work ended in a state of : Success Elapsed: 6 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/velocity] 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/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/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-01022005.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-01022005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-01022005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-01022005.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-dep-01022005.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-01022005.jar - __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0.2 You are working offline so the build will continue, but commons-jelly-SNAPSHOT.jar may be out of date! build:start: java:prepare-filesystem: [mkdir] Created dir: /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/velocity/target/classes java:compile: [echo] Compiling to /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/velocity/target/classes [echo] == NOTE: Targetting JVM 1.4, classes will not run on earlier JVMs == [javac] Compiling 4 source files to /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/velocity/target/classes java:jar-resources: test:prepare-filesystem: [mkdir] Created dir: /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/velocity/target/test-classes [mkdir] Created dir: /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/velocity/target/test-reports test:test-resources: test:compile: [javac] Compiling 1 source file to /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/velocity/target/test-classes test:test: jar:jar:
[GUMP@brutus]: Project commons-jelly-tags-util (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-util has an issue affecting its community integration. This issue affects 7 projects, and has been outstanding for 7 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-ant : Commons Jelly - commons-jelly-tags-fmt : Commons Jelly - commons-jelly-tags-html : Commons Jelly - commons-jelly-tags-jsl : Commons Jelly - commons-jelly-tags-util : Commons Jelly - maven : Project Management Tools - maven-bootstrap : Project Management Tools Full details are available at: http://brutus.apache.org/gump/public/commons-jelly/commons-jelly-tags-util/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-util-01022005.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/util/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/util/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/util/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/util/target/test-reports -WARNING- No directory [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/util/target/test-reports] -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/commons-jelly/commons-jelly-tags-util/gump_work/build_commons-jelly_commons-jelly-tags-util.html Work Name: build_commons-jelly_commons-jelly-tags-util (Type: Build) Work ended in a state of : Failed Elapsed: 5 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/util] 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/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/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/optional/bean-collections/dist/commons-beanutils-bean-collections.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-01022005.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-01022005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-01022005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-01022005.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-01022005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-01022005.jar - __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0.2 You are working offline so the build will continue, but commons-jelly-SNAPSHOT.jar may be out of date! build:start: java:prepare-filesystem: [mkdir] Created dir: /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/util/target/classes java:compile: [echo] Compiling to /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/util/target/classes [echo] == NOTE: Targetting JVM 1.4, classes will not run on earlier JVMs == [javac] Compiling 9 source files to /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/util/target/classes [javac]
svn commit: r149383 - jakarta/commons/proper/jelly/trunk/jelly-tags/velocity/project.xml
Author: brett Date: Tue Feb 1 02:13:07 2005 New Revision: 149383 URL: http://svn.apache.org/viewcvs?view=revrev=149383 Log: specify gump id for velocity to eliminate warning Modified: jakarta/commons/proper/jelly/trunk/jelly-tags/velocity/project.xml Modified: jakarta/commons/proper/jelly/trunk/jelly-tags/velocity/project.xml URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/jelly/trunk/jelly-tags/velocity/project.xml?view=diffr1=149382r2=149383 == --- jakarta/commons/proper/jelly/trunk/jelly-tags/velocity/project.xml (original) +++ jakarta/commons/proper/jelly/trunk/jelly-tags/velocity/project.xml Tue Feb 1 02:13:07 2005 @@ -44,6 +44,7 @@ urlhttp://jakarta.apache.org/velocity//url properties gump.projectjakarta-velocity/gump.project +gump.idvelocity/gump.id /properties /dependency - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r149313 - in jakarta/commons/sandbox/javaflow/trunk/src: java/org/apache/commons/javaflow/ java/org/apache/commons/javaflow/bytecode/bcel/ test/org/apache/commons/javaflow/ test/org/apache/commons/javaflow/testcode/
Closing an OutputStream twice is a bug or is it indeed nitpicking? ;) Bummer missed that one :) That nitpicking was not aimed at your submission. ...it was on a new line on the commit message ;) Well, the point is that the file writing code is temporary anyway. I should go away in the near future. That's why fixing it is not that important. Btw: for some reason I've some problem applying your patches with eclipse :-/ ...most of the hunks are not being found. I was thinking that it might make sense for me to work on some docs as well... might be a good opportunity for me to dig deeper through things as well as put down in words what I'm seeing and learn a few things from you about the overall design. Thoughts? Sounds awesome! cheers -- Torsten signature.asc Description: OpenPGP digital signature
svn commit: r149385 - jakarta/commons/sandbox/javaflow/trunk/src/java/org/apache/commons/javaflow/bytecode/bcel/BcelClassTransformer.java
Author: tcurdt
Date: Tue Feb 1 02:50:06 2005
New Revision: 149385
URL: http://svn.apache.org/viewcvs?view=revrev=149385
Log:
don't close the output stream twice
Modified:
jakarta/commons/sandbox/javaflow/trunk/src/java/org/apache/commons/javaflow/bytecode/bcel/BcelClassTransformer.java
Modified:
jakarta/commons/sandbox/javaflow/trunk/src/java/org/apache/commons/javaflow/bytecode/bcel/BcelClassTransformer.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/javaflow/trunk/src/java/org/apache/commons/javaflow/bytecode/bcel/BcelClassTransformer.java?view=diffr1=149384r2=149385
==
---
jakarta/commons/sandbox/javaflow/trunk/src/java/org/apache/commons/javaflow/bytecode/bcel/BcelClassTransformer.java
(original)
+++
jakarta/commons/sandbox/javaflow/trunk/src/java/org/apache/commons/javaflow/bytecode/bcel/BcelClassTransformer.java
Tue Feb 1 02:50:06 2005
@@ -115,7 +115,6 @@
out = new FileOutputStream(path + .orig);
out.write(orig);
out.flush();
-out.close();
} catch (final IOException e) {
e.printStackTrace();
@@ -185,7 +184,6 @@
out = new FileOutputStream(clazzGen.getClassName() + .rewritten);
out.write(changed);
out.flush();
-out.close();
} catch (final IOException e) {
e.printStackTrace();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r149313 - in jakarta/commons/sandbox/javaflow/trunk/src: java/org/apache/commons/javaflow/ java/org/apache/commons/javaflow/bytecode/bcel/ test/org/apache/commons/javaflow/ test/org/apache/commons/javaflow/testcode/
Torsten Curdt wrote: Well, the point is that the file writing code is temporary anyway. I should go away in the near future. That's why fixing it is not that important. Yes, I was going to ask about that one... can you let me in on your plans for this? I agree that it should go away, but I haven't spent any time rethinking this. Btw: for some reason I've some problem applying your patches with eclipse :-/ ...most of the hunks are not being found. How goofy. The subclipse client isn't as painfree as the cvs one from what I can tell. The team synchronizing perspective occasionally indicates to me that there differences between local and remote when there are none. I'm not sure what could cause this... will investigate. phil. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Net] Bug in FTPFile.Timestamp near end of month
What version of commons-net are you using?
The latest versions on the site (nightly build, source or binary) have a
fix for this problem. It explicitly lets you set a time zone for the
ftp server so that you can get correct dates. In fact, you who have a
real need for this functionality, would be an ideal person to try this
out. If you are interested I will happily help you through any
difficulties you may have with this, although I think you will find it
easy enough to use.
Steve Cohen
W. McDonald Buck wrote:
I'm reporting a minor bug in UnixFTPEntryParser.java, in computing the
timestamp for an FTPFile. I looked briefly at the parsers for the other
systems, and didn't see a similar problem. I'm not subscribed to this
list so please send any response by email.
Scenario:
It is January 31, 2005 at 10:00pm in Boulder, Colorado.
I'm using org.apache.commons.net.ftp to parse a directory of files on a
server 3 timezones to the east, comparing timestamps on the files using
FTPFile.getTimestamp(). I'm getting a wrong answer.
Problem: I'm looking at a file just created in Washington, D.C. and it
is already February 1, 2005 there. The following code in
UnixFTPEntryParser @ line 205 is wrong:
// if the month we're reading is greater than now, it must
// be last year
if (cal.get(Calendar.MONTH) month)
{
year--;
}
cal.set(Calendar.YEAR, year);
At this point month contains the month number of the file, scanned off
the returned ls. This code compares the remote file's month of creation
to the current month on the local machine, and if greater than the local
month, subtracts 1 from the year.
Since the file I'm looking at was created moments ago in Washington,
D.C. where it is already Feb 1, 2005, but it is still Jan 31, 2005 in
Boulder, where the code is running, the test above subtracts 1 from the
year, and sets the timestamp of the FTPFile to Feb 1, 2004 -- off by a
year.
A solution which allows for files in earlier timezones to be a few hours
ahead will, of course, create a bug for files which are a few hours less
than a year old in the current or lagging time zones. Is it fair to say
that precision of measurement is more likely to be important on files a
few hours old than on files already a year old? That is true for me at
least.
I'm not set up to send you a patch for this, but wouldn't it be simple
just to add one day, to compensate for possible time zone differences,
i.e. :
cal.add(Calendar.DAY_OF_MONTH,1);
if (cal.get(Calendar.MONTH)month)
{
year--;
}
cal.add(Calendar.DAY_OF_MONTH,-1);
cal.set(Calendar.YEAR, year);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[BeanUtils] Could be changed propertyUtilsBean.findNextNestedInde x(String expression) modifier to protected ?
Hi. This message is for BeanUtils folks. Coulbe be changed findNextNestedIndex modifier from private to protected ? It's to avoid to senselessly copy out this algo in custom PropertyUtilsBean subclasses to get exactly same feature. Thanks. -- Marc DeXeT Centre National de la Recherche Scientifique.
Re: [digester] initial code for Digester2.0
--- Simon Kitching [EMAIL PROTECTED] wrote: Does this mean you prefer Action to Rule? I certainly expect to hear from people who want to keep the current names... I'm not wedded to Rule but I do have a concern about Action. I suspect it could make Struts code rather confusing. __ Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. http://info.mail.yahoo.com/mail_250 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
--- Simon Kitching [EMAIL PROTECTED] wrote: Ok, we'll see what the general consensus is. I happen to personally like prefixes rather than suffixes, but will go with the majority opinion. I vote for prefixes. That sounds reasonable. However I do dislike having mutual dependencies between java packages; a DAG (directed acyclic graph) is good for a number of reasons. I strongly agree. Cyclic package dependencies seem unimportant when you only have a few classes, but as the amount of code grows, you quickly find that testing and refactoring because much more difficult than it had to be. __ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[contract] class diagram
This server is not so good, but works sometimes ... http://www.drianoxaman.kit.net/sandbox/contract.zip Woody - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
Reid Pinchback wrote: I strongly agree. Cyclic package dependencies seem unimportant when you only have a few classes, but as the amount of code grows, you quickly find that testing and refactoring because much more difficult than it had to be. Can you give an example of a difficult refactoring due to a cyclic dependency between 2 packages ? I'm not sure to understand the practical issue. Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
Simon Kitching wrote: Does this mean you prefer Action to Rule? I certainly expect to hear from people who want to keep the current names... No preference there, [and I'll get used to prefix/suffix, whichever way it goes, it's not THAT big of a deal, but you asked...] -- Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] proposal: FileUtils
Continuing the command pattern, I rejiggered the Save command to use a
Backup command rather than hard-coding the backup policy:
public class Save implements IOOperation {
private final Backup backup;
private final InputStream newContents;
private final FuFile original;
public Save(final Backup backup, final InputStream newContents,
final FuFile original) {
if (null == backup) throw new NullPointerException();
if (null == newContents) throw new NullPointerException();
if (null == original) throw new NullPointerException();
this.backup = backup;
this.newContents = newContents;
this.original = original;
}
public void execute()
throws IOException {
backup.prepare(original,
new Write(newContents, original)).execute();
}
}
Notice the prepare method which is an example of delayed
initialization. Since Backup needs a next operation, but Save both
needs a Backup and creates the next operation (a Write command), I
cannot both create an immutable Backup and create an immutable Save at
the same time.
And looking at Backup:
public abstract class Backup implements IOOperation {
protected final FuPolicy policy;
private FuFile original;
private IOOperation next;
protected Backup(final FuPolicy policy) {
if (null == policy) throw new NullPointerException();
this.policy = policy;
}
protected FuFile getOriginal() {
return original;
}
protected IOOperation getNext() {
return next;
}
public Backup prepare(final FuFile original, final IOOperation next) {
if (null == original) throw new NullPointerException();
if (null == next) throw new NullPointerException();
this.original = original;
this.next = next;
return this;
}
}
And two implementations:
public class NoBackup extends Backup {
public NoBackup(final FuPolicy policy) {
super(policy);
}
public void execute()
throws IOException {
final FuFile original = getOriginal();
new Delete(original, policy.createScratch(original),
getNext()).execute();
}
}
public class SimpleBackup extends Backup {
public SimpleBackup(final FuPolicy policy) {
super(policy);
}
public void execute()
throws IOException {
final FuFile original = getOriginal();
final FuFile backup = policy.createBackup(original);
new Delete(backup, policy.createScratch(backup),
new Move(original, backup, getNext())).execute();
}
}
The second implementation, SimpleBackup, implements the policy
hard-coded previously in Save.
I still use the FuPolicy object to decide how to make a temporary and a
backup file. I think that creating a backup should be merged into the
Backup object instead, but I haven't decided what the best way to do
that is. The problem scenario is an Emacs-scheme multiple backup (e.g.,
foo.txt, foo.txt.~1~, foo.txt.~2~, etc.). There the policy for naming
backups and the backup command are very intimate, and really belong in
the same object.
Cheers,
--binkley
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32360] - [jxpath] Default Namespace not handled correctly
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=32360. 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=32360 --- Additional Comments From [EMAIL PROTECTED] 2005-02-01 17:16 --- We're having similar problems as Richard has. Especially in automation the current solution does not work well. The problem seems to be related to the nature of the binding. Right now the binding of prefix and namespace is done on the context and not on the query. This makes it impossible to distinguish between: a. the namespace bindings of the document itself, and b. the namespace bindings of context of the document. I will even go so far as to say the namespace binding solution, proposed in the XPath specification is too thin. The reasons in favor for the XPath solutions are clear though: uncluttered means of querying (binding for every XPath query would be too combersome). Nevertheless, the specs are how they are and we can't change much about that. The situation with JXPath is different than XPath. JXPath has the fortune of being able to access the same (set of) binding(s) multiple times without much clutter (by means of references). This makes at least a specific implementation of the query solver (through factory pattern) in my oppinion worthwhile. Especially in the eye of automation (regarding the creation of automatic bindings/matchers based on xsd analysis), this is a worthwhile feature. (In reply to comment #3) cut If I declare context.registerNamespace(null, http://test;) and then try: context.getValue(/parent/test/child-element) I get nothing, because parent does not have http://test; as its namespace. Yes, this would be a problem. Nevertheless, if I would create a subcontext (which is more than logical, since it is clearly in another namespace), then I can make an addditional binding. Thanks and regards, Edwin -- 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]
[digester] org.apache.commons.digester2
Big +1 for org.apache.commons.digester2! Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
Sure thing. Just to make it easier to envision, let's get
packages out of the equation. Just think about cyclic
dependencies between two classes in the same package.
That is enough to show the problem; packages just add complexity
because the dependencies can be much harder to detect visually
(usually you would use something like JDepend to spot them)
and harder to unwind.
Refactoring is harder simply because you have to do a larger
number of smaller steps. Doesn't mean impossible, more steps
just mean more work, more time, more money. Tricky enough when
only two classes are involved, harder as the number of classes
involved in the cycle increase. Get enough classes involved,
and you start to hear statements like it will be easier to
throw that away and start over again than it will be to fix it.
class A {
int a;
int fooA(int arg) {
// 1a. do stuff with {B.fooB,a,arg}
// 2a. do other stuff with result and {a}
}
}
class B {
int b1, b2;
int fooB(int arg) {
// 1b. do stuff with {A.fooA,b1,arg}
// 2b. do other stuff with result and b2
// 3b. do stuff with {A.fooA,b2,arg}
}
}
Refactoring remains possible, but tricky because
you have both compile-time code dependencies and
run-time state dependencies. You are faced with
things like factoring out small fragments of code
into helper classes, and maybe introducing an
interface to at least eliminate the compile-time
dependency between A and B, even if the run-time
dependency remains.
Often the solution ends up something like
a) make interface I
b) create class C implements I
and migrate some of A and B state into C
c) modify A and B to share I
It works, it just takes time... and often you
are doing it before even trying to tackle whatever
bug or feature enhancement you were faced with
in the first place.
__
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33331] New: - Custom Object-String Conversion in .betwixt file
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=1. 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=1 Summary: Custom Object-String Conversion in .betwixt file Product: Commons Version: Nightly Builds Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: Betwixt AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] This is a patch to allow ObjectStringConverter to be specified in .betwixt file. This allows a specific ObjectStringConverter class to be used for a specific element. The converter specified is only used for that element. All other elements use the DefaultObjectStringConverter. -- 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 33331] - Custom Object-String Conversion in .betwixt file
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=1. 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=1 --- Additional Comments From [EMAIL PROTECTED] 2005-02-01 17:57 --- Created an attachment (id=14151) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14151action=view) Fix to enable ObjectStringConverter specification in .betwixt file -- 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 33331] - [betwixt] Custom Object-String Conversion in .betwixt file
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=1. 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=1 [EMAIL PROTECTED] changed: What|Removed |Added OS/Version|Windows XP |All Platform|PC |All Summary|Custom Object-String |[betwixt] Custom Object- |Conversion in .betwixt file |String Conversion in ||.betwixt file -- 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]
[i18n] class diagram suggested
Hi folks, I make some changes in my i18n version and the final class diagram is given in link below: http://www.drianoxaman.kit.net/sandbox/i18n_suggestion.zip Woody - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
I very much like that and think it really is straight forward. Comments: - Why is Action an abstract class? - Wouldn't it be possible (and even desirable) to have a more general Pattern class instead of a String in Digester#addRule? - I like the bodySegment vs. body design :) - I like the no dependency and digester2 package approach - It's no secret that I am no fun of reflection stuff: is it really necessary to have the subclasses of Action be part of the *very*, *very* digester *core*? If so I would be more than happy to abandon xmlio (in) as - apart from philosophical considerations - it would be superfluous and I would offer development support for digester if that is welcome. Oliver On Mon, 31 Jan 2005 23:09:28 +1300, Simon Kitching [EMAIL PROTECTED] wrote: Hi, As I mentioned a few months ago, I've been working on some ideas for Digester 2.0. I've put some code and notes up on http://www.apache.org/~skitching Comments from all commons-dev subscribers are welcome, but particularly from Craig and Robert. The RELEASE-NOTES.txt file gives a brief overview of what I've done so far, and what I personally would like to see. This is *not* intended to be final code, but rather to solicit yes/no feedback on what people like/dislike about the posted code. As you will see, many parts are still missing and I personally would still like to see significant changes even to parts already included (see RELEASE-NOTES.txt). However the basic structure is there, including a number of controversial (I expect) name changes. Once we get the general opinions out, and I have massaged the code into something that meets general concensus I hope to then add it to the sandbox for everyone to hack away at. Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33336] New: - CountingInputStream.getCount() often returns invalid values.
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=6.
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=6
Summary: CountingInputStream.getCount() often returns invalid
values.
Product: Commons
Version: 1.0 Final
Platform: PC
OS/Version: Linux
Status: NEW
Severity: major
Priority: P2
Component: IO
AssignedTo: commons-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
In all read methods there is code like this:
int found = super.read(b);
this.count += found;
return found;
or like this:
this.count++;
return super.read();
It is ok until we will reach EOF. In this case super.read() returns -1, and
decreases count in the first case, and increases in the second. In such case
count should not be changed. So when we have something like this:
File file = new File(somefile.txt) //File with text 123 and no newlines
CountingInputStream cis = new CountingInputStream(new FileInputStream (file));
BufferedReader reader = new BufferedReader(new InputStreamReader(cis));
while(reader.read() != -1) {}
After this code when we call cis.getCount() it will return 2, while number of
bytes in read file is 3.
--
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 33336] - [io] CountingInputStream.getCount() often returns invalid values
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=6. 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=6 [EMAIL PROTECTED] changed: What|Removed |Added Summary|CountingInputStream.getCount|[io] |() often returns invalid|CountingInputStream.getCount |values. |() often returns invalid ||values -- 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]
[dbutils] component proposal
Hi folks, I dono if you are open for this idea or if this topic was already discussed but let me explain: I´m working on a project where I decide to use the pattern Data Transfer Rowset (a fast lane reader) given by Marinescu on book EJB Design Patterns. When I decided this (four months ago) I do some research and look for some open source implementations but the only implementation I found was the sun CachedRowset implementation (with SCSL license and, for java 1.4.2, the sources is unavailable). The version done by sun was done for use with java 1.4.2 (and I was using WAS 4, with java 1.3.1!!!) I faced many problems with this (and my envinronment) and, yet now, does not exist a CachedRowset implementation ... Months ago, when sun releases tiger, I try to see the sources looking for the CachedRowsetImpl but this source is not given yet (and, as I see, never will). I know there is another implementation, but is not open source too (is from oracle, with huge bugs). I think this is the right place to a component like this. I'm right? I have some work done in this direction and wanna knows if can I help (with hands on). Tks Woody - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbutils] component proposal
DbUtils is a small JDBC helper library. We don't implement features that already exist in the standard Java distro. David --- Anaximandro (Woody) [EMAIL PROTECTED] wrote: Hi folks, I dono if you are open for this idea or if this topic was already discussed but let me explain: I´m working on a project where I decide to use the pattern Data Transfer Rowset (a fast lane reader) given by Marinescu on book EJB Design Patterns. When I decided this (four months ago) I do some research and look for some open source implementations but the only implementation I found was the sun CachedRowset implementation (with SCSL license and, for java 1.4.2, the sources is unavailable). The version done by sun was done for use with java 1.4.2 (and I was using WAS 4, with java 1.3.1!!!) I faced many problems with this (and my envinronment) and, yet now, does not exist a CachedRowset implementation ... Months ago, when sun releases tiger, I try to see the sources looking for the CachedRowsetImpl but this source is not given yet (and, as I see, never will). I know there is another implementation, but is not open source too (is from oracle, with huge bugs). I think this is the right place to a component like this. I'm right? I have some work done in this direction and wanna knows if can I help (with hands on). Tks Woody - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
On 2005-01-31 9:59:52, Simon Kitching wrote: As I mentioned a few months ago, I've been working on some ideas for Digester 2.0. I've put some code and notes up on http://www.apache.org/~skitching Simon, Joran classes and documentation mention that it is influenced by Digester. Is your design for Digester 2.0 influenced by Joran? If it is, this should be mentioned as a matter courtesy. Regards, -- Ceki Gülcü The complete log4j manual: http://www.qos.ch/log4j/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33331] - [betwixt] Custom Object-String Conversion in .betwixt file
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=1. 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=1 --- Additional Comments From [EMAIL PROTECTED] 2005-02-01 20:43 --- Created an attachment (id=14154) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14154action=view) Patch for fixing compile failure on anonymous inner classes Fix problems with MapEntryAdder, ArryBindAction - forgot to clean first -- 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: [dbutils] component proposal
DbUtils is a small JDBC helper library. We don't implement features that already exist in the standard Java distro. David David, I don't think this feature is standard (you need to download 2 jars from sun to use this feature) But is ok, thanx by reply. Woody - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Identify Class Loader Problems
On 2005-01-27 22:52:02, Richard Sitze wrote: A. Parent / Child ClassLoaders, General - commons-logging.jar#org.apache.commons.logging.Log is loaded/loadable by Parent. - Child is the thread context ClassLoader. - Parent defines a LogAWrapper for LogAImpl - Child defines a LogAImpl Problem: 1. Discovery finds Child[LogAImpl], and attempts to instantiate LogAWrapper in Parent. Fails, because Parent cannot see child. Richard, Forgive my nitpicking, but what do you mean exactly by LogAWrapper? By LogAImpl? Many thanks in advance for your response. -- Ceki Gülcü The complete log4j manual: http://www.qos.ch/log4j/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Identify Class Loader Problems
Ceki Gülcü [EMAIL PROTECTED] wrote on 02/01/2005 01:55:13 PM: On 2005-01-27 22:52:02, Richard Sitze wrote: A. Parent / Child ClassLoaders, General - commons-logging.jar#org.apache.commons.logging.Log is loaded/loadable by Parent. - Child is the thread context ClassLoader. - Parent defines a LogAWrapper for LogAImpl - Child defines a LogAImpl Problem: 1. Discovery finds Child[LogAImpl], and attempts to instantiate LogAWrapper in Parent. Fails, because Parent cannot see child. Richard, Forgive my nitpicking, but what do you mean exactly by LogAWrapper? By LogAImpl? By wrapper, I mean a commons-logging wrapper class. by impl, I mean a target logger implementation, such as Log4J. This is, I believe, the Log4J problem you've previously described. Where you drop Log4J in the client, and it caused the discovery mechanism to throw an exception. LogA is any logger... such as Log4J: Discovery finds Child[Log4J], and attempts to instantiate Log4JLogger in Parent. Fails, because Parent cannot see child: org.apache.commons.logging.impl.Log4JLogger [in parent] cannot load org.apache.log4j.Logger [in child]. Many thanks in advance for your response. -- Ceki Gülcü The complete log4j manual: http://www.qos.ch/log4j/ *** Richard A. Sitze IBM WebSphere WebServices Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r149154 - jakarta/commons/proper/httpclient/trunk/src/test/org/apache/commons/httpclient/ssl/SimpleSSLSocketFactory.java jakarta/commons/proper/httpclient/trunk/src/test/org/apache/commons/httpclient/ssl/SimpleSSLTestProtocolSocketFactory.java
On Mon, 2005-01-31 at 06:44 +0800, Brett Porter wrote: Yuck :) Can we help fix this? IIRC, other people having problems have corrected them by using /org/apache/commons/... (note leading /). Brett, Unfortunately this doesn't help. The trouble is that junit resource files do not seem to be copied to HOME/target/test-classes/ If I manually copy the required resources to HOME/target/test-classes/ test cases perform as expected Oleg It's been a while since I read the spec on this but it is because no / has a different classloader search criteria which doesn't work inside Maven. I think another alternative is to fork the unit tests. If these resolutions are correct, its probably time for a FAQ entry... - Brett Quoting [EMAIL PROTECTED] [EMAIL PROTECTED]: Author: olegk Date: Sun Jan 30 13:02:40 2005 New Revision: 149154 URL: http://svn.apache.org/viewcvs?view=revrev=149154 Log: Maven workaround - 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] history lessons revisited
robert burrell donkin [EMAIL PROTECTED] wrote on 01/30/2005 04:09:54 PM: On 28 Jan 2005, at 20:15, Richard Sitze wrote: [re-send.. I don't see this picked up... hmmm] Once, a long long time ago... someone wrote: The problem: it won't work if commons-logging.jar is installed in the parent class loader, and log4j.jar ( or another logger ) is installed in a child loader ( like WEB-INF/lib ). What happens: - the factory uses the thread class loader to check if the log4j ( or any other impl. ) exists ( and it does ). - it creates an instance of the Logger adapter. This will be created using parent loader ( the one that loads commons-logging ). - the Logger instance makes references to Category or other classes that are used in it's implementation. End of story, since the class loader can't find the reference. This works fine for JAXP because the adapter for a parser is part of the parser jar. It doesn't work for c-l because the adapter is in the root loader ( with the API), not with the logging impl. That doesn't affect people who just use a single logger or can put the logger impl. in the same place with common-logging. It only affect containers like tomcat, when you want to let each webapp use it's own logger impl. of choice. I tried all kind of introspection games, it won't work. The only solution I see is to make sure the adapters are in the same place with the logger. Solution: Split commons-logging.jar in commons-logging-api.jar ( only the API and the LogFactoryImpl, no adapteer ) and commons-logging-impl.jar. Alternatively, leave commons-logging.jar as it is and create a second commons-logging-api.jar. The -api will be included in the common loader. Each webapp will have to include commons-logging.jar ( or -impl ), and it's own logger. Or course, the best would be to have the adapter included in the logger impl. What do you think ? Craig, Remy can we make another c-l dot release with this change ? ( I'll do some more testing to see how it works ) i suspect that this solution may run into some issues with the way that JCL 1.0.x is factored into API and implementation. of course, i'd be glad for someone to prove me wrong ;) And now I ask... is it *ever* appropriate to use to the Thread Context Class Loader for our auto detect of impls? The correct class loader to use is *always* the classloader used to load the wrapper. No? yes: the test should always be performed with the classloader that used to load the wrapper. Ok, so this was my main focus/point on this topic. I know we use the context class loader for some situations [and it's appropriate to do so]. Beginning to recognize that we don't need to take a 'carte-blanc' toward this. Is this something you'd like to capture for the 1.0.5 release? It resolves point A in my summary of class loader issues. (i seem to recall a discussion about this on the commons logging list sometime in the last few months but i can't remember whether any subtle issues emerged...) it may be appropriate to use the thread context class loader if that's the one to be used to load the wrapper. i wonder whether it might make sense for logging implementations to be passed in the classloader which should be used to load whatever classes they required... - robert *** Richard A. Sitze IBM WebSphere WebServices Development
Re: [GUMP@brutus]: Project commons-jelly-tags-util (in module commons-jelly) failed
taglib should depend on beanutils-core and beanutils-collections from beanutils 1.7. probably just need to update the project.xml. i'm having machine and subversion problems (my much-loved cube blew up last week) or i'd sort this out myself. - robert On Tue, 2005-02-01 at 00:59, Brett Porter wrote: It's specified, but Maven isn't going to use it because it isn't listed in the dependencies. Either the util taglib needs to upgrade to beanutils 1.7, or there needs to be a beanutils 1.6 in gump. - Brett Quoting Dion Gillard [EMAIL PROTECTED]: This looks like either a missing or wrong dependency. util should depend on commons-beanutils-collections or whatever it's called for gump. On Mon, 31 Jan 2005 02:07:20 PST, commons-jelly-tags-util development commons-dev@jakarta.apache.org wrote: 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-util has an issue affecting its community integration. This issue affects 7 projects, and has been outstanding for 5 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-ant : Commons Jelly - commons-jelly-tags-fmt : Commons Jelly - commons-jelly-tags-html : Commons Jelly - commons-jelly-tags-jsl : Commons Jelly - commons-jelly-tags-util : Commons Jelly - maven : Project Management Tools - maven-bootstrap : Project Management Tools Full details are available at: http://brutus.apache.org/gump/public/commons-jelly/commons-jelly-tags-util/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-util-31012005.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/util/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/util/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/util/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/util/target/test-reports -WARNING- No directory [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/util/target/test-reports] -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/commons-jelly/commons-jelly-tags-util/gump_work/build_commons-jelly_commons-jelly-tags-util.html Work Name: build_commons-jelly_commons-jelly-tags-util (Type: Build) Work ended in a state of : Failed Elapsed: 5 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/util] CLASSPATH:
Re: [BeanUtils] Could be changed propertyUtilsBean.findNextNestedInde x(String expression) modifier to protected ?
my much-lovely cube blew up recently and my secondary development box is needing quite a bit of tweaking. please create a bug report so this doesn't get lost. (you might also need to remind me in a week or so if i don't get round to it by then.) - robert On Tue, 2005-02-01 at 13:00, Marc DEXET wrote: Hi. This message is for BeanUtils folks. Coulbe be changed findNextNestedIndex modifier from private to protected ? It's to avoid to senselessly copy out this algo in custom PropertyUtilsBean subclasses to get exactly same feature. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Commons Wiki] Updated: Logging/1.0.5ReleasePlan
Date: 2005-02-01T14:40:42 Editor: RobertBurrellDonkin Wiki: Jakarta Commons Wiki Page: Logging/1.0.5ReleasePlan URL: http://wiki.apache.org/jakarta-commons/Logging/1.0.5ReleasePlan note about status of plan Change Log: -- @@ -6,7 +6,7 @@ == Status == -RELEASE PLAN is waiting on conversion of repository to subversion +RELEASE PLAN is stalled (my much-loved cube blew up) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r149154 - jakarta/commons/proper/httpclient/trunk/src/test/org/apache/commons/httpclient/ssl/SimpleSSLSocketFactory.java jakarta/commons/proper/httpclient/trunk/src/test/org/apache/commons/httpclient/ssl/SimpleSSLTestProtocolSocketFactory.java
Quoting Oleg Kalnichevski [EMAIL PROTECTED]: On Mon, 2005-01-31 at 06:44 +0800, Brett Porter wrote: Yuck :) Can we help fix this? IIRC, other people having problems have corrected them by using /org/apache/commons/... (note leading /). Brett, Unfortunately this doesn't help. The trouble is that junit resource files do not seem to be copied to HOME/target/test-classes/ If you declare the resources inside your unit test element they should be: unitTest includes ... /includes resources resource directorysrc/test/directory includes include**/*.properties/include /includes /resource /resources /unitTest Does that help? Cheers, Brett If I manually copy the required resources to HOME/target/test-classes/ test cases perform as expected Oleg It's been a while since I read the spec on this but it is because no / has a different classloader search criteria which doesn't work inside Maven. I think another alternative is to fork the unit tests. If these resolutions are correct, its probably time for a FAQ entry... - Brett Quoting [EMAIL PROTECTED] [EMAIL PROTECTED]: Author: olegk Date: Sun Jan 30 13:02:40 2005 New Revision: 149154 URL: http://svn.apache.org/viewcvs?view=revrev=149154 Log: Maven workaround - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33340] New: - HelpFormatter doesn't function correctly for options with only LongOpt
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=33340.
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=33340
Summary: HelpFormatter doesn't function correctly for options
with only LongOpt
Product: Commons
Version: 1.0 Final
Platform: All
OS/Version: All
Status: NEW
Severity: major
Priority: P3
Component: CLI
AssignedTo: commons-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
The following doesn't work (org.apache.commons.cli.HelpFormatter
)correctly and doesn't print out the help menu of options
that only specify LongOpt.
The output is:
[java] usage: -a | -d | --shutdown | -s | -h [-r email] [-f flight] [-t]
[java] VendMore - Email Management System
[java] -t,--test test mode - makes no permanent changes.
[java] --shutdown shutdown rpc server.
[java] -a,--addadd user to email queue.
[java] -d,--delete delete user from email queue.
[java] -f,--flight flight which is the index into the email being sent
[java] -h,--help Print this usage information.
[java] -r recipient's email
[java] -s,--send send email command
[java] For more information, see Steve Morin
[java] Java Result: 1
it is missing the following options when printing the help display.
options.addOption(OptionBuilder.withDescription(hostname for the XmlRpc
client to connect to.).withLongOpt(hostname).create());
options.addOption(OptionBuilder.withDescription(port for the xmlrpc
client to use.).withLongOpt(port).create());
options.addOption(OptionBuilder.withDescription(additional xmlrpc
connection).withLongOpt(urlpath).create());
options.addOption(OptionBuilder.withDescription(add a parameter
form name=value.).hasArg().withLongOpt(params).create());
example of the offending code
private CommandLineParser cmd;
private Options options;
private OptionGroup ogmain;
public CmdLineArg() {
super();
cmd = new BasicParser();
options = new Options();
ogmain = new OptionGroup();
ogmain.setRequired(true);
localinit();
init();
}
public CommandLine run(String[] args) {
try {
options.addOption(OptionBuilder.withDescription(add a parameter
form name=value.).hasArg().withLongOpt(params).create());
options.addOption(OptionBuilder.withDescription(recipient's
email).hasArg().create('r'));
options.addOption(OptionBuilder.withDescription(flight which is
the index into the email being
sent).withLongOpt(flight).hasArg().create('f'));
options.addOption(OptionBuilder.withDescription(test mode - makes
no permanent changes.).withLongOpt(test).create('t'));
ogmain.addOption(OptionBuilder.withDescription(Print this usage
information.).withLongOpt(help).create('h'));
ogmain.addOption(OptionBuilder.withDescription(send email
command).withLongOpt(send).hasArg().create('s'));
ogmain.addOption(OptionBuilder.withDescription(add user to email
queue.).withLongOpt(add).create('a'));
ogmain.addOption(OptionBuilder.withDescription(delete user from email
queue.).withLongOpt(delete).create('d'));
ogmain.addOption(OptionBuilder.withDescription(shutdown rpc
server.).withLongOpt(shutdown).create());
options.addOption(OptionBuilder.withDescription(hostname for the XmlRpc
client to connect to.).withLongOpt(hostname).create());
options.addOption(OptionBuilder.withDescription(port for the xmlrpc
client to use.).withLongOpt(port).create());
options.addOption(OptionBuilder.withDescription(additional xmlrpc
connection).withLongOpt(urlpath).create());
options.addOptionGroup(this.ogmain);
return cmd.parse(options,args);
} catch (ParseException e) {
printUsage();
System.exit(1);
return null;
}
}
protected void printUsage(){
HelpFormatter helpFormatter = new HelpFormatter();
helpFormatter.printHelp(getUSAGE(),getHEADER(),options,getFOOTER());
}
--
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 33341] New: - HelpFormatter doesn't function correctly for options with only LongOpt
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=33341.
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=33341
Summary: HelpFormatter doesn't function correctly for options
with only LongOpt
Product: Commons
Version: 1.0 Final
Platform: All
OS/Version: All
Status: NEW
Severity: major
Priority: P2
Component: CLI
AssignedTo: commons-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
The following doesn't work (org.apache.commons.cli.HelpFormatter
)correctly and doesn't print out the help menu of options
that only specify LongOpt.
The output is:
[java] usage: -a | -d | --shutdown | -s | -h [-r email] [-f flight] [-t]
[java] VendMore - Email Management System
[java] -t,--test test mode - makes no permanent changes.
[java] --shutdown shutdown rpc server.
[java] -a,--addadd user to email queue.
[java] -d,--delete delete user from email queue.
[java] -f,--flight flight which is the index into the email being sent
[java] -h,--help Print this usage information.
[java] -r recipient's email
[java] -s,--send send email command
[java] For more information, see Steve Morin
[java] Java Result: 1
it is missing the following options when printing the help display.
options.addOption(OptionBuilder.withDescription(hostname for the XmlRpc
client to connect to.).withLongOpt(hostname).create());
options.addOption(OptionBuilder.withDescription(port for the xmlrpc
client to use.).withLongOpt(port).create());
options.addOption(OptionBuilder.withDescription(additional xmlrpc
connection).withLongOpt(urlpath).create());
options.addOption(OptionBuilder.withDescription(add a parameter
form name=value.).hasArg().withLongOpt(params).create());
example of the offending code
private CommandLineParser cmd;
private Options options;
private OptionGroup ogmain;
public CmdLineArg() {
super();
cmd = new BasicParser();
options = new Options();
ogmain = new OptionGroup();
ogmain.setRequired(true);
localinit();
init();
}
public CommandLine run(String[] args) {
try {
options.addOption(OptionBuilder.withDescription(add a parameter
form name=value.).hasArg().withLongOpt(params).create());
options.addOption(OptionBuilder.withDescription(recipient's
email).hasArg().create('r'));
options.addOption(OptionBuilder.withDescription(flight which is
the index into the email being
sent).withLongOpt(flight).hasArg().create('f'));
options.addOption(OptionBuilder.withDescription(test mode - makes
no permanent changes.).withLongOpt(test).create('t'));
ogmain.addOption(OptionBuilder.withDescription(Print this usage
information.).withLongOpt(help).create('h'));
ogmain.addOption(OptionBuilder.withDescription(send email
command).withLongOpt(send).hasArg().create('s'));
ogmain.addOption(OptionBuilder.withDescription(add user to email
queue.).withLongOpt(add).create('a'));
ogmain.addOption(OptionBuilder.withDescription(delete user from email
queue.).withLongOpt(delete).create('d'));
ogmain.addOption(OptionBuilder.withDescription(shutdown rpc
server.).withLongOpt(shutdown).create());
options.addOption(OptionBuilder.withDescription(hostname for the XmlRpc
client to connect to.).withLongOpt(hostname).create());
options.addOption(OptionBuilder.withDescription(port for the xmlrpc
client to use.).withLongOpt(port).create());
options.addOption(OptionBuilder.withDescription(additional xmlrpc
connection).withLongOpt(urlpath).create());
options.addOptionGroup(this.ogmain);
return cmd.parse(options,args);
} catch (ParseException e) {
printUsage();
System.exit(1);
return null;
}
}
protected void printUsage(){
HelpFormatter helpFormatter = new HelpFormatter();
helpFormatter.printHelp(getUSAGE(),getHEADER(),options,getFOOTER());
}
--
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: [logging] history lessons revisited
On Tue, 2005-02-01 at 20:27, Richard Sitze wrote: robert burrell donkin [EMAIL PROTECTED] wrote on 01/30/2005 04:09:54 PM: On 28 Jan 2005, at 20:15, Richard Sitze wrote: [re-send.. I don't see this picked up... hmmm] Once, a long long time ago... someone wrote: The problem: it won't work if commons-logging.jar is installed in the parent class loader, and log4j.jar ( or another logger ) is installed in a child loader ( like WEB-INF/lib ). What happens: - the factory uses the thread class loader to check if the log4j ( or any other impl. ) exists ( and it does ). - it creates an instance of the Logger adapter. This will be created using parent loader ( the one that loads commons-logging ). - the Logger instance makes references to Category or other classes that are used in it's implementation. End of story, since the class loader can't find the reference. This works fine for JAXP because the adapter for a parser is part of the parser jar. It doesn't work for c-l because the adapter is in the root loader ( with the API), not with the logging impl. That doesn't affect people who just use a single logger or can put the logger impl. in the same place with common-logging. It only affect containers like tomcat, when you want to let each webapp use it's own logger impl. of choice. I tried all kind of introspection games, it won't work. The only solution I see is to make sure the adapters are in the same place with the logger. Solution: Split commons-logging.jar in commons-logging-api.jar ( only the API and the LogFactoryImpl, no adapteer ) and commons-logging-impl.jar. Alternatively, leave commons-logging.jar as it is and create a second commons-logging-api.jar. The -api will be included in the common loader. Each webapp will have to include commons-logging.jar ( or -impl ), and it's own logger. Or course, the best would be to have the adapter included in the logger impl. What do you think ? Craig, Remy can we make another c-l dot release with this change ? ( I'll do some more testing to see how it works ) i suspect that this solution may run into some issues with the way that JCL 1.0.x is factored into API and implementation. of course, i'd be glad for someone to prove me wrong ;) And now I ask... is it *ever* appropriate to use to the Thread Context Class Loader for our auto detect of impls? The correct class loader to use is *always* the classloader used to load the wrapper. No? yes: the test should always be performed with the classloader that used to load the wrapper. Ok, so this was my main focus/point on this topic. I know we use the context class loader for some situations [and it's appropriate to do so]. Beginning to recognize that we don't need to take a 'carte-blanc' toward this. Is this something you'd like to capture for the 1.0.5 release? It resolves point A in my summary of class loader issues. (my much loved cube blew up recently stalling my plans both for the 1.0.5 release and for comments one your discovery thread.) probably not for a couple of reasons: * 1.0.5 contains code that plugs memory leaks on many popular J2EE platforms. changes to the discovery are risky. * there are a few potential issues which i need to find time to think about more carefully. (i will prepare some responses to your classloading thread soon.) (thanks to brian) i hope to be able to take a release branch soon. any worthy changes to the discovery code can then to made on HEAD. i'd be happy to roll a 1.0.6 release if this seems appropriate. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33340] - [cli] HelpFormatter doesn't function correctly for options with only LongOpt
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=33340. 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=33340 [EMAIL PROTECTED] changed: What|Removed |Added Summary|HelpFormatter doesn't |[cli] HelpFormatter doesn't |function correctly for |function correctly for |options with only LongOpt |options with only LongOpt -- 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 33341] - [cli] HelpFormatter doesn't function correctly for options with only LongOpt
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=33341. 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=33341 [EMAIL PROTECTED] changed: What|Removed |Added Summary|HelpFormatter doesn't |[cli] HelpFormatter doesn't |function correctly for |function correctly for |options with only LongOpt |options with only LongOpt -- 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: [BeanUtils] Could be changedpropertyUtilsBean.findNextNestedInde x(String expression) modifier toprotected ?
robert burrell donkin wrote: my much-lovely cube blew up recently and my secondary development box is needing quite a bit of tweaking. please create a bug report so this doesn't get lost. (you might also need to remind me in a week or so if i don't get round to it by then.) Ok, I'll do it tomorrow in the morning. RIP lovely cube. Marc DeXeT - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33342] New: - Change propertyUtilsBean.findNextNestedIndex(String expression) modifier to protected ?
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=33342. 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=33342 Summary: Change propertyUtilsBean.findNextNestedIndex(String expression) modifier to protected ? Product: Commons Version: unspecified Platform: PC OS/Version: Windows XP Status: NEW Severity: enhancement Priority: P2 Component: Bean Utilities AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Could be be changed findNextNestedIndex modifier from private to protected ? It's to avoid to senselessly copy out this algo in custom PropertyUtilsBean subclasses to get exactly same feature. Thanks. -- 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: [lang] new method on ClassUtils
I think that we would have to ask for classloader advice ;-) I suspect we would need: loadClassSystemClassLoader() - Class.forName loadClassThreadContextClassLoader() - thread loadClassLangClassLoader() - from ClassUtils loadClass(ClassLoader) ;-) Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] The important part for me is the munging that stops primitives being special and [] not working. I'm happy to replace the forName part with a better way and rename to getClass. Would Thread.currentThread().getContextClassLoader().loadClass(String) be acceptable instead of the forName call? Hen On Thu, 27 Jan 2005 23:43:58 -, Stephen Colebourne [EMAIL PROTECTED] wrote: While I support the addition of a get class method in principle, I am concerned that this brushes over the class loader issue. I would say that Class.forName() will often cause problems, so maybe this isn't the best way to code this. Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] I committed this btw. Hen On Wed, 26 Jan 2005 17:34:39 -0500, Henri Yandell [EMAIL PROTECTED] wrote: I'd like to add ClassUtils.forName; to all intents and purposes the same as Class.forName except that: 1) It understands arrays ending with [] instead of the [Lclass; ugliness. 2) It can handle primitives, int would correctly return int.class. 3) (perhaps?) null-safe. No idea really, just throwing it in :) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] ReflectionUtils
By using an interface strategy to find methods I believe that this takes it out of scope for [lang]. We have tried to restrict lang to tasks that are non-framework like and non-religious. I am also being harsh, because there is a [reflect] component in the sandbox, which is dormant. That was meant to handle generic ReflectionUtils type things. Plus there are MethodUtils and so on in [beanutils]. Stephen - Original Message - From: Torsten Curdt [EMAIL PROTECTED] To: Jakarta Commons Developers List commons-dev@jakarta.apache.org Sent: Monday, January 31, 2005 11:10 PM Subject: [lang] ReflectionUtils - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33342] - [beanutils] Change propertyUtilsBean.findNextNestedIndex(String) modifier to protected ?
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=33342. 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=33342 [EMAIL PROTECTED] changed: What|Removed |Added OS/Version|Windows XP |All Platform|PC |All Summary|Change |[beanutils] Change |propertyUtilsBean.findNextNe|propertyUtilsBean.findNextNe |stedIndex(String expression)|stedIndex(String) modifier |modifier to protected ? |to protected ? -- 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 33340] - [cli] HelpFormatter doesn't function correctly for options with only LongOpt
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=33340. 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=33340 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2005-02-02 01:34 --- *** Bug 33341 has been marked as a duplicate of this bug. *** -- 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 33341] - [cli] HelpFormatter doesn't function correctly for options with only LongOpt
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=33341. 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=33341 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2005-02-02 01:34 --- *** This bug has been marked as a duplicate of 33340 *** -- 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]
svn commit: r149466 - jakarta/commons/sandbox/feedparser/trunk/src/java/org/apache/commons/feedparser/test/TestPerformance.java
Author: burton
Date: Tue Feb 1 16:40:19 2005
New Revision: 149466
URL: http://svn.apache.org/viewcvs?view=revrev=149466
Log:
benchmarks of SAX vs JDOM
Added:
jakarta/commons/sandbox/feedparser/trunk/src/java/org/apache/commons/feedparser/test/TestPerformance.java
Added:
jakarta/commons/sandbox/feedparser/trunk/src/java/org/apache/commons/feedparser/test/TestPerformance.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/feedparser/trunk/src/java/org/apache/commons/feedparser/test/TestPerformance.java?view=autorev=149466
==
---
jakarta/commons/sandbox/feedparser/trunk/src/java/org/apache/commons/feedparser/test/TestPerformance.java
(added)
+++
jakarta/commons/sandbox/feedparser/trunk/src/java/org/apache/commons/feedparser/test/TestPerformance.java
Tue Feb 1 16:40:19 2005
@@ -0,0 +1,161 @@
+/*
+ * Copyright 1999,2004 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.feedparser.test;
+
+import java.applet.*;
+import java.util.*;
+import java.io.*;
+import java.net.*;
+import java.security.*;
+import java.lang.reflect.*;
+
+import junit.framework.*;
+
+import org.apache.commons.feedparser.*;
+import org.apache.commons.feedparser.impl.*;
+import org.apache.commons.feedparser.network.*;
+
+import javax.xml.parsers.*;
+import org.xml.sax.*;
+import org.xml.sax.helpers.*;
+
+/**
+ *
+ * @author a href=mailto:[EMAIL PROTECTED]Kevin A. Burton/a
+ * @version $Id: TestAtom.java 149187 2005-01-30 23:54:29Z burton $
+ */
+public class TestPerformance {
+
+static SAXParser parser = null;
+
+public static void doTestSAX() throws Exception {
+
+if ( parser == null ) {
+parser = SAXParserFactory.newInstance().newSAXParser();
+
+//need to enable SAX2 locals and namespace
+parser.getXMLReader().setFeature(
http://xml.org/sax/features/namespaces;, true );
+}
+
+ org.apache.commons.feedparser.sax.RSSFeedParser handler =
+ new org.apache.commons.feedparser.sax.RSSFeedParser();
+
+ handler.listener = new DefaultFeedParserListener() {
+
+ public void onChannel( FeedParserState state,
+String title,
+String link,
+String description ) throws
FeedParserException {
+
+// System.out.println( onChannel: title: + title );
+
+ }
+
+ public void onItem( FeedParserState state,
+ String title,
+ String link,
+ String description,
+ String permalink ) throws
FeedParserException {
+
+// System.out.println( onItem: title: + title );
+
+ }
+
+ public void onItemEnd() throws FeedParserException {
+
+// System.out.println( onItemEnd);
+
+ }
+
+ };
+
+String resource = file:/home/burton/index.rss;
+
+ResourceRequest request = ResourceRequestFactory
+.getResourceRequest( resource );
+
+parser.parse( request.getInputStream(), handler );
+
+}
+
+public static void doTestDefault() throws Exception {
+
+FeedParser parser = FeedParserFactory.newFeedParser();
+FeedParserListener listener = new DefaultFeedParserListener() {};
+
+String resource = file:/home/burton/index.rss;
+
+ResourceRequest request = ResourceRequestFactory
+.getResourceRequest( resource );
+
+parser.parse( listener,
+ request.getInputStream(),
+ resource );
+
+}
+
+public static void main( String[] args ) throws Exception {
+
+TestPerformance test = new TestPerformance();
+
+//test.testGetWeblogLinkForResource();
+//test.test1();
+
+doTestMethod( doTestSAX, TestPerformance.class, 100 );
+doTestMethod( doTestDefault, TestPerformance.class, 100 );
+
+}
+
+public static void doTestMethod( String name, Class clazz, int max )
throws Exception {
+
+Method method = clazz.getMethod( name, null );
+
+
DO NOT REPLY [Bug 33340] - [cli] HelpFormatter doesn't function correctly for options with only LongOpt
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=33340. 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=33340 --- Additional Comments From [EMAIL PROTECTED] 2005-02-02 01:57 --- Created an attachment (id=14157) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14157action=view) PATCH but only a portion of a diff I created a fix for version 1.0 of cli but getting the latest code from nightly builds see that this bug has been fixed. -- 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: [lang] ReflectionUtils
Stephen Colebourne wrote: By using an interface strategy to find methods I believe that this takes it out of scope for [lang]. We have tried to restrict lang to tasks that are non-framework like and non-religious. I see I am also being harsh, because there is a [reflect] component in the sandbox, which is dormant. That was meant to handle generic ReflectionUtils type things. What about it? Plus there are MethodUtils and so on in [beanutils]. Ok ...I will have a look into both the beanutils and the reflect component. cheers -- Torsten signature.asc Description: OpenPGP digital signature
Re: [lang] new method on ClassUtils
On Wed, 2 Feb 2005 00:19:06 -, Stephen Colebourne [EMAIL PROTECTED] wrote: I think that we would have to ask for classloader advice ;-) Probably. I suspect we would need: loadClassSystemClassLoader() - Class.forName loadClassThreadContextClassLoader() - thread loadClassLangClassLoader() - from ClassUtils loadClass(ClassLoader) We could just do the latter? Let's all the options be used without us having to drag through a list of all the likely options. No matter what classloader advice we got, it's likely to be usable. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
On Tue, 2005-02-01 at 20:40 +0100, Ceki Gülcü wrote: On 2005-01-31 9:59:52, Simon Kitching wrote: As I mentioned a few months ago, I've been working on some ideas for Digester 2.0. I've put some code and notes up on http://www.apache.org/~skitching Simon, Joran classes and documentation mention that it is influenced by Digester. Is your design for Digester 2.0 influenced by Joran? If it is, this should be mentioned as a matter courtesy. Hi Ceki, The only influence so far is the use of the word Action instead of Rule. I gave credit to Joran for this influence in my email to the dev list, but don't think a single name is quite enough to earn credit in the documentation. And anyway, I'm still waiting to see if people are happy changing name Rule - Action. I did read the Joran code about 12 months ago. I should take time to look back at Joran again to see if there are any ideas that are suitable for borrowing for digester 2.0; if this does happen I promise I will give due credit. If you are aware of anything that might be of use to Digester, then it would be great if you could point it out... Regards, Simon PS: How's the skiing this season? That's something I really miss after leaving Switzerland... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33340] - [cli] HelpFormatter doesn't function correctly for options with only LongOpt
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=33340. 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=33340 --- Additional Comments From [EMAIL PROTECTED] 2005-02-02 02:20 --- I checked and this fix only seems to be in nightly build could the same fix be updated and release as 1.0.1 or something because the nightly build is failing it's junit application test? -- 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: [digester] initial code for Digester2.0
Hi Oliver, On Tue, 2005-02-01 at 18:04 +0100, Oliver Zeigermann wrote: I very much like that and think it really is straight forward. Comments: - Why is Action an abstract class? So that we can later add new functionality to Action without breaking custom Action subclasses that users have written. As long as we can provide a suitable default implementation in the Action abstract class, everything runs smoothly. One example is the bodySegment callback that is now in Action. In Digester 1.x we could not have added this to Rule without breaking all custom Rule classes. But if digester2.0 had been released without it, we could have added it later with no source or binary compatibility problems. Of course because of Java's single-inheritance policy, it would be impossible for a class to extend both Action and some other class. But (a) this is extremely unlikely, and (b) using an adapter class works around this anyway if it absolutely has to be done. - Wouldn't it be possible (and even desirable) to have a more general Pattern class instead of a String in Digester#addRule? Can you explain more? - I like the bodySegment vs. body design :) Cool. Now I just have to implement it :-) The inspiration can be found in the digester 1.6 src/examples/api/document-markup example, where the code has to go to great lengths to handle XHTML-style input. - I like the no dependency and digester2 package approach Ok. I really thought people wouldn't like o.a.c.digester2. In fact, I'm not sure I like it myself. The main reasons are: (1) that I don't know any other projects that do this. Tomcat, struts, commons-collections, etc, don't do this. (2) that upgrading an application using digester 1.x to digester2.x requires changes to all the import statements. As noted, there is still currently a dependency on BeanUtils; digester uses too much from that package to copy the classes into digester. But as noted I would like to experiment with accessing BeanUtils functionality via a custom classloader so that if people have problems with clashing lib versions there is a solution. - It's no secret that I am no fun of reflection stuff: is it really necessary to have the subclasses of Action be part of the *very*, *very* digester *core*? Sorry, I don't follow this. Could you explain? One thing the proposed code does do is separate ActionFactory from Digester, so the Digester class doesn't have compile-time dependencies on any Action subclasses. I quite like Emmanuel Bourg's suggestion of an actions subpackage to hold the subclasses of Action, which would show that they aren't tightly coupled to the Digester core classes. Or are you by chance referring to my suggestions for xml-rules? If so I would be more than happy to abandon xmlio (in) as - apart from philosophical considerations - it would be superfluous and I would offer development support for digester if that is welcome. You would be very welcome indeed to work on digester if you wish. My memory of our discussions about xmlio/digester is a little vague now, but I remember coming to the conclusion that their concepts were different in some fundamental ways. If we *can* find some way to merge the two projects, though, I'm all for it. Does the fact that Digester and SAXHandler have been split apart make this possible now? Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [digester] initial code for Digester2.0
- Why is Action an abstract class? So that we can later add new functionality to Action without breaking custom Action subclasses that users have written. As long as we can provide a suitable default implementation in the Action abstract class, everything runs smoothly. One example is the bodySegment callback that is now in Action. In Digester 1.x we could not have added this to Rule without breaking all custom Rule classes. But if digester2.0 had been released without it, we could have added it later with no source or binary compatibility problems. Of course because of Java's single-inheritance policy, it would be impossible for a class to extend both Action and some other class. But (a) this is extremely unlikely, and (b) using an adapter class works around this anyway if it absolutely has to be done. I prefer interface + default abstract implementation, the way Swing provides e.g. Action* and AbstractAction. That way a class can still implement the interface even if it extends from something else, and use a delegate to implement the interface. You can still evolve the interface without breaking existing classes that extend the abstract class. Of course, there is nothing to force people to extend the abstract class, but you can make it clear in the doco for the interface that not to extend the abstract class is an explicit design choice that may have dire consequences. * yes, the name Action is quite overused. Not that I can think of a better alternative... ;-) Colin Sharples IBM Advisory IT Specialist Email: [EMAIL PROTECTED] Mobile: +64 21 402 085 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r149477 - jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/time/StopWatchTest.java
Author: bayard
Date: Tue Feb 1 19:52:50 2005
New Revision: 149477
URL: http://svn.apache.org/viewcvs?view=revrev=149477
Log:
tested some missing bad states
Modified:
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/time/StopWatchTest.java
Modified:
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/time/StopWatchTest.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/time/StopWatchTest.java?view=diffr1=149476r2=149477
==
---
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/time/StopWatchTest.java
(original)
+++
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/time/StopWatchTest.java
Tue Feb 1 19:52:50 2005
@@ -24,7 +24,7 @@
* TestCase for StopWatch.
*
* @author Stephen Colebourne
- * @version $Id: StopWatchTest.java,v 1.8 2004/09/05 19:55:29 bayard Exp $
+ * @version $Id$
*/
public class StopWatchTest extends TestCase {
@@ -129,6 +129,13 @@
}
try {
+watch.split();
+fail(Calling split on a non-running StopWatch should throw an
exception. );
+} catch(IllegalStateException ise) {
+// expected
+}
+
+try {
watch.unsplit();
fail(Calling unsplit on an unsplit StopWatch should throw an
exception. );
} catch(IllegalStateException ise) {
@@ -146,7 +153,7 @@
try {
watch.start();
-fail(Calling start on an started StopWatch should throw an
exception. );
+fail(Calling start on a started StopWatch should throw an
exception. );
} catch(IllegalStateException ise) {
// expected
}
@@ -168,6 +175,15 @@
try {
watch.resume();
fail(Calling resume on an unsuspended StopWatch should throw an
exception. );
+} catch(IllegalStateException ise) {
+// expected
+}
+
+watch.stop();
+
+try {
+watch.start();
+fail(Calling start on a stopped StopWatch should throw an
exception as it needs to be reset. );
} catch(IllegalStateException ise) {
// expected
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Commons Wiki] Updated: Lang
Date: 2005-02-01T20:21:02 Editor: HenriYandell Wiki: Jakarta Commons Wiki Page: Lang URL: http://wiki.apache.org/jakarta-commons/Lang no comment Change Log: -- @@ -22,7 +22,7 @@ 1. [http://issues.apache.org/bugzilla/show_bug.cgi?id=22717 22717][lang] MutableNumbers - '''see lang.mutable.''' - '''COMPLETE''' 1. [http://issues.apache.org/bugzilla/show_bug.cgi?id=30334 30334][lang] New class proposal: '''CharacterEncoding''' - '''COMPLETE''' 1. [http://issues.apache.org/bugzilla/show_bug.cgi?id=29163 29163]Make StopWatch validate state transitions - '''COMPLETE''' - 1. [http://issues.apache.org/bugzilla/show_bug.cgi?id=26056 26056][lang] Add methods to ArrayUtils: add at end and insert-like ops - '''DONE - add(Object[], Object) is overloaded for all the primitives, as is add(Object[], int, Object) but addAll(Object[], Object[]) is not overloaded for primitives yet. '' + 1. [http://issues.apache.org/bugzilla/show_bug.cgi?id=26056 26056][lang] Add methods to ArrayUtils: add at end and insert-like ops - '''DONE - add(Object[], Object) is overloaded for all the primitives, as is add(Object[], int, Object) and addAll(Object[], Object[]). '' 1. [http://issues.apache.org/bugzilla/show_bug.cgi?id=24910 24910]new StringUtils.split methods that split on the whole separator string - '''committed as splitByWholeSeparator''' 1. [http://issues.apache.org/bugzilla/show_bug.cgi?id=15082 15082][lang] elapsed time formatting utility method - '''DurationFormatUtils.''' 1. DateUtils.isSameDay() - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29163] - [lang] Make StopWatch validate state transitions
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=29163. 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=29163 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-02-02 05:24 --- Tis all implemented. The state table is slightly different for reset, anything may be reset so X's all the way across. -- 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]
svn commit: r149480 - jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/WordUtils.java
Author: bayard
Date: Tue Feb 1 20:46:02 2005
New Revision: 149480
URL: http://svn.apache.org/viewcvs?view=revrev=149480
Log:
stab at making the javadoc a bit easier to understand
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/WordUtils.java
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/WordUtils.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/WordUtils.java?view=diffr1=149479r2=149480
==
---
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/WordUtils.java
(original)
+++
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/WordUtils.java
Tue Feb 1 20:46:02 2005
@@ -28,7 +28,7 @@
* @author a href=mailto:[EMAIL PROTECTED]Henning P. Schmiedehausen/a
* @author Gary Gregory
* @since 2.0
- * @version $Id: WordUtils.java,v 1.16 2004/10/16 15:20:30 scolebourne Exp $
+ * @version $Id$
*/
public class WordUtils {
@@ -218,8 +218,9 @@
//---
/**
* pCapitalizes all the whitespace separated words in a String.
- * Only the first letter of each word is changed. To change all letters to
- * the capitalized case, use [EMAIL PROTECTED]
#capitalizeFully(String)}./p
+ * Only the first letter of each word is changed. To convert the
+ * rest of each word to lowercase at the same time,
+ * use [EMAIL PROTECTED] #capitalizeFully(String)}./p
*
* pWhitespace is defined by [EMAIL PROTECTED]
Character#isWhitespace(char)}.
* A codenull/code input String returns codenull/code.
@@ -243,8 +244,9 @@
/**
* pCapitalizes all the delimiter separated words in a String.
- * Only the first letter of each word is changed. To change all letters to
- * the capitalized case, use [EMAIL PROTECTED]
#capitalizeFully(String)}./p
+ * Only the first letter of each word is changed. To convert the
+ * rest of each word to lowercase at the same time,
+ * use [EMAIL PROTECTED] #capitalizeFully(String, char[])}./p
*
* pThe delimiters represent a set of characters understood to separate
words.
* The first string character and the first non-delimiter character after a
@@ -311,8 +313,9 @@
}
/**
- * pCapitalizes all the whitespace separated words in a String.
- * All letters are changed, so the resulting string will be fully
changed./p
+ * pConverts all the whitespace separated words in a String into
capitalized words,
+ * that is each word is made up of a titlecase character and then a series
of
+ * lowercase characters. /p
*
* pWhitespace is defined by [EMAIL PROTECTED]
Character#isWhitespace(char)}.
* A codenull/code input String returns codenull/code.
@@ -333,8 +336,9 @@
}
/**
- * pCapitalizes all the delimiter separated words in a String.
- * All letters are changed, so the resulting string will be fully
changed./p
+ * pConverts all the delimiter separated words in a String into
capitalized words,
+ * that is each word is made up of a titlecase character and then a series
of
+ * lowercase characters. /p
*
* pThe delimiters represent a set of characters understood to separate
words.
* The first string character and the first non-delimiter character after a
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] 2.1...
On Wed, 26 Jan 2005 00:14:24 -, Stephen Colebourne [EMAIL PROTECTED] wrote: Checking my mail history Still TODO: 5) - WordUtils Capitalize with separator methods need to define null handling for delimiter list, and better javadoc for two of the three methods Unsure exactly what was wanted with this. The null handling seems to be there. I modified the javadoc a bit to hopefully make understanding it easier. Although it's technically correct to say that in the capitalzed word 'Home', the 'o' is in the capitalized form, I suspect that most users will get confused thinking that capitalization means titlecase. Apart from the method I added to ClassUtils that'll need removing if I can't justify it, and whatever needs to happen to the javadoc above, we seem to be ready for 2.1. I'll wait to hear Stephen's reply to my latest ClassUtils.forName comment as I think it's a worthwhile method and it's very easy to test it completely so risk should be low. Once we get that squared away I'll go ahead and create an informal 2.1-rc1 for us to look at and vote over, with clover/jdiff/javadoc etc. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[resources] complete class diagram
I wish it helps http://www.drianoxaman.kit.net/commons/resources.zip Woody PS: this server is very busy, if you receive a timeout retry again - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jxpath] Pre-commit check failed - Help needed
I was trying to commit a patch provided by Emond Papegaaij, but got a Pre-commit check failed message from CVS. I haven't done any commits since December. Has something changed? Is it possible that I somehow lost my karma? Thank you, - Dmitri
RE: [digester] initial code for Digester2.0
On Wed, 2005-02-02 at 15:04 +1300, Sharples, Colin wrote: - Why is Action an abstract class? So that we can later add new functionality to Action without breaking custom Action subclasses that users have written. As long as we can provide a suitable default implementation in the Action abstract class, everything runs smoothly. One example is the bodySegment callback that is now in Action. In Digester 1.x we could not have added this to Rule without breaking all custom Rule classes. But if digester2.0 had been released without it, we could have added it later with no source or binary compatibility problems. Of course because of Java's single-inheritance policy, it would be impossible for a class to extend both Action and some other class. But (a) this is extremely unlikely, and (b) using an adapter class works around this anyway if it absolutely has to be done. I prefer interface + default abstract implementation, the way Swing provides e.g. Action* and AbstractAction. That way a class can still implement the interface even if it extends from something else, and use a delegate to implement the interface. You can still evolve the interface without breaking existing classes that extend the abstract class. Of course, there is nothing to force people to extend the abstract class, but you can make it clear in the doco for the interface that not to extend the abstract class is an explicit design choice that may have dire consequences. Interesting. Extending an interface by adding methods causes source and binary incompatibility with all *implementers* of the interface, but not with *users* of the interface. So it is not a problem if classes like SAXHandler reference Action; user subclasses will still work fine with the new interface [1]. [1] Though if they override methods that have been modified in SAXHandler to *use* the new methods, then things might get hairy... My major concern is that if we are going to warn people not to implement the Action interface, then what really is the point of providing it in the first place? As I said above, I just cannot think of any situation where a class would want to be an Action *and* extend some other class. Nevertheless, there are definite benefits to following a standard convention... * yes, the name Action is quite overused. Not that I can think of a better alternative... ;-) Yep :-( Rule is at least different - but unfortunately can be misleading. A tough choice.. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jxpath] Pre-commit check failed - Help needed
We've moved over to subversion for jakarta commons. CVS is read only. On Wed, 2 Feb 2005 00:12:44 -0500, Dmitri Plotnikov [EMAIL PROTECTED] wrote: I was trying to commit a patch provided by Emond Papegaaij, but got a Pre-commit check failed message from CVS. I haven't done any commits since December. Has something changed? Is it possible that I somehow lost my karma? Thank you, - Dmitri -- http://www.multitask.com.au/people/dion/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jxpath] Pre-commit check failed - Help needed
Thanks, Dion, I did not realize this has happened. I'll read up on it. - Dmitri - Original Message - From: Dion Gillard [EMAIL PROTECTED] To: Jakarta Commons Developers List commons-dev@jakarta.apache.org Sent: Wednesday, February 02, 2005 12:19 AM Subject: Re: [jxpath] Pre-commit check failed - Help needed We've moved over to subversion for jakarta commons. CVS is read only. On Wed, 2 Feb 2005 00:12:44 -0500, Dmitri Plotnikov [EMAIL PROTECTED] wrote: I was trying to commit a patch provided by Emond Papegaaij, but got a Pre-commit check failed message from CVS. I haven't done any commits since December. Has something changed? Is it possible that I somehow lost my karma? Thank you, - Dmitri -- http://www.multitask.com.au/people/dion/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
On Tue, 2005-02-01 at 16:20 +0100, Emmanuel Bourg wrote: Reid Pinchback wrote: I strongly agree. Cyclic package dependencies seem unimportant when you only have a few classes, but as the amount of code grows, you quickly find that testing and refactoring because much more difficult than it had to be. Can you give an example of a difficult refactoring due to a cyclic dependency between 2 packages ? I'm not sure to understand the practical issue. Well, I don't know about the refactoring issues. But I prefer avoiding cyclic dependencies because: * You can learn the classes in packages in order, without bouncing back and forth between packages * javac, javadoc, UML diagramming tools, etc. can process code in directory order without having to bounce back and forth. This just has to improve performance and reliability. * you can trim down a distribution by progressively leaving out packages * when porting code or revising code (including refactoring) you can do this in a progressive manner, starting with the package at the root of the dependency tree and working forward rather than having to migrate classes scattered across a selection of packages. * having clean package dependencies encourages lower code coupling. Quite often I find it prompts me to create clean interfaces to break inter-package dependencies, and I then find those interfaces are sensible for many reasons. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jxpath] Pre-commit check failed - Help needed
See http://www.apache.org/dev/version-control.html for some more detail. On Wed, 2 Feb 2005 00:28:07 -0500, Dmitri Plotnikov [EMAIL PROTECTED] wrote: Thanks, Dion, I did not realize this has happened. I'll read up on it. - Dmitri - Original Message - From: Dion Gillard [EMAIL PROTECTED] To: Jakarta Commons Developers List commons-dev@jakarta.apache.org Sent: Wednesday, February 02, 2005 12:19 AM Subject: Re: [jxpath] Pre-commit check failed - Help needed We've moved over to subversion for jakarta commons. CVS is read only. On Wed, 2 Feb 2005 00:12:44 -0500, Dmitri Plotnikov [EMAIL PROTECTED] wrote: I was trying to commit a patch provided by Emond Papegaaij, but got a Pre-commit check failed message from CVS. I haven't done any commits since December. Has something changed? Is it possible that I somehow lost my karma? Thank you, - Dmitri -- http://www.multitask.com.au/people/dion/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.multitask.com.au/people/dion/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
