Mailet changes (Was: 2.3.x vs trunk)

[Stefano Bagnara <ap...@bago.org>]

Noel J. Bergman ha scritto:
> Robert Burrell Donkin wrote:
>> i think that moving the mailets into a separate project should make
>> things move managable.
> 
> In the long run, I agree.  Even in the mid-term, we can compare the Mailets
> in the new project with those in the release, and validate the changes.

I agree this should be done. We have a mailet project and changes 
between mailet v2.3 and current trunk mailet are minor.

>> a single consolidated library can used for both 2.x and 3.x releases (as
> well as trunk).
> 
> We'll may have to make some changes to allow that, since people didn't treat
> the code in a manner that would ensure this simple statement.  This would be
> another benefit from your proposal.  Separating the Mailet library from the
> server would discourage people from changing them in lockstep.

"people didn't treat the code.... "? Whom? What changes?

Every single change we did in trunk mailets has been discussed in the 
mailing list. Most changes we did from 2.2.0 to 2.3.0 was to make sure 
some JAMES specific mailets could be made generic mailets (e.g: we moved 
some method from MailImpl to Mail in order to remove every cast to 
MailImpl in mailets).

Here is instead a list of changes between mailet released in 2.3.0 and 
current mailet trunk code:

GenericMailet
- altered default logging to include mailet name
+ added checkInitParameters and arrayToString methods

GenericMatcher
- altered default logging to include mailet name

MailAddress
- constructor throws AddressException instead of ParseException
- other changes by danny:
   http://svn.apache.org/viewvc?view=rev&revision=565772
   http://issues.apache.org/jira/browse/MAILET-7

MailetContext
- isLocalUser now expect a full email address. if no @ is there then 
@localhost is appended for the check.
+ added isLocalEmail

As you can see changes are very limited and maybe the only issue that 
should be better checked is the MailAddress compatibility. Every other 
change since 2.3.0 seems to be backward compatible (I would say both 
binary and source compatible)

> That said, we want to be able to evolve the Mailet API, in a controlled and
> proper manner.
> 
> 	--- Noel

+1

we created mailet-api@ list, the mailet svn tree and the mailet jira 
because of this.
Feel free to use one of this tools in order to discuss about your 
specific concerns about current mailet sources!

I cross post to mailet-api so we can continue there.

Stefano


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org