DO NOT REPLY [Bug 31393] - SetNestedPropertiesRule causes StackOverflowError
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=31393. 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=31393 SetNestedPropertiesRule causes StackOverflowError --- Additional Comments From [EMAIL PROTECTED] 2004-10-06 06:34 --- Yep, this is definitely a bug - and definitely my fault too. Too much optimisation, assuming that this rule will only be used on a leaf node :-( I've created unit tests to duplicate the problem. I've also created *a* fix simply by removing *all* the optimisation attempted in the current version. But I'm not happy with this because 99% of the time it *will* be applied to a leaf node. I hope to have something to commit soonish. If anyone else wants to work on this, please contact me and I can provide the code I have so far. Thanks for the bug report James. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] XMLOutput.data(Object)
Maybe one little quick example: - currently, jelly-swing's ComponentTag calls, somewhere down in its doTag() findAncestorWithClass(ContainerTag.class) to which they call addComponent... At least one major drawback: putting such in a defined tag does not work unless you go till the top-level container in the defined tag (so no re-used swing script-snippets). Many other issues... - proposed: jelly-swing's ComponentTag should call, in its doTag(), xmlOutput.data(myBean) Advantage: works with scripts. - currently: jelly-sql can only define variables with the current result-sets Instead, the result-set could be given as data and the latter be transformed by some other tags (e.g. a tag that would merge the fields, or extract the only interesting ones). Overall, the idea is to have the ability for a tag to give return value that is not XML. I could produce many more scenarios. Most probably that should affect UseBeanTag... though maybe not at first launch. I would propose to enrich XMLOutput class itself (by adding the method doing the default toString). This should really bother the release, I believe. Then I'd like to concentrate on using this jelly-swing, with the hope to be able to make a jelly-swing-runner as a browser (maybe for jelly-swing 1.1 or so). paul Le 6 oct. 04, à 00:05, Dion Gillard a écrit : I'm not sure I understand what the use of this method is for Tags and TagLibraries, since it's on XML output. Can you give us an idea? On Tue, 5 Oct 2004 21:31:08 +0200, Paul Libbrecht [EMAIL PROTECTED] wrote: Dear Jellyers, I'd like to propose an addition to the XMLOutput class, used throughout Jelly: a method called data() (or object) accepting any object. By default... take the toString and call characters... Actually, this is the way it is done with the return value of a Jexl expression as part of a text node. But the interesting comes in the non-default case: - a math library could return a polynomial or numerical type... and this could then be further evaluated by parents - the arg element of jelly could actually avoid special treatment as it has currently - most of my interest applies for jelly-swing: the components would then want to call data(component) on the xmlOutput. The latter could be filtered by constraint-tags to call data(component-with-constraints). Finally, container tags could, also, filter, and receive the resulting data and add it. I would look forward to comments ! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] XMLOutput.data(Object)
How does this differ from writing to XMLOutput. It seems XMLOutput is being confused with the context...? On Wed, 6 Oct 2004 09:54:11 +0200, Paul Libbrecht [EMAIL PROTECTED] wrote: Maybe one little quick example: - currently, jelly-swing's ComponentTag calls, somewhere down in its doTag() findAncestorWithClass(ContainerTag.class) to which they call addComponent... At least one major drawback: putting such in a defined tag does not work unless you go till the top-level container in the defined tag (so no re-used swing script-snippets). Many other issues... - proposed: jelly-swing's ComponentTag should call, in its doTag(), xmlOutput.data(myBean) Advantage: works with scripts. - currently: jelly-sql can only define variables with the current result-sets Instead, the result-set could be given as data and the latter be transformed by some other tags (e.g. a tag that would merge the fields, or extract the only interesting ones). Overall, the idea is to have the ability for a tag to give return value that is not XML. I could produce many more scenarios. Most probably that should affect UseBeanTag... though maybe not at first launch. I would propose to enrich XMLOutput class itself (by adding the method doing the default toString). This should really bother the release, I believe. Then I'd like to concentrate on using this jelly-swing, with the hope to be able to make a jelly-swing-runner as a browser (maybe for jelly-swing 1.1 or so). paul Le 6 oct. 04, à 00:05, Dion Gillard a écrit : I'm not sure I understand what the use of this method is for Tags and TagLibraries, since it's on XML output. Can you give us an idea? On Tue, 5 Oct 2004 21:31:08 +0200, Paul Libbrecht [EMAIL PROTECTED] wrote: Dear Jellyers, I'd like to propose an addition to the XMLOutput class, used throughout Jelly: a method called data() (or object) accepting any object. By default... take the toString and call characters... Actually, this is the way it is done with the return value of a Jexl expression as part of a text node. But the interesting comes in the non-default case: - a math library could return a polynomial or numerical type... and this could then be further evaluated by parents - the arg element of jelly could actually avoid special treatment as it has currently - most of my interest applies for jelly-swing: the components would then want to call data(component) on the xmlOutput. The latter could be filtered by constraint-tags to call data(component-with-constraints). Finally, container tags could, also, filter, and receive the resulting data and add it. I would look forward to comments ! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.multitask.com.au/people/dion/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/i18n project.properties
dflorey 2004/10/06 01:38:29
Modified:i18n project.properties
Log:
Revision ChangesPath
1.2 +24 -0 jakarta-commons-sandbox/i18n/project.properties
Index: project.properties
===
RCS file: /home/cvs/jakarta-commons-sandbox/i18n/project.properties,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- project.properties4 Oct 2004 13:41:10 - 1.1
+++ project.properties6 Oct 2004 08:38:29 - 1.2
@@ -1,5 +1,29 @@
+maven.checkstyle.properties = checkstyle.xml
+
+# uncomment the next line to work in offline mode (no jar download no linkcheck)
+#maven.mode.online=
+
+maven.javadoc.debug=yes
maven.javadoc.author=false
maven.javadoc.links=http://java.sun.com/products/jdk/1.4/docs/api
+
+maven.xdoc.jsl=../../jakarta-commons/commons-build/commons-site.jsl
+maven.xdoc.date=bottom
+maven.xdoc.poweredby.image=maven-feather.png
+maven.xdoc.version=${pom.currentVersion}
+maven.xdoc.developmentProcessUrl=http://jakarta.apache.org/commons/charter.html
+
+maven.compile.debug=on
+maven.compile.deprecation=off
+maven.compile.optimize=off
+
+maven.jarResources.basedir=src/java
+maven.jar.excludes=**/package.html
+maven.junit.fork=true
+maven.junit.sysproperties=org.xml.sax.driver
+org.xml.sax.driver=org.apache.xerces.parsers.SAXParser
+
+clover.excludes=**/Test*.java
#
# M A V E N J A R O V E R R I D E
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/i18n project.xml
dflorey 2004/10/06 01:44:01 Modified:i18n project.xml Log: Revision ChangesPath 1.3 +5 -0 jakarta-commons-sandbox/i18n/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons-sandbox/i18n/project.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- project.xml 5 Oct 2004 21:05:44 - 1.2 +++ project.xml 6 Oct 2004 08:44:01 - 1.3 @@ -34,6 +34,11 @@ version1.1/version urlhttp://sourceforge.net/projects/xml-im-exporter/index.html/url /dependency + +!-- these two are required by maven -- +dependencyidxml-apis/idversion2.0.2/version/dependency +dependencyidxerces/idversion2.0.2/version/dependency +!-- /these two are required by maven -- /dependencies build - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/i18n project.properties project.xml
dflorey 2004/10/06 01:48:08
Modified:i18n project.properties project.xml
Log:
Makes them look like in sandbox-transaction
Revision ChangesPath
1.3 +1 -1 jakarta-commons-sandbox/i18n/project.properties
Index: project.properties
===
RCS file: /home/cvs/jakarta-commons-sandbox/i18n/project.properties,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- project.properties6 Oct 2004 08:38:29 - 1.2
+++ project.properties6 Oct 2004 08:48:07 - 1.3
@@ -33,4 +33,4 @@
#
# Jars set explicity by path.
#
-maven.jar.xml-im-exporter = ${basedir}/lib/xml-im-exporter1.1.jar
\ No newline at end of file
+maven.jar.xml-im-exporter = ${basedir}/lib/xml-im-exporter1.1.jar
1.4 +1 -5 jakarta-commons-sandbox/i18n/project.xml
Index: project.xml
===
RCS file: /home/cvs/jakarta-commons-sandbox/i18n/project.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- project.xml 6 Oct 2004 08:44:01 - 1.3
+++ project.xml 6 Oct 2004 08:48:07 - 1.4
@@ -1,5 +1,6 @@
?xml version=1.0?
project
+ extend../sandbox-build/project.xml/extend
nameCommons I18n/name
idcommons-i18n/id
logo/images/i18n-logo-white.png/logo
@@ -34,11 +35,6 @@
version1.1/version
urlhttp://sourceforge.net/projects/xml-im-exporter/index.html/url
/dependency
-
-!-- these two are required by maven --
-dependencyidxml-apis/idversion2.0.2/version/dependency
-dependencyidxerces/idversion2.0.2/version/dependency
-!-- /these two are required by maven --
/dependencies
build
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
AW: [i18n] New component - help needed
Hi Eric, Thanks for your help, but this didn't help much as with your changes the layout is broken and I cannot upload the website as some ssh-infos are missing. I wonder why the maven scripts for the transaction component (that I used as a blueprint) are working perfectly? I've no clue. Maybe I've to go to the maven mailinglists... Thanks again for your help, Daniel -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Eric Pugh Gesendet: Dienstag, 5. Oktober 2004 22:35 An: Jakarta Commons Developers List Betreff: RE: [i18n] New component - help needed Danile, I just tossed in a fix. basically the parent project is broken.. not extending it works.. as far tas the script, just rerun on your box the entire script, and then upload the homepage. Eric -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 05, 2004 8:12 PM To: Jakarta Commons Developers List Subject: [i18n] New component - help needed Hi folks, I've successfully added the I18n component to the commons sandbox. As I'm new to Maven I didn't managed to generate the API Javadocs. Can anyone have a look at this? Is this my fault as I assume? Seems that Maven can not find the source (but is actually building the jars without trouble). Any hints would be great! How can I integrate the link to the new component to the main commons page? Should I run the script on commons-sandbox top level? I'm afraid to do so as I may cause something bad. Regards, Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] XMLOutput.data(Object)
It does differ only by the fact that you write an Object and not XML-nodes! Only, this tiny change to be able to invoke the sacred functional word. paul Le 6 oct. 04, à 10:12, Dion Gillard a écrit : How does this differ from writing to XMLOutput. It seems XMLOutput is being confused with the context...? On Wed, 6 Oct 2004 09:54:11 +0200, Paul Libbrecht [EMAIL PROTECTED] wrote: Maybe one little quick example: - currently, jelly-swing's ComponentTag calls, somewhere down in its doTag() findAncestorWithClass(ContainerTag.class) to which they call addComponent... At least one major drawback: putting such in a defined tag does not work unless you go till the top-level container in the defined tag (so no re-used swing script-snippets). Many other issues... - proposed: jelly-swing's ComponentTag should call, in its doTag(), xmlOutput.data(myBean) Advantage: works with scripts. - currently: jelly-sql can only define variables with the current result-sets Instead, the result-set could be given as data and the latter be transformed by some other tags (e.g. a tag that would merge the fields, or extract the only interesting ones). Overall, the idea is to have the ability for a tag to give return value that is not XML. I could produce many more scenarios. Most probably that should affect UseBeanTag... though maybe not at first launch. I would propose to enrich XMLOutput class itself (by adding the method doing the default toString). This should really bother the release, I believe. Then I'd like to concentrate on using this jelly-swing, with the hope to be able to make a jelly-swing-runner as a browser (maybe for jelly-swing 1.1 or so). paul Le 6 oct. 04, à 00:05, Dion Gillard a écrit : I'm not sure I understand what the use of this method is for Tags and TagLibraries, since it's on XML output. Can you give us an idea? On Tue, 5 Oct 2004 21:31:08 +0200, Paul Libbrecht [EMAIL PROTECTED] wrote: Dear Jellyers, I'd like to propose an addition to the XMLOutput class, used throughout Jelly: a method called data() (or object) accepting any object. By default... take the toString and call characters... Actually, this is the way it is done with the return value of a Jexl expression as part of a text node. But the interesting comes in the non-default case: - a math library could return a polynomial or numerical type... and this could then be further evaluated by parents - the arg element of jelly could actually avoid special treatment as it has currently - most of my interest applies for jelly-swing: the components would then want to call data(component) on the xmlOutput. The latter could be filtered by constraint-tags to call data(component-with-constraints). Finally, container tags could, also, filter, and receive the resulting data and add it. I would look forward to comments ! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.multitask.com.au/people/dion/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[configuration] handling exceptions in AbstractConfiguration implementations
Hi All, I'm currently developing a sub-class of the AbstractConfiguration classthat uses Hibernate to access configuration properties (unimaginatively called Hibernate Configuration). I'm slightly concerned about the way sub-classes are suposed to handle exceptions: All the abstract method are defined as not throwing exceptions. All calls to hibernate, however, throw HibernateExceptions. So, for example, my implementation of getPropertyDirect calls the hibernate Session.get() method which can throw an exception. Looking at your implementation of the DatabaseConfiguration I can see that it simply consumes SQLExceptions thrown from the JDBC API, logging the stack trace. However, what if you want to be warned of exceptions being thrown by the underlying implementation of Configuration? I notice you already have a nestable ConfigurationException implemented. Surely, all Configuration methods should indicate they will throw this exception if they are expected to read/write data? Also, the AbstractConfiguration class does not describe this contract (logging all errors throw by underlying framework) or what should be returned in the event of an error? I assume you should return null values but this is not described anywhere. Kind regards, -- Ricardo Gladwell - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: jakarta-commons-sandbox/commons-resources 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 folk at [EMAIL PROTECTED] Project commons-resources has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 88L runs. Project State : 'Failed' The following are affected: - commons-resources : Commons resources Full details are available at: http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-resources/index.html That said, some snippets follow: The following annotations were provided: -DEBUG- Sole output [commons-resources-06102004.jar] identifier set to project name -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-resources/gump_work/build_jakarta-commons-sandbox_commons-resources.html Work Name: build_jakarta-commons-sandbox_commons-resources (Type: Build) State: Failed Elapsed: 3 secs Command Line: java -Djava.awt.headless=true -Dbuild.clonevm=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dfinal.name=commons-resources-06102004 dist [Working Directory: /usr/local/gump/public/workspace/jakarta-commons-sandbox/resources] CLASSPATH : /usr/local/j2sdk1.4.2_04/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons-sandbox/resources/target/classes:/usr/local/gump/public/workspace/jakarta-commons-sandbox/resources/target/test-classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.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-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-06102004.jar:/usr/local/gump/public/workspace/jakarta-commons/digester/dist/commons-digester.jar:/usr/local/gump/public/workspace/jakarta-commons/discovery/dist/commons-discovery.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/jakarta-servletapi-4/lib/servlet.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/packages/iBATIS_DBL-2.0.5.399/ibatis-dao-2.jar:/usr/local/gump/packages/iBATIS_DBL-2.0.5.399/ibatis-common-2.jar:/usr/local/gump/packages/iBATIS_DBL-2.0.5.399/ibatis-sqlmap-2.jar- Buildfile: build.xml init: [mkdir] Created dir: /usr/local/gump/public/workspace/jakarta-commons-sandbox/resources/target/lib get-deps: compile: [mkdir] Created dir: /usr/local/gump/public/workspace/jakarta-commons-sandbox/resources/target/classes [javac] Compiling 28 source files to /usr/local/gump/public/workspace/jakarta-commons-sandbox/resources/target/classes [javac] /usr/local/gump/public/workspace/jakarta-commons-sandbox/resources/src/java/org/apache/commons/resources/impl/IBatisResources.java:38: package com.ibatis.db.sqlmap does not exist [javac] import com.ibatis.db.sqlmap.SqlMap; [javac] ^ [javac] /usr/local/gump/public/workspace/jakarta-commons-sandbox/resources/src/java/org/apache/commons/resources/impl/IBatisResources.java:39: package com.ibatis.db.sqlmap does not exist [javac] import com.ibatis.db.sqlmap.XmlSqlMapBuilder; [javac] ^ [javac] /usr/local/gump/public/workspace/jakarta-commons-sandbox/resources/src/java/org/apache/commons/resources/impl/IBatisResources.java:64: cannot resolve symbol [javac] symbol : class SqlMap [javac] location: class org.apache.commons.resources.impl.IBatisResources [javac] protected static SqlMap sqlMap; [javac] ^ [javac] /usr/local/gump/public/workspace/jakarta-commons-sandbox/resources/src/java/org/apache/commons/resources/impl/IBatisResources.java:135: cannot resolve symbol [javac] symbol : variable XmlSqlMapBuilder [javac] location: class org.apache.commons.resources.impl.IBatisResources [javac] sqlMap =
[CONFIGURATION] [CfV] Commons Configuration Version 1.0
Hi, this is the Call for Votes (CfV) for the release of Commons Configuration 1.0. I was volunteered as release manager so I will do this release, build release jars and send out announcements. Please vote now: [ ] +1 - Yes [ ] 0 - I don't care [ ] -1 - No My vote is (obviously) +1 Regards Hennig -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Fighting for one's political stand is an honorable action, but re- fusing to acknowledge that there might be weaknesses in one's position - in order to identify them so that they can be remedied - is a large enough problem with the Open Source movement that it deserves to be on this list of the top five problems. -- Michelle Levesque, Fundamental Issues with Open Source Software Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] XMLOutput.data(Object)
So what's the advantage over this versus the context. XMLOutput is for producing output, not storing data. The context is for storing data. Paul, I must be missing something obvious here. On Wed, 6 Oct 2004 10:37:21 +0200, Paul Libbrecht [EMAIL PROTECTED] wrote: It does differ only by the fact that you write an Object and not XML-nodes! Only, this tiny change to be able to invoke the sacred functional word. paul Le 6 oct. 04, à 10:12, Dion Gillard a écrit : How does this differ from writing to XMLOutput. It seems XMLOutput is being confused with the context...? On Wed, 6 Oct 2004 09:54:11 +0200, Paul Libbrecht [EMAIL PROTECTED] wrote: Maybe one little quick example: - currently, jelly-swing's ComponentTag calls, somewhere down in its doTag() findAncestorWithClass(ContainerTag.class) to which they call addComponent... At least one major drawback: putting such in a defined tag does not work unless you go till the top-level container in the defined tag (so no re-used swing script-snippets). Many other issues... - proposed: jelly-swing's ComponentTag should call, in its doTag(), xmlOutput.data(myBean) Advantage: works with scripts. - currently: jelly-sql can only define variables with the current result-sets Instead, the result-set could be given as data and the latter be transformed by some other tags (e.g. a tag that would merge the fields, or extract the only interesting ones). Overall, the idea is to have the ability for a tag to give return value that is not XML. I could produce many more scenarios. Most probably that should affect UseBeanTag... though maybe not at first launch. I would propose to enrich XMLOutput class itself (by adding the method doing the default toString). This should really bother the release, I believe. Then I'd like to concentrate on using this jelly-swing, with the hope to be able to make a jelly-swing-runner as a browser (maybe for jelly-swing 1.1 or so). paul Le 6 oct. 04, à 00:05, Dion Gillard a écrit : I'm not sure I understand what the use of this method is for Tags and TagLibraries, since it's on XML output. Can you give us an idea? On Tue, 5 Oct 2004 21:31:08 +0200, Paul Libbrecht [EMAIL PROTECTED] wrote: Dear Jellyers, I'd like to propose an addition to the XMLOutput class, used throughout Jelly: a method called data() (or object) accepting any object. By default... take the toString and call characters... Actually, this is the way it is done with the return value of a Jexl expression as part of a text node. But the interesting comes in the non-default case: - a math library could return a polynomial or numerical type... and this could then be further evaluated by parents - the arg element of jelly could actually avoid special treatment as it has currently - most of my interest applies for jelly-swing: the components would then want to call data(component) on the xmlOutput. The latter could be filtered by constraint-tags to call data(component-with-constraints). Finally, container tags could, also, filter, and receive the resulting data and add it. I would look forward to comments ! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.multitask.com.au/people/dion/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.multitask.com.au/people/dion/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31560] New: - FTPClient.listFiles method returns null for some files
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=31560. 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=31560 FTPClient.listFiles method returns null for some files Summary: FTPClient.listFiles method returns null for some files Product: Commons Version: unspecified Platform: PC OS/Version: Windows XP Status: NEW Severity: Normal Priority: Other Component: Net AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] There's problem in regullar expression in class org.apache.commons.net.ftp.parser.UnixFTPEntryParser which causes that files with lastmodified attribute from 0 to 1 a.m. are not listed by ftpclient listFiles method. Example: This file is listed correctly: -rwxrwxrwx 1 owner group 5127 Sep 24 11:44 somefile_tst_200409192_v105_breq.xml For this, listFiles method returns null: -rwxrwxrwx 1 owner group 5127 Sep 20 0:32 somefile_tst_200409192_v101_breq.xml Problem seems to be in: private static final String REGEX = ([bcdlfmpSs-]) + (((r|-)(w|-)([xsStTL-]))((r|-)(w|-)([xsStTL-]))((r|-)(w|-)([xsStTL-])))\\s+ + (\\d+)\\s+ + (\\S+)\\s+ + (?:(\\S+)\\s+)? + (\\d+)\\s+ + MONTHS + \\s+ + ((?:[0-9])|(?:[0-2][0-9])|(?:3[0-1]))\\s+ + ((\\d\\d\\d\\d)|((?:[01]\\d)|(?:2[0123])|(?:[1-9])):([012345]\\d))\\s+ + (\\S+)(\\s*.*); where correct expression should be like this (0 insted of 1): private static final String REGEX = ([bcdlfmpSs-]) + (((r|-)(w|-)([xsStTL-]))((r|-)(w|-)([xsStTL-]))((r|-)(w|-)([xsStTL-])))\\s+ + (\\d+)\\s+ + (\\S+)\\s+ + (?:(\\S+)\\s+)? + (\\d+)\\s+ + MONTHS + \\s+ + ((?:[0-9])|(?:[0-2][0-9])|(?:3[0-1]))\\s+ + ((\\d\\d\\d\\d)|((?:[01]\\d)|(?:2[0123])|(?:[0-9])):([012345]\\d))\\s+ + (\\S+)(\\s*.*); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] handling exceptions in AbstractConfiguration implementations
Hi Ricardo.. Sounds like you are working on something I've been wanting for a long time! At any rate.. I believe there is a ConfigurationRuntimeException that you could throw, even though it's not part of the API. I think the reason that most of the gets don't throw an exception is because 99% of the time if you throw an exception then the calling class will just have to rethrow it. In otherwords, say I am using a Configuration object in my code, and I do configuration.getDouble(key);. If getDouble throws an exception then I am going to have these try/catch cluases all over the place, cluttering the code. and, I really except getDouble() to allows work. If it doesn't, my application will just pass it on,not have some sort of fancy if getDouble fails, then try getString or something weird. I think what you can do is just wrap your HibernateException in a ConfiguratoinRuntimeException and toss that. JDBCConfiguration should probably be doning the same thing. Eric -Original Message- From: Ricardo Gladwell [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 06, 2004 12:56 PM To: Jakarta Commons Developers List Subject: [configuration] handling exceptions in AbstractConfiguration implementations Hi All, I'm currently developing a sub-class of the AbstractConfiguration classthat uses Hibernate to access configuration properties (unimaginatively called Hibernate Configuration). I'm slightly concerned about the way sub-classes are suposed to handle exceptions: All the abstract method are defined as not throwing exceptions. All calls to hibernate, however, throw HibernateExceptions. So, for example, my implementation of getPropertyDirect calls the hibernate Session.get() method which can throw an exception. Looking at your implementation of the DatabaseConfiguration I can see that it simply consumes SQLExceptions thrown from the JDBC API, logging the stack trace. However, what if you want to be warned of exceptions being thrown by the underlying implementation of Configuration? I notice you already have a nestable ConfigurationException implemented. Surely, all Configuration methods should indicate they will throw this exception if they are expected to read/write data? Also, the AbstractConfiguration class does not describe this contract (logging all errors throw by underlying framework) or what should be returned in the event of an error? I assume you should return null values but this is not described anywhere. Kind regards, -- Ricardo Gladwell - 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: [CONFIGURATION] [CfV] Commons Configuration Version 1.0
Please vote now: [X] +1 - Yes [ ] 0 - I don't care [ ] -1 - No - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-150) j:forEach tag not properly using varStatus attribute
The following comment has been added to this issue: Author: dion gillard Created: Wed, 6 Oct 2004 4:58 AM Body: Any comments on my patch? It seems to resolve the concerns we have about adding jstl to the dependencies, and it works. - View this comment: http://issues.apache.org/jira/browse/JELLY-150?page=comments#action_53751 - View the issue: http://issues.apache.org/jira/browse/JELLY-150 Here is an overview of the issue: - Key: JELLY-150 Summary: j:forEach tag not properly using varStatus attribute Type: Bug Status: Unassigned Priority: Major Project: jelly Components: core / taglib.core Versions: 1.0-beta-4 1.0 1.1-beta-1 jface-1.0-beta-1 jface-1.0 swt-1.0 1.0-beta-5 Assignee: Reporter: Ben Anderson Created: Fri, 24 Sep 2004 4:57 AM Updated: Wed, 6 Oct 2004 4:58 AM Environment: win2k / cygwin Description: According to the jstl specification 1.1, the varStatus attribute of the forEach tag should create a variable with type javax.servlet.jsp.jstl.core.LoopTagStatus. Currently a variable is set with type Integer which contains the index of the current iteration. I created a test case (I don't think any existed for forEach) that demonstrates this. I also began making the fix, but it doesn't fully work. I am submitting my patch along with the test cases. The comments I placed in the code should be enough to tip someone off as to why it's not working (I hope). I am relatively new to jelly (been using the standard taglibs for awhile) and have never opened the source before. I am willing to complete the patch, but will probably need some guidance because I messed with it for awhile before determing I couldn't complete without some help. Thanks! :-) - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] handling exceptions in AbstractConfiguration implementations
Eric Pugh wrote:
Hi Ricardo.. Sounds like you are working on something I've been wanting for
a long time!
Of course, I was going to release it anyway so please find the
source-code attached. Not sure it belongs in commons-configration API;
probably better contributed to the hibernate project. If you can think
of any improvements please mail the patches back to me for my own project :)
In otherwords, say I am using a Configuration object in my code, and I do
configuration.getDouble(key);. If getDouble throws an exception then I am
going to have these try/catch cluases all over the place, cluttering the
code. and, I really except getDouble() to allows work. If it doesn't, my
application will just pass it on,not have some sort of fancy if getDouble
fails, then try getString or something weird.
Good point, although I'm still dubious about throwing RuntimeExceptions
- those things shoot straight through everything like a silver bullet
and can even crash some servlet engines.
From my perspective, I'm not bothered if the Configuration object
throws exceptions: I wouldn't catch such exceptions in my web
application, instead letting them fly all the way to the exception
screen. This way, I can see them occuring as I test my application
through the browser.
Obviously, sometimes when configuring your application you just want
your configuration to work or keep on working untill if it encounters an
errors. However, simply allowing your application to ignore exceptions
until they create new exception elsewhere seems like a good way to
create hard-to-fix bugs. Surely, it would be better to relay the errors
and let the application decide what to do with them?
I think what you can do is just wrap your HibernateException in a
ConfiguratoinRuntimeException and toss that. JDBCConfiguration should
probably be doning the same thing.
Another alternative would be to have a getExceptions() method for all
Configurations which stores exceptions occuring and stores them for
later reporting. A good comprimise would be to allow all Configuration
objects to have two modes: one where exceptions are thrown as soon as
they occur and another one which stores exceptions as I suggested.
Kind regards,
-- Ricardo Gladwell
-Original Message-
From: Ricardo Gladwell [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 06, 2004 12:56 PM
To: Jakarta Commons Developers List
Subject: [configuration] handling exceptions in AbstractConfiguration
implementations
Hi All,
I'm currently developing a sub-class of the AbstractConfiguration
classthat uses Hibernate to access configuration properties
(unimaginatively called Hibernate Configuration). I'm slightly concerned
about the way sub-classes are suposed to handle exceptions:
All the abstract method are defined as not throwing exceptions. All
calls to hibernate, however, throw HibernateExceptions. So, for example,
my implementation of getPropertyDirect calls the hibernate Session.get()
method which can throw an exception.
Looking at your implementation of the DatabaseConfiguration I can see
that it simply consumes SQLExceptions thrown from the JDBC API, logging
the stack trace. However, what if you want to be warned of exceptions
being thrown by the underlying implementation of Configuration?
I notice you already have a nestable ConfigurationException implemented.
Surely, all Configuration methods should indicate they will throw this
exception if they are expected to read/write data?
Also, the AbstractConfiguration class does not describe this contract
(logging all errors throw by underlying framework) or what should be
returned in the event of an error? I assume you should return null
values but this is not described anywhere.
Kind regards,
-- Ricardo Gladwell
package net.sf.jexus.server.components;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import java.util.Iterator;
import java.util.List;
import net.sf.hibernate.HibernateException;
import net.sf.hibernate.Session;
import net.sf.hibernate.Transaction;
import net.sf.jexus.server.data.object.ConfigurationProperty;
import org.apache.commons.beanutils.ConvertUtils;
import org.apache.commons.configuration.AbstractConfiguration;
/**
* pHibernate configuation class. Reads configuration infomation from a
* database through the a href=http://www.hibernate.org/;Hibernate/a
* O/R mapping API. Data is stored as name-value pairs, along with the class
* information of data stored, using the mapping* defined by the
* [EMAIL PROTECTED] ConfigurationProperty} POJO hibernate xdoclet directives. Values
are
* converted to and from strings using
* [EMAIL PROTECTED] org.apache.commons.beanutils.ConvertUtils}./p
*
* @author a href=mailto:[EMAIL PROTECTED]Ricardo Gladwell/a
*/
public class HibernateConfiguration extends AbstractConfiguration {
/**
* Logger for this class
*/
private static final Log log = LogFactory.getLog(HibernateConfiguration.class);
/**
DO NOT REPLY [Bug 31561] New: - javadoc - 'four basic XML entities' should be 5 (apos is missing)
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=31561. 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=31561 javadoc - 'four basic XML entities' should be 5 (apos is missing) Summary: javadoc - 'four basic XML entities' should be 5 (apos is missing) Product: Commons Version: unspecified Platform: All URL: http://jakarta.apache.org/commons/lang/api/org/apache/co mmons/lang/StringEscapeUtils.html#escapeXml(java.lang.St ring) OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Lang AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] in class codeStringEscapeUtils/code, the javadoc of the methods codepublic static String escapeXml(String str)/code and codepublic static String unescapeXml(String str)/code says: 'Supports only the four basic XML entities (gt, lt, quot, amp).' It should say 'Supports only the five basic XML entities (gt, lt, quot, amp, apos).' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-150) j:forEach tag not properly using varStatus attribute
The following comment has been added to this issue: Author: Ben Anderson Created: Wed, 6 Oct 2004 5:12 AM Body: Well, that certainly will work. Off course that's getting away from standards for no legitimate reason. Just to add the discussion - the jstl.jar IS on ibiblio's repository and it's a whopping 20k. Standard taglibs does ship with it. I don't see what the big deal is. IMHO, Jelly should either decide to include this dependency or else take all the jstl claims off the front page: http://jakarta.apache.org/commons/jelly/ - View this comment: http://issues.apache.org/jira/browse/JELLY-150?page=comments#action_53752 - View the issue: http://issues.apache.org/jira/browse/JELLY-150 Here is an overview of the issue: - Key: JELLY-150 Summary: j:forEach tag not properly using varStatus attribute Type: Bug Status: Unassigned Priority: Major Project: jelly Components: core / taglib.core Versions: 1.0-beta-4 1.0 1.1-beta-1 jface-1.0-beta-1 jface-1.0 swt-1.0 1.0-beta-5 Assignee: Reporter: Ben Anderson Created: Fri, 24 Sep 2004 4:57 AM Updated: Wed, 6 Oct 2004 5:12 AM Environment: win2k / cygwin Description: According to the jstl specification 1.1, the varStatus attribute of the forEach tag should create a variable with type javax.servlet.jsp.jstl.core.LoopTagStatus. Currently a variable is set with type Integer which contains the index of the current iteration. I created a test case (I don't think any existed for forEach) that demonstrates this. I also began making the fix, but it doesn't fully work. I am submitting my patch along with the test cases. The comments I placed in the code should be enough to tip someone off as to why it's not working (I hope). I am relatively new to jelly (been using the standard taglibs for awhile) and have never opened the source before. I am willing to complete the patch, but will probably need some guidance because I messed with it for awhile before determing I couldn't complete without some help. Thanks! :-) - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] handling exceptions in AbstractConfiguration implementations
Problem with having Hibernate implementations is that the license is incompatible with the ASL. So you'll need to keep any incompatible code somewhere elselike I do with commons-resources at sf.net. -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: Ricardo Gladwell [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Wednesday, October 06, 2004 8:07 AM Subject: Re: [configuration] handling exceptions in AbstractConfiguration implementations Eric Pugh wrote: Hi Ricardo.. Sounds like you are working on something I've been wanting for a long time! Of course, I was going to release it anyway so please find the source-code attached. Not sure it belongs in commons-configration API; probably better contributed to the hibernate project. If you can think of any improvements please mail the patches back to me for my own project :) In otherwords, say I am using a Configuration object in my code, and I do configuration.getDouble(key);. If getDouble throws an exception then I am going to have these try/catch cluases all over the place, cluttering the code. and, I really except getDouble() to allows work. If it doesn't, my application will just pass it on,not have some sort of fancy if getDouble fails, then try getString or something weird. Good point, although I'm still dubious about throwing RuntimeExceptions - those things shoot straight through everything like a silver bullet and can even crash some servlet engines. From my perspective, I'm not bothered if the Configuration object throws exceptions: I wouldn't catch such exceptions in my web application, instead letting them fly all the way to the exception screen. This way, I can see them occuring as I test my application through the browser. Obviously, sometimes when configuring your application you just want your configuration to work or keep on working untill if it encounters an errors. However, simply allowing your application to ignore exceptions until they create new exception elsewhere seems like a good way to create hard-to-fix bugs. Surely, it would be better to relay the errors and let the application decide what to do with them? I think what you can do is just wrap your HibernateException in a ConfiguratoinRuntimeException and toss that. JDBCConfiguration should probably be doning the same thing. Another alternative would be to have a getExceptions() method for all Configurations which stores exceptions occuring and stores them for later reporting. A good comprimise would be to allow all Configuration objects to have two modes: one where exceptions are thrown as soon as they occur and another one which stores exceptions as I suggested. Kind regards, -- Ricardo Gladwell -Original Message- From: Ricardo Gladwell [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 06, 2004 12:56 PM To: Jakarta Commons Developers List Subject: [configuration] handling exceptions in AbstractConfiguration implementations Hi All, I'm currently developing a sub-class of the AbstractConfiguration classthat uses Hibernate to access configuration properties (unimaginatively called Hibernate Configuration). I'm slightly concerned about the way sub-classes are suposed to handle exceptions: All the abstract method are defined as not throwing exceptions. All calls to hibernate, however, throw HibernateExceptions. So, for example, my implementation of getPropertyDirect calls the hibernate Session.get() method which can throw an exception. Looking at your implementation of the DatabaseConfiguration I can see that it simply consumes SQLExceptions thrown from the JDBC API, logging the stack trace. However, what if you want to be warned of exceptions being thrown by the underlying implementation of Configuration? I notice you already have a nestable ConfigurationException implemented. Surely, all Configuration methods should indicate they will throw this exception if they are expected to read/write data? Also, the AbstractConfiguration class does not describe this contract (logging all errors throw by underlying framework) or what should be returned in the event of an error? I assume you should return null values but this is not described anywhere. Kind regards, -- Ricardo Gladwell package net.sf.jexus.server.components; import org.apache.commons.logging.Log; import org.apache.commons.logging.LogFactory; import java.util.Iterator; import java.util.List; import net.sf.hibernate.HibernateException; import net.sf.hibernate.Session; import net.sf.hibernate.Transaction; import net.sf.jexus.server.data.object.ConfigurationProperty; import org.apache.commons.beanutils.ConvertUtils; import org.apache.commons.configuration.AbstractConfiguration; /** * pHibernate
[jira] Commented: (JELLY-150) j:forEach tag not properly using varStatus attribute
The following comment has been added to this issue: Author: dion gillard Created: Wed, 6 Oct 2004 5:39 AM Body: Off course that's getting away from standards for no legitimate reason. The reason, so far, has been licensing and details about jstl.jar. If it's part of the standard taglibs from Apache, then fine. However, jars from Sun licensed under their Binary Code License have not been previously allowed to be distributed on ibiblio. I'm happy if we can depend on jstl.jar as the sources are part of the standard taglib. See http://cvs.apache.org/viewcvs.cgi/jakarta-taglibs/standard/src/javax/servlet/jsp/jstl/core/LoopTagStatus.java?rev=1.4.2.1only_with_tag=STANDARD_1_0_BRANCHview=markup So. If I replace the custom LoopStatus in ForEachTag with the JSTL one, and keep the rest, what is the difference between our patches? - View this comment: http://issues.apache.org/jira/browse/JELLY-150?page=comments#action_53753 - View the issue: http://issues.apache.org/jira/browse/JELLY-150 Here is an overview of the issue: - Key: JELLY-150 Summary: j:forEach tag not properly using varStatus attribute Type: Bug Status: Unassigned Priority: Major Project: jelly Components: core / taglib.core Versions: 1.0-beta-4 1.0 1.1-beta-1 jface-1.0-beta-1 jface-1.0 swt-1.0 1.0-beta-5 Assignee: Reporter: Ben Anderson Created: Fri, 24 Sep 2004 4:57 AM Updated: Wed, 6 Oct 2004 5:39 AM Environment: win2k / cygwin Description: According to the jstl specification 1.1, the varStatus attribute of the forEach tag should create a variable with type javax.servlet.jsp.jstl.core.LoopTagStatus. Currently a variable is set with type Integer which contains the index of the current iteration. I created a test case (I don't think any existed for forEach) that demonstrates this. I also began making the fix, but it doesn't fully work. I am submitting my patch along with the test cases. The comments I placed in the code should be enough to tip someone off as to why it's not working (I hope). I am relatively new to jelly (been using the standard taglibs for awhile) and have never opened the source before. I am willing to complete the patch, but will probably need some guidance because I messed with it for awhile before determing I couldn't complete without some help. Thanks! :-) - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [CONFIGURATION] [CfV] Commons Configuration Version 1.0
Hi, Please vote now: [ X ] +1 - Yes [ ] 0 - I don't care [ ] -1 - No Yes, definitely, it's about time ;) Thanks for making this happen, Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-150) j:forEach tag not properly using varStatus attribute
The following comment has been added to this issue: Author: dion gillard Created: Wed, 6 Oct 2004 5:46 AM Body: Differences from memory: - You are creating a new LoopTagStatus class each time through the loop, I was reusing a single instance. - You only handled one branch in the ForEachTag code. - You removed the indexVar, whereas I left it alone. - Your logic for isLast is easier, but relies on the itemsSize private variable, which should be declared inside doTag, and which doesn't handle iterators. I'm also not sure we're going for a completely compatible JSTL implementation, as our EL is slightly different. As you say, we possibly should remove that chunk on the homepage. - View this comment: http://issues.apache.org/jira/browse/JELLY-150?page=comments#action_53754 - View the issue: http://issues.apache.org/jira/browse/JELLY-150 Here is an overview of the issue: - Key: JELLY-150 Summary: j:forEach tag not properly using varStatus attribute Type: Bug Status: Unassigned Priority: Major Project: jelly Components: core / taglib.core Versions: 1.0-beta-4 1.0 1.1-beta-1 jface-1.0-beta-1 jface-1.0 swt-1.0 1.0-beta-5 Assignee: Reporter: Ben Anderson Created: Fri, 24 Sep 2004 4:57 AM Updated: Wed, 6 Oct 2004 5:46 AM Environment: win2k / cygwin Description: According to the jstl specification 1.1, the varStatus attribute of the forEach tag should create a variable with type javax.servlet.jsp.jstl.core.LoopTagStatus. Currently a variable is set with type Integer which contains the index of the current iteration. I created a test case (I don't think any existed for forEach) that demonstrates this. I also began making the fix, but it doesn't fully work. I am submitting my patch along with the test cases. The comments I placed in the code should be enough to tip someone off as to why it's not working (I hope). I am relatively new to jelly (been using the standard taglibs for awhile) and have never opened the source before. I am willing to complete the patch, but will probably need some guidance because I messed with it for awhile before determing I couldn't complete without some help. Thanks! :-) - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-150) j:forEach tag not properly using varStatus attribute
The following comment has been added to this issue: Author: Ben Anderson Created: Wed, 6 Oct 2004 5:56 AM Body: snip If I replace the custom LoopStatus in ForEachTag with the JSTL one, and keep the rest, what is the difference between our patches? /snip Are there any good tools for comparing or injecting diffs? I want to do a diff on my files vs. your files instead of your diff vs my diff. Sorry, like I said I'm new to Apache development, so diff(unified formart)/svn/etc. is all new to me. I think you understand that the LoopTagStatus in jstl.jar is only interface, right? We'll still need to implement it - probably in an inner class... whether it's anonymous or not I don't really care. I think being an inner class is fine, because it's not used by any other classes. - View this comment: http://issues.apache.org/jira/browse/JELLY-150?page=comments#action_53755 - View the issue: http://issues.apache.org/jira/browse/JELLY-150 Here is an overview of the issue: - Key: JELLY-150 Summary: j:forEach tag not properly using varStatus attribute Type: Bug Status: Unassigned Priority: Major Project: jelly Components: core / taglib.core Versions: 1.0-beta-4 1.0 1.1-beta-1 jface-1.0-beta-1 jface-1.0 swt-1.0 1.0-beta-5 Assignee: Reporter: Ben Anderson Created: Fri, 24 Sep 2004 4:57 AM Updated: Wed, 6 Oct 2004 5:56 AM Environment: win2k / cygwin Description: According to the jstl specification 1.1, the varStatus attribute of the forEach tag should create a variable with type javax.servlet.jsp.jstl.core.LoopTagStatus. Currently a variable is set with type Integer which contains the index of the current iteration. I created a test case (I don't think any existed for forEach) that demonstrates this. I also began making the fix, but it doesn't fully work. I am submitting my patch along with the test cases. The comments I placed in the code should be enough to tip someone off as to why it's not working (I hope). I am relatively new to jelly (been using the standard taglibs for awhile) and have never opened the source before. I am willing to complete the patch, but will probably need some guidance because I messed with it for awhile before determing I couldn't complete without some help. Thanks! :-) - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] handling exceptions in AbstractConfiguration implementations
I tried hitting commons-resources.sf.net but no joy.. I think this licensing thing is going to bite a lot of projects.. I was thinking of settingup a sf project called hibernatecodethatiwantedatapache.sf.net where I could toss all these bits and pieces. Has Jakarta-Commons actually set up a parralel site on SF to work around these issues? ERic -Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 06, 2004 2:15 PM To: Jakarta Commons Developers List Subject: Re: [configuration] handling exceptions in AbstractConfiguration implementations Problem with having Hibernate implementations is that the license is incompatible with the ASL. So you'll need to keep any incompatible code somewhere elselike I do with commons-resources at sf.net. -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: Ricardo Gladwell [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Wednesday, October 06, 2004 8:07 AM Subject: Re: [configuration] handling exceptions in AbstractConfiguration implementations Eric Pugh wrote: Hi Ricardo.. Sounds like you are working on something I've been wanting for a long time! Of course, I was going to release it anyway so please find the source-code attached. Not sure it belongs in commons-configration API; probably better contributed to the hibernate project. If you can think of any improvements please mail the patches back to me for my own project :) In otherwords, say I am using a Configuration object in my code, and I do configuration.getDouble(key);. If getDouble throws an exception then I am going to have these try/catch cluases all over the place, cluttering the code. and, I really except getDouble() to allows work. If it doesn't, my application will just pass it on,not have some sort of fancy if getDouble fails, then try getString or something weird. Good point, although I'm still dubious about throwing RuntimeExceptions - those things shoot straight through everything like a silver bullet and can even crash some servlet engines. From my perspective, I'm not bothered if the Configuration object throws exceptions: I wouldn't catch such exceptions in my web application, instead letting them fly all the way to the exception screen. This way, I can see them occuring as I test my application through the browser. Obviously, sometimes when configuring your application you just want your configuration to work or keep on working untill if it encounters an errors. However, simply allowing your application to ignore exceptions until they create new exception elsewhere seems like a good way to create hard-to-fix bugs. Surely, it would be better to relay the errors and let the application decide what to do with them? I think what you can do is just wrap your HibernateException in a ConfiguratoinRuntimeException and toss that. JDBCConfiguration should probably be doning the same thing. Another alternative would be to have a getExceptions() method for all Configurations which stores exceptions occuring and stores them for later reporting. A good comprimise would be to allow all Configuration objects to have two modes: one where exceptions are thrown as soon as they occur and another one which stores exceptions as I suggested. Kind regards, -- Ricardo Gladwell -Original Message- From: Ricardo Gladwell [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 06, 2004 12:56 PM To: Jakarta Commons Developers List Subject: [configuration] handling exceptions in AbstractConfiguration implementations Hi All, I'm currently developing a sub-class of the AbstractConfiguration classthat uses Hibernate to access configuration properties (unimaginatively called Hibernate Configuration). I'm slightly concerned about the way sub-classes are suposed to handle exceptions: All the abstract method are defined as not throwing exceptions. All calls to hibernate, however, throw HibernateExceptions. So, for example, my implementation of getPropertyDirect calls the hibernate Session.get() method which can throw an exception. Looking at your implementation of the DatabaseConfiguration I can see that it simply consumes SQLExceptions thrown from the JDBC API, logging the stack trace. However, what if you want to be warned of exceptions being thrown by the underlying implementation of Configuration? I notice you already have a nestable ConfigurationException implemented. Surely, all Configuration methods should indicate they will throw this exception if they are expected to read/write data? Also, the AbstractConfiguration class does not describe this contract (logging all errors throw by underlying framework) or what should be returned in the event of
Re: [jelly] XMLOutput.data(Object)
Gee... I was really thinking this was obvious... hence the relatively undetailed descriptions. - XMLoutput objects are exchanged as part of the doTag nested calls. Therefore it is easy for something aimed at receiving data to create an XMLOutput object that does something just for the data() call, and passes-through for the rest. This way a tag can receive a return value. There's no way to do so with the context except delicate hacks and fragile naming-conventions. - The objects being exchanged aren't meant ot be stored. They are part of the process... i.e. when I write math:determinant math:product math:matri/math:matrix math:matri/math:matrix /math:product /math:determinant I am not storing the matrix of the product, I'm just passing it around. - to me, it makes loads of sense to have tags that transform their output... and that should apply to object-data as well. (so that adding a constraint in jelly-swing would be simply a transformation) - another fancy feature: the result of a bsf or beanshell script could be fed using this data() function... and thus used (it is currently only used when setting a variable) At least, to me, it is the only way for a component child, like a swing button, to talk flexibly to a component container, without manually walking the hierarchy. paul Le 6 oct. 04, à 13:19, Dion Gillard a écrit : So what's the advantage over this versus the context. XMLOutput is for producing output, not storing data. The context is for storing data. Paul, I must be missing something obvious here. On Wed, 6 Oct 2004 10:37:21 +0200, Paul Libbrecht [EMAIL PROTECTED] wrote: It does differ only by the fact that you write an Object and not XML-nodes! Only, this tiny change to be able to invoke the sacred functional word. paul Le 6 oct. 04, à 10:12, Dion Gillard a écrit : How does this differ from writing to XMLOutput. It seems XMLOutput is being confused with the context...? On Wed, 6 Oct 2004 09:54:11 +0200, Paul Libbrecht [EMAIL PROTECTED] wrote: Maybe one little quick example: - currently, jelly-swing's ComponentTag calls, somewhere down in its doTag() findAncestorWithClass(ContainerTag.class) to which they call addComponent... At least one major drawback: putting such in a defined tag does not work unless you go till the top-level container in the defined tag (so no re-used swing script-snippets). Many other issues... - proposed: jelly-swing's ComponentTag should call, in its doTag(), xmlOutput.data(myBean) Advantage: works with scripts. - currently: jelly-sql can only define variables with the current result-sets Instead, the result-set could be given as data and the latter be transformed by some other tags (e.g. a tag that would merge the fields, or extract the only interesting ones). Overall, the idea is to have the ability for a tag to give return value that is not XML. I could produce many more scenarios. Most probably that should affect UseBeanTag... though maybe not at first launch. I would propose to enrich XMLOutput class itself (by adding the method doing the default toString). This should really bother the release, I believe. Then I'd like to concentrate on using this jelly-swing, with the hope to be able to make a jelly-swing-runner as a browser (maybe for jelly-swing 1.1 or so). paul Le 6 oct. 04, à 00:05, Dion Gillard a écrit : I'm not sure I understand what the use of this method is for Tags and TagLibraries, since it's on XML output. Can you give us an idea? On Tue, 5 Oct 2004 21:31:08 +0200, Paul Libbrecht [EMAIL PROTECTED] wrote: Dear Jellyers, I'd like to propose an addition to the XMLOutput class, used throughout Jelly: a method called data() (or object) accepting any object. By default... take the toString and call characters... Actually, this is the way it is done with the return value of a Jexl expression as part of a text node. But the interesting comes in the non-default case: - a math library could return a polynomial or numerical type... and this could then be further evaluated by parents - the arg element of jelly could actually avoid special treatment as it has currently - most of my interest applies for jelly-swing: the components would then want to call data(component) on the xmlOutput. The latter could be filtered by constraint-tags to call data(component-with-constraints). Finally, container tags could, also, filter, and receive the resulting data and add it. I would look forward to comments ! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.multitask.com.au/people/dion/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For
Re: [configuration] handling exceptions in AbstractConfiguration implementations
I don't know about a parallel site, but I put my code under sf.net/projects/struts (just because I already use that repos) I'm not one of those letter-of-the-law types, but I don't want anything I work on to be accused of said infractions (Gawd!! I sound like one now ;) -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: Eric Pugh [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Wednesday, October 06, 2004 9:05 AM Subject: RE: [configuration] handling exceptions in AbstractConfiguration implementations I tried hitting commons-resources.sf.net but no joy.. I think this licensing thing is going to bite a lot of projects.. I was thinking of settingup a sf project called hibernatecodethatiwantedatapache.sf.net where I could toss all these bits and pieces. Has Jakarta-Commons actually set up a parralel site on SF to work around these issues? ERic -Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 06, 2004 2:15 PM To: Jakarta Commons Developers List Subject: Re: [configuration] handling exceptions in AbstractConfiguration implementations Problem with having Hibernate implementations is that the license is incompatible with the ASL. So you'll need to keep any incompatible code somewhere elselike I do with commons-resources at sf.net. -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: Ricardo Gladwell [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Wednesday, October 06, 2004 8:07 AM Subject: Re: [configuration] handling exceptions in AbstractConfiguration implementations Eric Pugh wrote: Hi Ricardo.. Sounds like you are working on something I've been wanting for a long time! Of course, I was going to release it anyway so please find the source-code attached. Not sure it belongs in commons-configration API; probably better contributed to the hibernate project. If you can think of any improvements please mail the patches back to me for my own project :) In otherwords, say I am using a Configuration object in my code, and I do configuration.getDouble(key);. If getDouble throws an exception then I am going to have these try/catch cluases all over the place, cluttering the code. and, I really except getDouble() to allows work. If it doesn't, my application will just pass it on,not have some sort of fancy if getDouble fails, then try getString or something weird. Good point, although I'm still dubious about throwing RuntimeExceptions - those things shoot straight through everything like a silver bullet and can even crash some servlet engines. From my perspective, I'm not bothered if the Configuration object throws exceptions: I wouldn't catch such exceptions in my web application, instead letting them fly all the way to the exception screen. This way, I can see them occuring as I test my application through the browser. Obviously, sometimes when configuring your application you just want your configuration to work or keep on working untill if it encounters an errors. However, simply allowing your application to ignore exceptions until they create new exception elsewhere seems like a good way to create hard-to-fix bugs. Surely, it would be better to relay the errors and let the application decide what to do with them? I think what you can do is just wrap your HibernateException in a ConfiguratoinRuntimeException and toss that. JDBCConfiguration should probably be doning the same thing. Another alternative would be to have a getExceptions() method for all Configurations which stores exceptions occuring and stores them for later reporting. A good comprimise would be to allow all Configuration objects to have two modes: one where exceptions are thrown as soon as they occur and another one which stores exceptions as I suggested. Kind regards, -- Ricardo Gladwell -Original Message- From: Ricardo Gladwell [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 06, 2004 12:56 PM To: Jakarta Commons Developers List Subject: [configuration] handling exceptions in AbstractConfiguration implementations Hi All, I'm currently developing a sub-class of the AbstractConfiguration classthat uses Hibernate to access configuration properties (unimaginatively called Hibernate Configuration). I'm slightly concerned about the way sub-classes are suposed to handle exceptions: All the abstract method are defined as not throwing exceptions. All calls to hibernate, however, throw HibernateExceptions. So, for example, my implementation of
Re: [configuration] handling exceptions in AbstractConfiguration implementations
P.S. Please find the JUnit test code attached. Ricardo Gladwell wrote: Eric Pugh wrote: Hi Ricardo.. Sounds like you are working on something I've been wanting for a long time! Of course, I was going to release it anyway so please find the source-code attached. Not sure it belongs in commons-configration API; probably better contributed to the hibernate project. If you can think of any improvements please mail the patches back to me for my own project :) In otherwords, say I am using a Configuration object in my code, and I do configuration.getDouble(key);. If getDouble throws an exception then I am going to have these try/catch cluases all over the place, cluttering the code. and, I really except getDouble() to allows work. If it doesn't, my application will just pass it on,not have some sort of fancy if getDouble fails, then try getString or something weird. Good point, although I'm still dubious about throwing RuntimeExceptions - those things shoot straight through everything like a silver bullet and can even crash some servlet engines. From my perspective, I'm not bothered if the Configuration object throws exceptions: I wouldn't catch such exceptions in my web application, instead letting them fly all the way to the exception screen. This way, I can see them occuring as I test my application through the browser. Obviously, sometimes when configuring your application you just want your configuration to work or keep on working untill if it encounters an errors. However, simply allowing your application to ignore exceptions until they create new exception elsewhere seems like a good way to create hard-to-fix bugs. Surely, it would be better to relay the errors and let the application decide what to do with them? I think what you can do is just wrap your HibernateException in a ConfiguratoinRuntimeException and toss that. JDBCConfiguration should probably be doning the same thing. Another alternative would be to have a getExceptions() method for all Configurations which stores exceptions occuring and stores them for later reporting. A good comprimise would be to allow all Configuration objects to have two modes: one where exceptions are thrown as soon as they occur and another one which stores exceptions as I suggested. Kind regards, -- Ricardo Gladwell -Original Message- From: Ricardo Gladwell [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 06, 2004 12:56 PM To: Jakarta Commons Developers List Subject: [configuration] handling exceptions in AbstractConfiguration implementations Hi All, I'm currently developing a sub-class of the AbstractConfiguration classthat uses Hibernate to access configuration properties (unimaginatively called Hibernate Configuration). I'm slightly concerned about the way sub-classes are suposed to handle exceptions: All the abstract method are defined as not throwing exceptions. All calls to hibernate, however, throw HibernateExceptions. So, for example, my implementation of getPropertyDirect calls the hibernate Session.get() method which can throw an exception. Looking at your implementation of the DatabaseConfiguration I can see that it simply consumes SQLExceptions thrown from the JDBC API, logging the stack trace. However, what if you want to be warned of exceptions being thrown by the underlying implementation of Configuration? I notice you already have a nestable ConfigurationException implemented. Surely, all Configuration methods should indicate they will throw this exception if they are expected to read/write data? Also, the AbstractConfiguration class does not describe this contract (logging all errors throw by underlying framework) or what should be returned in the event of an error? I assume you should return null values but this is not described anywhere. Kind regards, -- Ricardo Gladwell package net.sf.jexus.server.components; import org.apache.commons.logging.Log; import org.apache.commons.logging.LogFactory; import java.util.Iterator; import java.util.List; import net.sf.hibernate.HibernateException; import net.sf.hibernate.Session; import net.sf.hibernate.Transaction; import net.sf.jexus.server.data.object.ConfigurationProperty; import org.apache.commons.beanutils.ConvertUtils; import org.apache.commons.configuration.AbstractConfiguration; /** * pHibernate configuation class. Reads configuration infomation from a * database through the a href=http://www.hibernate.org/;Hibernate/a * O/R mapping API. Data is stored as name-value pairs, along with the class * information of data stored, using the mapping* defined by the * [EMAIL PROTECTED] ConfigurationProperty} POJO hibernate xdoclet directives. Values are * converted to and from strings using * [EMAIL PROTECTED] org.apache.commons.beanutils.ConvertUtils}./p * * @author a href=mailto:[EMAIL PROTECTED]Ricardo Gladwell/a */ public class HibernateConfiguration extends
[jira] Commented: (JELLY-150) j:forEach tag not properly using varStatus attribute
The following comment has been added to this issue: Author: Ben Anderson Created: Wed, 6 Oct 2004 6:54 AM Body: - You are creating a new LoopTagStatus class each time through the loop, I was reusing a single instance. agreed - good catch! - You only handled one branch in the ForEachTag code. I'm unsure what you mean here. - You removed the indexVar, whereas I left it alone. agreed - better to leave it. - Your logic for isLast is easier, but relies on the itemsSize private variable, which should be declared inside doTag, and which doesn't handle iterators. agreed - I new I didn't do that the best way, but wasn't sure how to do it better. Yours looks good! - View this comment: http://issues.apache.org/jira/browse/JELLY-150?page=comments#action_53758 - View the issue: http://issues.apache.org/jira/browse/JELLY-150 Here is an overview of the issue: - Key: JELLY-150 Summary: j:forEach tag not properly using varStatus attribute Type: Bug Status: Unassigned Priority: Major Project: jelly Components: core / taglib.core Versions: 1.0-beta-4 1.0-beta-5 swt-1.0 jface-1.0 jface-1.0-beta-1 1.1-beta-1 1.0 Assignee: Reporter: Ben Anderson Created: Fri, 24 Sep 2004 4:57 AM Updated: Wed, 6 Oct 2004 6:54 AM Environment: win2k / cygwin Description: According to the jstl specification 1.1, the varStatus attribute of the forEach tag should create a variable with type javax.servlet.jsp.jstl.core.LoopTagStatus. Currently a variable is set with type Integer which contains the index of the current iteration. I created a test case (I don't think any existed for forEach) that demonstrates this. I also began making the fix, but it doesn't fully work. I am submitting my patch along with the test cases. The comments I placed in the code should be enough to tip someone off as to why it's not working (I hope). I am relatively new to jelly (been using the standard taglibs for awhile) and have never opened the source before. I am willing to complete the patch, but will probably need some guidance because I messed with it for awhile before determing I couldn't complete without some help. Thanks! :-) - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[i18n] Did I miss something?
Wow, how did I miss this? I wonder what we can do with this and commons-resources and/or Apache Struts. In my current gig we are using a home grown solution in combination with ActionErrors/ActionMessages provided by Struts. This project would have been nice to have about 8 months ago. My immediate needs (scratching my own itch here) would be to help provide greater granularity for application messaging (similar to log levels) and perhaps a jsp taglib or two to help take advantage of this in my apps (this would probably go under Apache Struts contrib). So, with that said, I would like to volunteer to help with this project. Off the top of my head what I would like to do is: a) offer the same solution with the following alternate implementations: - properties file based configuration (more on this later) - RDBMS based configuration (I've already done this in commons-resources) b) Develop a Struts plug-in that will load and configure commons-i18n for my Struts applications. (I guess I could just add this as a plug-in under struts) c) The types of LocalizedMessages or LocalizedExceptions I can use are the following: - System error - Error - Warning - Alert - Flag - Info d) I would like to add an entry like: entry key=small-icon/images/some-icon-small.jpg/entry (also one for large-icon) e) New MessageManager impl that can assemble messages based on a config file who's entries simply point to existing i18n'd properties file(s) keys. (I will provide more details for this on my ShortTermPlans page http://wiki.apache.org/struts/ShortTermPlansForJamesMitchell) General questions: Is there any reason you did not use commons-logging? Can we change this to commons since it will (by default) delegate to the appropriate logging framework (let's eat our own dogfood)? Any reason you are using xml-importer instead of digester? I've read the docs on sf.net, but the advantages still aren't clear to me (I'm guessing it was just a personal choice made some time ago and you just stayed with it). Can we change this to use either (or use commons-configuration)? Have you thought about Spring integration? -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [CONFIGURATION] [CfV] Commons Configuration Version 1.0
Henning P. Schmiedehausen wrote: [ ] +1 - Yes [ ] 0 - I don't care [ +1 ] -1 - No I probably don't get a vote, but I would advise that there are still some changes, for example, to the way that commons-configuration defines exception handling before it is ready for prime-time. As I stated in my previous emails, we should at least make it clear in the Configuration interface or AbstractConfiguration class javadoc exactly how implementers should handle exceptions that are thrown from underlying frameworks, i.e. should they log errors, what values should be returned from methods calls that fail? Kind regards, -- Ricardo Gladwell - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Which version of JUnit do I use for test cases
I am trying to write some test cases for some commons code. A ways back I had a problem because I was using a newer version of JUnit than what was in the server build. What version of JUnit is acceptable? I am writing the test cases for commons-chain if that makes a difference. Thanks, sean - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [CONFIGURATION] [CfV] Commons Configuration Version 1.0
+1 ! There is still a lot to do but I'm really satisfied with the current state of [configuration]. I can't wait to start implementing the new features :) Emmanuel Bourg Henning P. Schmiedehausen wrote: Hi, this is the Call for Votes (CfV) for the release of Commons Configuration 1.0. I was volunteered as release manager so I will do this release, build release jars and send out announcements. Please vote now: [X] +1 - Yes [ ] 0 - I don't care [ ] -1 - No My vote is (obviously) +1 Regards Hennig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [CONFIGURATION] [CfV] Commons Configuration Version 1.0
Ricardo Gladwell wrote: I probably don't get a vote, but I would advise that there are still some changes, for example, to the way that commons-configuration defines exception handling before it is ready for prime-time. As I stated in my previous emails, we should at least make it clear in the Configuration interface or AbstractConfiguration class javadoc exactly how implementers should handle exceptions that are thrown from underlying frameworks, i.e. should they log errors, what values should be returned from methods calls that fail? I agree we'll have to think about a consistent exception handling in [configuration] but I don't think it's worth holding the 1.0 release for this reason. It can safely be added at a later time. Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] handling exceptions in AbstractConfiguration implementations
I don't want to sound harsh, but what is the added value of using Hibernate here for such a simple data structure ? A direct JDBC implementation is good enough and spare a 1.5MB dependency. Emmanuel Bourg Ricardo Gladwell wrote: Hi All, I'm currently developing a sub-class of the AbstractConfiguration classthat uses Hibernate to access configuration properties (unimaginatively called Hibernate Configuration). I'm slightly concerned about the way sub-classes are suposed to handle exceptions: All the abstract method are defined as not throwing exceptions. All calls to hibernate, however, throw HibernateExceptions. So, for example, my implementation of getPropertyDirect calls the hibernate Session.get() method which can throw an exception. Looking at your implementation of the DatabaseConfiguration I can see that it simply consumes SQLExceptions thrown from the JDBC API, logging the stack trace. However, what if you want to be warned of exceptions being thrown by the underlying implementation of Configuration? I notice you already have a nestable ConfigurationException implemented. Surely, all Configuration methods should indicate they will throw this exception if they are expected to read/write data? Also, the AbstractConfiguration class does not describe this contract (logging all errors throw by underlying framework) or what should be returned in the event of an error? I assume you should return null values but this is not described anywhere. Kind regards, -- Ricardo Gladwell - 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: [configuration] handling exceptions in AbstractConfiguration implementations
James Mitchell wrote: Problem with having Hibernate implementations is that the license is incompatible with the ASL. So you'll need to keep any incompatible code somewhere elselike I do with commons-resources at sf.net. AKAIK Hibernate is licensed under the LGPL and is perfectly compatible with the ASL. Building an HibernateConfiguration doesn't constitue a modification of Hibernate requiring its distribution under the LGPL. Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Which version of JUnit do I use for test cases
Well what about the latest ? (3.8.1) Emmanuel Bourg Sean Schofield wrote: I am trying to write some test cases for some commons code. A ways back I had a problem because I was using a newer version of JUnit than what was in the server build. What version of JUnit is acceptable? I am writing the test cases for commons-chain if that makes a difference. Thanks, sean - 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: Which version of JUnit do I use for test cases
Well what about the latest ? (3.8.1) Emmanuel Bourg That's what I'm going with. It's probably less of a concern now that the API is more stable. I think it was an issue when they had introduced some new test methods in the newest release and commons wasn't using it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] handling exceptions in AbstractConfiguration implementations
That is good to know. I am not a licensing expert. I'm just going off of a prior conversation Stefan Bodewig whom I assume is more knowledgeable than I wrt this issue. - Original Message - From: Stefan Bodewig [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, July 08, 2004 6:02 AM Subject: Re: [EMAIL PROTECTED]: jakarta-commons-sandbox/commons-resources success On Tue, 6 Jul 2004, James Mitchell [EMAIL PROTECTED] wrote: On Fri, 2 Jul 2004, Stefan Bodewig wrote: Please note also that Hibernate's license is LGPL. I did not realize that. Can we continue to build these with this dependency? I don't think so. At least you can't do a release with a dependency like this. (If not, I can always push them back up to the contrib folder) If the contrib folder is outside of an ASF CVS or SVN repository. Stefan -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: Emmanuel Bourg [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Wednesday, October 06, 2004 1:03 PM Subject: Re: [configuration] handling exceptions in AbstractConfiguration implementations James Mitchell wrote: Problem with having Hibernate implementations is that the license is incompatible with the ASL. So you'll need to keep any incompatible code somewhere elselike I do with commons-resources at sf.net. AKAIK Hibernate is licensed under the LGPL and is perfectly compatible with the ASL. Building an HibernateConfiguration doesn't constitue a modification of Hibernate requiring its distribution under the LGPL. Emmanuel Bourg - 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 31566] New: - [commons-chain] Support for new CatalogFactory
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=31566. 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=31566 [commons-chain] Support for new CatalogFactory Summary: [commons-chain] Support for new CatalogFactory Product: Commons Version: Nightly Builds Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: chain AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] We need a CatalogFactoryBase (int the 'impl' pacakage) to go along with the new CatalogFactory interace. I will submit the necessary file and test case. Craig, please ignore the CatalogFactoryBase that was sent to the commons-dev mailing list directly by me (yesterday). I fixed a minor bug that I discovered when I wrote my test case. I know ... that will learn me to write my test case first! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] handling exceptions in AbstractConfiguration implementations
One advantage for me is having the ability to reuse your existing application's configuration. I created a Hibernate, iBatis, Torque, DBUtils, and straight JDBC implementations for commons-resource for this very purpose. I moved the Hibernate impl over to sf.net because of license conflicts. -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: Emmanuel Bourg [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Wednesday, October 06, 2004 12:59 PM Subject: Re: [configuration] handling exceptions in AbstractConfiguration implementations I don't want to sound harsh, but what is the added value of using Hibernate here for such a simple data structure ? A direct JDBC implementation is good enough and spare a 1.5MB dependency. Emmanuel Bourg Ricardo Gladwell wrote: Hi All, I'm currently developing a sub-class of the AbstractConfiguration classthat uses Hibernate to access configuration properties (unimaginatively called Hibernate Configuration). I'm slightly concerned about the way sub-classes are suposed to handle exceptions: All the abstract method are defined as not throwing exceptions. All calls to hibernate, however, throw HibernateExceptions. So, for example, my implementation of getPropertyDirect calls the hibernate Session.get() method which can throw an exception. Looking at your implementation of the DatabaseConfiguration I can see that it simply consumes SQLExceptions thrown from the JDBC API, logging the stack trace. However, what if you want to be warned of exceptions being thrown by the underlying implementation of Configuration? I notice you already have a nestable ConfigurationException implemented. Surely, all Configuration methods should indicate they will throw this exception if they are expected to read/write data? Also, the AbstractConfiguration class does not describe this contract (logging all errors throw by underlying framework) or what should be returned in the event of an error? I assume you should return null values but this is not described anywhere. Kind regards, -- Ricardo Gladwell - 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]
DO NOT REPLY [Bug 31566] - [commons-chain] Support for new CatalogFactory
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=31566. 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=31566 [commons-chain] Support for new CatalogFactory --- Additional Comments From [EMAIL PROTECTED] 2004-10-06 17:26 --- Created an attachment (id=12961) [chain] CatalogFactoryBase - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31566] - [commons-chain] Support for new CatalogFactory
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=31566. 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=31566 [commons-chain] Support for new CatalogFactory --- Additional Comments From [EMAIL PROTECTED] 2004-10-06 17:27 --- Created an attachment (id=12962) [chain] ChainFactoryBaseTestCase - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31566] - [chain] Support for new CatalogFactory
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=31566. 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=31566 [chain] Support for new CatalogFactory [EMAIL PROTECTED] changed: What|Removed |Added Summary|[commons-chain] Support for |[chain] Support for new |new CatalogFactory |CatalogFactory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] handling exceptions in AbstractConfiguration implementations
Emmanuel Bourg wrote: I don't want to sound harsh, but what is the added value of using Hibernate here for such a simple data structure ? A direct JDBC implementation is good enough and spare a 1.5MB dependency. Nothing, AFAIK: the only reason I developed it was because I was using Hibernate in my own application and I just thought it would be nice if all database calls, including those for configuration, could be re-directed through the Hibernate API to take advantage of it's caching, logging, etc. I only posted it here to demonstrate the issue I was explaining and because of the interest - otherwise it will just sit in my project never reaching the wider world. Do what thou wilt with it :) Kind regards, -- Ricardo Ricardo Gladwell wrote: Hi All, I'm currently developing a sub-class of the AbstractConfiguration classthat uses Hibernate to access configuration properties (unimaginatively called Hibernate Configuration). I'm slightly concerned about the way sub-classes are suposed to handle exceptions: All the abstract method are defined as not throwing exceptions. All calls to hibernate, however, throw HibernateExceptions. So, for example, my implementation of getPropertyDirect calls the hibernate Session.get() method which can throw an exception. Looking at your implementation of the DatabaseConfiguration I can see that it simply consumes SQLExceptions thrown from the JDBC API, logging the stack trace. However, what if you want to be warned of exceptions being thrown by the underlying implementation of Configuration? I notice you already have a nestable ConfigurationException implemented. Surely, all Configuration methods should indicate they will throw this exception if they are expected to read/write data? Also, the AbstractConfiguration class does not describe this contract (logging all errors throw by underlying framework) or what should be returned in the event of an error? I assume you should return null values but this is not described anywhere. Kind regards, -- Ricardo Gladwell - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31566] - [chain] Support for new CatalogFactory
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=31566. 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=31566 [chain] Support for new CatalogFactory --- Additional Comments From [EMAIL PROTECTED] 2004-10-06 18:35 --- Created an attachment (id=12968) [chain] patch for CatalogFactory (same as submitted to 10/05 mailing list) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/discovery/src/java/org/apache/commons/discovery ResourceNameIterator.java
rsitze 2004/10/06 11:40:57
Modified:discovery/src/java/org/apache/commons/discovery
ResourceNameIterator.java
Log:
Revision ChangesPath
1.5 +12 -0
jakarta-commons/discovery/src/java/org/apache/commons/discovery/ResourceNameIterator.java
Index: ResourceNameIterator.java
===
RCS file:
/home/cvs/jakarta-commons/discovery/src/java/org/apache/commons/discovery/ResourceNameIterator.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- ResourceNameIterator.java 27 Feb 2004 23:36:54 - 1.4
+++ ResourceNameIterator.java 6 Oct 2004 18:40:57 - 1.5
@@ -17,15 +17,27 @@
/**
+ * Iterate over resource names.
+ * The semantics are somewhat unusual, for better or worse.
+ * hasNext is presumed to be destructive to the current state,
+ * each call will 'move' the cursor.
+ * nextResourceName() MUST BE non-destructive,
+ * it does not change the state.
+ *
+ * TODO: FIX iterator logic/semantics, possibly add 'currentResourceName()'.
+ *
* @author Richard A. Sitze
*/
public interface ResourceNameIterator
{
/**
+ * hasNext()
*/
public boolean hasNext();
/**
+ * nextResourceName() returns the name of the next resource,
+ * and MUST be non-destructive. Repeated calls
*/
public String nextResourceName();
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] handling exceptions in AbstractConfiguration implementations
This is really driving me crazy.. I have tracked threads on general and jakarta-pmc mailing lists about this.. And everytime it comes down to I am not a lawyer and a bunch of FUD. We really need someone from the top of Apache to provide direction. I work a lot with hibernate code and can think of at least 4 projects that have hibernate code in them (at least as far as import statements). Of course, I guess this isn't the right mailing list.. I could try and push this to some sort of conclusion, but I don't want to be told no! right now you can just pick your interpretation! Argh, Eric -Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 06, 2004 7:23 PM To: Jakarta Commons Developers List Subject: Re: [configuration] handling exceptions in AbstractConfiguration implementations One advantage for me is having the ability to reuse your existing application's configuration. I created a Hibernate, iBatis, Torque, DBUtils, and straight JDBC implementations for commons-resource for this very purpose. I moved the Hibernate impl over to sf.net because of license conflicts. -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: Emmanuel Bourg [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Wednesday, October 06, 2004 12:59 PM Subject: Re: [configuration] handling exceptions in AbstractConfiguration implementations I don't want to sound harsh, but what is the added value of using Hibernate here for such a simple data structure ? A direct JDBC implementation is good enough and spare a 1.5MB dependency. Emmanuel Bourg Ricardo Gladwell wrote: Hi All, I'm currently developing a sub-class of the AbstractConfiguration classthat uses Hibernate to access configuration properties (unimaginatively called Hibernate Configuration). I'm slightly concerned about the way sub-classes are suposed to handle exceptions: All the abstract method are defined as not throwing exceptions. All calls to hibernate, however, throw HibernateExceptions. So, for example, my implementation of getPropertyDirect calls the hibernate Session.get() method which can throw an exception. Looking at your implementation of the DatabaseConfiguration I can see that it simply consumes SQLExceptions thrown from the JDBC API, logging the stack trace. However, what if you want to be warned of exceptions being thrown by the underlying implementation of Configuration? I notice you already have a nestable ConfigurationException implemented. Surely, all Configuration methods should indicate they will throw this exception if they are expected to read/write data? Also, the AbstractConfiguration class does not describe this contract (logging all errors throw by underlying framework) or what should be returned in the event of an error? I assume you should return null values but this is not described anywhere. Kind regards, -- Ricardo Gladwell - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31500] - Problem in Reading the Bean containing another bean
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=31500. 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=31500 Problem in Reading the Bean containing another bean [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-10-06 20:09 --- By default, Betwixt assumes that collectives should be wrapped in a containing element. For example, persons persons.../person /persons So, you need to configure Betwixt so that this behaviour is switched off with something like: beanReader.getXMLIntrospector().getConfiguration().setWrapCollectionsInElement(false); There is something about this in http://jakarta.apache.org/commons/betwixt/guide/binding.html but it's a little thin. A documentation patch would be gratefully received or add a FAQ to the wiki. BTW a good tip when you're having trouble with a reading configuration is to write out what you expect and see what the differences are. Cheers Robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31568] New: - ConvertUtilsBean: register converter for specific property
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=31568. 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=31568 ConvertUtilsBean: register converter for specific property Summary: ConvertUtilsBean: register converter for specific property Product: Commons Version: 1.5 Final Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Bean Utilities AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Currently, converters are selected only based on the class to which they convert objects. In general this works pretty well, but I've encountered cases, where this doesn't work out. For example, I'm using java.util.Date objects to represent points and intervals in time that are not completely specific, such as day of the week and month. Now I can easily write a Converter that uses SimpleDateFormat to convert string representations of these dates (Mon, Feb) to Date objects. When I register one of these converters with ConvertUtils(Bean), though, it preempts any conversion to Date. Something I clearly don't want as I have to deal with different kinds of dates. As a solution, I'd like to be able to register a converter for a specific property of a bean class, with a method this ConvertUtilsBean#register(Converter converter, java.lang.Class destinationClass, java.lang.Class beanClass, java.lang.String propertyName) Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/io/read ReadContext.java
rdonkin 2004/10/06 13:39:13
Modified:betwixt/src/java/org/apache/commons/betwixt/io/read
ReadContext.java
Log:
Fixed some of my sloppy coding :( Fix for issue #30990
Revision ChangesPath
1.9 +12 -1
jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/io/read/ReadContext.java
Index: ReadContext.java
===
RCS file:
/home/cvs/jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/io/read/ReadContext.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- ReadContext.java 4 Jul 2004 16:41:16 - 1.8
+++ ReadContext.java 6 Oct 2004 20:39:13 - 1.9
@@ -221,7 +221,18 @@
* or null if there has been no element mapped
*/
public String getCurrentElement() {
- return (String) elementMappingStack.peek();
+ String result = null;
+ int stackSize = elementMappingStack.size();
+ int i = 0;
+ while ( i stackSize ) {
+ Object mappedElement = elementMappingStack.peek(i);
+ if (mappedElement instanceof String) {
+ result = (String) mappedElement;
+ break;
+ }
+ --i;
+ }
+ return result;
}
/**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30990] - ClassCastException if TraceEnabled during parse of XML String
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=30990. 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=30990 ClassCastException if TraceEnabled during parse of XML String [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-10-06 20:43 --- My apologies - looks like some sloppy experimental code made it into HEAD. I've committed some code that tightens up the test. It's hard for me to test (there will only be problems with the last code in infrequently circumstances) so I'd be glad if you'd build from HEAD and retry. If the problem still isn't fixed then please reopen this bug report. Robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-150) j:forEach tag not properly using varStatus attribute
The following comment has been added to this issue: Author: dion gillard Created: Wed, 6 Oct 2004 2:18 PM Body: Ok, so general consensus is to add JSTL.jar and use an anonymous implementation of it instead of the LoopStatus class. Unless someone disagrees in the next few days, I'll commit a change to that effect. - View this comment: http://issues.apache.org/jira/browse/JELLY-150?page=comments#action_53787 - View the issue: http://issues.apache.org/jira/browse/JELLY-150 Here is an overview of the issue: - Key: JELLY-150 Summary: j:forEach tag not properly using varStatus attribute Type: Bug Status: Unassigned Priority: Major Project: jelly Components: core / taglib.core Versions: 1.0-beta-4 1.0 1.1-beta-1 jface-1.0-beta-1 jface-1.0 swt-1.0 1.0-beta-5 Assignee: Reporter: Ben Anderson Created: Fri, 24 Sep 2004 4:57 AM Updated: Wed, 6 Oct 2004 2:18 PM Environment: win2k / cygwin Description: According to the jstl specification 1.1, the varStatus attribute of the forEach tag should create a variable with type javax.servlet.jsp.jstl.core.LoopTagStatus. Currently a variable is set with type Integer which contains the index of the current iteration. I created a test case (I don't think any existed for forEach) that demonstrates this. I also began making the fix, but it doesn't fully work. I am submitting my patch along with the test cases. The comments I placed in the code should be enough to tip someone off as to why it's not working (I hope). I am relatively new to jelly (been using the standard taglibs for awhile) and have never opened the source before. I am willing to complete the patch, but will probably need some guidance because I messed with it for awhile before determing I couldn't complete without some help. Thanks! :-) - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/betwixt/xdocs/guide binding.xml
rdonkin 2004/10/06 14:38:06
Modified:betwixt/src/java/org/apache/commons/betwixt
XMLIntrospector.java
betwixt/src/java/org/apache/commons/betwixt/digester
AddDefaultsRule.java
betwixt/src/java/org/apache/commons/betwixt/strategy
PropertySuppressionStrategy.java
betwixt/src/test/org/apache/commons/betwixt/derived
TestWriteClass.java
betwixt/xdocs/guide binding.xml
Log:
Improved PropertySuppressionStrategy interface and documentation. Issue #31553.
Submitted by Christoph Gaffga.
Revision ChangesPath
1.38 +12 -3
jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/XMLIntrospector.java
Index: XMLIntrospector.java
===
RCS file:
/home/cvs/jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/XMLIntrospector.java,v
retrieving revision 1.37
retrieving revision 1.38
diff -u -r1.37 -r1.38
--- XMLIntrospector.java 4 Oct 2004 22:27:12 - 1.37
+++ XMLIntrospector.java 6 Oct 2004 21:38:05 - 1.38
@@ -1431,7 +1431,10 @@
if ( descriptors != null ) {
for (int i=0, size=descriptors.length; isize; i++) {
if (!getConfiguration().getPropertySuppressionStrategy()
- .suppressProperty(
descriptors[i].getPropertyType(), descriptors[i].getName())) {
+ .suppressProperty(
+beanClass,
+descriptors[i].getPropertyType(),
+descriptors[i].getName())) {
propertyDescriptors.add( descriptors[i] );
}
}
@@ -1446,7 +1449,10 @@
if ( descriptors != null ) {
for (int j=0, innerSize=descriptors.length;
jinnerSize; j++) {
if
(!getConfiguration().getPropertySuppressionStrategy()
- .suppressProperty(
descriptors[j].getPropertyType(), descriptors[j].getName())) {
+ .suppressProperty(
+ beanClass,
+descriptors[j].getPropertyType(),
+descriptors[j].getName())) {
propertyDescriptors.add( descriptors[j] );
}
}
@@ -1484,7 +1490,10 @@
PropertyDescriptor[] descriptors =
beanInfo.getPropertyDescriptors();
for (int j=0, descriptorLength=descriptors.length;
jdescriptorLength ; j++) {
if (!getConfiguration().getPropertySuppressionStrategy()
- .suppressProperty(
descriptors[j].getPropertyType(), descriptors[j].getName())) {
+ .suppressProperty(
+ beanClass,
+descriptors[j].getPropertyType(),
+descriptors[j].getName())) {
propertyDescriptors.add( descriptors[j] );
}
}
1.15 +4 -1
jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/digester/AddDefaultsRule.java
Index: AddDefaultsRule.java
===
RCS file:
/home/cvs/jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/digester/AddDefaultsRule.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- AddDefaultsRule.java 4 Oct 2004 21:50:35 - 1.14
+++ AddDefaultsRule.java 6 Oct 2004 21:38:05 - 1.15
@@ -110,7 +110,10 @@
continue;
}
if
(!getXMLIntrospector().getConfiguration().getPropertySuppressionStrategy()
-.suppressProperty(descriptor.getPropertyType(),
descriptor.getName())) {
+.suppressProperty(
+beanClass,
+descriptor.getPropertyType(),
+descriptor.getName())) {
Descriptor nodeDescriptor =
getXMLIntrospector().createXMLDescriptor(new BeanProperty(descriptor));
if (
DO NOT REPLY [Bug 31553] - [betwixt][Patch] PropertySuppressionStrategy.suppressProperty include the bean containing the property
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=31553. 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=31553 [betwixt][Patch] PropertySuppressionStrategy.suppressProperty include the bean containing the property [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-10-06 21:41 --- I've commit a variation upon your theme. The only substantive difference is that I think that the right class to take is the class of the bean (rather than that of the bean info which may potential be a superclass or superinterface). I believe that this should have no detrimental side effects but should be simpler for users to understand. Please reopen if I've overlooked anything... Some comments (in no particular order): 1. Attachments are good. 2. I'm very, very keen on preserving backwards compatibility. The commons guidelines say code which has been released should be deprecated before being incompatibly modified but are silent about development code. In Betwixt, we've tried to preserve compatibility even when the code has never been released but, in this case the code has only just been committed and so modifying the interface now seems best. 3. It did consider this but couldn't think of a good use case. Should probably have thought a little longer... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang CharEncoding.java
scolebourne2004/10/06 14:40:09 Modified:lang/src/java/org/apache/commons/lang CharEncoding.java Log: Javadoc Revision ChangesPath 1.2 +16 -30 jakarta-commons/lang/src/java/org/apache/commons/lang/CharEncoding.java Index: CharEncoding.java === RCS file: /home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/CharEncoding.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- CharEncoding.java 2 Oct 2004 01:46:29 - 1.1 +++ CharEncoding.java 6 Oct 2004 21:40:09 - 1.2 @@ -19,20 +19,15 @@ import java.io.UnsupportedEncodingException; /** - * TODO: Accept/Reject for 2.1. + * pCharacter encoding names required of every implementation of the Java platform./p * - * Character encoding names required of every implementation of the Java platform. - * - * According to the Java documentation a - * href=http://java.sun.com/j2se/1.3/docs/api/java/lang/package-summary.html#charenc;JRE character encoding names - * /a: - * p + * pAccording to the Java documentation + * a href=http://java.sun.com/j2se/1.3/docs/api/java/lang/package-summary.html#charenc;JRE character encoding names/a:br / * citeEvery implementation of the Java platform is required to support the following character encodings. Consult the * release documentation for your implementation to see if any other encodings are supported. /cite * /p * - * @see a href=http://java.sun.com/j2se/1.3/docs/api/java/lang/package-summary.html#charenc;JRE character encoding - * names /a + * @see a href=http://java.sun.com/j2se/1.3/docs/api/java/lang/package-summary.html#charenc;JRE character encoding names/a * @author Apache Software Foundation * @since 2.1 * @version $Id$ @@ -47,8 +42,7 @@ * Every implementation of the Java platform is required to support this character encoding. * /p * - * @see a href=http://java.sun.com/j2se/1.3/docs/api/java/lang/package-summary.html#charenc;JRE character - * encoding names /a + * @see a href=http://java.sun.com/j2se/1.3/docs/api/java/lang/package-summary.html#charenc;JRE character encoding names/a */ public static final String ISO_8859_1 = ISO-8859-1; @@ -60,8 +54,7 @@ * Every implementation of the Java platform is required to support this character encoding. * /p * - * @see a href=http://java.sun.com/j2se/1.3/docs/api/java/lang/package-summary.html#charenc;JRE character - * encoding names /a + * @see a href=http://java.sun.com/j2se/1.3/docs/api/java/lang/package-summary.html#charenc;JRE character encoding names/a */ public static final String US_ASCII = US-ASCII; @@ -74,8 +67,7 @@ * Every implementation of the Java platform is required to support this character encoding. * /p * - * @see a href=http://java.sun.com/j2se/1.3/docs/api/java/lang/package-summary.html#charenc;JRE character - * encoding names /a + * @see a href=http://java.sun.com/j2se/1.3/docs/api/java/lang/package-summary.html#charenc;JRE character encoding names/a */ public static final String UTF_16 = UTF-16; @@ -87,8 +79,7 @@ * Every implementation of the Java platform is required to support this character encoding. * /p * - * @see a href=http://java.sun.com/j2se/1.3/docs/api/java/lang/package-summary.html#charenc;JRE character - * encoding names /a + * @see a href=http://java.sun.com/j2se/1.3/docs/api/java/lang/package-summary.html#charenc;JRE character encoding names/a */ public static final String UTF_16BE = UTF-16BE; @@ -100,8 +91,7 @@ * Every implementation of the Java platform is required to support this character encoding. * /p * - * @see a href=http://java.sun.com/j2se/1.3/docs/api/java/lang/package-summary.html#charenc;JRE character - * encoding names /a + * @see a href=http://java.sun.com/j2se/1.3/docs/api/java/lang/package-summary.html#charenc;JRE character encoding names/a */ public static final String UTF_16LE = UTF-16LE; @@ -113,8 +103,7 @@ * Every implementation of the Java platform is required to support this character encoding. * /p * - * @see a href=http://java.sun.com/j2se/1.3/docs/api/java/lang/package-summary.html#charenc;JRE character - * encoding names /a + * @see a href=http://java.sun.com/j2se/1.3/docs/api/java/lang/package-summary.html#charenc;JRE character encoding names/a */ public static final String UTF_8 = UTF-8; @@ -123,17 +112,14 @@ * Returns whether the named charset is supported. * /p * p -
Re: [betwixt] Re: Howto serialize the classname when writing XML
On 6 Oct 2004, at 00:19, Christoph Gaffga ((triplemind.com)) wrote: i think that the code i've just committed should allow you to solve your problem. unfortunately, it's not as well documented as i would have liked (it's getting late for me and i need to finished off the 0.6 release). basically, i've refactored the code so that betwixt now ignores the class property by calling a pluggable strategy. Great. thanks, didn't expected a reaction so soon. I had one problem left: I needed to switch on the output of class properties only for classes derived from Throwable. So I can't make a decision in suppressProperty method based on the name and type of the property, I need the type of the bean containing the property also. I added a patch for that case, including some samples for the xdocs. see: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=31553 committed. many thanks. this breaks compatibility with code i committed earlier this week but (in this case) given the short time that the code has been in CVS (and the fact that it hasn't been released), it seems best to move now to the revised signature. some folks living on the edge may need to recompile... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31569] New: - Dbcp doesn't meet JDBC specification
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=31569. 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=31569 Dbcp doesn't meet JDBC specification Summary: Dbcp doesn't meet JDBC specification Product: Commons Version: 2.1 Final Platform: All OS/Version: Other Status: NEW Severity: Major Priority: Other Component: Dbcp AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The JDBC specification says for ResultSet and Statement that the ResultSet and Statement will be automatically closed when garbage collected. This means that people often write code like this Connection.getStatement().executeSQL(); However, because the DelegateConnection/DelegateStatement/DelegateResultSet extend AbandonedTrace (and are linked into the abandoned trace mechanism) they will not be garbage collected until the connection is closed. This of course means that DBCP holds on to lots of memory that it shouldn't do (I've had people complain to me of memory leaks). Surely it's possible to make the DelegateXX hold onto something else which does the AbandonedTrace and so when it is released it can do the implicit close and then everything will be coool. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31519] - Getting rid of some javadoc warn messages (3.2-dev)
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=31519. 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=31519 Getting rid of some javadoc warn messages (3.2-dev) --- Additional Comments From [EMAIL PROTECTED] 2004-10-06 22:02 --- The next patch is related to the BooleanComparator class. Some public methods in that class refer in their javadoc comments to the private variable 'trueFirst'. Since the default package access in the build.xml is set to protected, the javadoc generator will not see this private variable and gives warnings. The result is incomplete documentation (broken sentences...) But hey, there is the public method #sortsTrueFirst, to which these methods can refer to. So, this simple beauty patch just rewrites the javadoc comments a bit. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31571] New: - Handling exceptions during BeanUtils.populate()
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=31571. 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=31571 Handling exceptions during BeanUtils.populate() Summary: Handling exceptions during BeanUtils.populate() Product: Commons Version: unspecified Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Bean Utilities AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hi, I know this has been asked already before but could there be a way to handle exceptions that occur during population? The populate() function could either return a map(property, exception), take that kind of map as argument or -even better- take a PopulateExceptionHandler as argument. The reason I would like to see this feature implemented is to allow struts to use this mechanism to convert parameters from the request to actionform's properties without *falling apart* when encountering one that is not well- formed. It would be nice too if we were not *forced* to use string-only properties for actionforms (which in fact is a way to circumvent this conversion problem). I would like my ActionForm or DynaActionForm declare strongly-typed properties (maybe custom classes), register proper Converters into ConvertUtils in the ActionServlet.initServlet() for example, and then maybe get back conversion errors from within my action (maybe the PopulateExceptionHandler could add some ActionErrors to the request). What do you think? I know this issue is tightly coupled to struts but well... ;-) Thanks a lot, Xavier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31519] - Getting rid of some javadoc warn messages (3.2-dev)
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=31519. 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=31519 Getting rid of some javadoc warn messages (3.2-dev) --- Additional Comments From [EMAIL PROTECTED] 2004-10-06 22:03 --- Created an attachment (id=12972) BooleanComparator: Little rewrite of javadoc comments to avoid refering to a private variable - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Licensing (was: Re: [configuration] handling exceptions in AbstractConfiguration implementations)
Eric Pugh [EMAIL PROTECTED] writes: This is really driving me crazy.. I have tracked threads on general and jakarta-pmc mailing lists about this.. And everytime it comes down to I am not a lawyer and a bunch of FUD. We really need someone from the top of Apache to provide direction. I work a lot with hibernate code and can think of at least 4 projects that have hibernate code in them (at least as far as import statements). There _is_ a clear statement from the board. And even though we don't really like it technology-wise, it is sound from a licensing point of view. #1 No LGPL dependencies in code delivered from *.apache.org #2 import xxx where xxx is a LGPLed package is already a dependency. I think that Geir made this clear on [EMAIL PROTECTED] So every project that does have e.g. Hibernate dependencies in there must move off-Apache. This holds true for some maven-plugins and it would also hold true for a possible Hibernate-related commons-configuration module. This is not a bad thing IMHO. Apache is mainly about community and the drive to keep the sources clean. Having some modules or code being outside apache.org (e.g. on SourceForge) shouldn't be a big problem. We add a links to related stuff to the site and everything is fine. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Fighting for one's political stand is an honorable action, but re- fusing to acknowledge that there might be weaknesses in one's position - in order to identify them so that they can be remedied - is a large enough problem with the Open Source movement that it deserves to be on this list of the top five problems. -- Michelle Levesque, Fundamental Issues with Open Source Software Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31572] New: - [LANG] - o.a.c.lang.enum.ValuedEnum: 'enum'is a keyword in JDK1.5.0
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=31572. 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=31572 [LANG] - o.a.c.lang.enum.ValuedEnum: 'enum'is a keyword in JDK1.5.0 Summary: [LANG] - o.a.c.lang.enum.ValuedEnum: 'enum'is a keyword in JDK1.5.0 Product: Commons Version: 2.0 Final Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Lang AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I meet this error while trying to compile cocoon code using JDK1.5.0: /cocoon-2.1/src/blocks/forms/java/org/apache/cocoon/forms/event/ProcessingPhase.java:22: as of release 1.5, 'enum' is a keyword, and may not be used as an identifier (try -source 1.4 or lower to use 'enum' as an identifier) import org.apache.commons.lang.enum.ValuedEnum; Seems like JDK1.5.0 don't like the enum keyword inside the import statement. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/src/test/org/apache/commons/lang/text StrTokenizerTest.java TextTestSuite.java
scolebourne2004/10/06 15:29:25
Modified:lang/src/java/org/apache/commons/lang/text package.html
lang/src/test/org/apache/commons/lang/text
TextTestSuite.java
Added: lang/src/java/org/apache/commons/lang/text StrTokenizer.java
lang/src/test/org/apache/commons/lang/text
StrTokenizerTest.java
Removed: lang/src/test/org/apache/commons/lang TokenizerTest.java
lang/src/java/org/apache/commons/lang Tokenizer.java
Log:
Rename Tokenizer to StrTokenizer and move to text subpackage
Revision ChangesPath
1.2 +3 -1
jakarta-commons/lang/src/java/org/apache/commons/lang/text/package.html
Index: package.html
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/text/package.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- package.html 30 Sep 2004 16:57:05 - 1.1
+++ package.html 6 Oct 2004 22:29:24 - 1.2
@@ -16,7 +16,9 @@
html
body
p
-Provides classes for handling text in conjunction with [EMAIL PROTECTED] java.text}.
+Provides classes for handling and manipulating text, partly as an extension to
[EMAIL PROTECTED] java.text}.
+The classes in this package are, for the most part, intended to be instantiated.
+(ie. they are not utility classes with lots of static methods)
/p
@since 2.1
/body
1.1
jakarta-commons/lang/src/java/org/apache/commons/lang/text/StrTokenizer.java
Index: StrTokenizer.java
===
/*
* Copyright 2003-2004 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.apache.commons.lang.text;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;
import java.util.ListIterator;
/**
* Tokenizes a string based based on delimiters (separators)
* and supporting quoting and ignored character concepts.
* p
* This class can split a String into many smaller strings.
* It aims to do a similar job to java util StringTokenizer, however it offers
* much more control and flexibility. By default, it is setup like StringTokenizer.
* p
* The input String is split into a number of itokens/i.
* Each token is separated from the next String by a idelimiter/i.
* One or more delimiter characters must be specified.
* p
* The processing then strips all the iignored/i characters from each side of
the token.
* The token may also have iquotes/i to mark an area not to be stripped or
tokenized.
* Empty tokens may be removed or returned as null.
* This example is based on the CSV tokenizer.
* pre
* a,b,c - Three tokens a,b,c (comma delimiter)
* a, b , c- Three tokens a,b,c (ignored space characters stripped)
* a, b , c - Three tokens a, b ,c (quoted text untouched)
* /pre
* p
*
* This tokenizer has the following properties and options:
*
* table
* tr
* thProperty/ththType/ththDefault/th
* /tr
* tr
* tddelim/tdtdCharSetMatcher/tdtd{ \t\n\r\f}/td
* /tr
* tr
* tdquote/tdtdNoneMatcher/tdtd{}/td
* /tr
* tr
* tdignore/tdtdNoneMatcher/tdtd{}/td
* /tr
* tr
* tdemptyTokenAsNull/tdtdboolean/tdtdfalse/td
* /tr
* tr
* tdignoreEmptyTokens/tdtdboolean/tdtdtrue/td
* /tr
* /table
*
* @author Matthew Inger
* @author Stephen Colebourne
* @author Gary D. Gregory
* @since 2.1
* @version $Id: StrTokenizer.java,v 1.1 2004/10/06 22:29:24 scolebourne Exp $
*/
public class StrTokenizer implements ListIterator, Cloneable {
/**
* A Matcher which matches the comma character.
* Best used for codedelimiter/code.
*/
public static final Matcher COMMA_MATCHER = new CharMatcher(',');
/**
* A Matcher which matches the tab character.
* Best used for codedelimiter/code.
*/
public static final Matcher TAB_MATCHER = new CharMatcher('\t');
/**
* A Matcher which matches the space character.
* Best used for codedelimiter/code.
*/
public static final Matcher SPACE_MATCHER = new CharMatcher(' ');
/**
* A Matcher which matches the same
cvs commit: jakarta-commons/discovery/src/java/org/apache/commons/discovery/jdk JDK11Hooks.java JDK12Hooks.java
rsitze 2004/10/06 15:29:51
Modified:discovery/src/java/org/apache/commons/discovery/jdk
JDK11Hooks.java JDK12Hooks.java
Log:
In newer JVM/compilers, runtime complains when we try to invoke setLog on a
non-public class.
Revision ChangesPath
1.5 +1 -1
jakarta-commons/discovery/src/java/org/apache/commons/discovery/jdk/JDK11Hooks.java
Index: JDK11Hooks.java
===
RCS file:
/home/cvs/jakarta-commons/discovery/src/java/org/apache/commons/discovery/jdk/JDK11Hooks.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- JDK11Hooks.java 27 Feb 2004 23:36:56 - 1.4
+++ JDK11Hooks.java 6 Oct 2004 22:29:51 - 1.5
@@ -23,7 +23,7 @@
/**
* @author Richard A. Sitze
*/
-class JDK11Hooks extends JDKHooks {
+public class JDK11Hooks extends JDKHooks {
private static final ClassLoader systemClassLoader
= new PsuedoSystemClassLoader();
1.7 +1 -1
jakarta-commons/discovery/src/java/org/apache/commons/discovery/jdk/JDK12Hooks.java
Index: JDK12Hooks.java
===
RCS file:
/home/cvs/jakarta-commons/discovery/src/java/org/apache/commons/discovery/jdk/JDK12Hooks.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- JDK12Hooks.java 27 Feb 2004 23:36:56 - 1.6
+++ JDK12Hooks.java 6 Oct 2004 22:29:51 - 1.7
@@ -27,7 +27,7 @@
/**
* @author Richard A. Sitze
*/
-class JDK12Hooks extends JDKHooks {
+public class JDK12Hooks extends JDKHooks {
/**
* Logger
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/discovery/src/java/org/apache/commons/discovery/resource ResourceDiscoverImpl.java
rsitze 2004/10/06 15:31:01
Modified:discovery/src/java/org/apache/commons/discovery/resource
ResourceDiscoverImpl.java
Log:
Defer creation of ClassLoaders until we need them,
and create a useful default [non-null].
Revision ChangesPath
1.5 +4 -2
jakarta-commons/discovery/src/java/org/apache/commons/discovery/resource/ResourceDiscoverImpl.java
Index: ResourceDiscoverImpl.java
===
RCS file:
/home/cvs/jakarta-commons/discovery/src/java/org/apache/commons/discovery/resource/ResourceDiscoverImpl.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- ResourceDiscoverImpl.java 27 Feb 2004 23:36:55 - 1.4
+++ ResourceDiscoverImpl.java 6 Oct 2004 22:31:01 - 1.5
@@ -38,7 +38,6 @@
* Construct a new resource discoverer
*/
public ResourceDiscoverImpl() {
-setClassLoaders(new ClassLoaders());
}
/**
@@ -61,10 +60,13 @@
* It is recommended to add the most specific loaders first.
*/
public void addClassLoader(ClassLoader loader) {
-classLoaders.put(loader);
+getClassLoaders().put(loader);
}
protected ClassLoaders getClassLoaders() {
+if (classLoaders == null) {
+classLoaders = ClassLoaders.getLibLoaders(this.getClass(), null, true);
+}
return classLoaders;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/discovery/src/java/org/apache/commons/discovery/tools ManagedProperties.java
rsitze 2004/10/06 15:31:34
Modified:discovery/src/java/org/apache/commons/discovery/tools
ManagedProperties.java
Log:
Instrument logging to help identify source of properties.
Revision ChangesPath
1.8 +18 -1
jakarta-commons/discovery/src/java/org/apache/commons/discovery/tools/ManagedProperties.java
Index: ManagedProperties.java
===
RCS file:
/home/cvs/jakarta-commons/discovery/src/java/org/apache/commons/discovery/tools/ManagedProperties.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- ManagedProperties.java17 Aug 2004 18:32:06 - 1.7
+++ ManagedProperties.java6 Oct 2004 22:31:34 - 1.8
@@ -24,6 +24,8 @@
import java.util.Properties;
import org.apache.commons.discovery.jdk.JDKHooks;
+import org.apache.commons.discovery.log.DiscoveryLogFactory;
+import org.apache.commons.logging.Log;
@@ -76,6 +78,11 @@
* @author Richard A. Sitze
*/
public class ManagedProperties {
+private static Log log = DiscoveryLogFactory.newLog(ManagedProperties.class);
+public static void setLog(Log _log) {
+log = _log;
+}
+
/**
* Cache of Properties, keyed by (thread-context) class loaders.
* Use codeHashMap/code because it allows 'null' keys, which
@@ -120,6 +127,9 @@
if (val != null) {
value = val.value;
}
+} else if (log.isDebugEnabled()) {
+log.debug(found System property ' + propertyName + ' +
+ with value ' + value + '.);
}
return value;
}
@@ -314,8 +324,15 @@
// set value only if override exists..
// otherwise pass default (or null) on..
-if (altValue != null)
+if (altValue != null) {
value = altValue;
+
+if (log.isDebugEnabled()) {
+log.debug(found Managed property ' + propertyName
+ ' +
+ with value ' + value + ' +
+ bound to classloader + classLoader +
.);
+}
+}
}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31572] - [LANG] - o.a.c.lang.enum.ValuedEnum: 'enum'is a keyword in JDK1.5.0
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=31572. 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=31572 [LANG] - o.a.c.lang.enum.ValuedEnum: 'enum'is a keyword in JDK1.5.0 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-10-06 22:35 --- Try using the CVS version where the enum package is renamed to enums. (duplicate report) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] handling exceptions in AbstractConfiguration implementations
Eric Pugh wrote: This is really driving me crazy.. I have tracked threads on general and jakarta-pmc mailing lists about this.. And everytime it comes down to I am not a lawyer and a bunch of FUD. We really need someone from the top of Apache to provide direction. I work a lot with hibernate code and can think of at least 4 projects that have hibernate code in them (at least as far as import statements). From a technical/legal point of view there is no reason to avoid a dependency on a LGPLed component in an Apache project, the license FAQ on Hibernate is pretty clear: The use of the unmodified Hibernate binary of course never affects the license of your application or distribution. If you modify Hibernate and redistribute your modifications, the LGPL applies. Excluding LGPLed projects is just a political decision imho. Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31572] - [LANG] - o.a.c.lang.enum.ValuedEnum: 'enum'is a keyword in JDK1.5.0
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=31572. 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=31572 [LANG] - o.a.c.lang.enum.ValuedEnum: 'enum'is a keyword in JDK1.5.0 --- Additional Comments From [EMAIL PROTECTED] 2004-10-06 22:42 --- When is planned a new commons-lang release? We (Cocoon) are planning a new release and we try to avoid CVS versions libraries. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: [i18n] Did I miss something?
Hi James, Any contributions are welcome! As I still don't get the site generated with maven completely (layout is somehow broken and javadocs are missing) this is very high on my todo... Maybe you can help me out? Would be nice to get a link from the commons page to the i18n in the sandbox. Do you know if someone can manage this (having commit access to commons)? - In general I like the idea to read messages from properties files as this might be very useful to migrate existing application to i18n. Even though I like the xml-based format more as you can see which entries belong together. - Adding icons and so on can easily be achieved by adding a new class (like LocalizedDescription...) - I'll add a proposal for using localized messages for logging as I've used this in a project using an additional Information class. This works very nice and lets you map different error entries to different log messages (details to debug, text to info or something like that). - I don't know if I used logging at all but it should be no prob to switch to log4j or commons-logging. - I don't like digester at all as this seems to me the most confusing and overdosed way to parse xml files. I talked to Oliver Zeigermann and we will add xml-im-exporter to commons-sandbox as I find this the very best tool do sax-based xml-parsing. It's ultra-simple, fast and intuitive. That's why I've used it in many projects in the past and would be very glad to see it here. I've worked with digester in the past but it's just too complex and xml-im-exporter is just kicking-ass... Warmest regards, Daniel -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von James Mitchell Gesendet: Mittwoch, 6. Oktober 2004 15:17 An: Jakarta Commons Developers List Betreff: [i18n] Did I miss something? Wow, how did I miss this? I wonder what we can do with this and commons-resources and/or Apache Struts. In my current gig we are using a home grown solution in combination with ActionErrors/ActionMessages provided by Struts. This project would have been nice to have about 8 months ago. My immediate needs (scratching my own itch here) would be to help provide greater granularity for application messaging (similar to log levels) and perhaps a jsp taglib or two to help take advantage of this in my apps (this would probably go under Apache Struts contrib). So, with that said, I would like to volunteer to help with this project. Off the top of my head what I would like to do is: a) offer the same solution with the following alternate implementations: - properties file based configuration (more on this later) - RDBMS based configuration (I've already done this in commons-resources) b) Develop a Struts plug-in that will load and configure commons-i18n for my Struts applications. (I guess I could just add this as a plug-in under struts) c) The types of LocalizedMessages or LocalizedExceptions I can use are the following: - System error - Error - Warning - Alert - Flag - Info d) I would like to add an entry like: entry key=small-icon/images/some-icon-small.jpg/entry (also one for large-icon) e) New MessageManager impl that can assemble messages based on a config file who's entries simply point to existing i18n'd properties file(s) keys. (I will provide more details for this on my ShortTermPlans page http://wiki.apache.org/struts/ShortTermPlansForJamesMitchell) General questions: Is there any reason you did not use commons-logging? Can we change this to commons since it will (by default) delegate to the appropriate logging framework (let's eat our own dogfood)? Any reason you are using xml-importer instead of digester? I've read the docs on sf.net, but the advantages still aren't clear to me (I'm guessing it was just a personal choice made some time ago and you just stayed with it). Can we change this to use either (or use commons-configuration)? Have you thought about Spring integration? -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - 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: cvs commit: jakarta-commons/discovery/src/java/org/apache/commons/discovery/tools ManagedProperties.java
Richard,
Are u planning any more updates? Can we try and make a
commons-discovery release before Axis gets finalized?
thanks,
dims
On 6 Oct 2004 22:31:34 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
rsitze 2004/10/06 15:31:34
Modified:discovery/src/java/org/apache/commons/discovery/tools
ManagedProperties.java
Log:
Instrument logging to help identify source of properties.
Revision ChangesPath
1.8 +18 -1
jakarta-commons/discovery/src/java/org/apache/commons/discovery/tools/ManagedProperties.java
Index: ManagedProperties.java
===
RCS file:
/home/cvs/jakarta-commons/discovery/src/java/org/apache/commons/discovery/tools/ManagedProperties.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- ManagedProperties.java17 Aug 2004 18:32:06 - 1.7
+++ ManagedProperties.java6 Oct 2004 22:31:34 - 1.8
@@ -24,6 +24,8 @@
import java.util.Properties;
import org.apache.commons.discovery.jdk.JDKHooks;
+import org.apache.commons.discovery.log.DiscoveryLogFactory;
+import org.apache.commons.logging.Log;
@@ -76,6 +78,11 @@
* @author Richard A. Sitze
*/
public class ManagedProperties {
+private static Log log = DiscoveryLogFactory.newLog(ManagedProperties.class);
+public static void setLog(Log _log) {
+log = _log;
+}
+
/**
* Cache of Properties, keyed by (thread-context) class loaders.
* Use codeHashMap/code because it allows 'null' keys, which
@@ -120,6 +127,9 @@
if (val != null) {
value = val.value;
}
+} else if (log.isDebugEnabled()) {
+log.debug(found System property ' + propertyName + ' +
+ with value ' + value + '.);
}
return value;
}
@@ -314,8 +324,15 @@
// set value only if override exists..
// otherwise pass default (or null) on..
-if (altValue != null)
+if (altValue != null) {
value = altValue;
+
+if (log.isDebugEnabled()) {
+log.debug(found Managed property ' +
propertyName + ' +
+ with value ' + value + ' +
+ bound to classloader + classLoader
+ .);
+}
+}
}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Davanum Srinivas - http://webservices.apache.org/~dims/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: [i18n] Did I miss something?
If people really want this stuff I would be glad to create a new sandbox component for the XML import and export stuff. Importer is mainly SAX plus all that I ever wanted to have additonally, i.e. have the path of the generated event, more than one listener, element, attribute and conent data at one position where applicable and more. Almost no overhead. Exporter is a simple set of helpers that makes you generate valid XML with almost zero performance overhead. Oliver On Thu, 7 Oct 2004 00:46:52 +0200, Daniel Florey [EMAIL PROTECTED] wrote: Hi James, Any contributions are welcome! As I still don't get the site generated with maven completely (layout is somehow broken and javadocs are missing) this is very high on my todo... Maybe you can help me out? Would be nice to get a link from the commons page to the i18n in the sandbox. Do you know if someone can manage this (having commit access to commons)? - In general I like the idea to read messages from properties files as this might be very useful to migrate existing application to i18n. Even though I like the xml-based format more as you can see which entries belong together. - Adding icons and so on can easily be achieved by adding a new class (like LocalizedDescription...) - I'll add a proposal for using localized messages for logging as I've used this in a project using an additional Information class. This works very nice and lets you map different error entries to different log messages (details to debug, text to info or something like that). - I don't know if I used logging at all but it should be no prob to switch to log4j or commons-logging. - I don't like digester at all as this seems to me the most confusing and overdosed way to parse xml files. I talked to Oliver Zeigermann and we will add xml-im-exporter to commons-sandbox as I find this the very best tool do sax-based xml-parsing. It's ultra-simple, fast and intuitive. That's why I've used it in many projects in the past and would be very glad to see it here. I've worked with digester in the past but it's just too complex and xml-im-exporter is just kicking-ass... Warmest regards, Daniel -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von James Mitchell Gesendet: Mittwoch, 6. Oktober 2004 15:17 An: Jakarta Commons Developers List Betreff: [i18n] Did I miss something? Wow, how did I miss this? I wonder what we can do with this and commons-resources and/or Apache Struts. In my current gig we are using a home grown solution in combination with ActionErrors/ActionMessages provided by Struts. This project would have been nice to have about 8 months ago. My immediate needs (scratching my own itch here) would be to help provide greater granularity for application messaging (similar to log levels) and perhaps a jsp taglib or two to help take advantage of this in my apps (this would probably go under Apache Struts contrib). So, with that said, I would like to volunteer to help with this project. Off the top of my head what I would like to do is: a) offer the same solution with the following alternate implementations: - properties file based configuration (more on this later) - RDBMS based configuration (I've already done this in commons-resources) b) Develop a Struts plug-in that will load and configure commons-i18n for my Struts applications. (I guess I could just add this as a plug-in under struts) c) The types of LocalizedMessages or LocalizedExceptions I can use are the following: - System error - Error - Warning - Alert - Flag - Info d) I would like to add an entry like: entry key=small-icon/images/some-icon-small.jpg/entry (also one for large-icon) e) New MessageManager impl that can assemble messages based on a config file who's entries simply point to existing i18n'd properties file(s) keys. (I will provide more details for this on my ShortTermPlans page http://wiki.apache.org/struts/ShortTermPlansForJamesMitchell) General questions: Is there any reason you did not use commons-logging? Can we change this to commons since it will (by default) delegate to the appropriate logging framework (let's eat our own dogfood)? Any reason you are using xml-importer instead of digester? I've read the docs on sf.net, but the advantages still aren't clear to me (I'm guessing it was just a personal choice made some time ago and you just stayed with it). Can we change this to use either (or use commons-configuration)? Have you thought about Spring integration? -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To
Re: [betwixt] Re: Howto serialize the classname when writing XML
I added a patch for that case, including some samples for the xdocs. see: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=31553 committed. many thanks. the pleasure is mine. this breaks compatibility with code i committed earlier this week but (in this case) given the short time that the code has been in CVS (and the fact that it hasn't been released), it seems best to move now to the revised signature. agree with you. Would have sent the patch earlier, but was away. some folks living on the edge may need to recompile... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31519] - Getting rid of some javadoc warn messages (3.2-dev)
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=31519. 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=31519 Getting rid of some javadoc warn messages (3.2-dev) --- Additional Comments From [EMAIL PROTECTED] 2004-10-06 23:26 --- The following three patches touches MultiKeyMap, ReferenceIdentityMap and ReferenceMap. Just added full qualified names to linked classes, if they havent been explicitely imported from the source files. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31519] - Getting rid of some javadoc warn messages (3.2-dev)
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=31519. 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=31519 Getting rid of some javadoc warn messages (3.2-dev) --- Additional Comments From [EMAIL PROTECTED] 2004-10-06 23:31 --- Created an attachment (id=12973) ReferenceIdentityMap: Adding full qualified names to classes, which have not been imported explictely - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31519] - Getting rid of some javadoc warn messages (3.2-dev)
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=31519. 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=31519 Getting rid of some javadoc warn messages (3.2-dev) --- Additional Comments From [EMAIL PROTECTED] 2004-10-06 23:31 --- Created an attachment (id=12974) ReferenceMap: Adding full qualified names to classes, which have not been imported explictely - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31519] - Getting rid of some javadoc warn messages (3.2-dev)
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=31519. 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=31519 Getting rid of some javadoc warn messages (3.2-dev) --- Additional Comments From [EMAIL PROTECTED] 2004-10-06 23:34 --- Ups, i was wrong. The 3rd patch, the one for MultiKeyMap, fixes the javadoc code for the method putAll(Map), that referenced non existing parameters. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31519] - Getting rid of some javadoc warn messages (3.2-dev)
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=31519. 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=31519 Getting rid of some javadoc warn messages (3.2-dev) --- Additional Comments From [EMAIL PROTECTED] 2004-10-06 23:35 --- Created an attachment (id=12975) MultiKeyMap: Fixed wrong parameters in javadoc for method putAll - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31519] - Getting rid of some javadoc warn messages (3.2-dev)
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=31519. 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=31519 Getting rid of some javadoc warn messages (3.2-dev) --- Additional Comments From [EMAIL PROTECTED] 2004-10-06 23:44 --- Created an attachment (id=12976) SingletonMap: Fixes javadoc for constructor SingletonMap(MapEntry) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] XMLOutput.data(Object)
On Wed, 6 Oct 2004 15:18:50 +0200, Paul Libbrecht [EMAIL PROTECTED] wrote: Gee... I was really thinking this was obvious... hence the relatively undetailed descriptions. Obviously it isn't for me. It seems to me that you want to use XMLOutput to pass data around, even though it's currently a 'write-only' object, i.e. there's no way of getting of data back out of it. - XMLoutput objects are exchanged as part of the doTag nested calls. Therefore it is easy for something aimed at receiving data to create an XMLOutput object that does something just for the data() call, and passes-through for the rest. This way a tag can receive a return value. There's no way to do so with the context except delicate hacks and fragile naming-conventions. Sounds like hand-waving. Obviously tags return values, e.g. the set tag. - The objects being exchanged aren't meant ot be stored. They are part of the process... i.e. when I write math:determinant math:product math:matri/math:matrix math:matri/math:matrix /math:product /math:determinant I am not storing the matrix of the product, I'm just passing it around. Isn't the context for passing stuff around? - to me, it makes loads of sense to have tags that transform their output... and that should apply to object-data as well. (so that adding a constraint in jelly-swing would be simply a transformation) Tags that transform their own output? Or output from nested tags? - another fancy feature: the result of a bsf or beanshell script could be fed using this data() function... and thus used (it is currently only used when setting a variable) At least, to me, it is the only way for a component child, like a swing button, to talk flexibly to a component container, without manually walking the hierarchy. Hmmm. *Only* way seems to be a little exaggerated. Can't the component have it's parent set at some time later? -- http://www.multitask.com.au/people/dion/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/java/org/apache/commons/httpclient HttpHost.java
mbecke 2004/10/06 17:36:25
Modified:httpclient/src/java/org/apache/commons/httpclient
HttpHost.java
Log:
Removed unnecessary synchronized keywords.
Revision ChangesPath
1.2 +5 -5
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpHost.java
Index: HttpHost.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpHost.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- HttpHost.java 6 Oct 2004 17:32:03 - 1.1
+++ HttpHost.java 7 Oct 2004 00:36:25 - 1.2
@@ -139,7 +139,7 @@
*
* @return the host port, or code-1/code if not set
*/
-public synchronized int getPort() {
+public int getPort() {
return this.port;
}
@@ -147,7 +147,7 @@
* Returns the protocol.
* @return The protocol.
*/
-public synchronized Protocol getProtocol() {
+public Protocol getProtocol() {
return this.protocol;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31519] - [collections] Getting rid of some javadoc warn messages (3.2-dev)
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=31519. 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=31519 [collections] Getting rid of some javadoc warn messages (3.2-dev) [EMAIL PROTECTED] changed: What|Removed |Added Summary|Getting rid of some javadoc |[collections] Getting rid of |warn messages (3.2-dev) |some javadoc warn messages ||(3.2-dev) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31572] - [LANG] - o.a.c.lang.enum.ValuedEnum: 'enum'is a keyword in JDK1.5.0
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=31572. 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=31572 [LANG] - o.a.c.lang.enum.ValuedEnum: 'enum'is a keyword in JDK1.5.0 --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 02:13 --- It's ASAP, tying the loose ends and getting close to calling for a release. However, that translates as probably around the end of the year if I had to make a solid bet. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31574] New: - Return empty array rather than null
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=31574. 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=31574 Return empty array rather than null Summary: Return empty array rather than null Product: Commons Version: 2.0 Beta 1 Platform: PC URL: http://http://http:// OS/Version: Windows XP Status: NEW Severity: Enhancement Priority: Other Component: CLI AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Patch to follow changes CommandLine and Option to return an empty String array rather than null. This makes it easier for the caller to process the values. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Licensing (was: Re: [configuration] handling exceptions in AbstractConfiguration implementations)
Correct. I'll work to resolve the lack of published information. It's more than just LGPL really, we need a page that lists all acceptable OSI-accepted licences. LGPL is just the biggest issue as it's probably the 2nd most common open-source Java licence behind BSD-like. As far as the FUD/IANAL stuff, it's all pretty honest but I'm happy to take a stand and say that we won't have LGPL in Jakarta code until we hear otherwise from the board. I'd love to be using JFreeChart here, but it's LGPL. Hen (Henning's .sig is especially apt in his reply btw. :) ) On Wed, 6 Oct 2004 22:13:30 + (UTC), Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Eric Pugh [EMAIL PROTECTED] writes: This is really driving me crazy.. I have tracked threads on general and jakarta-pmc mailing lists about this.. And everytime it comes down to I am not a lawyer and a bunch of FUD. We really need someone from the top of Apache to provide direction. I work a lot with hibernate code and can think of at least 4 projects that have hibernate code in them (at least as far as import statements). There _is_ a clear statement from the board. And even though we don't really like it technology-wise, it is sound from a licensing point of view. #1 No LGPL dependencies in code delivered from *.apache.org #2 import xxx where xxx is a LGPLed package is already a dependency. I think that Geir made this clear on [EMAIL PROTECTED] So every project that does have e.g. Hibernate dependencies in there must move off-Apache. This holds true for some maven-plugins and it would also hold true for a possible Hibernate-related commons-configuration module. This is not a bad thing IMHO. Apache is mainly about community and the drive to keep the sources clean. Having some modules or code being outside apache.org (e.g. on SourceForge) shouldn't be a big problem. We add a links to related stuff to the site and everything is fine. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Fighting for one's political stand is an honorable action, but re- fusing to acknowledge that there might be weaknesses in one's position - in order to identify them so that they can be remedied - is a large enough problem with the Open Source movement that it deserves to be on this list of the top five problems. -- Michelle Levesque, Fundamental Issues with Open Source Software Development - 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 31574] - Return empty array rather than null
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=31574. 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=31574 Return empty array rather than null --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 02:24 --- Created an attachment (id=12978) Return empty string array rather than null - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: [i18n] Did I miss something?
On Thu, 7 Oct 2004 00:46:52 +0200, Daniel Florey [EMAIL PROTECTED] wrote: Hi James, Any contributions are welcome! As I still don't get the site generated with maven completely (layout is somehow broken and javadocs are missing) this is very high on my todo... Maybe you can help me out? Would be nice to get a link from the commons page to the i18n in the sandbox. Do you know if someone can manage this (having commit access to commons)? - In general I like the idea to read messages from properties files as this might be very useful to migrate existing application to i18n. Even though I like the xml-based format more as you can see which entries belong together. - Adding icons and so on can easily be achieved by adding a new class (like LocalizedDescription...) - I'll add a proposal for using localized messages for logging as I've used this in a project using an additional Information class. This works very nice and lets you map different error entries to different log messages (details to debug, text to info or something like that). - I don't know if I used logging at all but it should be no prob to switch to log4j or commons-logging. - I don't like digester at all as this seems to me the most confusing and overdosed way to parse xml files. I talked to Oliver Zeigermann and we will add xml-im-exporter to commons-sandbox as I find this the very best tool do sax-based xml-parsing. It's ultra-simple, fast and intuitive. That's why I've used it in many projects in the past and would be very glad to see it here. I've worked with digester in the past but it's just too complex and xml-im-exporter is just kicking-ass... I would very strongly encourage you to use Digester. It's actually a piece of cake to use - I've seldom had to spend more than a few minutes writing any set of rules I've needed. And besides the fact that it's already here in Commons and uses Commons Logging, it's also in use by many other major projects at Apache, such as Tomcat and Struts, that would be potential customers for the i18n component. -- Martin Cooper Warmest regards, Daniel -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von James Mitchell Gesendet: Mittwoch, 6. Oktober 2004 15:17 An: Jakarta Commons Developers List Betreff: [i18n] Did I miss something? Wow, how did I miss this? I wonder what we can do with this and commons-resources and/or Apache Struts. In my current gig we are using a home grown solution in combination with ActionErrors/ActionMessages provided by Struts. This project would have been nice to have about 8 months ago. My immediate needs (scratching my own itch here) would be to help provide greater granularity for application messaging (similar to log levels) and perhaps a jsp taglib or two to help take advantage of this in my apps (this would probably go under Apache Struts contrib). So, with that said, I would like to volunteer to help with this project. Off the top of my head what I would like to do is: a) offer the same solution with the following alternate implementations: - properties file based configuration (more on this later) - RDBMS based configuration (I've already done this in commons-resources) b) Develop a Struts plug-in that will load and configure commons-i18n for my Struts applications. (I guess I could just add this as a plug-in under struts) c) The types of LocalizedMessages or LocalizedExceptions I can use are the following: - System error - Error - Warning - Alert - Flag - Info d) I would like to add an entry like: entry key=small-icon/images/some-icon-small.jpg/entry (also one for large-icon) e) New MessageManager impl that can assemble messages based on a config file who's entries simply point to existing i18n'd properties file(s) keys. (I will provide more details for this on my ShortTermPlans page http://wiki.apache.org/struts/ShortTermPlansForJamesMitchell) General questions: Is there any reason you did not use commons-logging? Can we change this to commons since it will (by default) delegate to the appropriate logging framework (let's eat our own dogfood)? Any reason you are using xml-importer instead of digester? I've read the docs on sf.net, but the advantages still aren't clear to me (I'm guessing it was just a personal choice made some time ago and you just stayed with it). Can we change this to use either (or use commons-configuration)? Have you thought about Spring integration? -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail:
DO NOT REPLY [Bug 31575] New: - OptionBuilder create enhancements
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=31575. 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=31575 OptionBuilder create enhancements Summary: OptionBuilder create enhancements Product: Commons Version: 2.0 Beta 1 Platform: PC URL: http://http://http:// OS/Version: Windows XP Status: NEW Severity: Enhancement Priority: Other Component: CLI AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Patch to follow adds check to ensure that withValueSeparator is used with at least two arguments, and sets the count to 2 if not already set. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31575] - OptionBuilder create enhancements
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=31575. 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=31575 OptionBuilder create enhancements --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 02:41 --- Created an attachment (id=12979) withValueSeparator check - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Licensing
Henri Yandell wrote: I'll work to resolve the lack of published information. It's more than just LGPL really, we need a page that lists all acceptable OSI-accepted licences. LGPL is just the biggest issue as it's probably the 2nd most common open-source Java licence behind BSD-like. http://nagoya.apache.org/wiki/apachewiki.cgi?Licensing This is on the old-soon-to-be-deprecated wiki, and it hasn't been ported over. -- Serge Knystautas Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Matrix subMatrix and mean methods
Thanks, Wolfgang. This is a pretty easy case for us - as it sits today, especially with this email note from Wolfgang (which should be included in a NOTES file sitting near colt.jar when imported) it looks perfectly fine to incorporate this into Apache, preserving CERN's copyright notice. From a policy perspective, we should commit to the repository not just the .jar file but the source code as well. Any patches that Apache developers need to make should be offered upstream, of course, and then reincorporated into the ASF repository by merging in a new version. But if we need to locally modify the work, then the copyright on the resulting derivative work would be (C) Apache Software Foundation and the Apache 2.0 license, being careful not to remove the original (C) CERN or license/notice. Brian On Tue, 5 Oct 2004, Wolfgang Hoschek wrote: Hi, let me briefly introduce myself. I'm the author of Colt which has the BSD-style license you referred to below. I encourage you to take code or ideas from Colt, as you see fit, and as you see compatible with Apache licensing policy. I wrote this code some six years ago while working at CERN, so the copyright is not with me personally, but with CERN (http://www.cern.ch). I have left CERN some years ago to work for a Bay Area research lab, so I consider it unlikely that the license could be changed, and I'm not in a position to help change the license, even though I would support such a license change. In my judgement, you will have to decide if the current license works for you, or not. If it works for you, you are most welcome. As far as Jama is concerned, the code is a straightforward adaption of the original Jama code, as explained on http://dsd.lbl.gov/~hoschek/colt/api/cern/colt/matrix/linalg/package- summary.html#Overview You could contact the Jama authors for licensing issues. Hope this helps, Wolfgang. I am posting this to the Licensing list as well because it is very unclear how to proceed and we dearly need their advice on this subject. Licensing, the issue has to do with policy for adding code from a external project, which the author has approved our usage of via email. http://www.theserverside.com/news/thread.tss?thread_id=28596#137409 /www.mail-archive.com/[EMAIL PROTECTED]/msg48417.html We would like to add certain fragments of the Colt API which is licensed under a BSD style licensing. http://dsd.lbl.gov/~hoschek/colt/license.html How do we properly proceed? Al Chou wrote: Colt contains a port of much of JAMA, IIRC, and as Wolfgang posted not too long ago, Colt's new license is much more compatible with the Apache license. I'm not sure if it's sufficiently compatible for us to start merging in code, though. Al I think we should clarify our own position given his approval. 1.) I think the appropriate path is to discuss with Wolfgang and our Licensing list what is required to meet any ASF requirements that may exist. Licensing needs to clarify how we should proceed. The challenge is what to do about any ASF polices concerning licensing adjustments, for which none of us are knowledgeable. 2.) I think this is a exception to our policy of acknowledging authorship in the project documentation and not in the code. In this case I think we should attempt to maintain significant references to his project as the original source of any codebase additions added to the Commons math API. 3.) If ASF requires more stringent approval in writing, we request more formally to have Wolfgang fax in some sort of donation form to ASF. -Mark -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu --- Wolfgang Hoschek | email: [EMAIL PROTECTED] Distributed Systems Department| phone: (415)-533-7610 Berkeley Laboratory | http://dsd.lbl.gov/~hoschek/ --- - 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: [configuration] handling exceptions in AbstractConfiguration implementations
I feel your pain. After spending time shuffling code up and down from a contrib folder so that gump would, then would not compile those sources, I finally moved the code over to sf.net and updated the docs to mention the additional impls. I would like a straight answer on this too. I wish I could keep everything together. -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: Eric Pugh [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Wednesday, October 06, 2004 3:16 PM Subject: RE: [configuration] handling exceptions in AbstractConfiguration implementations This is really driving me crazy.. I have tracked threads on general and jakarta-pmc mailing lists about this.. And everytime it comes down to I am not a lawyer and a bunch of FUD. We really need someone from the top of Apache to provide direction. I work a lot with hibernate code and can think of at least 4 projects that have hibernate code in them (at least as far as import statements). Of course, I guess this isn't the right mailing list.. I could try and push this to some sort of conclusion, but I don't want to be told no! right now you can just pick your interpretation! Argh, Eric -Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 06, 2004 7:23 PM To: Jakarta Commons Developers List Subject: Re: [configuration] handling exceptions in AbstractConfiguration implementations One advantage for me is having the ability to reuse your existing application's configuration. I created a Hibernate, iBatis, Torque, DBUtils, and straight JDBC implementations for commons-resource for this very purpose. I moved the Hibernate impl over to sf.net because of license conflicts. -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: Emmanuel Bourg [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Wednesday, October 06, 2004 12:59 PM Subject: Re: [configuration] handling exceptions in AbstractConfiguration implementations I don't want to sound harsh, but what is the added value of using Hibernate here for such a simple data structure ? A direct JDBC implementation is good enough and spare a 1.5MB dependency. Emmanuel Bourg Ricardo Gladwell wrote: Hi All, I'm currently developing a sub-class of the AbstractConfiguration classthat uses Hibernate to access configuration properties (unimaginatively called Hibernate Configuration). I'm slightly concerned about the way sub-classes are suposed to handle exceptions: All the abstract method are defined as not throwing exceptions. All calls to hibernate, however, throw HibernateExceptions. So, for example, my implementation of getPropertyDirect calls the hibernate Session.get() method which can throw an exception. Looking at your implementation of the DatabaseConfiguration I can see that it simply consumes SQLExceptions thrown from the JDBC API, logging the stack trace. However, what if you want to be warned of exceptions being thrown by the underlying implementation of Configuration? I notice you already have a nestable ConfigurationException implemented. Surely, all Configuration methods should indicate they will throw this exception if they are expected to read/write data? Also, the AbstractConfiguration class does not describe this contract (logging all errors throw by underlying framework) or what should be returned in the event of an error? I assume you should return null values but this is not described anywhere. Kind regards, -- Ricardo Gladwell - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Matrix subMatrix and mean methods
Hi Brian, After being reminded by Wolfgang that he had previously given me a contact at CERN to discuss these issues with, I emailed that contact. He forwarded me to the Technology Transfer officer for CERN. I just finished emailing a request to that individual to comment on the position CERN holds on this subject of relicensing/donation. Once we hear back from them we can also include this information into the discussion. I expect it will clarify if any opposition does exist at the original institution. Cheers, Mark Brian Behlendorf wrote: Thanks, Wolfgang. This is a pretty easy case for us - as it sits today, especially with this email note from Wolfgang (which should be included in a NOTES file sitting near colt.jar when imported) it looks perfectly fine to incorporate this into Apache, preserving CERN's copyright notice. From a policy perspective, we should commit to the repository not just the .jar file but the source code as well. Any patches that Apache developers need to make should be offered upstream, of course, and then reincorporated into the ASF repository by merging in a new version. But if we need to locally modify the work, then the copyright on the resulting derivative work would be (C) Apache Software Foundation and the Apache 2.0 license, being careful not to remove the original (C) CERN or license/notice. Brian On Tue, 5 Oct 2004, Wolfgang Hoschek wrote: Hi, let me briefly introduce myself. I'm the author of Colt which has the BSD-style license you referred to below. I encourage you to take code or ideas from Colt, as you see fit, and as you see compatible with Apache licensing policy. I wrote this code some six years ago while working at CERN, so the copyright is not with me personally, but with CERN (http://www.cern.ch). I have left CERN some years ago to work for a Bay Area research lab, so I consider it unlikely that the license could be changed, and I'm not in a position to help change the license, even though I would support such a license change. In my judgement, you will have to decide if the current license works for you, or not. If it works for you, you are most welcome. As far as Jama is concerned, the code is a straightforward adaption of the original Jama code, as explained on http://dsd.lbl.gov/~hoschek/colt/api/cern/colt/matrix/linalg/package- summary.html#Overview You could contact the Jama authors for licensing issues. Hope this helps, Wolfgang. I am posting this to the Licensing list as well because it is very unclear how to proceed and we dearly need their advice on this subject. Licensing, the issue has to do with policy for adding code from a external project, which the author has approved our usage of via email. http://www.theserverside.com/news/thread.tss?thread_id=28596#137409 /www.mail-archive.com/[EMAIL PROTECTED]/msg48417.html We would like to add certain fragments of the Colt API which is licensed under a BSD style licensing. http://dsd.lbl.gov/~hoschek/colt/license.html How do we properly proceed? Al Chou wrote: Colt contains a port of much of JAMA, IIRC, and as Wolfgang posted not too long ago, Colt's new license is much more compatible with the Apache license. I'm not sure if it's sufficiently compatible for us to start merging in code, though. Al I think we should clarify our own position given his approval. 1.) I think the appropriate path is to discuss with Wolfgang and our Licensing list what is required to meet any ASF requirements that may exist. Licensing needs to clarify how we should proceed. The challenge is what to do about any ASF polices concerning licensing adjustments, for which none of us are knowledgeable. 2.) I think this is a exception to our policy of acknowledging authorship in the project documentation and not in the code. In this case I think we should attempt to maintain significant references to his project as the original source of any codebase additions added to the Commons math API. 3.) If ASF requires more stringent approval in writing, we request more formally to have Wolfgang fax in some sort of donation form to ASF. -Mark -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu --- Wolfgang Hoschek | email: [EMAIL PROTECTED] Distributed Systems Department| phone: (415)-533-7610 Berkeley Laboratory | http://dsd.lbl.gov/~hoschek/ --- - 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] -- Mark Diggory Open Source Software Developer Apache Jakarta Project http://jakarta.apache.org
[Jakarta Commons Wiki] Updated: MathWishList
Date: 2004-10-06T22:48:12 Editor: AlChou [EMAIL PROTECTED] Wiki: Jakarta Commons Wiki Page: MathWishList URL: http://wiki.apache.org/jakarta-commons/MathWishList no comment Change Log: -- @@ -21,3 +21,4 @@ * Rolling statistics with large windows but limited storage [http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgId=1312178] * I don't understand; we already have some storage-less statistics. What am I missing from the post you refer to? -- AlChou * Oh, I remember now that with the standard deviation algorithm I researched, in order to maintain a '''rolling window''', it would have to store all the data in the window so it could delete the least recent one while adding the most recent one. Sorry for the denseness. -- AlChou + * Provide FFT's. -- AlChou - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 2.0.2 release
+1 On Wed, 2004-10-06 at 03:48, Michael Becke wrote: After a little delay... I propose that we mark the latest code in CVS HTTPCLIENT_2_0 as 2.0.2 and proceed with a release. Please vote as follows: -- Vote: HttpClient 2.0.2 release [x] +1 I am in favor of the release, and will help support it. [ ] +0 I am in favor of the release, but am unable to help support it. [ ] -0 I am not in favor of the release. [ ] -1 I am against this proposal (must include a reason). -- - 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: HttpClient query...
Hi, Thanks for your help. I found the samples specified by you very much useful. I got it working with my JSP by sending user credential parameters which were required at my server. Now the problem is making the same with an applet as it is not working from remote client accessing the JSP. The flow is like this. I have a screen where I enter drive name, and directory to be uploaded and in the next JSP I get the files of specified folder and create multipart request and send to the server along with User credentials. Everything is working fine on the system which both client and server are running. But If I try the same from remote client then It is looking for files in the folder specified by client in server which is generating null pointer exception. Now I need to make the functionality of creating the multipart request at client side, I am planning to do it in the applet. Is it the right way to go for an applet, or can you suggest me some other solution.. thanks, Srinivas. Roland Weber [EMAIL PROTECTED] wrote: Hello Srinivas, you are using HttpClient from within a JSP to connect to the server that is running the JSP? Or to a different server? If you want to set request parameters, you don't do that before creating the multipart request. You create the multipart request, then add the parameters using MP.addParameter(..) or MP.addPart(...). Just make sure to add all required parameters before you *execute* the method. See also the web site at http://jakarta.apache.org/commons/httpclient/methods/multipartpost.html The sample code for multipart file upload is for the 2.0 API, but it should be helpful anyway. Go straight to the actionPerformed method: http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/examples/?only_with_tag=HTTPCLIENT_2_0_BRANCH cheers, Roland Srinivas Velidanda 05.10.2004 14:00 Please respond to Commons HttpClient Project To Commons HttpClient Project cc Subject Re: HttpClient query... Hi Roland, thanks for the reply. I am new to this API and pl let me know how can I do the following. 1. can I set the same parameters coming from the session before creating Multipart request to the Multipart request, if yes, how can I set and how can these parameters can be referred at the server side. 2.I am getting the session parameters in the JSP where I am creating Multipart request, but once I post the Multipart request to the server the session is getting killed. We are not working with cookies. Is there a solution without using cookies or I must go for cookies.. thanks, Srinivas Roland Weber wrote: Hello Srinivas, if the session is handled by a session cookie, just make sure you use the same HttpState object for all requests. That should happen automagically if you do nothing special and re-use one HttpClient for all requests. If the server uses URL rewriting because it believes that the client can't handle cookies, you have a problem. You will have to parse server responses in order to extract URLs with the session information encoded in them. Or convince the server to send cookies. hope that helps, Roland Srinivas Velidanda 05.10.2004 13:32 Please respond to Commons HttpClient Project To [EMAIL PROTECTED] cc Subject HttpClient query... Hi, I am using HttpClient (commons-httpclient-3.0-alpha2) api for file upload. How to handle a session if I am creating a MultipartPost request in a JSP and posting the request using client.executeMethod(mPost) to a servlet URL. Once I send the request the session is getting killed and could not pass on the request to a specific handler in sequence.. Pl. let me know how to handle the session, if possible send me some sample code for that. thanks in advance.. Srinivas. - Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! - Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. - Do you Yahoo!? vote.yahoo.com - Register online to vote today!
Re: HttpClient query...
Hello Srinivas, I think some people have succeeded in using HttpClient from an applet. Remember you will have to sign the applet in order to access the client file system. But you could run into problems accessing the user credentials in the applet. You could also try to write JavaScript code which generates an HTML form, including one file element for every file in the directory. In that case, the browser would take care of building the HTTP request and adding user credentials. The problem once more is to access the file system from the script code. Using a combination of both could work out. It is possible to call JavaScript from an applet and vice versa. So you could write (and sign!) an applet that creates a directory listing, then use that listing in JavaScript to create a form which is then posted by the browser to the server. Other ideas? cheers, Roland Srinivas Velidanda [EMAIL PROTECTED] 06.10.2004 13:43 Please respond to Commons HttpClient Project To [EMAIL PROTECTED] cc Subject Re: HttpClient query... Hi, Thanks for your help. I found the samples specified by you very much useful. I got it working with my JSP by sending user credential parameters which were required at my server. Now the problem is making the same with an applet as it is not working from remote client accessing the JSP. The flow is like this. I have a screen where I enter drive name, and directory to be uploaded and in the next JSP I get the files of specified folder and create multipart request and send to the server along with User credentials. Everything is working fine on the system which both client and server are running. But If I try the same from remote client then It is looking for files in the folder specified by client in server which is generating null pointer exception. Now I need to make the functionality of creating the multipart request at client side, I am planning to do it in the applet. Is it the right way to go for an applet, or can you suggest me some other solution.. thanks, Srinivas. Roland Weber [EMAIL PROTECTED] wrote: Hello Srinivas, you are using HttpClient from within a JSP to connect to the server that is running the JSP? Or to a different server? If you want to set request parameters, you don't do that before creating the multipart request. You create the multipart request, then add the parameters using MP.addParameter(..) or MP.addPart(...). Just make sure to add all required parameters before you *execute* the method. See also the web site at http://jakarta.apache.org/commons/httpclient/methods/multipartpost.html The sample code for multipart file upload is for the 2.0 API, but it should be helpful anyway. Go straight to the actionPerformed method: http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/examples/?only_with_tag=HTTPCLIENT_2_0_BRANCH cheers, Roland Srinivas Velidanda 05.10.2004 14:00 Please respond to Commons HttpClient Project To Commons HttpClient Project cc Subject Re: HttpClient query... Hi Roland, thanks for the reply. I am new to this API and pl let me know how can I do the following. 1. can I set the same parameters coming from the session before creating Multipart request to the Multipart request, if yes, how can I set and how can these parameters can be referred at the server side. 2.I am getting the session parameters in the JSP where I am creating Multipart request, but once I post the Multipart request to the server the session is getting killed. We are not working with cookies. Is there a solution without using cookies or I must go for cookies.. thanks, Srinivas Roland Weber wrote: Hello Srinivas, if the session is handled by a session cookie, just make sure you use the same HttpState object for all requests. That should happen automagically if you do nothing special and re-use one HttpClient for all requests. If the server uses URL rewriting because it believes that the client can't handle cookies, you have a problem. You will have to parse server responses in order to extract URLs with the session information encoded in them. Or convince the server to send cookies. hope that helps, Roland Srinivas Velidanda 05.10.2004 13:32 Please respond to Commons HttpClient Project To [EMAIL PROTECTED] cc Subject HttpClient query... Hi, I am using HttpClient (commons-httpclient-3.0-alpha2) api for file upload. How to handle a session if I am creating a MultipartPost request in a JSP and posting the request using client.executeMethod(mPost) to a servlet URL. Once I send the request the session is getting killed and could not pass on the request to a specific handler in sequence.. Pl. let me know how to handle the session, if possible send me some sample code for that. thanks in advance.. Srinivas. - Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! - Do you Yahoo!? Yahoo!
RE: [VOTE] 2.0.2 release
+0 -Original Message- From: Michael Becke [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 05, 2004 7:48 PM To: Commons HttpClient Project Subject: [VOTE] 2.0.2 release After a little delay... I propose that we mark the latest code in CVS HTTPCLIENT_2_0 as 2.0.2 and proceed with a release. Please vote as follows: -- Vote: HttpClient 2.0.2 release [ ] +1 I am in favor of the release, and will help support it. [ ] +0 I am in favor of the release, but am unable to help support it. [ ] -0 I am not in favor of the release. [ ] -1 I am against this proposal (must include a reason). -- - 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 31471] - HostConfiguration handling requires cleanup
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=31471. 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=31471 HostConfiguration handling requires cleanup --- Additional Comments From [EMAIL PROTECTED] 2004-10-06 16:52 --- Mike, In my opinion HttpMethod interface is hopelessly broken. Having or not having HttpMethod#getHost will not significantly change the situation. I will commit the patch as is shortly, so Vikram could resume testing the preferences architecture. Should you strongly favour parsing the URI, I'll submit a corrective patch Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
