DO NOT REPLY [Bug 33347] New: - Allow logging additional fields to database
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=33347. 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=33347 Summary: Allow logging additional fields to database Product: Commons Version: unspecified Platform: PC OS/Version: Windows XP Status: NEW Severity: enhancement Priority: P2 Component: Logging AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Instead of current only allow log.info(String message, Throwable t) being logged. I'm wondering can we have new feature to allow logging additional fields data i.e. user id, log timestamp, activity done etc via commons-logging--log4j to database for audit log trail purposes? -- 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 33347] - [logging] Allow logging additional fields to database
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=33347. 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=33347 [EMAIL PROTECTED] changed: What|Removed |Added Summary|Allow logging additional|[logging] Allow logging |fields to database |additional fields to ||database -- 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]
[jelly] x:set null pointer exception
Hi Paul, The issue I was having was a null pointer exception resulting from running the following: x:parse var=navXML xml= / x:set var=nav value=$navXML/body / I think in the past, this used to set nav to null (presumably because navXML was an empty document, where now it is a null document?) I'm now just skipping this code when xml is empty in the script. Any thoughts on how this should be handled? - Brett Brett Porter wrote: Hi Paul, This fixed the original issue. I have another issue (as I mentioned before), if you run maven -e xdoc on maven-1/plugins/trunk/ashkelon you can see it. I'll investigate when I can, but hold off on that release in the mean time :) - Brett - 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 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-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-02022005.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
[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 9 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-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-02022005.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-02022005.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-02022005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-02022005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-02022005.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-02022005.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-02022005.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]
DO NOT REPLY [Bug 33352] New: - add collection modifiers feature to PropertyUtilsBean.
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=33352.
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=33352
Summary: add collection modifiers feature to PropertyUtilsBean.
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]
There's some java beans who are not lazy ones and who need to modify collection
type properties. Ongoing propertyUtilsBean only allows to set indexed property,
but not to add or remove items in collection.
This is a proposition to add following new features :
- propertyUtilsBean.(add | remove )CollectionPropertyValue(Object bean, String
name, Object value)
Action: (add to | remove from ) bean property name a value.
In other words, search a method (add | remove)item(parameterType value) where
parameterType.isAssignable(value.class) to add value to item collection, item
collection bean property being deduced with a stemmer algo (as in
betwixt.DefaultPluralStemmer) from method name and declared by
getProperty(bean,name).getClass();
Sample :
myPropertyUtilsBean.addCollectionPropertyValue(myBean,
productMap(food).catalog.products, new Product(acmeDogFood, 12));
will use Catalog.addProduct(Product p) to add new Product(acmeDogFood, 12) to
inner collection Catalog.products.
- PropertyUtilsBean.(add | remove )CollectionPropertyValue(Object bean, String
property, String itemName, Object value)
Action: (add to | remove from ) bean property name a value.
In other words, search a method (add | remove)item(parameterType value) where
parameterType.isAssignable(value.class) to add value to item collection, item
collection being deduced with a stemmer algo (as in
betwixt.DefaultPluralStemmer) from itemName and declared by
getProperty(bean,name).getClass();
Sample :
myPropertyUtilsBean.addCollectionPropertyValue(myBean,
productMap(food).catalog,product, new Product(acmeDogFood, 12));
will use Catalog.addProduct(Product p) to add new Product(acmeDogFood, 12) to
inner Catalog.productList.
If there's no Catalog.addProduct(Product p) method, try to invoke
Collection.add(Object obj) on Catalog.products.
I have yet created in PropertyUtilsBean sub class such feature as demonstrator
and unit tests work (for the meantime).
Constraints:
- Object are to apply java beans specification.
- Collection must have readable method ( to be considered as bean property)
- adder and remover method have to follow conventions copied from
org.apache.commons.betwixt.strategy.DefaultPluralStemmer
Matching select in this order for an given itemName or a deduced from method
name one:
1. get itemName+s :(items)
2. if ( itemName ends with y )
1. get itemName+es (no sample, my english is too poor !)
2. get substitute itemName ending with ies (baby = babies)
3. get itemName + List
4. get itemName + Set
5. get itemName + Collection
6. Browse propertyMap to get a property starting with itemName, as itemBag.
If there's several property matching later, select the longuest property
name : itemBagCollection instead of itemBag
- method selection :
If two methods match this upper requirements (name (add | remove)Item(ParmType
value) and parameterType.isAssignable(value.class)) , first method matching is
selected. Methods are ordered following min distance metric :
- Distance metric is the base on
public int getDistance(Class c) {
Class superclass = c.getSuperclass();
int distance = 0;
while ( superclass != null ) {
superclass = superclass.getSuperclass();
distance ++;
}
return distance;
}
--
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 33353] New: - add collection modifiers feature to PropertyUtilsBean.
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=33353.
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=33353
Summary: add collection modifiers feature to PropertyUtilsBean.
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]
There's some java beans who are not lazy ones and who need to modify collection
type properties. Ongoing propertyUtilsBean only allows to set indexed property,
but not to add or remove items in collection.
This is a proposition to add following new features :
- propertyUtilsBean.(add | remove )CollectionPropertyValue(Object bean, String
name, Object value)
Action: (add to | remove from ) bean property name a value.
In other words, search a method (add | remove)item(parameterType value) where
parameterType.isAssignable(value.class) to add value to item collection, item
collection bean property being deduced with a stemmer algo (as in
betwixt.DefaultPluralStemmer) from method name and declared by
getProperty(bean,name).getClass();
Sample :
myPropertyUtilsBean.addCollectionPropertyValue(myBean,
productMap(food).catalog.products, new Product(acmeDogFood, 12));
will use Catalog.addProduct(Product p) to add new Product(acmeDogFood, 12) to
inner collection Catalog.products.
- PropertyUtilsBean.(add | remove )CollectionPropertyValue(Object bean, String
property, String itemName, Object value)
Action: (add to | remove from ) bean property name a value.
In other words, search a method (add | remove)item(parameterType value) where
parameterType.isAssignable(value.class) to add value to item collection, item
collection being deduced with a stemmer algo (as in
betwixt.DefaultPluralStemmer) from itemName and declared by
getProperty(bean,name).getClass();
Sample :
myPropertyUtilsBean.addCollectionPropertyValue(myBean,
productMap(food).catalog,product, new Product(acmeDogFood, 12));
will use Catalog.addProduct(Product p) to add new Product(acmeDogFood, 12) to
inner Catalog.productList.
If there's no Catalog.addProduct(Product p) method, try to invoke
Collection.add(Object obj) on Catalog.products.
I have yet created in PropertyUtilsBean sub class such feature as demonstrator
and unit tests work (for the meantime).
Constraints:
- Object are to apply java beans specification.
- Collection must have readable method ( to be considered as bean property)
- adder and remover method have to follow conventions copied from
org.apache.commons.betwixt.strategy.DefaultPluralStemmer
Matching select in this order for an given itemName or a deduced from method
name one:
1. get itemName+s :(items)
2. if ( itemName ends with y )
1. get itemName+es (no sample, my english is too poor !)
2. get substitute itemName ending with ies (baby = babies)
3. get itemName + List
4. get itemName + Set
5. get itemName + Collection
6. Browse propertyMap to get a property starting with itemName, as itemBag.
If there's several property matching later, select the longuest property
name : itemBagCollection instead of itemBag
- method selection :
If two methods match this upper requirements (name (add | remove)Item(ParmType
value) and parameterType.isAssignable(value.class)) , first method matching is
selected. Methods are ordered following min distance metric :
- Distance metric is the base on
public int getDistance(Class c) {
Class superclass = c.getSuperclass();
int distance = 0;
while ( superclass != null ) {
superclass = superclass.getSuperclass();
distance ++;
}
return distance;
}
--
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 33352] - [beanutils] add collection modifiers feature to PropertyUtilsBean
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=33352. 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=33352 [EMAIL PROTECTED] changed: What|Removed |Added OS/Version|Windows XP |All Platform|PC |All Summary|add collection modifiers|[beanutils] add collection |feature to |modifiers feature to |PropertyUtilsBean. |PropertyUtilsBean -- 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 33353] - add collection modifiers feature to PropertyUtilsBean.
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=33353. 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=33353 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID -- 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 33353] - [beanutils] add collection modifiers feature to PropertyUtilsBean
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=33353. 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=33353 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED OS/Version|Windows XP |All Platform|PC |All Resolution|INVALID | Summary|add collection modifiers|[beanutils] add collection |feature to |modifiers feature to |PropertyUtilsBean. |PropertyUtilsBean -- 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 33353] - [beanutils] add collection modifiers feature to PropertyUtilsBean
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=33353. 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=33353 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2005-02-02 12:18 --- *** This bug has been marked as a duplicate of 33352 *** -- 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 33352] - [beanutils] add collection modifiers feature to PropertyUtilsBean
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=33352. 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=33352 --- Additional Comments From [EMAIL PROTECTED] 2005-02-02 12:18 --- *** Bug 33353 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 33347] - [logging] Allow logging additional fields to database
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=33347. 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=33347 [EMAIL PROTECTED] changed: What|Removed |Added OS/Version|Windows XP |All Platform|PC |All -- 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: [resources] complete class diagram
This fails for me. If you would like us to include this in the docs, you could open an enhancement ticket and attach the file. That would also give your diagrams more visibility. Thanks. -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: Anaximandro (Woody) [EMAIL PROTECTED] To: Jakarta Commons Developers List commons-dev@jakarta.apache.org Sent: Wednesday, February 02, 2005 5:15 AM Subject: [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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] x:set null pointer exception
I fear this used to be treated as exception eater. More precisely: it throwed if it could not parse the xpath. But it just gave null if there were some other exceptions... So the easy thing would probably be to return null if there was an exception at evaluating XPath... (I think this is what most processors do anyways). paul Le 2 févr. 05, à 09:58, Brett Porter a écrit : Hi Paul, The issue I was having was a null pointer exception resulting from running the following: x:parse var=navXML xml= / x:set var=nav value=$navXML/body / I think in the past, this used to set nav to null (presumably because navXML was an empty document, where now it is a null document?) I'm now just skipping this code when xml is empty in the script. Any thoughts on how this should be handled? - Brett Brett Porter wrote: Hi Paul, This fixed the original issue. I have another issue (as I mentioned before), if you run maven -e xdoc on maven-1/plugins/trunk/ashkelon you can see it. I'll investigate when I can, but hold off on that release in the mean time :) - Brett - 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: [resources] complete class diagram
enhancement ticket? I dono if I really understand this ... Well, lets go If anyone needs the model (rose) send me a note. Woody - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
On Wed, 02 Feb 2005 18:28:04 +1300, Simon Kitching [EMAIL PROTECTED] wrote:
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...
I am +1 for using an interface and the default (why abstract?)
implementation like with Swing or SAX. Adding new (non-abstract) call
back methods later is restricted to additional ones onyway. You can
not replace methods or their semantics. Because of this you could
easily later (after 2.0) add something like
interface ExtendedAction extends Action {
... bodySegment(...);
}
class DefaultAction implements ExtendedAction {... }
which used to be
class DefaultAction implements Action {... }
and no existing code would break, but people would be free to use the
new, extended version.
I do not agree with people being asked to extend the default
implementation only as this would make the interface obsolete. But
with the stuff I tried to sketch above it should not be possible.
Hope this makes my point clear,
Oliver
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
One section of the release notes says: The Digester now *always* uses a namespace-aware xml parser. I was wondering why this is. There are a lot of XML parsers out there, and some of them have done things like trade namespace awareness for performance. If somebody has a application where namespaces aren't an issue, why should they be limited to only using a namespace-aware parser? Not something that seems like an important issue if you are just using a Digester to process some kind of app config file, but is an issue if processing streams of XML data is fundamentally what the app is about. __ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
--- Oliver Zeigermann [EMAIL PROTECTED] wrote: On Wed, 02 Feb 2005 18:28:04 +1300, Simon Kitching [EMAIL PROTECTED] wrote: 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. I am +1 for using an interface and the default (why abstract?) implementation like with Swing or SAX. I don't get why we would ever warn people not to implement the interface, beyond including JavaDoc that clarified what the behaviour contract is for the various methods. Part of a developer's job is to exercise judgement about what they are or are not going to do in their implementation. If the existing Action implementations and base class provides what a developer needs to do 99% of the time, they won't bother implementing the interface, but when they encounter that 1% scenario, its nice not to hit a brick wall. Here is a concrete example of why you could want to implement the interface and extend another class, I've actually had situations with the existing Digester where I'd wished I could do that. The one that I can recall now was an instrumentation issue. Doing debugging and performance tuning of a suite of rules can be tedious because, currently, the only options are either to watch a spew of logging messages or single-step your way through all the callbacks in a debugger (PAIN). If the major coupling points in the Digester had been abstracted by interfaces, it would have been easier to insert instrumentation proxies or EasyMock'd test implementations of classes at key points. __ 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 Wed, 02 Feb 2005 14:48:42 +1300, Simon Kitching [EMAIL PROTECTED] wrote: - 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? Well, RuleManager is an abstract class (discussion abstract class vs. interface applies here as well) with a default implemenation, but Pattern is a String. Wouldn't it be more flexible with little extra cost to have a Pattern interface with a default String Path implementation like the current one? - I like the bodySegment vs. body design :) Cool. Now I just have to implement it :-) Ooops, doesn't it work, yet? 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 was also wondering, there may be occasions where it is desirable to have the full body *including tags* passed in a call back. This would mostly apply in mixed context tags where text is mixed with style information that do not need processing like with XTHML. - 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. Tomcat does not need to as it is no library. commons-collections should better have done this - for more details have a look at the thread all this was discussed in recently. (2) that upgrading an application using digester 1.x to digester2.x requires changes to all the import statements. I understand Digester2 is incompatible to 1.x anyway, so changes to the import statements aren't the primary problem, right? If it was fully compatible, there would be no need to call the package digester2 anyway. 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. Could you elaborate this? 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. That's exactly what I would want to see. Or are you by chance referring to my suggestions for xml-rules? No, what are they? 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? Honestly, I do not remember much of that discussion, but I thought we came to the conclusion that we would try to make xmlio obsolete with Digester2. The reason I preferred xmlio over digester was simplicity and obviousness mainly. Now this new Digester2 core (even better with the Action subclasses in a package of their own) is simple and obvious as well, so I see no strong reason to stick to xmlio. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] proposal: FileUtils
Hello!
Sorry for being late, but I have had an appointment day with one of our
customers.
public abstract class Backup implements IOOperation {
protected Backup(final FuPolicy policy) {
And two implementations:
public class NoBackup extends Backup {
public class SimpleBackup extends Backup {
The only thing I do not understand is why you need the policy if you
extend the Backup. The derived classes are the policy.
Else you should do somethink like NoBackupPolicy and SimpleBackupPolicy
which will be passed to Backup.
But I think extending Backup (to implement different policies) is good
enough and then you could drop the policy, no?
Ciao,
Mario
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r149515 - in jakarta/commons/proper/transaction/trunk: RELEASE-NOTES.txt build.xml project.xml
Author: ozeigermann
Date: Wed Feb 2 06:45:55 2005
New Revision: 149515
URL: http://svn.apache.org/viewcvs?view=revrev=149515
Log:
Prepared 1.1b2
Modified:
jakarta/commons/proper/transaction/trunk/RELEASE-NOTES.txt
jakarta/commons/proper/transaction/trunk/build.xml
jakarta/commons/proper/transaction/trunk/project.xml
Modified: jakarta/commons/proper/transaction/trunk/RELEASE-NOTES.txt
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/transaction/trunk/RELEASE-NOTES.txt?view=diffr1=149514r2=149515
==
--- jakarta/commons/proper/transaction/trunk/RELEASE-NOTES.txt (original)
+++ jakarta/commons/proper/transaction/trunk/RELEASE-NOTES.txt Wed Feb 2
06:45:55 2005
@@ -1,8 +1,8 @@
-Jakarta Commons Transaction Release 1.1 beta2 pre
--
+Jakarta Commons Transaction Release 1.1 beta2
+-
-RELEASE NUMBER: 1.1b2pre
-RELEASE TAG / BRANCH: none yet / none yet
+RELEASE NUMBER: 1.1b2
+RELEASE TAG / BRANCH: TRANSACTION_1_1_B2_RELEASE / none yet
DESCRIPTION
---
Modified: jakarta/commons/proper/transaction/trunk/build.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/transaction/trunk/build.xml?view=diffr1=149514r2=149515
==
--- jakarta/commons/proper/transaction/trunk/build.xml (original)
+++ jakarta/commons/proper/transaction/trunk/build.xml Wed Feb 2 06:45:55 2005
@@ -20,7 +20,7 @@
property name=compile.deprecation value=true /
property name=compile.optimize value=true /
- property name=version value=1.1b2pre/
+ property name=version value=1.1b2/
property name=name value=commons-transaction /
property name=title value=Commons Transaction /
property name=package value=org.apache.commons.transaction /
Modified: jakarta/commons/proper/transaction/trunk/project.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/transaction/trunk/project.xml?view=diffr1=149514r2=149515
==
--- jakarta/commons/proper/transaction/trunk/project.xml (original)
+++ jakarta/commons/proper/transaction/trunk/project.xml Wed Feb 2 06:45:55
2005
@@ -10,7 +10,7 @@
shortDescriptionCommons Transaction/shortDescription
descriptionCommons Transaction/description
- currentVersion1.1b2pre/currentVersion
+ currentVersion1.1b2/currentVersion
urlhttp://jakarta.apache.org/commons/${pom.artifactId.substring(8)}//url
packageorg.apache.commons.${pom.artifactId.substring(8)}/package
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] proposal: FileUtils
What do you think, if the commands do not chain the next command, but if
they create a Undo-Command which will be put on a stack and - in case of
an exception can be processed to rollback all commands.
I havent though about it in every detail, but if it is possible it is
easier to handle - and in the case of a file-manager one could provide a
undo function.
In pseudo code:
UndoStack tx = new UndoStack();
try
{
Backup(tx, ...)
Copy(tx, ...)
Move(tx, ...)
}
catch (Exception)
{
tx.rollback(); - process undo-stack
}
But again - [transaction] already do something like this. I think I have
some time today evening to check this out.
Ciao,
Mario
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] proposal: FileUtils
Mario Ivankovits wrote:
In pseudo code:
UndoStack tx = new UndoStack();
try
{
Backup(tx, ...)
Copy(tx, ...)
Move(tx, ...)
}
catch (Exception)
{
tx.rollback(); - process undo-stack
}
This looks ok. I still prefer each command to handle it's own cleanup
(try/catch/finally in part existing for this purpose), but there's
nothing wrong with the concept.
I'm curious what you find out about Commons Transactions. When I looked
it over, it seemd to me designed with primitives for us to use to make
our own transactions. I missed any ready-to-use code for this purpose.
I wonder how much overlap there is with java.util.concurrent in the
new JDK 5.
Cheers,
--binkley
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] proposal: FileUtils
Hello! I'm curious what you find out about Commons Transactions. When I looked it over, it seemd to me designed with primitives for us to use to make our own transactions. I missed any ready-to-use code for this purpose. I wonder how much overlap there is with java.util.concurrent in the new JDK 5. On their homepage they state they have done this for a java.io.File implementation. JDK5: Dont forget, our target is jdk1.3 (even if I use 1.5 since it is out) You cant imagine how fast the first user shouted after I used (by mistake) a jdk 1.4 method. --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r149517 - in jakarta/commons/proper/transaction/trunk: build.xml project.xml
Author: ozeigermann Date: Wed Feb 2 07:12:35 2005 New Revision: 149517 URL: http://svn.apache.org/viewcvs?view=revrev=149517 Log: Added new test Modified: jakarta/commons/proper/transaction/trunk/build.xml jakarta/commons/proper/transaction/trunk/project.xml Modified: jakarta/commons/proper/transaction/trunk/build.xml URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/transaction/trunk/build.xml?view=diffr1=149516r2=149517 == --- jakarta/commons/proper/transaction/trunk/build.xml (original) +++ jakarta/commons/proper/transaction/trunk/build.xml Wed Feb 2 07:12:35 2005 @@ -373,6 +373,7 @@ test name=org.apache.commons.transaction.memory.OptimisticMapWrapperTest haltonfailure=yes todir=tmp/ test name=org.apache.commons.transaction.memory.PessimisticMapWrapperTest haltonfailure=yes todir=tmp/ test name=org.apache.commons.transaction.locking.GenericLockTest haltonfailure=yes todir=tmp/ + test name=org.apache.commons.transaction.locking.LockTestRepeatableReads haltonfailure=yes todir=tmp/ /junit /target Modified: jakarta/commons/proper/transaction/trunk/project.xml URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/transaction/trunk/project.xml?view=diffr1=149516r2=149517 == --- jakarta/commons/proper/transaction/trunk/project.xml (original) +++ jakarta/commons/proper/transaction/trunk/project.xml Wed Feb 2 07:12:35 2005 @@ -149,7 +149,7 @@ includeorg/apache/commons/transaction/memory/OptimisticMapWrapperTest.java/include includeorg/apache/commons/transaction/memory/PessimisticMapWrapperTest.java/include includeorg/apache/commons/transaction/locking/GenericLockTest.java/include - /includes + includeorg/apache/commons/transaction/locking/LockTestRepeatableReads.java/include /unitTest /build - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] proposal: FileUtils
Mario Ivankovits wrote: JDK5: Dont forget, our target is jdk1.3 (even if I use 1.5 since it is out) You cant imagine how fast the first user shouted after I used (by mistake) a jdk 1.4 method. JDK 1.3!? I had no earthly idea. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[vfs] temporary files
What's the right way to make a temporary file with VFS? I need some for
unit tests. For the nonce I did this:
FileObject createTemporary() {
// Using JDK UUID generator -- is this JDK1.3-compiant?
final FileObject tmp = VFS.getManager().resolveFile(
tmp:/ + UUID.randomUUID());
tmp.createFile();
return tmp;
}
But this has several drawbacks, among them:
* No automatic cleanup on exit as with File.deleteOnExit()
* Depends on TempFS being configured
* Relies on the static VFS.getManager() call
* Smells hacky
Cheers,
--binkley
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r149519 - jakarta/commons/proper/transaction/tags/TRANSACTION_1_1_B2_RELEASE
Author: ozeigermann Date: Wed Feb 2 07:23:20 2005 New Revision: 149519 URL: http://svn.apache.org/viewcvs?view=revrev=149519 Log: Tagging as 1.1b2 Added: jakarta/commons/proper/transaction/tags/TRANSACTION_1_1_B2_RELEASE/ - copied from r149518, jakarta/commons/proper/transaction/trunk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r149521 - jakarta/commons/proper/transaction/trunk/project.xml
Author: ozeigermann Date: Wed Feb 2 07:31:50 2005 New Revision: 149521 URL: http://svn.apache.org/viewcvs?view=revrev=149521 Log: Added missing end tag Modified: jakarta/commons/proper/transaction/trunk/project.xml Modified: jakarta/commons/proper/transaction/trunk/project.xml URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/transaction/trunk/project.xml?view=diffr1=149520r2=149521 == --- jakarta/commons/proper/transaction/trunk/project.xml (original) +++ jakarta/commons/proper/transaction/trunk/project.xml Wed Feb 2 07:31:50 2005 @@ -150,6 +150,7 @@ includeorg/apache/commons/transaction/memory/PessimisticMapWrapperTest.java/include includeorg/apache/commons/transaction/locking/GenericLockTest.java/include includeorg/apache/commons/transaction/locking/LockTestRepeatableReads.java/include + includes /unitTest /build - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r149522 - jakarta/commons/proper/transaction/trunk/project.xml
Author: ozeigermann Date: Wed Feb 2 07:35:16 2005 New Revision: 149522 URL: http://svn.apache.org/viewcvs?view=revrev=149522 Log: *really* added missing end tag Modified: jakarta/commons/proper/transaction/trunk/project.xml Modified: jakarta/commons/proper/transaction/trunk/project.xml URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/transaction/trunk/project.xml?view=diffr1=149521r2=149522 == --- jakarta/commons/proper/transaction/trunk/project.xml (original) +++ jakarta/commons/proper/transaction/trunk/project.xml Wed Feb 2 07:35:16 2005 @@ -150,7 +150,7 @@ includeorg/apache/commons/transaction/memory/PessimisticMapWrapperTest.java/include includeorg/apache/commons/transaction/locking/GenericLockTest.java/include includeorg/apache/commons/transaction/locking/LockTestRepeatableReads.java/include - includes + /includes /unitTest /build - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r149523 - jakarta/commons/proper/transaction/tags/TRANSACTION_1_1_B2_RELEASE/trunk
Author: ozeigermann Date: Wed Feb 2 07:35:55 2005 New Revision: 149523 URL: http://svn.apache.org/viewcvs?view=revrev=149523 Log: Tagging as 1.1b2 Added: jakarta/commons/proper/transaction/tags/TRANSACTION_1_1_B2_RELEASE/trunk/ - copied from r149522, jakarta/commons/proper/transaction/trunk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[transaction][VOTE] Release 1.1b2
Dear community, after the first commons transaction 1.1 beta release - some bugs partially found by OJB committer Armin Waibel have been fixed, - some tests partially taken over from OJB have been added, and - tests on a multi processor machine have been successfully performed This seems to be enough to give commons transaction a second beta round. I have already created a new release tag using svn copy https://svn.apache.org/repos/asf/jakarta/commons/proper/transaction/trunk https://svn.apache.org/repos/asf/jakarta/commons/proper/transaction/tags/TRANSACTION_1_1_B2_RELEASE -m Tagging as 1.1b2 As usual I have already created the distributions by calling 'ant package'. They are ready for inspection here: http://www.apache.org/~ozeigermann/tx-1.1b2 The release notes are here: http://svn.apache.org/repos/asf/jakarta/commons/proper/transaction/tags/TRANSACTION_1_1_B2_RELEASE/RELEASE-NOTES.txt Here is my +1! Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[svn][ot] How to move a tag?
Folks, sorry, this is a bit OT, but I am struggeling how to move a tag in SVN. Any hints? Thanks in advance, Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33364] New: - FastDateFormat analog for DecimalFormat
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=33364. 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=33364 Summary: FastDateFormat analog for DecimalFormat Product: Commons Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: Lang AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Should commons-lang include something analogous to FastDateFormat as a replacement for DecimalFormat? Or is there no need (is DecimalFormat already thread-safe for formatting only)? -- 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: [transaction][VOTE] Release 1.1b2
+1, Stefan Oliver Zeigermann wrote: Dear community, after the first commons transaction 1.1 beta release - some bugs partially found by OJB committer Armin Waibel have been fixed, - some tests partially taken over from OJB have been added, and - tests on a multi processor machine have been successfully performed This seems to be enough to give commons transaction a second beta round. I have already created a new release tag using svn copy https://svn.apache.org/repos/asf/jakarta/commons/proper/transaction/trunk https://svn.apache.org/repos/asf/jakarta/commons/proper/transaction/tags/TRANSACTION_1_1_B2_RELEASE -m Tagging as 1.1b2 As usual I have already created the distributions by calling 'ant package'. They are ready for inspection here: http://www.apache.org/~ozeigermann/tx-1.1b2 The release notes are here: http://svn.apache.org/repos/asf/jakarta/commons/proper/transaction/tags/TRANSACTION_1_1_B2_RELEASE/RELEASE-NOTES.txt Here is my +1! Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Stefan Lützkendorf -- [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] temporary files
B. K. Oxley (binkley) wrote:
What's the right way to make a temporary file with VFS? I need some
for unit tests. For the nonce I did this:
FileObject createTemporary() {
// Using JDK UUID generator -- is this JDK1.3-compiant?
final FileObject tmp = VFS.getManager().resolveFile(
tmp:/ + UUID.randomUUID());
tmp.createFile();
return tmp;
}
But this has several drawbacks, among them:
* No automatic cleanup on exit as with File.deleteOnExit()
Yes - and in my opinion thats ok so. If you run VFS in an WebApp
environment the next exit might be very long in the future. And even
then, if the jvm crashes or is killed chances are good the files were
not deleted.
So doing a cleanup if the Filesystem is no longer needet should be a must.
This can easily be done with:
tmp.delete(new AllFileSelector());
A external cron-job (on unix) which delete all tempfs where the
modification-date is older than 2 days could also be a solution.
* Depends on TempFS being configured
Whats bad with this? TempFS is very lightweight.
* Relies on the static VFS.getManager() call
Not necessarily, you could create you own Manager if this is a
requirement, though - why is it bad?
StandardFileSystemManager fsm = new StandardFileSystemManager();
fsm.init();
* Smells hacky
You are right with the need to generate a UUID. Might it help if we
introduce a method to always create a new filesystem regardless if there
is already one cached. That way, you could always create a new empty TempFS.
Hmmm, but why dont you use the new RamFS ;-)
---
Mario
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[resources] todo
There is anyone working on Unit Tests for Property Resources or Unit Tests for Abstract Classess tasks? Woody - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] temporary files
Mario Ivankovits wrote: But this has several drawbacks, among them: * No automatic cleanup on exit as with File.deleteOnExit() Yes - and in my opinion thats ok so. If you run VFS in an WebApp environment the next exit might be very long in the future. And even then, if the jvm crashes or is killed chances are good the files were not deleted. Sorry, not for application code, for unit test code. I never use deleteOnExit() in production code -- that would be silly. :-) * Smells hacky You are right with the need to generate a UUID. Might it help if we introduce a method to always create a new filesystem regardless if there is already one cached. That way, you could always create a new empty TempFS. Hmmm, but why dont you use the new RamFS ;-) Yah, yah. Not there yet. :-) But this is a good point. Have you run across any good tree implementations? (I don't, of course, mean TreeMap.) Cheers, --binkley - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] temporary files
B. K. Oxley (binkley) wrote: Hmmm, but why dont you use the new RamFS ;-) Yah, yah. Not there yet. :-) But this is a good point. :-) I just wanted to underline the great possibilities. Have you run across any good tree implementations? (I don't, of course, mean TreeMap.) Dont know what you call a good tree, but maybe you might find one in http://jakarta.apache.org/commons/collections/ Api-doc of its maps: http://jakarta.apache.org/commons/collections/apidocs-COLLECTIONS_3_0/org/apache/commons/collections/map/package-summary.html --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r149546 - in jakarta/commons/proper/httpclient/trunk: project.xml src/test/org/apache/commons/httpclient/ssl/SimpleSSLSocketFactory.java src/test/org/apache/commons/httpclient/ssl/SimpleSSLTestProtocolSocketFactory.java
Author: olegk
Date: Wed Feb 2 10:51:25 2005
New Revision: 149546
URL: http://svn.apache.org/viewcvs?view=revrev=149546
Log:
Fixed the problem with the test server keytstore. Special thanks to Brett
Porter brett -at- apache.org
Modified:
jakarta/commons/proper/httpclient/trunk/project.xml
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
Modified: jakarta/commons/proper/httpclient/trunk/project.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/httpclient/trunk/project.xml?view=diffr1=149545r2=149546
==
--- jakarta/commons/proper/httpclient/trunk/project.xml (original)
+++ jakarta/commons/proper/httpclient/trunk/project.xml Wed Feb 2 10:51:25 2005
@@ -295,6 +295,14 @@
includes
include**/TestNoHost.java/include
/includes
+ resources
+resource
+ directorysrc/test/directory
+ includes
+include**/*.keystore/include
+ /includes
+/resource
+ /resources
/unitTest
/build
Modified:
jakarta/commons/proper/httpclient/trunk/src/test/org/apache/commons/httpclient/ssl/SimpleSSLSocketFactory.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/httpclient/trunk/src/test/org/apache/commons/httpclient/ssl/SimpleSSLSocketFactory.java?view=diffr1=149545r2=149546
==
---
jakarta/commons/proper/httpclient/trunk/src/test/org/apache/commons/httpclient/ssl/SimpleSSLSocketFactory.java
(original)
+++
jakarta/commons/proper/httpclient/trunk/src/test/org/apache/commons/httpclient/ssl/SimpleSSLSocketFactory.java
Wed Feb 2 10:51:25 2005
@@ -59,9 +59,6 @@
try {
ClassLoader cl = SimpleSocketFactory.class.getClassLoader();
URL url =
cl.getResource(org/apache/commons/httpclient/ssl/simpleserver.keystore);
-if (url == null) {
-url = new
URL(file:src/test/org/apache/commons/httpclient/ssl/simpleserver.keystore);
-}
KeyStore keystore = KeyStore.getInstance(jks);
keystore.load(url.openStream(), nopassword.toCharArray());
KeyManagerFactory kmfactory = KeyManagerFactory.getInstance(
Modified:
jakarta/commons/proper/httpclient/trunk/src/test/org/apache/commons/httpclient/ssl/SimpleSSLTestProtocolSocketFactory.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/httpclient/trunk/src/test/org/apache/commons/httpclient/ssl/SimpleSSLTestProtocolSocketFactory.java?view=diffr1=149545r2=149546
==
---
jakarta/commons/proper/httpclient/trunk/src/test/org/apache/commons/httpclient/ssl/SimpleSSLTestProtocolSocketFactory.java
(original)
+++
jakarta/commons/proper/httpclient/trunk/src/test/org/apache/commons/httpclient/ssl/SimpleSSLTestProtocolSocketFactory.java
Wed Feb 2 10:51:25 2005
@@ -58,9 +58,6 @@
try {
ClassLoader cl = SimpleSocketFactory.class.getClassLoader();
URL url =
cl.getResource(org/apache/commons/httpclient/ssl/simpleserver.keystore);
-if (url == null) {
-url = new
URL(file:src/test/org/apache/commons/httpclient/ssl/simpleserver.keystore);
-}
KeyStore keystore = KeyStore.getInstance(jks);
keystore.load(url.openStream(), nopassword.toCharArray());
TrustManagerFactory tmfactory = TrustManagerFactory.getInstance(
-
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
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? It truly does. Many thanks, Brett Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [resources] todo
What would like to know? -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 02, 2005 1:34 PM Subject: [resources] todo There is anyone working on Unit Tests for Property Resources or Unit Tests for Abstract Classess tasks? Woody - 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: [svn][ot] How to move a tag?
You mean retag a file that has already been tagged? You can probably copy with history again. If that doesn't work, it's probably a matter of essentially merging the changes since the file was tagged. Remember, svn doesn't really tag anything and there is nothing magic about the trunk, branches and tags directory. They are all just copies (with history). - Brett Oliver Zeigermann wrote: Folks, sorry, this is a bit OT, but I am struggeling how to move a tag in SVN. Any hints? Thanks in advance, Oliver - 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: [resources] todo
I can help in this tasks (and a little in documentation, with diagrams and so on). Can I? Woody What would like to know? James Mitchell There is anyone working on Unit Tests for Property Resources or Unit Tests for Abstract Classess tasks? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [resources] todo
You are welcome to take a look at it. The Resources project is pretty much complete and simply waiting for integration into Struts (and potentially other) projects. For Struts integration, it won't be much longer. -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: [EMAIL PROTECTED] To: Jakarta Commons Developers List commons-dev@jakarta.apache.org Sent: Wednesday, February 02, 2005 2:36 PM Subject: Re: [resources] todo I can help in this tasks (and a little in documentation, with diagrams and so on). Can I? Woody What would like to know? James Mitchell There is anyone working on Unit Tests for Property Resources or Unit Tests for Abstract Classess tasks? - 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]
svn commit: r151054 - in jakarta/commons/sandbox/feedparser/trunk/src/java/org/apache/commons/feedparser: MetaFeedParserListener.java example/HelloFeedParser.java sax/RSSFeedParser.java
Author: burton
Date: Wed Feb 2 13:00:54 2005
New Revision: 151054
URL: http://svn.apache.org/viewcvs?view=revrev=151054
Log:
example of how to include date info in a parser
Modified:
jakarta/commons/sandbox/feedparser/trunk/src/java/org/apache/commons/feedparser/MetaFeedParserListener.java
jakarta/commons/sandbox/feedparser/trunk/src/java/org/apache/commons/feedparser/example/HelloFeedParser.java
jakarta/commons/sandbox/feedparser/trunk/src/java/org/apache/commons/feedparser/sax/RSSFeedParser.java
Modified:
jakarta/commons/sandbox/feedparser/trunk/src/java/org/apache/commons/feedparser/MetaFeedParserListener.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/feedparser/trunk/src/java/org/apache/commons/feedparser/MetaFeedParserListener.java?view=diffr1=151053r2=151054
==
---
jakarta/commons/sandbox/feedparser/trunk/src/java/org/apache/commons/feedparser/MetaFeedParserListener.java
(original)
+++
jakarta/commons/sandbox/feedparser/trunk/src/java/org/apache/commons/feedparser/MetaFeedParserListener.java
Wed Feb 2 13:00:54 2005
@@ -117,5 +117,24 @@
public void onGenerator( FeedParserState state, String content ) throws
FeedParserException;
public void onGeneratorEnd() throws FeedParserException;
-}
+/**
+ * Provided for author information across RSS 2.0, atom, dc:creator in RSS
+ * 1.0. Both email, and resource may be null if not specified.
+ *
+ * TODO: what does RSS 0.91, 0.9, etc provide?
+ *
+ * NOTE that this is not yet 100% compatible with FOAF person constructs.
+ * FOAF provides additional metadata including title, firstName, surname,
+ * nick, etc which we don't provide with this method. We'll probably add
+ * additional events for this in the future.
+ *
+ * @author a href=mailto:[EMAIL PROTECTED]Kevin A. Burton/a
+ */
+public void onAuthor( FeedParserState state,
+ String name,
+ String email,
+ String resource ) throws FeedParserException;
+public void onAuthorEnd() throws FeedParserException;
+
+}
Modified:
jakarta/commons/sandbox/feedparser/trunk/src/java/org/apache/commons/feedparser/example/HelloFeedParser.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/feedparser/trunk/src/java/org/apache/commons/feedparser/example/HelloFeedParser.java?view=diffr1=151053r2=151054
==
---
jakarta/commons/sandbox/feedparser/trunk/src/java/org/apache/commons/feedparser/example/HelloFeedParser.java
(original)
+++
jakarta/commons/sandbox/feedparser/trunk/src/java/org/apache/commons/feedparser/example/HelloFeedParser.java
Wed Feb 2 13:00:54 2005
@@ -50,11 +50,21 @@
}
+public void onCreated( FeedParserState state, Date date )
throws FeedParserException {
+System.out.println( Which was created on: + date );
+}
+
};
//specify the feed we want to fetch
+
String resource = http://peerfear.org/rss/index.rss;;
+if ( args.length == 1 )
+resource = args[0];
+
+System.out.println( Fetching resource: + resource );
+
//use the FeedParser network IO package to fetch our resource URL
ResourceRequest request = ResourceRequestFactory.getResourceRequest(
resource );
Modified:
jakarta/commons/sandbox/feedparser/trunk/src/java/org/apache/commons/feedparser/sax/RSSFeedParser.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/feedparser/trunk/src/java/org/apache/commons/feedparser/sax/RSSFeedParser.java?view=diffr1=151053r2=151054
==
---
jakarta/commons/sandbox/feedparser/trunk/src/java/org/apache/commons/feedparser/sax/RSSFeedParser.java
(original)
+++
jakarta/commons/sandbox/feedparser/trunk/src/java/org/apache/commons/feedparser/sax/RSSFeedParser.java
Wed Feb 2 13:00:54 2005
@@ -31,7 +31,7 @@
/** *
* @author a href=mailto:[EMAIL PROTECTED]Kevin A. Burton (burtonator)/a
- * @version $Id: RSSFeedParser.java,v 1.2 2004/04/23 17:45:43 burton Exp $
+ * @version $Id$
*/
public class RSSFeedParser extends BaseDefaultHandler {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33167] - [dbcp] Individual connection close method
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=33167. 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=33167 --- Additional Comments From [EMAIL PROTECTED] 2005-02-02 22:02 --- I'm wondering if the pool should be removed from the pools map = pools.remove(key) and thus needs to be synchronized. Looking at pool.close() I think the pool will be unusable once it has been closed. Do you have JUnit tests showing the correct working of this new method? (use pool, close, use pool again ?) -- 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 33167] - [dbcp] Individual connection close method
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=33167.
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=33167
--- Additional Comments From [EMAIL PROTECTED] 2005-02-02 22:19 ---
JUnit Test case for my initial the code I posted
public void testClosing1() throws Exception {
Connection c = null;
c = ds.getConnection(u1,p1);
ds.close(u1);
assertTrue(c.isClosed());
c = ds.getConnection(u1,p1);
assertTrue(!c.isClosed());
}
As far as removing the pool, if we don't leave it will it be reused, inwhich
case it can be left there. I am not sure about what should be done there.
--
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: [resources] complete class diagram
I think James wants an enhancement issue in bugzilla with the file attached. -- Dirk Anaximandro (Woody) wrote: enhancement ticket? I dono if I really understand this ... Well, lets go If anyone needs the model (rose) send me a note. Woody - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] proposal: FileUtils
B. K. Oxley (binkley) wrote:
I'm curious what you find out about Commons Transactions. When I
looked it over, it seemd to me designed with primitives for us to use
to make our own transactions. I missed any ready-to-use code for this
purpose.
After 2 hours of copy/paste their FileResourceManager to use
vfs.FileObject only I am able to do such thing:
// init phase
String tx1 = tx1;
VFSResourceManager rsm = new VFSResourceManager(
VFS.getManager(),
/home/im/tmp/tx/store, // = root filesystem where the
real stuff should happen on commit
/home/im/tmp/tx/work, // = work filesystem - could be
different to store above
new PrintWriterLogger(new PrintWriter(System.err), VFS, true),
true
);
rsm.start();
// start transaction
rsm.startTransaction(tx1);
// create file1
rsm.createResource(tx1, dir1/file1.txt);
// create file2
rsm.createResource(tx1, dir2/file1.txt);
// write into file1
OutputStream os = rsm.writeResource(tx1, dir1/file1.txt);
os.write(test.getBytes());
os.close();
// delete file2
rsm.deleteResource(tx1, dir2/file1.txt);
rsm.deleteResource(tx1, dir2); // = dir2 has been created by
the above createResource - now we have to remove it here manually.
// commit transaction
rsm.commitTransaction(tx1);
Now - whats missing in this example? right there is no move
or rename operation.
Summary:
*) implement rename
*) implement something like listResource(tx) where we could get a list
of all files in an directory - including/excluding those created/deleted
within the transation.
Both need some more investigation to see how this could happen.
After experimenting a little bit it is fantastic to see who it prevents
two simultan transactions to create the same file - in fact it isnt
prevent - the second transaction just waits until the first has finished
and then the second gains the lock.
So we get in-process locking for free.
The above code is just a start, but think of a file-object where the
transactional logic is encapsulated and one can do whatever he wants -
it will only be represented on the filesystem if commit() has been called.
FileObject foRootTransactional = VFS.getManager().beginTransaction(foRoot)
for (child .. foRootTransactional.getChildren())
{
child.delete();
}
VFS.getManager().commitTransaction(foRootTransactional);
And maybe if your RamFS comes to reality we could use it as work-space
e.g. if we know we handle only small transactions.
I am looking forward to read what you think about it.
If you would like to experiment a little bit follow the instructions at
http://l3x.net/imwiki/Wiki.jsp?page=VfsStuff
---
Mario
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r151071 - jakarta/commons/proper/chain/trunk/src/java/org/apache/commons/chain/generic/DispatchCommand.java
Author: jmitchell Date: Wed Feb 2 14:17:52 2005 New Revision: 151071 URL: http://svn.apache.org/viewcvs?view=revrev=151071 Log: remove used import Modified: jakarta/commons/proper/chain/trunk/src/java/org/apache/commons/chain/generic/DispatchCommand.java Modified: jakarta/commons/proper/chain/trunk/src/java/org/apache/commons/chain/generic/DispatchCommand.java URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/chain/trunk/src/java/org/apache/commons/chain/generic/DispatchCommand.java?view=diffr1=151070r2=151071 == --- jakarta/commons/proper/chain/trunk/src/java/org/apache/commons/chain/generic/DispatchCommand.java (original) +++ jakarta/commons/proper/chain/trunk/src/java/org/apache/commons/chain/generic/DispatchCommand.java Wed Feb 2 14:17:52 2005 @@ -4,7 +4,6 @@ import org.apache.commons.chain.Context; import java.lang.reflect.Method; import java.util.WeakHashMap; -import java.lang.reflect.InvocationTargetException; /** * An abstract base command which uses introspection to look up a method to execute. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
Hi Oliver,
On Wed, 2005-02-02 at 15:22 +0100, Oliver Zeigermann wrote:
On Wed, 02 Feb 2005 14:48:42 +1300, Simon Kitching [EMAIL PROTECTED] wrote:
- 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?
Well, RuleManager is an abstract class (discussion abstract class vs.
interface applies here as well) with a default implemenation, but
Pattern is a String. Wouldn't it be more flexible with little extra
cost to have a Pattern interface with a default String Path
implementation like the current one?
Well, I would prefer to avoid having users do:
addRule(new Pattern(/foo/bar), )
as this is just more readable:
addRule(/foo/bar, ...)
However if we ever do find that there are some patterns that just can't
be represented nicely as a string, then we could simply add a new
method:
addRule(Pattern p, ...) { }
and reimplement addRule to preserve compatibility:
addRule(String s, ... ) { addRule(new Pattern(s), ...); }
So in short, I would prefer [1] to keep the current String pattern as
one of the options, for user convenience, but I don't see any major
issue with adding Patterns later if we need them. I guess it would break
custom subclasses of RuleManager, but that would be a very rare thing to
do.
And right now, DefaultRuleManager definitely needs its patterns to be
strings, so if we had a Pattern class as the pattern, we would be
forcing users to create an instance just so the DefaultRuleManager could
turn it back into a string.
- I like the bodySegment vs. body design :)
Cool. Now I just have to implement it :-)
Ooops, doesn't it work, yet?
Minor detail. I just need to merge the code from the example I
referenced into the core. Why are there never enough hours in a day?
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 was also wondering, there may be occasions where it is desirable to
have the full body *including tags* passed in a call back. This would
mostly apply in mixed context tags where text is mixed with style
information that do not need processing like with XTHML.
You mean stringify the child elements too, like XSLT does if you ask for
the text of a mixed-content element?
I suppose we could do this, though I am not entirely sure how much use
this would be. Can you think of a use-case?
If you mean pass a DOM tree into the Action to represent the full body
content, I think not :-).
- 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.
Tomcat does not need to as it is no library. commons-collections
should better have done this - for more details have a look at the
thread all this was discussed in recently.
Yes, I remember that thread. I'll re-read it.
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.
Could you elaborate this?
Suppose digester requires beanutils 1.7, but a user wants to call
digester from an app that is using beanutils 1.6 (or 1.8) or similar,
and the beanutils lib versions are incompatible.
In this situation, the user is currently out of luck (or at least there
is no documented solution).
But using classloaders it is possible to access classes different from
the classes available to other parts of an app. For example, webapps in
tomcat have their own private libs that are not available to either
tomcat or sibling webapps. Using this sort of trick, we could arrange
for digester to access all the beanutils classes via a user-provided
classloader, which accesses a beanutils-1.7.jar that is not in the
classpath for the rest of the app.
I haven't really thought about this in detail; it's just an idea at the
moment. I'm vaguely envisaging a method
Digester.setLibraryClassLoader(ClassLoader cl)
or
Digester.setLibraryClasspath(String customClasspath)
It might end up better to load the whole of Digester in a custom
classloader, in which case the problem is pushed back up to the user
domain; all we would need to do is document how to do this rather than
actually add any custom code.
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.
That's exactly what I would want to see.
Well, it's done. I hope to post the new version later today.
RE: [digester] initial code for Digester2.0
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. Maybe I wasn't clear enough - I didn't say that the Action interface should not be implemented by anything except the default implementation (what indeed would be the point of that?). The point is, the majority of Actions that people create would extend the default implementation, and would be (mostly) immune to API evolution. People who decide to implement Action directly are free to do so - and they accept that if they do so then they will need to evolve with the API. As Oliver said, if you use an interface then you have some extra options for how you add functionality, such as adding new interfaces that extend Action. Colin Sharples IBM Advisory IT Specialist Email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
On Wed, 2005-02-02 at 06:04 -0800, Reid Pinchback wrote: --- Oliver Zeigermann [EMAIL PROTECTED] wrote: On Wed, 02 Feb 2005 18:28:04 +1300, Simon Kitching [EMAIL PROTECTED] wrote: 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. I am +1 for using an interface and the default (why abstract?) implementation like with Swing or SAX. I don't get why we would ever warn people not to implement the interface We (digester developers) want the ability to add methods to Action in minor releases. But adding methods to an interface breaks all classes that directly implement that interface. So people should not extend an Action interface because their classes could be broken by a minor-version update of Digester, eg 2.0 - 2.1. They wouldn't be forbidden from implementing Action, just warned about the consequences. By encouraging users to extend AbstractAction instead of implementing Action, we have the chance to provide default implementations for new functionality, and thereby give ourselves the chance to improve digester in minor releases without breaking user code. Here is a concrete example of why you could want to implement the interface and extend another class, I've actually had situations with the existing Digester where I'd wished I could do that. The one that I can recall now was an instrumentation issue. Doing debugging and performance tuning of a suite of rules can be tedious because, currently, the only options are either to watch a spew of logging messages or single-step your way through all the callbacks in a debugger (PAIN). If the major coupling points in the Digester had been abstracted by interfaces, it would have been easier to insert instrumentation proxies or EasyMock'd test implementations of classes at key points. I don't know much about EasyMock, and have only rarely used java.lang.reflect.Proxy. But if having an Interface rather than an abstract class makes it easier to use these, then that's a very good point in favour of Colin Sharples' recommendation to create Action (interface) + AbstractAction (class). Normal code extends AbstractAction, but instrumentation code can proxy the interface if it really needs to. And as these uses of the interface are transient, we don't have to worry about breaking code when the interface is modified, right? Does this satisfy your concerns? Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33377] New: - A bug in BeanPointer::asPath()
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=33377.
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=33377
Summary: A bug in BeanPointer::asPath()
Product: Commons
Version: 1.2 Final
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: major
Priority: P2
Component: JXPath
AssignedTo: commons-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
The method call JXPathContext::iteratePointers() returns the correct number of
pointers. However, the pointers do not always return correct path on asPath()
method call on them. A pointer returns a path that corresponds to the last
Node in the sibling Nodes of the node that the pointer points to.
Here is an example:
Class A{
private List list;
//getter and setter
:
}
Here is a code snippet for creating an object graph that starts from
instance of A.
A a1 = new A();
List list1 = new LinkedList();
A a11 = new A();
list1.add(a11);
A a12 = new A();
List list12 = new LinkedList();
A a121 = new A();
list12.add(a121);
a12.setList(list12);
list1.add(a12);
A a13 = new A();
list1.add(a11);
a1.setList(list1);
And the list attribute can have instances of A as elements in it.
The JXPathContext correspong to a1 returns pointers when it's iteratePointers
() method is called. And the pointers correspond to the following nodes.
A[1]
A[2]
A[2]/A[1]
A[3]
This is absolutely as expected. However, asPath() method on each of these
Pointers do not always return the correct path.
Currently, the asPath() method calls on the corresponding Pointers return this
output respectively.
A[3]
A[3]
A[2]/A[1]
A[3]
This needs to be 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: [resources] complete class diagram
Ohh, Know I understand ... Sorry. I will post this today. I think James wants an enhancement issue in bugzilla with the file attached. -- Dirk Anaximandro (Woody) wrote: enhancement ticket? I dono if I really understand this ... Well, lets go If anyone needs the model (rose) send me a note. Woody - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33379] New: - Class diagram
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=33379. 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=33379 Summary: Class diagram Product: Commons Version: unspecified Platform: PC OS/Version: Windows 2000 Status: NEW Severity: enhancement Priority: P2 Component: Resources AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL 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 33379] - Class diagram
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=33379. 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=33379 --- Additional Comments From [EMAIL PROTECTED] 2005-02-03 00:37 --- Created an attachment (id=14164) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14164action=view) jakarta-commons-resources class diagram -- 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: [svn][ot] How to move a tag?
Yes, that's what I was trying. However, merging the new stuff in generated a new trunk inside the tag (which seems to be just like a branch). Isn't there anything similiar to CVS moving a tag? Thanks anyway :) Oliver On Thu, 03 Feb 2005 06:32:26 +1100, Brett Porter [EMAIL PROTECTED] wrote: You mean retag a file that has already been tagged? You can probably copy with history again. If that doesn't work, it's probably a matter of essentially merging the changes since the file was tagged. Remember, svn doesn't really tag anything and there is nothing magic about the trunk, branches and tags directory. They are all just copies (with history). - Brett Oliver Zeigermann wrote: Folks, sorry, this is a bit OT, but I am struggeling how to move a tag in SVN. Any hints? Thanks in advance, Oliver - 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: [digester] initial code for Digester2.0
On Thu, 03 Feb 2005 11:39:01 +1300, Simon Kitching [EMAIL PROTECTED] wrote: I was also wondering, there may be occasions where it is desirable to have the full body *including tags* passed in a call back. This would mostly apply in mixed context tags where text is mixed with style information that do not need processing like with XTHML. You mean stringify the child elements too, like XSLT does if you ask for the text of a mixed-content element? Yes. I suppose we could do this, though I am not entirely sure how much use this would be. Can you think of a use-case? Think of the transformation of our web pages. There is structure information wrapping pure XHTML. You would not want a callback for all formatting tags, would you? Maybe this is not a very common use of Digester, though... If you mean pass a DOM tree into the Action to represent the full body content, I think not :-). Certainly not. I think there is no place for the DOM in Digester. Or are you by chance referring to my suggestions for xml-rules? No, what are they? I was puzzled about your reference to reflection in the previous email, as accessing Rule (now Action) classes is never done via reflection. However in the RELEASE-NOTES.txt I do discuss possible updates to the classes in the xmlrules package to use reflection to make Action classes accessable via the xmlrules mapping file rather than have the xmlrules java code contain an explicit mapping class for each Action as is currently done. Is that so? I have no internal knowlede of beanutils, but I thought there is no other way of calling a parameterized method than by refelection methods. But I am happy to learn something here :) 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? Honestly, I do not remember much of that discussion, but I thought we came to the conclusion that we would try to make xmlio obsolete with Digester2. The reason I preferred xmlio over digester was simplicity and obviousness mainly. Now this new Digester2 core (even better with the Action subclasses in a package of their own) is simple and obvious as well, so I see no strong reason to stick to xmlio. That would be very cool. I remember the main issue being that Digester is built around the concept of having patterns control what operations were executed for each xml element, and having the invoked logic partitioned into many small Rule classes. You wished the user to write a big switch statement in Java to determine what operations were executed, as you felt that this was more natural to people used to writing SAX code by hand. We did briefly discuss ways of layering the code so that these were two possible options the user could choose between, but I couldn't see then how this would be possible. Thanks for reminding me of my reservations :) Now I remember! Especially when writing rahter simply import code I think it is much easier and obvious to have all the code at one position instead of having it distributed into many classes. However, this seems to be rather simple to accomplish. You just register a single action to be matched for all elements and then access the context to tell you the path of the current element. Maybe having a conveniece method to match paths to the current element directly. Wouldn't this work? Speed is another issue with xmlio, as it is really fast. But with some optimizations geared towards this, digester shoudn't relly be much slower anyway... If you can think of some way of merging these quite different approaches, I'm very keen to hear it. Or if you feel more kindly toward a distributed pattern-matching + Action class approach, then that would resolve the major issue and we can look at how the other xmlio features could be provided in Digester (well, we can do that anyway!). Are you thinking of the export features? Thinking of the import features, having more than one actions being invoked on a certain element would be essantial. Just think of some sorf of logging or debugging action that is triggered with every element next to the normal processing. Does this currently work with digester 2? Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
VOTE: FeedParser move to Commons Proper...
Subject: Hey gang. I'd like to propose that we move FeedParser into commons proper. The main personal requirement for this is that I want to do a 0.5 release for my CodeCon talk on the FeedParser on Feb 11. http://jakarta.apache.org/commons/sandbox/feedparser/ We've been in the sandbox for 11 months now. The FeedParser itself is more than 2 years old. Its currently used in production at rojo.com to handle more than 1.9 million feeds. We currently have three developers working on the FeedParser: Kevin Burton (me) Brad Neuberg (Rojo Networks Inc.) Joseph Ottinger (Fusion Alliance) We're also working with the Rome developers (another RSS parser) to try to standardize APIs and are collaborating on a common feed parsing components including networking IO, autodiscovery, unit test, and potential collaboration. In order for this to happen though I need to get a stable release of FeedParser out the door and the sandbox doesn't allow any releases. I also want to be able to give out SVN commit to additional developers as they come on board. Also... I assume we can get a dedicated mailing list for the FeedParser? HttpClient is currently doing this. The roadmap for FeedParser is to get a 0.5 release out before Feb 11 and then about a month later to release 1.0. Then I want to start working on better and DEEPER unit tests and then rewrite the backend to use SAX. At this point I can make a better case that the Rome developers should build their object model on top of FeedParser Thanks guys!!! -- Use Rojo (RSS/Atom aggregator). Visit http://rojo.com. Ask me for an invite! Also see irc.freenode.net #rojo if you want to chat. Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html If you're interested in RSS, Weblogs, Social Networking, etc... then you should work for Rojo! If you recommend someone and we hire them you'll get a free iPod! Kevin A. Burton, Location - San Francisco, CA AIM/YIM - sfburtonator, Web - http://peerfear.org/ GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [svn][ot] How to move a tag?
Hi Oliver,
I don't quite understand what you are trying to do. I hope the following
helps (though I'm not an SVN guru, so others might correct this).
Normally CVS tags are simply used to mark a set of files so that you
can retrieve that same set later. In this case, the equivalent in
subversion is just to use
svn cp {from} {to}
eg
svn cp https:///trunk https://.../tags/beta1
to save the current state of the trunk as a directory beta1. The copy
command makes a light-weight copy, essentially a sort of hard link
with copy-on-write so updates don't affect the original source.
If the trunk versions move on, and you later want beta1 to include one
of the updated files, then update what beta1 refers to by relinking
from the beta1 directory to the version you really want:
* removing the file (link) you no longer need from the tag dir
eg svn rm https://../tags//foo.txt [1]
* copying back in (ie link to) the version you want
eg svn cp
-r 100 https:///trunk/.../foo.txt [2]
https:///tags/.../foo.txt [3]
[1] or if you have a working copy of the tag dir, you can
do svn rm and svn commit
[2] if you want the latest version, just omit the -r 100.
[3] or if you have a working copy of the tag, copy to your working
copy then svn commit it.
Performing the copy again (ie linking to the *updated* file [together
with its history] from the tag) is what Brett means by copy with
history again. Using svn merge doesn't do the same thing, because it
is effectively generating a patch file then applying it to your version;
the differences get merged in, but not the history.
Alternatively, if the updated tag is meant to look mostly or
completely like the new trunk, then just use svn update to ensure your
trunk working copy looks like the stuff you want to tag, then delete the
old beta1 directory, and recreate it. Copies are cheap!
There isn't any difference between a directory created with the intent
of just using it as a tag and a directory created with the intent of
using it as a branch. The convention of putting the scn copy into
subdirs {project}/branches and {project}/tags are traditionally used
to *indicate the intent* of the copy, but they are functionally
identical.
For some other traditional uses of CVS tags, it might be better to use
subversion properties (see svn set-prop).
I suggest you read the subversion manual, particularly the section on
branches. It is very well written..
http://svnbook.red-bean.com/
Regards
Simon
PS: Bottom-posting would have made this thread much more readable!
On Thu, 2005-02-03 at 01:44 +0100, Oliver Zeigermann wrote:
Yes, that's what I was trying. However, merging the new stuff in
generated a new trunk inside the tag (which seems to be just like a
branch). Isn't there anything similiar to CVS moving a tag?
Thanks anyway :)
Oliver
On Thu, 03 Feb 2005 06:32:26 +1100, Brett Porter [EMAIL PROTECTED] wrote:
You mean retag a file that has already been tagged?
You can probably copy with history again. If that doesn't work, it's
probably a matter of essentially merging the changes since the file was
tagged.
Remember, svn doesn't really tag anything and there is nothing magic
about the trunk, branches and tags directory. They are all just copies
(with history).
- Brett
Oliver Zeigermann wrote:
Folks,
sorry, this is a bit OT, but I am struggeling how to move a tag in SVN.
Any hints?
Thanks in advance,
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Commons Wiki] Updated: FeedParser/HelpingDevel
Date: 2005-02-02T18:16:00 Editor: KevinBurton Wiki: Jakarta Commons Wiki Page: FeedParser/HelpingDevel URL: http://wiki.apache.org/jakarta-commons/FeedParser/HelpingDevel no comment Change Log: -- @@ -2,9 +2,7 @@ * Publicize FeedParser. We need more people to find FeedParser. This includes a Freshmeat entry, Maybe a post to JavaBlogs... Maybe something on Javalobby. Maybe an O'Reilly article... * Setup Bugzilla within Apache - * Setup website so that it builds within Apache - * Integration with GUMP? - * Fix the maven build so that it works correctly + * Fix the maven build so that it works correctly with 'jar' * More documentation * More unit tests * Feedback - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction][VOTE] Release 1.1b2
Looks good. +1 -James On Wed, 2005-02-02 at 17:03 +0100, Oliver Zeigermann wrote: Dear community, after the first commons transaction 1.1 beta release - some bugs partially found by OJB committer Armin Waibel have been fixed, - some tests partially taken over from OJB have been added, and - tests on a multi processor machine have been successfully performed This seems to be enough to give commons transaction a second beta round. I have already created a new release tag using svn copy https://svn.apache.org/repos/asf/jakarta/commons/proper/transaction/trunk https://svn.apache.org/repos/asf/jakarta/commons/proper/transaction/tags/TRANSACTION_1_1_B2_RELEASE -m Tagging as 1.1b2 As usual I have already created the distributions by calling 'ant package'. They are ready for inspection here: http://www.apache.org/~ozeigermann/tx-1.1b2 The release notes are here: http://svn.apache.org/repos/asf/jakarta/commons/proper/transaction/tags/TRANSACTION_1_1_B2_RELEASE/RELEASE-NOTES.txt Here is my +1! Oliver - 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]
svn commit: r151102 - in jakarta/commons/sandbox/feedparser/trunk: build.xml src/java/org/apache/commons/feedparser/example/HelloFeedParser.java xdocs/index.xml
Author: burton
Date: Wed Feb 2 18:23:27 2005
New Revision: 151102
URL: http://svn.apache.org/viewcvs?view=revrev=151102
Log:
dox for a more advanced feedparser.
Modified:
jakarta/commons/sandbox/feedparser/trunk/build.xml
jakarta/commons/sandbox/feedparser/trunk/src/java/org/apache/commons/feedparser/example/HelloFeedParser.java
jakarta/commons/sandbox/feedparser/trunk/xdocs/index.xml
Modified: jakarta/commons/sandbox/feedparser/trunk/build.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/feedparser/trunk/build.xml?view=diffr1=151101r2=151102
==
--- jakarta/commons/sandbox/feedparser/trunk/build.xml (original)
+++ jakarta/commons/sandbox/feedparser/trunk/build.xml Wed Feb 2 18:23:27 2005
@@ -141,10 +141,10 @@
target name=test depends=jar,compile.test description=Run junit
tests. if=junit.available
junit printsummary=withOutAndErr
-fork=true
-filtertrace=true
-haltonfailure=true
-haltonerror=false
+ fork=true
+ filtertrace=true
+ haltonfailure=true
+ haltonerror=false
sysproperty key=feedparser.home value=${feedparser.home}/
classpath
path refid=project.classpath/
Modified:
jakarta/commons/sandbox/feedparser/trunk/src/java/org/apache/commons/feedparser/example/HelloFeedParser.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/feedparser/trunk/src/java/org/apache/commons/feedparser/example/HelloFeedParser.java?view=diffr1=151101r2=151102
==
---
jakarta/commons/sandbox/feedparser/trunk/src/java/org/apache/commons/feedparser/example/HelloFeedParser.java
(original)
+++
jakarta/commons/sandbox/feedparser/trunk/src/java/org/apache/commons/feedparser/example/HelloFeedParser.java
Wed Feb 2 18:23:27 2005
@@ -40,6 +40,15 @@
//create a listener for handling our callbacks
FeedParserListener listener = new DefaultFeedParserListener() {
+public void onChannel( FeedParserState state,
+ String title,
+ String link,
+ String description ) throws
FeedParserException {
+
+System.out.println( Found a new channel: + title );
+
+}
+
public void onItem( FeedParserState state,
String title,
String link,
Modified: jakarta/commons/sandbox/feedparser/trunk/xdocs/index.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/feedparser/trunk/xdocs/index.xml?view=diffr1=151101r2=151102
==
--- jakarta/commons/sandbox/feedparser/trunk/xdocs/index.xml (original)
+++ jakarta/commons/sandbox/feedparser/trunk/xdocs/index.xml Wed Feb 2
18:23:27 2005
@@ -207,10 +207,22 @@
/p
source
+
+//create a new FeedParser...
FeedParser parser = FeedParserFactory.newFeedParser();
+//create a listener for handling our callbacks
FeedParserListener listener = new DefaultFeedParserListener() {
+public void onChannel( FeedParserState state,
+ String title,
+ String link,
+ String description ) throws FeedParserException
{
+
+System.out.println( Found a new channel: + title );
+
+}
+
public void onItem( FeedParserState state,
String title,
String link,
@@ -221,9 +233,29 @@
}
+public void onCreated( FeedParserState state, Date date ) throws
FeedParserException {
+System.out.println( Which was created on: + date );
+}
+
};
-parser.parse( listener, new URL( http://peerfear.org/rss/index.rss;
).openStream() );
+//specify the feed we want to fetch
+
+String resource = http://peerfear.org/rss/index.rss;;
+
+if ( args.length == 1 )
+resource = args[0];
+
+System.out.println( Fetching resource: + resource );
+
+//use the FeedParser network IO package to fetch our resource URL
+ResourceRequest request = ResourceRequestFactory.getResourceRequest( resource
);
+
+//grab our input stream
+InputStream is = request.getInputStream();
+
+//start parsing our feed and have the above onItem methods called
+parser.parse( listener, is, resource );
/source
@@ -367,6 +399,38 @@
/section
--
+
+section name=Visualizing FeedParser Events
+
+p
+
+The FeedParser includes a sample console application which
+accepts a URL to a feed, parses it, receives events, and then
+
Re: [digester] initial code for Digester2.0
On Thu, 2005-02-03 at 02:11 +0100, Oliver Zeigermann wrote:
On Thu, 03 Feb 2005 11:39:01 +1300, Simon Kitching [EMAIL PROTECTED] wrote:
I was also wondering, there may be occasions where it is desirable to
have the full body *including tags* passed in a call back. This would
mostly apply in mixed context tags where text is mixed with style
information that do not need processing like with XTHML.
You mean stringify the child elements too, like XSLT does if you ask for
the text of a mixed-content element?
Yes.
I suppose we could do this, though I am not entirely sure how much use
this would be. Can you think of a use-case?
Think of the transformation of our web pages. There is structure
information wrapping pure XHTML. You would not want a callback for all
formatting tags, would you? Maybe this is not a very common use of
Digester, though...
Ok, I see. It would be reasonably simple to implement; we already
calculate the full text for each element (so we can pass it to the body
methods) in the SAXHandler class; we just need to keep appending these
instead of discarding them when the element ends.
One issue, I guess, is that by the end of the document we have a
StringBuffer that contains the entire text for the entire document -
which might take up a bit of memory. So maybe we need some mechanism for
an Action to tell the SAXHandler [from its begin() method, via a mixin
interface, or otherwise] that it wants a full text tree. The SAXHandler
can then start accumulating.
If you wished to contribute such a patch, I think I'd be in favour of
it.
If you mean pass a DOM tree into the Action to represent the full body
content, I think not :-).
Certainly not. I think there is no place for the DOM in Digester.
Phew! :-)
Or are you by chance referring to my suggestions for xml-rules?
No, what are they?
I was puzzled about your reference to reflection in the previous
email, as accessing Rule (now Action) classes is never done via
reflection. However in the RELEASE-NOTES.txt I do discuss possible
updates to the classes in the xmlrules package to use reflection to make
Action classes accessable via the xmlrules mapping file rather than have
the xmlrules java code contain an explicit mapping class for each Action
as is currently done.
Is that so? I have no internal knowlede of beanutils, but I thought
there is no other way of calling a parameterized method than by
refelection methods. But I am happy to learn something here :)
Just some minor misunderstanding I think..
The digester framework invokes Rule (Action) classes directly. There is
no reflection involved in the invocation of Rule (Action) classes.
I am proposing that xmlrules actually uses reflection to generate a set
of Action objects when parsing its rule configuration input file. Of
course the parsing of the actual user input would then be done in the
normal manner (with the digester framework calling the Actions
directly).
The Rule (Action) classes interact with domain-specific (user) classes
via BeanUtils and reflection. I don't see any alternative, except for
the pre-processor type xml mapping tools, or runtime bytecode
generation, neither of which are really Digester's domain.
I remember the main issue being that Digester is built around the
concept of having patterns control what operations were executed for
each xml element, and having the invoked logic partitioned into many
small Rule classes.
You wished the user to write a big switch statement in Java to determine
what operations were executed, as you felt that this was more natural to
people used to writing SAX code by hand.
We did briefly discuss ways of layering the code so that these were two
possible options the user could choose between, but I couldn't see then
how this would be possible.
Thanks for reminding me of my reservations :) Now I remember!
Especially when writing rahter simply import code I think it is much
easier and obvious to have all the code at one position instead of
having it distributed into many classes. However, this seems to be
rather simple to accomplish. You just register a single action to be
matched for all elements and then access the context to tell you the
path of the current element. Maybe having a conveniece method to match
paths to the current element directly.
Wouldn't this work?
Hmm.. If we had a class that implements RuleManager that always returns
a custom Action no matter what the path, then all events would be
forwarded to the user-provided action, where the user can call
context.getMatchPath()
to access the current path, and determine from there what operations to
perform.
// xmlio-style digester
Action myHandler = new AbstractAction() {
public void begin(
Context context,
String namespace, String name,
Attributes attrs) {
String path = context.getMatchPath();
if (path.equals(..)) {
svn commit: r151107 - in jakarta/commons/sandbox/feedparser/trunk/src/java/org/apache/commons/feedparser: DefaultFeedParserListener.java MetaFeedParser.java impl/DebugFeedParserListener.java
Author: burton
Date: Wed Feb 2 18:50:39 2005
New Revision: 151107
URL: http://svn.apache.org/viewcvs?view=revrev=151107
Log:
support for new onAuthor methods
Modified:
jakarta/commons/sandbox/feedparser/trunk/src/java/org/apache/commons/feedparser/DefaultFeedParserListener.java
jakarta/commons/sandbox/feedparser/trunk/src/java/org/apache/commons/feedparser/MetaFeedParser.java
jakarta/commons/sandbox/feedparser/trunk/src/java/org/apache/commons/feedparser/impl/DebugFeedParserListener.java
Modified:
jakarta/commons/sandbox/feedparser/trunk/src/java/org/apache/commons/feedparser/DefaultFeedParserListener.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/feedparser/trunk/src/java/org/apache/commons/feedparser/DefaultFeedParserListener.java?view=diffr1=151106r2=151107
==
---
jakarta/commons/sandbox/feedparser/trunk/src/java/org/apache/commons/feedparser/DefaultFeedParserListener.java
(original)
+++
jakarta/commons/sandbox/feedparser/trunk/src/java/org/apache/commons/feedparser/DefaultFeedParserListener.java
Wed Feb 2 18:50:39 2005
@@ -106,6 +106,13 @@
public void onGenerator( FeedParserState state, String content ) throws
FeedParserException {}
public void onGeneratorEnd() throws FeedParserException {}
+public void onAuthor( FeedParserState state,
+ String name,
+ String email,
+ String resource ) throws FeedParserException {}
+
+public void onAuthorEnd() throws FeedParserException {}
+
// ModContentFeedParserListener
public void onContentEncoded( FeedParserState state,
Modified:
jakarta/commons/sandbox/feedparser/trunk/src/java/org/apache/commons/feedparser/MetaFeedParser.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/feedparser/trunk/src/java/org/apache/commons/feedparser/MetaFeedParser.java?view=diffr1=151106r2=151107
==
---
jakarta/commons/sandbox/feedparser/trunk/src/java/org/apache/commons/feedparser/MetaFeedParser.java
(original)
+++
jakarta/commons/sandbox/feedparser/trunk/src/java/org/apache/commons/feedparser/MetaFeedParser.java
Wed Feb 2 18:50:39 2005
@@ -32,7 +32,7 @@
* @author a href=mailto:[EMAIL PROTECTED]Kevin A. Burton (burtonator)/a
* @version $Id$
*/
-public class MetaFeedParser {
+public class MetaFeedParser extends BaseParser {
/**
*
@@ -55,7 +55,60 @@
//confirm but I think they are working correctly
parseGUID( state, mfp );
-
+
+parseAuthor( state, mfp );
+
+}
+
+private static void parseAuthor( FeedParserState state,
+ MetaFeedParserListener listener )
+throws FeedParserException {
+
+Element element = null;
+
+String name = null;
+String email = null;
+String resource = null;
+
+try {
+
+//atom:author
+
+element = state.current.getChild( author, NS.ATOM );
+
+if ( element != null ) {
+name = selectText( atom:name, element );
+email = selectText( atom:email, element );
+resource = selectText( atom:uri, element );
+}
+
+//dc:creator (RSS 1.0)
+element = state.current.getChild( creator, NS.DC );
+
+if ( element != null )
+name = element.getText();
+
+//author (RSS 2.0)
+element = state.current.getChild( author );
+
+if ( element != null )
+name = element.getText();
+
+if ( name != null ! .equals( name ) ) {
+
+listener.onAuthor( state,
+ name,
+ email,
+ resource );
+
+listener.onAuthorEnd();
+
+}
+
+} catch ( Exception e ) {
+throw new FeedParserException( e );
+}
+
}
private static void parseGUID( FeedParserState state,
@@ -67,13 +120,13 @@
String guid = null;
boolean isPermalink = false;
-id = state.current.getChild( id, NS.ATOM );
+id = state.current.getChild( id, NS.ATOM );
if ( id != null ) {
guid = id.getText();
}
-id = state.current.getChild( guid );
+id = state.current.getChild( guid );
if ( id != null ) {
Modified:
jakarta/commons/sandbox/feedparser/trunk/src/java/org/apache/commons/feedparser/impl/DebugFeedParserListener.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/feedparser/trunk/src/java/org/apache/commons/feedparser/impl/DebugFeedParserListener.java?view=diffr1=151106r2=151107
svn commit: r151108 - jakarta/commons/sandbox/feedparser/trunk/src/java/org/apache/commons/feedparser/DefaultFeedParserListener.java
Author: burton Date: Wed Feb 2 18:51:34 2005 New Revision: 151108 URL: http://svn.apache.org/viewcvs?view=revrev=151108 Log: more javadoc... Modified: jakarta/commons/sandbox/feedparser/trunk/src/java/org/apache/commons/feedparser/DefaultFeedParserListener.java Modified: jakarta/commons/sandbox/feedparser/trunk/src/java/org/apache/commons/feedparser/DefaultFeedParserListener.java URL: http://svn.apache.org/viewcvs/jakarta/commons/sandbox/feedparser/trunk/src/java/org/apache/commons/feedparser/DefaultFeedParserListener.java?view=diffr1=151107r2=151108 == --- jakarta/commons/sandbox/feedparser/trunk/src/java/org/apache/commons/feedparser/DefaultFeedParserListener.java (original) +++ jakarta/commons/sandbox/feedparser/trunk/src/java/org/apache/commons/feedparser/DefaultFeedParserListener.java Wed Feb 2 18:51:34 2005 @@ -24,6 +24,10 @@ * be used as a base class for new implementations which do not need most of the * functionality of a FeedParserListener. * + * Its recommended (but not required) that implementors extend this interface to + * that when new methods are added to the FeedParserListener that upgrades to + * this library do not break your application. + * * @see FeedParserListener * @author a href=mailto:[EMAIL PROTECTED]Kevin A. Burton (burtonator)/a * @version $Id$ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: FeedParser move to Commons Proper...
I'm +1 on the promotion. On Wed, 02 Feb 2005 17:54:11 -0800, Kevin A. Burton [EMAIL PROTECTED] wrote: Subject: Hey gang. I'd like to propose that we move FeedParser into commons proper. The main personal requirement for this is that I want to do a 0.5 release for my CodeCon talk on the FeedParser on Feb 11. http://jakarta.apache.org/commons/sandbox/feedparser/ We've been in the sandbox for 11 months now. The FeedParser itself is more than 2 years old. Its currently used in production at rojo.com to handle more than 1.9 million feeds. We currently have three developers working on the FeedParser: Kevin Burton (me) Brad Neuberg (Rojo Networks Inc.) Joseph Ottinger (Fusion Alliance) We're also working with the Rome developers (another RSS parser) to try to standardize APIs and are collaborating on a common feed parsing components including networking IO, autodiscovery, unit test, and potential collaboration. In order for this to happen though I need to get a stable release of FeedParser out the door and the sandbox doesn't allow any releases. I also want to be able to give out SVN commit to additional developers as they come on board. Also... I assume we can get a dedicated mailing list for the FeedParser? HttpClient is currently doing this. The roadmap for FeedParser is to get a 0.5 release out before Feb 11 and then about a month later to release 1.0. Then I want to start working on better and DEEPER unit tests and then rewrite the backend to use SAX. At this point I can make a better case that the Rome developers should build their object model on top of FeedParser Thanks guys!!! -- Use Rojo (RSS/Atom aggregator). Visit http://rojo.com. Ask me for an invite! Also see irc.freenode.net #rojo if you want to chat. Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html If you're interested in RSS, Weblogs, Social Networking, etc... then you should work for Rojo! If you recommend someone and we hire them you'll get a free iPod! Kevin A. Burton, Location - San Francisco, CA AIM/YIM - sfburtonator, Web - http://peerfear.org/ GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412 - 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]
Re: [digester] initial code for Digester2.0
On Wed, 2005-02-02 at 05:48 -0800, Reid Pinchback wrote: One section of the release notes says: The Digester now *always* uses a namespace-aware xml parser. I was wondering why this is. There are a lot of XML parsers out there, and some of them have done things like trade namespace awareness for performance. If somebody has a application where namespaces aren't an issue, why should they be limited to only using a namespace-aware parser? Not something that seems like an important issue if you are just using a Digester to process some kind of app config file, but is an issue if processing streams of XML data is fundamentally what the app is about. Supporting namespaces in an xml parser seems very simple to me. I think it much more likely that only antique and unmaintained parsers fail to support namespaces. And people who are determined to use antique and unmaintained parsers can just stick with digester 1.x as far as I am concerned. I'm not pushing for digester to remove non-namespace-aware support - just digester2! Removing code that handles non-namespace parsers from digester simplifies the code and reduces the library size. It also pushes users to write their code correctly; code that processes XML and doesn't handle namespaces is fundamentally broken and we shouldn't be providing tools that encourage people to write broken code. However if you can give an example of a modern and maintained xml parser that deliberately doesn't support namespaces in order to improve performance or reduce footprint, I will gladly reconsider. Or of course the consensus here favours supporting broken parsers :-) Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] new method on ClassUtils
Potential problem with the forName is bad issue, we already have a method using forName: convertClassNamesToClasses which turns a List of String into a List of Class using forName. So, a) this seems to be a problem? b) I'd like to point it at the new forName method (or however that gets solved). Hen On Tue, 1 Feb 2005 20:11:09 -0500, Henri Yandell [EMAIL PROTECTED] wrote: 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
--- Simon Kitching [EMAIL PROTECTED] wrote: Supporting namespaces in an xml parser seems very simple to me. I think it much more likely that only antique and unmaintained parsers fail to support namespaces. And people who are determined to use antique and unmaintained parsers can just stick with digester 1.x as far as I am concerned. I'm not pushing for digester to remove non-namespace-aware support - just digester2! Wow, that is an unexpectedly harsh reaction. My reason for asking was simple, and I believe not unreasonable. You were the one asking for feedback on your proposal. Using the namespace-based API of an XML parser is known throughput substantially, covered in a host of Java xml mag articles, available from google searches, and one or two of the Java performance tuning books still in distribution. XML performance tuning is a tough area, and people continually struggle with it. I don't recall the SAX-only stats, but I know that for DOM parsers you can shoot for an increase XML processing bandwidth by an order of magnitude through a change in parser and not using NS. Antiqueness of parsers isn't the issue. I think it helps to keep in mind that NS was intended as a way of creating name-resolution scopes that allow the merging of document structures from different origins that otherwise could experience element and attribute name clashes. When somebody has an application that doesn't require that kind of merging, and they aren't using a namespace-dependent XML technology like Soap or XMLSchma, then using using NS features of an NS parser can be a burden without corresponding benefit. Under the hood, that parser has to do a lot of work to continually manage the NS resolution of the node names. It has no way of knowing that the work is pointless - you've told it to assume that there is a point when you use the NS features. __ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
On Wed, 2005-02-02 at 20:45 -0800, Reid Pinchback wrote: --- Simon Kitching [EMAIL PROTECTED] wrote: Supporting namespaces in an xml parser seems very simple to me. I think it much more likely that only antique and unmaintained parsers fail to support namespaces. And people who are determined to use antique and unmaintained parsers can just stick with digester 1.x as far as I am concerned. I'm not pushing for digester to remove non-namespace-aware support - just digester2! Wow, that is an unexpectedly harsh reaction. My reason for asking was simple, and I believe not unreasonable. You were the one asking for feedback on your proposal. Sorry, Reid. I didn't mean it that way. I apologise for any offense. I was just stating my personal opinion - that every app eventually drops support for obsolete technologies, and I think it's time to drop support for non-namespace-aware parsers. I was serious, too, about users of old technology sticking with digester 1.x. I'm aware that upgrading core libs can sometimes be a pain, but digester1.x is still there and isn't going away (I'm one of the maintainers for that code, and have every intention of continuing that even when 2.0 is out). I just don't see the point of migrating the backwards compatibility code from the 1.x series. Of course if someone can demonstrate that non-namespace-aware parsers *are* still useful then I'll change my mind. Using the namespace-based API of an XML parser is known throughput substantially, covered in a host of Java xml mag articles, available from google searches, and one or two of the Java performance tuning books still in distribution. XML performance tuning is a tough area, and people continually struggle with it. I don't recall the SAX-only stats, but I know that for DOM parsers you can shoot for an increase XML processing bandwidth by an order of magnitude through a change in parser and not using NS. Antiqueness of parsers isn't the issue. Is there any chance you could provide a reference to such an article? I still find it hard to believe that leaving out namespace support makes a performance difference. The parser needs to keep a map of prefix-(stack of namespace) and that's about it. Surely that's a fraction of a percent of the parser performance, memory usage, and processing time. So why wouldn't a parser do it? Leaving out *validation* would improve performance and footprint significantly, but validation and namespace support are unrelated. I had a quick look for high-performance/small-footprint xml parsers: parser NS-support maintained? Piccolo y y Aelfred y y ElectrixXML y n? (can't find a current website) MinML n n (last release nov 2001) NanoXML y n (last release april 2002) JapiSoft y y (commercial) I also googled for xml parser performance namespace but didn't get anything relevant. I think it helps to keep in mind that NS was intended as a way of creating name-resolution scopes that allow the merging of document structures from different origins that otherwise could experience element and attribute name clashes. When somebody has an application that doesn't require that kind of merging, and they aren't using a namespace-dependent XML technology like Soap or XMLSchma, then using using NS features of an NS parser can be a burden without corresponding benefit. Under the hood, that parser has to do a lot of work to continually manage the NS resolution of the node names. It has no way of knowing that the work is pointless - you've told it to assume that there is a point when you use the NS features. True. Namespaces are not relevant in many contexts. But as noted above, I do find it hard to believe that parser has to do a lot of work to manage NS resolution. If you can show me I'm wrong, I'll buy you a beer ;-) Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
