Re: DO NOT REPLY [Bug 32094] - [email] All exceptions seem to be thrown as messagingExceptions
I'm not sure what this class is for but it can be used to check char sets
java.nio.charset.Charset
public void setCharset(String newCharset)
throws UnsupportedEncodingException
{
if (Charset.isSupported(newCharset))
{
this.charset = newCharset;
}
else
{
throw new UnsupportedEncodingException(Charset unknown);
}
}
This would mean that although we'd still need to catch the UEE is
would never have any real likelyhood of getting thown.
If we chose a default charset we can also shorten the address creation
to something like
private InternetAddress createAddress(String name, String email)
throws AddressException
{
InternetAddress address = null;
try
new InternetAddress(email, name, this.charset);
} catch(UEE e) {
}
address.validate();
return address;
}
Would be okay wouldn't it?
Mark
On Mon, 15 Nov 2004 14:17:57 +0800, Corey Scott [EMAIL PROTECTED] wrote:
I also like these ideas and am happy to help you implement them if you
would like. However there is one thing we may want to be aware of. I
dont think that the setCharset causes the UnsupportedCharsetException
to be throw, I believe that it doesn't check it and therefore allows
for any value to be set. As we are trying to keep email small and
maintainable, I dont think it is a good idea to try to added
verfication to our classes. That said, I believe that the only value
I came accross during testing that did throw this exception was the
setName part of the addresses. Therefore the unsupported charset
exception is thrown for all of the setFrom, addTo, addCc, addBcc, etc
functions only at the moment.
I hope this helps,
Corey
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 32094] - [email] All exceptions seem to be thrown as messagingExceptions
Opps.. I'd need to watch teh null pointer exception also :o)
On Mon, 15 Nov 2004 09:43:29 +0100, Mark Lowe [EMAIL PROTECTED] wrote:
I'm not sure what this class is for but it can be used to check char sets
java.nio.charset.Charset
public void setCharset(String newCharset)
throws UnsupportedEncodingException
{
if (Charset.isSupported(newCharset))
{
this.charset = newCharset;
}
else
{
throw new UnsupportedEncodingException(Charset unknown);
}
}
This would mean that although we'd still need to catch the UEE is
would never have any real likelyhood of getting thown.
If we chose a default charset we can also shorten the address creation
to something like
private InternetAddress createAddress(String name, String email)
throws AddressException
{
InternetAddress address = null;
try
new InternetAddress(email, name, this.charset);
} catch(UEE e) {
}
address.validate();
return address;
}
Would be okay wouldn't it?
Mark
On Mon, 15 Nov 2004 14:17:57 +0800, Corey Scott [EMAIL PROTECTED] wrote:
I also like these ideas and am happy to help you implement them if you
would like. However there is one thing we may want to be aware of. I
dont think that the setCharset causes the UnsupportedCharsetException
to be throw, I believe that it doesn't check it and therefore allows
for any value to be set. As we are trying to keep email small and
maintainable, I dont think it is a good idea to try to added
verfication to our classes. That said, I believe that the only value
I came accross during testing that did throw this exception was the
setName part of the addresses. Therefore the unsupported charset
exception is thrown for all of the setFrom, addTo, addCc, addBcc, etc
functions only at the moment.
I hope this helps,
Corey
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/email STATUS.html
epugh 2004/11/15 00:55:58 Modified:emailSTATUS.html Log: Add Joe to list of committers Revision ChangesPath 1.4 +11 -7 jakarta-commons-sandbox/email/STATUS.html Index: STATUS.html === RCS file: /home/cvs/jakarta-commons-sandbox/email/STATUS.html,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- STATUS.html 2 Nov 2004 11:23:04 - 1.3 +++ STATUS.html 15 Nov 2004 08:55:58 - 1.4 @@ -36,7 +36,7 @@ h31. INTRODUCTION/h3 pThe emEmail/em Component contains a set of Java classes provide a -thin convenience layer over JavaMail. +thin convenience layer over JavaMail./p a name=Dependencies/a h32. DEPENDENCIES/h3 @@ -72,17 +72,21 @@ a name=Committers/a h34. COMMITTERS/h3 -pThe following individuals are the current developers and maintainers of this +p +The following individuals are the current developers and maintainers of this component, there are many emeritus developers. The lack of commons committers is -indicative of the long stagnant period, plus recent new blood. Developers who plan to use emEmail/em in their own -projects are encouraged to collaborate on the future development of this -component to ensure that it continues to meet a variety of needs./p +indicative of the long stagnant period, plus recent new blood that haven't been +involved long enough to be voted in as committers. Developers who plan to use +emEmail/em in their own projects are encouraged to collaborate on the future +development of this component to ensure that it continues to meet a variety of needs. +/p ul lia href=mailto:epugh at opensourceconnections.comEric Pugh/a (Commons Committer)/li +lia href=mailto:joe at germuska.comJoe Germuska/a (Commons Sandbox Committer)/li lia href=mailto:corey.scott at gmail.comCorey Scott/a (Contributor)/li lia href=mailto:mark.lowe at boxstuff.comMark Lowe/a (Contributor)/li lia href=mailto:jmcnally at apache.orgJohn McNally/a (Emeritus Committer)/li -lia href=mailto:jon at apache.orgJon Stevens/a (Emeritus Committer) Committer)/li +lia href=mailto:jon at apache.orgJon Stevens/a (Emeritus Committer)/li /ul /body - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/email STATUS.html
epugh 2004/11/15 01:05:51 Modified:emailSTATUS.html Log: update text a bit Revision ChangesPath 1.5 +2 -3 jakarta-commons-sandbox/email/STATUS.html Index: STATUS.html === RCS file: /home/cvs/jakarta-commons-sandbox/email/STATUS.html,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- STATUS.html 15 Nov 2004 08:55:58 - 1.4 +++ STATUS.html 15 Nov 2004 09:05:51 - 1.5 @@ -27,7 +27,6 @@ a href=#Dependencies[Dependencies]/a a href=#Release Info[Release Info]/a a href=#Committers[Committers]/a -a href=#Action Items[Action Items]/a br /br / /div @@ -35,7 +34,7 @@ a name=Introduction/a h31. INTRODUCTION/h3 -pThe emEmail/em Component contains a set of Java classes provide a +pThe emEmail/em Component contains a set of Java classes providing a thin convenience layer over JavaMail./p a name=Dependencies/a - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [email] Website has been updated
Right now, anything that gets deployed into the Apache dist directory gets rsynced over to ibiblio. However, for things like -SNAPSHOT releases, they really shouldn't be going to Ibiblio b/c they aren't really released. I think the commons-email SNAPSHOT was moved when Maven project and IBiblio were first being set up. We should point people to the nightlies that are generated instead. Eric -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Monday, November 15, 2004 6:49 AM To: Jakarta Commons Developers List Subject: Re: [email] Website has been updated Eric, Do you know why the commons-email SNAPSHOT.jar is very old on the maven repo? Do we have to do something to keep this up to date? Thanks, Corey - 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: [email] Handling bounces (was Re: DO NOT REPLY [Bug 18968] - [email] Support SMTP Envelope From (bounce address))
Joe, Can you add your change to /xdocs/changes.xml? Also, you may want to add yourself to project.xml as well :-) Eric -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Sunday, November 14, 2004 9:18 PM To: Jakarta Commons Developers List Subject: [email] Handling bounces (was Re: DO NOT REPLY [Bug 18968] - [email] Support SMTP Envelope From (bounce address)) I updated Email.java and added some notes at the bottom of xdocs/examples.xml. I couldn't figure out any way to have Dumbster simulate a bounce, but I did write a trivial Java app that sent a message with and without setting the bounce address value and confirmed that it did what I intended it to do. I haven't yet got karma for any Commons-proper projects, but I'd be happy to be on STATUS and continue to try to help keep email going after it graduates from the sandbox. Joe I am happy to have you apply this fix, I think I understand better. The one thing I would ask is that you put a bit of documentation into either the javadocs, or even better, into /xdocs describing this behavior. I agree that is shouldn't be a system property. System properties often have a habit of causing nasty head scratching bugs as you wonder why the bounce isn't working properly! Since we are moving to promote from commons-sandbox, are you also a commons committer? Can I list you on the STATUS document? -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex - 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: DO NOT REPLY [Bug 32094] - [email] All exceptions seem to be thrown as messagingExceptions
So, we are agreed that we should have an EmailException that should be thrown? And that will wrap any underlying exception? EmailException should extend NestableException. Eric -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Monday, November 15, 2004 6:18 AM To: Jakarta Commons Developers List; Mark Lowe Subject: Re: DO NOT REPLY [Bug 32094] - [email] All exceptions seem to be thrown as messagingExceptions I also like these ideas and am happy to help you implement them if you would like. However there is one thing we may want to be aware of. I dont think that the setCharset causes the UnsupportedCharsetException to be throw, I believe that it doesn't check it and therefore allows for any value to be set. As we are trying to keep email small and maintainable, I dont think it is a good idea to try to added verfication to our classes. That said, I believe that the only value I came accross during testing that did throw this exception was the setName part of the addresses. Therefore the unsupported charset exception is thrown for all of the setFrom, addTo, addCc, addBcc, etc functions only at the moment. I hope this helps, Corey - 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: DO NOT REPLY [Bug 32094] - [email] All exceptions seem to be thrown as messagingExceptions
I don't mind.. But seems that Javamail already has some exceptions that we're not using why not use them more adding any new ones? If we though the UnsupportedEncodingException in the right place, and then silence is in a reuseable createAddress method.. that should work shouldn't it? It seems reasonable to inform the user that the encoding s/he is trying is dodgy, if done on setCharset() . Likewise an addressexception when setting addresses. I think also controlling the javamail exceptions seems to fit with the idea of being a bridge between javamail and something simpler. Mark On Mon, 15 Nov 2004 09:07:16 -, Eric Pugh [EMAIL PROTECTED] wrote: So, we are agreed that we should have an EmailException that should be thrown? And that will wrap any underlying exception? EmailException should extend NestableException. Eric -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Monday, November 15, 2004 6:18 AM To: Jakarta Commons Developers List; Mark Lowe Subject: Re: DO NOT REPLY [Bug 32094] - [email] All exceptions seem to be thrown as messagingExceptions I also like these ideas and am happy to help you implement them if you would like. However there is one thing we may want to be aware of. I dont think that the setCharset causes the UnsupportedCharsetException to be throw, I believe that it doesn't check it and therefore allows for any value to be set. As we are trying to keep email small and maintainable, I dont think it is a good idea to try to added verfication to our classes. That said, I believe that the only value I came accross during testing that did throw this exception was the setName part of the addresses. Therefore the unsupported charset exception is thrown for all of the setFrom, addTo, addCc, addBcc, etc functions only at the moment. I hope this helps, Corey - 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]
[GUMP@brutus]: Project commons-betwixt (in module jakarta-commons) failed
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-betwixt has an issue affecting its community integration.
This issue affects 3 projects,
and has been outstanding for 12 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-betwixt : Commons Betwixt Package
- commons-jelly-tags-betwixt : This is a Jelly interface for Betwixt.
- jakarta-turbine-stratum : Turbine Components
Full details are available at:
http://brutus.apache.org/gump/public/jakarta-commons/commons-betwixt/index.html
That said, some information snippets are provided here.
The following annotations (debug/informational/warning/error messages) were
provided:
-DEBUG- Sole output [commons-betwixt-15112004.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/commons-betwixt/gump_work/build_jakarta-commons_commons-betwixt.html
Work Name: build_jakarta-commons_commons-betwixt (Type: Build)
Work ended in a state of : Failed
Elapsed: 6 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
org.apache.tools.ant.Main
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml
-Dbuild.sysclasspath=only -Dfinal.name=commons-betwixt-15112004
-Dresourcedir=/usr/local/gump/public/workspace/jakarta-commons/betwixt jar
[Working Directory: /usr/local/gump/public/workspace/jakarta-commons/betwixt]
CLASSPATH:
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/betwixt/target/classes:/usr/local/gump/public/workspace/jakarta-commons/betwixt/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/digester/dist/commons-digester.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-15112004.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.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/dist/junit/junit.jar
-
[javac] ^
[javac]
/home/gump/workspaces2/public/workspace/jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/io/BeanCreateRule.java:496:
warning: isWrapCollectionsInElement() in
org.apache.commons.betwixt.ElementDescriptor has been deprecated
[javac] if
(childDescriptor.isWrapCollectionsInElement()) {
[javac]^
[javac]
/home/gump/workspaces2/public/workspace/jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/io/BeanCreateRule.java:507:
warning: org.apache.commons.betwixt.digester.XMLIntrospectorHelper in
org.apache.commons.betwixt.digester has been deprecated
[javac] if ( XMLIntrospectorHelper.isPrimitiveType(
beanClass ) ) {
[javac] ^
[javac]
/home/gump/workspaces2/public/workspace/jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/io/BeanCreateRule.java:507:
warning: isPrimitiveType(java.lang.Class) in
org.apache.commons.betwixt.digester.XMLIntrospectorHelper has been deprecated
[javac] if ( XMLIntrospectorHelper.isPrimitiveType(
beanClass ) ) {
[javac] ^
[javac]
/home/gump/workspaces2/public/workspace/jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/io/BeanCreateRule.java:574:
warning: body(java.lang.String) in org.apache.commons.digester.Rule has been
deprecated
[javac] public void body(String text) throws Exception {
[javac] ^
[javac] 10 warnings
[copy] Copying 12 files to
/home/gump/workspaces2/public/workspace/jakarta-commons/betwixt/target/classes
[copy] Copying 31 files to
[GUMP@brutus]: Project commons-jelly-tags-junit (in module jelly-tags) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-junit has an issue affecting its community integration. This issue affects 16 projects, and has been outstanding for 12 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-ant : This is a Jelly interface for Ant. - commons-jelly-tags-bean : A tag library for mapping tags to beans using a similar appr... - commons-jelly-tags-beanshell : This is a Jelly interface for BeanShell. - commons-jelly-tags-define : This is a Jelly taglib for defining new tags and tag librari... - commons-jelly-tags-dynabean : This is a Jelly taglib for defining new tags and tag librari... - commons-jelly-tags-fmt : This is a set of Jelly i18n tags. - commons-jelly-tags-html : These Jelly tags can scrub commons errors in HTML syntax. - commons-jelly-tags-jsl : The Jelly Stylesheet Library (JSL) - commons-jelly-tags-junit : The Jelly Unit Test Tags - commons-jelly-tags-log : The Jelly Logging Tags - commons-jelly-tags-sql : This is a Jelly interface for SQL - commons-jelly-tags-threads : A library for processing Jelly scripts using multiple thread... - commons-jelly-tags-util : This is a set of Jelly utility tags. - commons-jelly-tags-validate : This is a Jelly interface for XML validation. - commons-jelly-tags-xml : ??? - commons-jelly-tags-xmlunit : This is a Jelly interface for unit testing XML applications. Full details are available at: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-junit/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-junit-15112004.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/jelly-tags/commons-jelly-tags-junit/gump_work/build_jelly-tags_commons-jelly-tags-junit.html Work Name: build_jelly-tags_commons-jelly-tags-junit (Type: Build) Work ended in a state of : 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 org.apache.tools.ant.Main -Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dfinal.name=commons-jelly-tags-junit-15112004 jar [Working Directory: /usr/local/gump/public/workspace/jelly-tags/junit] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jelly-tags/junit/target/classes:/usr/local/gump/public/workspace/jelly-tags/junit/target/test-classes:/usr/local/gump/public/workspace/jakarta-commons/jelly/target/commons-jelly-15112004.jar:/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-15112004.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-15112004.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-15112004.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/packages/dom4j-1.4/dom4j-full.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-15112004.jar:/usr/local/gump/public/workspace/jakarta-commons/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr154/dist/lib/servlet-api.jar:/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152/dist/lib/jsp-api.jar:/usr/local/gump/public/workspace/jakarta-taglibs/dist/standard/lib/standard.jar:/usr/local/gump/public/workspace/jakarta-taglibs/dist/standard/lib/jstl.jar:/usr/local/gump/packages/nekohtml-0.9.3/nekohtmlXni.jar:/usr/local/gump/packages/nekohtml-0.9.3/nekohtml.jar - Buildfile:
[GUMP@brutus]: Project commons-jelly-tags-swing (in module jelly-tags) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-swing has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 12 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-swing : This is a Jelly interface for configuring Swing applications... Full details are available at: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-swing/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-swing-15112004.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/jelly-tags/commons-jelly-tags-swing/gump_work/build_jelly-tags_commons-jelly-tags-swing.html Work Name: build_jelly-tags_commons-jelly-tags-swing (Type: Build) Work ended in a state of : Failed Elapsed: 4 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 org.apache.tools.ant.Main -Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dfinal.name=commons-jelly-tags-swing-15112004 jar [Working Directory: /usr/local/gump/public/workspace/jelly-tags/swing] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jelly-tags/swing/target/classes:/usr/local/gump/public/workspace/jelly-tags/swing/target/test-classes:/usr/local/gump/public/workspace/jakarta-commons/jelly/target/commons-jelly-15112004.jar:/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-15112004.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-15112004.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-15112004.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/packages/dom4j-1.4/dom4j-full.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-15112004.jar:/usr/local/gump/public/workspace/jakarta-commons/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr154/dist/lib/servlet-api.jar:/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152/dist/lib/jsp-api.jar:/usr/local/gump/public/workspace/jakarta-taglibs/dist/standard/lib/standard.jar:/usr/local/gump/public/workspace/jakarta-taglibs/dist/standard/lib/jstl.jar:/usr/local/gump/packages/nekohtml-0.9.3/nekohtmlXni.jar:/usr/local/gump/packages/nekohtml-0.9.3/nekohtml.jar - Buildfile: build.xml init: [mkdir] Created dir: /home/gump/workspaces2/public/workspace/jelly-tags/swing/target/lib get-deps: compile: [mkdir] Created dir: /home/gump/workspaces2/public/workspace/jelly-tags/swing/target/classes [javac] Compiling 35 source files to /home/gump/workspaces2/public/workspace/jelly-tags/swing/target/classes [copy] Copying 10 files to /home/gump/workspaces2/public/workspace/jelly-tags/swing/target/test-classes compile-tests: [javac] Compiling 5 source files to /home/gump/workspaces2/public/workspace/jelly-tags/swing/target/test-classes internal-test: [mkdir] Created dir: /home/gump/workspaces2/public/workspace/jelly-tags/swing/target/test-reports [junit] Running org.apache.commons.jelly.swing.TestConverters BUILD FAILED /home/gump/workspaces2/public/workspace/jelly-tags/swing/build.xml:97: Invalid attribute: builtin Total time: 3 seconds - To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-swing/rss.xml - Atom:
Re: DO NOT REPLY [Bug 32094] - [email] All exceptions seem to be thrown as messagingExceptions
I like the intent, but I am not sure that it will work as we intend.
Having the charset checked when it is set is a definate must, but it
doesnt mean that the supplied values are of the same charset. Eg. you
can setCharset to US_ASCI and then supply a chinese name to the name
property of an address. Unless we are going to validate that the
supplied inputs are the same as the set charset (or auto-convert
them), this exception will still be thrown.
All that said, my preferences are for checking the setCharset (as Mark
proposed) and NOT suppressing the exceptions in the other functions.
-Corey
On Mon, 15 Nov 2004 09:37:51 -, Eric Pugh [EMAIL PROTECTED] wrote:
It seems like having a default charset, and being able to override it is the
way to go. After all, we are aiming to provide a convenience layer. Most
developers don't have to deal with the charset at all...
-Original Message-
From: Mark Lowe [mailto:[EMAIL PROTECTED]
Sent: Monday, November 15, 2004 8:45 AM
To: Corey Scott
Cc: Jakarta Commons Developers List
Subject: Re: DO NOT REPLY [Bug 32094] - [email] All exceptions seem to
be thrown as messagingExceptions
Opps.. I'd need to watch teh null pointer exception also :o)
On Mon, 15 Nov 2004 09:43:29 +0100, Mark Lowe [EMAIL PROTECTED] wrote:
I'm not sure what this class is for but it can be used to check
char sets
java.nio.charset.Charset
public void setCharset(String newCharset)
throws UnsupportedEncodingException
{
if (Charset.isSupported(newCharset))
{
this.charset = newCharset;
}
else
{
throw new UnsupportedEncodingException(Charset unknown);
}
}
This would mean that although we'd still need to catch the UEE is
would never have any real likelyhood of getting thown.
If we chose a default charset we can also shorten the address creation
to something like
private InternetAddress createAddress(String name, String email)
throws AddressException
{
InternetAddress address = null;
try
new InternetAddress(email, name, this.charset);
} catch(UEE e) {
}
address.validate();
return address;
}
Would be okay wouldn't it?
Mark
On Mon, 15 Nov 2004 14:17:57 +0800, Corey Scott
[EMAIL PROTECTED] wrote:
I also like these ideas and am happy to help you implement them if you
would like. However there is one thing we may want to be aware of. I
dont think that the setCharset causes the UnsupportedCharsetException
to be throw, I believe that it doesn't check it and therefore allows
for any value to be set. As we are trying to keep email small and
maintainable, I dont think it is a good idea to try to added
verfication to our classes. That said, I believe that the only value
I came accross during testing that did throw this exception was the
setName part of the addresses. Therefore the unsupported charset
exception is thrown for all of the setFrom, addTo, addCc, addBcc, etc
functions only at the moment.
I hope this helps,
Corey
-
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 32240] New: - XMLConfiguration::save() does not keep element hierarchy
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=32240.
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=32240
Summary: XMLConfiguration::save() does not keep element hierarchy
Product: Commons
Version: 1.0 Final
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: Configuration
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I am using commons.configuration.XMLConfiguration to save some configuration
elements of my Java 1.4.2 application in a file. If I use nested elements in my
configuration, this structure is not mapped to the saved XML-File.
As an example, consider the following simple main method:
public static void main(String[] args) {
try {
XMLConfiguration myXMLConfig = new XMLConfiguration();
myXMLConfig.setProperty(A,valueA);
myXMLConfig.setProperty(A.B,valueA.B);
myXMLConfig.setProperty(A.B.C.D,valueA.B.C.D);
myXMLConfig.setProperty(E.F.G.H,valueE.F.G.H);
myXMLConfig.setProperty(I.J.K.L,valueI.J.K.L);
myXMLConfig.setProperty(I.J.K,null);
myXMLConfig.setProperty(I.J,null);
myXMLConfig.setProperty(I,null);
myXMLConfig.save(testConfig.xml);
} catch (ConfigurationException e) {
System.out.println(ERROR: + e.toString());
}
}
What I expect to get by executing this piece of code is the following (modulo
formatting issues, of course):
?xml version=1.0 encoding=UTF-8?
configuration
A valueA
B valueB
C
D valueD
/D
/C
/B
/A
E
F
G
H valueE.F.G.H
/H
/G
/F
/E
I null
J null
K null
L valueI.J.K.L
/L
/K
/J
/I
/configuration
The null-values in I.J.K and so on have only been introduced to show that such a
workarund does not work, either.
What I actually receive by storing testConfig.xml is the following:
?xml version=1.0 encoding=UTF-8?
configuration
AvalueABvalueA.BDvalueA.B.C.D/D
/B
/A
HvalueE.F.G.H/H
LvalueI.J.K.L/L
Knull/K
Jnull/J
Inull/I
/configuration
In my opinion, at least two failures can be seen above:
a) The elements I, J, K, and L are not nested, but all declared on top level of
the XML-document
b) Elements without any value are not automatically inserted as, e.g., element
C for the path A.B.C.D or elements E, F, and G for E.F.G.H
I also tried to use HierarchicalXMLConfiguration, but corresponding objects can
not be saved:
ERROR: org.apache.commons.configuration.ConfigurationException: Can't save
HierarchicalXMLConfigurations
I am using the final Version 1.0 (not RC1 nor RC2) JAR-Files provied by
http://jakarta.apache.org/commons/configuration/downloads.html
Best regards,
Christian Kemmer
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32240] - [configuration] XMLConfiguration.save() does not keep element hierarchy
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=32240. 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=32240 [EMAIL PROTECTED] changed: What|Removed |Added OS/Version|Windows XP |All Platform|PC |All Summary|XMLConfiguration::save()|[configuration] |does not keep element |XMLConfiguration.save() does |hierarchy |not keep element hierarchy -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Created: (JELLY-163) Allow Expressions to throw exceptions
Hans,
I think this is exactly what made me stumble... I don't really get
this...
(I'm again about my fuzzyness of understanding jelly lifecycle... sorry
for this!). I see two times where such an exception can occur:
- at compilation time. This should be the same when a tag would meet
unknown attributes or a (strict) taglib would meet an unknown tag.
- at execution time, when the expression should return something
(maybe).
In both cases, the exception should be thrown and wrapped into some
generic exception which should include location information.
My current attempt was the script:
j:jelly xmlns:j=jelly:core
j:set var=b value=blop/
${b-'b'}
/j:jelly
Which did throw me an exception (as I instructed it) but which was not
caught, or wrapped...
In which of the two phases should such a thing be caught ?
Are there other phases ?
thanks
paul
Le 15 nov. 04, à 02:32, Hans Gilde (JIRA) a écrit :
Expressions are evaluated before the tag is run, so it normally
wouldn't know anything about them.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 32094] - [email] All exceptions seem to be thrown as messagingExceptions
I guess thats why sun throw unsupported charset and address exceptions.
As you know, i dont mind passing either back (as long as the
setCharset() throws . On the rare occasions when the user enters a
unsupported charset then bubbling the exception up would seem the
thing to do.
In both cases the exception thrown would have some semantic value. I
can help thinking that the folk who developed javamail would have been
where we are now.
A generic EmailException I think would cloud this issue. Like throwing
Messaging exception does.
One alternative is to just use the InternetAddress(String, String)
rather than the one inclusive of charset. I need to check if it would
default to the mail or the system however.
Mark
On Mon, 15 Nov 2004 18:00:43 +0800, Corey Scott [EMAIL PROTECTED] wrote:
I like the intent, but I am not sure that it will work as we intend.
Having the charset checked when it is set is a definate must, but it
doesnt mean that the supplied values are of the same charset. Eg. you
can setCharset to US_ASCI and then supply a chinese name to the name
property of an address. Unless we are going to validate that the
supplied inputs are the same as the set charset (or auto-convert
them), this exception will still be thrown.
All that said, my preferences are for checking the setCharset (as Mark
proposed) and NOT suppressing the exceptions in the other functions.
-Corey
On Mon, 15 Nov 2004 09:37:51 -, Eric Pugh [EMAIL PROTECTED] wrote:
It seems like having a default charset, and being able to override it is the
way to go. After all, we are aiming to provide a convenience layer. Most
developers don't have to deal with the charset at all...
-Original Message-
From: Mark Lowe [mailto:[EMAIL PROTECTED]
Sent: Monday, November 15, 2004 8:45 AM
To: Corey Scott
Cc: Jakarta Commons Developers List
Subject: Re: DO NOT REPLY [Bug 32094] - [email] All exceptions seem to
be thrown as messagingExceptions
Opps.. I'd need to watch teh null pointer exception also :o)
On Mon, 15 Nov 2004 09:43:29 +0100, Mark Lowe [EMAIL PROTECTED] wrote:
I'm not sure what this class is for but it can be used to check
char sets
java.nio.charset.Charset
public void setCharset(String newCharset)
throws UnsupportedEncodingException
{
if (Charset.isSupported(newCharset))
{
this.charset = newCharset;
}
else
{
throw new UnsupportedEncodingException(Charset unknown);
}
}
This would mean that although we'd still need to catch the UEE is
would never have any real likelyhood of getting thown.
If we chose a default charset we can also shorten the address creation
to something like
private InternetAddress createAddress(String name, String email)
throws AddressException
{
InternetAddress address = null;
try
new InternetAddress(email, name, this.charset);
} catch(UEE e) {
}
address.validate();
return address;
}
Would be okay wouldn't it?
Mark
On Mon, 15 Nov 2004 14:17:57 +0800, Corey Scott
[EMAIL PROTECTED] wrote:
I also like these ideas and am happy to help you implement them if you
would like. However there is one thing we may want to be aware of. I
dont think that the setCharset causes the UnsupportedCharsetException
to be throw, I believe that it doesn't check it and therefore allows
for any value to be set. As we are trying to keep email small and
maintainable, I dont think it is a good idea to try to added
verfication to our classes. That said, I believe that the only value
I came accross during testing that did throw this exception was the
setName part of the addresses. Therefore the unsupported charset
exception is thrown for all of the setFrom, addTo, addCc, addBcc, etc
functions only at the moment.
I hope this helps,
Corey
-
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 32020] - [configuration] Fails silently if asked to save to an invalid filename
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=32020. 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=32020 [EMAIL PROTECTED] changed: What|Removed |Added Priority||P1 Summary|Fails silently if asked to |[configuration] Fails |save to an invalid filename |silently if asked to save to ||an invalid filename -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Promote Email to Commons Proper
Email exhibits all of the qualities of a component that should be in Commons proper: - It's small and focused. - It's API is well defined - It has good unit test coverage. It has also been tested in real world email applications (Turbine 2.3, 2.4, 3.0, Scarab). - It has automated nightly builds, website, and Maven all working - It has incubated in the sandbox for long enough to become stable (97% Jcoverage!) Email is a mature component that should move to Commons proper so it can be released to the public. Here's my +1. The website has additional information: http://jakarta.apache.org/commons/sandbox/email/index.html Here's the component proposal for reference: (1) INTRODUCTION The Email Component contains a set of Java classes providing a thin convenience layer over JavaMail. (2) DEPENDENCIES The Email component is dependent upon the following external components for development and use: * Java Development Kit (Version 1.2 or later) * JavaMail . (Version 1.2 or later) * JavaBeans Activation Framework (Version 1.0.1 or later) - dependency of JavaMail. * JUnit Testing Framework (Version 3.7 or later) - for unit tests only, not required for deployment * Dumbster Fake SMTP (Version 1.0.3 or later) - for unit tests only, not required for deployment (3) Required Jakarta-Commons Resources CVS Repository - New directory email in the jakarta-commons CVS repository. Mailing List - Discussions will take place on the general commons-dev mailing list. To help list subscribers identify messages of interest, it is suggested that the message subject of messages about this component be prefixed with [email]. Bugzilla - New component Email under the Commons product category, with appropriate version identifiers as needed. (4) Initial Committers The initial committers on the DBUtils component shall be: * Eric Pugh (Commons Committer) * Joe Germuska (Commons Sandbox Committer) Current active contributors include: * Corey Scott * Mark Lowe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32020] - [configuration] Fails silently if asked to save to an invalid filename
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=32020. 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=32020 --- Additional Comments From [EMAIL PROTECTED] 2004-11-15 13:02 --- What's the best solution ? Throwing a ConfigurationException wrapping the FileNotFoundException, or creating the path and the file automatically ? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/email/xdocs changes.xml
germuska2004/11/15 04:02:33 Modified:email/xdocs changes.xml Log: add support for bounce handling and document in examples.xml Revision ChangesPath 1.11 +5 -2 jakarta-commons-sandbox/email/xdocs/changes.xml Index: changes.xml === RCS file: /home/cvs/jakarta-commons-sandbox/email/xdocs/changes.xml,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- changes.xml 11 Nov 2004 09:22:02 - 1.10 +++ changes.xml 15 Nov 2004 12:02:32 - 1.11 @@ -24,12 +24,12 @@ action dev=epugh type=add Integrate our own checkstyle config instead of using Turbine style only. /action - action dev=epugh type=add due-to=Joe Germuska + action dev=epugh type=add due-to=Joe Germuska issue=18968 Clone the System.getProperties() call instead of putting random properties into it. /action action dev=epugh type=add issue=16859 -Can't supply a javax.mail.Session to Commons Email componenet +Can't supply a javax.mail.Session to Commons Email component /action action dev=epugh type=add issue=30973 due-to=Corey Scott HTML email with plain text alternative and attachments @@ -43,6 +43,9 @@ action dev=epugh type=update Update dependencies to latest available. /action + action dev=germuska type=add issue=18968 +Support the delivery of bounced messages to an address other than from. + /action /release /body /document - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/email project.xml
germuska2004/11/15 04:04:38 Modified:emailproject.xml Log: add myself to project.xml Revision ChangesPath 1.22 +5 -0 jakarta-commons-sandbox/email/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons-sandbox/email/project.xml,v retrieving revision 1.21 retrieving revision 1.22 diff -u -r1.21 -r1.22 --- project.xml 2 Nov 2004 11:59:55 - 1.21 +++ project.xml 15 Nov 2004 12:04:38 - 1.22 @@ -71,6 +71,11 @@ email[EMAIL PROTECTED]/email organizationZenplex/organization /developer +developer + nameJoe Germuska/name + idgermuska/id + email[EMAIL PROTECTED]/email +/developer /developers contributors - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32020] - [configuration] Fails silently if asked to save to an invalid filename
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=32020. 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=32020 --- Additional Comments From [EMAIL PROTECTED] 2004-11-15 13:16 --- Throwing a ConfigurationException wrapping the FileNotFoundException, or creating the path and the file automatically ? Just IMO, creating the file would be good - but not always possible. The path might be completely invalid or on a drive that isn't present etc. In which case you'd have to throw. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Promote Email to Commons Proper
+1 Email is indeed a nice *component*, that simplifies the JavaMail-Api. -Matthias -Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED] Sent: Monday, November 15, 2004 12:10 PM To: Commons-Dev Subject: [VOTE] Promote Email to Commons Proper Email exhibits all of the qualities of a component that should be in Commons proper: - It's small and focused. - It's API is well defined - It has good unit test coverage. It has also been tested in real world email applications (Turbine 2.3, 2.4, 3.0, Scarab). - It has automated nightly builds, website, and Maven all working - It has incubated in the sandbox for long enough to become stable (97% Jcoverage!) Email is a mature component that should move to Commons proper so it can be released to the public. Here's my +1. The website has additional information: http://jakarta.apache.org/commons/sandbox/email/index.html Here's the component proposal for reference: (1) INTRODUCTION The Email Component contains a set of Java classes providing a thin convenience layer over JavaMail. (2) DEPENDENCIES The Email component is dependent upon the following external components for development and use: * Java Development Kit (Version 1.2 or later) * JavaMail . (Version 1.2 or later) * JavaBeans Activation Framework (Version 1.0.1 or later) - dependency of JavaMail. * JUnit Testing Framework (Version 3.7 or later) - for unit tests only, not required for deployment * Dumbster Fake SMTP (Version 1.0.3 or later) - for unit tests only, not required for deployment (3) Required Jakarta-Commons Resources CVS Repository - New directory email in the jakarta-commons CVS repository. Mailing List - Discussions will take place on the general commons-dev mailing list. To help list subscribers identify messages of interest, it is suggested that the message subject of messages about this component be prefixed with [email]. Bugzilla - New component Email under the Commons product category, with appropriate version identifiers as needed. (4) Initial Committers The initial committers on the DBUtils component shall be: * Eric Pugh (Commons Committer) * Joe Germuska (Commons Sandbox Committer) Current active contributors include: * Corey Scott * Mark Lowe - 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: [VOTE] Promote Email to Commons Proper
Hi, - It has good unit test coverage. It has also been tested in real world email applications (Turbine 2.3, 2.4, 3.0, Scarab). Is it relied upon by these packages, out of curiosity? Or was it tested and not used subsequently? +1 from me. Good proposal. 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]
[GUMP@brutus]: Project commons-net (in module jakarta-commons) success
To whom it may satisfy... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-net *no longer* has an issue. The current state of this project is 'Success'. Full details are available at: http://brutus.apache.org/gump/public/jakarta-commons/commons-net/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-net-15112004.jar] identifier set to project name -INFO- Made directory [/usr/local/gump/public/workspace/jakarta-commons/net/target/classes] -INFO- Made directory [/usr/local/gump/public/workspace/jakarta-commons/net/target/test-classes] -INFO- No license on redistributable project with outputs. The following work was performed: http://brutus.apache.org/gump/public/jakarta-commons/commons-net/gump_work/build_jakarta-commons_commons-net.html Work Name: build_jakarta-commons_commons-net (Type: Build) Work ended in a state of : Success Elapsed: 1 min 43 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 org.apache.tools.ant.Main -Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dfinal.name=commons-net-15112004 dist [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/net] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/net/target/classes:/usr/local/gump/public/workspace/jakarta-commons/net/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-oro/jakarta-oro-15112004.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar - [javadoc] Generating /home/gump/workspaces2/public/workspace/jakarta-commons/net/dist/docs/api/org/apache/commons/net/ntp/NTPUDPClient.html... [javadoc] Returns the NTP protocol version number that client sets on request packet [javadoc] that is sent to remote host (e.g. [javadoc] This sentence is different from what would be generated using -breakiterator: [javadoc] Returns the NTP protocol version number that client sets on request packet [javadoc] that is sent to remote host (e.g. 3=NTP v3, 4=NTP v4, etc.) [javadoc] Generating /home/gump/workspaces2/public/workspace/jakarta-commons/net/dist/docs/api/org/apache/commons/net/ntp/NtpUtils.html... [javadoc] /home/gump/workspaces2/public/workspace/jakarta-commons/net/src/java/org/apache/commons/net/ntp/NtpUtils.java:33: warning - The first sentence is interpreted to be: [javadoc] Returns 32-bit integer address to IPv4 address string %d.%d.%d.%d format. [javadoc] This sentence is different from what would be generated using -breakiterator: [javadoc] Returns 32-bit integer address to IPv4 address string %d. [javadoc] /home/gump/workspaces2/public/workspace/jakarta-commons/net/src/java/org/apache/commons/net/ntp/NtpV3Impl.java:127: warning - The first sentence is interpreted to be: [javadoc] Generating /home/gump/workspaces2/public/workspace/jakarta-commons/net/dist/docs/api/org/apache/commons/net/ntp/NtpV3Impl.html... [javadoc] Returns poll interval as defined in RFC-1305, which is an eight-bit [javadoc] signed integer indicating the maximum interval between successive [javadoc] messages, in seconds to the nearest power of two (e.g. [javadoc] This sentence is different from what would be generated using -breakiterator: [javadoc] Returns poll interval as defined in RFC-1305, which is an eight-bit [javadoc] signed integer indicating the maximum interval between successive [javadoc] messages, in seconds to the nearest power of two (e.g. value of six [javadoc] indicates an interval of 64 seconds. [javadoc] /home/gump/workspaces2/public/workspace/jakarta-commons/net/src/java/org/apache/commons/net/ntp/TimeStamp.java:400: warning - The first sentence is interpreted to be: [javadoc] Generating /home/gump/workspaces2/public/workspace/jakarta-commons/net/dist/docs/api/org/apache/commons/net/ntp/TimeStamp.html... [javadoc] Converts this codeTimeStamp/code object to a codeString/code [javadoc] of the form: [javadoc] blockquote [javadoc] This sentence is different from what would be
[VOTE] Promote Transaction to Commons Proper
Folks, as described in previous posts and inspired by the fine proposal for email promotion I would like to see the transaction component http://jakarta.apache.org/commons/sandbox/transaction/ promoted to commons proper. The initial committers would be Stefan Lützkendorf, James Mason, Daniel Florey and me. AFAIK none of us is a committer in commons proper so the promotion would include making as committers there. We all are Jakarta Slide committers and this is where the component came from. We factored out code for a transactional file system, transactional maps (implementing Map interface) with different ACID strategies, general purpose locks and a few more helper classes. Junit tests exist for all parts and succeed: http://jakarta.apache.org/commons/sandbox/transaction/junit-report.html Javadoc is pretty complete http://jakarta.apache.org/commons/sandbox/transaction/apidocs/index.html and general documentation and even a short tutorial for locks exist: http://jakarta.apache.org/commons/sandbox/transaction/locks/tutorial.html The transaction component is stable enough to be released as a 1.0 soon after promotion and would initially be maintained by the committers of the Slide community. Once promoted growth is anticipated as even in the sandbox it attracted some attention. As I am not a commons committer, I have no binding vote, but my non-binding vote of course is +1. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote Transaction to Commons Proper
My (non-binding) vote: +1 as this package makes the complicated transaction stuff more handy Daniel Jakarta Commons Developers List [EMAIL PROTECTED] schrieb am 15.11.04 18:50:02: Folks, as described in previous posts and inspired by the fine proposal for email promotion I would like to see the transaction component http://jakarta.apache.org/commons/sandbox/transaction/ promoted to commons proper. The initial committers would be Stefan Lützkendorf, James Mason, Daniel Florey and me. AFAIK none of us is a committer in commons proper so the promotion would include making as committers there. We all are Jakarta Slide committers and this is where the component came from. We factored out code for a transactional file system, transactional maps (implementing Map interface) with different ACID strategies, general purpose locks and a few more helper classes. Junit tests exist for all parts and succeed: http://jakarta.apache.org/commons/sandbox/transaction/junit-report.html Javadoc is pretty complete http://jakarta.apache.org/commons/sandbox/transaction/apidocs/index.html and general documentation and even a short tutorial for locks exist: http://jakarta.apache.org/commons/sandbox/transaction/locks/tutorial.html The transaction component is stable enough to be released as a 1.0 soon after promotion and would initially be maintained by the committers of the Slide community. Once promoted growth is anticipated as even in the sandbox it attracted some attention. As I am not a commons committer, I have no binding vote, but my non-binding vote of course is +1. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt neu bei WEB.DE FreeMail: http://freemail.web.de/?mc=021193 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Promote Email to Commons Proper
The code originally came from Turbine, back in the Turbine 2.2 time frame. It then pretty much sat in the sandbox. Turbine 3 picked it up, and therefore Scarab, built on Turbine 3, uses it. Because we didn't want to add yet another unreleased component to Turbine 2.x, we haven't removed the original code. The plan is to move to commons-email once a 1.0 is released. ERic -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Monday, November 15, 2004 4:51 PM To: Jakarta Commons Developers List Subject: RE: [VOTE] Promote Email to Commons Proper Hi, - It has good unit test coverage. It has also been tested in real world email applications (Turbine 2.3, 2.4, 3.0, Scarab). Is it relied upon by these packages, out of curiosity? Or was it tested and not used subsequently? +1 from me. Good proposal. 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32251] New: - org.apache.commons.beanutils.ConvertingWrapDynaBean exception handling
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=32251.
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=32251
Summary: org.apache.commons.beanutils.ConvertingWrapDynaBean
exception handling
Product: Commons
Version: Nightly Builds
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Bean Utilities
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I received an error java.lang.IllegalArgumentException: Property 'filesIterator'
has no write method when in fact the bean did have a setFilesIterator method.
This happend because there was a NullPointerException in the filesIterator. The
exception thrown did not report the initial cause nor log the error.
The class org.apache.commons.beanutils.ConvertingWrapDynaBean catches Throwable
and does not propogate the initial cause which makes finding some error hard.
Attached is a patch that fixes this.
===
RCS file:
/home/cvspublic/jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/ConvertingWrapDyn
aBean.java,v
retrieving revision 1.7
diff -d -r1.7 ConvertingWrapDynaBean.java
18a19,20
import java.lang.reflect.InvocationTargetException;
70,71c72,73
} catch (Throwable t) {
throw new IllegalArgumentException
---
} catch (InvocationTargetException t) {
IllegalArgumentException e = new IllegalArgumentException
72a75,76
e.initCause(t);
throw e;
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32251] - org.apache.commons.beanutils.ConvertingWrapDynaBean exception handling
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=32251. 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=32251 --- Additional Comments From [EMAIL PROTECTED] 2004-11-15 19:36 --- Created an attachment (id=13469) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=13469action=view) Only catch specific exceptions and propogate them. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32251] - [beanutils] ConvertingWrapDynaBean exception handling
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=32251. 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=32251 [EMAIL PROTECTED] changed: What|Removed |Added Summary|org.apache.commons.beanutils|[beanutils] |.ConvertingWrapDynaBean |ConvertingWrapDynaBean |exception handling |exception handling -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project commons-betwixt (in module jakarta-commons) success
To whom it may satisfy... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-betwixt *no longer* has an issue. The current state of this project is 'Success'. Full details are available at: http://brutus.apache.org/gump/public/jakarta-commons/commons-betwixt/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-betwixt-15112004.jar] identifier set to project name -INFO- No license on redistributable project with outputs. The following work was performed: http://brutus.apache.org/gump/public/jakarta-commons/commons-betwixt/gump_work/build_jakarta-commons_commons-betwixt.html Work Name: build_jakarta-commons_commons-betwixt (Type: Build) Work ended in a state of : Success Elapsed: 1 min 14 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 org.apache.tools.ant.Main -Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dfinal.name=commons-betwixt-15112004 -Dresourcedir=/usr/local/gump/public/workspace/jakarta-commons/betwixt jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/betwixt] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/betwixt/target/classes:/usr/local/gump/public/workspace/jakarta-commons/betwixt/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/digester/dist/commons-digester.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-15112004.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.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/dist/junit/junit.jar - [junit] Testsuite: org.apache.commons.betwixt.strategy.TestSimpleTypeMapper [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.642 sec [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.642 sec [junit] Testcase: testDefaultExceptionType took 0.013 sec [junit] Testcase: testNewStrategy took 0.168 sec [junit] Testcase: testWrite took 0.189 sec [junit] Testcase: testRead took 0.105 sec [junit] Running org.apache.commons.betwixt.strategy.Testi18nObjectStringConversion [junit] Testsuite: org.apache.commons.betwixt.strategy.Testi18nObjectStringConversion [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.287 sec [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.287 sec [junit] Testcase: testFrenchDefaultLocale took 0.007 sec [junit] Testcase: testBaseConverter took 0.002 sec [junit] Testcase: testConvertUtilsConverter took 0.124 sec [junit] Testcase: testDefaultOSConverter took 0.004 sec [junit] Testcase: testDefaultOSConverterDates took 0.009 sec [junit] Running org.apache.commons.betwixt.strategy.alt.TestElementsAlt [junit] Testsuite: org.apache.commons.betwixt.strategy.alt.TestElementsAlt [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.734 sec [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.734 sec [junit] Testcase: testCapitalizeNameMapper took 0.5 sec [junit] Testcase: testDecapitalizeNameMapper took 0.021 sec [junit] Testcase: testDefaultElementMapper took 0.02 sec [junit] Testcase: testHyphenatedNameMapper took 0.023 sec [junit] Running org.apache.commons.betwixt.xmlunit.TestXmlTestCase [junit] Testsuite: org.apache.commons.betwixt.xmlunit.TestXmlTestCase [junit] Tests run: 10, Failures: 0, Errors: 0, Time elapsed: 0.542 sec [junit] Tests run: 10, Failures: 0, Errors: 0, Time elapsed: 0.542 sec [junit] Testcase: testXMLUnit took 0.067 sec [junit] Testcase: testXMLUnit2 took 0.022 sec [junit] Testcase: testXMLUnit3 took 0.02 sec [junit] Testcase: testXMLUnit4 took 0.027 sec [junit] Testcase: testXMLUnit5 took 0.015 sec [junit] Testcase: testXMLUnit6 took 0.025 sec [junit] Testcase:
DO NOT REPLY [Bug 30637] - BeanUtils.setProperty fails with mapped properties containing several MAPPED_DELIM2 characters
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=30637. 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=30637 [EMAIL PROTECTED] changed: What|Removed |Added Priority||P1 Summary|BenaUtils.setProperty fails |BeanUtils.setProperty fails |with mapped properties that |with mapped properties |contains more than a|containing several |MAPPED_DELIM2 char in it|MAPPED_DELIM2 characters -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27633] - IllegalArgumentException in BeanUtils.copyProperties when property types don't match
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=27633. 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=27633 [EMAIL PROTECTED] changed: What|Removed |Added Priority||P1 Summary|java.lang.IllegalArgumentExc|IllegalArgumentException in |eption in |BeanUtils.copyProperties |BeanUtils.copyProperties|when property types don't |when property types don't |match |match | -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30520] - [beanutils] Better implementation of SqlDateConverter.convert()
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=30520. 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=30520 [EMAIL PROTECTED] changed: What|Removed |Added Priority||P1 Summary|[commons-beanutils]Better |[beanutils] Better |implementation of |implementation of |SqlDateConverter.convert() |SqlDateConverter.convert() -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32009] - IllegalArgumentException: PropertyUtils is describing the wrong class.
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=32009. 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=32009 [EMAIL PROTECTED] changed: What|Removed |Added OS/Version||All Priority||P1 Summary|java.lang.IllegalArgumentExc|IllegalArgumentException: |eption: PropertyUtils is|PropertyUtils is describing |describing the wrong class. |the wrong class. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17002] - Problem with index 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=17002. 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=17002 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED] |commons- ||[EMAIL PROTECTED] Status|REOPENED|NEW OS/Version||All Priority||P1 --- Additional Comments From [EMAIL PROTECTED] 2004-11-15 19:57 --- Reassigning to commons-dev -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31852] - Mapped property inside a mapped property is not populated on submit
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=31852. 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=31852 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED] |commons- ||[EMAIL PROTECTED] Priority||P1 --- Additional Comments From [EMAIL PROTECTED] 2004-11-15 19:59 --- Reassigning to commons-dev -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project commons-jelly-tags-junit (in module jelly-tags) success
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-jelly-tags-junit *no longer* has an issue.
The current state of this project is 'Success'.
Full details are available at:
http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-junit/index.html
That said, some information snippets are provided here.
The following annotations (debug/informational/warning/error messages) were
provided:
-DEBUG- Sole output [commons-jelly-tags-junit-15112004.jar] identifier set to
project name
-INFO- No license on redistributable project with outputs.
The following work was performed:
http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-junit/gump_work/build_jelly-tags_commons-jelly-tags-junit.html
Work Name: build_jelly-tags_commons-jelly-tags-junit (Type: Build)
Work ended in a state of : Success
Elapsed: 4 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
org.apache.tools.ant.Main
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml
-Dbuild.sysclasspath=only -Dfinal.name=commons-jelly-tags-junit-15112004 jar
[Working Directory: /usr/local/gump/public/workspace/jelly-tags/junit]
CLASSPATH:
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jelly-tags/junit/target/classes:/usr/local/gump/public/workspace/jelly-tags/junit/target/test-classes:/usr/local/gump/public/workspace/jakarta-commons/jelly/target/commons-jelly-15112004.jar:/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-15112004.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-15112004.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-15112004.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/packages/dom4j-1.4/dom4j-full.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-15112004.jar:/usr/local/gump/public/workspace/jakarta-commons/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr154/dist/lib/servlet-api.jar:/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152/dist/lib/jsp-api.jar:/usr/local/gump/public/workspace/jakarta-taglibs/dist/standard/lib/standard.jar:/usr/local/gump/public/workspace/jakarta-taglibs/dist/standard/lib/jstl.jar:/usr/local/gump/packages/nekohtml-0.9.3/nekohtmlXni.jar:/usr/local/gump/packages/nekohtml-0.9.3/nekohtml.jar
-
[mkdir] Created dir:
/home/gump/workspaces2/public/workspace/jelly-tags/junit/target/classes
[javac] Compiling 11 source files to
/home/gump/workspaces2/public/workspace/jelly-tags/junit/target/classes
[copy] Copying 2 files to
/home/gump/workspaces2/public/workspace/jelly-tags/junit/target/test-classes
compile-tests:
[javac] Compiling 1 source file to
/home/gump/workspaces2/public/workspace/jelly-tags/junit/target/test-classes
internal-test:
[mkdir] Created dir:
/home/gump/workspaces2/public/workspace/jelly-tags/junit/target/test-reports
[junit] Running org.apache.commons.jelly.tags.junit.TestJUnit
[junit] Testsuite: org.apache.commons.jelly.tags.junit.TestJUnit
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.228 sec
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.228 sec
[junit] - Standard Output ---
[junit]
[junit] The exception was:
file:/home/gump/workspaces2/public/workspace/jelly-tags/junit/target/test-classes/org/apache/commons/jelly/tags/junit/suite.jelly:25:43:
test:assert
file:/home/gump/workspaces2/public/workspace/jelly-tags/junit/target/test-classes/org/apache/commons/jelly/tags/junit/suite.jelly:25:43:
test:assert This should always fail. Assertion failed while evaluating test:
${2 != 2}
[junit]
[junit]
[junit]
[junit] The exception was:
[GUMP@brutus]: Project commons-jelly-tags-swing (in module jelly-tags) success
To whom it may satisfy... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-swing *no longer* has an issue. The current state of this project is 'Success'. Full details are available at: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-swing/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-swing-15112004.jar] identifier set to project name -INFO- No license on redistributable project with outputs. The following work was performed: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-swing/gump_work/build_jelly-tags_commons-jelly-tags-swing.html Work Name: build_jelly-tags_commons-jelly-tags-swing (Type: Build) Work ended in a state of : Success Elapsed: 5 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 org.apache.tools.ant.Main -Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dfinal.name=commons-jelly-tags-swing-15112004 jar [Working Directory: /usr/local/gump/public/workspace/jelly-tags/swing] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jelly-tags/swing/target/classes:/usr/local/gump/public/workspace/jelly-tags/swing/target/test-classes:/usr/local/gump/public/workspace/jakarta-commons/jelly/target/commons-jelly-15112004.jar:/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-15112004.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-15112004.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-15112004.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/packages/dom4j-1.4/dom4j-full.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-15112004.jar:/usr/local/gump/public/workspace/jakarta-commons/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr154/dist/lib/servlet-api.jar:/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152/dist/lib/jsp-api.jar:/usr/local/gump/public/workspace/jakarta-taglibs/dist/standard/lib/standard.jar:/usr/local/gump/public/workspace/jakarta-taglibs/dist/standard/lib/jstl.jar:/usr/local/gump/packages/nekohtml-0.9.3/nekohtmlXni.jar:/usr/local/gump/packages/nekohtml-0.9.3/nekohtml.jar - Buildfile: build.xml init: [mkdir] Created dir: /home/gump/workspaces2/public/workspace/jelly-tags/swing/target/lib get-deps: compile: [mkdir] Created dir: /home/gump/workspaces2/public/workspace/jelly-tags/swing/target/classes [javac] Compiling 35 source files to /home/gump/workspaces2/public/workspace/jelly-tags/swing/target/classes [copy] Copying 10 files to /home/gump/workspaces2/public/workspace/jelly-tags/swing/target/test-classes compile-tests: [javac] Compiling 5 source files to /home/gump/workspaces2/public/workspace/jelly-tags/swing/target/test-classes internal-test: [mkdir] Created dir: /home/gump/workspaces2/public/workspace/jelly-tags/swing/target/test-reports [junit] Running org.apache.commons.jelly.swing.TestConverters [junit] Testsuite: org.apache.commons.jelly.swing.TestConverters [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.147 sec [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.147 sec [junit] Testcase: testDimensions took 0.006 sec [junit] Testcase: testPoints took 0.001 sec [junit] Running org.apache.commons.jelly.swing.TestSwingTags [junit] Testsuite: org.apache.commons.jelly.swing.TestSwingTags [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.228 sec [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.228 sec [junit] Testcase: testBasicComponentFunctions took 0.071 sec [junit] Testcase: testGridBagBasic
DO NOT REPLY [Bug 32015] - [chain] Make CatalogBase.getCommand() thread safe
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=32015. 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=32015 [EMAIL PROTECTED] changed: What|Removed |Added Priority||P1 Summary|[commons-chain] Make|[chain] Make |CatalogBase.getCommand()|CatalogBase.getCommand() |thread safe |thread safe -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project commons-jelly-tags-ant (in module jelly-tags) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-ant has an issue affecting its community integration. This issue affects 5 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-ant : This is a Jelly interface for Ant. - commons-jelly-tags-fmt : This is a set of Jelly i18n tags. - commons-jelly-tags-jsl : The Jelly Stylesheet Library (JSL) - maven : Project Management Tools - maven-bootstrap : Project Management Tools Full details are available at: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-ant/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-ant-15112004.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/jelly-tags/commons-jelly-tags-ant/gump_work/build_jelly-tags_commons-jelly-tags-ant.html Work Name: build_jelly-tags_commons-jelly-tags-ant (Type: Build) Work ended in a state of : Failed Elapsed: 6 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 org.apache.tools.ant.Main -Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dfinal.name=commons-jelly-tags-ant-15112004 jar [Working Directory: /usr/local/gump/public/workspace/jelly-tags/ant] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jelly-tags/ant/target/classes:/usr/local/gump/public/workspace/jelly-tags/ant/target/test-classes:/usr/local/gump/public/workspace/jakarta-commons/jelly/target/commons-jelly-15112004.jar:/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-15112004.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-15112004.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-15112004.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/packages/dom4j-1.4/dom4j-full.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-15112004.jar:/usr/local/gump/public/workspace/jakarta-commons/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr154/dist/lib/servlet-api.jar:/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152/dist/lib/jsp-api.jar:/usr/local/gump/public/workspace/jakarta-taglibs/dist/standard/lib/standard.jar:/usr/local/gump/public/workspace/jakarta-taglibs/dist/standard/lib/jstl.jar:/usr/local/gump/packages/nekohtml-0.9.3/nekohtmlXni.jar:/usr/local/gump/packages/nekohtml-0.9.3/nekohtml.jar:/usr/local/gump/public/workspace/commons-grant/target/commons-grant-15112004.jar:/usr/local/gump/public/workspace/jelly-tags/util/target/commons-jelly-tags-util-15112004.jar:/usr/local/gump/public/workspace/jelly-tags/junit/target/commons-jelly-tags-junit-15112004.jar - [junit] Testcase: readWriteIn took 0.219 sec [junit] Testcase: startUpReadWrite took 0.136 sec [junit] Testcase: copy took 0.142 sec [junit] Caused an ERROR [junit] file:/home/gump/workspaces2/public/workspace/jelly-tags/ant/target/test-classes/org/apache/commons/jelly/ant/suite.jelly:114:80: util:loadText charsetName [junit] org.apache.commons.jelly.JellyTagException: file:/home/gump/workspaces2/public/workspace/jelly-tags/ant/target/test-classes/org/apache/commons/jelly/ant/suite.jelly:114:80: util:loadText charsetName [junit] at org.apache.commons.jelly.impl.TagScript.handleException(TagScript.java:680) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:263) [junit]
[Jakarta Commons Wiki] New: Configuration
Date: 2004-11-15T11:41:11 Editor: EmmanuelBourg [EMAIL PROTECTED] Wiki: Jakarta Commons Wiki Page: Configuration URL: http://wiki.apache.org/jakarta-commons/Configuration no comment New Page: ##language:en = Component Overview = || http://jakarta.apache.org/commons/component/images/component-logo-white.png || [http://jakarta.apache.org/commons/component/ Commons-Configuration] Tools to assist in the reading of configuration/preferences files in various formats.[[BR]] A lot of information is available on the [http://jakarta.apache.org/commons/configuration/ Commons-Configuration website]. If you don't find the information you need you can always contact us using one of the [http://jakarta.apache.org/site/mail2.html#Commons mailing lists]. || = External Resources = ||Do you have a good example, add it here!|| = FAQ = ||Add your questions/answers here.|| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Commons Wiki] Updated: FrontPage
Date: 2004-11-15T11:38:37 Editor: EmmanuelBourg [EMAIL PROTECTED] Wiki: Jakarta Commons Wiki Page: FrontPage URL: http://wiki.apache.org/jakarta-commons/FrontPage no comment Change Log: -- @@ -15,6 +15,7 @@ * [:Betwixt] - Betwixt provides services for mapping !JavaBeans to XML documents, and vice versa. * [:Codec] - Codec contains some general encoding/decoding algorithms. Includes some phonetic encoders, Hex, Base64, and a URL encoder. * [:Collections] - Collections builds upon the Java Collections Framework of List, Set and Map to provide many more implementations, new collections and abstract base classes. + * [:Configuration] - Tools to assist in the reading of configuration/preferences files in various formats * [:DBCP] - DBCP provides database connection pooling services. * [:Digester] - Digester is an XML-to-Java-object mapping utility commonly used for parsing XML configuration files. * [:HttpClient] - !HttpClient provides a framework for working with the client-side of the HTTP protocol. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Validator] Version 1.1.4 (Alpha) Available for Testing
Version 1.1.4 (Alpha) of Commons Validator is now available for download and testing here: http://cvs.apache.org/dist/jakarta/commons/validator/v1.1.4/ This new version has minor changes from Version 1.1.3 and is a maintenance release that adds a few new methods whose absence was preventing all the attributes defined in the Validator DTD from being supported. Details of the changes in this version can be found here: http://jakarta.apache.org/commons/validator/changes-report.html The changes in this version are a pre-requisite to fixing some outstanding bugs in Struts and until there is GA quality version of Validator that Struts can depend on, work on these issues cannot begin. Any help in testing this version would be appreciated and will help to speed up the availability of a new GA quality release of Validator. No difference in behaviour between this new 1.1.4 (alpha) version and Version 1.1.3 should be experienced (well, not until down stream software, such as Struts, is changed to take advantage of the fixes). This version of Commons Validator uses the same DTD as Version 1.1.3 - the only requirement to upgrade is to deploy the new jar. Related Bugzilla reports are here: http://issues.apache.org/bugzilla/show_bug.cgi?id=18169 http://issues.apache.org/bugzilla/show_bug.cgi?id=21760 http://issues.apache.org/bugzilla/show_bug.cgi?id=29452 Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29452] - Field class Msg access mod
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=29452. 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=29452 [EMAIL PROTECTED] changed: What|Removed |Added Priority||P1 --- Additional Comments From [EMAIL PROTECTED] 2004-11-15 20:52 --- Version 1.1.4 (alpha) has just been made available which includes this patch. Any help in testing that version would be appreciated. Available here: http://cvs.apache.org/dist/jakarta/commons/validator/v1.1.4/ Niall -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] (reprise) links to books (and similar resources)
On 12 Nov 2004, at 07:08, Henri Yandell wrote: http://wiki.apache.org/jakarta-commons/JakartaCommonsResources added. looks good :) I'd like to get a breakdown of components and versions that each book cover, but it'll involve a bit of research. Alternatively, I may just define a format and then invite the authors to specify the versions etc themselves :) +1 - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging]: WeakHashtable
hi brian sorry i haven't got back early (didn't seem to stop all weekend). been a bit embarrassed since (after sleeping on the code i last committed) i released that reference queues were a more efficient approach but that i wasn't going to have the time to fix it before anyone noticed ;) i've taken a first pass through your emails and i'll definitely be drafting replies but i'm not sure how much time i'll get tonight (and i might need to sleep on the code...) - robert On 15 Nov 2004, at 04:12, Brian Stansberry wrote: I've attached a patch that adds a couple more tests and fixes a problem found by one of them. New test LogFactoryTest.testHoldsFactories() shows that WeakHashtable does not keep a LogFactory from being gc'ed even if the ClassLoader associated with it is still alive. So, calls to LogFactory.getFactory() result in new factories being created. The patch to WeakHashtable is largely designed to fix that. The patched WeakHashtable holds values in the table until the WeakReference to the associated ClassLoader is removed, even if the classloader itself has been gc'ed. Because of this, the potential amount of garbage left in the table is greater than it was before. The patch partly tries to remedy that by doing a purge before each rehash. The patch also switches the purge mechanism to one that uses a ReferenceQueue. This should be more performant, as it allows the purging process to only deal with items (if any) that definitely need to be removed from the hashtable, rather than iterating through all entries in the map. ReferenceQueue.poll() itself is quite fast, basically consisting of popping off the first element in a linked list. In this patch the way LogFactories are kept from being dropped from the hashtable is not ideal. Basically the keys in the map hold hard references to the LogFactories, keeping the WeakReferences to the LogFactories from being cleared. This approach is a leftover remnant of a failed attempt on my part at getting the hashtable itself to clear unneeded factories without the need for a call to purge(). It would be much cleaner to just have the hashtable hold normal hard references to the LogFactories. I didn't include such a change in this patch as 1) it may have made the patch overly complicated, and 2) I didn't have time ;-) If the powers that be agree that the LogFactories should be held directly by the Hashtable, I would be happy to create another patch. (Also, there's some funky stuff in the test cases where I try to handle OutOfMemoryError. It works on my environment (Eclipse 3.0, Sun JDK 1.4.2_03), but if others have thoughts about this, they would be much appreciated). Best, Brian --- Brian Stansberry [EMAIL PROTECTED] wrote: --- robert burrell donkin wrote: On 11 Nov 2004, at 07:40, Brian Stansberry wrote: A couple things occurred to me as I looked. 1) The instances of Referenced are not cleared from the underlying table if their underlying references are cleared. 2) Passing null keys/values to put() does not result in a NPE. One thought on #1 is to make Referenced a subclass of WeakReference instead of a wrapper. You can then keep a ReferenceQueue and poll it to remove cleared references from the hashtable whenever get() is called. This is similar to what WeakHashMap does. i had a bit of a think about the best way to do this. i think the approach outlined would be best if this were a general implementation. in this case, though, the majority of calls are going to be to get with somewhat less going to put and very few to any others. i can't think of any occasions when the symantics of put and get are influenced by the presence of extra entries. so i've opted for code that simply purges entries that have lost their referants which is called at the start of other interrogative methods. the data returned will be more stale than using a reference queue but i think that liveliness for put and get should be improved. Yep, slowing down the critical get() just to sweep up some dust in the corners makes no sense. i'd be grateful if people would take a look at the code and try to find any holes in this approach or reasons why using a ReferenceQueue might improve liveliness (preferably with patches)... I was thinking about this and concluded that the approach of iterating the Hashtable.entrySet() would be faster since you're checking if either the key or the value has been cleared. Using a ReferenceQueue for values would force you to use a reverse lookup map, which seems inefficient. But then I thought, wait, should the values be held in WeakReferences? In a typical case where the application just calls LogFactory.getLog(), won't the only reference to the LogFactory instance be the value in the map? In this case a lot of calls to getLog() will end up going through the getFactory() discovery mechanism as the GC keeps clearing the values from the hashtable. Brian __ Do you Yahoo!? Check out the new
[Jakarta Commons Wiki] Updated: JakartaCommonsResources
Date: 2004-11-15T12:51:47 Editor: TorstenCurdt [EMAIL PROTECTED] Wiki: Jakarta Commons Wiki Page: JakartaCommonsResources URL: http://wiki.apache.org/jakarta-commons/JakartaCommonsResources no comment Change Log: -- @@ -4,11 +4,12 @@ A very useful summary of articles and resources available for Jakarta Commons may be found at [http://www.java201.com/resources/browse/70-all.html Java201]. == Books == -There are currently 5 known books on Jakarta Commons. In order of publication: +There are currently 6 known books on Jakarta Commons. In order of publication: * [http://www.charlesriver.com/titles/apachejakarta.html Applied Software Engineering Using Apache Jakarta Commons] by Christian Gross (2003-11), Charles River Media. * [http://apress.com/book/bookDisplay.html?bID=246 Pro Jakarta Commons] by Harshad Oak (2004-03), Apress. * [http://www.oreilly.com/catalog/jakartackbk/ Jakarta Commons Cookbook] by Tim O'Brien (2004-11 est), O'Reilly. + * [http://www.software-support.biz/sus/sus_buch/psecom,id,63,nodeid,8,_language,de.html Jakarta Commons] by Torsten Curdt, Stefan Edlich, Henrik Hörning, Reidar Hörning, Software Support Verlag, in German * [http://www.sourcebeat.com/TitleAction.do?id=4 Jakarta Commons Live] by Jonathan Lehr (coming soon), SourceBeat. * [http://www.manning.com Jakarta Commons in Action] by Vikram Goyal (coming soon), Manning. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[email] ByteArrayDataSource
Hi, I noticted that the ByteArrayDataSource class was removed from commons-email. I found it to be a useful addition to commons-email...has it moved to a different commons project? The Turbine javadoc for this class says that org.apache.turbine.util.mail.ByteArrayDataSource is deprecated and that org.apache.commons.mail.ByteArrayDataSource should be used instead. Is it possible that the class remained deprecated when moved from Turbine to commons-email, and that its removal was accidental? Thanks, Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote Email to Commons Proper
On 15 Nov 2004, at 11:10, Eric Pugh wrote: snip (2) DEPENDENCIES The Email component is dependent upon the following external components for development and use: snip * Dumbster Fake SMTP (Version 1.0.3 or later) - for unit tests only, not required for deployment i hate to do this to what is a good proposal but... isn't dumbster LGPL'd...? BaseEmailTestCase imports LGPL'd code and IIRC that's still problematic. (FSF refuse to clarify the situation with regard to java.) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging]: WeakHashtable
--- robert burrell donkin [EMAIL PROTECTED] wrote: hi brian sorry i haven't got back early (didn't seem to stop all weekend). No worries. It's good to have a real life :) i've taken a first pass through your emails and i'll definitely be drafting replies but i'm not sure how much time i'll get tonight (and i might need to sleep on the code...) Sounds good. Sleep is good Also, one thought in the back of my mind is that a ReferenceQueue also makes it easy to do cleanup in small doses. E.g. every X number of calls to put() or something, pop one key off the queue and remove it. - brian __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote Transaction to Commons Proper
+1 This project looks well maintained. It would be good to state the minimum Java version required on the home page. David --- Oliver Zeigermann [EMAIL PROTECTED] wrote: Folks, as described in previous posts and inspired by the fine proposal for email promotion I would like to see the transaction component http://jakarta.apache.org/commons/sandbox/transaction/ promoted to commons proper. The initial committers would be Stefan Lützkendorf, James Mason, Daniel Florey and me. AFAIK none of us is a committer in commons proper so the promotion would include making as committers there. We all are Jakarta Slide committers and this is where the component came from. We factored out code for a transactional file system, transactional maps (implementing Map interface) with different ACID strategies, general purpose locks and a few more helper classes. Junit tests exist for all parts and succeed: http://jakarta.apache.org/commons/sandbox/transaction/junit-report.html Javadoc is pretty complete http://jakarta.apache.org/commons/sandbox/transaction/apidocs/index.html and general documentation and even a short tutorial for locks exist: http://jakarta.apache.org/commons/sandbox/transaction/locks/tutorial.html The transaction component is stable enough to be released as a 1.0 soon after promotion and would initially be maintained by the committers of the Slide community. Once promoted growth is anticipated as even in the sandbox it attracted some attention. As I am not a commons committer, I have no binding vote, but my non-binding vote of course is +1. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote Email to Commons Proper
i hate to do this to what is a good proposal but... isn't dumbster LGPL'd...? No. It's GPL. Which only makes it worse, right? http://sourceforge.net/projects/dumbster Dang viral licenses. And all the work that has been put into implementing Dumbster test cases! MockObjects is Apache-licensed, but the whole alt.javax.mail interface hierarchy has always kind of chafed me. Is it worth looking at it? Only javax.mail.Session is exposed in the current API at all, and that's only in a protected method. Maybe it wouldn't be as bad as it seems. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote Email to Commons Proper
A little bit of a digression but I'm reading through the LGPL blurb.. Can you give a bit more detail on this problem? Just as a matter or curiosity. Mark On Mon, 15 Nov 2004 21:00:16 +, robert burrell donkin [EMAIL PROTECTED] wrote: On 15 Nov 2004, at 11:10, Eric Pugh wrote: snip (2) DEENDENCIES The Email component is dependent upon the following external components for development and use: snip * Dumbster Fake SMTP (Version 1.0.3 or later) - for unit tests only, not required for deployment i hate to do this to what is a good proposal but... isn't dumbster LGPL'd...? BaseEmailTestCase imports LGPL'd code and IIRC that's still problematic. (FSF refuse to clarify the situation with regard to java.) - robert - 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: [VOTE] Promote Email to Commons Proper
Damn, I need to Wiki this :) Basically, LGPL is a license written for the C programming language. While we all agree that its intent is to allow people to freely use the library, its wording means that the actual application to a language other than C is up for debate. A lot of this comes down to whether the term 'linking' means 'import' in Java or not. Early vs Late linking languages etc. Anyways, legal advice given to the ASF is not to be tied to an LGPL license as the LGPL is feasibly as viral as GPL. This isn't just some not-invented-here view the ASF have. Lawrence Rosen's latest book on open-source licensing seems to repeat the view. This means we cannot have LGPL'd jars in the CVS repository, that we cannot modify previously LGPL'd code and that we cannot import LGPL'd code in our import statements. The same applies for GPL (to answer Joe's question that yes, GPL is worse). I'm hoping that as the months go by next year we'll be able to import LGPL'd code in our code. GPL will still be out of the question, as would LGPL in CVS or modifying LGPL; but use of JFreeCharts, Hibernate and other libraries would be possible. So, yep. Dumbster's license seems to be a problem. One path is to explain this to the author and ask if they can dual-license it under something like BSD or ASL 2.0. Hen On Mon, 15 Nov 2004 23:04:11 +0100, Mark Lowe [EMAIL PROTECTED] wrote: A little bit of a digression but I'm reading through the LGPL blurb.. Can you give a bit more detail on this problem? Just as a matter or curiosity. Mark On Mon, 15 Nov 2004 21:00:16 +, robert burrell donkin [EMAIL PROTECTED] wrote: On 15 Nov 2004, at 11:10, Eric Pugh wrote: snip (2) DEENDENCIES The Email component is dependent upon the following external components for development and use: snip * Dumbster Fake SMTP (Version 1.0.3 or later) - for unit tests only, not required for deployment i hate to do this to what is a good proposal but... isn't dumbster LGPL'd...? BaseEmailTestCase imports LGPL'd code and IIRC that's still problematic. (FSF refuse to clarify the situation with regard to java.) - robert - 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: [VOTE] Promote Email to Commons Proper
On 15 Nov 2004, at 22:04, Mark Lowe wrote: A little bit of a digression but I'm reading through the LGPL blurb.. Can you give a bit more detail on this problem? Just as a matter or curiosity. IANAL but here's my understanding of the apache concerns: the LGPL is strongly tied to C and C++ by the technical terms it uses. how these terms will be interpreted by the courts when used in java (or other similar languages) is uncertain to say the least. one perfectly reasonable reading is that (for java) the terms of the LGPL and the GPL are identical. the ASF has (over the years) made many approaches to the FSF asking them to address this issue but without success. therefore, until such time that either the courts or the FSF provide the necessary legal clarification, the ASF cannot allow such imports. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/transaction build.properties.sample
ozeigermann2004/11/15 14:19:10 Modified:transaction build.properties.sample Log: Changed to ASCII Revision ChangesPath 1.3 +19 -18 jakarta-commons-sandbox/transaction/build.properties.sample Index: build.properties.sample === RCS file: /home/cvs/jakarta-commons-sandbox/transaction/build.properties.sample,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- build.properties.sample 2 Jun 2004 11:24:57 - 1.2 +++ build.properties.sample 15 Nov 2004 22:19:10 - 1.3 @@ -1,18 +1,19 @@ -# -# build properties sample, move to build.properties and adapt to your settings -# - -# compile options - -compile.debug=on -compile.deprecation=on -compile.optimize=on - -# jars (set to have the spec from somewhere else) -#j2ee.jar=E:/lib/jboss-j2ee.jar -#servlet.jar=E:/lib/servlet.jar - -# deploy dirs - -jboss.deploy.dir=E:/Programme/jboss-3.2.3/server/default/deploy - +# +# build properties sample, move to build.properties and adapt to your settings +# + +# compile options + +compile.target=1.3 +compile.debug=on +compile.deprecation=on +compile.optimize=on + +# jars (set to have the spec from somewhere else) +#j2ee.jar=E:/lib/jboss-j2ee.jar +#servlet.jar=E:/lib/servlet.jar + +# deploy dirs + +jboss.deploy.dir=E:/Programme/jboss-3.2.3/server/default/deploy + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/transaction build.xml
ozeigermann2004/11/15 14:19:38
Modified:transaction build.xml
Log:
Made compile target adjustable and set to 1.3 as default
Revision ChangesPath
1.8 +5 -0 jakarta-commons-sandbox/transaction/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-commons-sandbox/transaction/build.xml,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- build.xml 31 Oct 2004 10:44:02 - 1.7
+++ build.xml 15 Nov 2004 22:19:37 - 1.8
@@ -15,6 +15,7 @@
property file=${basedir}/build.properties/
+ property name=compile.target value=1.3 /
property name=compile.debug value=true /
property name=compile.deprecation value=true /
property name=compile.optimize value=true /
@@ -150,6 +151,7 @@
target name=build depends=prepare
javac destdir=${build.classes}
+ target=${compile.target}
debug=${compile.debug}
deprecation=${compile.deprecation}
optimize=${compile.optimize}
@@ -161,6 +163,7 @@
target name=build-test depends=build
javac destdir=${build.classes}
+ target=${compile.target}
debug=${compile.debug}
deprecation=${compile.deprecation}
optimize=${compile.optimize}
@@ -171,6 +174,7 @@
target name=build-jca depends=build if=j2ee.present
javac destdir=${build.classes}
+ target=${compile.target}
debug=${compile.debug}
deprecation=${compile.deprecation}
optimize=${compile.optimize}
@@ -182,6 +186,7 @@
target name=build-map-example depends=build-jca if=servlet.present
javac destdir=${build.classes}
+ target=${compile.target}
debug=${compile.debug}
deprecation=${compile.deprecation}
optimize=${compile.optimize}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote Email to Commons Proper
http://wiki.apache.org/jakarta/Using_20LGPL_27d_20code On Mon, 15 Nov 2004 17:16:35 -0500, Henri Yandell [EMAIL PROTECTED] wrote: Damn, I need to Wiki this :) Basically, LGPL is a license written for the C programming language. While we all agree that its intent is to allow people to freely use the library, its wording means that the actual application to a language other than C is up for debate. A lot of this comes down to whether the term 'linking' means 'import' in Java or not. Early vs Late linking languages etc. Anyways, legal advice given to the ASF is not to be tied to an LGPL license as the LGPL is feasibly as viral as GPL. This isn't just some not-invented-here view the ASF have. Lawrence Rosen's latest book on open-source licensing seems to repeat the view. This means we cannot have LGPL'd jars in the CVS repository, that we cannot modify previously LGPL'd code and that we cannot import LGPL'd code in our import statements. The same applies for GPL (to answer Joe's question that yes, GPL is worse). I'm hoping that as the months go by next year we'll be able to import LGPL'd code in our code. GPL will still be out of the question, as would LGPL in CVS or modifying LGPL; but use of JFreeCharts, Hibernate and other libraries would be possible. So, yep. Dumbster's license seems to be a problem. One path is to explain this to the author and ask if they can dual-license it under something like BSD or ASL 2.0. Hen On Mon, 15 Nov 2004 23:04:11 +0100, Mark Lowe [EMAIL PROTECTED] wrote: A little bit of a digression but I'm reading through the LGPL blurb.. Can you give a bit more detail on this problem? Just as a matter or curiosity. Mark On Mon, 15 Nov 2004 21:00:16 +, robert burrell donkin [EMAIL PROTECTED] wrote: On 15 Nov 2004, at 11:10, Eric Pugh wrote: snip (2) DEENDENCIES The Email component is dependent upon the following external components for development and use: snip * Dumbster Fake SMTP (Version 1.0.3 or later) - for unit tests only, not required for deployment i hate to do this to what is a good proposal but... isn't dumbster LGPL'd...? BaseEmailTestCase imports LGPL'd code and IIRC that's still problematic. (FSF refuse to clarify the situation with regard to java.) - robert - 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: [VOTE] Promote Email to Commons Proper
On 15 Nov 2004, at 21:48, Joe Germuska wrote: i hate to do this to what is a good proposal but... isn't dumbster LGPL'd...? No. It's GPL. Which only makes it worse, right? just as bad :) however, what's worse is that the licensing seems pretty confused: http://quintanasoft.com/dumbster/. darn :( http://sourceforge.net/projects/dumbster Dang viral licenses. And all the work that has been put into implementing Dumbster test cases! since the source isn't effected (only the tests), one approach might be to offshore the integration tests with an appropriate license. alternatively, if this is a one-developer project then we could ask him if he'd be willing to release the code under an alternative license. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/transaction/xdocs index.xml
ozeigermann2004/11/15 14:25:15 Modified:transaction/xdocs index.xml Log: Added info for minimum required JDK Revision ChangesPath 1.5 +2 -1 jakarta-commons-sandbox/transaction/xdocs/index.xml Index: index.xml === RCS file: /home/cvs/jakarta-commons-sandbox/transaction/xdocs/index.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- index.xml 1 Nov 2004 18:25:51 - 1.4 +++ index.xml 15 Nov 2004 22:25:15 - 1.5 @@ -12,7 +12,8 @@ section name=The Transaction Component p Provides a set of utility classes for transactional data structures, -locks, and a transactional file system. +locks, and a transactional file system. Because it relies on the Map +interface it requires at least JDK1.2. /p p - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging]: WeakHashtable
On 15 Nov 2004, at 21:33, Brian Stansberry wrote: --- robert burrell donkin [EMAIL PROTECTED] wrote: hi brian sorry i haven't got back early (didn't seem to stop all weekend). No worries. It's good to have a real life :) i'm not so sure sometimes... i've taken a first pass through your emails and i'll definitely be drafting replies but i'm not sure how much time i'll get tonight (and i might need to sleep on the code...) Sounds good. Sleep is good i do all my best thinking in my sleep :) Also, one thought in the back of my mind is that a ReferenceQueue also makes it easy to do cleanup in small doses. E.g. every X number of calls to put() or something, pop one key off the queue and remove it. yep :) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote Email to Commons Proper
I don't think the dumbster jars are in CVS. But assuming that linking and importing are synominous then i guess things would be foiled on that front. I've sent dumbster man jason a mail explaining the problem. Mark On Mon, 15 Nov 2004 17:16:35 -0500, Henri Yandell [EMAIL PROTECTED] wrote: Damn, I need to Wiki this :) Basically, LGPL is a license written for the C programming language. While we all agree that its intent is to allow people to freely use the library, its wording means that the actual application to a language other than C is up for debate. A lot of this comes down to whether the term 'linking' means 'import' in Java or not. Early vs Late linking languages etc. Anyways, legal advice given to the ASF is not to be tied to an LGPL license as the LGPL is feasibly as viral as GPL. This isn't just some not-invented-here view the ASF have. Lawrence Rosen's latest book on open-source licensing seems to repeat the view. This means we cannot have LGPL'd jars in the CVS repository, that we cannot modify previously LGPL'd code and that we cannot import LGPL'd code in our import statements. The same applies for GPL (to answer Joe's question that yes, GPL is worse). I'm hoping that as the months go by next year we'll be able to import LGPL'd code in our code. GPL will still be out of the question, as would LGPL in CVS or modifying LGPL; but use of JFreeCharts, Hibernate and other libraries would be possible. So, yep. Dumbster's license seems to be a problem. One path is to explain this to the author and ask if they can dual-license it under something like BSD or ASL 2.0. Hen On Mon, 15 Nov 2004 23:04:11 +0100, Mark Lowe [EMAIL PROTECTED] wrote: A little bit of a digression but I'm reading through the LGPL blurb.. Can you give a bit more detail on this problem? Just as a matter or curiosity. Mark On Mon, 15 Nov 2004 21:00:16 +, robert burrell donkin [EMAIL PROTECTED] wrote: On 15 Nov 2004, at 11:10, Eric Pugh wrote: snip (2) DEENDENCIES The Email component is dependent upon the following external components for development and use: snip * Dumbster Fake SMTP (Version 1.0.3 or later) - for unit tests only, not required for deployment i hate to do this to what is a good proposal but... isn't dumbster LGPL'd...? BaseEmailTestCase imports LGPL'd code and IIRC that's still problematic. (FSF refuse to clarify the situation with regard to java.) - robert - 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: [VOTE] Promote Email to Commons Proper
Joe Germuska wrote: i hate to do this to what is a good proposal but... isn't dumbster LGPL'd...? No. It's GPL. Which only makes it worse, right? http://sourceforge.net/projects/dumbster Dang viral licenses. And all the work that has been put into implementing Dumbster test cases! MockObjects is Apache-licensed, but the whole alt.javax.mail interface hierarchy has always kind of chafed me. Is it worth looking at it? Only javax.mail.Session is exposed in the current API at all, and that's only in a protected method. Maybe it wouldn't be as bad as it seems. Joe Actually it seems that it is LGPL starting with version 1.1. At least that's what the docs accompanying version 1.4 says. http://quintanasoft.com/dumbster/ -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote Email to Commons Proper
I had a read of the LGPL, a lawyer but linking is mentioned. When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library.. Now just find out what they mean by criteria of freedom. On Mon, 15 Nov 2004 23:35:24 +0100, Dennis Lundberg [EMAIL PROTECTED] wrote: Joe Germuska wrote: i hate to do this to what is a good proposal but... isn't dumbster LGPL'd...? No. It's GPL. Which only makes it worse, right? http://sourceforge.net/projects/dumbster Dang viral licenses. And all the work that has been put into implementing Dumbster test cases! MockObjects is Apache-licensed, but the whole alt.javax.mail interface hierarchy has always kind of chafed me. Is it worth looking at it? Only javax.mail.Session is exposed in the current API at all, and that's only in a protected method. Maybe it wouldn't be as bad as it seems. Joe Actually it seems that it is LGPL starting with version 1.1. At least that's what the docs accompanying version 1.4 says. http://quintanasoft.com/dumbster/ -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: logging: WeakHashtable
On 12 Nov 2004, at 06:55, Brian Stansberry wrote: But then I thought, wait, should the values be held in WeakReferences? In a typical case where the application just calls LogFactory.getLog(), won't the only reference to the LogFactory instance be the value in the map? In this case a lot of calls to getLog() will end up going through the getFactory() discovery mechanism as the GC keeps clearing the values from the hashtable. this is actually quite a big issue. the reason why i made the LogFactory references weakly held was that there's a strong reference from any object to it's classloader (via getClass().getClassloader(). (unless there's some special mojo for this case which i'm unaware of) i'd say that whilst the LogFactory is hard referenced, so is it's classloader. (i should probably create a test to prove this reasoning.) but you're absolutely right that using a weak reference to hold the LogFactory may well result in poor performance. i've tried to think my way around this one, by thinking of possible ways of reference the two but (so far) i haven't come up with one. the only alternative approaches i've come up with so way are more than a little ugly, using counters (timers or something) so that references to values are weakened periodically. anyone have any better ideas? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote Email to Commons Proper
BTW lawrence rosen's 'open source licensing' is a good book (if you're interested in this kind of thing) also (aimed mainly at committers this comment, i suppose) the ASF have a list or two dedicated to licensing issues - robert On 15 Nov 2004, at 22:51, Mark Lowe wrote: I had a read of the LGPL, a lawyer but linking is mentioned. When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library.. Now just find out what they mean by criteria of freedom. On Mon, 15 Nov 2004 23:35:24 +0100, Dennis Lundberg [EMAIL PROTECTED] wrote: Joe Germuska wrote: i hate to do this to what is a good proposal but... isn't dumbster LGPL'd...? No. It's GPL. Which only makes it worse, right? http://sourceforge.net/projects/dumbster Dang viral licenses. And all the work that has been put into implementing Dumbster test cases! MockObjects is Apache-licensed, but the whole alt.javax.mail interface hierarchy has always kind of chafed me. Is it worth looking at it? Only javax.mail.Session is exposed in the current API at all, and that's only in a protected method. Maybe it wouldn't be as bad as it seems. Joe Actually it seems that it is LGPL starting with version 1.1. At least that's what the docs accompanying version 1.4 says. http://quintanasoft.com/dumbster/ -- Dennis Lundberg - 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: [email] ByteArrayDataSource
Hi, I use it to attach dynamically generated content (which often ends up as a byte[]) to an email. The attach() methods in MultipartEmail and the EmailAttachment class want either a File, URL, or DataSource. The ByteArrayDataSource class saves someone the time of implementing their own DataSource for this purpose. Of course, an attach() method that accepts a byte[] would work well also. Scott Eric Pugh wrote: That is quite possible! Can you explain the use case for ByteArrayDataSource? It seemed like a terrible hack, but maybe it was a terribly cool idea? -Original Message- From: Scott [mailto:[EMAIL PROTECTED] Sent: Monday, November 15, 2004 8:58 PM To: Commons-Dev Subject: [email] ByteArrayDataSource Hi, I noticted that the ByteArrayDataSource class was removed from commons-email. I found it to be a useful addition to commons-email...has it moved to a different commons project? The Turbine javadoc for this class says that org.apache.turbine.util.mail.ByteArrayDataSource is deprecated and that org.apache.commons.mail.ByteArrayDataSource should be used instead. Is it possible that the class remained deprecated when moved from Turbine to commons-email, and that its removal was accidental? Thanks, Scott - 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: [VOTE] Promote Email to Commons Proper
And LGPL ruins Eric's day.. Again.. When will Eric learn? He promises that this is the last time he'll look at a library without verifying the license first. So, enough with the third person. I wouldn't be surprised in the author picked LGPL because it look like a good middle of the road license. It does to me as well. Can you give me more details on what dual use means in the Apache friendly we can use it in email way? I did some searchs and found quite a few rather painful bits of information [1],[2], but nothing specific on what exactly dual licensing entails? And, which licenses can be dual licensed. This [3] article seemed to suggest that SpamAssassin was both ASL and LGPL at the same time? I am willing to approach Jason Kitche, the developer of Dumbster about either dual licensing or maybe granting us some sort of special license, but would like to have my facts in a row. Eric [1] http://www.apache.org/licenses/GPL-compatibility.html [2] http://www.dwheeler.com/essays/gpl-compatible.html [3] http://builder.com.com/5100-6372_14-5378447.html -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Monday, November 15, 2004 10:17 PM To: Jakarta Commons Developers List; Mark Lowe Subject: Re: [VOTE] Promote Email to Commons Proper Damn, I need to Wiki this :) Basically, LGPL is a license written for the C programming language. While we all agree that its intent is to allow people to freely use the library, its wording means that the actual application to a language other than C is up for debate. A lot of this comes down to whether the term 'linking' means 'import' in Java or not. Early vs Late linking languages etc. Anyways, legal advice given to the ASF is not to be tied to an LGPL license as the LGPL is feasibly as viral as GPL. This isn't just some not-invented-here view the ASF have. Lawrence Rosen's latest book on open-source licensing seems to repeat the view. This means we cannot have LGPL'd jars in the CVS repository, that we cannot modify previously LGPL'd code and that we cannot import LGPL'd code in our import statements. The same applies for GPL (to answer Joe's question that yes, GPL is worse). I'm hoping that as the months go by next year we'll be able to import LGPL'd code in our code. GPL will still be out of the question, as would LGPL in CVS or modifying LGPL; but use of JFreeCharts, Hibernate and other libraries would be possible. So, yep. Dumbster's license seems to be a problem. One path is to explain this to the author and ask if they can dual-license it under something like BSD or ASL 2.0. Hen On Mon, 15 Nov 2004 23:04:11 +0100, Mark Lowe [EMAIL PROTECTED] wrote: A little bit of a digression but I'm reading through the LGPL blurb.. Can you give a bit more detail on this problem? Just as a matter or curiosity. Mark On Mon, 15 Nov 2004 21:00:16 +, robert burrell donkin [EMAIL PROTECTED] wrote: On 15 Nov 2004, at 11:10, Eric Pugh wrote: snip (2) DEENDENCIES The Email component is dependent upon the following external components for development and use: snip * Dumbster Fake SMTP (Version 1.0.3 or later) - for unit tests only, not required for deployment i hate to do this to what is a good proposal but... isn't dumbster LGPL'd...? BaseEmailTestCase imports LGPL'd code and IIRC that's still problematic. (FSF refuse to clarify the situation with regard to java.) - robert - 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: logging: WeakHashtable
--- robert burrell donkin [EMAIL PROTECTED] wrote: On 12 Nov 2004, at 06:55, Brian Stansberry wrote: But then I thought, wait, should the values be held in WeakReferences? In a typical case where the application just calls LogFactory.getLog(), won't the only reference to the LogFactory instance be the value in the map? In this case a lot of calls to getLog() will end up going through the getFactory() discovery mechanism as the GC keeps clearing the values from the hashtable. this is actually quite a big issue. the reason why i made the LogFactory references weakly held was that there's a strong reference from any object to it's classloader (via getClass().getClassloader(). (unless there's some special mojo for this case which i'm unaware of) i'd say that whilst the LogFactory is hard referenced, so is it's classloader. (i should probably create a test to prove this reasoning.) Interesting. The LogFactoryTest.testReleaseFactories() test inadvertently shows a classloader is released. However, in the test, LogFactoryImpl was not loaded by the classloader that creates the map key. I can play with this tonight to see what happens if I change that. but you're absolutely right that using a weak reference to hold the LogFactory may well result in poor performance. i've tried to think my way around this one, by thinking of possible ways of reference the two but (so far) i haven't come up with one. the only alternative approaches i've come up with so way are more than a little ugly, using counters (timers or something) so that references to values are weakened periodically. anyone have any better ideas? I'm at work at the moment, so can't think too much ;-) Would getClass().getClassloader() return the Thread contextClassLoader that was in effect when getFactory() was first called, or a parent classloader if the parent was the one that actually loaded the class? E.g. a situation where a web app classloader first calls getFactory(), but because commons-logging.jar is on the server classpath it is actually loaded by a server classloader. I can test this tonight as well. - brian __ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [email] ByteArrayDataSource
It seems like byte[] would be simpler right? Save a layer of translation? Of course, that might just move the translation inwards.. Please file a bug so we don't forget about this... Eric -Original Message- From: Scott [mailto:[EMAIL PROTECTED] Sent: Monday, November 15, 2004 11:17 PM To: Jakarta Commons Developers List Subject: Re: [email] ByteArrayDataSource Hi, I use it to attach dynamically generated content (which often ends up as a byte[]) to an email. The attach() methods in MultipartEmail and the EmailAttachment class want either a File, URL, or DataSource. The ByteArrayDataSource class saves someone the time of implementing their own DataSource for this purpose. Of course, an attach() method that accepts a byte[] would work well also. Scott Eric Pugh wrote: That is quite possible! Can you explain the use case for ByteArrayDataSource? It seemed like a terrible hack, but maybe it was a terribly cool idea? -Original Message- From: Scott [mailto:[EMAIL PROTECTED] Sent: Monday, November 15, 2004 8:58 PM To: Commons-Dev Subject: [email] ByteArrayDataSource Hi, I noticted that the ByteArrayDataSource class was removed from commons-email. I found it to be a useful addition to commons-email...has it moved to a different commons project? The Turbine javadoc for this class says that org.apache.turbine.util.mail.ByteArrayDataSource is deprecated and that org.apache.commons.mail.ByteArrayDataSource should be used instead. Is it possible that the class remained deprecated when moved from Turbine to commons-email, and that its removal was accidental? Thanks, Scott - 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 32260] New: - [email] byte array attachments
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=32260. 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=32260 Summary: [email] byte array attachments Product: Commons Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Sandbox AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] With the removal of the ByteArrayDataSource class, there is no easy method for attaching dynamically generated content to an email. The attach() methods in MultipartEmail and the EmailAttachment class want either a File, URL, or DataSource. We should add the ability to easily attach byte[] attachments so that users are not required to implement their own DataSource. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote Transaction to Commons Proper
I'm +1 on the promotion. On Mon, 15 Nov 2004 18:43:10 +0100, Oliver Zeigermann [EMAIL PROTECTED] wrote: Folks, as described in previous posts and inspired by the fine proposal for email promotion I would like to see the transaction component http://jakarta.apache.org/commons/sandbox/transaction/ promoted to commons proper. The initial committers would be Stefan Lützkendorf, James Mason, Daniel Florey and me. AFAIK none of us is a committer in commons proper so the promotion would include making as committers there. We all are Jakarta Slide committers and this is where the component came from. We factored out code for a transactional file system, transactional maps (implementing Map interface) with different ACID strategies, general purpose locks and a few more helper classes. Junit tests exist for all parts and succeed: http://jakarta.apache.org/commons/sandbox/transaction/junit-report.html Javadoc is pretty complete http://jakarta.apache.org/commons/sandbox/transaction/apidocs/index.html and general documentation and even a short tutorial for locks exist: http://jakarta.apache.org/commons/sandbox/transaction/locks/tutorial.html The transaction component is stable enough to be released as a 1.0 soon after promotion and would initially be maintained by the committers of the Slide community. Once promoted growth is anticipated as even in the sandbox it attracted some attention. As I am not a commons committer, I have no binding vote, but my non-binding vote of course is +1. Oliver - 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]
Re: [VOTE] Promote Email to Commons Proper
On Tue, 16 Nov 2004 00:15:07 +0100, Emmanuel Bourg [EMAIL PROTECTED] wrote: robert burrell donkin wrote: until such time that either the courts or the FSF provide the necessary legal clarification, the ASF cannot allow such imports. Another solution mentioned in a previous thread is to write an addentum clarifying the uncertaincy of the LGPL for Java projects, have the ASF lawyers validate it and ask the authors of the LGPL components we'd like to use to add it to their licence. This is in the process by the way. Sam and Geir are our real champions on this, I figure my job is to nudge them from time to time. In the last board minutes, the board seemed to agree that this seemed reasonable and all seemed very positive about being able to use LGPL imports, though not .jars in our CVS or modifying LGPL code. I'm being a humble padowan, but I'll hassle them again in a few weeks to see if things are still moving. I assume they need to get this to the lawyers and get some agreement. So, there's hope, at the end of a still far away tunnel. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: logging: WeakHashtable
OK, been playing with different classloading
configurations to see if the loader gets stuck in map.
Good new/bad news.
1) As you'd expect,
LogFactoryTest.testReleaseFactories() will definitely
work because the dummy classloader I use in the call
to getFactory() was not the contextClassLoader when
LogFactoryImpl was first loaded. Duh.
2) Fixed that by ensuring that a trivial test
classloader was the thread context loader when
LogFactoryImpl was first loaded. TestClassLoader is
as follows:
private static final Class TestClassLoader
extends ClassLoader {
private TestClassLoader(ClassLoader parent) {
super(parent);
}
}
Again, the test passes. This is because the
TestClassLoader delegates to its parent, so the
LogFactory holds a reference to the parent, not the
child. Good news. I expect this would be a typical
situation with things like EJB classloaders and all
others that follow the Java2 delegation model.
3) Beefed up TestClassLoader by overriding loadClass()
so it was able to load LogFactoryImpl itself and
wouldn't delegate to its parent. This simulates a web
app situation, where the web app classloader ignores
normal Java2 classloading and may find its own copy of
commons-logging in WEB-INF/lib. Bad news. As you
expected, the test fails because the test classloader
is kept in the map by the hard reference from
LogFactoryImpl.
So, it seems like a hard reference in the map to a
LogFactory is mostly a problem for webapps that
include commons-logging in WEB-INF when it is already
available on the server classpath. Bad practice in
general to do this, but people do the darnedest
things. I know Tomcat and the embedded Tomcat in
JBoss both guard against this problem by calling
LogFactory.release() when they undeploy webapps.
Don't know about other webservers.
(BTW, the problem with JBoss that led to Bug 31286 is
related to EJB deployments. commons-logging is on the
JBoss server classpath (specifically in the
UnifiedClassLoaderRepository) due to its use in
embedded Tomcat, so the classloader situation should
be analogous to #2 above. JBoss doesn't call
LogFactory.release() when undeploying EJBs, because if
embedded Tomcat is not deployed they can't be sure
LogFactory will be available).
- brian
__
Do you Yahoo!?
Meet the all-new My Yahoo! - Try it today!
http://my.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote Email to Commons Proper
So back to the original problem. Dumbster is currently used by the tests. The way I see it this leaves us with a few options: 1) Remove it (and wait for the ok or change of license 2) Replace it (I havent seen an alternative, but I am willing to look) 3) Do it ourselves. To be honest, my main motivation is just to get Email promoted and moving. That said, after using dumbster for a while I have found it to be a good idea, although I find the implementation to be quite limited. As it also seems to be a one man show, the likelihood of it progressing to far, is low. For this reason, I would like to test the water a suggest, what does everything think about doing a similar component and putting it the sandbox? For my mind, this would help us immensely, we could shape the component so that is was more agreeable to what we are trying to test and ensure that a user was able to retrieve a decent amount of info from the 'sent' mails, as this is a lacking at the moment. I am willing to work on this, but I will need someone to help me champion it and CVS committer. -Corey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
