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]
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]
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: 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: 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]
