interesting aspect to have a RPC-mailet. maybe this could be done with a
more generic approach: a mailet which takes as configuration parameters
a. a jar (hessian.jar, activemq.jar, whatever is neccessary) which it
loads on its own
and
b. a class contained within the jar which is instantiated by the mailet
this class has all the logic to send the mail from the mailet to the
remote service.
plusses:
there would be no explicit dependency on build time.
it would be open to any service.
...but maybe this is just over-engeneering ;-)
Bernd
Serge Knystautas wrote:
On 4/19/06, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
it introduces another dependency.
I'd rather not introduce that dependency. HOWEVER, we have been talking
about the fact that we have much better support for multiple Mailet
packages, and I would be +1 to add this to an OPTIONAL mailet package. Just
not the standard mailet package. Fair enough?
I'll get some examples together on the wiki next week.
I was looking at the method call, and realized that Mailet's
service(Mail) is probably the most appropriate. I noticed then that
the remaining methods are all related to lifecycle/configuration and
potentially would get removed down the road. Same thing with the
Matcher interface.
This seemed interesting to me because it could make James very
distributed... use this to create remote matchers and mailets, either
to run business logic, or to transfer a Mail in a spool on one server
to a spool on another server.
--
Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. [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]
