RE: [logging] proposal
Hello, just to complete this, I requested this some time ago also: http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg52438.html ... and no, joerg and me only share the name, not the instance g - Jörg joerg wrote on Monday, August 01, 2005 9:01 PM: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, I have a request on the commons-logging API and I did not put it on the subject to not hit your mailfilters :) Yep, you guessed it - it's the getChildLogger(String) thingy. First of all commons-logging, like other commons subprojects, aims to be a library to avoid having the reinvent-the-wheel effect so many projects can benifit using that single logging API and building a large community. I hope I see this right :) In general commons-logging does a good job and I can perfectly aggree with the loglevels defined by commons-logging and with every method available in the Log interface (I could not do this for the JDK Logging API). What I am missing is the simple getChildLogger(String) method. And I am not the first and the only one out there: So the last time it was proposed seems to be 23 Apr 2004: http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/2 00404.mbox/[EMAIL PROTECTED] Then there was the discussion http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg 17177.html esp. http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg 17204.html The thread died because people worried about compotibility. Besides the references in those threads there are many more projects that defined their own Log(ger) API (e.g. plexus to mention another) simply because the lack of the getChildLogger(String) method. So the result is that you write your code according to one logging API and can not embed that code (library, component, or whatever it may be) in the next project because there a different Logging API is used. JAVA is cool but when classpaths become of political interest I wish back the good old smalltalk days ;) So all I want is that more projects are using commons-logging. Isn't that your interest, too? So give me another try: If you do not like to break compatibility, simply add another interface called org.apache.commons.logging.Logger (this would also give it a nicer name :) ). Give it the method /** * This method creates a new child logger. * The name of the child logger will be * codecurrent-name + '.' + nameSuffix/code. * * @param nameSuffix * the postfix for the name of the child logger to create. * It must have a [EMAIL PROTECTED] String#length()} greater zero. * @return the new logger * @throws IllegalArgumentException if the given name has a */ Logger getChildLogger(String nameSuffix); This would make many people happy. Not as important but even nicer would be to also have a method /** * This method gets the name of this logger.br * Best practice is to use package-names or even classpaths * as name for a logger. * * @return the loggers name. */ String getName(); BTW then you could change the line above from * codethis.name + '.' + nameSuffix/code. to * code[EMAIL PROTECTED] #getName() name} + '.' + nameSuffix/code. Now If you still want more, I would like to see generic methods as void log(Loglevel level, Object message); void log(Loglevel level, Object message, Throwable cause); boolean isLoglevelEnabled(Loglevel level); Where Loglevel is a typesafe enum containing the 6 available loglevels (I will leve it open for now if that's gonna be a jdk5.0 enum). If you want I could send you a full-featured and full-documented Logger Interface. Now, if that was too much, just add the single getChildLogger(String) method. You may modify the javadoc according to your needs and wishes. You may even do NOT touch your implementation and anything else in commons-logging to make me really happy. People could write their own implementations (which would still be silly) but the code using the API would be reusable with another implementation (esp. one of the millions of IoC or whatever frameworks out there). Just this single method eigther in Log or in Logger. What do you think? Best regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC7nFRmPuec2Dcv/8RAuIrAJ0elWFO3UbsI7gG7IoWBF/dmf7FVwCfbsmq voGbNjp73fbCdIFoXIe1Z84= =NLJW -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [logging] proposal
[AARGH - I hate top-posting!] I'm not opposed to this proposal. Commons-logging already creates a proxy Log object for each underlying real logger object, so at the worst the name can be remembered at the Log object level as far as I can see. In other words, this functionality should be possible to implement whatever the underlying logging library. And I'm generally convinced by the emails to this thread that all reasonable logging libraries provide a way for logging objects to return their name anyway. I don't personally have any need for this feature, but it seems that people with reasonable credentials do. So overall I'm in favour of some kind of implementation of this feature. Commons-logging needs to be *very* careful about adding features to its API but this seems to me like one that passes the necessary tests. If you were to create a bugzilla entry with an implementation of this feature and supporting unit tests [and assuming no-one else votes against it] I will review and commit it sometime in the next few weeks. Note, however, that commons-logging isn't making much progress at the moment, and several issues standing in the way of a new release. So there's no guarantee of when the next release might actually be pushed out. Regards, Simon PS: Two Joerg Schaibles? How confusing! On Tue, 2005-08-02 at 08:12 +0200, Jörg Schaible wrote: Hello, just to complete this, I requested this some time ago also: http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg52438.html ... and no, joerg and me only share the name, not the instance g - Jörg joerg wrote on Monday, August 01, 2005 9:01 PM: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, I have a request on the commons-logging API and I did not put it on the subject to not hit your mailfilters :) Yep, you guessed it - it's the getChildLogger(String) thingy. First of all commons-logging, like other commons subprojects, aims to be a library to avoid having the reinvent-the-wheel effect so many projects can benifit using that single logging API and building a large community. I hope I see this right :) In general commons-logging does a good job and I can perfectly aggree with the loglevels defined by commons-logging and with every method available in the Log interface (I could not do this for the JDK Logging API). What I am missing is the simple getChildLogger(String) method. And I am not the first and the only one out there: So the last time it was proposed seems to be 23 Apr 2004: http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/2 00404.mbox/[EMAIL PROTECTED] Then there was the discussion http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg 17177.html esp. http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg 17204.html The thread died because people worried about compotibility. Besides the references in those threads there are many more projects that defined their own Log(ger) API (e.g. plexus to mention another) simply because the lack of the getChildLogger(String) method. So the result is that you write your code according to one logging API and can not embed that code (library, component, or whatever it may be) in the next project because there a different Logging API is used. JAVA is cool but when classpaths become of political interest I wish back the good old smalltalk days ;) So all I want is that more projects are using commons-logging. Isn't that your interest, too? So give me another try: If you do not like to break compatibility, simply add another interface called org.apache.commons.logging.Logger (this would also give it a nicer name :) ). Give it the method /** * This method creates a new child logger. * The name of the child logger will be * codecurrent-name + '.' + nameSuffix/code. * * @param nameSuffix * the postfix for the name of the child logger to create. * It must have a [EMAIL PROTECTED] String#length()} greater zero. * @return the new logger * @throws IllegalArgumentException if the given name has a */ Logger getChildLogger(String nameSuffix); This would make many people happy. Not as important but even nicer would be to also have a method /** * This method gets the name of this logger.br * Best practice is to use package-names or even classpaths * as name for a logger. * * @return the loggers name. */ String getName(); BTW then you could change the line above from * codethis.name + '.' + nameSuffix/code. to * code[EMAIL PROTECTED] #getName() name} + '.' + nameSuffix/code. Now If you still want more, I would like to see generic methods as void log(Loglevel level, Object message); void log(Loglevel level, Object message, Throwable cause); boolean isLoglevelEnabled(Loglevel level); Where Loglevel is a
RE: [logging] proposal
Hi Simon, Simon Kitching wrote on Tuesday, August 02, 2005 10:00 AM: [AARGH - I hate top-posting!] me too. I'm not opposed to this proposal. Commons-logging already creates a proxy Log object for each underlying real logger object, so at the worst the name can be remembered at the Log object level as far as I can see. In other words, this functionality should be possible to implement whatever the underlying logging library. And I'm generally convinced by the emails to this thread that all reasonable logging libraries provide a way for logging objects to return their name anyway. I don't personally have any need for this feature, but it seems that people with reasonable credentials do. Fine. So overall I'm in favour of some kind of implementation of this feature. Commons-logging needs to be *very* careful about adding features to its API but this seems to me like one that passes the necessary tests. If you were to create a bugzilla entry with an implementation of this feature and supporting unit tests [and assuming no-one else votes against it] I will review and commit it sometime in the next few weeks. OK. Note, however, that commons-logging isn't making much progress at the moment, and several issues standing in the way of a new release. So there's no guarantee of when the next release might actually be pushed out. Well, the requests started two years ago, so we have already waited some time. At least I will be glad if it gets into the next version. Regards, Simon PS: Two Joerg Schaibles? How confusing! No, just two Jörgs, but I did not want that somebody assumes, that we try to urge somebody about this feature using different aliases, just because of the same (first) name. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35970] New: - white spaces in empty elements with indentation active
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=35970.
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=35970
Summary: white spaces in empty elements with indentation active
Product: Commons
Version: unspecified
Platform: Other
OS/Version: All
Status: NEW
Severity: minor
Priority: P4
Component: Betwixt
AssignedTo: commons-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
Element's name contains trailing spaces caused by indentation algorithm, under
specific circumstances.
When xml is written from the org.apache.commons.betwixt.io.BeanWriter, an empty
(property value is null) element's name contains trailing spaces if:
a. pretty printing is enabled
b. setEndTagForEmptyElement is set to true
The output looks like this:
emptytag/emptytag
The number of spaces depends on the indentation level of the tag being written.
Note:I'm not sure that this could be considered a bug, but it causes some real
problems for one of our application where a third-party CORBA component parses
the tag without trimming the spaces, and thus is unable to correctly identify
the tag name.
A work-around is to set pretty print off.
The issue is present in codebase for Betwixt 0.7 revision 226973.
http://svn.apache.org/repos/asf/jakarta/commons/proper/betwixt/branches/RELEASE_0_7_BRANCH/src/java/org/apache/commons/betwixt/io/BeanWriter.java
The culprit is in the endElement() method, as shown in the following snippet:
protected void endElement(
WriteContext context,
String uri,
String localName,
String qualifiedName)
throws
IOException,
SAXException {
if (
!addEndTagForEmptyElement
!closedStartTag
currentElementIsEmpty ) {
writer.write( / );
closedStartTag = true;
} else {
if (!currentElementHasBodyText) {
indent(); /*-- LOOK HERE */
}
if (
addEndTagForEmptyElement
!closedStartTag ) {
writer.write( );
closedStartTag = true;
}
writer.write( / );
writer.write( qualifiedName );
writer.write( '' );
}
indentLevel--;
printLine();
currentElementHasBodyText = false;
}
Actually I can't manage to understand why indent() is called but for a null
property it tries to indent the output *before* closing the opening tag
resulting in trailing spaces in the tag name (and after the attibutes when
present, I assume...).
Thank you.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [exec] Design of commons-exec
Brett Porter wrote: * Would it be a good starting point (if so I'll create a patch for the code I've cleaned up and removed the Ant specifics from)? I think so. Cool, I'll get you a SVN patch tonight to get started. /niklas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-javaflow (in module jakarta-commons-sandbox) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-javaflow has an issue affecting its community integration. This issue affects 4 projects, and has been outstanding for 6 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon-block-javaflow : Java XML Framework - cocoon-block-mail : Java XML Framework - cocoon-block-scratchpad : Java XML Framework - commons-javaflow : Commons Javaflow Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-javaflow/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-javaflow-02082005.jar] identifier set to project name -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/javaflow/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/javaflow/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/javaflow/project.properties -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-javaflow/gump_work/build_jakarta-commons-sandbox_commons-javaflow.html Work Name: build_jakarta-commons-sandbox_commons-javaflow (Type: Build) Work ended in a state of : Failed Elapsed: 13 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons-sandbox/javaflow] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/io/dist/jakarta-commons-io-02082005.jar:/usr/local/gump/public/workspace/jakarta-commons-sandbox/jci/target/commons-jci-02082005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-02082005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-02082005.jar:/usr/local/gump/public/workspace/jakarta-jmeter/lib/xstream-1.1.2.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar - | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0.2 build:start: java:prepare-filesystem: [mkdir] Created dir: /x1/gump/public/workspace/jakarta-commons-sandbox/javaflow/target/classes java:compile: [echo] Compiling to /x1/gump/public/workspace/jakarta-commons-sandbox/javaflow/target/classes [echo] == NOTE: Targetting JVM 1.4, classes will not run on earlier JVMs == [javac] Compiling 28 source files to /x1/gump/public/workspace/jakarta-commons-sandbox/javaflow/target/classes java:jar-resources: test:prepare-filesystem: [mkdir] Created dir: /x1/gump/public/workspace/jakarta-commons-sandbox/javaflow/target/test-classes [mkdir] Created dir: /x1/gump/public/workspace/jakarta-commons-sandbox/javaflow/target/test-reports test:test-resources: test:compile: [javac] Compiling 9 source files to /x1/gump/public/workspace/jakarta-commons-sandbox/javaflow/target/test-classes test:test: [junit] Running org.apache.commons.javaflow.ContinuationTestCase [junit] Tests run: 2, Failures: 0, Errors: 2, Time elapsed: 1.638 sec [junit] [ERROR] TEST org.apache.commons.javaflow.ContinuationTestCase FAILED [junit] Running org.apache.commons.javaflow.ContinuationCompilingClassLoaderTestCase [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.491 sec [junit] Running org.apache.commons.javaflow.SerializationTestCase [junit] Tests run: 2, Failures: 0, Errors: 2, Time elapsed: 1.442 sec [junit] [ERROR] TEST org.apache.commons.javaflow.SerializationTestCase FAILED BUILD FAILED File.. /home/gump/.maven/cache/maven-test-plugin-1.6.2/plugin.jelly Element... fail Line.. 181 Column 54 There were test failures. Total time: 12 seconds Finished at: Tue Aug 02 02:54:09 PDT 2005
[EMAIL PROTECTED]: Project commons-javaflow (in module jakarta-commons-sandbox) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-javaflow has an issue affecting its community integration. This issue affects 4 projects, and has been outstanding for 6 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon-block-javaflow : Java XML Framework - cocoon-block-mail : Java XML Framework - cocoon-block-scratchpad : Java XML Framework - commons-javaflow : Commons Javaflow Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-javaflow/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-javaflow-02082005.jar] identifier set to project name -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/javaflow/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/javaflow/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/javaflow/project.properties -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-javaflow/gump_work/build_jakarta-commons-sandbox_commons-javaflow.html Work Name: build_jakarta-commons-sandbox_commons-javaflow (Type: Build) Work ended in a state of : Failed Elapsed: 13 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons-sandbox/javaflow] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/io/dist/jakarta-commons-io-02082005.jar:/usr/local/gump/public/workspace/jakarta-commons-sandbox/jci/target/commons-jci-02082005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-02082005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-02082005.jar:/usr/local/gump/public/workspace/jakarta-jmeter/lib/xstream-1.1.2.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar - | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0.2 build:start: java:prepare-filesystem: [mkdir] Created dir: /x1/gump/public/workspace/jakarta-commons-sandbox/javaflow/target/classes java:compile: [echo] Compiling to /x1/gump/public/workspace/jakarta-commons-sandbox/javaflow/target/classes [echo] == NOTE: Targetting JVM 1.4, classes will not run on earlier JVMs == [javac] Compiling 28 source files to /x1/gump/public/workspace/jakarta-commons-sandbox/javaflow/target/classes java:jar-resources: test:prepare-filesystem: [mkdir] Created dir: /x1/gump/public/workspace/jakarta-commons-sandbox/javaflow/target/test-classes [mkdir] Created dir: /x1/gump/public/workspace/jakarta-commons-sandbox/javaflow/target/test-reports test:test-resources: test:compile: [javac] Compiling 9 source files to /x1/gump/public/workspace/jakarta-commons-sandbox/javaflow/target/test-classes test:test: [junit] Running org.apache.commons.javaflow.ContinuationTestCase [junit] Tests run: 2, Failures: 0, Errors: 2, Time elapsed: 1.638 sec [junit] [ERROR] TEST org.apache.commons.javaflow.ContinuationTestCase FAILED [junit] Running org.apache.commons.javaflow.ContinuationCompilingClassLoaderTestCase [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.491 sec [junit] Running org.apache.commons.javaflow.SerializationTestCase [junit] Tests run: 2, Failures: 0, Errors: 2, Time elapsed: 1.442 sec [junit] [ERROR] TEST org.apache.commons.javaflow.SerializationTestCase FAILED BUILD FAILED File.. /home/gump/.maven/cache/maven-test-plugin-1.6.2/plugin.jelly Element... fail Line.. 181 Column 54 There were test failures. Total time: 12 seconds Finished at: Tue Aug 02 02:54:09 PDT 2005
Re: [exec] Design of commons-exec
On 01/08/05, Niklas Gustavsson [EMAIL PROTECTED] wrote: ... This is a very short description of the cleaned up Ant exec task design: ... * Process destroyer: adds itself as a shutdown hook, Execute adds and removes created processes to ensure that they are correctly destroyed when the JVM stops. I'm sure it works in Ant but I'm worry about using such solution in server-side applications where JVM (in therory) do not stop - just application is being redeployed over and over. Regards, Tomek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly (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 has an issue affecting its community integration. This issue affects 47 projects, and has been outstanding for 50 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon-block-ojb : Java XML Framework - cocoon-block-querybean : Java XML Framework - commons-jelly : Commons Jelly - commons-jelly-tags-ant : Commons Jelly - commons-jelly-tags-antlr : Commons Jelly - commons-jelly-tags-avalon : Commons Jelly - commons-jelly-tags-bean : Commons Jelly - commons-jelly-tags-beanshell : Commons Jelly - commons-jelly-tags-betwixt : Commons Jelly - commons-jelly-tags-bsf : Commons Jelly - commons-jelly-tags-define : Commons Jelly - commons-jelly-tags-dynabean : Commons Jelly - commons-jelly-tags-email : Commons Jelly - commons-jelly-tags-fmt : Commons Jelly - commons-jelly-tags-html : Commons Jelly - commons-jelly-tags-http : Commons Jelly - commons-jelly-tags-interaction : Commons Jelly - commons-jelly-tags-jaxme : Commons Jelly - commons-jelly-tags-jetty : Commons Jelly - commons-jelly-tags-jface : Commons Jelly - commons-jelly-tags-jms : Commons Jelly - commons-jelly-tags-jmx : Commons Jelly - commons-jelly-tags-jsl : Commons Jelly - commons-jelly-tags-junit : Commons Jelly - commons-jelly-tags-log : Commons Jelly - commons-jelly-tags-memory : Commons Jelly - commons-jelly-tags-ojb : Commons Jelly - commons-jelly-tags-quartz : Commons Jelly - commons-jelly-tags-regexp : Commons Jelly - commons-jelly-tags-soap : Commons Jelly - commons-jelly-tags-sql : Commons Jelly - commons-jelly-tags-swing : Commons Jelly - commons-jelly-tags-swt : Commons Jelly - commons-jelly-tags-threads : Commons Jelly - commons-jelly-tags-util : Commons Jelly - commons-jelly-tags-validate : Commons Jelly - commons-jelly-tags-velocity : Commons Jelly - commons-jelly-tags-xml : Commons Jelly - commons-jelly-tags-xmlunit : Commons Jelly - commons-latka : Functional Testing Suite - commons-sql : Basic Services Architecture - db-ojb : ObjectRelationalBridge - db-ojb-from-packages : ObjectRelationalBridge - geronimo : Apache Geronimo, the J2EE server project of the Apache Softw... - maven : Project Management Tools - maven-bootstrap : Project Management Tools - test-ojb : ObjectRelationalBridge Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly/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-02082005.jar] identifier set to project name -DEBUG- Dependency on jakarta-servletapi-5-servlet exists, no need to add for property maven.jar.servletapi. -DEBUG- Dependency on jakarta-taglibs-standard exists, no need to add for property maven.jar.jstl. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/target/test-reports -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly/gump_work/build_commons-jelly_commons-jelly.html Work Name: build_commons-jelly_commons-jelly (Type: Build) Work ended in a state of : Failed Elapsed: 1 min 3 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly] CLASSPATH:
[EMAIL PROTECTED]: Project commons-jelly (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 has an issue affecting its community integration. This issue affects 47 projects, and has been outstanding for 50 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon-block-ojb : Java XML Framework - cocoon-block-querybean : Java XML Framework - commons-jelly : Commons Jelly - commons-jelly-tags-ant : Commons Jelly - commons-jelly-tags-antlr : Commons Jelly - commons-jelly-tags-avalon : Commons Jelly - commons-jelly-tags-bean : Commons Jelly - commons-jelly-tags-beanshell : Commons Jelly - commons-jelly-tags-betwixt : Commons Jelly - commons-jelly-tags-bsf : Commons Jelly - commons-jelly-tags-define : Commons Jelly - commons-jelly-tags-dynabean : Commons Jelly - commons-jelly-tags-email : Commons Jelly - commons-jelly-tags-fmt : Commons Jelly - commons-jelly-tags-html : Commons Jelly - commons-jelly-tags-http : Commons Jelly - commons-jelly-tags-interaction : Commons Jelly - commons-jelly-tags-jaxme : Commons Jelly - commons-jelly-tags-jetty : Commons Jelly - commons-jelly-tags-jface : Commons Jelly - commons-jelly-tags-jms : Commons Jelly - commons-jelly-tags-jmx : Commons Jelly - commons-jelly-tags-jsl : Commons Jelly - commons-jelly-tags-junit : Commons Jelly - commons-jelly-tags-log : Commons Jelly - commons-jelly-tags-memory : Commons Jelly - commons-jelly-tags-ojb : Commons Jelly - commons-jelly-tags-quartz : Commons Jelly - commons-jelly-tags-regexp : Commons Jelly - commons-jelly-tags-soap : Commons Jelly - commons-jelly-tags-sql : Commons Jelly - commons-jelly-tags-swing : Commons Jelly - commons-jelly-tags-swt : Commons Jelly - commons-jelly-tags-threads : Commons Jelly - commons-jelly-tags-util : Commons Jelly - commons-jelly-tags-validate : Commons Jelly - commons-jelly-tags-velocity : Commons Jelly - commons-jelly-tags-xml : Commons Jelly - commons-jelly-tags-xmlunit : Commons Jelly - commons-latka : Functional Testing Suite - commons-sql : Basic Services Architecture - db-ojb : ObjectRelationalBridge - db-ojb-from-packages : ObjectRelationalBridge - geronimo : Apache Geronimo, the J2EE server project of the Apache Softw... - maven : Project Management Tools - maven-bootstrap : Project Management Tools - test-ojb : ObjectRelationalBridge Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly/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-02082005.jar] identifier set to project name -DEBUG- Dependency on jakarta-servletapi-5-servlet exists, no need to add for property maven.jar.servletapi. -DEBUG- Dependency on jakarta-taglibs-standard exists, no need to add for property maven.jar.jstl. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/target/test-reports -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly/gump_work/build_commons-jelly_commons-jelly.html Work Name: build_commons-jelly_commons-jelly (Type: Build) Work ended in a state of : Failed Elapsed: 1 min 3 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly] CLASSPATH:
Native File System Integration
Hi, Is there any Java based solution for mounting any file resourse (cifs, zip, etc.) to a drive on Windows and to any where in UNIX? I know, this is not directly related to Commons VFS. One more question that is related to Commons VFS and my previos question is: Is there any Java and Commons VFS based solution for mounting Commons VFS resource to the native file system? If this could be done than all the applications using Commons VFS directly benefit from native file system integration. Cheers, -- Ersin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [exec] Design of commons-exec
Tomasz Pik wrote: * Process destroyer: adds itself as a shutdown hook, Execute adds and removes created processes to ensure that they are correctly destroyed when the JVM stops. I'm sure it works in Ant but I'm worry about using such solution in server-side applications where JVM (in therory) do not stop - just application is being redeployed over and over. I agree. Right now everything is tuned for Ant-type applications (quick runs). In the case of long-runnings JVMs a Watchdog is more appropriate. In the current code I got the ProcessDestroyer is not optional but I'll make a note of fixing that. Thanks! /niklas -- Niklas Gustavsson [EMAIL PROTECTED] http://www.protocol7.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [docs] draft of building components page
On 31/07/05, Phil Steitz [EMAIL PROTECTED] wrote: Sorry...URL below should be http://people.apache.org/~psteitz/building.html On 7/31/05, Phil Steitz [EMAIL PROTECTED] wrote: I committed a draft in /commons-build/xdocs/building.xml, but did not link this. You can see the html here: http://people.apache.org/~psteitz/buildling.html I also committed a bunch of sample files referred to in in the text. Pls (gently) correct any errors or bad recommendations. Thanks! Looks good. Using here for link names is not ideal. Rather than: Follow the instructions here to download and install maven why not put Follow the instructions to download and install maven instead? And similarly for the other generic link text items. Makes it easier for screen readers (software and human!) to understand what the link does without needing to look at the context. Just my 1d. S. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r227018 [2/2] - in /jakarta/commons/proper/configuration/trunk: ./ conf/ src/java/org/apache/commons/configuration/ src/java/org/apache/commons/configuration/plist/ src/test/org/apache/commons/configuration/plist/ xdocs/
Added:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/plist/SimpleCharStream.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/plist/SimpleCharStream.java?rev=227018view=auto
==
---
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/plist/SimpleCharStream.java
(added)
+++
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/plist/SimpleCharStream.java
Tue Aug 2 07:43:20 2005
@@ -0,0 +1,401 @@
+/* Generated By:JavaCC: Do not edit this line. SimpleCharStream.java Version
3.0 */
+package org.apache.commons.configuration.plist;
+
+/**
+ * An implementation of interface CharStream, where the stream is assumed to
+ * contain only ASCII characters (without unicode processing).
+ */
+
+class SimpleCharStream
+{
+ public static final boolean staticFlag = false;
+ int bufsize;
+ int available;
+ int tokenBegin;
+ public int bufpos = -1;
+ protected int bufline[];
+ protected int bufcolumn[];
+
+ protected int column = 0;
+ protected int line = 1;
+
+ protected boolean prevCharIsCR = false;
+ protected boolean prevCharIsLF = false;
+
+ protected java.io.Reader inputStream;
+
+ protected char[] buffer;
+ protected int maxNextCharInd = 0;
+ protected int inBuf = 0;
+
+ protected void ExpandBuff(boolean wrapAround)
+ {
+ char[] newbuffer = new char[bufsize + 2048];
+ int newbufline[] = new int[bufsize + 2048];
+ int newbufcolumn[] = new int[bufsize + 2048];
+
+ try
+ {
+if (wrapAround)
+{
+ System.arraycopy(buffer, tokenBegin, newbuffer, 0, bufsize -
tokenBegin);
+ System.arraycopy(buffer, 0, newbuffer,
+ bufsize - tokenBegin, bufpos);
+ buffer = newbuffer;
+
+ System.arraycopy(bufline, tokenBegin, newbufline, 0, bufsize -
tokenBegin);
+ System.arraycopy(bufline, 0, newbufline, bufsize - tokenBegin,
bufpos);
+ bufline = newbufline;
+
+ System.arraycopy(bufcolumn, tokenBegin, newbufcolumn, 0, bufsize -
tokenBegin);
+ System.arraycopy(bufcolumn, 0, newbufcolumn, bufsize - tokenBegin,
bufpos);
+ bufcolumn = newbufcolumn;
+
+ maxNextCharInd = (bufpos += (bufsize - tokenBegin));
+}
+else
+{
+ System.arraycopy(buffer, tokenBegin, newbuffer, 0, bufsize -
tokenBegin);
+ buffer = newbuffer;
+
+ System.arraycopy(bufline, tokenBegin, newbufline, 0, bufsize -
tokenBegin);
+ bufline = newbufline;
+
+ System.arraycopy(bufcolumn, tokenBegin, newbufcolumn, 0, bufsize -
tokenBegin);
+ bufcolumn = newbufcolumn;
+
+ maxNextCharInd = (bufpos -= tokenBegin);
+}
+ }
+ catch (Throwable t)
+ {
+throw new Error(t.getMessage());
+ }
+
+
+ bufsize += 2048;
+ available = bufsize;
+ tokenBegin = 0;
+ }
+
+ protected void FillBuff() throws java.io.IOException
+ {
+ if (maxNextCharInd == available)
+ {
+if (available == bufsize)
+{
+ if (tokenBegin 2048)
+ {
+ bufpos = maxNextCharInd = 0;
+ available = tokenBegin;
+ }
+ else if (tokenBegin 0)
+ bufpos = maxNextCharInd = 0;
+ else
+ ExpandBuff(false);
+}
+else if (available tokenBegin)
+ available = bufsize;
+else if ((tokenBegin - available) 2048)
+ ExpandBuff(true);
+else
+ available = tokenBegin;
+ }
+
+ int i;
+ try {
+if ((i = inputStream.read(buffer, maxNextCharInd,
+available - maxNextCharInd)) == -1)
+{
+ inputStream.close();
+ throw new java.io.IOException();
+}
+else
+ maxNextCharInd += i;
+return;
+ }
+ catch(java.io.IOException e) {
+--bufpos;
+backup(0);
+if (tokenBegin == -1)
+ tokenBegin = bufpos;
+throw e;
+ }
+ }
+
+ public char BeginToken() throws java.io.IOException
+ {
+ tokenBegin = -1;
+ char c = readChar();
+ tokenBegin = bufpos;
+
+ return c;
+ }
+
+ protected void UpdateLineColumn(char c)
+ {
+ column++;
+
+ if (prevCharIsLF)
+ {
+prevCharIsLF = false;
+line += (column = 1);
+ }
+ else if (prevCharIsCR)
+ {
+prevCharIsCR = false;
+if (c == '\n')
+{
+ prevCharIsLF = true;
+}
+else
+ line += (column = 1);
+ }
+
+ switch (c)
+ {
+
DO NOT REPLY [Bug 32633] - [configuration] Support the OpenStep property list format
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=32633. 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=32633 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-08-02 16:52 --- Two new configurations are now in SVN, PropertyListConfiguration and XMLPropertyListConfiguration in the org.apache.commons.configuration.plist package. Both classes are hierarchical configurations, I introducted AbstractHierarchicalFileConfiguration to factorize some code (XMLConfiguration may benefit from extending this class as well). PropertyListConfiguration uses a parser generated by JavaCC, the grammar is in the same package, it's not based on the Cayenne grammar mentionned in Comment #1. XMLPropertyListConfiguration uses Digester. Both configurations have an additional dependency on commons-codec (used for encoding/decoding byte[] values). -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r227019 - in /jakarta/commons/proper/configuration/trunk: conf/test.plist.xml src/java/org/apache/commons/configuration/plist/XMLPropertyListConfiguration.java
Author: ebourg Date: Tue Aug 2 07:58:15 2005 New Revision: 227019 URL: http://svn.apache.org/viewcvs?rev=227019view=rev Log: Fixed the version of the property list (1.1 - 1.0) Modified: jakarta/commons/proper/configuration/trunk/conf/test.plist.xml jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/plist/XMLPropertyListConfiguration.java Modified: jakarta/commons/proper/configuration/trunk/conf/test.plist.xml URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/configuration/trunk/conf/test.plist.xml?rev=227019r1=227018r2=227019view=diff == --- jakarta/commons/proper/configuration/trunk/conf/test.plist.xml (original) +++ jakarta/commons/proper/configuration/trunk/conf/test.plist.xml Tue Aug 2 07:58:15 2005 @@ -1,6 +1,6 @@ ?xml version=1.0? !DOCTYPE plist SYSTEM file://localhost/System/Library/DTDs/PropertyList.dtd -plist version=1.1 +plist version=1.0 dict keystring/key Modified: jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/plist/XMLPropertyListConfiguration.java URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/plist/XMLPropertyListConfiguration.java?rev=227019r1=227018r2=227019view=diff == --- jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/plist/XMLPropertyListConfiguration.java (original) +++ jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/plist/XMLPropertyListConfiguration.java Tue Aug 2 07:58:15 2005 @@ -55,7 +55,7 @@ * pre * lt;?xml version=1.0? * lt;!DOCTYPE plist SYSTEM file://localhost/System/Library/DTDs/PropertyList.dtd - * lt;plist version=1.1 + * lt;plist version=1.0 * lt;dict * lt;keystringlt;/key * lt;stringvalue1lt;/string @@ -283,7 +283,7 @@ } writer.println(!DOCTYPE plist SYSTEM \file://localhost/System/Library/DTDs/PropertyList.dtd\); -writer.println(plist version=\1.1\); +writer.println(plist version=\1.0\); printNode(writer, 1, getRoot()); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35946] - [configuration] CompositeConfiguration getList doesn't return all property values
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35946. 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=35946 [EMAIL PROTECTED] changed: What|Removed |Added Summary|CompositeConfiguration |[configuration] |getList doesn't return all |CompositeConfiguration |property values |getList doesn't return all ||property values -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [exec] Design of commons-exec
On Tue, 2005-08-02 at 16:18 +0200, Niklas Gustavsson wrote: Tomasz Pik wrote: * Process destroyer: adds itself as a shutdown hook, Execute adds and removes created processes to ensure that they are correctly destroyed when the JVM stops. I'm sure it works in Ant but I'm worry about using such solution in server-side applications where JVM (in therory) do not stop - just application is being redeployed over and over. I agree. Right now everything is tuned for Ant-type applications (quick runs). In the case of long-runnings JVMs a Watchdog is more appropriate. In the current code I got the ProcessDestroyer is not optional but I'll make a note of fixing that. The folks developing Continuum would certainly like to help work on something that is usable in a server environment. We use some command line utilities to call various build tools and we'd love to be able to use the tool developed here instead of maintaining our own (which we borrowed from CruiseControl -- some other people that might want to help contribute to this cause). Thanks! /niklas -- Niklas Gustavsson [EMAIL PROTECTED] http://www.protocol7.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org Three people can keep a secret provided two of them are dead. -- Unknown - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35946] - [configuration] CompositeConfiguration getList doesn't return all property values
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35946. 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=35946 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-08-02 17:16 --- Hi Steve, this is actually the intend of this configuration. Sorry if it is misnamed, ChainedConfiguration or CascadedConfiguration would be more appropriate. -- 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 33840] - [beanutils] PropertyUtils.isReadable() and PropertyUtils.getProperty() not consistent
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=33840.
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=33840
--- Additional Comments From [EMAIL PROTECTED] 2005-08-02 17:18 ---
Furthermore, at least the 1.7 implementation is not sufficiently robust. For
example, if I try:
PropertyUtils.isReadable(new WrapDynaBean(new Socket()), inputStream)
returns 'true'. A subsequent read of this field will yield:
java.lang.IllegalArgumentException: Property 'inputStream' has no read method
PropertyUtils should either inspect DynaBeans in a manner that WrapDynaBean (and
presumably other types of DynaBeans) can modulate (for instance: template
methods DynaBean.isReadable()/isWriteable()) or it should special-case
WrapDynaBean to perform the more thorough PropertyDescriptor test on the
WrapDynaBean.instance() return value:
// Return the requested result
Object realInstance;
if (bean instanceof WrapDynaBean) {
realInstance = ((WrapDynaBean) bean).getInstance();
} else {
realInstance = bean;
}
try {
PropertyDescriptor desc =
getPropertyDescriptor(bean, name);
if (desc != null) {
Method readMethod = desc.getReadMethod();
if ((readMethod == null)
(desc instanceof IndexedPropertyDescriptor)) {
readMethod = ((IndexedPropertyDescriptor)
desc).getIndexedReadMethod();
}
return (readMethod != null);
} else {
return (false);
}
} catch (IllegalAccessException e) {
return (false);
} catch (InvocationTargetException e) {
return (false);
} catch (NoSuchMethodException e) {
return (false);
}
}
For that matter, is there a reason the read/write status of a property is not
just part of the DynaProperty structure?
--
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 35945] - [configuration] MapConfiguration doesn't support multiple-valued properties
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=35945. 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=35945 [EMAIL PROTECTED] changed: What|Removed |Added Summary|MapConfiguration doesn't|[configuration] |support multiple-valued |MapConfiguration doesn't |properties |support multiple-valued ||properties -- 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: r227023 - /jakarta/commons/proper/discovery/trunk/src/java/org/apache/commons/discovery/jdk/JDK12Hooks.java
Author: dims
Date: Tue Aug 2 08:23:04 2005
New Revision: 227023
URL: http://svn.apache.org/viewcvs?rev=227023view=rev
Log:
Check permission to create a class loader (Axis fails in Applet Scenarios -
http://issues.apache.org/jira/browse/AXIS-2145)
Modified:
jakarta/commons/proper/discovery/trunk/src/java/org/apache/commons/discovery/jdk/JDK12Hooks.java
Modified:
jakarta/commons/proper/discovery/trunk/src/java/org/apache/commons/discovery/jdk/JDK12Hooks.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/discovery/trunk/src/java/org/apache/commons/discovery/jdk/JDK12Hooks.java?rev=227023r1=227022r2=227023view=diff
==
---
jakarta/commons/proper/discovery/trunk/src/java/org/apache/commons/discovery/jdk/JDK12Hooks.java
(original)
+++
jakarta/commons/proper/discovery/trunk/src/java/org/apache/commons/discovery/jdk/JDK12Hooks.java
Tue Aug 2 08:23:04 2005
@@ -210,7 +210,14 @@
}
if (classLoader == null) {
-classLoader = new PsuedoSystemClassLoader();
+SecurityManager security = System.getSecurityManager();
+if (security != null) {
+try {
+security.checkCreateClassLoader();
+classLoader = new PsuedoSystemClassLoader();
+} catch (SecurityException se){
+}
+}
}
// Return the selected class loader
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33840] - [beanutils] PropertyUtils.isReadable() and PropertyUtils.getProperty() not consistent
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=33840. 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=33840 --- Additional Comments From [EMAIL PROTECTED] 2005-08-02 17:29 --- My example was inaccurate - it showed a different problem, namely that IllegalArgumentException is being thrown in WrapDynaBean get() without a cause being set, which is misleading. In that case inputStream is indeed available to read, however an exception occurs (probably because the socket is not connection). One can choose any other arbitrary object to illustrate the problem I was trying to describe however. For example, URL will report host as writeable when it really isn't. -- 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: r227028 - in /jakarta/commons/proper/configuration/trunk: project.xml src/java/org/apache/commons/configuration/HierarchicalConfiguration.java src/test/org/apache/commons/configuration/TestHierarchicalConfiguration.java xdocs/changes.xml
Author: ebourg
Date: Tue Aug 2 08:45:55 2005
New Revision: 227028
URL: http://svn.apache.org/viewcvs?rev=227028view=rev
Log:
getKeys() in HierarchicalConfiguration now returns an iterator over an ordered
set, this implies an upgrade of the dependency on Commons Collections (3.0 -
3.1) (Bug 35903)
New Node constructor (name/value)
Removed the default constuctor from HierarchicalConfiguration
Modified:
jakarta/commons/proper/configuration/trunk/project.xml
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/HierarchicalConfiguration.java
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestHierarchicalConfiguration.java
jakarta/commons/proper/configuration/trunk/xdocs/changes.xml
Modified: jakarta/commons/proper/configuration/trunk/project.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/configuration/trunk/project.xml?rev=227028r1=227027r2=227028view=diff
==
--- jakarta/commons/proper/configuration/trunk/project.xml (original)
+++ jakarta/commons/proper/configuration/trunk/project.xml Tue Aug 2 08:45:55
2005
@@ -198,7 +198,7 @@
dependency
groupIdcommons-collections/groupId
artifactIdcommons-collections/artifactId
- version3.0/version
+ version3.1/version
properties
war.bundletrue/war.bundle
/properties
Modified:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/HierarchicalConfiguration.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/HierarchicalConfiguration.java?rev=227028r1=227027r2=227028view=diff
==
---
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/HierarchicalConfiguration.java
(original)
+++
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/HierarchicalConfiguration.java
Tue Aug 2 08:45:55 2005
@@ -19,7 +19,6 @@
import java.io.Serializable;
import java.util.ArrayList;
import java.util.Collection;
-import java.util.HashSet;
import java.util.Iterator;
import java.util.LinkedList;
import java.util.List;
@@ -27,6 +26,7 @@
import java.util.Stack;
import org.apache.commons.collections.map.LinkedMap;
+import org.apache.commons.collections.set.ListOrderedSet;
import org.apache.commons.lang.StringUtils;
/**
@@ -92,8 +92,7 @@
* @version $Id: HierarchicalConfiguration.java,v 1.14 2004/12/02 22:05:52
* ebourg Exp $
*/
-public class HierarchicalConfiguration extends AbstractConfiguration implements
-Cloneable
+public class HierarchicalConfiguration extends AbstractConfiguration
implements Serializable, Cloneable
{
/** Constant for a new dummy key. */
private static final String NEW_KEY = newKey;
@@ -102,14 +101,6 @@
private Node root = new Node();
/**
- * Creates a new instance of codeHierarchicalConfiguration/code.
- */
-public HierarchicalConfiguration()
-{
-super();
-}
-
-/**
* Returns the root node of this hierarchical configuration.
*
* @return the root node
@@ -421,8 +412,8 @@
}
/**
- * pReturns an iterator with all keys defined in this configuration./p
- * pNote that the keys returned by this method will not contain any
+ * Returns an iterator with all keys defined in this configuration.
+ * Note that the keys returned by this method will not contain any
* indices. This means that some structure will be lost./p
*
* @return an iterator with the defined keys in this configuration
@@ -431,6 +422,7 @@
{
DefinedKeysVisitor visitor = new DefinedKeysVisitor();
getRoot().visit(visitor, new ConfigurationKey());
+
return visitor.getKeyList().iterator();
}
@@ -523,13 +515,13 @@
*
* @param keyPart the configuration key iterator
* @param node the actual node
- * @param data here the found nodes are stored
+ * @param nodes here the found nodes are stored
*/
-protected void findPropertyNodes(ConfigurationKey.KeyIterator keyPart,
Node node, Collection data)
+protected void findPropertyNodes(ConfigurationKey.KeyIterator keyPart,
Node node, Collection nodes)
{
if (!keyPart.hasNext())
{
-data.add(node);
+nodes.add(node);
}
else
{
@@ -540,14 +532,14 @@
if (keyPart.getIndex() children.size() keyPart.getIndex()
= 0)
{
findPropertyNodes((ConfigurationKey.KeyIterator)
keyPart.clone(), (Node) children.get(keyPart
-.getIndex()), data);
+.getIndex()), nodes);
}
}
else
DO NOT REPLY [Bug 35903] - [configuration] getKeys() in HierarchicalConfiguration doesn't preserve the order of the keys
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=35903. 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=35903 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-08-02 17:46 --- Fixed -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Why is org.apache.commons.lang.math.IntRange final?
I am trying to extend the functionality of IntRange based on Martin Fowler's Analysis Pattern of Range to model a street Address Range. http://www.martinfowler.com/ap2/range.html So for example, a street Joe Blow St will have an associated AddressRange of 2000-2999 etc... I wanted to extend IntRange and add the functions mentioned in the Range pattern and add some more: for e.g. to check if its valid range (ideally in a constructor or a isValid() method). Right now I am forced into cut pasting IntRange in my AddressRange class which extends org.apache.commons.lang.math.Range. I would ideally like to just extend IntRange. Why are these classes finalized? Is it just because of security as David Wheeler says in #8 http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/java.html Btw, Commons is cool! I am also using MultiKey and MultiKeyMap to figure out errors in street attributes. Thanks in advance! Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r227044 - in /jakarta/commons/proper/discovery/trunk/src/java/org/apache/commons/discovery: jdk/JDK11Hooks.java jdk/JDK12Hooks.java jdk/JDKHooks.java tools/ManagedProperties.java
Author: dims
Date: Tue Aug 2 10:04:25 2005
New Revision: 227044
URL: http://svn.apache.org/viewcvs?rev=227044view=rev
Log:
- Adding getSystemProperty in JDKHooks for handling SecurityException
- Handle one more SecurityException in classLoader.getParent()
Modified:
jakarta/commons/proper/discovery/trunk/src/java/org/apache/commons/discovery/jdk/JDK11Hooks.java
jakarta/commons/proper/discovery/trunk/src/java/org/apache/commons/discovery/jdk/JDK12Hooks.java
jakarta/commons/proper/discovery/trunk/src/java/org/apache/commons/discovery/jdk/JDKHooks.java
jakarta/commons/proper/discovery/trunk/src/java/org/apache/commons/discovery/tools/ManagedProperties.java
Modified:
jakarta/commons/proper/discovery/trunk/src/java/org/apache/commons/discovery/jdk/JDK11Hooks.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/discovery/trunk/src/java/org/apache/commons/discovery/jdk/JDK11Hooks.java?rev=227044r1=227043r2=227044view=diff
==
---
jakarta/commons/proper/discovery/trunk/src/java/org/apache/commons/discovery/jdk/JDK11Hooks.java
(original)
+++
jakarta/commons/proper/discovery/trunk/src/java/org/apache/commons/discovery/jdk/JDK11Hooks.java
Tue Aug 2 10:04:25 2005
@@ -27,6 +27,15 @@
private static final ClassLoader systemClassLoader
= new PsuedoSystemClassLoader();
+/**
+ * Get the system property
+ *
+ * @param propName name of the property
+ * @return value of the property
+ */
+public String getSystemProperty(final String propName) {
+return System.getProperty(propName);
+}
/**
* The thread context class loader is available for JDK 1.2
Modified:
jakarta/commons/proper/discovery/trunk/src/java/org/apache/commons/discovery/jdk/JDK12Hooks.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/discovery/trunk/src/java/org/apache/commons/discovery/jdk/JDK12Hooks.java?rev=227044r1=227043r2=227044view=diff
==
---
jakarta/commons/proper/discovery/trunk/src/java/org/apache/commons/discovery/jdk/JDK12Hooks.java
(original)
+++
jakarta/commons/proper/discovery/trunk/src/java/org/apache/commons/discovery/jdk/JDK12Hooks.java
Tue Aug 2 10:04:25 2005
@@ -46,6 +46,25 @@
}
/**
+ * Get the system property
+ *
+ * @param propName name of the property
+ * @return value of the property
+ */
+public String getSystemProperty(final String propName) {
+return (String)
+java.security.AccessController.doPrivileged(new
java.security.PrivilegedAction() {
+public Object run() {
+try {
+return System.getProperty(propName);
+} catch (SecurityException se){
+return null;
+}
+}
+});
+}
+
+/**
* The thread context class loader is available for JDK 1.2
* or later, if certain security conditions are met.
*
Modified:
jakarta/commons/proper/discovery/trunk/src/java/org/apache/commons/discovery/jdk/JDKHooks.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/discovery/trunk/src/java/org/apache/commons/discovery/jdk/JDKHooks.java?rev=227044r1=227043r2=227044view=diff
==
---
jakarta/commons/proper/discovery/trunk/src/java/org/apache/commons/discovery/jdk/JDKHooks.java
(original)
+++
jakarta/commons/proper/discovery/trunk/src/java/org/apache/commons/discovery/jdk/JDKHooks.java
Tue Aug 2 10:04:25 2005
@@ -41,6 +41,14 @@
}
/**
+ * Get the system property
+ *
+ * @param propName name of the property
+ * @return value of the property
+ */
+public abstract String getSystemProperty(final String propName);
+
+/**
* The thread context class loader is available for JDK 1.2
* or later, if certain security conditions are met.
*
Modified:
jakarta/commons/proper/discovery/trunk/src/java/org/apache/commons/discovery/tools/ManagedProperties.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/discovery/trunk/src/java/org/apache/commons/discovery/tools/ManagedProperties.java?rev=227044r1=227043r2=227044view=diff
==
---
jakarta/commons/proper/discovery/trunk/src/java/org/apache/commons/discovery/tools/ManagedProperties.java
(original)
+++
jakarta/commons/proper/discovery/trunk/src/java/org/apache/commons/discovery/tools/ManagedProperties.java
Tue Aug 2 10:04:25 2005
@@ -121,7 +121,7 @@
* @return property value if found, otherwise default.
*/
public static String getProperty(ClassLoader classLoader, String
propertyName) {
-String value = System.getProperty(propertyName);
+String value =
Re: [EMAIL PROTECTED]: Project commons-javaflow (in module jakarta-commons-sandbox) failed
Brett Porter wrote: Someone needs to edit: http://svn.apache.org/repos/asf/gump/metadata/project/jakarta-commons-sandbox.xml (which all Apache committers can) You should add: junitreport nested=./target/test-reports / to the section that already exists for javaflow. Thanks for a detailed instruction. I made the change. -- Kohsuke Kawaguchi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[lang] RE: Why is org.apache.commons.lang.math.IntRange final?
Personally, I do not see why these classes should be non-subclassable, if that's a word. In the Range class I see: Specific subclasses hold the range values as different types. Each * subclass should be immutable and [EMAIL PROTECTED] java.io.Serializable Serializable} * if possible. I do not know why a range should be immutable, maybe Stephen can elaborate. Seems like Range should really be an interface and not a class, then we could have a MutableRange subinterface (subclass?) Should we have an ImmutableRange interface with a MutableRange sub so that we can keep Range as a class for b/w compat? But I'm not sure that makes any sense. Gary -Original Message- From: Amit Kulkarni [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 02, 2005 9:08 AM To: commons-dev@jakarta.apache.org Subject: Why is org.apache.commons.lang.math.IntRange final? I am trying to extend the functionality of IntRange based on Martin Fowler's Analysis Pattern of Range to model a street Address Range. http://www.martinfowler.com/ap2/range.html So for example, a street Joe Blow St will have an associated AddressRange of 2000-2999 etc... I wanted to extend IntRange and add the functions mentioned in the Range pattern and add some more: for e.g. to check if its valid range (ideally in a constructor or a isValid() method). Right now I am forced into cut pasting IntRange in my AddressRange class which extends org.apache.commons.lang.math.Range. I would ideally like to just extend IntRange. Why are these classes finalized? Is it just because of security as David Wheeler says in #8 http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/java.html Btw, Commons is cool! I am also using MultiKey and MultiKeyMap to figure out errors in street attributes. Thanks in advance! Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs - 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: [javaflow] class loader
I noticed that in ContinuationClassLoader you aren't actually using
the marker interface to decide what to instrument any more. Is this
by design? I also noticed a similar comment in the TODO file.
Yes, I am no big fan of empty marker interfaces.
I'd prefer a configuration approach.
If so, I can remove the Continuable interface.
Sure
I still see some value in retaining the ContinuationCapable
interface, as this seems to be something we can use for detecting
errors at runtime. But since ContinuationCapable doesn't need to be
visible to users, I wonder if we can move it to the bytecode
subpackage.
Makes sense, too ...maybe *that* interface
should be called Continuable then. WDYT?
Another thing about ContinuationClassLoader. Right now this class
is hard-coded to recognize the javaflow test packages, but this
needs to be parameterized.
Yes, that needs to change
Also, in JUnit, the list of excluded packages can be read from a
data file [1]. I suggest we implement something like that. I don't
think it makes sense for this file to be a property file, so I
think we can just read this as an UTF-8 encoded text file where
each line specifies a new mask. Let me know how you think about me
making those changes.
Not sure how...that's why I haven't done
it yet. I'd rather like to use a more
sophisticated configuration approach.
Usually I love the configuration classes
from Avalon ...but I don't want to have
that dependency.
...question is also how it can be handled
when the classloader is being used as
system classloader.
BTW, I found this JUnit implementation interesting. It doesn't seem
to exclude any of the java.* or org.w3c.*, but it must be clearly
working.
But it does...
private String[] excludeFromLoading = {
java.,
javax.,
sun.,
org.xml.,
org.w3c.,
org.apache.commons.logging
};
...only the compiling one does not because
it's using parent-last delegation and the
repository of classes is restricted to the
user's classes.
Personally, I find the current ContinuationClassLoader bit too
error-prone. Because the parent ClassLoader can always load the
same class that a child ContinuationClassLoader can load, you can
easily get two Class objects that have the same name if you are not
careful.
Well ...we cannot necessarily prevent classes
from being loaded through the parent classloader.
In my day job, I saw several JAXB users who face this kind of
issues while using JAXB in JUnit, and these issues are very hard to
diagnose.
Sure ...classloader stuff is always tricky.
For this reason, I wonder if we can have another ClassLoader that
works more like a traditional URLClassLoader --- you tell it a set
of locations to look at, then the class loader loads a class file
from it with byte-code instrumentation. This requires a developer
to have separate location for a host and the code that runs inside
the continuation environment, but it eliminates a danger of having
two copies of the same class.
We should be able to achieve the same by
restricting the classloader to those
included packages. Don't you think?
I am not yet convinced that a separate
location is that convenient.
URLClassLoader isn't reusable for us, but I think we can start from
AntClassLoader.
Well ...if you really think that's
required. As long as it works... :)
cheers
--
Torsten
PGP.sig
Description: This is a digitally signed message part
Re: [javaflow] byte code instrumentation
I wonder if we can reduce this to just one, namely to Stack. Instead of remembering Thread-Continuation association, we can remember Thread-Stack association. We then replace Continuation.currentContinuation() with Stack.currentStack(), and we can also move relevant flags (like restoring/capturing) to a Stack object. This also has a nice side-effect of moving methods like isCapturing/ isRestoring to a non-API package. Today, those methods are defined as public methods of Continuation, as a part of the API class, even though they aren't supposed to be called by applications. In this way, we can also make the Continuation truly immutable. Does this sound reasonable? Well ...it does sound reasonable - except that isRestoring/isCapturing feels also a bit awkward inside the Stack class. Would have been nice to keep that one clean :-/ But on the other hand a clean Continuation interface and saving some instructions on the bytecode level does sound very tempting. ...we could also have a specialized Stack with those flags extending the basic Stack implementation. WDYT? cheers -- Torsten PGP.sig Description: This is a digitally signed message part
Betwixt - BeanWriter's indent question
Hello everybody, In org.apache.commons.betwixt.io.BeanWriter, I am wondering why the indentLevel starts at 1 with the first element. It makes the root element has indent too, which is ugly. Am I wrong or it has some purpose? -- Best Regards, Alex Ieong / xela.org / MO - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Questions concerning VariableFormatter
Hi,
I just found out that this project has exactly what I was searching for
long time because MessageFormat doesn't really suite my needs.
I see that this Class has been added in 2.2:
a. Is there any plan when 2.2 is released
b. What would be with adding formats applied to values like
MessageFormat does it {myDate,date,short}. The attached patch does that
simply using MessageFormat.
c. Are there any planned changes to VariableFormatter to make it more
look like MessageFormat?
Thanks
Tom
Index:
E:/eclipse-workspaces/beso-internal-devel/jakarta-lang/src/java/org/apache/commons/lang/text/VariableFormatter.java
===
---
E:/eclipse-workspaces/beso-internal-devel/jakarta-lang/src/java/org/apache/commons/lang/text/VariableFormatter.java
(revision 226795)
+++
E:/eclipse-workspaces/beso-internal-devel/jakarta-lang/src/java/org/apache/commons/lang/text/VariableFormatter.java
(working copy)
@@ -16,6 +16,7 @@
package org.apache.commons.lang.text;
+import java.text.MessageFormat;
import java.util.ArrayList;
import java.util.Iterator;
import java.util.List;
@@ -139,7 +140,14 @@
if (this.getMap() == null) {
return null;
}
-return this.getMap().get(varName);
+
+int index;
+
+if( (index = varName.indexOf(,)) != -1 ) {
+ return
MessageFormat.format({0+varName.substring(index)+},new Object[] {
this.getMap().get(varName.substring(0,index)) } );
+} else {
+ return this.getMap().get(varName);
+}
}
/**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [exec] Design of commons-exec
Jerome Lacoste wrote a proposal a couple months ago to the CruiseControl mailing list talking about the same basic idea. His proposal is here: http://www.coffeebreaks.org/blogs/?p=8. I will forward this thread to him as he might be very interested in contributing. At any rate, something like this in Jakarta Commons would be great, I know I am using at least three different implementations of the same basic functionality! Eric Pugh On Aug 1, 2005, at 7:04 PM, Kev Jackson wrote: This is a very short description of the cleaned up Ant exec task design: * Exec: the former Ant task class used to create and configure Execute instances. Now mainly a convience class for starting new Execute instances. * Execute: the main class for running one process. Handles creation and configuration of the necessary objects (stream pump, watchdog, process destroyer). Can wait for the full execution time to enable synchronous return of the process return code or spawn a process to run async. * Process destroyer: adds itself as a shutdown hook, Execute adds and removes created processes to ensure that they are correctly destroyed when the JVM stops. * WatchDog: used to time out a running process. After a given time has passed, the process is checked if it's still running and there after destroyed. * CommandLauncher: a family of classes for actually starting the processes. Implementations exist for e.g. Java 1.1, Java 1.3, WinNT, Mac, VMS and so on. These classes handles the platform specifics. * Environment: used to retrive the current environment as well as setting new environment variables. Reading the current environment is done using platform specific commands (e.g. cmd /c set, env, /bin/env) and parsing the result. This could of course be improved on J2SE 5.0 to use System.getenv() instead. * StreamPumper: used to read/write the three stream (in, out, error) simultaniously. * CommandLine: class for handling (e.g. parsing, quoting) command lines. It might be worth extracting the interface from Ant, creating an implementation (using the interface) and then using this in a branch of Ant just to test that we've extracted all the necessary functionality. IIRC Environment is really derived through JavaEnvUtils (though I'll have to check source). A common interface for a commandLine would allow us to create platform specific commandLines depending on environment 2c Kev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35983] New: - [pipeline] SimpleStageDriver does not stop the monitor
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=35983. 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=35983 Summary: [pipeline] SimpleStageDriver does not stop the monitor Product: Commons Version: Nightly Builds Platform: PC OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Sandbox AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] When a pipeline.start() is requested a stage driver should put the stage monitor in the RUNNING state and when the pipeline.finish() is requested, the stage driver should put the stage monitor in the STOPPED state. The SimpleStageDriver is not putting the monitor in the STOPPED state when pipeline.finish() is called. Attached is a patch to SimpleStageDriverTest, which when applied will cause test failures. Also attached is a patch to SimpleStageDriver which once applied, will cause the test to pass. -- 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 35983] - [pipeline] SimpleStageDriver does not stop the monitor
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=35983. 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=35983 --- Additional Comments From [EMAIL PROTECTED] 2005-08-02 21:50 --- Created an attachment (id=15856) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15856action=view) Patch to the unit test to show the problem. -- 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 35983] - [pipeline] SimpleStageDriver does not stop the monitor
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=35983. 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=35983 --- Additional Comments From [EMAIL PROTECTED] 2005-08-02 21:50 --- Created an attachment (id=15857) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15857action=view) Patch to fix the tests. -- 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: r227075 - in /jakarta/commons/proper/vfs/trunk: ./ src/java/org/apache/commons/vfs/provider/ftp/ src/java/org/apache/commons/vfs/provider/local/
Author: imario
Date: Tue Aug 2 13:09:42 2005
New Revision: 227075
URL: http://svn.apache.org/viewcvs?rev=227075view=rev
Log:
ftp: configuration to use user-home as root
file: build windows filename according to the documentation. e.g.
file:///c:/dir, file:unchost/uncshare
Added:
jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/local/WindowsFileName.java
(with props)
Modified:
jakarta/commons/proper/vfs/trunk/RELEASE_NOTES.txt
jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/ftp/FtpClientFactory.java
jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/ftp/FtpFileObject.java
jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/ftp/FtpFileSystem.java
jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/ftp/FtpFileSystemConfigBuilder.java
jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/local/WindowsFileNameParser.java
Modified: jakarta/commons/proper/vfs/trunk/RELEASE_NOTES.txt
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/vfs/trunk/RELEASE_NOTES.txt?rev=227075r1=227074r2=227075view=diff
==
--- jakarta/commons/proper/vfs/trunk/RELEASE_NOTES.txt (original)
+++ jakarta/commons/proper/vfs/trunk/RELEASE_NOTES.txt Tue Aug 2 13:09:42 2005
@@ -1,4 +1,10 @@
-2005-Jul-11
+2005-
+
+ftp:
+configuration to use user-home as root
+
+file:
+build windows filename according to the documentation. e.g. file:///c:/dir,
file:unchost/uncshare
smb:
now uses NtlmPasswordAuthentication for credentials passing
Modified:
jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/ftp/FtpClientFactory.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/ftp/FtpClientFactory.java?rev=227075r1=227074r2=227075view=diff
==
---
jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/ftp/FtpClientFactory.java
(original)
+++
jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/ftp/FtpClientFactory.java
Tue Aug 2 13:09:42 2005
@@ -87,7 +87,9 @@
// Change to root by default
// All file operations a relative to the filesystem-root
// String root = getRoot().getName().getPath();
-if (workingDirectory != null)
+
+Boolean userDirIsRoot =
FtpFileSystemConfigBuilder.getInstance().getUserDirIsRoot(fileSystemOptions);
+if (workingDirectory != null (userDirIsRoot == null ||
!userDirIsRoot.booleanValue()))
{
if (!client.changeWorkingDirectory(workingDirectory))
{
Modified:
jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/ftp/FtpFileObject.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/ftp/FtpFileObject.java?rev=227075r1=227074r2=227075view=diff
==
---
jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/ftp/FtpFileObject.java
(original)
+++
jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/ftp/FtpFileObject.java
Tue Aug 2 13:09:42 2005
@@ -66,7 +66,8 @@
{
// do not use the . as path against the ftp-server
// e.g. the uu.net ftp-server do a recursive listing then
-this.relPath = UriParser.decode(rootName.getPath());
+// this.relPath = UriParser.decode(rootName.getPath());
+this.relPath = ;
}
else
{
@@ -77,7 +78,7 @@
/**
* Called by child file objects, to locate their ftp file info.
*
- * @param name the filename in its native form ie. without uri stuff (%nn)
+ * @param name the filename in its native form ie. without uri stuff (%nn)
* @param flush recreate children cache
*/
private FTPFile getChildFile(final String name, final boolean flush)
throws IOException
@@ -477,6 +478,7 @@
client.abort();
close();
}
+
/**
* Called after the stream has been closed.
*/
Modified:
jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/ftp/FtpFileSystem.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/ftp/FtpFileSystem.java?rev=227075r1=227074r2=227075view=diff
==
---
jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/ftp/FtpFileSystem.java
(original)
+++
DO NOT REPLY [Bug 35848] - [VFS] URI of LocalFile contains second slash after scheme
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=35848. 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=35848 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-08-02 22:13 --- Thanks! I decided to fix it according to the documentation which uses the url form of the file: scheme. e.g. file:///c:/dir or for unc file:host/share -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] remove bogus commons-cli jar from repository
On Tue, 2005-08-02 at 11:35 +1000, Brett Porter wrote: Thanks Robert! I have updated commons-cli.pom cheers and updated the md5 to fix a parse error what was the problem with the md5? - so if you notice that change, don't worry - it's not gremlins again :) cool :) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Betwixt - BeanWriter's indent question
On Wed, 2005-08-03 at 02:06 +0800, Alex Ieong wrote: Hello everybody, In org.apache.commons.betwixt.io.BeanWriter, I am wondering why the indentLevel starts at 1 with the first element. It makes the root element has indent too, which is ugly. Am I wrong or it has some purpose? if it had some purpose, it is lost in the depths of time... why not contribute a patch to apache that allows this value to be configured? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Simon Kitching wrote: [AARGH - I hate top-posting!] mmh, whatever you may mean with that (I am not a native englishman)... I'm not opposed to this proposal. Commons-logging already creates a proxy Log object for each underlying real logger object, so at the worst the name can be remembered at the Log object level as far as I can see. In other words, this functionality should be possible to implement whatever the underlying logging library. And I'm generally convinced by the emails to this thread that all reasonable logging libraries provide a way for logging objects to return their name anyway. I don't personally have any need for this feature, but it seems that people with reasonable credentials do. So overall I'm in favour of some kind of implementation of this feature. Commons-logging needs to be *very* careful about adding features to its API but this seems to me like one that passes the necessary tests. If you were to create a bugzilla entry with an implementation of this feature and supporting unit tests [and assuming no-one else votes against it] I will review and commit it sometime in the next few weeks. Note, however, that commons-logging isn't making much progress at the moment, and several issues standing in the way of a new release. So there's no guarantee of when the next release might actually be pushed out. Great! This sounds like an option. I wouldn't mind making the bugzilla entry and writing junit tests. Maybe the two Joergs (and whoever likes this proposal) may get together doing this. Just let me know if I get it right: We add a new interface called Logger that extends Log. That is going to have two additional methods String getName() Logger getChildLogger(String) Is that right? You would also like me to send patches for the exisitng implementations so they implement Logger instead of Log? Further I leave things like LogFactory untouched. So whoever wants to have these two additional methods may cast from Log to Logger if he uses the LogFactory. Is that the right way to keep things easy and have no trouble with compatibility? Regards, Simon PS: Two Joerg Schaibles? How confusing! My name is Jörg Hohwiller. Thanks a lot so far! Best regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC79+DmPuec2Dcv/8RAkFEAJ94K8fuHQ9AGZFYYU5UaS4Pa84LKACfUTLS VYxV1hwFN3l+p0RQL3IZBKc= =LeNN -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VFS] Native File System Integration (resending)
Hi, Is there any Java based solution for mounting any file resourse (cifs, zip, etc.) to a drive on Windows and to any where in UNIX? I know, this is not directly related to Commons VFS. One more question that is related to Commons VFS and my previos question is: Is there any Java and Commons VFS based solution for mounting Commons VFS resource to the native file system? If this could be done than all the applications using Commons VFS directly benefit from native file system integration. Cheers, -- Ersin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [logging] proposal
On Tue, 2005-08-02 at 20:00 +1200, Simon Kitching wrote: [AARGH - I hate top-posting!] I'm not opposed to this proposal. Commons-logging already creates a proxy Log object for each underlying real logger object, so at the worst the name can be remembered at the Log object level as far as I can see. In other words, this functionality should be possible to implement whatever the underlying logging library. And I'm generally convinced by the emails to this thread that all reasonable logging libraries provide a way for logging objects to return their name anyway. I don't personally have any need for this feature, but it seems that people with reasonable credentials do. So overall I'm in favour of some kind of implementation of this feature. Commons-logging needs to be *very* careful about adding features to its API but this seems to me like one that passes the necessary tests. If you were to create a bugzilla entry with an implementation of this feature and supporting unit tests [and assuming no-one else votes against it] I will review and commit it sometime in the next few weeks. i see no reason (so far) to veto :) i've been thinking for a few months now that the long term solution to the difficulties associated with bridging APIs might be a logging specification (*not* an implementation which is IMHO where we've been going wrong). this would take ceki's static binding to another level: the specification should describe only a logging API with all the discovery and so on left entirely to the implementation. retrofitting this to JCL would allow slf4j to replace JCL (and the opposite) by just replacing the jars in the classpath. it would also provide a very clean way for JCL to provide specific implementations for specific purposes. given the backing of the JCL committers and the slf4j subscribers, i really think that this approach would stand a good chance of creating sufficient momentum to unify the various bridges out there. i've been thinking of posting a proposal to slf4j (but had been considering waiting until the slf4j interface was more mature). opinions welcomed i'd also be very interested to hear what the experts on the slf4j make of these ideas. Jörg and/or joerg: want to volunteer to raise it? Note, however, that commons-logging isn't making much progress at the moment, and several issues standing in the way of a new release. So there's no guarantee of when the next release might actually be pushed out. i hope to have a bit more time now but i've now lost track of where we are - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] remove bogus commons-cli jar from repository
robert burrell donkin wrote: On Tue, 2005-08-02 at 11:35 +1000, Brett Porter wrote: Thanks Robert! I have updated commons-cli.pom cheers and updated the md5 to fix a parse error what was the problem with the md5? sorry, what I meant was that I updated the POM to fix a parse error, and updated the md5 accordingly :) - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Robert, robert burrell donkin wrote: [cut.] i see no reason (so far) to veto :) :) i've been thinking for a few months now that the long term solution to the difficulties associated with bridging APIs might be a logging specification (*not* an implementation which is IMHO where we've been going wrong). I am on your side. this would take ceki's static binding to another level: the specification should describe only a logging API with all the discovery and so on left entirely to the implementation. retrofitting this to JCL would allow slf4j to replace JCL (and the opposite) by just replacing the jars in the classpath. it would also provide a very clean way for JCL to provide specific implementations for specific purposes. given the backing of the JCL committers and the slf4j subscribers, i really think that this approach would stand a good chance of creating sufficient momentum to unify the various bridges out there. i've been thinking of posting a proposal to slf4j (but had been considering waiting until the slf4j interface was more mature). opinions welcomed i'd also be very interested to hear what the experts on the slf4j make of these ideas. Jörg and/or joerg: want to volunteer to raise it? [cut] i hope to have a bit more time now but i've now lost track of where we are - robert just to get it right: Is JCL = Jakarta Commons Logging? lf4j is the Simple Logging Facade for Java and ceki the founder and they have http://www.slf4j.org/api/org/slf4j/Logger.html which is very similar to http://jakarta.apache.org/commons/logging/api/org/apache/commons/logging/Log.html slf4j seems to have two loglevels less than commons-logging (trace and fatal). I personaly would miss these levels a lot! Hope thats all correct. Anyways your suggestion was to bring the ideas of both projects together and have one Log(ger) interface (and maybe do not waste performance by adapters), is that correct? Maybe there was a lot more behind this but I am not too deep in that to get it. Well good idea if there are chances to make this happen. Even cooler would be if that API would go as JSR into the JDK, wow! But, mmh besides all my enthusiasm that is not going to be the next step esp. after the exisiting jdk logger :) For me the first step was to have these extension method to commons-logging and make it fill the needs of the joergs and many other people out there. I would not mind involving the slf4j community but cross-discussions on different mailing lists is not to easy to track and I would not like to loose the focus on this one. But I will subscribe to slf4j list and invite them to come into this discussion. Does that somehow match a little of your intention. (I better wait for response). Take care Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC7/jdmPuec2Dcv/8RAjV3AJwJQ67JVX6vqp4iKOdwW06CeacDJgCeJOez WBPy59BZ1xRPKYMS7iIgpQU= =A5HE -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta-commons Wiki] Update of Lang by StephenColebourne
Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta-commons Wiki for change notification. The following page has been changed by StephenColebourne: http://wiki.apache.org/jakarta-commons/Lang The comment on the change is: Update for 2.2 -- Development plan for 2.2 + 1. Bug fixes + 1. StrTokenizer + 1. StrBuilder + 1. VariableFormatter/interpolator - [http://issues.apache.org/bugzilla/show_bug.cgi?id=18962 18962] - Release the text package and bug fixes. - - Seeking opinions (2.1) - - 1. [http://issues.apache.org/bugzilla/show_bug.cgi?id=22692 22692] StringUtils.split ignores empty items - '''new splitPreserveAllTokens Needs to be reviewed.''' - 1. [http://issues.apache.org/bugzilla/show_bug.cgi?id=24910 24910] new StringUtils.split methods that split on the whole separator string - '''committed as splitByWholeSeparator''' - 1. [http://issues.apache.org/bugzilla/show_bug.cgi?id=15082 15082] [lang] elapsed time formatting utility method - '''DurationFormatUtils.''' - 1. DateUtils.isSameDay() - 1. DurationUtils ISO_EXTENDED_FORMAT uses FastDateFormat. This has problems with padding of years. See commented TODO in DurationFormatUtils. - '''No longer uses FastDateFormat. Instead it uses the DurationFormatUtils format code, of which a new variant has been added''' - === Pushed back (2.1) === + === Other ideas === 1. [http://issues.apache.org/bugzilla/show_bug.cgi?id=21663 21663] [lang] Add support in ToStringStyle for DateFormat. - '''Grows quickly into commons-convert''' 1. [http://issues.apache.org/bugzilla/show_bug.cgi?id=27643 27643] [lang][patch] ClassUtils.newInstance method - '''Seems unnecessary''' 1. [http://issues.apache.org/bugzilla/show_bug.cgi?id=29149 29149] [lang] StringEscapeUtils.unescapeHtml() doesn't handle an empty entity - '''Empty entity is in fact illegal HTML, so need to decide if we should ignore. Current behaviour seems acceptable as we're not in the work with bad HTML market.''' - 1. StringBuffer replacement - '''Probably 2.2/3.0. A lot of work in this I'd imagine. ''' 1. [http://issues.apache.org/bugzilla/show_bug.cgi?id=26659 26659] [lang] add method to DateUtils to get the distance between 2 dates - '''Mainly replicated by DurationFormatUtils, or non-obvious''' 1. [http://issues.apache.org/bugzilla/show_bug.cgi?id=29692 29692] [lang] String indentation feature request - '''Needs design as a non-simple problem''' 1. [http://issues.apache.org/bugzilla/show_bug.cgi?id=22172 22172] [lang] DateUtils.parseCVS behavior parsing h:mm z - '''Moved to sandbox''' 1. [http://issues.apache.org/bugzilla/show_bug.cgi?id=26297 26297] [lang] BitSetUtils class, toIndexArray and fromIndexArray - 1. [http://issues.apache.org/bugzilla/show_bug.cgi?id=26922 26922] [lang] public static boolean DateUtils.equals(Date dt1, Date dt2) 1. [http://issues.apache.org/bugzilla/show_bug.cgi?id=21333 21333] Add TimeoutController - '''Class in HttpClient. Leaving til 3.0 as not much movement on it''' 1. [http://issues.apache.org/bugzilla/show_bug.cgi?id=30674 30674] Support HttpClient's DateParser class - '''This is basically a Date parseDate(String dateValue, String[] dateFormats) method. ''' + 1. LocaleUtils - including toLocale(String,String) + 1. CloneUtils - multiple ways to clone an object - 1. [http://issues.apache.org/bugzilla/show_bug.cgi?id=15082 15082] [lang] elapsed time formatting utility method - '''DurationFormatUtils. Needs finishing.''' - 1. New text package with Interpolation class moved there and MappedMessageFormat from code in Digester. - 1. [http://issues.apache.org/bugzilla/show_bug.cgi?id=18962 18962] [lang] New Method: getSubstitutedValues( String, Map ) - '''org.apache.commons.lang.text.Interpolation available for opinions''' - - === Resolved list (2.1) === - - 1. [http://issues.apache.org/bugzilla/show_bug.cgi?id=30929 30929] [lang] Nestable.indexOfThrowable(Class)uses Class.equals() to match - '''DONE''' - 1. [http://issues.apache.org/bugzilla/show_bug.cgi?id=27592 27592] [lang] WordUtils capitalize improvement - '''DONE''' - 1. [http://issues.apache.org/bugzilla/show_bug.cgi?id=23557 23557] WordUtils.capitalizeFully(String str) should take a delimiter - '''DONE''' - 1. [http://issues.apache.org/bugzilla/show_bug.cgi?id=27778 27778] [lang] add remove methods to ArrayUtils - '''DONE''' - 1. StringTokenizer replacement: '''(DONE - Tokenizer)''' - 1. [http://issues.apache.org/bugzilla/show_bug.cgi?id=25227 25227] [lang] StringEscapeUtils.unescapeHtml() doesn't handle hex entities - '''DONE''' - 1. [http://issues.apache.org/bugzilla/show_bug.cgi?id=27640 27640] [lang][patch] ClassUtils.primitivesToWrappers method - '''DONE''' - 1. [http://issues.apache.org/bugzilla/show_bug.cgi?id=23749 23749] [lang] [PATCH]
[net] looking for solution to FTPClient hang on zOS (m/f platform )
for a week or so i've been investigating the hang during connect when running commons-net.1.4.0 ftpclient on zOS, connecting to Unix ftpd. skunking round led me to Bugzilla 31108 [net] FTP does not work on zos (ebcdic platform). i don't think that's my exact issue but i now suspect my problem is with the sequence \r\n. observing, via some debug, the line coming back from connect terminating only in '\r' and not \r\n, i modified the file FromNetASCIIInputStream.java, changing: _lineSeparator = System.getProperty(line.separator); to _lineSeparator = \r; and connect completed ! can someone explain what's busted here. is the line.separator property not configured correctly in my zOS environ ? thanks, lew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [javaflow] class loader
Torsten Curdt wrote:
I noticed that in ContinuationClassLoader you aren't actually using
the marker interface to decide what to instrument any more. Is this
by design? I also noticed a similar comment in the TODO file.
Yes, I am no big fan of empty marker interfaces.
I'd prefer a configuration approach.
If so, I can remove the Continuable interface.
Sure
OK.
I still see some value in retaining the ContinuationCapable
interface, as this seems to be something we can use for detecting
errors at runtime. But since ContinuationCapable doesn't need to be
visible to users, I wonder if we can move it to the bytecode
subpackage.
Makes sense, too ...maybe *that* interface
should be called Continuable then. WDYT?
Will make that change, too.
Another thing about ContinuationClassLoader. Right now this class
is hard-coded to recognize the javaflow test packages, but this
needs to be parameterized.
Yes, that needs to change
Also, in JUnit, the list of excluded packages can be read from a
data file [1]. I suggest we implement something like that. I don't
think it makes sense for this file to be a property file, so I
think we can just read this as an UTF-8 encoded text file where
each line specifies a new mask. Let me know how you think about me
making those changes.
Not sure how...that's why I haven't done
it yet. I'd rather like to use a more
sophisticated configuration approach.
Usually I love the configuration classes
from Avalon ...but I don't want to have
that dependency.
..question is also how it can be handled
when the classloader is being used as
system classloader.
I don't think we can even install ContinuationClassLoader as the system
class loader. I thought the system class loader is set up by JVM before
any Java code runs.
BTW, I found this JUnit implementation interesting. It doesn't seem
to exclude any of the java.* or org.w3c.*, but it must be clearly
working.
But it does...
private String[] excludeFromLoading = {
java.,
javax.,
sun.,
org.xml.,
org.w3c.,
org.apache.commons.logging
};
..only the compiling one does not because
it's using parent-last delegation and the
repository of classes is restricted to the
user's classes.
No, I meant that the JUnit TestCaseClassLoader doesn't have an exclusion
list like you have in ContinuationClassLoader. That must mean that
somehow the explicit exclusion code isn't necessary for things to work
correctly. I was wondering why.
For this reason, I wonder if we can have another ClassLoader that
works more like a traditional URLClassLoader --- you tell it a set
of locations to look at, then the class loader loads a class file
from it with byte-code instrumentation. This requires a developer
to have separate location for a host and the code that runs inside
the continuation environment, but it eliminates a danger of having
two copies of the same class.
We should be able to achieve the same by
restricting the classloader to those
included packages. Don't you think?
I am not yet convinced that a separate
location is that convenient.
In the scenario I explained in the previous e-mail, the benefit that the
separate location brings is that you get NoClassDefError for Y instead
of strange ClassCastException trying to cast Y' into Y.
NoClassDefError tends to happen a lot earlier than ClassCastException,
and it's usually easier for people to grok.
URLClassLoader isn't reusable for us, but I think we can start from
AntClassLoader.
Well ...if you really think that's
required. As long as it works... :)
I think I'll implement it, because I need it anyway. If eventually you
decide that you don't like it, we can talk.
--
Kohsuke Kawaguchi
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [javaflow] byte code instrumentation
Torsten Curdt wrote: Well ...it does sound reasonable - except that isRestoring/isCapturing feels also a bit awkward inside the Stack class. Would have been nice to keep that one clean :-/ But on the other hand a clean Continuation interface and saving some instructions on the bytecode level does sound very tempting. ..we could also have a specialized Stack with those flags extending the basic Stack implementation. WDYT? OK. we'll keep the current Stack class intact and extend it. We won't be using the basic Stack implementation by itself, but rather we'll be always using the extended Stack class. So the distinction seems bit odd, but I see why you'd want to do it. It's also very easy to merge those two classes into one later if we want to do so. -- Kohsuke Kawaguchi Sun Microsystems [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
[lang][patch] More tests and fixes for StrBuilder
Here's some more tests and fixes for StrBuilder. This should hopefully
test all methods in StrBuilder now, but may not get all the edge cases.
Index: src/test/org/apache/commons/lang/text/StrBuilderTest.java
===
--- src/test/org/apache/commons/lang/text/StrBuilderTest.java (revision
227120)
+++ src/test/org/apache/commons/lang/text/StrBuilderTest.java (working copy)
@@ -375,6 +375,8 @@
assertEquals(ddbbcc, sb.toString());
sb.replace('a', 'd');
assertEquals(ddbbcc, sb.toString());
+sb.replace('d', 'd');
+assertEquals(ddbbcc, sb.toString());
}
/**
@@ -394,6 +396,18 @@
assertEquals(ddbbcc, sb.toString());
}
+public void testReplaceIntIntStrBuilder() {
+StrBuilder sb = new StrBuilder(abc);
+sb.replace(0, 1, new StrBuilder (d));
+assertEquals(dbc, sb.toString());
+sb.replace(0, 1, new StrBuilder (aaa));
+assertEquals(aaabc, sb.toString());
+
+sb = new StrBuilder(aabbcc);
+sb.replace(0, 2, new StrBuilder(d));
+assertEquals(dbbcc, sb.toString());
+}
+
public void testSetCharAt() {
StrBuilder sb = new StrBuilder();
try {
@@ -435,6 +449,7 @@
assertTrue(sb.startsWith(a));
assertTrue(sb.startsWith(ab));
assertTrue(sb.startsWith(abc));
+assertFalse(sb.startsWith(cba));
}
public void testEndsWith() {
@@ -452,6 +467,7 @@
assertTrue(sb.endsWith(c));
assertTrue(sb.endsWith(bc));
assertTrue(sb.endsWith(abc));
+assertFalse(sb.endsWith(cba));
assertFalse(sb.endsWith(abcd));
assertFalse(sb.endsWith( abc));
assertFalse(sb.endsWith(abc ));
@@ -1493,4 +1509,84 @@
assertEquals (2, sb.lastIndexOf(za, sb.length()));
assertEquals (-1, sb.lastIndexOf(za, 1));
}
+
+public void testContainsChar() {
+StrBuilder sb = new StrBuilder(abcdefghijklmnopqrstuvwxyz);
+assertTrue (sb.contains('a'));
+assertTrue (sb.contains('o'));
+assertTrue (sb.contains('z'));
+assertFalse (sb.contains('1'));
+}
+
+public void testContainsString() {
+StrBuilder sb = new StrBuilder(abcdefghijklmnopqrstuvwxyz);
+assertTrue (sb.contains(a));
+assertTrue (sb.contains(pq));
+assertTrue (sb.contains(z));
+assertFalse (sb.contains(zyx));
+}
+
+public void testMidString() {
+StrBuilder sb = new StrBuilder(hello goodbye hello);
+assertEquals (goodbye, sb.midString(6, 7));
+assertEquals (hello, sb.midString(0, 5));
+assertEquals (hello, sb.midString(-5, 5));
+assertEquals (, sb.midString(0, -1));
+assertEquals (, sb.midString(20, 2));
+}
+
+public void testRightString() {
+StrBuilder sb = new StrBuilder(left right);
+assertEquals (right, sb.rightString(5));
+assertEquals (, sb.rightString(0));
+assertEquals (, sb.rightString(-5));
+assertEquals (left right, sb.rightString(15));
+}
+
+public void testLeftString() {
+StrBuilder sb = new StrBuilder(left right);
+assertEquals (left, sb.leftString(4));
+assertEquals (, sb.leftString(0));
+assertEquals (, sb.leftString(-5));
+assertEquals (left right, sb.leftString(15));
+}
+
+public void testSubstringInt() {
+StrBuilder sb = new StrBuilder (hello goodbye);
+assertEquals (goodbye, sb.substring(6));
+assertEquals (hello goodbye.substring(6), sb.substring(6));
+assertEquals (hello goodbye, sb.substring(0));
+assertEquals (hello goodbye.substring(0), sb.substring(0));
+try {
+sb.substring(-1);
+fail ();
+} catch (StringIndexOutOfBoundsException e) {}
+
+try {
+sb.substring(15);
+fail ();
+} catch (StringIndexOutOfBoundsException e) {}
+
+}
+
+public void testSubstringIntInt() {
+StrBuilder sb = new StrBuilder (hello goodbye);
+assertEquals (hello, sb.substring(0, 5));
+assertEquals (hello goodbye.substring(0, 6), sb.substring(0, 6));
+
+assertEquals (goodbye, sb.substring(6, 13));
+assertEquals (hello goodbye.substring(6,13), sb.substring(6, 13));
+
+assertEquals (goodbye, sb.substring(6, 20));
+
+try {
+sb.substring(-1, 5);
+fail();
+} catch (StringIndexOutOfBoundsException e) {}
+
+try {
+sb.substring(15, 20);
+fail();
+} catch (StringIndexOutOfBoundsException e) {}
+}
}
Index: src/java/org/apache/commons/lang/text/StrBuilder.java
===
--- src/java/org/apache/commons/lang/text/StrBuilder.java
svn commit: r227149 - in /jakarta/commons/proper/lang/trunk/src: java/org/apache/commons/lang/text/StrBuilder.java test/org/apache/commons/lang/text/StrBuilderTest.java
Author: ggregory
Date: Tue Aug 2 19:50:53 2005
New Revision: 227149
URL: http://svn.apache.org/viewcvs?rev=227149view=rev
Log:
Fixes and better unit test code coverage from Nathan Beyer [EMAIL PROTECTED]
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/StrBuilder.java
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/text/StrBuilderTest.java
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/StrBuilder.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/StrBuilder.java?rev=227149r1=227148r2=227149view=diff
==
---
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/StrBuilder.java
(original)
+++
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/StrBuilder.java
Tue Aug 2 19:50:53 2005
@@ -1058,12 +1058,15 @@
public StrBuilder replace(int startIndex, int endIndex, StrBuilder
builder) {
endIndex = validateRange(startIndex, endIndex);
int insertLen = builder.length();
-int removeLen = endIndex = startIndex;
+int removeLen = endIndex - startIndex;
if (insertLen removeLen) {
ensureCapacity(size - removeLen + insertLen);
}
if (insertLen != removeLen) {
+//shift the current characters to the right
System.arraycopy(buf, endIndex, buf, startIndex + insertLen, size
- endIndex);
+//adjust the size accordingly
+size += (insertLen - removeLen);
}
builder.getChars(0, insertLen, buf, startIndex);
return this;
@@ -1233,7 +1236,7 @@
} else if (length = size) {
return new String(buf, 0, size);
} else {
-return new String(buf, size - length, size);
+return new String(buf, size - length, length);
}
}
Modified:
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/text/StrBuilderTest.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/text/StrBuilderTest.java?rev=227149r1=227148r2=227149view=diff
==
---
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/text/StrBuilderTest.java
(original)
+++
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/text/StrBuilderTest.java
Tue Aug 2 19:50:53 2005
@@ -375,6 +375,8 @@
assertEquals(ddbbcc, sb.toString());
sb.replace('a', 'd');
assertEquals(ddbbcc, sb.toString());
+sb.replace('d', 'd');
+assertEquals(ddbbcc, sb.toString());
}
/**
@@ -394,6 +396,18 @@
assertEquals(ddbbcc, sb.toString());
}
+public void testReplaceIntIntStrBuilder() {
+StrBuilder sb = new StrBuilder(abc);
+sb.replace(0, 1, new StrBuilder (d));
+assertEquals(dbc, sb.toString());
+sb.replace(0, 1, new StrBuilder (aaa));
+assertEquals(aaabc, sb.toString());
+
+sb = new StrBuilder(aabbcc);
+sb.replace(0, 2, new StrBuilder(d));
+assertEquals(dbbcc, sb.toString());
+}
+
public void testSetCharAt() {
StrBuilder sb = new StrBuilder();
try {
@@ -435,6 +449,7 @@
assertTrue(sb.startsWith(a));
assertTrue(sb.startsWith(ab));
assertTrue(sb.startsWith(abc));
+assertFalse(sb.startsWith(cba));
}
public void testEndsWith() {
@@ -452,6 +467,7 @@
assertTrue(sb.endsWith(c));
assertTrue(sb.endsWith(bc));
assertTrue(sb.endsWith(abc));
+assertFalse(sb.endsWith(cba));
assertFalse(sb.endsWith(abcd));
assertFalse(sb.endsWith( abc));
assertFalse(sb.endsWith(abc ));
@@ -1492,5 +1508,85 @@
sb = new StrBuilder(xyzabc);
assertEquals (2, sb.lastIndexOf(za, sb.length()));
assertEquals (-1, sb.lastIndexOf(za, 1));
+}
+
+public void testContainsChar() {
+StrBuilder sb = new StrBuilder(abcdefghijklmnopqrstuvwxyz);
+assertTrue (sb.contains('a'));
+assertTrue (sb.contains('o'));
+assertTrue (sb.contains('z'));
+assertFalse (sb.contains('1'));
+}
+
+public void testContainsString() {
+StrBuilder sb = new StrBuilder(abcdefghijklmnopqrstuvwxyz);
+assertTrue (sb.contains(a));
+assertTrue (sb.contains(pq));
+assertTrue (sb.contains(z));
+assertFalse (sb.contains(zyx));
+}
+
+public void testMidString() {
+StrBuilder sb = new StrBuilder(hello goodbye hello);
+assertEquals (goodbye, sb.midString(6, 7));
+assertEquals (hello, sb.midString(0, 5));
+assertEquals (hello, sb.midString(-5, 5));
+assertEquals (,
RE: [lang][patch] More tests and fixes for StrBuilder
Patches applied, thanks again to Nathan. This brings StrBuilder coverage from 86.8% to 95.4%. All StrBuilder methods are now tested but there are a couple of code paths that are not. See the Clover report from a local Maven build for details. Thanks, Gary -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 02, 2005 7:20 PM To: Jakarta Commons Developers List Subject: [lang][patch] More tests and fixes for StrBuilder Here's some more tests and fixes for StrBuilder. This should hopefully test all methods in StrBuilder now, but may not get all the edge cases. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r227156 - /jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/text/StrBuilderTest.java
Author: ggregory
Date: Tue Aug 2 21:23:16 2005
New Revision: 227156
URL: http://svn.apache.org/viewcvs?rev=227156view=rev
Log:
Coverage of StrBuilder#delete(String)
Modified:
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/text/StrBuilderTest.java
Modified:
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/text/StrBuilderTest.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/text/StrBuilderTest.java?rev=227156r1=227155r2=227156view=diff
==
---
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/text/StrBuilderTest.java
(original)
+++
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/text/StrBuilderTest.java
Tue Aug 2 21:23:16 2005
@@ -122,6 +122,10 @@
assertEquals(abc,sb.toString());
sb.delete('a');
assertEquals(bc,sb.toString());
+sb.delete('c');
+assertEquals(b,sb.toString());
+sb.delete('b');
+assertEquals(,sb.toString());
}
public void testDeleteIntInt() {
@@ -138,10 +142,18 @@
public void testDeleteString() {
StrBuilder sb = new StrBuilder(abc);
+sb.delete(null);
+assertEquals(abc,sb.toString());
+sb.delete();
+assertEquals(abc,sb.toString());
sb.delete(X);
assertEquals(abc,sb.toString());
sb.delete(a);
assertEquals(bc,sb.toString());
+sb.delete(c);
+assertEquals(b,sb.toString());
+sb.delete(b);
+assertEquals(,sb.toString());
}
public void testDeleteCharAt() {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Progress on JCL (WAS [logging] proposal)
--- robert burrell donkin [EMAIL PROTECTED] wrote: On Tue, 2005-08-02 at 20:00 +1200, Simon Kitching wrote: Note, however, that commons-logging isn't making much progress at the moment, and several issues standing in the way of a new release. So there's no guarantee of when the next release might actually be pushed out. i hope to have a bit more time now but i've now lost track of where we are Been in China with only a dial-up connection that was so slow as to make following this list impossible. Hope to be a little more active now that I'm back (can't be any less active than I have been). But, have also lost track of where we are). Changing jobs in a couple weeks; after a month hope to have much more time to help out. -- Brian __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35989] New: - BeanUtilsBean: Value into scalar section
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=35989. 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=35989 Summary: BeanUtilsBean: Value into scalar section Product: Commons Version: unspecified Platform: All OS/Version: Windows 2000 Status: NEW Keywords: APIBug Severity: normal Priority: P2 Component: Bean Utilities AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Hi, I 'm using a map-backed property to get the data from a run-time generated form. If one of the controls in the form is a multi-select, I only get the first selected option, even though I have selected multiple values from the select list. For ActionForm, I'm using a map-backed action form and the bean reference in the map-backed action form is an instance of LazyDynaBean. As I de-bugged I figured out that when Struts tries to populate the values of the multi-select into the LazyDynaBean instance, only the first item in the selected list is used because it the way BeanUtilsBean class has been coded. Can this be rectified to accpet the entier array instead of **only the first element in the array** I'm using the commons-beanutils1.7 version, the line number where the above mentioned situation occurs is at 1004. Hope I have provided you with enough info, if you need more, I will be glad to assist you. regards, Sriram -- 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 35774] - [logging] TCCL problem in J2EE Container
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=35774. 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=35774 --- Additional Comments From [EMAIL PROTECTED] 2005-08-03 07:24 --- I haven't had a chance to fully digest this thread, so please forgive me if I'm way off base. In the specific scenario Michael described, JCL is available in a classloader that is a common parent of both apps involved in the Inter-App call. If the webapp deployed commons-logging-adapters.jar instead of the full commons-logging.jar there should be no Log incompatibility problems nor any memory leak. The logging would end up going to the loggers associated with the TCCL, which may or may not be the desired behavior. But that seems more like a problem with ensuring the TCCL is properly set when a thread crosses an app boundary and not something JCL can fix. (e.g. it seems to me that if a thread spawned by a timer service calls into an MBean, the TCCL should be set to the MBean's classloader before the call is made). What I'm suggesting of course wouldn't work if JCL wasn't available in a shared classloader, so I don't mean to imply some of the ideas raised on this thread are unneeded. But a commons-logging-adapters.jar approach might be a good workaround for the issue Michael specifically raised. (Such a jar doesn't exist in JCL 1.0.4, the latest official release, but it's simple enough to create one by taking commons-logging.jar and removing all classes found in commons-logging-api.jar). -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35774] - [logging] TCCL problem in J2EE Container
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=35774. 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=35774 --- Additional Comments From [EMAIL PROTECTED] 2005-08-03 07:42 --- 1. The J2EE Spec does not specify which classloader the TCCL should contains. only that it should be there. 2. Most AppServers won't have JCL in the common-classloader, jboss is the exception I would say. The common classloader there contains way to much. jboss seems to ignore the TCCL most of the time. It all comes down to the fact that we cannot know what the TCCL contains at a given time. Because it is not defined! I had this problem now in: - jmx-console calling mbean with Web TCCL - jmx-console calling mbean calling ejb with Web TCCL in the ejbCreate call!!! - instantiation of ManagedConnectionFactory/ManagedConnection (JCA) by jboss JCA Pool Loader with jboss TCCL Of course this is all in jboss, but as it is defined nowhere (at least I couldn't find it) I consider TCCL not reliable!! And many more. I changed the 1.0.4 commons-logging the way it is described in my patch and replaced it in jboss and all other apps. Now it works as expected. -- 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]
