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]
