Re: [logging] pom for commons-logging-api and building/testing JCLwith Maven 1
I didn't read the start of this topic, but just my 2 cents about creating more sub-projects for implementation specifics : You're suggesting to split the project into modules for log4j, avalon and so on. Using maven2 you can create those artifacts as POM (not jars) and keep commons-logging as a main jar with optional dependencies. The specific poms only declare commons-logging and required dependencies for a particular use-case. You can consider such poms as profiles for some typical use of the lib (but profile has other meaning in maven2). I myself use this for my corporate projects : only declare a dependency to mycompany:webapp and you get all required libs for a typical webapp (typical = the way we used to build webapps, other people may consider some of those dependencies useless) I think it is a good idea to keep the tiny commons-logging-api as separate artifact and allow people to only depend on that. For the review of the pom.xml some comments from me: - -consider about spitting off commons-logging-api as a separate project with its own pom.xml. The build logic could be so much simpler. - -what do you think about a common pom.xml for all commons? - -whenever you swith to maven2 then you should switch to the default directory layout - -the profile based dependency stuff is also very complicated magic. Following the maven2 conventions could make it a lot easier. But this might require that you split of the implementation (commons-logging-logj4, commons-logging-avalon, etc.) then you even do not need to declare the dependencies optional - I gues you are not looking foreward to do this (e.g. from the maintaince point of view)... Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFE5OG2mPuec2Dcv/8RAow/AJ9mIdj40xd7kXwq0FSSVQ0oTnOTyQCfdmdn UBpuYgDNsa82Z+V3DcRnH9U= =V5TA -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MATH-155) Number Base Conversion
Number Base Conversion -- Key: MATH-155 URL: http://issues.apache.org/jira/browse/MATH-155 Project: Commons Math Issue Type: New Feature Affects Versions: 1.2 Final Environment: NA Reporter: Chetan I think a maths package without a base conversion utility is quite incomplete. Would request you to include this feature in the package for the next release. From a user's perspective I would like to have a library that goes beyond the usual binary,octal,hexadecimal conversions. Would really be helpful if the library is very generic so as to support convert(Base from,Base to) calls. Pls let me know what you feel about this.Currently i am on the lookout for a base conversion class etc but haven't managed to hit upon anything that serves my purpose. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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: (MATH-155) Number Base Conversion
[ http://issues.apache.org/jira/browse/MATH-155?page=comments#action_12428966 ] James Carman commented on MATH-155: --- So, you basically want to translate the String representation of a number in one base into the String representation for the number in another base? Can you specify *exactly* what you want the API to look like (including return types)? Number Base Conversion -- Key: MATH-155 URL: http://issues.apache.org/jira/browse/MATH-155 Project: Commons Math Issue Type: New Feature Affects Versions: 1.2 Final Environment: NA Reporter: Chetan I think a maths package without a base conversion utility is quite incomplete. Would request you to include this feature in the package for the next release. From a user's perspective I would like to have a library that goes beyond the usual binary,octal,hexadecimal conversions. Would really be helpful if the library is very generic so as to support convert(Base from,Base to) calls. Pls let me know what you feel about this.Currently i am on the lookout for a base conversion class etc but haven't managed to hit upon anything that serves my purpose. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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: (MATH-155) Number Base Conversion
[ http://issues.apache.org/jira/browse/MATH-155?page=comments#action_12428968 ] Chetan commented on MATH-155: - I am not sure how this might work for arbitrary base where base may extend Base36(0-9 and A-Z gets used up). So atleast the convert(Base from,Base to) method call should handle base ranging from 2 -36. Number Base Conversion -- Key: MATH-155 URL: http://issues.apache.org/jira/browse/MATH-155 Project: Commons Math Issue Type: New Feature Affects Versions: 1.2 Final Environment: NA Reporter: Chetan I think a maths package without a base conversion utility is quite incomplete. Would request you to include this feature in the package for the next release. From a user's perspective I would like to have a library that goes beyond the usual binary,octal,hexadecimal conversions. Would really be helpful if the library is very generic so as to support convert(Base from,Base to) calls. Pls let me know what you feel about this.Currently i am on the lookout for a base conversion class etc but haven't managed to hit upon anything that serves my purpose. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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: (MATH-155) Number Base Conversion
[ http://issues.apache.org/jira/browse/MATH-155?page=comments#action_12428969 ] James Carman commented on MATH-155: --- What is Base in this API example? Is that some new class? Couldn't you represent the base using a simple integer? Also, what are you converting? You're not passing in a value in any way. Number Base Conversion -- Key: MATH-155 URL: http://issues.apache.org/jira/browse/MATH-155 Project: Commons Math Issue Type: New Feature Affects Versions: 1.2 Final Environment: NA Reporter: Chetan I think a maths package without a base conversion utility is quite incomplete. Would request you to include this feature in the package for the next release. From a user's perspective I would like to have a library that goes beyond the usual binary,octal,hexadecimal conversions. Would really be helpful if the library is very generic so as to support convert(Base from,Base to) calls. Pls let me know what you feel about this.Currently i am on the lookout for a base conversion class etc but haven't managed to hit upon anything that serves my purpose. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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: (MATH-155) Number Base Conversion
[ http://issues.apache.org/jira/browse/MATH-155?page=comments#action_12428971 ] Chetan commented on MATH-155: - Yes,String representaion should be ok . Something like String (String fromBase,String toBase,String number) For instance if I want to convert 2147483647(in dec) to base 36(ZIK0J) i would want it to look like convertToRequiredBaseAndReturnString(10,36,2147483647); Number Base Conversion -- Key: MATH-155 URL: http://issues.apache.org/jira/browse/MATH-155 Project: Commons Math Issue Type: New Feature Affects Versions: 1.2 Final Environment: NA Reporter: Chetan I think a maths package without a base conversion utility is quite incomplete. Would request you to include this feature in the package for the next release. From a user's perspective I would like to have a library that goes beyond the usual binary,octal,hexadecimal conversions. Would really be helpful if the library is very generic so as to support convert(Base from,Base to) calls. Pls let me know what you feel about this.Currently i am on the lookout for a base conversion class etc but haven't managed to hit upon anything that serves my purpose. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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: (MATH-155) Number Base Conversion
[ http://issues.apache.org/jira/browse/MATH-155?page=comments#action_12428974 ] James Carman commented on MATH-155: --- How about this? String stringValue( long n, int base ); One might argue that this belongs in Commons Lang's StringUtils class rather than in Math somewhere. Number Base Conversion -- Key: MATH-155 URL: http://issues.apache.org/jira/browse/MATH-155 Project: Commons Math Issue Type: New Feature Affects Versions: 1.2 Final Environment: NA Reporter: Chetan I think a maths package without a base conversion utility is quite incomplete. Would request you to include this feature in the package for the next release. From a user's perspective I would like to have a library that goes beyond the usual binary,octal,hexadecimal conversions. Would really be helpful if the library is very generic so as to support convert(Base from,Base to) calls. Pls let me know what you feel about this.Currently i am on the lookout for a base conversion class etc but haven't managed to hit upon anything that serves my purpose. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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: (MATH-155) Number Base Conversion
[ http://issues.apache.org/jira/browse/MATH-155?page=comments#action_12428975 ] James Carman commented on MATH-155: --- Why not try this? new java.math.BigInteger( 2147483647, 10 ).toString( 36 ); Wouldn't that do what you want? Number Base Conversion -- Key: MATH-155 URL: http://issues.apache.org/jira/browse/MATH-155 Project: Commons Math Issue Type: New Feature Affects Versions: 1.2 Final Environment: NA Reporter: Chetan I think a maths package without a base conversion utility is quite incomplete. Would request you to include this feature in the package for the next release. From a user's perspective I would like to have a library that goes beyond the usual binary,octal,hexadecimal conversions. Would really be helpful if the library is very generic so as to support convert(Base from,Base to) calls. Pls let me know what you feel about this.Currently i am on the lookout for a base conversion class etc but haven't managed to hit upon anything that serves my purpose. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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: (MATH-155) Number Base Conversion
[ http://issues.apache.org/jira/browse/MATH-155?page=all ] James Carman updated MATH-155: -- Comment: was deleted Number Base Conversion -- Key: MATH-155 URL: http://issues.apache.org/jira/browse/MATH-155 Project: Commons Math Issue Type: New Feature Affects Versions: 1.2 Final Environment: NA Reporter: Chetan I think a maths package without a base conversion utility is quite incomplete. Would request you to include this feature in the package for the next release. From a user's perspective I would like to have a library that goes beyond the usual binary,octal,hexadecimal conversions. Would really be helpful if the library is very generic so as to support convert(Base from,Base to) calls. Pls let me know what you feel about this.Currently i am on the lookout for a base conversion class etc but haven't managed to hit upon anything that serves my purpose. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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: (MATH-155) Number Base Conversion
[ http://issues.apache.org/jira/browse/MATH-155?page=comments#action_12428977 ] Chetan commented on MATH-155: - i guess that solves my problem. sorry for not doing my homework and needlessly raising a new feature request. Number Base Conversion -- Key: MATH-155 URL: http://issues.apache.org/jira/browse/MATH-155 Project: Commons Math Issue Type: New Feature Affects Versions: 1.2 Final Environment: NA Reporter: Chetan I think a maths package without a base conversion utility is quite incomplete. Would request you to include this feature in the package for the next release. From a user's perspective I would like to have a library that goes beyond the usual binary,octal,hexadecimal conversions. Would really be helpful if the library is very generic so as to support convert(Base from,Base to) calls. Pls let me know what you feel about this.Currently i am on the lookout for a base conversion class etc but haven't managed to hit upon anything that serves my purpose. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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] Closed: (MATH-155) Number Base Conversion
[ http://issues.apache.org/jira/browse/MATH-155?page=all ]
James Carman closed MATH-155.
-
Resolution: Won't Fix
Assignee: James Carman
This functionality is provided by the core JDK's java.math.BigDecimal API. It
would be trivial to create a helper method that looks like this:
public String convert( String value, int originalBase, int targetBase )
{
return new java.math.BigDecimal( value, originalBase ).toString( targetBase );
}
Number Base Conversion
--
Key: MATH-155
URL: http://issues.apache.org/jira/browse/MATH-155
Project: Commons Math
Issue Type: New Feature
Affects Versions: 1.2 Final
Environment: NA
Reporter: Chetan
Assigned To: James Carman
I think a maths package without a base conversion utility is quite incomplete.
Would request you to include this feature in the package for the next release.
From a user's perspective I would like to have a library that goes beyond the
usual binary,octal,hexadecimal conversions.
Would really be helpful if the library is very generic so as to support
convert(Base from,Base to) calls.
Pls let me know what you feel about this.Currently i am on the lookout for a
base conversion class etc but haven't managed to hit upon anything that
serves my purpose.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://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: (EL-13) Boolean bean property not found due to Introspector limitation
Boolean bean property not found due to Introspector limitation
--
Key: EL-13
URL: http://issues.apache.org/jira/browse/EL-13
Project: Commons EL
Issue Type: Bug
Affects Versions: 1.0 Final
Environment: Windows XP, Java 1.5.0_07-b03, Tomcat 5.5.17
Reporter: Joe Littlejohn
Attachments: AdditionalIntrospection.java, el_exception.txt
There is a bug in the java.beans.Introspector which means that it cannot find
the read method for a property of Boolean type (because it looks for the get
prefix, not the is prefix). This is arguably the expected behaviour of the
Introspector, however since the java.beans.PropertyDescriptor acts differently
(it can identify the property read method), this inconsistency hints it's a bug.
Also, with the advent of autoboxing, developers are supposed to be able to free
themselves from primitive types.
The commons EL library is affected by this bug, so using an interface like: -
public interface Bean {
Boolean isEnabled();
}
and an expression like: -
${bean.enabled}
fails with an ELException saying that the property could not be found (see
attached log snippet).
WebLogic does not suffer from this problem, presumably because they implement
their own EL parser (don't use commons.el) which doesn't use the Introspector. I
have written a suggested workaround for this problem which would allow the
commons.el library to continue its use of the Introspector, but deal with this
flaw (see attached). The AdditionalIntrospection could be used in the
BeanInfoManager.initialise() method, like so: -
PropertyDescriptor [] pds = mBeanInfo.getPropertyDescriptors ();
pds = AdditionalIntrospection.findMissingMethods(mBeanClass, pds); // new step
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://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: [logging] SLF4J?
Hello Jörg, Joerg Hohwiller wrote: But in the end, JCL will continue to improve as will SLF4J I expect, and people can choose as they wish - until j.u.logging knocks both libs into the dustbin of history. I do not think that JUL will knock out JCL or SLF4J[1]. JCL is much too spreaded. JUL itself (without homegrown additions or Tomcat-JULI[2] or x4juli[3]) has too less features (especially the handlers and the configuration[4]) too compete successfully against log4j or its derivates nlog4j[5] or logback[6]. just to let you know my oppinion: this will never ever happen. j.u.l is crap because it does NOT have something that one can call an API! Could you specify that with specific design errors? I know the argumentation of Ceki, who has written something before JDK 1.4 JSRs were finalized and tried to put log4j in place. Please do not repeat them - what did _you_ mean? I do not know what they drink at sun's but the jdk is full of rotten design mistakes. Some highlights: * See Calendar.get(int). And a Month starts with 0, but day with 1. This has nothing to do with JUL. * Why does Iterator not extend Enumeration This has nothing to do with JUL. * See the complete collections and OperationNotSupportedException - is that an API? This has nothing to do with JUL. I know its not always easy to design a great API and of course JDK is the most central part so there will always be someone complaining. At least the newer things get designed better. Serious applications will continue NOT to use j.u.l !!! Your arguments against some bad design in some JDK libraries may be OK or not, but I do not see the point against JUL. I think there are still good arguments to use JUL: - I18N support with default JDK mechanisms (there may be better, OK, but the JCP decided to use this ones). - Good (not excellent) possibilities to extend/override/exchange the backend. - No further dependencies than JDK1.4 or above - Interface of the logger-class has some good helper methods - Supported by the major wrappers JCL causing no dependency problems if an API requires JCL - Supported by the currently niche player SLF4J causing no dependency problems if an API requires SLF4J - Major issues solved in third party APIs (i.E., but not the only one, x4juli) Please keep going with JCL - hey, ho :) Yes, JCL is cool and the new 1.1 release makes life much easier, especially its new diagnostic functions and its improved exception/error messages. Great job. Hopefully containers who use/distribute it, will turn to this version. JCL, especially its logger interface and neutral LogFactory is still the number one choice for API developers. Classloader problems are based on missing knowledge, odd/strange behaviour of containers and the need for the absolute maximum flexibility demanded by the users and/or design/implementation goals of the developers. The static binding approach of SLF4J could be achieved with one build script and one or two binding classes - may be a good optional turn for self-compilers. Regards Boris [1] http://www.slf4j.org [2] http://tomcat.apache.org/tomcat-5.5-doc/logging.html [3] http://www.x4juli.org [4] http://java.sun.com/j2se/1.5.0/docs/guide/logging/index.html [5] http://www.slf4j.org/nlog4j/ [6] http://www.logback.com
[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 30 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. -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: 19 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-18082006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-18082006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-18082006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-18082006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-18082006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-18082006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-18082006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-18082006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-18082006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-18082006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-18082006.jar - [junit] at org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:63) [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:58) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:65) [junit] at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:112) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:160) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:80) [junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:102) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:91) [junit] at
[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-jsl-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 30 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. -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: 19 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-18082006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-18082006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-18082006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-18082006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-18082006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-18082006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-18082006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-18082006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-18082006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-18082006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-18082006.jar - [junit] at org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:63) [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:58) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:65) [junit] at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:112) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:160) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:80) [junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:102) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:91) [junit] at
[jira] Deleted: (VFS-79) Cannot list children of HTTP folders
[ http://issues.apache.org/jira/browse/VFS-79?page=all ] Mario Ivankovits deleted VFS-79: Cannot list children of HTTP folders Key: VFS-79 URL: http://issues.apache.org/jira/browse/VFS-79 Project: Commons VFS Issue Type: Bug Environment: Java 1.5 Reporter: Ben Ashpole Assigned To: Mario Ivankovits The following code produces the below exception at f.getChildren(), even though the specified location is a folder with children. Similar problems exist for other protocol supported by VFS. FileSystemManager fsManager = VFS.getManager(); final FileObject f = fsManager.resolveFile( http://people.apache.org/builds/jakarta-commons/nightly/commons-vfs/;); FileObject[] children = f.getChildren(); Exception in thread main org.apache.commons.vfs.FileSystemException: Could not list the contents of http://people.apache.org/builds/jakarta-commons/nightly/commons-vfs; because it is not a folder. at org.apache.commons.vfs.provider.AbstractFileObject.getChildren(AbstractFileObject.java:525) at com.bashpole.reflectorGadget.reflectionGroup.Sync.test(Sync.java:118) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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] Deleted: (VFS-77) VFS cannot determine file type of root for FTP, prevents listing of children at root
[ http://issues.apache.org/jira/browse/VFS-77?page=all ]
Mario Ivankovits deleted VFS-77:
VFS cannot determine file type of root for FTP, prevents listing of children
at root
Key: VFS-77
URL: http://issues.apache.org/jira/browse/VFS-77
Project: Commons VFS
Issue Type: Bug
Environment: Windows, Eclipse, Java 1.5
commons-vfs-20060808.zip
commons-net-1.4.1.jar, etc. (not sure one of the dependencies is the real
problem)
Reporter: Ben Ashpole
Assigned To: Mario Ivankovits
The following example, adapted from
http://jakarta.apache.org/commons/vfs/api.html, throws the below exception
for the given, valid FTP site. Please let me know if this issue can be
replicated!
FileSystemManager fsManager = VFS.getManager();
FileObject f = fsManager.resolveFile(ftp://ftp.uspto.gov/;);
FileObject[] children = f.getChildren(); // exception thrown here
System.out.println(Children of +f.getName().getURI());
for(int i = 0; ichildren.length; i++)
{
System.out.println(children[i].getName().getBaseName());
}
Exception in thread main org.apache.commons.vfs.FileSystemException: Could
not determine the type of file ftp://ftp.uspto.gov/;.
at
org.apache.commons.vfs.provider.AbstractFileObject.attach(AbstractFileObject.java:1281)
at
org.apache.commons.vfs.provider.AbstractFileObject.getType(AbstractFileObject.java:410)
at
org.apache.commons.vfs.provider.AbstractFileObject.getChildren(AbstractFileObject.java:523)
at com.bashpole.reflectorGadget.reflectionGroup.Ftp.test(Ftp.java:55)
at com.bashpole.reflectorGadget.reflectionGroup.Ftp.main(Ftp.java:24)
Caused by: org.apache.commons.vfs.FileSystemException: Object didnt extend
from AbstractFileObject. Object {0}
at
org.apache.commons.vfs.util.FileObjectUtils.getAbstractFileObject(FileObjectUtils.java:50)
at
org.apache.commons.vfs.provider.ftp.FtpFileObject.getInfo(FtpFileObject.java:174)
at
org.apache.commons.vfs.provider.ftp.FtpFileObject.doAttach(FtpFileObject.java:166)
at
org.apache.commons.vfs.provider.AbstractFileObject.attach(AbstractFileObject.java:1267)
... 4 more
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://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]
[nightly build] io failed.
Failed build logs: http://people.apache.org/~psteitz/commons-nightlies/20060818/io.log - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r432586 - in /jakarta/commons/proper/validator/trunk: build.xml src/share/org/apache/commons/validator/ValidatorAction.java xdocs/changes.xml
Author: niallp
Date: Fri Aug 18 07:02:45 2006
New Revision: 432586
URL: http://svn.apache.org/viewvc?rev=432586view=rev
Log:
Fix for VALIDATOR-198 - example does not compile using ant build script. Also
modify ValidatorAction to provide more obvious message for class not found -
thanks to Matthias Fischer
Modified:
jakarta/commons/proper/validator/trunk/build.xml
jakarta/commons/proper/validator/trunk/src/share/org/apache/commons/validator/ValidatorAction.java
jakarta/commons/proper/validator/trunk/xdocs/changes.xml
Modified: jakarta/commons/proper/validator/trunk/build.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/validator/trunk/build.xml?rev=432586r1=432585r2=432586view=diff
==
--- jakarta/commons/proper/validator/trunk/build.xml (original)
+++ jakarta/commons/proper/validator/trunk/build.xml Fri Aug 18 07:02:45 2006
@@ -457,7 +457,7 @@
/target
- target name=example depends=compile.example
+ target name=example depends=compile.example,compile.tests
description=Run example application
java fork=yes
classname=org.apache.commons.validator.example.ValidateExample
Modified:
jakarta/commons/proper/validator/trunk/src/share/org/apache/commons/validator/ValidatorAction.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/validator/trunk/src/share/org/apache/commons/validator/ValidatorAction.java?rev=432586r1=432585r2=432586view=diff
==
---
jakarta/commons/proper/validator/trunk/src/share/org/apache/commons/validator/ValidatorAction.java
(original)
+++
jakarta/commons/proper/validator/trunk/src/share/org/apache/commons/validator/ValidatorAction.java
Fri Aug 18 07:02:45 2006
@@ -624,7 +624,7 @@
try {
this.validationClass = loader.loadClass(this.classname);
} catch (ClassNotFoundException e) {
-throw new ValidatorException(e.getMessage());
+throw new ValidatorException(e.toString());
}
}
Modified: jakarta/commons/proper/validator/trunk/xdocs/changes.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/validator/trunk/xdocs/changes.xml?rev=432586r1=432585r2=432586view=diff
==
--- jakarta/commons/proper/validator/trunk/xdocs/changes.xml (original)
+++ jakarta/commons/proper/validator/trunk/xdocs/changes.xml Fri Aug 18
07:02:45 2006
@@ -39,6 +39,9 @@
body
release version=1.3.1 date=Pending
+ action dev=niallp type=fix issue=VALIDATOR-198 due-to=Matthias
Fischer
+Example does not compile using ant build script.
+ /action
action dev=niallp type=fix issue=VALIDATOR-189 due-to=Thomas
Bailey
Validating indexed properties fails when codenull/code.
/action
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VALIDATOR-198) example does not compile
[ http://issues.apache.org/jira/browse/VALIDATOR-198?page=all ] Niall Pemberton resolved VALIDATOR-198. --- Fix Version/s: 1.3.1 Resolution: Fixed Assignee: Niall Pemberton Fixed, thanks for reporting this. example does not compile Key: VALIDATOR-198 URL: http://issues.apache.org/jira/browse/VALIDATOR-198 Project: Commons Validator Issue Type: Bug Affects Versions: 1.3.0 Release Reporter: Matthias Fischer Assigned To: Niall Pemberton Priority: Minor Fix For: 1.3.1 Changing the example target to depend on compile.tests fixes this target name=example depends=compile.example,compile.tests -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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: (VFS-78) DefaultFileMonitor does not register changes made on FTP FileObjects
[ http://issues.apache.org/jira/browse/VFS-78?page=comments#action_12429045 ] Patrick Schulz commented on VFS-78: --- I investigated the problem a little bit. If you change something while you have DFM hold on a breakpoint at the beginning of run method's mainloop, then the addition may be registered. I suppose it has something to do with the children property of the FileMonitorAgent Objects. It looks like the FileObjects in this map are referencing the new FileName, so that the checkForNewChildren method cannot detect them. Or there could be timing issue before otherwise I cannot explain why it works while step-by-step debugging. DefaultFileMonitor does not register changes made on FTP FileObjects Key: VFS-78 URL: http://issues.apache.org/jira/browse/VFS-78 Project: Commons VFS Issue Type: Bug Affects Versions: Nightly Builds Environment: WinXP, java version 1.5.0_06, commons-vfs nightly 20060814 Reporter: Patrick Schulz Assigned To: Mario Ivankovits I don't know if it is a bug or a feature, but DefaultFileMonitor does not report a renaming of a folder ie. It is signaled as a deletion event, but the folder was renamed. So it is also not possible to register then any changes made in this subfolder until you renamed it again. The URL was something like ftp://ftp.server/incoming/ and the Monitor was started being recursive. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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: [nightly build] io id failed.
On 8/17/06, Jörg Schaible [EMAIL PROTECTED] wrote: Hi Phil, Phil Steitz wrote on Friday, August 18, 2006 3:28 AM: Hi Jorg, Sorry for the latency. I have been out of pocket this week. In answer to your question, I don't know, I just work here ;-) :) Seriously, I think vmbuild.apache.org is a vmware box and the nightlies are running in a Ubuntu Linux image. Here is what I get from uname: Linux vmbuild 2.6.15-23-server #1 SMP Tue May 23 15:10:35 UTC 2006 i686 GNU/Linux Yeah, I think so, too. The funny part about it, that previously the test failed that assumed, that it could create a quite good number of unique ids within a time period and I really had a hard time to find a good solution to compensate backward time shifts from the OS. Now the opposite hapens! This time another test fails, because it simply assumes that it cannot generate two ids within the same time slice (because the generator is configured in this way) ... and is fooled by the OS shifting time forward ;-) I'll modify the test to force the exception ASAP ... The lesson appears to be not to get involved with timing code :) IO's errors are due to timestamping of files on the file system. Lang's error is in its time package. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[httpclient] Please make compile.debug = true the default
Hello All: Unlike version 3.0.1, the 3.1-alpha1 version is not compiled with debug information. I think compile.debug = true is a better default. Thanks, Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r432652 - /jakarta/commons/proper/httpclient/trunk/project.properties
Author: olegk
Date: Fri Aug 18 10:21:16 2006
New Revision: 432652
URL: http://svn.apache.org/viewvc?rev=432652view=rev
Log:
Changed maven.compile.debug flag to true
Modified:
jakarta/commons/proper/httpclient/trunk/project.properties
Modified: jakarta/commons/proper/httpclient/trunk/project.properties
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/httpclient/trunk/project.properties?rev=432652r1=432651r2=432652view=diff
==
--- jakarta/commons/proper/httpclient/trunk/project.properties (original)
+++ jakarta/commons/proper/httpclient/trunk/project.properties Fri Aug 18
10:21:16 2006
@@ -2,7 +2,7 @@
maven.compile.source=1.2
maven.compile.target=1.2
-maven.compile.debug=false
+maven.compile.debug=true
maven.xdoc.date=left
maven.xdoc.version=${pom.currentVersion}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [httpclient] Please make compile.debug = true the default
On Fri, 2006-08-18 at 12:55 -0400, Gary Gregory wrote: Hello All: Unlike version 3.0.1, the 3.1-alpha1 version is not compiled with debug information. I think compile.debug = true is a better default. Done Oleg Thanks, Gary - 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 commit: r432652 - /jakarta/commons/proper/httpclient/trunk/project.properties
Thanks Oleg ;)
Gary
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, August 18, 2006 10:21 AM
To: [EMAIL PROTECTED]
Subject: svn commit: r432652 -
/jakarta/commons/proper/httpclient/trunk/project.properties
Author: olegk
Date: Fri Aug 18 10:21:16 2006
New Revision: 432652
URL: http://svn.apache.org/viewvc?rev=432652view=rev
Log:
Changed maven.compile.debug flag to true
Modified:
jakarta/commons/proper/httpclient/trunk/project.properties
Modified: jakarta/commons/proper/httpclient/trunk/project.properties
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/httpclient/trunk/pro
jec
t.properties?rev=432652r1=432651r2=432652view=diff
==
--- jakarta/commons/proper/httpclient/trunk/project.properties
(original)
+++ jakarta/commons/proper/httpclient/trunk/project.properties Fri Aug
18
10:21:16 2006
@@ -2,7 +2,7 @@
maven.compile.source=1.2
maven.compile.target=1.2
-maven.compile.debug=false
+maven.compile.debug=true
maven.xdoc.date=left
maven.xdoc.version=${pom.currentVersion}
-
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: (COLLECTIONS-222) CollectionUtils removeAll is actually retainAll
CollectionUtils removeAll is actually retainAll --- Key: COLLECTIONS-222 URL: http://issues.apache.org/jira/browse/COLLECTIONS-222 Project: Commons Collections Issue Type: Bug Components: Collection Affects Versions: 3.2 Reporter: Tim Lenz The removeAll(Collection collection, Collection remove) method calls ListUtils.retainAll(collection, remove) instead of ListUtils.removeAll(Collection collection, Collection remove) Should be an easy fix -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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: (COLLECTIONS-222) CollectionUtils removeAll is actually retainAll
[ http://issues.apache.org/jira/browse/COLLECTIONS-222?page=comments#action_12429071 ] Matt Benson commented on COLLECTIONS-222: - duplicate of COLLECTIONS-219 CollectionUtils removeAll is actually retainAll --- Key: COLLECTIONS-222 URL: http://issues.apache.org/jira/browse/COLLECTIONS-222 Project: Commons Collections Issue Type: Bug Components: Collection Affects Versions: 3.2 Reporter: Tim Lenz The removeAll(Collection collection, Collection remove) method calls ListUtils.retainAll(collection, remove) instead of ListUtils.removeAll(Collection collection, Collection remove) Should be an easy fix -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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: (MATH-155) Number Base Conversion
[ http://issues.apache.org/jira/browse/MATH-155?page=comments#action_12429080 ] Remi Arntzen commented on MATH-155: --- One system of radix conversion that is not currently supported by the base Java library's and the Commons is radix conversion for floating point numbers. Hexadecimal support for floating point numbers is given by Double.toHexString(double), however support for additional floating point radix's could be helpful/entertaining. Number Base Conversion -- Key: MATH-155 URL: http://issues.apache.org/jira/browse/MATH-155 Project: Commons Math Issue Type: New Feature Affects Versions: 1.2 Final Environment: NA Reporter: Chetan Assigned To: James Carman I think a maths package without a base conversion utility is quite incomplete. Would request you to include this feature in the package for the next release. From a user's perspective I would like to have a library that goes beyond the usual binary,octal,hexadecimal conversions. Would really be helpful if the library is very generic so as to support convert(Base from,Base to) calls. Pls let me know what you feel about this.Currently i am on the lookout for a base conversion class etc but haven't managed to hit upon anything that serves my purpose. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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] Closed: (COLLECTIONS-222) CollectionUtils removeAll is actually retainAll
[ http://issues.apache.org/jira/browse/COLLECTIONS-222?page=all ] Stephen Colebourne closed COLLECTIONS-222. -- Resolution: Duplicate CollectionUtils removeAll is actually retainAll --- Key: COLLECTIONS-222 URL: http://issues.apache.org/jira/browse/COLLECTIONS-222 Project: Commons Collections Issue Type: Bug Components: Collection Affects Versions: 3.2 Reporter: Tim Lenz The removeAll(Collection collection, Collection remove) method calls ListUtils.retainAll(collection, remove) instead of ListUtils.removeAll(Collection collection, Collection remove) Should be an easy fix -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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: r432694 - /jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/builder/ToStringStyle.java
Author: scolebourne
Date: Fri Aug 18 12:31:37 2006
New Revision: 432694
URL: http://svn.apache.org/viewvc?rev=432694view=rev
Log:
Change protected to package scope
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/builder/ToStringStyle.java
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/builder/ToStringStyle.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/builder/ToStringStyle.java?rev=432694r1=432693r2=432694view=diff
==
---
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/builder/ToStringStyle.java
(original)
+++
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/builder/ToStringStyle.java
Fri Aug 18 12:31:37 2006
@@ -1,5 +1,5 @@
/*
- * Copyright 2002-2005 The Apache Software Foundation.
+ * Copyright 2002-2006 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
@@ -1993,7 +1993,7 @@
*
* pUse the static constant rather than instantiating./p
*/
-protected DefaultToStringStyle() {
+DefaultToStringStyle() {
super();
}
@@ -2026,7 +2026,7 @@
*
* pUse the static constant rather than instantiating./p
*/
-protected NoFieldNameToStringStyle() {
+NoFieldNameToStringStyle() {
super();
this.setUseFieldNames(false);
}
@@ -2060,7 +2060,7 @@
*
* pUse the static constant rather than instantiating./p
*/
-protected ShortPrefixToStringStyle() {
+ShortPrefixToStringStyle() {
super();
this.setUseShortClassName(true);
this.setUseIdentityHashCode(false);
@@ -2092,7 +2092,7 @@
*
* pUse the static constant rather than instantiating./p
*/
-protected SimpleToStringStyle() {
+SimpleToStringStyle() {
super();
this.setUseClassName(false);
this.setUseIdentityHashCode(false);
@@ -2128,7 +2128,7 @@
*
* pUse the static constant rather than instantiating./p
*/
-protected MultiLineToStringStyle() {
+MultiLineToStringStyle() {
super();
this.setContentStart([);
this.setFieldSeparator(SystemUtils.LINE_SEPARATOR + );
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35338] - [net] FTPClient.listFiles() hangs on Red Hat Linux
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=35338. 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=35338 --- Additional Comments From [EMAIL PROTECTED] 2006-08-18 19:29 --- Whoops I forgot to provide a question with the post. My question is thus: #1 is this problem definitely due to having SELinux enabled #2 if yes to #1 is there any way to solve the problem without disabling SELinux #3 if no to #2 is there any way to disable SELinux without recompiling/switching the kernel (In reply to comment #44) I'm getting the same problem when running on: CentOS 4 uname -a returns:Linux horae 2.6.9-11.106.unsupportedsmp #1 SMP Wed Jun 8 22:05:04 CDT 2005 i686 i686 i386 GNU/Linux Here's the log messages my program printed out indicating ftp connection status/type: Log Message At: Thu Aug 17 15:04:47 PDT 2006 : FTPConnection connected to ftp.sac.co.za Log Message At: Thu Aug 17 15:04:47 PDT 2006 : Reply String: 220 scs Microsoft FTP Service (Version 5.0). Log Message At: Thu Aug 17 15:04:49 PDT 2006 : Client Type: Windows_NT version 5.0 Log Message At: Thu Aug 17 15:04:49 PDT 2006 : System Name: Windows_NT version 5.0 Log Message At: Thu Aug 17 15:04:49 PDT 2006 : Status: 211-scs Microsoft Windows NT FTP Server status: Version 5.0 Connected to horae.SSL.Berkeley.EDU Logged in as Themis TYPE: ASCII, FORM: Nonprint; STRUcture: File; transfer MODE: STREAM No data connection 211 End of status. I set my client to passive mode. -- 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 35338] - [net] FTPClient.listFiles() hangs on Red Hat Linux
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=35338. 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=35338 --- Additional Comments From [EMAIL PROTECTED] 2006-08-18 19:34 --- You need to be making your comments at https://issues.apache.org/jira/browse/NET-61 . All Jakarta commons issues are now in JIRA. -- 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 35338] - [net] FTPClient.listFiles() hangs on Red Hat Linux
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=35338. 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=35338 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2006-08-18 19:36 --- Adding pcruce so he will know to go to JIRA as I stated above. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r432703 - in /jakarta/commons/proper/lang/trunk/src: java/org/apache/commons/lang/enums/Enum.java test/org/apache/commons/lang/enums/EnumEqualsTest.java
Author: scolebourne
Date: Fri Aug 18 12:51:26 2006
New Revision: 432703
URL: http://svn.apache.org/viewvc?rev=432703view=rev
Log:
Ensure classes are the same in Enum.compareTo
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enums/Enum.java
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/enums/EnumEqualsTest.java
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enums/Enum.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enums/Enum.java?rev=432703r1=432702r2=432703view=diff
==
---
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enums/Enum.java
(original)
+++
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enums/Enum.java
Fri Aug 18 12:51:26 2006
@@ -1,5 +1,5 @@
/*
- * Copyright 2002-2005 The Apache Software Foundation.
+ * Copyright 2002-2006 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
@@ -584,6 +584,8 @@
if (other.getClass().getName().equals(this.getClass().getName())) {
return iName.compareTo( getNameInOtherClassLoader(other) );
}
+throw new ClassCastException(
+Different enum class ' +
ClassUtils.getShortClassName(other.getClass()) + ');
}
return iName.compareTo(((Enum) other).iName);
}
Modified:
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/enums/EnumEqualsTest.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/enums/EnumEqualsTest.java?rev=432703r1=432702r2=432703view=diff
==
---
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/enums/EnumEqualsTest.java
(original)
+++
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/enums/EnumEqualsTest.java
Fri Aug 18 12:51:26 2006
@@ -87,4 +87,33 @@
assertEquals(false, TrafficlightColorEnum.RED.equals(new
TotallyUnrelatedClass(some)));
assertEquals(false, CarColorEnum.RED.equals(new
TotallyUnrelatedClass(some)));
}
+
+//---
+public void testCompareTo() {
+try {
+CarColorEnum.RED.compareTo(TrafficlightColorEnum.RED);
+fail();
+} catch (ClassCastException ex) {}
+try {
+CarColorEnum.YELLOW.compareTo(TrafficlightColorEnum.YELLOW);
+fail();
+} catch (ClassCastException ex) {}
+try {
+TrafficlightColorEnum.RED.compareTo(new
TotallyUnrelatedClass(red));
+fail();
+} catch (ClassCastException ex) {}
+try {
+CarColorEnum.RED.compareTo(new TotallyUnrelatedClass(red));
+fail();
+} catch (ClassCastException ex) {}
+try {
+TrafficlightColorEnum.RED.compareTo(new
TotallyUnrelatedClass(some));
+fail();
+} catch (ClassCastException ex) {}
+try {
+CarColorEnum.RED.compareTo(new TotallyUnrelatedClass(some));
+fail();
+} catch (ClassCastException ex) {}
+}
+
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r432748 - in /jakarta/commons/proper/lang/trunk/src: java/org/apache/commons/lang/enums/ test/org/apache/commons/lang/enums/
Author: scolebourne
Date: Fri Aug 18 15:21:47 2006
New Revision: 432748
URL: http://svn.apache.org/viewvc?rev=432748view=rev
Log:
LANG-259 - Fix compareTo to check the type is the same
Added:
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/enums/ValuedLanguageEnum.java
(with props)
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enums/ValuedEnum.java
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/enums/EnumEqualsTest.java
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/enums/ValuedEnumTest.java
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enums/ValuedEnum.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enums/ValuedEnum.java?rev=432748r1=432747r2=432748view=diff
==
---
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enums/ValuedEnum.java
(original)
+++
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enums/ValuedEnum.java
Fri Aug 18 15:21:47 2006
@@ -1,5 +1,5 @@
/*
- * Copyright 2002-2005 The Apache Software Foundation.
+ * Copyright 2002-2006 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
@@ -15,6 +15,8 @@
*/
package org.apache.commons.lang.enums;
+import java.lang.reflect.InvocationTargetException;
+import java.lang.reflect.Method;
import java.util.Iterator;
import java.util.List;
@@ -165,7 +167,11 @@
*
* pThe default ordering is numeric by value, but this
* can be overridden by subclasses./p
- *
+ *
+ * pNOTE: From v2.2 the enums must be of the same type.
+ * If the parameter is in a different class loader than this instance,
+ * reflection is used to compare the values./p
+ *
* @see java.lang.Comparable#compareTo(Object)
* @param other the other object to compare to
* @return -ve if this is less than the other object, +ve if greater than,
@@ -174,7 +180,38 @@
* @throws NullPointerException if other is codenull/code
*/
public int compareTo(Object other) {
+if (other == this) {
+return 0;
+}
+if (other.getClass() != this.getClass()) {
+if (other.getClass().getName().equals(this.getClass().getName())) {
+return iValue - getValueInOtherClassLoader(other);
+}
+throw new ClassCastException(
+Different enum class ' +
ClassUtils.getShortClassName(other.getClass()) + ');
+}
return iValue - ((ValuedEnum) other).iValue;
+}
+
+/**
+ * pUse reflection to return an objects value./p
+ *
+ * @param other the object to determine the value for
+ * @return the value
+ */
+private int getValueInOtherClassLoader(Object other) {
+try {
+Method mth = other.getClass().getMethod(getValue, null);
+Integer value = (Integer) mth.invoke(other, null);
+return value.intValue();
+} catch (NoSuchMethodException e) {
+// ignore - should never happen
+} catch (IllegalAccessException e) {
+// ignore - should never happen
+} catch (InvocationTargetException e) {
+// ignore - should never happen
+}
+throw new IllegalStateException(This should not happen);
}
/**
Modified:
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/enums/EnumEqualsTest.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/enums/EnumEqualsTest.java?rev=432748r1=432747r2=432748view=diff
==
---
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/enums/EnumEqualsTest.java
(original)
+++
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/enums/EnumEqualsTest.java
Fri Aug 18 15:21:47 2006
@@ -1,5 +1,5 @@
/*
- * Copyright 2004-2005 The Apache Software Foundation.
+ * Copyright 2004-2006 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
@@ -15,6 +15,8 @@
*/
package org.apache.commons.lang.enums;
+import java.net.URLClassLoader;
+
import junit.framework.Test;
import junit.framework.TestCase;
import junit.framework.TestSuite;
@@ -86,6 +88,34 @@
assertEquals(false, TrafficlightColorEnum.RED.equals(new
TotallyUnrelatedClass(some)));
assertEquals(false, CarColorEnum.RED.equals(new
TotallyUnrelatedClass(some)));
+}
+
+public void testEquals_classloader_equal() throws Exception {
+ClassLoader cl =
[jira] Closed: (LANG-259) ValuedEnum.compareTo(Object other) not typesafe - it easily could be...
[ http://issues.apache.org/jira/browse/LANG-259?page=all ] Stephen Colebourne closed LANG-259. --- Fix Version/s: 2.2 (was: 2.3) Resolution: Fixed Fix compareTo to check type rv 432748 ValuedEnum.compareTo(Object other) not typesafe - it easily could be... --- Key: LANG-259 URL: http://issues.apache.org/jira/browse/LANG-259 Project: Commons Lang Issue Type: Bug Affects Versions: 2.1 Environment: all Reporter: Ralf Hauser Fix For: 2.2 int org.apache.commons.lang.enums.ValuedEnum.compareTo(Object other) is not typesafe - if the int-values are the same, it will return 0 even for two totally different sub-classes of ValuedEnum -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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: [all] maven group ids
On 8/16/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Yes, but instead of transiting something, that depends on other commons IMHO something without dependencies should be transited first. In other words, first thing to be done should be a graph of dependencies between various commons packages and those without dependencies should be migrated first. I guess commons-lang is a good candidate here, not configuration that depdends on many other (not migrated yet) components. What would we gain from this? A transition of component A will not include updating existing commons-dependencies in component A to the new ones with the new groupId. That will require a new release of that component A. If fact we don't even have to wait for a release of a component to do this. There is a good reason for *not* picking commons-lang or commons-logging, two components without dependencies on other commons components, as the first component to transition. That is that both are on ibiblio's top 10 downloads list. I had link to it before but can't seem to find it now, sorry. If we do it wrong there then all hell will break loose. It'd be better to choose a medium used component. But this means, that all of those users, that downloading those top10 jars in near future will have obosolete jars. Maven is not re-downloading nonSNAPSHOT artifacts so... Let's imagine I'm a new maven user having project with a dependency on commons-lang:commons-lang-2.1 and maven will download it for me. Some time later this package will be relocated to org.apache.commons.lang:commons-lang:2.1 (or similar). After that there'll be new, let's say acegi v1.4 depending on this 'new' commons-lang (org.apache:commons-lang:2.1) and I need this acegi in my project. So after adding dependency on acegi maven will download org.apache.commons.lang:commons-lang:2.1 and won't download commons-lang:commons-lang:2.1 (which should result as relocation info) and finally, maven will be adding those two commons-lang jars into classpath, copy into WEB-INF/lib and so on. All of this till the time I'll manually remove commons-lang:commons-lang:2.1 from my repository so maven will be forced to reload them (and will download relocation info then). So finally I think that sooner those jars will be relocated there'll be less users having problems like this. Regards, Tomek -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
