DO NOT REPLY [Bug 34204] - [configuration] XMLConfiguration ignore a specific encoding in XML declaration
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=34204. 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=34204 --- Additional Comments From [EMAIL PROTECTED] 2005-04-13 10:53 --- Thank you for the feedback. I leave this bug open until I commit a test case covering this issue. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project commons-jelly-tags-xml (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-xml has an issue affecting its community integration. This issue affects 12 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-define : Commons Jelly - commons-jelly-tags-html : Commons Jelly - commons-jelly-tags-http : Commons Jelly - commons-jelly-tags-jaxme : Commons Jelly - commons-jelly-tags-jetty : Commons Jelly - commons-jelly-tags-jface : Commons Jelly - commons-jelly-tags-jsl : Commons Jelly - commons-jelly-tags-swing : Commons Jelly - commons-jelly-tags-xml : Commons Jelly - commons-jelly-tags-xmlunit : Commons Jelly - maven : Project Management Tools - maven-bootstrap : Project Management Tools Full details are available at: http://brutus.apache.org/gump/public/commons-jelly/commons-jelly-tags-xml/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-xml-13042005.jar] identifier set to project name -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-reports -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/commons-jelly/commons-jelly-tags-xml/gump_work/build_commons-jelly_commons-jelly-tags-xml.html Work Name: build_commons-jelly_commons-jelly-tags-xml (Type: Build) Work ended in a state of : Failed Elapsed: 13 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-13042005.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-13042005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-13042005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-13042005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-13042005.jar - [mkdir] Created dir: /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/classes java:compile: [echo] Compiling to /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/classes [echo] == NOTE: Targetting JVM 1.4, classes will not run on earlier JVMs == [javac] Compiling 16 source files to /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/classes java:jar-resources: test:prepare-filesystem: [mkdir] Created dir: /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes [mkdir] Created dir: /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/test-reports test:test-resources: Copying 36 files to /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes test:compile: [javac] Compiling 4 source files to /home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes test:test: [junit] Running org.apache.commons.jelly.tags.xml.TestImport [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.996 sec [junit] Running org.apache.commons.jelly.tags.xml.TestJelly [junit] foosome text [junit] exists = true, readable = true, class=java.io.File [junit] [junit] Tests run: 15, Failures: 0, Errors: 13, Time elapsed: 0.522 sec [junit] [ERROR] TEST org.apache.commons.jelly.tags.xml.TestJelly FAILED [junit] Running org.apache.commons.jelly.tags.xml.TestParser [junit] Tests run: 1, Failures: 0, Errors:
DO NOT REPLY [Bug 34436] New: - allow to set headerEncoding to other than platform default encoding for fall-back
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=34436. 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=34436 Summary: allow to set headerEncoding to other than platform default encoding for fall-back Product: Commons Version: unspecified Platform: Other OS/Version: other Status: NEW Severity: enhancement Priority: P2 Component: File Upload AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] it happens often that headers do not have an encoding. Also in J2EE containers, there may be multiple web applications running, so it may not be permitted change the platform encoding. Therefore, it should be possible to change the default for org.apache.commons.fileupload.MultipartStream without altering the System.getProperty(file.encoding). -- 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 34436] - allow to set headerEncoding to other than platform default encoding for fall-back
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=34436. 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=34436 --- Additional Comments From [EMAIL PROTECTED] 2005-04-13 15:07 --- Created an attachment (id=14702) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14702action=view) MultipartStream.java.patch To have this effective, after loading, an init() must set the org.apache.commons.fileupload.MultipartStream.headerEncodingDefault --- since this is static, this obviously only works if the fileUpload.jar is not shared between the web-apps. see also Bug 34291 -- 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 24765] - The current code assumes the platforms default encoding is iso-8859-1
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=24765. 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=24765 --- Additional Comments From [EMAIL PROTECTED] 2005-04-13 15:08 --- see also Bug 34436 -- 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 34437] New: - commons logging 1.0.4 does not use log4j 1.3 trace methods
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=34437.
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=34437
Summary: commons logging 1.0.4 does not use log4j 1.3 trace
methods
Product: Commons
Version: 1.0.4
Platform: Other
OS/Version: other
Status: NEW
Severity: normal
Priority: P3
Component: Logging
AssignedTo: commons-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
Jakarta Commons Logging 1.0.4 detects log4j 1.3 and alters its behaviour
accordingly but continues to map its trace methods to log4j debug methods
while log4j 1.3 now has its own trace methods. The following patch fixes this
bug:
Index: commons-
logging/src/java/org/apache/commons/logging/impl/Log4JLogger.java
===
--- commons-logging/src/java/org/apache/commons/logging/impl/Log4JLogger.java
(revision 161137)
+++ commons-logging/src/java/org/apache/commons/logging/impl/Log4JLogger.java
(working copy)
@@ -84,7 +84,7 @@
if(is12) {
getLogger().log(FQCN, (Priority) Level.DEBUG, message, null );
} else {
-getLogger().log(FQCN, Level.DEBUG, message, null );
+getLogger().log(FQCN, Level.TRACE, message, null );
}
}
@@ -97,7 +97,7 @@
if(is12) {
getLogger().log(FQCN, (Priority) Level.DEBUG, message, t );
} else {
-getLogger().log(FQCN, Level.DEBUG, message, t );
+getLogger().log(FQCN, Level.TRACE, message, t );
}
}
@@ -277,7 +277,11 @@
* For Log4J, this returns the value of codeisDebugEnabled()/code
*/
public boolean isTraceEnabled() {
-return getLogger().isDebugEnabled();
+if(is12) {
+return getLogger().isDebugEnabled();
+} else {
+return getLogger().isTraceEnabled();
+}
}
/**
--
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 34436] - [fileupload] Allow to set headerEncoding to other than platform default encoding for fall-back
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=34436. 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=34436 [EMAIL PROTECTED] changed: What|Removed |Added Summary|allow to set headerEncoding |[fileupload] Allow to set |to other than platform |headerEncoding to other than |default encoding for fall- |platform default encoding |back|for fall-back -- 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 24765] - [fileupload] The current code assumes the platforms default encoding is iso-8859-1
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=24765. 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=24765 [EMAIL PROTECTED] changed: What|Removed |Added Summary|The current code assumes the|[fileupload] The current |platforms default encoding |code assumes the platforms |is iso-8859-1 |default encoding is iso- ||8859-1 -- 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 34437] - [logging] Log.trace() doesn't use log4j 1.3 trace methods
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=34437. 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=34437 [EMAIL PROTECTED] changed: What|Removed |Added Summary|commons logging 1.0.4 does |[logging] Log.trace() |not use log4j 1.3 trace |doesn't use log4j 1.3 trace |methods |methods -- 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 34416] - [validator] Form extends multiple forms
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=34416. 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=34416 [EMAIL PROTECTED] changed: What|Removed |Added Summary|Form extends multiple forms |[validator] Form extends ||multiple forms -- 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]
maven question
I have just started using maven on my first project, but I have been playing with it at home. My question for the commons developers is this, every project here uses maven, and I would assume many of you also use eclipse or some other similar IDE. Has anyone found a good way to add the jars managed by maven to your IDE classpath? In previous projects I would just put all of the jars in the lib directory and check them into CVS. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven question
Kyle Miller wrote: I have just started using maven on my first project, but I have been playing with it at home. My question for the commons developers is this, every project here uses maven, and I would assume many of you also use eclipse or some other similar IDE. Has anyone found a good way to add the jars managed by maven to your IDE classpath? In previous projects I would just put all of the jars in the lib directory and check them into CVS. http://mevenide.codehaus.org/ Cheers, -- Bob Arnott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34362] - [configuration] AbstractFileConfiguration.save() creates a new file instead of overwritting the existing one
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=34362. 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=34362 --- Additional Comments From [EMAIL PROTECTED] 2005-04-13 16:36 --- Hi Everyone, I have been working on a set of fixes for the bugs that are documented for the AbstractFileConfiguration and I wanted to run a few things by everyone for your input. Changes to File Loading: Ive updated the load methods to cascade into one another thus place 99% of the real business logic into a single load method. ( In this case load(URL url) ) thus: load(String fileName) woud create a file and from the filename and then pass to load(File file) which would get the URL and pass to load(URL url) which would be the primary loading mechanism. load() would use the stored url (instance variable) to forward to load(URL url) This then leads to the saving strategy. Calling save() will save your current configuration using the existing filename, path ect... calling save(String fileName) or any other save method that includes a parameter is actually a saveAs type feature. Updating values Updating the path and filename values will actually update the internally stored URL. thus calling setFileName(String name) should cause us to get the basePath.. tack on the fileName and generate the new URL to be used for loading and calling save(). The same logic is applied to setBasePath, setURL ect... Doing this has ment that the setFileName setBasePath setURL methods now must all throw ConfigurationException(s) where previously they did not.This is because if we update the instance URL we may encounter a malformedUrlException... These changes may also require updating some of our test cases.. ive been reviewing them as I write this email. Please let me know your thoughts. -- 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 34362] - [configuration] AbstractFileConfiguration.save() creates a new file instead of overwritting the existing one
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=34362. 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=34362 --- Additional Comments From [EMAIL PROTECTED] 2005-04-13 17:04 --- One last note.. getBasePath(); this method currently returns different values based on if you started off with a URL or a String / filename. ie.. new PropertiesConfigurationFile(/mydir/myConfiguFile.properites); would have a base path of /mydir/ but new PropertiesConfigurationFile (file://mydir/myConfigurationFile.properties); woul have a base path of file://mydir/ both instance however would still have a getURL method.. that would return a url full path. Since im proposing using the a URL as the internal base for file location basePath now has a new challenge. Do we still return different values based on how the configuration was initialized... ? or do we decide on a common form for base path.. lets say.. base path is now the path without protocol ie.. file:/mydir/myCOnfiguration.properties basepath is now /mydir/ same as if it was create using File(/mydir/myConfiguration.properties) :) and for those that need the URL base path..version we add a new method to the interface getURLBasePath(); which would return file:/mydir/myConfiguration even if you created the configuration using a string or file parameter.. (i know that was all a bit wordy.. sorry about that.. let me know your thoughts) -- 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]
[logging] update docs to specify that java 1.1 is supported
Hi, A user recently asked on the commons-user list whether JCL runs on java 1.1. I'm sure it is meant to, but I can't find anywhere in the docs myself that say what JVMs are supported. So attached is a proposed patch to clarify this in the docs. Is everyone happy with this? Cheers, Simon Index: xdocs/index.xml === --- xdocs/index.xml (revision 161185) +++ xdocs/index.xml (working copy) @@ -39,6 +39,9 @@ and contributors may write Log implementations for the library of their choice./p +pJakarta Commons Logging supports all versions of java equal to or later +than java 1.1./p + /section Index: xdocs/guide.xml === --- xdocs/guide.xml (revision 161185) +++ xdocs/guide.xml (working copy) @@ -92,6 +92,10 @@ logging abstraction, that allows the user (application developer) to plug in a specific logging implementation. /p + +pJCL supports all versions of java equal to or later +than java 1.1./p + pJCL provides thin-wrapper codeLog/code implementations for other logging tools, including a href=http://jakarta.apache.org/log4j/docs/index.html;Log4J/a, Index: src/java/org/apache/commons/logging/package.html === --- src/java/org/apache/commons/logging/package.html (revision 161185) +++ src/java/org/apache/commons/logging/package.html (working copy) @@ -43,6 +43,8 @@ System.err./li /ul +pThis library is intended to run on any JVM equal to or later than +version 1.1./p h3Quick Start Guide/h3 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] update docs to specify that java 1.1 is supported
LogFactory relies on Thread.getContextClassLoader(), which didn't exist in the 1.1 JVM. So, I wouldn't expect JCL to run. I played around with testing this a while back (downloaded Sun's 1.1 JVM), but hit some minor roadblock and stopped. You're right -- this should be clarified, particularly since it also impacts design issues. Tonight I'll get the test working. Brian --- Simon Kitching [EMAIL PROTECTED] wrote: Hi, A user recently asked on the commons-user list whether JCL runs on java 1.1. I'm sure it is meant to, but I can't find anywhere in the docs myself that say what JVMs are supported. So attached is a proposed patch to clarify this in the docs. Is everyone happy with this? Cheers, Simon Index: xdocs/index.xml === --- xdocs/index.xml (revision 161185) +++ xdocs/index.xml (working copy) @@ -39,6 +39,9 @@ and contributors may write Log implementations for the library of their choice./p +pJakarta Commons Logging supports all versions of java equal to or later +than java 1.1./p + /section Index: xdocs/guide.xml === --- xdocs/guide.xml (revision 161185) +++ xdocs/guide.xml (working copy) @@ -92,6 +92,10 @@ logging abstraction, that allows the user (application developer) to plug in a specific logging implementation. /p + +pJCL supports all versions of java equal to or later +than java 1.1./p + pJCL provides thin-wrapper codeLog/code implementations for other logging tools, including a href=http://jakarta.apache.org/log4j/docs/index.html;Log4J/a, Index: src/java/org/apache/commons/logging/package.html === --- src/java/org/apache/commons/logging/package.html (revision 161185) +++ src/java/org/apache/commons/logging/package.html (working copy) @@ -43,6 +43,8 @@ System.err./li /ul +pThis library is intended to run on any JVM equal to or later than +version 1.1./p h3Quick Start Guide/h3 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34436] - [fileupload] Allow to set headerEncoding to other than platform default encoding for fall-back
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=34436. 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=34436 --- Additional Comments From [EMAIL PROTECTED] 2005-04-13 17:52 --- It is already possible to set the header encoding on a per-instance basis using FileUploadBase.setHeaderEncoding(). I admit that's a little buried, which is why I'm going to leave this bug report open for now. I do not like the idea of using a static default value for exactly the reason you state - it will cause problems, and likely much confusion, in situations where a shared FileUpload jar is in use. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[digester] Proposal for release of version 1.7
Hi All, Digester 1.6 was released on 9-sep-2004 (7 months ago). Since then there have been a handful of small bugfixes or improvements. There's nothing particularly exciting happening here; Digester 1.x appears to have reached an extremely stable form. I've updated the RELEASE-NOTES.txt file with the list of all the changes since 1.6 (see attachment). Normally the few items that have accumulated since the last release wouldn't justify a release at this time. However it doesn't appear as if there will be any more changes to Digester 1.x coming along in the near future, and there are a few items checked in that will be useful to digester users. So it seems to me we may as well make what we have available now. Bugzilla currently contains 4 enhancement requests, none of which appear to have anyone willing to work on them - or to use them if they should ever be implemented. I've certainly got little enthusiasm for addressing any of these enhancements myself (though I would be willing to review patches if any are put forward). There's also one trivial enhancement/bug entry to do with MD5 sums for jar files that can be addressed during the release procedure. I'm happy to be the release manager for this one if that's ok with y'all. So what do you think? Should we work towards a release 1.7 or not? Cheers, Simon $Id: RELEASE-NOTES.txt 155412 2005-02-26 12:58:36Z dirkv $ Commons Digester Package Version 1.7 Release Notes INTRODUCTION This is a minor bugfix and maintenance release. A few small features have been added. New projects are encouraged to use this release of digester, but there is no urgency for existing projects to upgrade; Digester 1.6 has proven to be a stable release. This release is 100% binary and source compatible with the previous release. RELEASE TODO * update xdocs/index.xml * xdocs/navigation.xml * project.xml * build.xml * src/conf/MANIFEST.MF * verify package.html is correct html. * decide on javadoc license text in footer * run clirr to check for changes between releases. IMPORTANT NOTES === * The jakarta commons project has migrated to the Subversion version control system (previously, CVS was used). There should be no effect on users of the Digester library, but obviously the process of examining the latest source code, and of creating patches for Digester has now changed. Please see the jakarta commons website for details (http://jakarta.apache.org/commons). Dependencies = Release 1.7 has the same dependencies as release 1.6. Compatible Dependency Sets: Digester 1.7 + Logging 1.0.x + BeanUtils 1.x + Collections 2.x Digester 1.7 + Logging 1.0.x + BeanUtils 1.x + Collections 3.x Digester 1.7 + Logging 1.0.x + BeanUtils 1.7 NEW FEATURES = Improved Documentation -- As usual, documentation has improved in this release. Minor Javadoc improvements occur in the following classes: Rule, RulesBase, ExtendedBaseRules, NodeCreateRule, CallMethodRule, CallParamRule, SetNextRule The javadoc package documentation (package.html) has also had minor updates to the following topics: * How Digester can be used as a SAX content handler. * How wildcard rules are ignored if non-wildcard matches are available. Digester Named stacks are now cleared by the clear() method. Note that it is recommended that a new Digester instance be created for each document parsed, hence this should not be necessary. Method resetRoot has been added. Again, this should only be relevant for programs that attempt to reuse a single Digester instance to process multiple documents (which is not recommended). Method peek(String stackname, int n) has been added for consistency, to allow access to arbitrary objects on named stacks. Thanks to Brian Hanafee for the suggestion (bugzilla #33873). SetNestedPropertiesRule The toString method has been improved, for better logging diagnostics. Patch provided by Wendy Smoak. The addressbook sample now demonstrates use of SetNestedPropertiesRule. SetPropertiesRule - A new ignoreMissingProperty flag can be set false to cause an exception to be generated when the xml contains an attribute not available on the target bean. Patch contributed by Gabriele Carcassi. Xmlrules Enhancements -- The xmlrules module has had a number of minor updates to provide access to functionality that was previously accessable only via the digester API: -- add set-nested-properties-rule tag. Much of this patch provided by Wendy Smoak. -- add targetoffset attribute to call-method-rule tag, to allow the target object whose method is invoked to be any object on the digester stack. Patch by Wendy Smoak (bugzilla #33550). -- add stack-index attribute to call-param-rule
DO NOT REPLY [Bug 34441] New: - Setting Configuration Reloading Strategy to FileChangedReloadingStrategy erases entire configuration
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=34441.
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=34441
Summary: Setting Configuration Reloading Strategy to
FileChangedReloadingStrategy erases entire configuration
Product: Commons
Version: 1.1 Final
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: critical
Priority: P2
Component: Configuration
AssignedTo: commons-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
When setting a PropertiesConfiguration reloading strategy to
FileChangedReloadingStrategy - the entire configuration is erased.
The problem is that when the FileChangedReloadingStrategy is set, the
configuration file is erased and then reloaded and then written out.
The file is erased in AbstractFileConfiguration.save(File) when a new
FileOutputStream is created. Then in the PropertiesConfiguration.save(Writer)
the call to getKeys() causes a reaload() to occur (which the strategy says needs
to be reloaded because it has been modified). But the saved config file is now
zeroed out by the new file stream, and it is read in as an empty config.
Here is a testcase that exposed this defect:
public void
testPropertiesConfigurationWithFileChangedReloadingStrategyDefect() throws
ConfigurationException, FileNotFoundException, IOException {
FileWriter file = new FileWriter(testfile.properties);
file.write(a=1);
file.close();
FileConfiguration config = new
PropertiesConfiguration(testfile.properties);
config.setAutoSave(true);
config.setReloadingStrategy(new FileChangedReloadingStrategy());
assertEquals(1, config.getString(a));
config.setProperty(2, b);
assertEquals(1, config.getString(a));
}
--
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 34437] - [logging] Log.trace() doesn't use log4j 1.3 trace methods
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=34437. 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=34437 --- Additional Comments From [EMAIL PROTECTED] 2005-04-13 18:28 --- Hi Peter, I'm a bit concerned about the fact that this implementation requires testing a boolean flag for each call to Log.isTraceEnabled or Log.trace. Testing a single boolean isn't too bad, but logging *is* supposed to be highly tuned. Yes, the current code *already* does this boolean testing - but I'm not sure I agree with it. An alternative would be to instead create a Log4J13Logger class which subclasses Log4JLogger and overrides the trace and isTraceEnabled methods. This should produce the same effect without needing a boolean flag - though it means modifying LogFactoryImpl to do the testing for log4j version instead (so it can select the correct Log wrapper class constructor to call). However if no-one else is concerned about the performance implications of an extra boolean test in isTraceEnabled, then your patch could certainly be applied as-is. If we stay with the current implementation, I think it would be a good idea to rename is12 to isPre13 or similar; I was confused at first by this variable name (not your fault, Peter!). -- 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 34436] - [fileupload] Allow to set headerEncoding to other than platform default encoding for fall-back
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=34436. 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=34436 --- Additional Comments From [EMAIL PROTECTED] 2005-04-13 18:33 --- Martin, Now, I am confused: The javadoc for FileUploadBase.setHeaderEncoding() says: /** * Specifies the character encoding to be used when reading the headers of * individual parts. When not specified, or codenull/code, the platform * default encoding is used. * * @param encoding The encoding used to read part headers. */ so to me, it appears that this is complementary to what I am proposing: In fact, I see that struts as I am using it in org.apache.struts.upload.CommonsMultipartRequestHandler.handleRequest does call your setHeaderEncoding(), but it turns out that (be it struts' or the browser's fault) arrives as null. So, this is exactly the case where I want to avoid it being set to the system's file.encoding. Short from patching struts, I do not see an option where I as an application programmer who neither wants to touch the the struts nor the fileupload jar, can call your setHeaderEncoding() before it's already set to the platform encoding. So, what is probably needed that the FileUpload has an init() that creates a singleton per web-application for the headerEncodingDefault and the user can set that to a different value BEFORE e.g. struts or other frameworks start to use the FileUploadBase - what do you think? -- 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 34441] - [configuration] Setting the reloading strategy to FileChangedReloadingStrategy erases entire configuration
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=34441. 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=34441 [EMAIL PROTECTED] changed: What|Removed |Added Summary|Setting Configuration |[configuration] Setting the |Reloading Strategy to |reloading strategy to |FileChangedReloadingStrategy|FileChangedReloadingStrategy |erases entire configuration |erases entire configuration -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] update docs to specify that java 1.1 is supported
Hi Brian,
This code in LogFactory:
public static LogFactory getFactory()
throwsLogConfigurationException {
// Identify the class loader we will be using
ClassLoader contextClassLoader =
(ClassLoader)AccessController.doPrivileged(
new PrivilegedAction() {
public Object run() {
return getContextClassLoader();
}
});
actually calls a method named getContextClassLoader defined in the
LogFactory class, *not* Thread.getContextClassLoader. The local
getContextClassLoader method uses reflection to handle 1.1 jvms. On
1.1 JVMs, the classloader which loaded the current class is always
returned (see catch(NoSuchMethodException e) on line 551 of
LogFactory.java).
So I *think* everything currently works ok on 1.1 jvms. I haven't tested
it myself, though, so would be very interested in results of your
testing.
Can you even *download* 1.1 JVMs these days??
Cheers,
Simon
PS: I'm back from my holidays now, and ready to get stuck into JCL
(well, once recovered from my jetlag!).
On Wed, 2005-04-13 at 08:50 -0700, Brian Stansberry wrote:
LogFactory relies on Thread.getContextClassLoader(),
which didn't exist in the 1.1 JVM. So, I wouldn't
expect JCL to run. I played around with testing this
a while back (downloaded Sun's 1.1 JVM), but hit some
minor roadblock and stopped. You're right -- this
should be clarified, particularly since it also
impacts design issues. Tonight I'll get the test
working.
Brian
--- Simon Kitching [EMAIL PROTECTED] wrote:
Hi,
A user recently asked on the commons-user list
whether JCL runs on java
1.1. I'm sure it is meant to, but I can't find
anywhere in the docs
myself that say what JVMs are supported.
So attached is a proposed patch to clarify this in
the docs.
Is everyone happy with this?
Cheers,
Simon
Index: xdocs/index.xml
===
--- xdocs/index.xml (revision 161185)
+++ xdocs/index.xml (working copy)
@@ -39,6 +39,9 @@
and contributors may write Log implementations for
the library of
their choice./p
+pJakarta Commons Logging supports all versions of
java equal to or later
+than java 1.1./p
+
/section
Index: xdocs/guide.xml
===
--- xdocs/guide.xml (revision 161185)
+++ xdocs/guide.xml (working copy)
@@ -92,6 +92,10 @@
logging abstraction, that allows the user
(application developer) to plug in
a specific logging implementation.
/p
+
+pJCL supports all versions of java equal to or
later
+than java 1.1./p
+
pJCL provides thin-wrapper codeLog/code
implementations for
other logging tools, including
a
href=http://jakarta.apache.org/log4j/docs/index.html;Log4J/a,
Index:
src/java/org/apache/commons/logging/package.html
===
--- src/java/org/apache/commons/logging/package.html
(revision 161185)
+++ src/java/org/apache/commons/logging/package.html
(working copy)
@@ -43,6 +43,8 @@
System.err./li
/ul
+pThis library is intended to run on any JVM equal
to or later than
+version 1.1./p
h3Quick Start Guide/h3
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34436] - [fileupload] Allow to set headerEncoding to other than platform default encoding for fall-back
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=34436. 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=34436 --- Additional Comments From [EMAIL PROTECTED] 2005-04-13 18:45 --- If you look at that particular code in Struts, you will see: // The following line is to support an EncodingFilter // see http://issues.apache.org/bugzilla/show_bug.cgi?id=23255 upload.setHeaderEncoding(request.getCharacterEncoding()); The comment is important... -- 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]
[PATCH] [commons-configuration] - Added a preload feature to DatabaseConfiguration
Hi folks, the attachted (svn-)patch adds a preload feature to the DatabaseConfiguration class. I added (for backwards compatibility) a third constructor with a preloadData boolean variable. If this variable is set to true, all configuration data is read in one step and then cached in a local Map. This is more performant (and more database gentle) because all following operations (getProperty(), getKeys(), ...) are done on the local Map (but kept in sync with the database, if it is a write access). I'd be happy if you apply it to the trunk. Best, Oliver dbpreload.txt.gz Description: GNU Zip compressed data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34362] - [configuration] AbstractFileConfiguration.save() creates a new file instead of overwritting the existing one
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=34362. 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=34362 --- Additional Comments From [EMAIL PROTECTED] 2005-04-13 19:39 --- Hey, thanks for your work! Here are some of my thoughts: WRT load() methods: I may be wrong, but I thought that the load() methods were already implemented in a way that they call each other and that most part of the logic was placed in one of them. If your load(URL) method does the job, how do you handle readers and streams then? WRT save(): The save as semantic is okay with me, I think this is compatible with the actual implementation, isn't it? WRT setting the file name stuff: I am -1 that these methods should throw exceptions. Wouldn't it be possible to evaluate the values lazy, i.e. when the load() method is called? As I already pointed out, for me there is no need that all of the getters and setters are always in sync. If the URL that is used by the load() method is stored and used again by save(), this is fine. From your description I get the impression that the whole process is quite delicate, and I bet there will be a bunch of other opinions about how ambiguities (e.g. with the base path) should be resolved. So I would recommend to provide only simple getters and setters and in addition allow to retrieve the resolved URL used by load(). I see this fix as a temporary solution only. For the long run I am for the locators. -- 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 34436] - [fileupload] Allow to set headerEncoding to other than platform default encoding for fall-back
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=34436. 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=34436 --- Additional Comments From [EMAIL PROTECTED] 2005-04-13 19:40 --- Thx, this is an interesting hint, haven't tested it but I trust the folks over there did. Suggestion: for a new javadoc for the FileUploadBase.setHeaderEncoding(): /** * Specifies the character encoding to be used when reading the headers of * individual parts. When not specified, or codenull/code, the platform * default encoding is used. If you prefer some other encoding without * changing the platform's file.encoding, use an Encoding filter as * discussed in http://issues.apache.org/bugzilla/show_bug.cgi?id=23255 * for the requests coming from the browser that do not delare their * encoding. * * @param encoding The encoding used to read part headers. */ -- 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 34362] - [configuration] AbstractFileConfiguration.save() creates a new file instead of overwritting the existing one
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=34362. 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=34362 --- Additional Comments From [EMAIL PROTECTED] 2005-04-13 19:59 --- WRT: Methods Yes they did cascade into one another.. but some contained code to set the base path. ect.. along the way. This created a disconnect in when and what some of the get/setters would return based on how you initialized/created the configuration. This is futher compounded by the fact that you can change the filename, basepath ect and it may not effect how the file is loaded / saved! The goal of my changes is two fold. I would like to fix the existing bug. But in doing so we are also forced to re-examine fields such as basePath. and how they are related to the actual configuration file. What I have come up with is something like this: Lets say you create a PropertiesConfiguration(/myDir/MyConfig.properties); the base path would be /myDir/ the filename is MyConfig.properties if you save() the file will replace the existing file.(or create the file anew) if you save(String newName) a copy of the existing settings will be saved to newName but the existing configuration is unchanged if you setFileName( newName.props); the configuration will now use the new fileName from this point forward thus save() would now store to /myDir/newName.props The same applies to basePath. if you setBasePath(/newDir); the new stored location is now /newDir/newName.props This logic must work weither the user is using URL / String or File to create / manipulate the configuration. So far.. ive got the changes almost complete. Im aware that what im doing here is more than just fixing the existing bug. And that prior to now these settings had no guarrenty of being in synch with where save() actually store data... but then if its not in synch.. what go are they? The only place i ran into a potential issue is for web based URLs.. ie http://www.myweb.com/myprops.props for this configuration basePath should not return http://www.myweb.com/ this is unconsitent as it means the base app now has to be smart enough to change the basePath to a URL. Instead I would add getURLBase and return null from getBasePath where getURLBase returns a URL for all implementation (including local files); but getBase.. im not sure.. so right now null if the URL is a remote url. -- 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 27414] - [validator] GenericValidator.isDate can fail when strict == true
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=27414. 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=27414 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34442] New: - [configuration] XMLConfiguration may lose attributes in its save() method
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34442. 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=34442 Summary: [configuration] XMLConfiguration may lose attributes in its save() method Product: Commons Version: 1.1 Final Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Configuration AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Under some circumstances (if a configuration is loaded, cleared and then reloaded), the save() method forgets to write attributes. Their values are still contained in the configuration object itself, but they are not written to the output file. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r161196 - in jakarta/commons/proper/configuration/trunk: src/java/org/apache/commons/configuration/XMLConfiguration.java src/test/org/apache/commons/configuration/TestXMLConfiguration.java xdocs/changes.xml
Author: oheger
Date: Wed Apr 13 11:53:10 2005
New Revision: 161196
URL: http://svn.apache.org/viewcvs?view=revrev=161196
Log:
Fix for issue 34442: XMLConfiguration.save() won't forget attributes any more.
Modified:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/XMLConfiguration.java
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestXMLConfiguration.java
jakarta/commons/proper/configuration/trunk/xdocs/changes.xml
Modified:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/XMLConfiguration.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/XMLConfiguration.java?view=diffr1=161195r2=161196
==
---
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/XMLConfiguration.java
(original)
+++
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/XMLConfiguration.java
Wed Apr 13 11:53:10 2005
@@ -213,6 +213,16 @@
}
/**
+ * Removes all properties from this configuration. If this configuration
+ * was loaded from a file, the associated DOM document is also cleared.
+ */
+public void clear()
+{
+super.clear();
+document = null;
+}
+
+/**
* @inheritDoc
*/
public void setProperty(String key, Object value)
@@ -242,7 +252,7 @@
*/
private void constructHierarchy(Node node, Element element, boolean
elemRefs)
{
-processAttributes(node, element);
+processAttributes(node, element, elemRefs);
StringBuffer buffer = new StringBuffer();
NodeList list = element.getChildNodes();
for (int i = 0; i list.getLength(); i++)
@@ -275,8 +285,9 @@
*
* @param node the actual node
* @param element the actual XML element
+ * @param elemRefs a flag whether references to the XML elements should be
set
*/
-private void processAttributes(Node node, Element element)
+private void processAttributes(Node node, Element element, boolean
elemRefs)
{
NamedNodeMap attributes = element.getAttributes();
for (int i = 0; i attributes.getLength(); ++i)
@@ -287,7 +298,8 @@
Attr attr = (Attr) w3cNode;
for (Iterator it = PropertyConverter.split(attr.getValue(),
getDelimiter()).iterator(); it.hasNext();)
{
-Node child = new
XMLNode(ConfigurationKey.constructAttributeKey(attr.getName()), element);
+Node child = new
XMLNode(ConfigurationKey.constructAttributeKey(attr.getName()),
+(elemRefs) ? element : null);
child.setValue(it.next());
node.addChild(child);
}
Modified:
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestXMLConfiguration.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestXMLConfiguration.java?view=diffr1=161195r2=161196
==
---
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestXMLConfiguration.java
(original)
+++
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestXMLConfiguration.java
Wed Apr 13 11:53:10 2005
@@ -411,5 +411,19 @@
conf = new XMLConfiguration(testSaveConf);
assertEquals(value, conf.getString(element));
assertEquals(tasks, conf.getString(table.name));
+assertEquals(application, conf.getString([EMAIL PROTECTED]));
+}
+
+/**
+ * Tests saving attributes (related to issue 34442).
+ */
+public void testSaveAttributes() throws Exception
+{
+conf.clear();
+conf.load();
+conf.save(testSaveConf);
+conf = new XMLConfiguration();
+conf.load(testSaveConf);
+assertEquals(foo, conf.getString([EMAIL PROTECTED]));
}
}
Modified: jakarta/commons/proper/configuration/trunk/xdocs/changes.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/configuration/trunk/xdocs/changes.xml?view=diffr1=161195r2=161196
==
--- jakarta/commons/proper/configuration/trunk/xdocs/changes.xml (original)
+++ jakarta/commons/proper/configuration/trunk/xdocs/changes.xml Wed Apr 13
11:53:10 2005
@@ -23,6 +23,11 @@
body
release version=1.2-dev date=in SVN
+ action dev=oheger type=update due-to=Mi Zhang issue=34442
+Fixed a bug which causes XMLConfiguration.save to lose attribute values
+under some circumstances. The clear() method now also ensures that the
+
DO NOT REPLY [Bug 34442] - [configuration] XMLConfiguration may lose attributes in its save() method
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34442. 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=34442 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2005-04-13 20:57 --- Committed a fix to SVN. The clear() method was also updated to wipe out the associated DOM document. Otherwise it is possible that some artifacts of the old document (e.g. comments) appear again when save() is called later. -- 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: maven question
Hi Kyle, The first time you need to add an environment in your eclipse settings to define your maven repository home : maven -Dmaven.eclipse.workspace=/your/path/to/your/eclipse/workspace eclipse:add-maven-repo Then, in any maven project you generate your eclipse configuration : maven eclipse and you import it in eclipse (import an existing project ... in eclipse) Arnaud -Message d'origine- De : Kyle Miller [mailto:[EMAIL PROTECTED] Envoyé : mercredi 13 avril 2005 15:11 À : commons-dev@jakarta.apache.org Objet : maven question I have just started using maven on my first project, but I have been playing with it at home. My question for the commons developers is this, every project here uses maven, and I would assume many of you also use eclipse or some other similar IDE. Has anyone found a good way to add the jars managed by maven to your IDE classpath? In previous projects I would just put all of the jars in the lib directory and check them into CVS. - 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: [betwixt] [patch] Support for polymorphic references
On Sun, 2005-04-10 at 22:05 +0200, Thomas Dudziak wrote: Hi, hi Thomas sorry for ignoring so many of your posts (been very busy recently) snip The attached TestReferenceMapping provides a unit test for this scenario. sadly the unit test attachment didn't make it through to me Also attached is a unit test that shows a bug in betwixt for the same scenario but with a collection (see also section Mixed Collections - Guessing Element Names in http://jakarta.apache.org/commons/betwixt/guide/binding.html). thanks but again the unit test didn't seem to make it through the mailing list is sometimes too aggressive when stripping attachments. could you possibly create a bug report and attach all your patches to it? TIA - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [betwixt] [patch] Support for polymorphic references
sorry for ignoring so many of your posts (been very busy recently) who isn't ;-) the mailing list is sometimes too aggressive when stripping attachments. could you possibly create a bug report and attach all your patches to it? I'll try (though I really dislike bugzilla for its user-unfriendlyness). Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34443] New: - [betwixt] Betwixt does not support polymorphic references
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=34443.
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=34443
Summary: [betwixt] Betwixt does not support polymorphic
references
Product: Commons
Version: unspecified
Platform: Other
OS/Version: other
Status: NEW
Severity: major
Priority: P2
Component: Betwixt
AssignedTo: commons-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
Attached is a patch to commons-betwixt, SVN Head, that enables betwixt
to map polymorphic references. I.e. a class has a field of a type,
that itself or some of its subtypes are mapped:
class A
{
private B obj;
}
interface B
{}
class C implements B
{}
class D implements B
{}
This in effect makes it necessary to make the 'name' attribute completely
optional (using the property name when necessary) in order to be able to use the
element definition from the class descriptor of the reference type:
?xml version=1.0?
betwixt-config
class name=A
element name=a
element property=obj/
/element
/class
class name=C
element name=c/
/class
class name=D
element name=d/
/class
/betwixt-config
In the current betwixt version, the name attribute of the element for obj is
requires so that the name of the created subelement does not depend on the
actual type of the reference.
The attached TestReferenceMapping provides a unit test for this
scenario.
--
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 34443] - [betwixt] Betwixt does not support polymorphic references
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=34443. 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=34443 --- Additional Comments From [EMAIL PROTECTED] 2005-04-13 23:05 --- Created an attachment (id=14704) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14704action=view) Unified patch that allows betwixt to support polymorphic references -- 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 34443] - [betwixt] Betwixt does not support polymorphic references
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=34443. 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=34443 --- Additional Comments From [EMAIL PROTECTED] 2005-04-13 23:06 --- Created an attachment (id=14705) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14705action=view) A unit test for polymorphic references -- 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 34444] New: - [betwixt] Betwixt does not support polymorhpic types in collections
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=3.
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=3
Summary: [betwixt] Betwixt does not support polymorhpic types in
collections
Product: Commons
Version: unspecified
Platform: Other
OS/Version: other
Status: NEW
Severity: normal
Priority: P2
Component: Betwixt
AssignedTo: commons-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
Say a class A has a collection with elements of an interface type B which has
two subtypes:
class A
{
private List bs;
public Iterator getBs();
public void addB(B b);
}
interface B
{}
class C implements B
{}
class D implements B
{}
with the following mapping
?xml version=1.0?
betwixt-config
class name=A
element name=a
element property=bs/
/element
/class
class name=C
element name=c/
/class
class name=D
element name=d/
/class
/betwixt-config
However for an instance of A with both instances of C and D in the collection,
no c or d sub elements are generated but B elements instead.
The attached unit test exemplifies this.
--
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 34444] - [betwixt] Betwixt does not support polymorhpic types in collections
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=3. 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=3 --- Additional Comments From [EMAIL PROTECTED] 2005-04-13 23:13 --- Created an attachment (id=14706) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14706action=view) A unit test for polymorphic collections -- 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: [betwixt] [patch] Support for polymorphic references
On Wed, 2005-04-13 at 22:54 +0200, Thomas Dudziak wrote: sorry for ignoring so many of your posts (been very busy recently) who isn't ;-) the mailing list is sometimes too aggressive when stripping attachments. could you possibly create a bug report and attach all your patches to it? I'll try (though I really dislike bugzilla for its user-unfriendlyness). thanks AIUI it was the volume of viruses which meant the lists had to strip out most kinds of attachments - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r161229 - in jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang: ./ enum/ enums/ exception/ math/ mutable/ time/
Author: ggregory
Date: Wed Apr 13 15:36:48 2005
New Revision: 161229
URL: http://svn.apache.org/viewcvs?view=revrev=161229
Log:
Removed extra C style parens in return statements (as discussed on commons-dev).
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/ArrayUtils.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/BitField.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/BooleanUtils.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/CharRange.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/CharSet.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/CharUtils.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/ClassUtils.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/ObjectUtils.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/StringUtils.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/SystemUtils.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/WordUtils.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enum/Enum.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enums/Enum.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/exception/ExceptionUtils.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/exception/NestableDelegate.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/math/DoubleRange.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/math/FloatRange.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/math/IntRange.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/math/JVMRandom.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/math/LongRange.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/math/NumberRange.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/math/Range.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/mutable/MutableByte.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/mutable/MutableInt.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/mutable/MutableLong.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/mutable/MutableObject.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/mutable/MutableShort.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/time/DateUtils.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/time/StopWatch.java
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/ArrayUtils.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/ArrayUtils.java?view=diffr1=161228r2=161229
==
---
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/ArrayUtils.java
(original)
+++
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/ArrayUtils.java
Wed Apr 13 15:36:48 2005
@@ -1302,7 +1302,7 @@
* @return codetrue/code if the array contains the object
*/
public static boolean contains(Object[] array, Object objectToFind) {
-return (indexOf(array, objectToFind) != -1);
+return indexOf(array, objectToFind) != -1;
}
// long IndexOf
@@ -1405,7 +1405,7 @@
* @return codetrue/code if the array contains the object
*/
public static boolean contains(long[] array, long valueToFind) {
-return (indexOf(array, valueToFind) != -1);
+return indexOf(array, valueToFind) != -1;
}
// int IndexOf
@@ -1508,7 +1508,7 @@
* @return codetrue/code if the array contains the object
*/
public static boolean contains(int[] array, int valueToFind) {
-return (indexOf(array, valueToFind) != -1);
+return indexOf(array, valueToFind) != -1;
}
// short IndexOf
@@ -1611,7 +1611,7 @@
* @return codetrue/code if the array contains the object
*/
public static boolean contains(short[] array, short valueToFind) {
-return (indexOf(array, valueToFind) != -1);
+return indexOf(array, valueToFind) != -1;
}
// char IndexOf
@@ -1719,7 +1719,7 @@
* @since 2.1
*/
public static boolean contains(char[] array, char valueToFind) {
-return (indexOf(array, valueToFind) != -1);
+return indexOf(array, valueToFind) != -1;
}
// byte IndexOf
@@ -1822,7 +1822,7 @@
* @return codetrue/code if the array contains the object
*/
public static boolean
DO NOT REPLY [Bug 34437] - [logging] Log.trace() doesn't use log4j 1.3 trace methods
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=34437. 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=34437 --- Additional Comments From [EMAIL PROTECTED] 2005-04-14 01:27 --- Hi Simon, I was wondering about continual testing of the is12 flag in isTraceEnabled. It's obviously going to cost some time, though I don't really have the expertise to know how much, so I'm curious what others think. If you're looking for a volunteer, I'd enjoy taking a look at submitting a Log4J13Logger and the required LogFactoryImpl modification if that would help, or do the suggested rename of is12 to isPre13, though I may not be able to turn it around very quickly and I'll have questions (like should I actually be working on 1.0.5 and how to do unit testing). Regards, Peter -- 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]
[all] effect on Commons of Maven2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, No, this is not a proposal to convert all of Commons to Maven2 :) (If you'd like to give it a try, you are welcome too - we have dist and ant plugins!) What it is about is POMs. Commons is a highly depended on set of libraries, and anything that was not given due diligence is going to be highlighted very quickly through transitive dependencies (for example, the invalid commons-logging 1.0.4 release Robert fixed so quickly - thanks!) I'm about to send a message about configuration. We'll also be making enhancements to the m1-m2 converter to try and introduce as many smarts as possible. My question for the community is if this is the best way... mailing the list to ask for corrections in /www.apache.org/dist/java-repository/ and SCM, or whether there is some other way we can deal with these? Thanks, Brett -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCXa4qOb5RoQhMkRMRAp3wAJ9sJGERk0d2yrXC+wzAPoHdCu6mIQCgunR2 IUK95QJoecrG0vfVDmTTXqY= =Urn1 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[configuration] dependencies in 1.1 release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, There are a few suspect dependencies in the POM from the 1.1 release: - - resources:resources:1.0 doesn't exist - how does Maven build with this? - - as of commons-logging 1.0.4, I believe you should be dependening on commons-logging-api? - - dependency on dbunit, which is LGPL (Eric Pugh is a committer on both - perhaps he could propose a change to ASL/BSD?) - - badly specified mockobjects IDs (I thought the old format used + instead of :, but regardless - you should split it to group/artifactId - - dependency on findbugs, which is LGPL. (The plugin being used is ASL, but findbugs is LGPL) Anyone able to help? Thanks, Brett -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCXbCMOb5RoQhMkRMRArOTAJ9aCM5sUiaBUcosbYO1lviZ10uS7ACcCH72 YU8QSh/hmAyQvxWl7vUdEM8= =N+KG -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
commons-pool doesn't compile on java 1.5
I've checked recent archive and this compile error doesn't seem to be
listed.
[javac] Compiling 19 source files
to /var/tmp/portage/commons-pool-1.2/work/commons-pool-1.2/build/classes
[javac]
/var/tmp/portage/commons-pool-1.2/work/commons-pool-1.2/src/java/org/apache/commons/pool/impl/StackKeyedObjectPool.java:238:
as of release 1.5, 'enum' is a keyword, and may not be used as an identifier
[javac] (try -source 1.4 or lower to use 'enum' as an identifier)
[javac] Enumeration enum = stack.elements();
[javac] ^
[javac]
/var/tmp/portage/commons-pool-1.2/work/commons-pool-1.2/src/java/org/apache/commons/pool/impl/StackKeyedObjectPool.java:239:
as of release 1.5, 'enum' is a keyword, and may not be used as an identifier
[javac] (try -source 1.4 or lower to use 'enum' as an identifier)
[javac] while(enum.hasMoreElements()) {
[javac] ^
[javac]
/var/tmp/portage/commons-pool-1.2/work/commons-pool-1.2/src/java/org/apache/commons/pool/impl/StackKeyedObjectPool.java:241:
as of release 1.5, 'enum' is a keyword, and may not be used as an identifier
[javac] (try -source 1.4 or lower to use 'enum' as an identifier)
[javac]
_factory.destroyObject(key,enum.nextElement());
[javac]^
[javac]
/var/tmp/portage/commons-pool-1.2/work/commons-pool-1.2/src/java/org/apache/commons/pool/impl/StackObjectPool.java:199:
as of release 1.5, 'enum' is a keyword, and may not be used as an identifier
[javac] (try -source 1.4 or lower to use 'enum' as an identifier)
[javac] Enumeration enum = _pool.elements();
[javac] ^
[javac]
/var/tmp/portage/commons-pool-1.2/work/commons-pool-1.2/src/java/org/apache/commons/pool/impl/StackObjectPool.java:200:
as of release 1.5, 'enum' is a keyword, and may not be used as an identifier
[javac] (try -source 1.4 or lower to use 'enum' as an identifier)
[javac] while(enum.hasMoreElements()) {
[javac] ^
[javac]
/var/tmp/portage/commons-pool-1.2/work/commons-pool-1.2/src/java/org/apache/commons/pool/impl/StackObjectPool.java:202:
as of release 1.5, 'enum' is a keyword, and may not be used as an identifier
[javac] (try -source 1.4 or lower to use 'enum' as an identifier)
[javac]
_factory.destroyObject(enum.nextElement());
[javac]^
[javac] 6 errors
I can fix this (obviously) should I send a patch and to whom?
HTH
Stuart Guthrie
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] VOTE 2.1 release
We've noted in the .enum package @deprecated that the package will be removed in version 3.0. Should we not do the same for other @deprecated classes and methods? Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Sunday, April 10, 2005 5:54 PM To: Jakarta Commons Developers List Subject: [lang] VOTE 2.1 release Proposing a vote to go ahead and release Commons Lang 2.1. The release will pretty much match the release-candidate that is in: http://www.apache.org/~bayard/commons-lang-2.1/ Stephen's recent defaultIfEmpty method will be included in the release. If the vote is successful, I'll target spending next weekend performing the release (unless anyone wants to volunteer). [ ] +1 [ ] -1 Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r161241 - in jakarta/commons/proper/lang/trunk: build.xml default.properties
Author: ggregory
Date: Wed Apr 13 19:00:48 2005
New Revision: 161241
URL: http://svn.apache.org/viewcvs?view=revrev=161241
Log:
Fix Javadoc copyright year.
Modified:
jakarta/commons/proper/lang/trunk/build.xml
jakarta/commons/proper/lang/trunk/default.properties
Modified: jakarta/commons/proper/lang/trunk/build.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/lang/trunk/build.xml?view=diffr1=161240r2=161241
==
--- jakarta/commons/proper/lang/trunk/build.xml (original)
+++ jakarta/commons/proper/lang/trunk/build.xml Wed Apr 13 19:00:48 2005
@@ -99,7 +99,7 @@
version=true
doctitle=lt;h1gt;${component.title}lt;/h1gt;
windowtitle=${component.title} (Version
${component.version})
-bottom=Copyright amp;copy; 2001-2003 - Apache
Software Foundation
+bottom=Copyright amp;copy; 2001-${copyright.end} -
Apache Software Foundation
use=true
link=${jdk.javadoc}
source=${compile.source}
Modified: jakarta/commons/proper/lang/trunk/default.properties
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/lang/trunk/default.properties?view=diffr1=161240r2=161241
==
--- jakarta/commons/proper/lang/trunk/default.properties (original)
+++ jakarta/commons/proper/lang/trunk/default.properties Wed Apr 13 19:00:48
2005
@@ -31,6 +31,9 @@
# The current version number of this component
component.version = 2.0
+# The current year used for the end date in copyrights.
+copyright.end = 2005
+
# The name that is used to create the jar file
final.name = ${component.name}-${component.version}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: maven question
Thanks Arnaud, That is exactly what I was looking for... :) --- Arnaud HERITIER [EMAIL PROTECTED] wrote: Hi Kyle, The first time you need to add an environment in your eclipse settings to define your maven repository home : maven -Dmaven.eclipse.workspace=/your/path/to/your/eclipse/workspace eclipse:add-maven-repo Then, in any maven project you generate your eclipse configuration : maven eclipse and you import it in eclipse (import an existing project ... in eclipse) Arnaud -Message d'origine- De : Kyle Miller [mailto:[EMAIL PROTECTED] Envoyé : mercredi 13 avril 2005 15:11 À : commons-dev@jakarta.apache.org Objet : maven question I have just started using maven on my first project, but I have been playing with it at home. My question for the commons developers is this, every project here uses maven, and I would assume many of you also use eclipse or some other similar IDE. Has anyone found a good way to add the jars managed by maven to your IDE classpath? In previous projects I would just put all of the jars in the lib directory and check them into CVS. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] update docs to specify that java 1.1 is supported
No joy. Doesn't run under JDK 1.1. I wrote a simple
main method that calls LogFactory.getLog() and then
Log.info(). Call to LogFactory.getLog() fails with a
NoClassDefFoundError: java/security/PrivilegedAction.
java.security.AccessController isn't in 1.1 either.
Brian
--- Simon Kitching [EMAIL PROTECTED] wrote:
Hi Brian,
This code in LogFactory:
public static LogFactory getFactory()
throwsLogConfigurationException {
// Identify the class loader we will be
using
ClassLoader contextClassLoader =
(ClassLoader)AccessController.doPrivileged(
new PrivilegedAction() {
public Object run() {
return
getContextClassLoader();
}
});
actually calls a method named
getContextClassLoader defined in the
LogFactory class, *not*
Thread.getContextClassLoader. The local
getContextClassLoader method uses reflection to
handle 1.1 jvms. On
1.1 JVMs, the classloader which loaded the current
class is always
returned (see catch(NoSuchMethodException e) on
line 551 of
LogFactory.java).
So I *think* everything currently works ok on 1.1
jvms. I haven't tested
it myself, though, so would be very interested in
results of your
testing.
Can you even *download* 1.1 JVMs these days??
Cheers,
Simon
PS: I'm back from my holidays now, and ready to get
stuck into JCL
(well, once recovered from my jetlag!).
On Wed, 2005-04-13 at 08:50 -0700, Brian Stansberry
wrote:
LogFactory relies on
Thread.getContextClassLoader(),
which didn't exist in the 1.1 JVM. So, I wouldn't
expect JCL to run. I played around with testing
this
a while back (downloaded Sun's 1.1 JVM), but hit
some
minor roadblock and stopped. You're right -- this
should be clarified, particularly since it also
impacts design issues. Tonight I'll get the test
working.
Brian
--- Simon Kitching [EMAIL PROTECTED] wrote:
Hi,
A user recently asked on the commons-user list
whether JCL runs on java
1.1. I'm sure it is meant to, but I can't find
anywhere in the docs
myself that say what JVMs are supported.
So attached is a proposed patch to clarify this
in
the docs.
Is everyone happy with this?
Cheers,
Simon
Index: xdocs/index.xml
===
--- xdocs/index.xml (revision 161185)
+++ xdocs/index.xml (working copy)
@@ -39,6 +39,9 @@
and contributors may write Log implementations
for
the library of
their choice./p
+pJakarta Commons Logging supports all
versions of
java equal to or later
+than java 1.1./p
+
/section
Index: xdocs/guide.xml
===
--- xdocs/guide.xml (revision 161185)
+++ xdocs/guide.xml (working copy)
@@ -92,6 +92,10 @@
logging abstraction, that allows the user
(application developer) to plug in
a specific logging implementation.
/p
+
+pJCL supports all versions of java equal to
or
later
+than java 1.1./p
+
pJCL provides thin-wrapper codeLog/code
implementations for
other logging tools, including
a
href=http://jakarta.apache.org/log4j/docs/index.html;Log4J/a,
Index:
src/java/org/apache/commons/logging/package.html
===
---
src/java/org/apache/commons/logging/package.html
(revision 161185)
+++
src/java/org/apache/commons/logging/package.html
(working copy)
@@ -43,6 +43,8 @@
System.err./li
/ul
+pThis library is intended to run on any JVM
equal
to or later than
+version 1.1./p
h3Quick Start Guide/h3
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam
protection around
http://mail.yahoo.com
__
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
