[jira] Commented: (VFS-105) Make it possible to generate VFS sandbox jar with Ant
[ https://issues.apache.org/jira/browse/VFS-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463835 ] Mario Ivankovits commented on VFS-105: -- I'll see what I can do, shouldn't be that hard. Ciao, Mario Make it possible to generate VFS sandbox jar with Ant - Key: VFS-105 URL: https://issues.apache.org/jira/browse/VFS-105 Project: Commons VFS Issue Type: Improvement Reporter: Maarten Coene Assigned To: Mario Ivankovits I use the VFS-sandbox.jar in my project. Unfortunately, gump cannot build my project at the moment because the VFS-sandbox.jar isn't available in gump since gump doesn't support M2. If this sandbox jar could be built via Ant, it could be made available in gump. Maarten -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction] svn commit: r494203 - in /jakarta/commons/proper/transaction/trunk: RELEASE-NOTES.txt src/java/org/apache/commons/transaction/file/ResourceManager.java
On Wed, 2007-01-10 at 14:12 -0500, Rahul Akolkar wrote: On 1/10/07, Joerg Heinicke [EMAIL PROTECTED] wrote: Rahul Akolkar rahul.akolkar at gmail.com writes: Generally speaking, an interface-compatible change will at most change the private interface of a component, or simply add classes, methods and attributes whose use is optional to both internal and external interface clients. And this is not. In which way is it different from simply add [..] methods [..] whose use is optional to both internal and external interface clients. ?? Even simply replacing the former jar with the next version should work as the client does not know about the new methods. Only recompilation of implementations need adaptions before but that's not what I consider a use or a client. snip/ I suspect that bit is talking about Java classes (rather than interfaces), though I haven't tried to hunt it down in the guide. I flagged what I thought would lead to a versioning discussion at 1.2 voting time. There is a section in the java specification that defines precisely what binary compatibility involves, and adding a method to an interface definitely breaks it. This is an *object oriented* library we are talking about here, so use includes implementing any public interfaces, subclassing any non-final classes and overriding any public or protected methods. Unless explicitly documented, we cannot assume that users of an open-source library restrict themselves to just calling the existing classes. If the interfaces had been explicitly documented as being not intended for user implementation then this might be ok. Or if they had been placed in a special package, as Eclipse does, to explicitly separate internal from external apis. However if neither of these have been done, then I would personally expect these APIs to be binary-compatible, *at least* without a major version number update. In the branch for digester 2.x, I explicitly indicated the binary stability expectations for the Action interface: http://svn.apache.org/repos/asf/jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/Action.java Note that this is still experimental work, and I haven't received feedback from the commons community on whether this sort of comment would be considered adequate to allow an interface change in a minor release, but IMO without an indication of this sort an API really shouldn't change (without a major release at least). Ideally, existing public interfaces should not be changed *at all*, eg by introducing a new interface rather than changing the existing one. In cases where an application uses two different libraries that both depend on a commons lib, the existence of different versions of the commons lib with the same package names but different APIs can cause major headaches. As Rahul says this situation may well draw -1 votes at release time. We all want commons projects to have a good reputation for API stability. There have been mistakes made in the past, causing a lot of negative user feedback. Yes, it can be a hassle for development. However the reason that commons is a good place to host libraries is because commons is trusted, and that's because the software development processes here are reasonably strict. Writing libraries is hard - and quite different from writing full applications (eg tomcat, ant) or frameworks. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BETWIXT-57) Class loader problem in JBoss version 4.0.4GA
[
https://issues.apache.org/jira/browse/BETWIXT-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463858
]
Simon Kitching commented on BETWIXT-57:
---
Robert, I see that the new useContextClassLoader attribute defaults to false.
In Digester it defaults to false, but that is mainly because this feature was
added after Digester was already widely used and at a 1.x release. Changing the
existing behaviour would therefore not be acceptable.
Perhaps for Betwixt it should default to true instead? Or is it too late
already to change existing behaviour?
Either way, it would be nice if the javadoc indicated what the default
behaviour is...
Class loader problem in JBoss version 4.0.4GA
-
Key: BETWIXT-57
URL: https://issues.apache.org/jira/browse/BETWIXT-57
Project: Commons Betwixt
Issue Type: Bug
Environment: JBoss application server version 4.0.4GA. Probably
affects most versions of JBoss
Reporter: Surjit Sen
Priority: Critical
When using betwixt in a JBoss application, Class not found exceptions get
thrown when Class.forName methods are called in classes
org.apache.commons.betwixt.digester.ElementRule and
org.apache.commons.betwixt.digester.ClassRule. Specifically the Class.forName
method uses the system class loader to load classes and in JBoss the
classpath normally does not contain the application jar files. The fix is
very simple. The Class.forName method calls in both the classes were replaced
with the following code lines in ElementRule and similar changes were made in
ClassRule as well. This fix ensures that the appropriate class loader is used
for loading classes and is similar to the fix made in log4j.
ClassLoader loader =
Thread.currentThread().getContextClassLoader();
if (loader == null) {
loader =
Class.forName(implementationClass).getClassLoader();
//Class clazz = Class.forName(implementationClass);
}
Class clazz = loader.loadClass(implementationClass);
descriptor.setImplementationClass(clazz);
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly-tags-soap (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-soap has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 42 runs. The current state of this project is 'Failed', with reason 'Configuration Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-soap : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-soap/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-soap-11012007.jar] identifier set to project name -ERROR- No such project [ws-jaxme] for property. -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-api on: Maven on Project:commons-jelly-tags-soap -DEBUG- Dependency on ws-axis exists, no need to add for property maven.jar.axis. -DEBUG- Dependency on ws-axis exists, no need to add for property maven.jar.jaxrpc-api. -DEBUG- Dependency on ws-axis exists, no need to add for property maven.jar.saaj-api. -DEBUG- Dependency on jakarta-servletapi-5-servlet exists, no need to add for property maven.jar.servletapi. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: ws-jaxme unknown to *this* workspace -INFO- Failed to extract fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-soap/rss.xml - Atom: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-soap/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 1911012007, vmgump.apache.org:vmgump-public:1911012007 Gump E-mail Identifier (unique within run) #28. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly-tags-soap (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-soap has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 42 runs. The current state of this project is 'Failed', with reason 'Configuration Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-soap : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-soap/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-soap-11012007.jar] identifier set to project name -ERROR- No such project [ws-jaxme] for property. -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-api on: Maven on Project:commons-jelly-tags-soap -DEBUG- Dependency on ws-axis exists, no need to add for property maven.jar.axis. -DEBUG- Dependency on ws-axis exists, no need to add for property maven.jar.jaxrpc-api. -DEBUG- Dependency on ws-axis exists, no need to add for property maven.jar.saaj-api. -DEBUG- Dependency on jakarta-servletapi-5-servlet exists, no need to add for property maven.jar.servletapi. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: ws-jaxme unknown to *this* workspace -INFO- Failed to extract fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-soap/rss.xml - Atom: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-soap/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 1911012007, vmgump.apache.org:vmgump-public:1911012007 Gump E-mail Identifier (unique within run) #28. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly-tags-jaxme (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-jaxme has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 42 runs. The current state of this project is 'Failed', with reason 'Configuration Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-jaxme : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-jaxme-11012007.jar] identifier set to project name -ERROR- No such project [ws-jaxme] for property. -ERROR- No such project [ws-jaxme] for property. -ERROR- No such project [ws-jaxme] for property. -ERROR- No such project [ws-jaxme] for property. -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-js on: Maven on Project:commons-jelly-tags-jaxme -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme on: Maven on Project:commons-jelly-tags-jaxme -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-api on: Maven on Project:commons-jelly-tags-jaxme -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-xs on: Maven on Project:commons-jelly-tags-jaxme -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: ws-jaxme unknown to *this* workspace -INFO- Failed to extract fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/rss.xml - Atom: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 1911012007, vmgump.apache.org:vmgump-public:1911012007 Gump E-mail Identifier (unique within run) #37. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly-tags-jaxme (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-jaxme has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 42 runs. The current state of this project is 'Failed', with reason 'Configuration Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-jaxme : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-jaxme-11012007.jar] identifier set to project name -ERROR- No such project [ws-jaxme] for property. -ERROR- No such project [ws-jaxme] for property. -ERROR- No such project [ws-jaxme] for property. -ERROR- No such project [ws-jaxme] for property. -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-js on: Maven on Project:commons-jelly-tags-jaxme -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme on: Maven on Project:commons-jelly-tags-jaxme -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-api on: Maven on Project:commons-jelly-tags-jaxme -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-xs on: Maven on Project:commons-jelly-tags-jaxme -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: ws-jaxme unknown to *this* workspace -INFO- Failed to extract fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/rss.xml - Atom: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 1911012007, vmgump.apache.org:vmgump-public:1911012007 Gump E-mail Identifier (unique within run) #37. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (CONFIGURATION-248) Safeguard config source abstraction by using HierarchicalConfiguration as supertype for all configs
Safeguard config source abstraction by using HierarchicalConfiguration as supertype for all configs --- Key: CONFIGURATION-248 URL: https://issues.apache.org/jira/browse/CONFIGURATION-248 Project: Commons Configuration Issue Type: Wish Affects Versions: 1.3 Final Environment: - Reporter: Dennis Kuehn I hope I get this right: When I have a CompositeConfiguration, the nice thing about it is that I don't have to care in which file or file type a config entry has been defined. Now when part of my CompositeConfiguration has a hierarchical structure and I need the API provided by HierarchicalConfiguration, I lose the aforementioned abstraction: I need to cast a specific part of my CompositeConfiguration to HierarchicalConfiguration. This is a major design problem! It would be better to leverage the Composite Pattern here: derive all configuration objects from HierarchicalConfiguration. Put differently, move the HierarchicalConfiguration API to Configuration. Even if a config is not hierarchically structured, methods for hierarchical access will be present, but that's a minor drawback which is intrinsic to the Composite Pattern, like when you are modelling a tree structure and you have a common superclass Node which has a method getSubNodes() which will also be present for leaf nodes (in this case, getSubNodes() would return null etc.). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-jsl-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 16 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-jsl-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on ant exists, no need to add for property maven.jar.ant-optional. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -WARNING- Overriding Maven properties: [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/gump_work/build_commons-jelly_commons-jelly-tags-jsl-test.html Work Name: build_commons-jelly_commons-jelly-tags-jsl-test (Type: Build) Work ended in a state of : Failed Elapsed: 18 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/commons-cli-1.0.x/target/commons-cli-11012007.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-11012007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-11012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-11012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-11012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-11012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-11012007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-11012007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-11012007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-11012007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-11012007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar - [junit] at org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:64) [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:59) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:263) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:66) [junit] at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:113) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:161) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:80) [junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171) [junit]
[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-jsl-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 16 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-jsl-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on ant exists, no need to add for property maven.jar.ant-optional. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -WARNING- Overriding Maven properties: [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/gump_work/build_commons-jelly_commons-jelly-tags-jsl-test.html Work Name: build_commons-jelly_commons-jelly-tags-jsl-test (Type: Build) Work ended in a state of : Failed Elapsed: 18 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/commons-cli-1.0.x/target/commons-cli-11012007.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-11012007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-11012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-11012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-11012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-11012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-11012007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-11012007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-11012007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-11012007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-11012007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar - [junit] at org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:64) [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:59) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:263) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:66) [junit] at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:113) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:161) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:80) [junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171) [junit]
[EMAIL PROTECTED]: Project commons-jelly-tags-fmt-test (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-fmt-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 16 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-fmt-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -WARNING- Overriding Maven properties: [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/gump_work/build_commons-jelly_commons-jelly-tags-fmt-test.html Work Name: build_commons-jelly_commons-jelly-tags-fmt-test (Type: Build) Work ended in a state of : Failed Elapsed: 16 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-commands-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-classpath-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-core-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-bsf-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-reflect-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-util-2.0b4.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-11012007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-11012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-11012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/beanshell/target/commons-jelly-tags-beanshell-11012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-11012007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-11012007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-11012007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-11012007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-11012007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/commons-jelly-tags-fmt-11012007.jar - [junit] at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) [junit] at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) [junit] at java.net.URLClassLoader.access$100(URLClassLoader.java:56) [junit] at java.net.URLClassLoader$1.run(URLClassLoader.java:195) [junit] at java.security.AccessController.doPrivileged(Native Method) [junit] at java.net.URLClassLoader.findClass(URLClassLoader.java:188) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:306) [junit] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:251) [junit] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) [junit] at org.apache.commons.jelly.tags.ant.AntTagLibrary.createProject(AntTagLibrary.java:128)
[EMAIL PROTECTED]: Project commons-jelly-tags-fmt-test (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-fmt-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 16 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-fmt-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -WARNING- Overriding Maven properties: [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/gump_work/build_commons-jelly_commons-jelly-tags-fmt-test.html Work Name: build_commons-jelly_commons-jelly-tags-fmt-test (Type: Build) Work ended in a state of : Failed Elapsed: 16 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-commands-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-classpath-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-core-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-bsf-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-reflect-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-util-2.0b4.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-11012007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-11012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-11012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/beanshell/target/commons-jelly-tags-beanshell-11012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-11012007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-11012007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-11012007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-11012007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-11012007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/commons-jelly-tags-fmt-11012007.jar - [junit] at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) [junit] at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) [junit] at java.net.URLClassLoader.access$100(URLClassLoader.java:56) [junit] at java.net.URLClassLoader$1.run(URLClassLoader.java:195) [junit] at java.security.AccessController.doPrivileged(Native Method) [junit] at java.net.URLClassLoader.findClass(URLClassLoader.java:188) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:306) [junit] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:251) [junit] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) [junit] at org.apache.commons.jelly.tags.ant.AntTagLibrary.createProject(AntTagLibrary.java:128)
[jira] Updated: (CONFIGURATION-248) Safeguard config source abstraction by using HierarchicalConfiguration as supertype for all configs
[ https://issues.apache.org/jira/browse/CONFIGURATION-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Kuehn updated CONFIGURATION-248: --- Description: I hope I get this right: When I have a CompositeConfiguration, the nice thing about it is that I don't have to care in which file or file type a config entry has been defined. Now when part of my CompositeConfiguration has a hierarchical structure and I need the API provided by HierarchicalConfiguration, I lose the aforementioned abstraction: I need to cast a specific part of my CompositeConfiguration to HierarchicalConfiguration. This is a major design problem! It would be better to leverage the Composite Pattern here: derive all configuration classes from HierarchicalConfiguration. Put differently, move the HierarchicalConfiguration API to Configuration. Even if a config is not hierarchically structured, methods for hierarchical access will be present, but that's a minor drawback which is intrinsic to the Composite Pattern. This also happens when you are modelling a tree structure and you have a common supertype Node which has a method getSubNodes() which will also be present in leaf node instances (in this case, getSubNodes() would return null etc.). was: I hope I get this right: When I have a CompositeConfiguration, the nice thing about it is that I don't have to care in which file or file type a config entry has been defined. Now when part of my CompositeConfiguration has a hierarchical structure and I need the API provided by HierarchicalConfiguration, I lose the aforementioned abstraction: I need to cast a specific part of my CompositeConfiguration to HierarchicalConfiguration. This is a major design problem! It would be better to leverage the Composite Pattern here: derive all configuration objects from HierarchicalConfiguration. Put differently, move the HierarchicalConfiguration API to Configuration. Even if a config is not hierarchically structured, methods for hierarchical access will be present, but that's a minor drawback which is intrinsic to the Composite Pattern, like when you are modelling a tree structure and you have a common superclass Node which has a method getSubNodes() which will also be present for leaf nodes (in this case, getSubNodes() would return null etc.). Safeguard config source abstraction by using HierarchicalConfiguration as supertype for all configs --- Key: CONFIGURATION-248 URL: https://issues.apache.org/jira/browse/CONFIGURATION-248 Project: Commons Configuration Issue Type: Wish Affects Versions: 1.3 Final Environment: - Reporter: Dennis Kuehn I hope I get this right: When I have a CompositeConfiguration, the nice thing about it is that I don't have to care in which file or file type a config entry has been defined. Now when part of my CompositeConfiguration has a hierarchical structure and I need the API provided by HierarchicalConfiguration, I lose the aforementioned abstraction: I need to cast a specific part of my CompositeConfiguration to HierarchicalConfiguration. This is a major design problem! It would be better to leverage the Composite Pattern here: derive all configuration classes from HierarchicalConfiguration. Put differently, move the HierarchicalConfiguration API to Configuration. Even if a config is not hierarchically structured, methods for hierarchical access will be present, but that's a minor drawback which is intrinsic to the Composite Pattern. This also happens when you are modelling a tree structure and you have a common supertype Node which has a method getSubNodes() which will also be present in leaf node instances (in this case, getSubNodes() would return null etc.). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-248) Safeguard config source abstraction by using HierarchicalConfiguration as supertype for all configs
[ https://issues.apache.org/jira/browse/CONFIGURATION-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger updated CONFIGURATION-248: --- Fix Version/s: 2.0 Affects Version/s: (was: 2.0) 1.3 Final Safeguard config source abstraction by using HierarchicalConfiguration as supertype for all configs --- Key: CONFIGURATION-248 URL: https://issues.apache.org/jira/browse/CONFIGURATION-248 Project: Commons Configuration Issue Type: Wish Affects Versions: 1.3 Final Environment: - Reporter: Dennis Kuehn Fix For: 2.0 I hope I get this right: When I have a CompositeConfiguration, the nice thing about it is that I don't have to care in which file or file type a config entry has been defined. Now when part of my CompositeConfiguration has a hierarchical structure and I need the API provided by HierarchicalConfiguration, I lose the aforementioned abstraction: I need to cast a specific part of my CompositeConfiguration to HierarchicalConfiguration. This is a major design problem! It would be better to leverage the Composite Pattern here: derive all configuration classes from HierarchicalConfiguration. Put differently, move the HierarchicalConfiguration API to Configuration. Even if a config is not hierarchically structured, methods for hierarchical access will be present, but that's a minor drawback which is intrinsic to the Composite Pattern. This also happens when you are modelling a tree structure and you have a common supertype Node which has a method getSubNodes() which will also be present in leaf node instances (in this case, getSubNodes() would return null etc.). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-248) Safeguard config source abstraction by using HierarchicalConfiguration as supertype for all configs
[ https://issues.apache.org/jira/browse/CONFIGURATION-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger updated CONFIGURATION-248: --- Affects Version/s: (was: 1.3 Final) 2.0 I agree that a future version of the Configuration interface should support the special operations for hierarchical configurations. Non hierarchical configurations can be seen as a flat special case for hierarchical configurations. However because this is a major change that would break binary compatibility, such a change can only be done in a major release, i.e. for Commons Configuration 2.0. In the meantime: Did you see the CombinedConfiguration class? This is a hierarchical version of CompositeConfiguration. Safeguard config source abstraction by using HierarchicalConfiguration as supertype for all configs --- Key: CONFIGURATION-248 URL: https://issues.apache.org/jira/browse/CONFIGURATION-248 Project: Commons Configuration Issue Type: Wish Affects Versions: 1.3 Final Environment: - Reporter: Dennis Kuehn Fix For: 2.0 I hope I get this right: When I have a CompositeConfiguration, the nice thing about it is that I don't have to care in which file or file type a config entry has been defined. Now when part of my CompositeConfiguration has a hierarchical structure and I need the API provided by HierarchicalConfiguration, I lose the aforementioned abstraction: I need to cast a specific part of my CompositeConfiguration to HierarchicalConfiguration. This is a major design problem! It would be better to leverage the Composite Pattern here: derive all configuration classes from HierarchicalConfiguration. Put differently, move the HierarchicalConfiguration API to Configuration. Even if a config is not hierarchically structured, methods for hierarchical access will be present, but that's a minor drawback which is intrinsic to the Composite Pattern. This also happens when you are modelling a tree structure and you have a common supertype Node which has a method getSubNodes() which will also be present in leaf node instances (in this case, getSubNodes() would return null etc.). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (IO-109) FileSystemUtils freeSpaceUnix does not work for HP-UX 11
FileSystemUtils freeSpaceUnix does not work for HP-UX 11
Key: IO-109
URL: https://issues.apache.org/jira/browse/IO-109
Project: Commons IO
Issue Type: Bug
Components: Utilities
Affects Versions: 1.2
Environment: uname -a
HP-UX mbfwdv B.11.11 U 9000/800 3509210950 unlimited-user license
Reporter: Christopher Olsen
The freeSpaceUnix method does not work under HP-UX. The df command under HP-UX
is the old System V varient and the fields are not in the correct order. This
diff modifies the code to use the 'bdf' command when HP-UX is detected:
--- FileSystemUtils.java2006-03-19 12:42:48.0 -0800
+++ FileSystemUtils-HP-UX-Fix.java 2007-01-11 13:05:34.844269000 -0800
@@ -51,13 +51,15 @@
private static final int WINDOWS = 1;
/** Operating system state flag for Unix. */
private static final int UNIX = 2;
+/** Unix variant name */
+ private static String osName = null;
/** The operating system flag. */
private static final int OS;
static {
int os = OTHER;
try {
-String osName = System.getProperty(os.name);
+osName = System.getProperty(os.name);
if (osName == null) {
throw new IOException(os.name not found);
}
@@ -287,9 +289,18 @@
}
path = FilenameUtils.normalize(path);
+ // HP-UX sucks we need to use bdf instead
+ String dfCmd = df;
+ String dfOpts = -k;
+ if (osName.indexOf(hp-ux) != -1)
+ {
+ dfCmd = bdf;
+ dfOpts = ;
+ }
+
// build and run the 'dir' command
String[] cmdAttribs =
-(kb ? new String[] {df, -k, path} : new String[] {df, path});
+(kb ? new String[] {dfCmd, dfOpts, path} : new String[] {dfCmd,
path});
// read the output from the command until we come to the second line
long bytes = -1;
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (IO-109) FileSystemUtils freeSpaceUnix does not work for HP-UX 11
[
https://issues.apache.org/jira/browse/IO-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Olsen updated IO-109:
-
Attachment: FileSystemUtils-HP-UX.fix
FileSystemUtils freeSpaceUnix does not work for HP-UX 11
Key: IO-109
URL: https://issues.apache.org/jira/browse/IO-109
Project: Commons IO
Issue Type: Bug
Components: Utilities
Affects Versions: 1.2
Environment: uname -a
HP-UX mbfwdv B.11.11 U 9000/800 3509210950 unlimited-user license
Reporter: Christopher Olsen
Attachments: FileSystemUtils-HP-UX.fix
The freeSpaceUnix method does not work under HP-UX. The df command under
HP-UX is the old System V varient and the fields are not in the correct
order. This diff modifies the code to use the 'bdf' command when HP-UX is
detected:
--- FileSystemUtils.java2006-03-19 12:42:48.0 -0800
+++ FileSystemUtils-HP-UX-Fix.java 2007-01-11 13:05:34.844269000 -0800
@@ -51,13 +51,15 @@
private static final int WINDOWS = 1;
/** Operating system state flag for Unix. */
private static final int UNIX = 2;
+/** Unix variant name */
+ private static String osName = null;
/** The operating system flag. */
private static final int OS;
static {
int os = OTHER;
try {
-String osName = System.getProperty(os.name);
+osName = System.getProperty(os.name);
if (osName == null) {
throw new IOException(os.name not found);
}
@@ -287,9 +289,18 @@
}
path = FilenameUtils.normalize(path);
+ // HP-UX sucks we need to use bdf instead
+ String dfCmd = df;
+ String dfOpts = -k;
+ if (osName.indexOf(hp-ux) != -1)
+ {
+ dfCmd = bdf;
+ dfOpts = ;
+ }
+
// build and run the 'dir' command
String[] cmdAttribs =
-(kb ? new String[] {df, -k, path} : new String[] {df,
path});
+(kb ? new String[] {dfCmd, dfOpts, path} : new String[] {dfCmd,
path});
// read the output from the command until we come to the second line
long bytes = -1;
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BETWIXT-57) Class loader problem in JBoss version 4.0.4GA
[
https://issues.apache.org/jira/browse/BETWIXT-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464026
]
Robert Burrell Donkin commented on BETWIXT-57:
--
I was a little concerned about the effects on existing installations of using
the context classloader but Betwixt is only a 0.x so feel free to break the
semantics if it's right thing to do and you documentation it at the bottom of
tasks.xml.
Please feel free to go ahead and add more javadocs (and documentation, if you
can find some time)
Class loader problem in JBoss version 4.0.4GA
-
Key: BETWIXT-57
URL: https://issues.apache.org/jira/browse/BETWIXT-57
Project: Commons Betwixt
Issue Type: Bug
Environment: JBoss application server version 4.0.4GA. Probably
affects most versions of JBoss
Reporter: Surjit Sen
Priority: Critical
When using betwixt in a JBoss application, Class not found exceptions get
thrown when Class.forName methods are called in classes
org.apache.commons.betwixt.digester.ElementRule and
org.apache.commons.betwixt.digester.ClassRule. Specifically the Class.forName
method uses the system class loader to load classes and in JBoss the
classpath normally does not contain the application jar files. The fix is
very simple. The Class.forName method calls in both the classes were replaced
with the following code lines in ElementRule and similar changes were made in
ClassRule as well. This fix ensures that the appropriate class loader is used
for loading classes and is similar to the fix made in log4j.
ClassLoader loader =
Thread.currentThread().getContextClassLoader();
if (loader == null) {
loader =
Class.forName(implementationClass).getClassLoader();
//Class clazz = Class.forName(implementationClass);
}
Class clazz = loader.loadClass(implementationClass);
descriptor.setImplementationClass(clazz);
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r495428 - in /jakarta/commons/proper/transaction/trunk: RELEASE-NOTES.txt src/java/org/apache/commons/transaction/file/ResourceManager.java
Author: joerg Date: Thu Jan 11 15:21:34 2007 New Revision: 495428 URL: http://svn.apache.org/viewvc?view=revrev=495428 Log: revert commit 494203 / TRANSACTION-11 (http://marc.theaimsgroup.com/?t=11682925535r=1w=4) Modified: jakarta/commons/proper/transaction/trunk/RELEASE-NOTES.txt jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/ResourceManager.java Modified: jakarta/commons/proper/transaction/trunk/RELEASE-NOTES.txt URL: http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/RELEASE-NOTES.txt?view=diffrev=495428r1=495427r2=495428 == --- jakarta/commons/proper/transaction/trunk/RELEASE-NOTES.txt (original) +++ jakarta/commons/proper/transaction/trunk/RELEASE-NOTES.txt Thu Jan 11 15:21:34 2007 @@ -29,7 +29,6 @@ - Added functions to FileResourceManager for copying and moving resources. - Added possibility to append to (instead of overwriting) an existing resource with writeResource in FileResourceManager. - Added LoggerFacade implementation for Jakarta Commons Logging -- Added setDefaultTransactionTimeout() and reset() to ResourceManager (Jira issue TRANSACTION-11). BUGFIXES FROM 1.1 - Modified: jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/ResourceManager.java URL: http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/ResourceManager.java?view=diffrev=495428r1=495427r2=495428 == --- jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/ResourceManager.java (original) +++ jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/ResourceManager.java Thu Jan 11 15:21:34 2007 @@ -133,13 +133,6 @@ public boolean recover() throws ResourceManagerSystemException; /** - * Resets the store if applicable (optional operation). - * - * @throws UnsupportedOperationException if the codereset/code operation is not supported by this ResourceManager. - */ -public void reset(); - -/** * Gets the default isolation level as an integer. * The higher the value the higher the isolation. * @@ -210,15 +203,6 @@ */ public long getDefaultTransactionTimeout() throws ResourceManagerException; -/** - * Sets the default transaction timeout in milliseconds. - * - * @param mSecs default transaction timeout in milliseconds - * @throws ResourceManagerException if an error occured - * @see #getDefaultTransactionTimeout - */ -public void setDefaultTransactionTimeout(long mSecs) throws ResourceManagerException; - /** * Gets the transaction timeout of the specified transaction in milliseconds. * - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (TRANSACTION-11) Improve relationship between ResourceManager and FileResourceManager
[ https://issues.apache.org/jira/browse/TRANSACTION-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörg Heinicke reopened TRANSACTION-11: -- Reverted commit: http://marc.theaimsgroup.com/?t=11682925535r=1w=4. Improve relationship between ResourceManager and FileResourceManager Key: TRANSACTION-11 URL: https://issues.apache.org/jira/browse/TRANSACTION-11 Project: Commons Transaction Issue Type: Improvement Affects Versions: 1.1 Reporter: Jeremy Fujimoto-Johnson Assigned To: Jörg Heinicke Fix For: 2.0 Attachments: commons-transaction-rm-patch.txt Add the reset method to ResourceManager so that classes using a ResourceManager won't have to cast it to FileResourceManager to call this method. Add new constructors to FileResourceManager so that it can be constructed with the default timeout period for transactions already specified so that you don't have to cast to FileResourceManager to set it later. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TRANSACTION-11) Improve relationship between ResourceManager and FileResourceManager
[ https://issues.apache.org/jira/browse/TRANSACTION-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörg Heinicke updated TRANSACTION-11: - Fix Version/s: (was: 1.2) 2.0 Improve relationship between ResourceManager and FileResourceManager Key: TRANSACTION-11 URL: https://issues.apache.org/jira/browse/TRANSACTION-11 Project: Commons Transaction Issue Type: Improvement Affects Versions: 1.1 Reporter: Jeremy Fujimoto-Johnson Assigned To: Jörg Heinicke Fix For: 2.0 Attachments: commons-transaction-rm-patch.txt Add the reset method to ResourceManager so that classes using a ResourceManager won't have to cast it to FileResourceManager to call this method. Add new constructors to FileResourceManager so that it can be constructed with the default timeout period for transactions already specified so that you don't have to cast to FileResourceManager to set it later. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TRANSACTION-13) JTA Compliant
[ https://issues.apache.org/jira/browse/TRANSACTION-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörg Heinicke updated TRANSACTION-13: - Fix Version/s: (was: 1.3) 2.0 JTA Compliant - Key: TRANSACTION-13 URL: https://issues.apache.org/jira/browse/TRANSACTION-13 Project: Commons Transaction Issue Type: New Feature Reporter: Cyrille Assigned To: Jörg Heinicke Fix For: 2.0 Is there a plan to make Commons-Transaction compliant with JTA (Java Transaction API) ? It would be great to get it. For exemple, in case of a web file upload, we could make one transaction for tose 2 operations : 1) writing metadata in database (title,description...), 2) writing the file on the filesystem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] Inner class exception
On 1/9/07, Stephen Colebourne [EMAIL PROTECTED] wrote: From: Henri Yandell [EMAIL PROTECTED] This helps with naming, but without the scoping, you're left with the Javadocs as the only way to specify that the exception is intended to be used only within the DirectoryWalker class. Of course, a public static inner class can be used elsewhere as well, but the relationship with the enclosing class makes a clear statement of intent. We can agree to disagree, though - I was mostly just interested in what the arguments are against using inner classes, given that I see very clear and meaningful reasons for using them. Ditto. Your arguments are good, so I'm quite happy to go with whatever consensus is on this one. I think the other argument is that the JDK doesn't have inner exception classes (well, maybe it does, but I can't think of any well-known ones ATM). Since [io] is a JDK+ library, I'd say we should have no inner exceptions. Sorry, but this doesn't seem like a very good argument to me - on this basis you could argue against the whole existance of IO - since it provides stuff thats not in the JDK :-) If you could point to a no inner exceptions in the jdk policy with reasons why then that would be a different thing. Two of the reasons for inner classes on the Sun Java tutorial[1] apply to this case IMO - it logically groups the exception with the class it applies to - i.e. DirectoryWalker - it makes for more readable/maintainable code From whats been said in this thread then at the end of the day is purely down to different stylistic preferences. On that basis I'd prefer it to remain how I originally coded it. Having said that - if its going to prevent/hold up an IO 1.3 release then, as I said before, I'm not going to object to it being changed. Niall [1] http://java.sun.com/docs/books/tutorial/java/javaOO/nested.html Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] Inner class exception
Sorry, but this doesn't seem like a very good argument to me - on this basis you could argue against the whole existance of IO - since it provides stuff thats not in the JDK I don't know if I agree with this point, Niall. The stuff that's in IO wasn't left out of the JDK because of coding style, which is the reason Stephen (I believe that's who said it) is saying we shouldn't use nested exception classes. I would agree that nested exception classes should be avoided. I wouldn't want to have to qualify my exceptions in my catch blocks: catch( DirectoryWalker.CancelException e ) That just looks ugly/weird to me and people just usually don't do that. I would agree, however, that it does group stuff logically. On 1/11/07, Niall Pemberton [EMAIL PROTECTED] wrote: On 1/9/07, Stephen Colebourne [EMAIL PROTECTED] wrote: From: Henri Yandell [EMAIL PROTECTED] This helps with naming, but without the scoping, you're left with the Javadocs as the only way to specify that the exception is intended to be used only within the DirectoryWalker class. Of course, a public static inner class can be used elsewhere as well, but the relationship with the enclosing class makes a clear statement of intent. We can agree to disagree, though - I was mostly just interested in what the arguments are against using inner classes, given that I see very clear and meaningful reasons for using them. Ditto. Your arguments are good, so I'm quite happy to go with whatever consensus is on this one. I think the other argument is that the JDK doesn't have inner exception classes (well, maybe it does, but I can't think of any well-known ones ATM). Since [io] is a JDK+ library, I'd say we should have no inner exceptions. Sorry, but this doesn't seem like a very good argument to me - on this basis you could argue against the whole existance of IO - since it provides stuff thats not in the JDK :-) If you could point to a no inner exceptions in the jdk policy with reasons why then that would be a different thing. Two of the reasons for inner classes on the Sun Java tutorial[1] apply to this case IMO - it logically groups the exception with the class it applies to - i.e. DirectoryWalker - it makes for more readable/maintainable code From whats been said in this thread then at the end of the day is purely down to different stylistic preferences. On that basis I'd prefer it to remain how I originally coded it. Having said that - if its going to prevent/hold up an IO 1.3 release then, as I said before, I'm not going to object to it being changed. Niall [1] http://java.sun.com/docs/books/tutorial/java/javaOO/nested.html Stephen - 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: [io] Inner class exception
On 1/11/07, James Carman [EMAIL PROTECTED] wrote: Sorry, but this doesn't seem like a very good argument to me - on this basis you could argue against the whole existance of IO - since it provides stuff thats not in the JDK I don't know if I agree with this point, Niall. The stuff that's in IO wasn't left out of the JDK because of coding style, which is the reason Stephen (I believe that's who said it) is saying we shouldn't use nested exception classes. I would agree that nested exception classes should be avoided. I wouldn't want to have to qualify my exceptions in my catch blocks: catch( DirectoryWalker.CancelException e ) That just looks ugly/weird to me and people just usually don't do that. That depends a _lot_ on the kind of coding you're doing / exposed to. For example, it's not particularly common for web apps to use a lot of anonymous inner classes, but if you were looking at Swing code, you'd likely see them all over the place. The above may look ugly / weird to you, but it looks elegant / self-documenting to me. -- Martin Cooper I would agree, however, that it does group stuff logically. On 1/11/07, Niall Pemberton [EMAIL PROTECTED] wrote: On 1/9/07, Stephen Colebourne [EMAIL PROTECTED] wrote: From: Henri Yandell [EMAIL PROTECTED] This helps with naming, but without the scoping, you're left with the Javadocs as the only way to specify that the exception is intended to be used only within the DirectoryWalker class. Of course, a public static inner class can be used elsewhere as well, but the relationship with the enclosing class makes a clear statement of intent. We can agree to disagree, though - I was mostly just interested in what the arguments are against using inner classes, given that I see very clear and meaningful reasons for using them. Ditto. Your arguments are good, so I'm quite happy to go with whatever consensus is on this one. I think the other argument is that the JDK doesn't have inner exception classes (well, maybe it does, but I can't think of any well-known ones ATM). Since [io] is a JDK+ library, I'd say we should have no inner exceptions. Sorry, but this doesn't seem like a very good argument to me - on this basis you could argue against the whole existance of IO - since it provides stuff thats not in the JDK :-) If you could point to a no inner exceptions in the jdk policy with reasons why then that would be a different thing. Two of the reasons for inner classes on the Sun Java tutorial[1] apply to this case IMO - it logically groups the exception with the class it applies to - i.e. DirectoryWalker - it makes for more readable/maintainable code From whats been said in this thread then at the end of the day is purely down to different stylistic preferences. On that basis I'd prefer it to remain how I originally coded it. Having said that - if its going to prevent/hold up an IO 1.3 release then, as I said before, I'm not going to object to it being changed. Niall [1] http://java.sun.com/docs/books/tutorial/java/javaOO/nested.html Stephen - 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]
[io][lang] releases
Thought I'd start by commenting on the state of releases: IO - blocked on the Exception issue atm - see active thread on commons-dev. Lang - blocked by the cyclic bug needing to be fixed. The next week and a half is going to be busy for me (my open source laptop died :(, bad weather seems to = bad internet connection and I'm in Boston for a few days, board meeting on Wednesday), so if anyone wants to jump in on a release please don't let me be the one holding it up. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] Inner class exception
On 1/12/07, James Carman [EMAIL PROTECTED] wrote:
Sorry, but this doesn't seem like a very good argument to me - on
this basis you could argue against the whole existance of IO - since
it provides stuff thats not in the JDK
I don't know if I agree with this point, Niall. The stuff that's in
IO wasn't left out of the JDK because of coding style, which is the
reason Stephen (I believe that's who said it) is saying we shouldn't
use nested exception classes. I would agree that nested exception
classes should be avoided. I wouldn't want to have to qualify my
exceptions in my catch blocks:
Sorry, the existance of IO comment was a bad attempt at tongue in
cheek humour :-(
catch( DirectoryWalker.CancelException e )
That just looks ugly/weird to me and people just usually don't do
that. I would agree, however, that it does group stuff logically.
OK but CancelException is primarily there to control the processing
flow internally within DirectoryWalker - its a class designed to be
extended and implementations that do extend it don't have to qualify
the exception. When thrown it unwinds from the recursive depths and
causes the handleCancelled() lifecycle method to be called.
So IMO your more likely to see an implementation that does something like
public class MyWalker extends DirectoryWalker {
protected void handleStart() throws IOException {
if (...) {
throw new CancelException(...);
}
}
protected void handleCancelled(...) {
// my cancel processing here
}
}
The default implementation of that method does re-throw it and we have
2 scenrios for this class - cancelling internally by the process
itself or cancelling by an external process. Where users handle
cancellation outside of the implementation then yes they will have to
use the DirectoryWalker.CancelException notation (I personally don't
agree its ugly btw) - but if they don't like it they can easily
re-throw their own.
Niall
On 1/11/07, Niall Pemberton [EMAIL PROTECTED] wrote:
On 1/9/07, Stephen Colebourne [EMAIL PROTECTED] wrote:
From: Henri Yandell [EMAIL PROTECTED]
This helps with naming, but without the scoping, you're left with the
Javadocs as the only way to specify that the exception is intended to be
used only within the DirectoryWalker class. Of course, a public static
inner
class can be used elsewhere as well, but the relationship with the
enclosing
class makes a clear statement of intent.
We can agree to disagree, though - I was mostly just interested in what
the
arguments are against using inner classes, given that I see very clear
and
meaningful reasons for using them.
Ditto. Your arguments are good, so I'm quite happy to go with whatever
consensus is on this one.
I think the other argument is that the JDK doesn't have inner exception
classes (well, maybe it does, but I can't think of any well-known ones ATM). Since
[io] is a JDK+ library, I'd say we should have no inner exceptions.
Sorry, but this doesn't seem like a very good argument to me - on this
basis you could argue against the whole existance of IO - since it
provides stuff thats not in the JDK :-) If you could point to a no
inner exceptions in the jdk policy with reasons why then that would
be a different thing.
Two of the reasons for inner classes on the Sun Java tutorial[1]
apply to this case IMO
- it logically groups the exception with the class it applies to -
i.e. DirectoryWalker
- it makes for more readable/maintainable code
From whats been said in this thread then at the end of the day is
purely down to different stylistic preferences. On that basis I'd
prefer it to remain how I originally coded it. Having said that - if
its going to prevent/hold up an IO 1.3 release then, as I said before,
I'm not going to object to it being changed.
Niall
[1] http://java.sun.com/docs/books/tutorial/java/javaOO/nested.html
Stephen
-
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: [io] Inner class exception
On 1/12/07, Niall Pemberton [EMAIL PROTECTED] wrote:
On 1/12/07, James Carman [EMAIL PROTECTED] wrote:
Sorry, but this doesn't seem like a very good argument to me - on
this basis you could argue against the whole existance of IO - since
it provides stuff thats not in the JDK
I don't know if I agree with this point, Niall. The stuff that's in
IO wasn't left out of the JDK because of coding style, which is the
reason Stephen (I believe that's who said it) is saying we shouldn't
use nested exception classes. I would agree that nested exception
classes should be avoided. I wouldn't want to have to qualify my
exceptions in my catch blocks:
Sorry, the existance of IO comment was a bad attempt at tongue in
cheek humour :-(
catch( DirectoryWalker.CancelException e )
That just looks ugly/weird to me and people just usually don't do
that. I would agree, however, that it does group stuff logically.
OK but CancelException is primarily there to control the processing
flow internally within DirectoryWalker - its a class designed to be
extended and implementations that do extend it don't have to qualify
the exception. When thrown it unwinds from the recursive depths and
causes the handleCancelled() lifecycle method to be called.
So IMO your more likely to see an implementation that does something like
public class MyWalker extends DirectoryWalker {
protected void handleStart() throws IOException {
if (...) {
throw new CancelException(...);
}
}
protected void handleCancelled(...) {
// my cancel processing here
}
}
P.S. Making it a separate class means that users will have to add an
import statement for CancelException to their DirectoryWalker
implementation - which as a static inner class they don't have to do -
so it saves a line of code :-)
Niall
The default implementation of that method does re-throw it and we have
2 scenrios for this class - cancelling internally by the process
itself or cancelling by an external process. Where users handle
cancellation outside of the implementation then yes they will have to
use the DirectoryWalker.CancelException notation (I personally don't
agree its ugly btw) - but if they don't like it they can easily
re-throw their own.
Niall
On 1/11/07, Niall Pemberton [EMAIL PROTECTED] wrote:
On 1/9/07, Stephen Colebourne [EMAIL PROTECTED] wrote:
From: Henri Yandell [EMAIL PROTECTED]
This helps with naming, but without the scoping, you're left with the
Javadocs as the only way to specify that the exception is intended to
be
used only within the DirectoryWalker class. Of course, a public
static inner
class can be used elsewhere as well, but the relationship with the
enclosing
class makes a clear statement of intent.
We can agree to disagree, though - I was mostly just interested in
what the
arguments are against using inner classes, given that I see very
clear and
meaningful reasons for using them.
Ditto. Your arguments are good, so I'm quite happy to go with whatever
consensus is on this one.
I think the other argument is that the JDK doesn't have inner exception
classes (well, maybe it does, but I can't think of any well-known ones ATM). Since [io]
is a JDK+ library, I'd say we should have no inner exceptions.
Sorry, but this doesn't seem like a very good argument to me - on this
basis you could argue against the whole existance of IO - since it
provides stuff thats not in the JDK :-) If you could point to a no
inner exceptions in the jdk policy with reasons why then that would
be a different thing.
Two of the reasons for inner classes on the Sun Java tutorial[1]
apply to this case IMO
- it logically groups the exception with the class it applies to -
i.e. DirectoryWalker
- it makes for more readable/maintainable code
From whats been said in this thread then at the end of the day is
purely down to different stylistic preferences. On that basis I'd
prefer it to remain how I originally coded it. Having said that - if
its going to prevent/hold up an IO 1.3 release then, as I said before,
I'm not going to object to it being changed.
Niall
[1] http://java.sun.com/docs/books/tutorial/java/javaOO/nested.html
Stephen
-
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: [io] Inner class exception
I can see the elegance of the design. Personally, I don't really care one way or the other if you release with that in there. I do think, however, that you should consider the normal developer out there who probably hasn't seen something like this before. I've done a lot of coding in my days and I've never seen that done that I can remember. Most IDEs will automatically generate catch blocks for you anyway these days, but it might jump out at someone and cause some confusion. Then again, maybe it'll help someone learn something new about the Java language. :-) Heck it might even catch on! On 1/11/07, Martin Cooper [EMAIL PROTECTED] wrote: On 1/11/07, James Carman [EMAIL PROTECTED] wrote: Sorry, but this doesn't seem like a very good argument to me - on this basis you could argue against the whole existance of IO - since it provides stuff thats not in the JDK I don't know if I agree with this point, Niall. The stuff that's in IO wasn't left out of the JDK because of coding style, which is the reason Stephen (I believe that's who said it) is saying we shouldn't use nested exception classes. I would agree that nested exception classes should be avoided. I wouldn't want to have to qualify my exceptions in my catch blocks: catch( DirectoryWalker.CancelException e ) That just looks ugly/weird to me and people just usually don't do that. That depends a _lot_ on the kind of coding you're doing / exposed to. For example, it's not particularly common for web apps to use a lot of anonymous inner classes, but if you were looking at Swing code, you'd likely see them all over the place. The above may look ugly / weird to you, but it looks elegant / self-documenting to me. -- Martin Cooper I would agree, however, that it does group stuff logically. On 1/11/07, Niall Pemberton [EMAIL PROTECTED] wrote: On 1/9/07, Stephen Colebourne [EMAIL PROTECTED] wrote: From: Henri Yandell [EMAIL PROTECTED] This helps with naming, but without the scoping, you're left with the Javadocs as the only way to specify that the exception is intended to be used only within the DirectoryWalker class. Of course, a public static inner class can be used elsewhere as well, but the relationship with the enclosing class makes a clear statement of intent. We can agree to disagree, though - I was mostly just interested in what the arguments are against using inner classes, given that I see very clear and meaningful reasons for using them. Ditto. Your arguments are good, so I'm quite happy to go with whatever consensus is on this one. I think the other argument is that the JDK doesn't have inner exception classes (well, maybe it does, but I can't think of any well-known ones ATM). Since [io] is a JDK+ library, I'd say we should have no inner exceptions. Sorry, but this doesn't seem like a very good argument to me - on this basis you could argue against the whole existance of IO - since it provides stuff thats not in the JDK :-) If you could point to a no inner exceptions in the jdk policy with reasons why then that would be a different thing. Two of the reasons for inner classes on the Sun Java tutorial[1] apply to this case IMO - it logically groups the exception with the class it applies to - i.e. DirectoryWalker - it makes for more readable/maintainable code From whats been said in this thread then at the end of the day is purely down to different stylistic preferences. On that basis I'd prefer it to remain how I originally coded it. Having said that - if its going to prevent/hold up an IO 1.3 release then, as I said before, I'm not going to object to it being changed. Niall [1] http://java.sun.com/docs/books/tutorial/java/javaOO/nested.html Stephen - 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: [io][lang] releases
On 1/11/07, Henri Yandell [EMAIL PROTECTED] wrote: Thought I'd start by commenting on the state of releases: IO - blocked on the Exception issue atm - see active thread on commons-dev. Lang - blocked by the cyclic bug needing to be fixed. The next week and a half is going to be busy for me (my open source laptop died :(, bad weather seems to = bad internet connection and I'm in Boston for a few days, board meeting on Wednesday), so if anyone wants to jump in on a release please don't let me be the one holding it up. snip/ If RCs can be cut on m1 and 1.3 (the maven.compile.source for both seems to be set at 1.3 so would appear to be true), then I can probably help latter half of next week, if help is needed. -Rahul Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
UUID MAC configuration
hi all, I am using VersionOneGenerator and I see that we need to configure the MAC addres in the xml file , I mean the uuid.state file .It works locally .But how do I give to other teams and ask them to work without having to enter the MAC address in the uuid.state file.I mean is there any better way to detect the MAC address automatically ? *My Idea is to give a jar file to different teams in my company to generate UUID's. * Thanks Pradeep
[commons-httpclient] 1.x vs. 3.x
Hi, I'm using commons-httpclient 3.0.2 successfully on a new project that I'm working on. However, at the moment I'm having to enhance an old project that is dependent on commons-httpclient 1.x. Can someone tell me what functionality is not available at 1.x. - I assume http 1.0 is only supported, not http 1.1. - basic auth seems to be supported... any sample code? - proxy auth? ... any sample code? - configure socket timeout... do I need to create my own socket to do this? - setting arbitrary http headers... postMethod.setHeader(name, value). Sorry to bring up the past! Thanks for any assistance. Tony Dean SAS Institute Inc. 919.531.6704 [EMAIL PROTECTED] SAS... The Power to Know http://www.sas.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] Inner class exception
Yeah, I'm quite interested in what the response is to having this in the API. It's novel (for me), but could be interesting to release IO as is and see what feedback we get from users on the feature. Hen On 1/11/07, James Carman [EMAIL PROTECTED] wrote: I can see the elegance of the design. Personally, I don't really care one way or the other if you release with that in there. I do think, however, that you should consider the normal developer out there who probably hasn't seen something like this before. I've done a lot of coding in my days and I've never seen that done that I can remember. Most IDEs will automatically generate catch blocks for you anyway these days, but it might jump out at someone and cause some confusion. Then again, maybe it'll help someone learn something new about the Java language. :-) Heck it might even catch on! On 1/11/07, Martin Cooper [EMAIL PROTECTED] wrote: On 1/11/07, James Carman [EMAIL PROTECTED] wrote: Sorry, but this doesn't seem like a very good argument to me - on this basis you could argue against the whole existance of IO - since it provides stuff thats not in the JDK I don't know if I agree with this point, Niall. The stuff that's in IO wasn't left out of the JDK because of coding style, which is the reason Stephen (I believe that's who said it) is saying we shouldn't use nested exception classes. I would agree that nested exception classes should be avoided. I wouldn't want to have to qualify my exceptions in my catch blocks: catch( DirectoryWalker.CancelException e ) That just looks ugly/weird to me and people just usually don't do that. That depends a _lot_ on the kind of coding you're doing / exposed to. For example, it's not particularly common for web apps to use a lot of anonymous inner classes, but if you were looking at Swing code, you'd likely see them all over the place. The above may look ugly / weird to you, but it looks elegant / self-documenting to me. -- Martin Cooper I would agree, however, that it does group stuff logically. On 1/11/07, Niall Pemberton [EMAIL PROTECTED] wrote: On 1/9/07, Stephen Colebourne [EMAIL PROTECTED] wrote: From: Henri Yandell [EMAIL PROTECTED] This helps with naming, but without the scoping, you're left with the Javadocs as the only way to specify that the exception is intended to be used only within the DirectoryWalker class. Of course, a public static inner class can be used elsewhere as well, but the relationship with the enclosing class makes a clear statement of intent. We can agree to disagree, though - I was mostly just interested in what the arguments are against using inner classes, given that I see very clear and meaningful reasons for using them. Ditto. Your arguments are good, so I'm quite happy to go with whatever consensus is on this one. I think the other argument is that the JDK doesn't have inner exception classes (well, maybe it does, but I can't think of any well-known ones ATM). Since [io] is a JDK+ library, I'd say we should have no inner exceptions. Sorry, but this doesn't seem like a very good argument to me - on this basis you could argue against the whole existance of IO - since it provides stuff thats not in the JDK :-) If you could point to a no inner exceptions in the jdk policy with reasons why then that would be a different thing. Two of the reasons for inner classes on the Sun Java tutorial[1] apply to this case IMO - it logically groups the exception with the class it applies to - i.e. DirectoryWalker - it makes for more readable/maintainable code From whats been said in this thread then at the end of the day is purely down to different stylistic preferences. On that basis I'd prefer it to remain how I originally coded it. Having said that - if its going to prevent/hold up an IO 1.3 release then, as I said before, I'm not going to object to it being changed. Niall [1] http://java.sun.com/docs/books/tutorial/java/javaOO/nested.html Stephen - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (FILEUPLOAD-124) Error while uploading the file - in Clusterd in Environment
Error while uploading the file - in Clusterd in Environment --- Key: FILEUPLOAD-124 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-124 Project: Commons FileUpload Issue Type: Bug Environment: In the Integration Environment Reporter: Ramdeepak This happens once in a while, We use the WebLogic proxy itself for loadbalancing. The Weblogic servers are configured in Clustered mode. I have made my Deployments on a machine 'A'. But how and why do the files end up on other servers 'B'. ( The logs are from machine 'B' ). Exception : = org.apache.commons.fileupload.FileUploadException: Processing of multipart/form-data request failed. Stream ended unexpectedly at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:429) at com.nol.core.RequestParameterValue.init(RequestParameterValue.java:110) at com.nol.core.servlet.NolFrontController.doService(NolFrontController.java:187) at com.nol.core.servlet.NolFrontController.doPost(NolFrontController.java:177) at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1072) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:465) at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:28) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27) at com.nol.core.servlet.UserFilter.doFilter(UserFilter.java:300) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27) at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:6987) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121) at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3892) at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2766) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:224) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:183) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
