[email] apple mail
Has anyone come any issues displaying content type related mails with apple's mail client? Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Validator inside of Email.java (RE: [email] Dumbster failing)
Hi Eric, I just update my email sources. and looked abit on the patches you are submitting. Cool to have some unittest. Btw. I saw that EmailValidator of Commons Validator is used inside of Email.java; Does it realy make sence to validate an e-mail inside that class? shouldn't this work be done outside? eg. enter e-mail via Struts (validate it) in action.clazz passing the String to the class that is using [email] ? Just my thought. Btw. what should we do with the @author tags? since some projects of Apache/Jakarta are removing them. Regards, Matthias -Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED] Sent: Monday, October 25, 2004 11:35 PM Cc: Jakarta Commons Developers List Subject: RE: [email] Dumbster failing Not a problem. I appreciate your working with me on this. I am looking forward to getting [email] whipped into shape! ERi -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Monday, October 25, 2004 7:21 PM To: [EMAIL PROTECTED] Cc: Jakarta Commons Developers List Subject: Re: [email] Dumbster failing Ok, I have the tests all up and running with Maven. I have also made some minor mods, based on the tests or improving the input checking (this is why some of the tests are failing, there where against my changes not the HEAD version sorry) So once we get this formatting issue sorted, I will submit to you the new patch. This should raise the test coverage to 90+% for all (non-deprecated) classes. 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: Validator inside of Email.java (RE: [email] Dumbster failing)
Want to say: A object represented by a clazz (subclass) of Email should be a valid Email. The validation should be done *before* creating an object of that class. -Matthias -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 9:09 AM To: 'Jakarta Commons Developers List'; [EMAIL PROTECTED] Subject: Validator inside of Email.java (RE: [email] Dumbster failing) Hi Eric, I just update my email sources. and looked abit on the patches you are submitting. Cool to have some unittest. Btw. I saw that EmailValidator of Commons Validator is used inside of Email.java; Does it realy make sence to validate an e-mail inside that class? shouldn't this work be done outside? eg. enter e-mail via Struts (validate it) in action.clazz passing the String to the class that is using [email] ? Just my thought. Btw. what should we do with the @author tags? since some projects of Apache/Jakarta are removing them. Regards, Matthias -Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED] Sent: Monday, October 25, 2004 11:35 PM Cc: Jakarta Commons Developers List Subject: RE: [email] Dumbster failing Not a problem. I appreciate your working with me on this. I am looking forward to getting [email] whipped into shape! ERi -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Monday, October 25, 2004 7:21 PM To: [EMAIL PROTECTED] Cc: Jakarta Commons Developers List Subject: Re: [email] Dumbster failing Ok, I have the tests all up and running with Maven. I have also made some minor mods, based on the tests or improving the input checking (this is why some of the tests are failing, there where against my changes not the HEAD version sorry) So once we get this formatting issue sorted, I will submit to you the new patch. This should raise the test coverage to 90+% for all (non-deprecated) classes. 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Validator inside of Email.java (RE: [email] Dumbster failing)
Matthias, I definately agree with you, inputs (emails in this case) should be validated before submission to a low level api such as [email]. However I added the validation just to make sure. I guess you could call it 'defensive' coding. I am happy to remove this and numerous other input checks that I have added to the email project if this is the general consensus, however I will strongly recommend that it not be removed. As saying goes its better to be safe then sorry right? Regards, Corey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[email] was RE: Validator inside of Email.java (RE: [email] Dumbster failing)
HumI'll answer the easy question first.. I think the @author tags should stay since it is an option. The PMC justs asks that projects make a decision on it one way or the other. So, for [email], I'll register myself on the yes they should stay side. The reason is that it helps figure out who had impact on what code, and at least for me, gives me the warm fuzzy's! It doensn't change copyright or anything, that remains with ASF. I belive it encourages contribution to see your name in lights and I would like them to stay. So, on the second side.. I guess, to what extent do we validate email information? I agree that requiring commons-validator seems a bit much for a small project like [email] just to use it. On the other hand, it does wrap the functionatliy up. Can you think of way to have our cake and eat it too? In other words, what is involved in maybe adding some sort of email validator decorate/helper class? Maybe something in a contrib directory showing how to do it.. [email] should remain small, and having a dependency on commons-validator is a lot... Eric PS, please tag your emails with [email], many folks filter on that type of tag in commons! -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 9:25 AM To: 'Jakarta Commons Developers List' Subject: RE: Validator inside of Email.java (RE: [email] Dumbster failing) Want to say: A object represented by a clazz (subclass) of Email should be a valid Email. The validation should be done *before* creating an object of that class. -Matthias -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 9:09 AM To: 'Jakarta Commons Developers List'; [EMAIL PROTECTED] Subject: Validator inside of Email.java (RE: [email] Dumbster failing) Hi Eric, I just update my email sources. and looked abit on the patches you are submitting. Cool to have some unittest. Btw. I saw that EmailValidator of Commons Validator is used inside of Email.java; Does it realy make sence to validate an e-mail inside that class? shouldn't this work be done outside? eg. enter e-mail via Struts (validate it) in action.clazz passing the String to the class that is using [email] ? Just my thought. Btw. what should we do with the @author tags? since some projects of Apache/Jakarta are removing them. Regards, Matthias -Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED] Sent: Monday, October 25, 2004 11:35 PM Cc: Jakarta Commons Developers List Subject: RE: [email] Dumbster failing Not a problem. I appreciate your working with me on this. I am looking forward to getting [email] whipped into shape! ERi -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Monday, October 25, 2004 7:21 PM To: [EMAIL PROTECTED] Cc: Jakarta Commons Developers List Subject: Re: [email] Dumbster failing Ok, I have the tests all up and running with Maven. I have also made some minor mods, based on the tests or improving the input checking (this is why some of the tests are failing, there where against my changes not the HEAD version sorry) So once we get this formatting issue sorted, I will submit to you the new patch. This should raise the test coverage to 90+% for all (non-deprecated) classes. 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] - 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] was RE: Validator inside of Email.java (RE: [email] Dumbster failing)
- Original Message - From: Eric Pugh [EMAIL PROTECTED] So, on the second side.. I guess, to what extent do we validate email information? I agree that requiring commons-validator seems a bit much for a small project like [email] just to use it. On the other hand, it does wrap the functionatliy up. I am -1 to adding a dependency like commons-validator to [email]. If necessary, we should copy the method adding comments to both implementations about the duplicated code. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [email] was RE: Validator inside of Email.java (RE: [email] Dumbster failing)
I believe the code for email validation is not too much (certainly less than the whole of validator package). Are you thinking of duplicating it in place of the validation reference or removing the validation from the functions and providing a validation function? Either of which should not be too much work. I believe the email validation is based on some very clever javascript, this we can easily convert? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[io] 1.1 tasks
A starter list: 1) Change ant/maven to exclude finder directory (for 1.1, stays in CVS until worked on) 2) Check all method names and signatures in FilenameUtils (and any other class whose first release it is) 3) Decide on whether to merge WildcardUtils with FilenameUtils 4) Check whether there are any other method names we got wrong in 1.0 and we want to fix now (like CopyUtils) 5) Check jdiff and clirr for compatability Any more? Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[email] Anyone interested?
Is anyone interested in a set of wrapper classes around the rest of the Mail API, naming for the receiving of email? As email is intended to be small maybe this would consistute a new project? Just interested to hear anyones thoughts (positive or negative welcome :-D) -Corey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project commons-messenger (in module jakarta-commons-sandbox) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-messenger has an issue affecting its community integration. This issue affects 15 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - avalon-jms-api : Avalon SVN - avalon-jms-impl : Avalon SVN - avalon-jms-test : Avalon SVN - avalon-planet-facilities : Avalon SVN - commons-jelly-tags-jms : This is a Jelly interface for the Java Message Service. - commons-jelly-tags-ojb : A variety of tags for working with the ObjectBridge persiste... - commons-messenger : A web based JMS framework - db-ojb : ObjectRelationalBridge - db-torque : Persistence Layer - jakarta-taglibs-jmstags : JMS Taglib - jakarta-turbine-3 : A servlet based framework. - jakarta-turbine-stratum : Turbine Components - jakarta-turbine-stratum-full : Turbine Components - scarab : Issue Tracking Built for the Ages - test-ojb : ObjectRelationalBridge Full details are available at: http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-messenger/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-messenger-26102004.jar] identifier set to project name -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/messenger/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/messenger/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/messenger/project.properties -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-messenger/gump_work/build_jakarta-commons-sandbox_commons-messenger.html Work Name: build_jakarta-commons-sandbox_commons-messenger (Type: Build) Work ended in a state of : Failed Elapsed: 1 sec Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons-sandbox/messenger] CLASSPATH : /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons-sandbox/target/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-26102004.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/jakarta-servletapi-4/lib/servlet.jar:/usr/local/gump/packages/jms1.0.2/lib/jms.jar:/usr/local/gump/packages/jta-spec1_0_1/jta-spec1_0_1.jar - __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0 The build cannot continue because of the following unsatisfied dependencies: commons-beanutils-1.6.1.jar geronimo-spec-jms-DEV.jar geronimo-spec-jta-DEV.jar Total time: 1 seconds Finished at: Tue Oct 26 01:27:01 PDT 2004 - To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-messenger/rss.xml - Atom: http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-messenger/atom.xml == Gump Tracking Only === Produced by Gump version 2.1.0-alpha-0003. Gump Run 3026102004, brutus:brutus-public:3026102004 Gump E-mail Identifier (unique within run) #9. -- Apache Gump http://gump.apache.org/ [Instance: brutus] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Validator inside of Email.java (RE: [email] Dumbster failing)
I think the question is the extra dependency.. Is it worth it? And, is there a way to make it optional? I actually am now back to the it should be optional as the validator class for emails has bugs against it for new email types. I think 4 letter suffixes don't pass for example.. However, for other types that don't require an extra dependency, I see it being worth having the extra checks. -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 10:04 AM To: Jakarta Commons Developers List Subject: Re: Validator inside of Email.java (RE: [email] Dumbster failing) Matthias, I definately agree with you, inputs (emails in this case) should be validated before submission to a low level api such as [email]. However I added the validation just to make sure. I guess you could call it 'defensive' coding. I am happy to remove this and numerous other input checks that I have added to the email project if this is the general consensus, however I will strongly recommend that it not be removed. As saying goes its better to be safe then sorry right? Regards, 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]
[GUMP@brutus]: Project commons-xo (in module jakarta-commons-sandbox) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-xo has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-xo : Jakarta commons sandbox Full details are available at: http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-xo/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-xo-26102004.jar] identifier set to project name -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/xo/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/xo/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/xo/project.properties -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-xo/gump_work/build_jakarta-commons-sandbox_commons-xo.html Work Name: build_jakarta-commons-sandbox_commons-xo (Type: Build) Work ended in a state of : Failed Elapsed: 1 sec Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons-sandbox/xo] CLASSPATH : /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons-sandbox/target/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/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/io/dist/jakarta-commons-io-26102004.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-26102004.jar - __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0 The build cannot continue because of the following unsatisfied dependencies: commons-beanutils-1.7-dev.jar commons-collections-1.0.jar (try downloading from http://jakarta.apache.org/commons/collections/index.html) Total time: 1 seconds Finished at: Tue Oct 26 01:33:38 PDT 2004 - To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-xo/rss.xml - Atom: http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-xo/atom.xml == Gump Tracking Only === Produced by Gump version 2.1.0-alpha-0003. Gump Run 3026102004, brutus:brutus-public:3026102004 Gump E-mail Identifier (unique within run) #11. -- Apache Gump http://gump.apache.org/ [Instance: brutus] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [email] was RE: Validator inside of Email.java (RE: [email] Dumbster failing)
see intermixed HumI'll answer the easy question first.. I think the @author tags should stay since it is an option. The PMC justs asks that projects make a decision on it one way or the other. So, for [email], I'll register myself on the yes they should stay side. yes ok :) no problem with it. In MyFaces, which is now in Incubator, we keep them too. But Struts for instance has removed them. The reason is that it helps figure out who had impact on what code, and at least for me, gives me the warm fuzzy's! It doensn't change copyright or anything, that remains with ASF. I belive it encourages contribution to see your name in lights and I would like them to stay. yes! that's it ;-) So, on the second side.. I guess, to what extent do we validate email information? I agree that requiring commons-validator seems a bit much for a small project like [email] just to use it. On the other hand, it does wrap the functionatliy up. Can you think of way to have our cake and eat it too? In other words, what is involved in maybe adding some sort of email validator decorate/helper class? Maybe something in a contrib directory showing how to do it.. well helperclazzes sounds more reasonable to me, but does this blow up [email] ? [email] should remain small, and having a dependency on commons-validator is a lot... yes! my +1 on remoing this dependency Eric PS, please tag your emails with [email], many folks filter on that type of tag in commons! sorry just forgotten... Matthias -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 9:25 AM To: 'Jakarta Commons Developers List' Subject: RE: Validator inside of Email.java (RE: [email] Dumbster failing) Want to say: A object represented by a clazz (subclass) of Email should be a valid Email. The validation should be done *before* creating an object of that class. -Matthias -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 9:09 AM To: 'Jakarta Commons Developers List'; [EMAIL PROTECTED] Subject: Validator inside of Email.java (RE: [email] Dumbster failing) Hi Eric, I just update my email sources. and looked abit on the patches you are submitting. Cool to have some unittest. Btw. I saw that EmailValidator of Commons Validator is used inside of Email.java; Does it realy make sence to validate an e-mail inside that class? shouldn't this work be done outside? eg. enter e-mail via Struts (validate it) in action.clazz passing the String to the class that is using [email] ? Just my thought. Btw. what should we do with the @author tags? since some projects of Apache/Jakarta are removing them. Regards, Matthias -Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED] Sent: Monday, October 25, 2004 11:35 PM Cc: Jakarta Commons Developers List Subject: RE: [email] Dumbster failing Not a problem. I appreciate your working with me on this. I am looking forward to getting [email] whipped into shape! ERi -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Monday, October 25, 2004 7:21 PM To: [EMAIL PROTECTED] Cc: Jakarta Commons Developers List Subject: Re: [email] Dumbster failing Ok, I have the tests all up and running with Maven. I have also made some minor mods, based on the tests or improving the input checking (this is why some of the tests are failing, there where against my changes not the HEAD version sorry) So once we get this formatting issue sorted, I will submit to you the new patch. This should raise the test coverage to 90+% for all (non-deprecated) classes. 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] - 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] Anyone interested?
Corey, are you thinking of introducing preconfigured email-objects as well? -Matthias -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 10:27 AM To: Jakarta Commons Developers List Subject: [email] Anyone interested? Is anyone interested in a set of wrapper classes around the rest of the Mail API, naming for the receiving of email? As email is intended to be small maybe this would consistute a new project? Just interested to hear anyones thoughts (positive or negative welcome :-D) -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]
[GUMP@brutus]: Project commons-email (in module jakarta-commons-sandbox) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-email has an issue affecting its community integration. This issue affects 2 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-email : Commons Email Package - fulcrum-template : Services Framework Full details are available at: http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-email/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-email-26102004.jar] identifier set to project name -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/email/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/email/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/email/project.properties -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-email/gump_work/build_jakarta-commons-sandbox_commons-email.html Work Name: build_jakarta-commons-sandbox_commons-email (Type: Build) Work ended in a state of : Failed Elapsed: 1 sec Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons-sandbox/email] CLASSPATH : /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons-sandbox/target/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/lang/dist/commons-lang-26102004.jar:/usr/local/gump/public/workspace/jakarta-commons/validator/dist/commons-validator.jar:/usr/local/gump/public/workspace/jakarta-oro/jakarta-oro-26102004.jar:/usr/local/gump/packages/javamail-1.3/mail.jar:/usr/local/gump/packages/javamail-1.3/lib/mailapi.jar:/usr/local/gump/packages/jaf-1.0.1/activation.jar - __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0 The build cannot continue because of the following unsatisfied dependency: dumbster-1.0.3.jar Total time: 1 seconds Finished at: Tue Oct 26 01:51:43 PDT 2004 - To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-email/rss.xml - Atom: http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-email/atom.xml == Gump Tracking Only === Produced by Gump version 2.1.0-alpha-0003. Gump Run 3026102004, brutus:brutus-public:3026102004 Gump E-mail Identifier (unique within run) #14. -- Apache Gump http://gump.apache.org/ [Instance: brutus] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [email] Anyone interested?
I guess it depends on the scope of the extra dependencies and functionality. This sounds like it's within the scope of [email]. It isnt called [sendemail]!Also, is this starting to intrude on the space that James has? Not looking to create a mail server, or anything. You may want to look at http://james.apache.org/ for ideas. Eric -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 10:27 AM To: Jakarta Commons Developers List Subject: [email] Anyone interested? Is anyone interested in a set of wrapper classes around the rest of the Mail API, naming for the receiving of email? As email is intended to be small maybe this would consistute a new project? Just interested to hear anyones thoughts (positive or negative welcome :-D) -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]
[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 4 projects, and has been outstanding for 13 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-fmt : This is a set of Jelly i18n tags. - commons-jelly-tags-jsl : The Jelly Stylesheet Library (JSL) - 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-26102004.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=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dfinal.name=commons-jelly-tags-ant-26102004 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-26102004.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-26102004.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-26102004.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-26102004.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-26102004.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-26102004.jar:/usr/local/gump/public/workspace/jelly-tags/util/target/commons-jelly-tags-util-26102004.jar:/usr/local/gump/public/workspace/jelly-tags/junit/target/commons-jelly-tags-junit-26102004.jar - [junit] Testcase: readWrite took 0.109 sec [junit] Testcase: writeIn took 0.213 sec [junit] Testcase: readWriteIn took 0.191 sec [junit] Testcase: startUpReadWrite took 0.126 sec [junit] Testcase: copy took 0.129 sec [junit] Caused an ERROR [junit] file:/usr/local/gump/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:/usr/local/gump/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:677) [junit] at
[GUMP@brutus]: Project commons-resources (in module jakarta-commons-sandbox) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-resources has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 42 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-resources : Commons resources Full details are available at: http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-resources/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-resources-26102004.jar] identifier set to project name -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/resources/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/resources/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/resources/project.properties -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-resources/gump_work/build_jakarta-commons-sandbox_commons-resources.html Work Name: build_jakarta-commons-sandbox_commons-resources (Type: Build) Work ended in a state of : Failed Elapsed: 1 sec Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons-sandbox/resources] CLASSPATH : /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons-sandbox/resources/target/classes:/usr/local/gump/public/workspace/jakarta-commons-sandbox/resources/target/test-classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-26102004.jar:/usr/local/gump/public/workspace/jakarta-commons/digester/dist/commons-digester.jar:/usr/local/gump/public/workspace/jakarta-commons/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/packages/iBATIS_DBL-2.0.5.399/ibatis-dao-2.jar:/usr/local/gump/packages/iBATIS_DBL-2.0.5.399/ibatis-common-2.jar:/usr/local/gump/packages/iBATIS_DBL-2.0.5.399/ibatis-sqlmap-2.jar - __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0 The build cannot continue because of the following unsatisfied dependencies: commons-beanutils-1.5.jar hsqldb-1.7.1.jar jdom-b10.jar Total time: 1 seconds Finished at: Tue Oct 26 02:18:28 PDT 2004 - To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-resources/rss.xml - Atom: http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-resources/atom.xml == Gump Tracking Only === Produced by Gump version 2.1.0-alpha-0003. Gump Run 3026102004, brutus:brutus-public:3026102004 Gump E-mail Identifier (unique within run) #20. -- Apache Gump http://gump.apache.org/ [Instance: brutus] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [email] Anyone interested?
I guess Corey means only helper classes for [email] - A simple wrapper for validation - configured email-settings, that is in XML. for now, a developer needs to set all the stuff (eg. smtp-server, user,...) with a xml based *config* you could have more easy development. only setting sender,recipient, subject and text. isn't it? I guess he didn't wanted to created a mail server :) Regards, Matthias -Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 11:09 AM To: Jakarta Commons Developers List; Corey Scott Subject: RE: [email] Anyone interested? I guess it depends on the scope of the extra dependencies and functionality. This sounds like it's within the scope of [email]. It isnt called [sendemail]!Also, is this starting to intrude on the space that James has? Not looking to create a mail server, or anything. You may want to look at http://james.apache.org/ for ideas. Eric -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 10:27 AM To: Jakarta Commons Developers List Subject: [email] Anyone interested? Is anyone interested in a set of wrapper classes around the rest of the Mail API, naming for the receiving of email? As email is intended to be small maybe this would consistute a new project? Just interested to hear anyones thoughts (positive or negative welcome :-D) -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]
Re: [email] Anyone interested?
I definately don't want to create a mail server :-) Actually I was thinking of something similar to a simple set of functions similar to the way that PHP has wrappers on the IMAP lib (ftp://ftp.cac.washington.edu/imap/) Maybe James takes care of this already, I am not certain. As to adding XML config, I am for it, but there was a recently discussion about this and it seemed that is may not be wanted. My major concern with adding it would be that my first stop would be use digester for parsing the XML file and that adds dependancies again!! Is there anyway anyone can think of to keep the [email] project as is (small and compact) and yet add all of these optional or nice to have functions? This way those that wanted the small compact version wouldnt be burdened with all the extra dependancies and features that they have no need for. -Corey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [email] Anyone interested?
Well.. As we add functionalty, it will drag along the dependencies. Which is okay if they aren't mandated. For example, in [configuration] you need very little for the base function. But, as you add in Configuration objects backed by JNDI, Databases, Servlet web.xml, etc, you need more and more. This is address partly by just documentation: http://jakarta.apache.org/commons/configuration/dependencies.html So, I am okay I guess with adding configuration/digester/etc. As long as the core API doesn't require it. I guess it comes down to the fact that things like configuration are orthongonal (?) to what email is. Lets add the functionality, but lets not mandate it. Eric -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 11:57 AM To: Jakarta Commons Developers List Subject: Re: [email] Anyone interested? I definately don't want to create a mail server :-) Actually I was thinking of something similar to a simple set of functions similar to the way that PHP has wrappers on the IMAP lib (ftp://ftp.cac.washington.edu/imap/) Maybe James takes care of this already, I am not certain. As to adding XML config, I am for it, but there was a recently discussion about this and it seemed that is may not be wanted. My major concern with adding it would be that my first stop would be use digester for parsing the XML file and that adds dependancies again!! Is there anyway anyone can think of to keep the [email] project as is (small and compact) and yet add all of these optional or nice to have functions? This way those that wanted the small compact version wouldnt be burdened with all the extra dependancies and features that they have no need for. -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] Anyone interested?
Just a few opinions on the flurry of commons-email discussion... On the subject of validating email addresses: I would recommend against any required validation inside the classes which represent email messages to be sent. There's enough possibility that your validation rules won't work, and I believe it should be the user's responsibility to determine strictness. From there, I would agree that it might be nice for email to provide some address validation interface of its own, but this should be external from the Email class and its family. I don't think this is critical, but I wouldn't think it was wrong. Regarding configuration, I would want to see more specifics before offering an opinion, but I think that in general, all that needs to happen is that Email classes should follow JavaBean specifications as much as possible. If this is done, then a number of different configuration tools will all be able to populate instances. As with providing any validation facility, I don't think this is critical at all, but I don't think it's wrong. And as for classes to simplify receiving email, I don't think that needs to be in a separate package. We're not talking about writing J2ME libraries that have to economize wherever possible on JAR size. I just think that the most successful projects are the ones with the tightest focus. But receiving email belongs in commons-email more than it belongs in a new library. I haven't had any use for such things, but that's no reason to say it doesn't belong. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [email] Anyone interested?
Hi, These ideas are all very interesting. I would just caution against falling into the same pits experienced by [configuration] and [math]: that is, endlessly debating/adding features, refactoring, etc, before ever making a release. It might be good to get a 1.0 release out there and then discuss/act upon these new ideas for 1.1 or 2.0. Release early, release often is always my vote ;) Yoav Shapira http://www.yoavshapira.com -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 8:49 AM To: Jakarta Commons Developers List Subject: RE: [email] Anyone interested? Just a few opinions on the flurry of commons-email discussion... On the subject of validating email addresses: I would recommend against any required validation inside the classes which represent email messages to be sent. There's enough possibility that your validation rules won't work, and I believe it should be the user's responsibility to determine strictness. From there, I would agree that it might be nice for email to provide some address validation interface of its own, but this should be external from the Email class and its family. I don't think this is critical, but I wouldn't think it was wrong. Regarding configuration, I would want to see more specifics before offering an opinion, but I think that in general, all that needs to happen is that Email classes should follow JavaBean specifications as much as possible. If this is done, then a number of different configuration tools will all be able to populate instances. As with providing any validation facility, I don't think this is critical at all, but I don't think it's wrong. And as for classes to simplify receiving email, I don't think that needs to be in a separate package. We're not talking about writing J2ME libraries that have to economize wherever possible on JAR size. I just think that the most successful projects are the ones with the tightest focus. But receiving email belongs in commons-email more than it belongs in a new library. I haven't had any use for such things, but that's no reason to say it doesn't belong. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] 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]
Re: Validator inside of Email.java (RE: [email] Dumbster failing)
As a validator committer I'd thought I'd share my 2 cents. I agree that validating the email address should be done by the user of [email]. If the address passed to [email] is invalid, the user will receive a MessageException just as they would expect from using JavaMail. Unfortunately, validator's dependency list is quite bloated at the moment so it would be painful for you to have a dependency on it because it will drag along a boatload of other components you don't need. We are working to correct that but it probably won't be as soon as you'd like :-). IMO, copy and pasting the validator code into email is a bad idea. This code is not stable and you will constantly be in catch up mode. Not to mention that coding technique is probably the worst thing a programmer can do. I just spent a *long* time deleting approximately 50% of a code base that now does what it used to do in half the code and half the time. We're better than this at Apache :-). Commons projects and Struts chose to get rid of the @author tags for some of these reasons: 1. They imply ownership over the code and create a territorial environment. This is community owned code and @author tags violate that spirit. 2. Apache code lives for many years and well past the original author's contributions. Does an @author tag from 10 years ago after major refactoring of the file still apply? 3. The source control system (CVS, Subversion, etc) is a more accurate tracking device for contributions. Username, date, comments, and release tags all say much more about a contribution than a simple @author tag. 4. The project contributors webpage is a good place for publicly recognizing people's contributions without affecting the code. David --- Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi Eric, I just update my email sources. and looked abit on the patches you are submitting. Cool to have some unittest. Btw. I saw that EmailValidator of Commons Validator is used inside of Email.java; Does it realy make sence to validate an e-mail inside that class? shouldn't this work be done outside? eg. enter e-mail via Struts (validate it) in action.clazz passing the String to the class that is using [email] ? Just my thought. Btw. what should we do with the @author tags? since some projects of Apache/Jakarta are removing them. Regards, Matthias -Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED] Sent: Monday, October 25, 2004 11:35 PM Cc: Jakarta Commons Developers List Subject: RE: [email] Dumbster failing Not a problem. I appreciate your working with me on this. I am looking forward to getting [email] whipped into shape! ERi -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Monday, October 25, 2004 7:21 PM To: [EMAIL PROTECTED] Cc: Jakarta Commons Developers List Subject: Re: [email] Dumbster failing Ok, I have the tests all up and running with Maven. I have also made some minor mods, based on the tests or improving the input checking (this is why some of the tests are failing, there where against my changes not the HEAD version sorry) So once we get this formatting issue sorted, I will submit to you the new patch. This should raise the test coverage to 90+% for all (non-deprecated) classes. 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] __ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [email] Anyone interested?
I think this is a great idea!! -Corey Hi, These ideas are all very interesting. I would just caution against falling into the same pits experienced by [configuration] and [math]: that is, endlessly debating/adding features, refactoring, etc, before ever making a release. It might be good to get a 1.0 release out there and then discuss/act upon these new ideas for 1.1 or 2.0. Release early, release often is always my vote ;) Yoav Shapira http://www.yoavshapira.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [email] Anyone interested?
my +1 too -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 3:29 PM To: Jakarta Commons Developers List Subject: Re: [email] Anyone interested? I think this is a great idea!! -Corey Hi, These ideas are all very interesting. I would just caution against falling into the same pits experienced by [configuration] and [math]: that is, endlessly debating/adding features, refactoring, etc, before ever making a release. It might be good to get a 1.0 release out there and then discuss/act upon these new ideas for 1.1 or 2.0. Release early, release often is always my vote ;) Yoav Shapira http://www.yoavshapira.com - 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] Anyone interested?
Bases on the release early, release often criteria, maybe it makes sense to get the rest of Corey's unit tests patches in, and spend a bit of time verifing all the javadocs etc. Then do a 1.0 of whats there. That way we don't have to be quite as contrained by the existing API, as projects that depend on email will have a nice released version that they can use. This also might be the time to migrate out of the sandbox? -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 3:44 PM To: 'Jakarta Commons Developers List'; 'Corey Scott' Subject: RE: [email] Anyone interested? my +1 too -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 3:29 PM To: Jakarta Commons Developers List Subject: Re: [email] Anyone interested? I think this is a great idea!! -Corey Hi, These ideas are all very interesting. I would just caution against falling into the same pits experienced by [configuration] and [math]: that is, endlessly debating/adding features, refactoring, etc, before ever making a release. It might be good to get a 1.0 release out there and then discuss/act upon these new ideas for 1.1 or 2.0. Release early, release often is always my vote ;) Yoav Shapira http://www.yoavshapira.com - 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]
[other] Gmail
I know this is outside of the limits of this list but I think that the people here might be those that might be interested. I have 3 gmail invitations free if anyone that hasn't already got a gmail account and would like one. Its a first come, first served deal. Please dont flame me for posting non-common related stuff here. Regards, Corey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Commons websites] not updated recently
Is there a reason why a some of the commons sites have not been updated for a few months? Isnt this giving people (outsiders) a false sense of how active/inactive the projects are? I thought that seeing as most sites are probably auto-generated/updated using maven that someone would have cron'd this? Thanks, Corey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [email] Anyone interested?
hi, Bases on the release early, release often criteria, maybe it makes sense to get the rest of Corey's unit tests patches in, and spend a bit of time verifing all the javadocs etc. Then do a 1.0 of whats there. That way we don't have to be quite as contrained by the existing API, as projects that depend on email will have a nice released version that they can use. yes, sounds good to me. But in 1.0 [email] should not depend on Commons Validator. This also might be the time to migrate out of the sandbox? I guess this depends on a vote in commons-dev list, isn't it? Regards, Matthias -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 3:44 PM To: 'Jakarta Commons Developers List'; 'Corey Scott' Subject: RE: [email] Anyone interested? my +1 too -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 3:29 PM To: Jakarta Commons Developers List Subject: Re: [email] Anyone interested? I think this is a great idea!! -Corey Hi, These ideas are all very interesting. I would just caution against falling into the same pits experienced by [configuration] and [math]: that is, endlessly debating/adding features, refactoring, etc, before ever making a release. It might be good to get a 1.0 release out there and then discuss/act upon these new ideas for 1.1 or 2.0. Release early, release often is always my vote ;) Yoav Shapira http://www.yoavshapira.com - 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: Validator inside of Email.java (RE: [email] Dumbster failing)
So have we reached a concensus on all of this? To summarize: -Validation should NOT be included in the current version -This issue will be revisited after the release -The current functionality is appropriate AS IS -The major targets we have now prior to a first release are: 1) Complete the Unit Tests 2) Ensure the JavaDocs are up to scratch 3) Add documentation that indicates that the Dumbster and other recently added dependancies are for testing purposes only. 4) Anything else I missed? Regards, Corey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [email] Anyone interested?
--- Eric Pugh [EMAIL PROTECTED] wrote: Bases on the release early, release often criteria, maybe it makes sense to get the rest of Corey's unit tests patches in, and spend a bit of time verifing all the javadocs etc. Then do a 1.0 of whats there. That way we don't have to be quite as contrained by the existing API, as projects that depend on email will have a nice released version that they can use. This also might be the time to migrate out of the sandbox? Sandbox projects are not allowed to have releases so you would need to get voted into commons proper before releasing 1.0. David -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 3:44 PM To: 'Jakarta Commons Developers List'; 'Corey Scott' Subject: RE: [email] Anyone interested? my +1 too -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 3:29 PM To: Jakarta Commons Developers List Subject: Re: [email] Anyone interested? I think this is a great idea!! -Corey Hi, These ideas are all very interesting. I would just caution against falling into the same pits experienced by [configuration] and [math]: that is, endlessly debating/adding features, refactoring, etc, before ever making a release. It might be good to get a 1.0 release out there and then discuss/act upon these new ideas for 1.1 or 2.0. Release early, release often is always my vote ;) Yoav Shapira http://www.yoavshapira.com - 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 you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Commons websites] not updated recently
Corey Scott wrote: Is there a reason why a some of the commons sites have not been updated for a few months? Isnt this giving people (outsiders) a false sense of how active/inactive the projects are? I thought that seeing as most sites are probably auto-generated/updated using maven that someone would have cron'd this? I believe the last time we spoke about this topic we stumbled on the lack of distinction between stable and unstable documentation in maven. With the default maven configuration, updating the site automatically means publishing unstable javadoc API and documentation pages that do not apply to the latest release, which is confusing for users. Some projects likes [collections] or [digester] have hacked the publishing process to generate separated documentations for released API and developpement API, but this is not generalized yet. We just need someone courageous to step in and harmonize the maven configurations for all commons projects, or even better patch maven directly. Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [email] Anyone interested?
David, thanks for pointing this out! Regards, Matthias -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 6:12 PM To: Jakarta Commons Developers List Subject: RE: [email] Anyone interested? --- Eric Pugh [EMAIL PROTECTED] wrote: Bases on the release early, release often criteria, maybe it makes sense to get the rest of Corey's unit tests patches in, and spend a bit of time verifing all the javadocs etc. Then do a 1.0 of whats there. That way we don't have to be quite as contrained by the existing API, as projects that depend on email will have a nice released version that they can use. This also might be the time to migrate out of the sandbox? Sandbox projects are not allowed to have releases so you would need to get voted into commons proper before releasing 1.0. David -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 3:44 PM To: 'Jakarta Commons Developers List'; 'Corey Scott' Subject: RE: [email] Anyone interested? my +1 too -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 3:29 PM To: Jakarta Commons Developers List Subject: Re: [email] Anyone interested? I think this is a great idea!! -Corey Hi, These ideas are all very interesting. I would just caution against falling into the same pits experienced by [configuration] and [math]: that is, endlessly debating/adding features, refactoring, etc, before ever making a release. It might be good to get a 1.0 release out there and then discuss/act upon these new ideas for 1.1 or 2.0. Release early, release often is always my vote ;) Yoav Shapira http://www.yoavshapira.com - 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 you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail - 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: [Commons websites] not updated recently
Forgive me if I am speaking out of turn, but would this only be a matter of running the maven reports target against the release branch of the cvs not the latest? (this sound like something obtainable with a reasonably small amount of effort) Then hacking together a menu which indicated this? Please tell me if I am missing the point here. Thanks, Corey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/jelly/jelly-tags/util/src/test/org/apache/commons/jelly/tags/util Customer.java suite.jelly
dion2004/10/26 09:42:56
Modified:jelly/jelly-tags/util/src/java/org/apache/commons/jelly/tags/util
UtilTagLibrary.java
jelly/jelly-tags/util/xdocs changes.xml
jelly/jelly-tags/util/src/test/org/apache/commons/jelly/tags/util
suite.jelly
Added: jelly/jelly-tags/util/src/java/org/apache/commons/jelly/tags/util
SortTag.java
jelly/jelly-tags/util/src/test/org/apache/commons/jelly/tags/util
Customer.java
Log:
Jelly-157: Add a util:sort tag to sort lists.
Revision ChangesPath
1.6 +3 -2
jakarta-commons/jelly/jelly-tags/util/src/java/org/apache/commons/jelly/tags/util/UtilTagLibrary.java
Index: UtilTagLibrary.java
===
RCS file:
/home/cvs/jakarta-commons/jelly/jelly-tags/util/src/java/org/apache/commons/jelly/tags/util/UtilTagLibrary.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- UtilTagLibrary.java 9 Sep 2004 12:22:43 - 1.5
+++ UtilTagLibrary.java 26 Oct 2004 16:42:56 - 1.6
@@ -30,7 +30,8 @@
registerTag(loadText, LoadTextTag.class);
registerTag(properties, PropertiesTag.class);
registerTag(replace, ReplaceTag.class);
-registerTag(tokenize, TokenizeTag.class);
registerTag(sleep, SleepTag.class);
+registerTag(sort, SortTag.class);
+registerTag(tokenize, TokenizeTag.class);
}
}
1.1
jakarta-commons/jelly/jelly-tags/util/src/java/org/apache/commons/jelly/tags/util/SortTag.java
Index: SortTag.java
===
/*
* Copyright 2002,2004 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.apache.commons.jelly.tags.util;
import java.util.ArrayList;
import java.util.Collections;
import java.util.List;
import org.apache.commons.beanutils.BeanComparator;
import org.apache.commons.jelly.JellyTagException;
import org.apache.commons.jelly.MissingAttributeException;
import org.apache.commons.jelly.TagSupport;
import org.apache.commons.jelly.XMLOutput;
public class SortTag extends TagSupport {
/** things to sort */
private List items;
/** the variable to store the result in */
private String var;
/** property of the beans to sort on, if any */
private String property;
// Tag interface
//-
public void doTag(final XMLOutput output) throws JellyTagException {
if (var == null)
{
throw new MissingAttributeException(var);
}
if (items == null) {
throw new MissingAttributeException(items);
}
List sorted = new ArrayList(items);
if (property == null) {
Collections.sort(sorted);
} else {
BeanComparator comparator = new BeanComparator(property);
Collections.sort(sorted, comparator);
}
context.setVariable(var, sorted);
}
/**
* Set the items to be sorted
* @param newItems some collection
*/
public void setItems(List newItems) {
items = newItems;
}
/**
* The variable to hold the sorted collection.
* @param newVar the name of the variable.
*/
public void setVar(String newVar) {
var = newVar;
}
public void setProperty(String newProperty)
{
property = newProperty;
}
}
1.5 +1 -0 jakarta-commons/jelly/jelly-tags/util/xdocs/changes.xml
Index: changes.xml
===
RCS file: /home/cvs/jakarta-commons/jelly/jelly-tags/util/xdocs/changes.xml,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- changes.xml 12 Sep 2004 16:04:59 - 1.4
+++ changes.xml 26 Oct 2004 16:42:56 - 1.5
@@ -25,6 +25,7 @@
/properties
body
release version=1.1-SNAPSHOT date=in CVS
+ action dev=dion type=add
[jira] Resolved: (JELLY-157) New tag that generates sorted collection
[ http://issues.apache.org/jira/browse/JELLY-157?page=history ]
dion gillard resolved JELLY-157:
Resolution: Fixed
Fix Version: 1.0
Done.
New tag that generates sorted collection
Key: JELLY-157
URL: http://issues.apache.org/jira/browse/JELLY-157
Project: jelly
Type: New Feature
Components: taglib.util
Versions: 1.0
Reporter: Felipe Leme
Priority: Minor
Fix For: 1.0
A cool tag would be one that takes one collection (or map) and returns a new
collection/map, sorted by a given property (on each of the collection's elements).
This tag could be used, for instance, on Maven's multiproject plugin to generate a
sorted report of sub-projects:
util:sort var=multiprojectsSortedByName items=${multiprojects}
sortingProperty=name/
Such tag shouldn't be hard to implement, but I haven't the time to do the full job
right now (i.e., writing the tag, test cases, documentation, etc...), but I can give
it a shot in the near future, if there is enough interested on such feature (in
other words, if someone is willing to commit the changes :-).
-- Felipe
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-157) New tag that generates sorted collection
[ http://issues.apache.org/jira/browse/JELLY-157?page=comments#action_54678 ]
Felipe Leme commented on JELLY-157:
---
Hi Dion,
Thanks for implementing it.
BTW, could you please notify when a new version will be available on ibiblio (even if
its a timestamped release)?
-- Felipe
New tag that generates sorted collection
Key: JELLY-157
URL: http://issues.apache.org/jira/browse/JELLY-157
Project: jelly
Type: New Feature
Components: taglib.util
Versions: 1.0
Reporter: Felipe Leme
Priority: Minor
Fix For: 1.0
A cool tag would be one that takes one collection (or map) and returns a new
collection/map, sorted by a given property (on each of the collection's elements).
This tag could be used, for instance, on Maven's multiproject plugin to generate a
sorted report of sub-projects:
util:sort var=multiprojectsSortedByName items=${multiprojects}
sortingProperty=name/
Such tag shouldn't be hard to implement, but I haven't the time to do the full job
right now (i.e., writing the tag, test cases, documentation, etc...), but I can give
it a shot in the near future, if there is enough interested on such feature (in
other words, if someone is willing to commit the changes :-).
-- Felipe
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Util tag library 1.1 released.
The jelly team is pleased to announce the commons-jelly-tags-util 1.1 release! http://jakarta.apache.org/commons/jelly/libs/util/index.html This is a set of Jelly utility tags. Changes in this version include: New Features: o Add util:sort to sort lists, including sorting by bean properties Issue: JELLY-157. Changes: o support encoding parameter for util:loadText Issue: JELLY-57. Thanks to Bill Keese. Have fun! -- http://www.multitask.com.au/people/dion/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [other] Gmail
Corey Scott wrote: I know this is outside of the limits of this list but I think that the people here might be those that might be interested. I have 3 gmail invitations free if anyone that hasn't already got a gmail account and would like one. Its a first come, first served deal. Please dont flame me for posting non-common related stuff here. Regards, Corey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Many thanks, again, Corey. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31881] - [email] Style only changes
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=31881. 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=31881 [email] Style only changes --- Additional Comments From [EMAIL PROTECTED] 2004-10-26 18:31 --- Created an attachment (id=13224) style only changes for deprecated class ByteArrayDataSouce - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31881] - [email] Style only changes
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=31881. 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=31881 [email] Style only changes --- Additional Comments From [EMAIL PROTECTED] 2004-10-26 18:32 --- Changes for last attachment (10/26/04 18:31) ByteArrayDataSource - -Minor style changes -Removed redunant try/catch blocks from: byteArrayDataSource(InputStream aIs, String aType) ByteArrayDataSource(byte[] data, String aType) ByteArrayDataSource(String data, String aType) -Changed the empty catch (UnsupportedEncodingException uex), which is an coding style violation, to throw an IOException -Changed the line byte[] buffer = new byte[512]; in byteArrayDataSource(InputStream aIs, String aType) to a static property again to conform to the coding style - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31900] New: - GenericObjectPool: TestWhileIdle is mutually exclusive with MinEvictableIdleTimeMillis
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=31900. 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=31900 GenericObjectPool: TestWhileIdle is mutually exclusive with MinEvictableIdleTimeMillis Summary: GenericObjectPool: TestWhileIdle is mutually exclusive with MinEvictableIdleTimeMillis Product: Commons Version: 1.2 Final Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Pool AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If a GenericObjectPool is configured with a postive MinEvictableIdleTimeMillis value, then idle validations are not performed even if TestWhileIdle is true. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31901] New: - [email] further improvements to test code and removal of emails validation
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=31901. 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=31901 [email] further improvements to test code and removal of emails validation Summary: [email] further improvements to test code and removal of emails validation Product: Commons Version: 1.0 Alpha Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Sandbox AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Changes list: Email - -Removed Email validation -changed (back) to getInstance due to security exceptions caused when testing using maven -In setFrom(String email, String name) changed the checking to StringUtils.isNotEmpty -Fixed some incorrect logic in testing for charset in: addTo(String email, String name) addCc(String email, String name) addBcc(String email, String name) addReplyTo(String email, String name) Mulitpart Email - -Corrected style errors involving imports -Added validation to disallow null message contents in setMsg(String msg) -Removed redundant if statment from send() to streamline the function -Added validation to disallow null attachements to attach(EmailAttachment attachment) -Added URL validation for attach(URL url, String name, String description, String disposition) -Added Datasource validation for attach( DataSource ds, String name, String description) -Removed redundant if statement from getPrimaryBodyPart() as the code was a duplicate of code inside init() EmailAttachmentTest - -Coding style changes only EmailTest - -Added test for the Get/Set session -Minor Coding style changes -Added exception test for the person param to all relevant address functions -Added the server port as a configurable var and added it as a static property -Added code to set the configured port during tests HtmlEmailTest - -Minor Coding style changes -Added the server port as a configurable var and added it as a static property -Added code to set the configured port during tests MulitpartEmailTest - -Minor Coding style changes -Added the server port as a configurable var and added it as a static property -Added code to set the configured port during tests -Removed the hard coded test url and added reference to the configuration class instead -Added test for init SimpleEmailTest - -added apache license -Minor Coding style changes -Added the server port as a configurable var and added it as a static property -Added code to set the configured port during tests EmailConfiguration - -added apache license -Minor Coding style changes -changed the test url to a active url MockEmailConcrete - -added apache license -Minor Coding style changes -added function to help test get/set session MockHtmlEmailConcrete - -added apache license MockMulitPartEmailConcrete - -added apache license -added test for init function MockHtmlEmailConcrete - -added apache license - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31901] - [email] further improvements to test code and removal of emails validation
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=31901. 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=31901 [email] further improvements to test code and removal of emails validation --- Additional Comments From [EMAIL PROTECTED] 2004-10-26 19:23 --- Created an attachment (id=13225) patch as described in bug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31904] New: - Inline attatchment encoding was incorrect
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=31904. 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=31904 Inline attatchment encoding was incorrect Summary: Inline attatchment encoding was incorrect Product: Commons Version: 1.0 Alpha Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Sandbox AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] the Content-ID needs to be between this was preventing effective inclusion of inline images in html emails. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31904] - Inline attatchment encoding was incorrect
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=31904. 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=31904 Inline attatchment encoding was incorrect --- Additional Comments From [EMAIL PROTECTED] 2004-10-26 19:54 --- Created an attachment (id=13226) Returns correct id string, and sets contentid correctly of inline attatchments. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [email] apple mail
Well it wasn't apple mail at all it was the embed method. When adding a an inline attachment the Content-ID needs to be in myid tags. Submitted a patch, the problem doesn't get picked up by the unit so no test case. Mark On 26 Oct 2004, at 09:05, Mark Lowe wrote: Has anyone come any issues displaying content type related mails with apple's mail client? Mark - 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 31904] - [email] Inline attatchment encoding was incorrect
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=31904. 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=31904 [email] Inline attatchment encoding was incorrect [EMAIL PROTECTED] changed: What|Removed |Added Summary|Inline attatchment encoding |[email] Inline attatchment |was incorrect |encoding was incorrect - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/digester/xdocs navigation.xml
rdonkin 2004/10/26 14:52:37 Modified:digester/xdocs navigation.xml Log: Really fixed the urls this time! (I hope) Revision ChangesPath 1.13 +2 -2 jakarta-commons/digester/xdocs/navigation.xml Index: navigation.xml === RCS file: /home/cvs/jakarta-commons/digester/xdocs/navigation.xml,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- navigation.xml17 Oct 2004 15:29:50 - 1.12 +++ navigation.xml26 Oct 2004 21:52:37 - 1.13 @@ -17,11 +17,11 @@ item name=Overview (Current) href=/index.html/ item name=Guide (Current) - href=http://jakarta.apache.org/commons/digester/commons-digester-1.6/apidocs/org/apache/commons/digester/package-summary.html/ + href=http://jakarta.apache.org/commons/digester/apidocs/org/apache/commons/digester/package-summary.html/ /menu menu name=Release Documentation item name=Digester 1.6 -href=/index.html/ + href=http://jakarta.apache.org/commons/digester/commons-digester-1.6/docs/api/org/apache/commons/digester/package-summary.html/ item name=Digester 1.5 href=http://jakarta.apache.org/commons/digester/commons-digester-1.5/docs/api/ /menu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31838] - [Digester] Guide (Current) link on home page is broken
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=31838. 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=31838 [Digester] Guide (Current) link on home page is broken [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-10-26 21:55 --- Fix committed. Many thanks for the spot 8-) Robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/jelly/src/java/org/apache/commons/jelly/test - New directory
dion2004/10/26 16:54:35 jakarta-commons/jelly/src/java/org/apache/commons/jelly/test - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/jelly/jelly-tags/swing project.xml
dion2004/10/26 16:54:37 Modified:jelly/src/test/org/apache/commons/jelly/core TestFileTag.java TestUseBeanTag.java TestForEachTag.java TestInvokeStaticTag.java TestInvokeTag.java TestSwitchTag.java TestChooseTag.java TestBreakTag.java TestNewTag.java TestGetStaticTag.java TestArgTag.java jellyproject.xml jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing TestSwingTags.java jelly/jelly-tags/swing project.xml Added: jelly/src/java/org/apache/commons/jelly/test BaseJellyTest.java Removed: jelly/src/test/org/apache/commons/jelly/core BaseJellyTest.java Log: Jelly-159 - Share BaseJellyTest class Revision ChangesPath 1.7 +2 -1 jakarta-commons/jelly/src/test/org/apache/commons/jelly/core/TestFileTag.java Index: TestFileTag.java === RCS file: /home/cvs/jakarta-commons/jelly/src/test/org/apache/commons/jelly/core/TestFileTag.java,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- TestFileTag.java 9 Sep 2004 12:29:35 - 1.6 +++ TestFileTag.java 26 Oct 2004 23:54:37 - 1.7 @@ -21,6 +21,7 @@ import org.apache.commons.jelly.Script; import org.apache.commons.jelly.XMLOutput; +import org.apache.commons.jelly.test.BaseJellyTest; import org.dom4j.io.HTMLWriter; import org.dom4j.io.OutputFormat; import org.dom4j.io.XMLWriter; 1.6 +1 -0 jakarta-commons/jelly/src/test/org/apache/commons/jelly/core/TestUseBeanTag.java Index: TestUseBeanTag.java === RCS file: /home/cvs/jakarta-commons/jelly/src/test/org/apache/commons/jelly/core/TestUseBeanTag.java,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- TestUseBeanTag.java 9 Sep 2004 12:29:35 - 1.5 +++ TestUseBeanTag.java 26 Oct 2004 23:54:37 - 1.6 @@ -18,6 +18,7 @@ import junit.framework.TestSuite; import org.apache.commons.jelly.Script; +import org.apache.commons.jelly.test.BaseJellyTest; /** * Tests for UseBean tag 1.2 +2 -1 jakarta-commons/jelly/src/test/org/apache/commons/jelly/core/TestForEachTag.java Index: TestForEachTag.java === RCS file: /home/cvs/jakarta-commons/jelly/src/test/org/apache/commons/jelly/core/TestForEachTag.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- TestForEachTag.java 18 Oct 2004 05:45:28 - 1.1 +++ TestForEachTag.java 26 Oct 2004 23:54:37 - 1.2 @@ -18,6 +18,7 @@ import junit.framework.TestSuite; import org.apache.commons.jelly.Script; +import org.apache.commons.jelly.test.BaseJellyTest; import org.apache.commons.lang.StringUtils; /** 1.9 +2 -1 jakarta-commons/jelly/src/test/org/apache/commons/jelly/core/TestInvokeStaticTag.java Index: TestInvokeStaticTag.java === RCS file: /home/cvs/jakarta-commons/jelly/src/test/org/apache/commons/jelly/core/TestInvokeStaticTag.java,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- TestInvokeStaticTag.java 8 Sep 2004 04:36:52 - 1.8 +++ TestInvokeStaticTag.java 26 Oct 2004 23:54:37 - 1.9 @@ -19,6 +19,7 @@ import org.apache.commons.jelly.JellyException; import org.apache.commons.jelly.Script; +import org.apache.commons.jelly.test.BaseJellyTest; /** * @author a href=mailto:[EMAIL PROTECTED]Robert McIntosh/a 1.9 +2 -1 jakarta-commons/jelly/src/test/org/apache/commons/jelly/core/TestInvokeTag.java Index: TestInvokeTag.java === RCS file: /home/cvs/jakarta-commons/jelly/src/test/org/apache/commons/jelly/core/TestInvokeTag.java,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- TestInvokeTag.java8 Sep 2004 04:36:52 - 1.8 +++ TestInvokeTag.java26 Oct 2004 23:54:37 - 1.9 @@ -20,6 +20,7 @@ import org.apache.commons.jelly.JellyException; import org.apache.commons.jelly.Script; import org.apache.commons.jelly.core.Customer; +import org.apache.commons.jelly.test.BaseJellyTest; /** * @author Rodney Waldhoff 1.9 +2 -1 jakarta-commons/jelly/src/test/org/apache/commons/jelly/core/TestSwitchTag.java Index: TestSwitchTag.java === RCS file:
[jira] Resolved: (JELLY-159) share base test classes with tag lib test builds
[ http://issues.apache.org/jira/browse/JELLY-159?page=history ] dion gillard resolved JELLY-159: Resolution: Fixed Fix Version: 1.0 Done. share base test classes with tag lib test builds Key: JELLY-159 URL: http://issues.apache.org/jira/browse/JELLY-159 Project: jelly Type: Improvement Components: core / taglib.core Versions: 1.0 Reporter: Hans Gilde Priority: Minor Fix For: 1.0 Base test classes like BaseJellyTest aren't shareable, so we have several versions of the same classes. I don't know if these classes should go in core or if the build should be updated to share the core test clases. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-148) Huge memory leak resulting from the use of ThreadLocal
[ http://issues.apache.org/jira/browse/JELLY-148?page=history ] dion gillard updated JELLY-148: --- Fix Version: 1.0 Moved to 1.0 release Huge memory leak resulting from the use of ThreadLocal -- Key: JELLY-148 URL: http://issues.apache.org/jira/browse/JELLY-148 Project: jelly Type: Bug Components: core / taglib.core Versions: 1.0 Reporter: Hans Gilde Priority: Critical Fix For: 1.0 Attachments: jelly-nothreadlocal.ZIP, jelly-nothreadlocal2.ZIP, memory-leak-junit-test.txt, thread-local-memory-leak-fix-demo-parent.txt, thread-local-memory-leak-fix-demo.txt, thread-local-memory-leak-fix-final-1.txt, thread-local-memory-leak-fix-final-xml-tags.txt, thread-local-memory-leak-fix-final.txt, thread-local-memory-leak-profile.zip, thread-local-memory-leak.zip There is a huge memory leak that results from the TagScript's use of ThreadLocal. ThreadLocal is usually used from a staic variable, while TagScript uses it from an instance variable. Although this looks legal to me, it causes a huge memory leak. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project commons-jelly-tags-util (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-util 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) - commons-jelly-tags-util : This is a set of Jelly utility tags. - maven-bootstrap : Project Management Tools Full details are available at: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-util/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-util-26102004.jar] identifier set to project name -INFO- Failed with reason build failed -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-util/gump_work/build_jelly-tags_commons-jelly-tags-util.html Work Name: build_jelly-tags_commons-jelly-tags-util (Type: Build) Work ended in a state of : Failed Elapsed: 2 secs Command Line: java -Djava.awt.headless=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=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dfinal.name=commons-jelly-tags-util-26102004 jar [Working Directory: /usr/local/gump/public/workspace/jelly-tags/util] CLASSPATH : /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jelly-tags/util/target/classes:/usr/local/gump/public/workspace/jelly-tags/util/target/test-classes:/usr/local/gump/public/workspace/jakarta-commons/jelly/target/commons-jelly-26102004.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-26102004.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-26102004.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-26102004.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-26102004.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/jelly-tags/junit/target/commons-jelly-tags-junit-26102004.jar - Buildfile: build.xml init: [mkdir] Created dir: /usr/local/gump/public/workspace/jelly-tags/util/target/lib get-deps: compile: [mkdir] Created dir: /usr/local/gump/public/workspace/jelly-tags/util/target/classes [javac] Compiling 9 source files to /usr/local/gump/public/workspace/jelly-tags/util/target/classes [javac] /usr/local/gump/public/workspace/jelly-tags/util/src/java/org/apache/commons/jelly/tags/util/SortTag.java:23: cannot resolve symbol [javac] symbol : class BeanComparator [javac] location: package beanutils [javac] import org.apache.commons.beanutils.BeanComparator; [javac] ^ [javac] /usr/local/gump/public/workspace/jelly-tags/util/src/java/org/apache/commons/jelly/tags/util/SortTag.java:56: cannot resolve symbol [javac] symbol : class BeanComparator [javac] location: class
[jelly] interim release for testing memory use?
We're not entirely sure if the big memory leak is gone, how about an interim release for Servlet users to test? Hans
[OT] gmail invites
They are all gone now... thx for your interest. Glad to be able to help :-) Regards, Corey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31901] - [email] further improvements to test code and removal of emails validation
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=31901. 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=31901 [email] further improvements to test code and removal of emails validation --- Additional Comments From [EMAIL PROTECTED] 2004-10-27 04:39 --- Created an attachment (id=13231) this patch is cumlative of all other recently submitted patches - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31901] - [email] further improvements to test code and removal of emails validation
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=31901. 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=31901 [email] further improvements to test code and removal of emails validation --- Additional Comments From [EMAIL PROTECTED] 2004-10-27 04:41 --- there was something wrong with the previously posted patches submitted for this and the style only bug. I have regenerated the patch and tested applying it, it all appears to work this time. I am not sure what was causing the problems with this before but I hope it is fixed now. Sorry for any inconvenence caused. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] Any reason why JNDIConfiguration is readonly?
Hmm, navigating through a tree based on a configuration key, creating missing nodes if necessary and finally storing the value... Similar code is contained in HierarchicalConfiguration and I suppose in XMLConfiguration, too, to update the internally used DOM tree. I wonder if this could be generalized. Oliver Eric Pugh wrote: Well.. I started on the bind/rebind stuff. and am having a really hard time of it... I can bind a property like this newprop just fine.. However, a property like my.newprop fails.. I think I need to crawl the tree and find the correct context and then set that... argh.. I don't just want to save in a temporary storage because I want to be able to persist via JNDI configuration changes. Eric -Original Message- From: Emmanuel Bourg [mailto:[EMAIL PROTECTED] Sent: Monday, October 25, 2004 5:54 PM To: Jakarta Commons Developers List Subject: Re: [configuration] Any reason why JNDIConfiguration is readonly? Eric Pugh wrote: Anyone have a good reason whe JNDIConfiguration doesn't support setting properties? I was thinking of going for just a simple string storing of properties, not binding in Datasources or anything funky like that... Eric How to you plan to implement this ? By playing with the bind/rebind/unbind functions of the Context interface, or by storing the new properties into a Map ? Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
