RE: Redirect - getX() vs getX(Mail) - was Special MailAddresses

[Vincenzo Gianferrari Pini <vi...@praxis.it>]

Very good. I'll start following this path and see on the road if there are surprises.
In the next few days I'll be erratically busy visiting customers but I will try to keep in touch with the list and follow it. If you don't hear from me don't worry ;-), I'll do this job.

I have two observations:

1) Usage of null.
Looking at the current code in service(Mail), when a getX() returns null it simply means that it will be ignored. Just the usage of getSender() seems to be an exception, instead it still means "ignore it, and use the message's FROM header". In general it seems to mean:
"Redirect is a Forward with no changes; if getX() !=null, change things related to X".

I would make this a documented convention for overriding getX() and getX(Mail).

2) getX(Mail) and setX(Mail, Tx).
I think that we need thread safe local variables, initialized for each Mail object at the beginning of service(Mail) using the instance variables both in the static and in the dynamic cases). All the get getX(Mail) and setX(Mail, Tx) should be able to access all of them (I've already seen such need).
An approach could be to have a new Redirection object, allocated for each mail at the beginning of service(Mail), that holds such local variables as his instance variables.
Then the setX and getX could become getX(Mail, Redirection) and setX(Mail, Redirection). The Redirection class would have simple setters and getters (is a javabean), and could even have a public method Redirection.service(Mail) that is invoked in Redirect.service(Mail) to do the job, and it could be used also in other parts of the James code: maximum flexibility.

Bye

Vincenzo

> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: martedì 20 maggio 2003 5.32
> To: James Developers List
> Subject: RE: Redirect - Special MailAddresses
> 
> 
> Vincenzo,
> 
> I was coming to see the same problem this afternoon.  Danny just 
> expressed a
> major insight regarding his intent for the methods, and it makes 
> sense: the
> methods are only for static values.  How could they be used for
> message-related values if they don't have access to the message?
> 
> I agree with your thought to add getX(Mail) methods for each of 
> the dynamic
> values.  The way I believe that I would use them would be something like:
> 
>   init {
>     if (isStatic) {
>       this.x = getX();  // the one and only value of x
>       ...
>     }
>   }
> 
>    // return a real value, null, or [new] one of the IDENTITIES
>   getX() {
>     String s = getInitParameter("X");
>     ...
>     return ... ;
>   }
> 
>   // return the static value, or map from IDENTITY to value
>   getX(Mail mail) {
>     MailAddress x = (isStatic) ? this.x : getX();
>     if (x == null || getX() == SpecialAddresses.SENDER) {
>       x = ... ;
>     } else if (getSender() == SpecialAddresses. ...) {
>       x = ... ;
>     } else if ... {
>       x = ... ;
>     }
>     return x;
>   }
> 
>   // set the provided value, or perform IDENTITY action
>   setX(Mail mail, Tx x) {
>      if (x == SpecialAddresses.DELETE) {
>       remove x;
>     } else if (getSender() == SpecialAddresses.NULL) {
>       ... ;
>     } else if ... {
>       ... ;
>     }
>   }
> 
>   service(Mail mail) {
>   ...
>     setX(Mail, getX(Mail));
>   ...
>   }
> 
> The getX() methods return either a static value or one of the special
> addresses, the getX(Mail) addresses handle the dynamic processing, finally
> the setX(Mail, Tx x) methods know how to do that change.  That moves the
> dynamic processing out from the main code, and makes it clearer, too, and
> also overloadable.  This addresses the thread safety issue, and I believe
> that it also addresses most of, if not all of, the problem with invalid
> static configurations.  Finally, it allows a subclass to impact static
> behavior, permitting it to treat some values as static, and others as
> dynamic.
> 
> Yes, it adds a lot of new methods, but it also shrinks service()
> considerably, mostly be re-factoring, makes it more customizable and
> maintainable.
> 
> Unless I am missing something, that change should remain perfectly
> compatible with subclasses of the current Redirect, since they 
> can currently
> only return a real value, or null.  But it permits new behavior based upon
> the identity checks and customizing the accessors & mutators.
> 
> How does this work for you, Vincenzo?  Danny?  Serge?  Others?
> 
> 	--- Noel
> 


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

RE: Redirect - getX() vs getX(Mail) - was Special MailAddresses

["Noel J. Bergman" <no...@devtech.com>]

Vincenzo,

>  2) getX(Mail) and setX(Mail, Tx).
>  I think that we need thread safe local variables, initialized
>  for each Mail object at the beginning of service(Mail) using
>  the instance variables both in the static and in the dynamic
>  cases). All the get getX(Mail) and setX(Mail, Tx) should be
>  able to access all of them (I've already seen such need).

Can you illustrate why you think so?  If you use the setX(reply,
getX(message)) pattern, then there is no local value.  If you need to in
some case, you could do:

    Tx x = getX(message);
    setX(reply, x);

but I'm not spotting a general need for shared local values.

	--- Noel


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