You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Serge Sozonoff <se...@globalbeach.com> on 2003/01/27 11:17:23 UTC
Mailet Configuration
Hi Guys,
Continuing on with my BounceHandler mailet idea, I would need to do
something like this in my configuration block for my mailet
<mailet match="RecipientIs=test1@localhost" class="BounceHandler">
<bounceHandlers>
<bounceHandler class="DSNBounce"/>
<bounceHandler class=".........."/>
</bounceHandlers>
<bounceProcessors>
<bounceProcessor class="DBBounceProcessor">
<database>.....</database>
<....>...</...>
<bounceProcessor>
</bounceProcessors>
</mailet>
However the mailet API does not give me access to this sort of thing and I
have not figured out if I can gain access directly to the James
Configuration object from my Mailet. I think not.
As a temporary work around I could do something like this:
<mailet match="RecipientIs=test1@localhost" class="BounceHandler">
<bounceHandlers>class=DSNBounce;class=QmailBounce;class=etc</bounceHandlers>
<bounceProcessors>name=DBBounceProcessor;database=......</bounceProcessors>
</mailet>
But this is not very elegent and idealy I would at the very minimum need to
pass additional config parameters to the bounceProcessors.
Anyone have any ideas, suggestions?
Thanks,
Sergei
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Configuration Subsystem (was Mailet Configuration)
Posted by Serge Knystautas <se...@lokitech.com>.
Aaron Knauf wrote:
> I disagree, but rather than go into the why's and wherefore's here, I
> will finish off the UML that I am working on to ensure that we are not
> just misunderstanding each other. I will however, say this:
>
> I think that access to some form of structured config for mailets is
> important.
>
> Plugability of config implementations is not something that needs to be
> reflected directly in the Mailet API, but can be a value add for a
> particular container implementation. (Like ours!)
Ok sure, just as long as it's not in the mailet API or specification,
that's cool with me.
> Dynamic reconfiguration must be supported by the configuration subsystem
> if it is to exist at all. Someone listed this item on the wiki as being
> a desirable for V3. It is quite a lot simpler not to do it.
Yes, I think dynamic reconfiguration is a must.
> IMHO, the key to doing this successfully is to provide a system that is
> simple by default, but powerful for those that wish to put in the effort
> and dig a little deeper. Log4J is an excellent example of this concept.
> It takes a 4 line config file and single line of code to get basic
> logging to work. However, if you want more, you can make your logs get
> up and make coffee!
I agree, and I think your log4j reference is a good example of what I'm
shooting for... let the application developer do whatever he or she
wants using all the options available with Java. I'm just looking to
provide rules for a mailet container, i.e., how you could write some
Java to process email messages. This doesn't need to (and shouldn't
IMHO) include much about logging, databases, configuration, etc...
So I like to keep it lightweight and focused on the specific problem of
email processing. Also when in doubt about the appropriate level of
complexity, I tend to fall back on whatever the servlet API deemed
appropriate. Servlet apps haven't shown much limitations with that API
(either too advanced or too lightweight), and it's fostered numerous
implementations.
So for the sake of Mailet API and specification, if in doubt, leave it
out. Then figure out a way how a specific mailet container like James
could offer the necessary features on its own.
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Configuration Subsystem (was Mailet Configuration)
Posted by Aaron Knauf <ak...@xtra.co.nz>.
Serge Knystautas wrote:
>----- Original Message -----
>From: "Aaron Knauf" <ak...@xtra.co.nz>
>
>
>
>>Hi Danny,
>>
>>The format you suggest certainly allows for multiple matchers and better
>>matcher configuration. However, it still leaves us with unstructured
>>name/value pairs. There have been a number of requests for structured
>>mailet configuration.
>>
>>
>
>
>I don't think the level of configuration you're proposing needs to be
>included as part of the mailet container. IMO, the container should load an
>application, and if the application has complex configuration, the
>application should handle configuring itself. I think many of your
>suggestions unnecessarily raise the bar for mailet container implementations
>and is looking for more than just a container.
>
>
I disagree, but rather than go into the why's and wherefore's here, I
will finish off the UML that I am working on to ensure that we are not
just misunderstanding each other. I will however, say this:
I think that access to some form of structured config for mailets is
important.
Plugability of config implementations is not something that needs to be
reflected directly in the Mailet API, but can be a value add for a
particular container implementation. (Like ours!)
Dynamic reconfiguration must be supported by the configuration subsystem
if it is to exist at all. Someone listed this item on the wiki as being
a desirable for V3. It is quite a lot simpler not to do it.
IMHO, the key to doing this successfully is to provide a system that is
simple by default, but powerful for those that wish to put in the effort
and dig a little deeper. Log4J is an excellent example of this concept.
It takes a 4 line config file and single line of code to get basic
logging to work. However, if you want more, you can make your logs get
up and make coffee!
Cheers
ADK
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Configuration Subsystem (was Mailet Configuration)
Posted by Serge Knystautas <se...@lokitech.com>.
----- Original Message -----
From: "Aaron Knauf" <ak...@xtra.co.nz>
> Hi Danny,
>
> The format you suggest certainly allows for multiple matchers and better
> matcher configuration. However, it still leaves us with unstructured
> name/value pairs. There have been a number of requests for structured
> mailet configuration.
I don't think the level of configuration you're proposing needs to be
included as part of the mailet container. IMO, the container should load an
application, and if the application has complex configuration, the
application should handle configuring itself. I think many of your
suggestions unnecessarily raise the bar for mailet container implementations
and is looking for more than just a container.
I think name-value pairs are a good addition to matchers, and I think it
would be good to have a way to reference files bundled with the mailet
classes (as part of the application files), either with getResource() or
maybe getRealPath(), something along those lines.
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 1.301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Configuration Subsystem (was Mailet Configuration)
Posted by Aaron Knauf <ak...@xtra.co.nz>.
Stephen McConnell wrote:
>>
>> Hmmmm. I am not sure that I fully follow what you are saying here,
>> but I believe I have the gist of it. When I initially looked into
>> the Avalon configuration subsystem, I was disappointed to find that
>> we are forced into a quite sizeable Configuration interface for
>> configurating our Configurables. Further, this interface exposed
>> XML-specific namespace stuff to the Configurable, when (IMHO) that
>> ought to be an implementation detail used by the parser when reading
>> the config.xml and creating the Configuration impl.
>
>
>
> I'm not familiar with the XML-specific namespace stuff - but I do know
> the there is broad support for the Configuration interface. It is
> simply really really nice to work with. If the Mailet API comes up
> with something new - I really hope it looks and smells like the Avalon
> Configuration interface.
I don't have anything against the Configuration interface per se. As a
generic way of providing access to configuration data it is great. I
do, however have two issues with it:
1) If the author of a particular Configurable wants to go to the effort
of providing a custom Configuration object, he is likely to want to
provide accessors like: getMyAttribute() rather than
getAttribute("myAttribute"). It would be good if he could implement an
interface higher up the inheritence tree that didn't force him to expose
the getAttribute("myAttribute") interface when he wasn't going to use
it. In cases where a given Configuration implementation was re-used by
many Configurables, possibly written by different authors, providing
getMyAttribute() rather than getAttribute("myAttribute") provides a
compile time defence against typos spelling "myAtribute".
2) The namespace thing, as mentioned before, is a technical detail that
only the parser should be concerned with. If a particular Configuration
author want's to expose it for some special reason, fine, he can add the
method to his implementation class. The trouble is that (IMHO) most
Configuration authors are going to want to encapsulate the namespace as
an implementation detail that the Configurable should have no knowledge
of. In Avalon, it is impossible to encapsulate this because the
interface forces you to expose it. (Throwing
UnsupportedOperationException is always ugly.)
If the getNamespace() method were removed entirely, I would be quite happy.
If the various getX(String name) methods were moved to a
subclass/subinterface, (maybe StandardConfiguration,) allowing me to
slot in configurations that exposed their own accessors, I would be
ecstatic.
Cheers
ADK
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Configuration Subsystem (was Mailet Configuration)
Posted by Stephen McConnell <mc...@apache.org>.
Aaron Knauf wrote:
>
>
> Stephen McConnell wrote:
>
>>
>>
>> Aaron Knauf wrote:
>>
>>> I have an idea for addressing this that needs some work, but
>>> basically it goes like this:
>>> Implement the configuration as an Avalon block. (I think this is
>>> the right term, but I am not too familiar with Avalon, so bear with
>>> me.) This block would basically manage the loading and parsing of
>>> configurations from any datasource that you want to write a plugin
>>> for. Components will obtain their configuration from this block.
>>
>>
>>
>> Hi Aaron:
>>
>> I read you email with interest. Concerning the above paragraph - I
>> think it would be preferable for the James system to be acting a
>> mailet container and following IOC principals. This means that the
>> container figures out what the mailet needs, pulls it together, and
>> supplies it to the mailet. I.e. the mailet does not need to be
>> concerned with "obtaining" the things it needs - instead - it gets
>> supplied everything it needs.
>
>
>
> Oh, I agree completely. I guess I wasn't clear on this point. I
> expect that the MailetLoader would be the thing parsing the config the
> Mailet configs and handing them to the mailets. Also, the plugin
> parsers would be called by the configuration manager and handed just
> the part of the config that they are responsible for.
>
> As a matter of fact, I had to learn the hard way the benefits of IOC
> while implementing the config subsystem for my recent project. I was
> unable to use IOC because I was stuck with an existing server
> implementation that had static getConfig().getThis() and
> getConfig().getThat() calls all over the place. Making the thing
> re-initialise certain components when the config changed was a nightmare.
>
>
>>
>>
>>
>>>
>>> A question: should we hook heavily in to Avalon with this thing, or
>>> should we make it something more portable, that can be used outside
>>> of Avalon?
>>
>>
>>
>>
>> I think there are separate concerns relating to the Mailet API versus
>> the container implementation approach. From everything I've seen
>> here the principal is to keep the mailet API as free of dependencies
>> as possible.
>
>
> This question was never intended to suggest that Avalon APIs might
> make an appearance in the Mailet API. There needs to be a clear
> delineation between the portable container API and the non-portable
> container implementation.
>
> What I really meant was do we make this whole configuration manager
> thing another james component, so that the James container
> implementation could hook into it without going through Avalon, or do
> we hook in to all of the Avalon APIs that I am sure I will find
> enticing along the way? This is all behind that Mailet abstraction
> layer.
>
>> The other side of that coin is that you end up falling back to the
>> lowest common denominator. The approach I'm working on is to enable
>> components (e.g. mailets) to declare a strategy to the container
>> (e.g. James) ... i.e. the mailet declares that it is using interface
>> Xxxxx for configuration and the container simply takes care of this
>> by selecting and applying an appropriate handler. This means I can
>> write a mailet that uses a Servelt configuration model, or the Avalon
>> Configurable interface, or a Mailet special, or whatever. The mailet
>> API remains independent - but I (as a mailet author) can leverage the
>> technologies I want.
>
>
> Hmmmm. I am not sure that I fully follow what you are saying here,
> but I believe I have the gist of it. When I initially looked into the
> Avalon configuration subsystem, I was disappointed to find that we are
> forced into a quite sizeable Configuration interface for configurating
> our Configurables. Further, this interface exposed XML-specific
> namespace stuff to the Configurable, when (IMHO) that ought to be an
> implementation detail used by the parser when reading the config.xml
> and creating the Configuration impl.
I'm not familiar with the XML-specific namespace stuff - but I do know
the there is broad support for the Configuration interface. It is
simply really really nice to work with. If the Mailet API comes up with
something new - I really hope it looks and smells like the Avalon
Configuration interface.
> If you are suggesting that Configurables might be able to get fed an
> arbitrary configuration object in future, (possibly implementing a
> smaller interface to allow the framework to handle it,) then that is
> great news.
I'm suggesting that a component (using information declared in meta
data) declares what its configuration contract is. The container simply
resolves that depedency. Keep in mind that this direction is much more a
Merlin specific thing - but on the other hand the Avalon peeps are
actively discussing such radical stuff over on avalon-dev.
> Perhaps you might consider my proposed configuration manager as an
> implementation for driving this?
Consider it as considered. If you make this a component (Phoenix Block)
it will automatically work in Merlin.
> If so, I would suggest that -
> a) The configuration manager have a clear interface whose
> implementation could be substituted for another
> b) Perhaps my configuration manager proposal is something that
> belongs in Avalon, rather than being specific to James?
Maybe - its just happens to be something I was thinking about in
relation to Merlin acoule of weeks ago.
>>
>>
>> Aside from the IOC issue - a pluggable configuration provider is
>> definitely something I would be interested in seeing and using.
>
>
> Then keep an eye on this list. I will post some UML before I begin
> coding. I would appreciate any feedback you might be able to give.
I will (just make sure the message title is descriptive or I could miss it).
Cheers, Steve.
>
>
> Cheers
>
> ADK
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Configuration Subsystem (was Mailet Configuration)
Posted by Aaron Knauf <ak...@xtra.co.nz>.
Stephen McConnell wrote:
>
>
> Aaron Knauf wrote:
>
>> I have an idea for addressing this that needs some work, but
>> basically it goes like this:
>> Implement the configuration as an Avalon block. (I think this is the
>> right term, but I am not too familiar with Avalon, so bear with me.)
>> This block would basically manage the loading and parsing of
>> configurations from any datasource that you want to write a plugin
>> for. Components will obtain their configuration from this block.
>
>
> Hi Aaron:
>
> I read you email with interest. Concerning the above paragraph - I
> think it would be preferable for the James system to be acting a
> mailet container and following IOC principals. This means that the
> container figures out what the mailet needs, pulls it together, and
> supplies it to the mailet. I.e. the mailet does not need to be
> concerned with "obtaining" the things it needs - instead - it gets
> supplied everything it needs.
Oh, I agree completely. I guess I wasn't clear on this point. I expect
that the MailetLoader would be the thing parsing the config the Mailet
configs and handing them to the mailets. Also, the plugin parsers would
be called by the configuration manager and handed just the part of the
config that they are responsible for.
As a matter of fact, I had to learn the hard way the benefits of IOC
while implementing the config subsystem for my recent project. I was
unable to use IOC because I was stuck with an existing server
implementation that had static getConfig().getThis() and
getConfig().getThat() calls all over the place. Making the thing
re-initialise certain components when the config changed was a nightmare.
>
>
>
>>
>> A question: should we hook heavily in to Avalon with this thing, or
>> should we make it something more portable, that can be used outside
>> of Avalon?
>
>
>
> I think there are separate concerns relating to the Mailet API versus
> the container implementation approach. From everything I've seen here
> the principal is to keep the mailet API as free of dependencies as
> possible.
This question was never intended to suggest that Avalon APIs might make
an appearance in the Mailet API. There needs to be a clear delineation
between the portable container API and the non-portable container
implementation.
What I really meant was do we make this whole configuration manager
thing another james component, so that the James container
implementation could hook into it without going through Avalon, or do we
hook in to all of the Avalon APIs that I am sure I will find enticing
along the way? This is all behind that Mailet abstraction layer.
> The other side of that coin is that you end up falling back to the
> lowest common denominator. The approach I'm working on is to enable
> components (e.g. mailets) to declare a strategy to the container (e.g.
> James) ... i.e. the mailet declares that it is using interface Xxxxx
> for configuration and the container simply takes care of this by
> selecting and applying an appropriate handler. This means I can write
> a mailet that uses a Servelt configuration model, or the Avalon
> Configurable interface, or a Mailet special, or whatever. The mailet
> API remains independent - but I (as a mailet author) can leverage the
> technologies I want.
Hmmmm. I am not sure that I fully follow what you are saying here, but
I believe I have the gist of it. When I initially looked into the
Avalon configuration subsystem, I was disappointed to find that we are
forced into a quite sizeable Configuration interface for configurating
our Configurables. Further, this interface exposed XML-specific
namespace stuff to the Configurable, when (IMHO) that ought to be an
implementation detail used by the parser when reading the config.xml and
creating the Configuration impl.
If you are suggesting that Configurables might be able to get fed an
arbitrary configuration object in future, (possibly implementing a
smaller interface to allow the framework to handle it,) then that is
great news. Perhaps you might consider my proposed configuration
manager as an implementation for driving this? If so, I would suggest
that -
a) The configuration manager have a clear interface whose
implementation could be substituted for another
b) Perhaps my configuration manager proposal is something that
belongs in Avalon, rather than being specific to James?
>
>
> Aside from the IOC issue - a pluggable configuration provider is
> definitely something I would be interested in seeing and using.
Then keep an eye on this list. I will post some UML before I begin
coding. I would appreciate any feedback you might be able to give.
Cheers
ADK
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Configuration Subsystem (was Mailet Configuration)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I think it would be preferable for the James system to be acting a mailet
> container and following IOC principals.
> the mailet does not need to be concerned with "obtaining"
> the things it needs - instead - it gets supplied everything
> it needs.
I understand your view. There are good arguments both ways. At the moment,
the Mailet API design is not based upon IoC; it models J2EE, and is pull
oriented rather than push oriented. I don't expect that to change in the
Mailet API, although it would be possible for James to provide additional
lifecycle methods if a matcher or mailet supported them.
> Aside from the IOC issue - a pluggable configuration provider is
> definitely something I would be interested in seeing and using.
My proposal to Aaron supports that pluggable provider where needed. As
proposed it follows the J2EE pattern, although if everyone decided to change
the Mailet API to use IoC, the same basic strategy applies. It is just a
matter of how you get the resource.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Configuration Subsystem (was Mailet Configuration)
Posted by Stephen McConnell <mc...@apache.org>.
Aaron Knauf wrote:
> I have an idea for addressing this that needs some work, but basically
> it goes like this:
> Implement the configuration as an Avalon block. (I think this is the
> right term, but I am not too familiar with Avalon, so bear with me.)
> This block would basically manage the loading and parsing of
> configurations from any datasource that you want to write a plugin
> for. Components will obtain their configuration from this block.
Hi Aaron:
I read you email with interest. Concerning the above paragraph - I
think it would be preferable for the James system to be acting a mailet
container and following IOC principals. This means that the container
figures out what the mailet needs, pulls it together, and supplies it to
the mailet. I.e. the mailet does not need to be concerned with
"obtaining" the things it needs - instead - it gets supplied everything
it needs.
>
> A question: should we hook heavily in to Avalon with this thing, or
> should we make it something more portable, that can be used outside of
> Avalon?
I think there are separate concerns relating to the Mailet API versus
the container implementation approach. From everything I've seen here
the principal is to keep the mailet API as free of dependencies as
possible. The other side of that coin is that you end up falling back to
the lowest common denominator. The approach I'm working on is to enable
components (e.g. mailets) to declare a strategy to the container (e.g.
James) ... i.e. the mailet declares that it is using interface Xxxxx for
configuration and the container simply takes care of this by selecting
and applying an appropriate handler. This means I can write a mailet
that uses a Servelt configuration model, or the Avalon Configurable
interface, or a Mailet special, or whatever. The mailet API remains
independent - but I (as a mailet author) can leverage the technologies I
want.
>
> Either way, I would like to use the lastest version of Avalon, to
> avoid being obsolete before I start.
Let me know if you need a hand navigating through all of the Avalon
stuff. You may be interested in checking out the Merlin demos - it has
examples of (a) custom lifecycle strategies, and (b) configuration
separation - i.e. configuration fragments containing sensitive data are
separate from the main configuration. Merlin handles the merging of
these configurations during deployment. The main benefits are two fold:
firstly it enables a very significant simplification of the
configuration overhead for the user, and secondly, allows separation of
sensitive information.
>
> Having just successfully implemented a configuration subsystem (with
> pluggable config sources and dynamic reconfiguration) for our SMS
> server at work, I know that this will not be a trivial undertaking. I
> also have a ton of ideas for how to improve over the last attempt.
> While I am willing to write the code, I do need some indication that I
> am headed in the right direction. Some helpful advice would also be
> handy (as would any other contributions).
> The code would be written for my own interest, but I would like to
> have the satisfaction of seeing it as part of James when it is done.
> This means getting some buyin from the James community along the way,
> so let me know what you think.
Aside from the IOC issue - a pluggable configuration provider is
definitely something I would be interested in seeing and using.
Cheers, Steve.
>
> Cheers
>
> ADK
>
>
>
> Danny Angus wrote:
>
>> Aaron,
>>
>> You wrote:
>>
>>
>>
>>> This subject has come up a few times. I suggested an approach to
>>> handling mailet and matcher config better, as did a few others. I
>>> even offered to write it. However, due to the distinct lack of
>>> enthusiasm for my (or any other) solution, I lost interest. I could
>>> be convinced to revisit this if some of the committers indicated
>>> that they were interested.
>>>
>>
>>
>> Without checking I think that the perceived lack of interest was due
>> to a deferal of these issues to v3.
>> Now that v3 is proceding go ahead with it, I'm indicating that I'm
>> interested and will support your contribution.
>> Check the wiki for others' opinions on this (and other) v3 topics,
>> and post your ideas, or code, here for discussion & inclusion.
>>
>> AFAICR we reached some concensus on the following style.. which would
>> allow us to produce a processor DTD (example attached) and
>> standardise every mailet config.
>> I can't remember what other suggestions/arguments were raised, but
>> you could check the mail archive.
>>
>> <mailet .............>
>> <matcher class="...">
>> <condition>...</condition>
>> <parameters>
>> <parameter name="..."></parameter>
>> <parameter name="..."></parameter>
>> </parameters>
>> </matcher>
>> <matcher class="...">
>> <condition>...</condition>
>> <parameters>
>> <parameter name="..."></parameter>
>> <parameter name="..."></parameter>
>> </parameters>
>> </matcher>
>> <parameters>
>> <parameter name="..."></parameter>
>> <parameter name="..."></parameter>
>> </parameters>
>> </mailet>
>>
>> d.
>>
>>
>> ------------------------------------------------------------------------
>>
>> <!ELEMENT processor (mailet)+>
>> <!ATTLIST processor
>> class CDATA #REQUIRED
>> name CDATA #REQUIRED
>>
>>
>> <!ELEMENT mailet (matcher,parameters)*>
>> <!ATTLIST mailet
>> class CDATA #REQUIRED
>>
>>
>> <!ELEMENT matcher (condition,parameters)*>
>> <!ATTLIST matcher
>> class CDATA #REQUIRED
>>
>>
>> <!ELEMENT condition (#PCDATA)>
>> <!ELEMENT parameters (parameter)+>
>> <!ELEMENT parameter (#PCDATA)>
>> <!ATTLIST parameter
>> name CDATA #REQUIRED
>>
>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>> --
>>> To unsubscribe, e-mail:
>>> <ma...@jakarta.apache.org>
>>> For additional commands, e-mail:
>>> <ma...@jakarta.apache.org>
>>>
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Configuration Subsystem (was Mailet Configuration)
Posted by Aaron Knauf <ak...@xtra.co.nz>.
Hi Danny,
The format you suggest certainly allows for multiple matchers and better
matcher configuration. However, it still leaves us with unstructured
name/value pairs. There have been a number of requests for structured
mailet configuration.
Having just re-read the last configuration thread, I am not sure that a
consensus was reached. Here is the address of the last mailing list
post from our previous discussion on this subject:
http://www.mail-archive.com/james-dev@jakarta.apache.org/msg05485.html
Before I proceed with writing any code, I would like to agree on
A - some requirements
B - an implementation approach
A - Requirements
I would expect that any effort in the configuration area would need to
achieve the following four things:
1) Structured Mailet config.
2) A storage agnostic Mailet config API. The Mailet API should have
no knowledge of the underlying implementation mechanics. It should work
just the same for configuration pulled from a database, an XML file, or
a JNDI tree.
3) Dynamic reconfiguration of processors.
4) I believe rule 1 of API design is to make things as simple and
easy as possible for the client programmer.
I also consider the following requirements to be secondary, but desirable:
* Validation of XML config files against an XSD.
* Dynamic reconfiguration of other components.
B - Implementation
Initially, I would expect to implement these requirements using XML
configuration files. The API should, however, be designed to allow
other config sources to be plugged in. Further, other config sources
should be able to be plugged a granular level. Initially, I suggest
that the granularity be at the level of (a) overall server config, and
(b) individual mailets. So the James server would be configured from a
particular config source, but individual mailets could be configured to
pull their config from differents sources to the James server.
This last item opens the question of what should be the expected
behaviour if a particular mailet's config source is not available when
the server starts?
Both you and Kenny expressed reservations regarding use of namespaces.
I would agree with these reservations if the namespace complexity were
to be exposed in the Mailet API. (That would not only be complex - it
would break abstraction by exposing XML-specific features where the
Mailet config should be source-agnostic.) The advantage I see in using
namespaces internally to james is that it allows us to validate the XML
structure with an XSD, rather than laboriously doing it in code.
Further - if a particular mailet author does not want to use a XSD,
they would not be forced to. They ought to be able to put arbitrary XML
in there and just have that part unvalidated.
Based on the above implementation approach, I think that there needs to
be two APIs defined for configuration:
1) The API used by a Mailet to access its configuration.
2) The API used by plugin config sources to provide configuration to
components that want need it.
These APIs need to be defined.
The trouble is, the Avalon configuration API is rather XML-centric. One
would think that this would make things easier, but it doesn't allow the
flexibility to plug in (e.g.) a RDBMS-based config. It also breaks
abstraction by exposing namespaces to the actual component, (in the
Configuration interface,) when the parser should be the only thing to
care about this kind of detail. I would prefer not to have to implement
the Configuration interface in the new config objects.
I have an idea for addressing this that needs some work, but basically
it goes like this:
Implement the configuration as an Avalon block. (I think this is the
right term, but I am not too familiar with Avalon, so bear with me.)
This block would basically manage the loading and parsing of
configurations from any datasource that you want to write a plugin for.
Components will obtain their configuration from this block.
This could be implemented by plugging a custom configuration parser into
the Avalon config subsystem. The custom parser would read config.xml
far enough to find that component X's config should be obtained from the
Configuration Block and would then switch to using that.
I would want to implement this using a staged approach. First,
individual Mailets could use the Configuration Block by modifying the
MailetLoader to be aware of the block and look for an attribute in the
mailet tag. (No need for the custom avalon config parser, just yet.)
This would let us try out the Configuration Block approach and see if
it is good.
Assuming that the Configuration Block idea turns out to be useful, other
James components could then start using it if it looks like a good idea.
We could then make it a more generic Avalon component thing.
This approach has the advantage that it can be completely backward
compatible. If a mailet tag does not have the necessary flag set, then
the current behaviour applies.
A question: should we hook heavily in to Avalon with this thing, or
should we make it something more portable, that can be used outside of
Avalon?
Either way, I would like to use the lastest version of Avalon, to avoid
being obsolete before I start.
Having just successfully implemented a configuration subsystem (with
pluggable config sources and dynamic reconfiguration) for our SMS server
at work, I know that this will not be a trivial undertaking. I also
have a ton of ideas for how to improve over the last attempt. While I
am willing to write the code, I do need some indication that I am headed
in the right direction. Some helpful advice would also be handy (as
would any other contributions).
The code would be written for my own interest, but I would like to have
the satisfaction of seeing it as part of James when it is done. This
means getting some buyin from the James community along the way, so let
me know what you think.
Cheers
ADK
Danny Angus wrote:
>Aaron,
>
>You wrote:
>
>
>
>>This subject has come up a few times. I suggested an approach to
>>handling mailet and matcher config better, as did a few others. I even
>>offered to write it. However, due to the distinct lack of enthusiasm
>>for my (or any other) solution, I lost interest. I could be convinced
>>to revisit this if some of the committers indicated that they were
>>interested.
>>
>>
>
>Without checking I think that the perceived lack of interest was due to a deferal of these issues to v3.
>Now that v3 is proceding go ahead with it, I'm indicating that I'm interested and will support your contribution.
>Check the wiki for others' opinions on this (and other) v3 topics, and post your ideas, or code, here for discussion & inclusion.
>
>AFAICR we reached some concensus on the following style.. which would allow us to produce a processor DTD (example attached) and standardise every mailet config.
>I can't remember what other suggestions/arguments were raised, but you could check the mail archive.
>
><mailet .............>
> <matcher class="...">
> <condition>...</condition>
> <parameters>
> <parameter name="..."></parameter>
> <parameter name="..."></parameter>
> </parameters>
> </matcher>
> <matcher class="...">
> <condition>...</condition>
> <parameters>
> <parameter name="..."></parameter>
> <parameter name="..."></parameter>
> </parameters>
> </matcher>
> <parameters>
> <parameter name="..."></parameter>
> <parameter name="..."></parameter>
> </parameters>
></mailet>
>
>d.
>
>
>------------------------------------------------------------------------
>
><!ELEMENT processor (mailet)+>
><!ATTLIST processor
> class CDATA #REQUIRED
> name CDATA #REQUIRED
>
>
><!ELEMENT mailet (matcher,parameters)*>
><!ATTLIST mailet
> class CDATA #REQUIRED
>
>
><!ELEMENT matcher (condition,parameters)*>
><!ATTLIST matcher
> class CDATA #REQUIRED
>
>
><!ELEMENT condition (#PCDATA)>
><!ELEMENT parameters (parameter)+>
><!ELEMENT parameter (#PCDATA)>
><!ATTLIST parameter
> name CDATA #REQUIRED
>
>
>>------------------------------------------------------------------------
>>
>>--
>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Mailet Configuration
Posted by Aaron Knauf <ak...@xtra.co.nz>.
I have no current plans to attack this area. I pushed fairly hard for a
more complex approach, because that is the requirement that I have for
mailet projects that I am involved with. My requirement should now be
met by the JNDI stuff that I am working on. The JNDI stuff is also
likely to take up as much spare time as I have available in the short term.
Cheers
ADK
Noel J. Bergman wrote:
>Danny,
>
>Regarding:
>
><mailet .............>
> <matcher class="...">
> <condition>...</condition>
> <parameters>
> <parameter name="..."></parameter>
> <parameter name="..."></parameter>
> </parameters>
> </matcher>
> <matcher class="...">
> <condition>...</condition>
> <parameters>
> <parameter name="..."></parameter>
> <parameter name="..."></parameter>
> </parameters>
> </matcher>
> <parameters>
> <parameter name="..."></parameter>
> <parameter name="..."></parameter>
> </parameters>
></mailet>
>
>I concur that this is the consensus for the Mailet API and config.xml. Is
>this something that you were coding, or Aaron, or ... ?
>
> --- Noel
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: james-dev-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Mailet Configuration
Posted by "Noel J. Bergman" <no...@devtech.com>.
Danny,
Regarding:
<mailet .............>
<matcher class="...">
<condition>...</condition>
<parameters>
<parameter name="..."></parameter>
<parameter name="..."></parameter>
</parameters>
</matcher>
<matcher class="...">
<condition>...</condition>
<parameters>
<parameter name="..."></parameter>
<parameter name="..."></parameter>
</parameters>
</matcher>
<parameters>
<parameter name="..."></parameter>
<parameter name="..."></parameter>
</parameters>
</mailet>
I concur that this is the consensus for the Mailet API and config.xml. Is
this something that you were coding, or Aaron, or ... ?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Mailet Configuration
Posted by Danny Angus <da...@apache.org>.
Aaron,
You wrote:
> This subject has come up a few times. I suggested an approach to
> handling mailet and matcher config better, as did a few others. I even
> offered to write it. However, due to the distinct lack of enthusiasm
> for my (or any other) solution, I lost interest. I could be convinced
> to revisit this if some of the committers indicated that they were
> interested.
Without checking I think that the perceived lack of interest was due to a deferal of these issues to v3.
Now that v3 is proceding go ahead with it, I'm indicating that I'm interested and will support your contribution.
Check the wiki for others' opinions on this (and other) v3 topics, and post your ideas, or code, here for discussion & inclusion.
AFAICR we reached some concensus on the following style.. which would allow us to produce a processor DTD (example attached) and standardise every mailet config.
I can't remember what other suggestions/arguments were raised, but you could check the mail archive.
<mailet .............>
<matcher class="...">
<condition>...</condition>
<parameters>
<parameter name="..."></parameter>
<parameter name="..."></parameter>
</parameters>
</matcher>
<matcher class="...">
<condition>...</condition>
<parameters>
<parameter name="..."></parameter>
<parameter name="..."></parameter>
</parameters>
</matcher>
<parameters>
<parameter name="..."></parameter>
<parameter name="..."></parameter>
</parameters>
</mailet>
d.
Re: Mailet Configuration
Posted by Aaron Knauf <ak...@xtra.co.nz>.
Hi Serge,
This subject has come up a few times. I suggested an approach to
handling mailet and matcher config better, as did a few others. I even
offered to write it. However, due to the distinct lack of enthusiasm
for my (or any other) solution, I lost interest. I could be convinced
to revisit this if some of the committers indicated that they were
interested.
Cheers
ADK
Serge Sozonoff wrote:
>Hi Guys,
>
>Continuing on with my BounceHandler mailet idea, I would need to do
>something like this in my configuration block for my mailet
>
> <mailet match="RecipientIs=test1@localhost" class="BounceHandler">
> <bounceHandlers>
> <bounceHandler class="DSNBounce"/>
> <bounceHandler class=".........."/>
> </bounceHandlers>
> <bounceProcessors>
> <bounceProcessor class="DBBounceProcessor">
> <database>.....</database>
> <....>...</...>
> <bounceProcessor>
> </bounceProcessors>
> </mailet>
>
>However the mailet API does not give me access to this sort of thing and I
>have not figured out if I can gain access directly to the James
>Configuration object from my Mailet. I think not.
>
>As a temporary work around I could do something like this:
>
> <mailet match="RecipientIs=test1@localhost" class="BounceHandler">
>
><bounceHandlers>class=DSNBounce;class=QmailBounce;class=etc</bounceHandlers>
>
><bounceProcessors>name=DBBounceProcessor;database=......</bounceProcessors>
> </mailet>
>
>But this is not very elegent and idealy I would at the very minimum need to
>pass additional config parameters to the bounceProcessors.
>
>Anyone have any ideas, suggestions?
>
>Thanks,
>Sergei
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Mailet Configuration
Posted by Danny Angus <da...@apache.org>.
> > Without knowing what your doing its hard to say exactly what the answer
> should be.
> I tried to describe the process here
> http://www.mail-archive.com/james-dev@jakarta.apache.org/msg06017.html
Thx Sergei, I know you did, but I didn't follow it very closely.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Mailet Configuration
Posted by Serge Sozonoff <se...@globalbeach.com>.
Hi Noel,
Ahhh now I am getting some attention... I mean feedback :-)
> I'm not at all in favor of the particular direction being taken for this
> bounce handler, but I still have more reading to do. It seems to me that
it
> is attempting to build a pipeline within in a mailet, rather than take
> advantage of matchers, mailets and the processor pipeline. My current
> belief, which still begs more reading, is that there will be good code,
but
> that the code related to his complex configuration is going to be wasted.
OK, So I did point out (and so did Danny) in my previous posts that what I
was doing was very similar in concept to the mailet/matcher/processor stuff
we already have in James, and begged for feedback.
However there are several things I just can 't do with the current Mailet
API as it stands today (I know that you guys have been asking for feedback,
unfortunately I needed to start coding a Mailet to provide this <g>).
I think Danny pointed out several additions to v3 Mailets which would help
solve many of the requirements I need for this Mailet.
Now I have the option to stop working on my bounce handler and maybe try and
help out with Mailet v3 coding, or try and finnish a basic prototype and
submit the code so that it could be used as a partial "requirements list".
Once coding of v3 Mailets is underway I can start migrating the Mailet code
to the new API.
I also agree that what I am doing now config wise will be wasted, but thats
not a big deal. Its not that much code.
Thanks,
Sergei
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Mailet Configuration
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I have *just now* commited a revised James.java which
> provides an attribute "confDir" this attribute is a
> string path to ~james/appas/james/conf to allow you
> to pick up config files from there.
If you would't mind, would you please apply the fix (from the other thread),
if you get to it before I do tomorrow?
> It should work, because it is exactly the same as the
> method used to get a path for the mailet/matcher
> classloaders, which do work.
Same thing. We need to avoid BlockContext.
> > Did we come to a conclusion on how to handle DB connections in Mailets?
> I suspect we may end up with "hasDBProvider()" and "getDBProvider()" so
> that DB provision is optional but allowed for containers.
Serge indicates that he wants to expose JNDI in the Mailet API to gain
access to resources. If you want to respond to that, please change the
subject. :-)
I'm not at all in favor of the particular direction being taken for this
bounce handler, but I still have more reading to do. It seems to me that it
is attempting to build a pipeline within in a mailet, rather than take
advantage of matchers, mailets and the processor pipeline. My current
belief, which still begs more reading, is that there will be good code, but
that the code related to his complex configuration is going to be wasted.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Mailet Configuration
Posted by Danny Angus <da...@apache.org>.
Sergei,
> This all sounds very good!
> Since am almost 70% done with my implementation including a
> handler for DSN
> style bounce messages and an Example DBProcessor.
> I would suggest that I complete an initial prototype (Non mailet/matcher
> approach) including rolling my own config and then I submit my code
> somewhere for others to review. (This should help back some requirements
> with a concrete example)
Yes, very good I agree. I have *just now* commited a revised James.java which provides an attribute "confDir" this attribute is a string path to ~james/appas/james/conf to allow you to pick up config files from there.
I *haven't* tested it, excpet that it does compile.
It should work, because it is exactly the same as the method used to get a path for the mailet/matcher classloaders, which do work.
> One reason for this is that I guess it will still be a little while before
> the new Mailet API is usable. As the new Mailet API starts to
> develop we can
> start migrating my code to the new mailet/matcher API with the enhanced
> features and maybe discover some other requirements.
Yep.
> 1. Did we come to a conclusion on how to handle DB connections in Mailets?
> Is the mailet responsable, is the MailetContext going to provide
> for this or
> is it optional based on the MailetContext implementation?
The general feeling seemed to be that the the mailets should be responsible, at least for now.
I suspect we may end up with "hasDBProvider()" and "getDBProvider()" so that DB provision is optional but allowed for containers.
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Mailet Configuration
Posted by Serge Sozonoff <se...@globalbeach.com>.
Hi Danny,
This all sounds very good!
Since am almost 70% done with my implementation including a handler for DSN
style bounce messages and an Example DBProcessor.
I would suggest that I complete an initial prototype (Non mailet/matcher
approach) including rolling my own config and then I submit my code
somewhere for others to review. (This should help back some requirements
with a concrete example)
One reason for this is that I guess it will still be a little while before
the new Mailet API is usable. As the new Mailet API starts to develop we can
start migrating my code to the new mailet/matcher API with the enhanced
features and maybe discover some other requirements.
Other points:
1. Did we come to a conclusion on how to handle DB connections in Mailets?
Is the mailet responsable, is the MailetContext going to provide for this or
is it optional based on the MailetContext implementation?
Thanks,
Sergei
----- Original Message -----
From: "Danny Angus" <da...@apache.org>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Monday, January 27, 2003 3:25 PM
Subject: RE: Mailet Configuration
Ok, I just re-read your original.
My opinion is now that you either do use mailets or you don't.
Obviously a 1/2 and 1/2 approach is going to be the worst of both worlds.
What I'd also say is why not try to use a mailet approach.
I say this because we're trying to get the mailet API enhanced to support
more sophisticated behaviour, and you have a test case of more sophisticated
behaviour.
What we're about to offer, that is relevant, is
a) Mail properties. Matchers and mailets will be able to set and get
serializable persistent properties on Mail objects they handle. This allows
mailets to work step-wise with Mail exhibiting state.
b) Matcher parameters, enhanced matcher config provided by elevating match
from attribute to element in the config.
c) Matcher chains, initially AND (only no OR) matcher chains will pass the
mail through the configured matchers and only mail which passes all matchers
will reach the mailet.
d) Configurable processor classes. Its my desire, now that the Mailet
contract so closely resembles the Processor contract, to see processors
added to the API, so that developers can add new processors other than the
standard LinearProcessor. This will allow people to support FIFO pipelines,
or forking pipelines and other more sophisticated or specialised pipelines.
I hope that this covers all of your requirements, I believe that it does.
:-)
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Mailet sub-packages
Posted by "Noel J. Bergman" <no...@devtech.com>.
Serge Knystautas write:
> Noel J. Bergman wrote:
> > Actually, I think so, but perhaps not the same way that you anticipate.
I'd
> > like to see us ensure that the base "Mailet" package is protocol
neutral.
> Protocol neutral? What does that mean? I assume we keep it focused on
> spool processing (messaging in general) and MimeMessages. Are you
> suggesting we decouple from email addresses? What else would you change?
Consider XMPP, which uses XML streams. Likewise, the XMPP IETF draft spec
currently adds something to the e-mail address. They format it as
user@host/resource. We could contact them, and encourage them to change it
to adhere to localpart@host, and encode the resource in the localpart.
In any event, the point is simply that we have senders, recipients, message
content at the abstract, and then concrete RFC specifications of sender,
recipient, and content formats.
This is *not* a radical refactoring. Just a basic recognition of
generalization and specialization. I'm not married to how we do it, but I
do think that it should be accommodated.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Mailet sub-packages
Posted by Serge Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
> Actually, I think so, but perhaps not the same way that you anticipate. I'd
> like to see us ensure that the base "Mailet" package is protocol neutral.
Protocol neutral? What does that mean? I assume we keep it focused on
spool processing (messaging in general) and MimeMessages. Are you
suggesting we decouple from email addresses? What else would you change?
> The current package has started incrementally tying itself to SMTP and MIME.
> I'd like us to take a similar approach to the servlet and servlet.http
> packages.
servlet and servlet.http? If this was done in the name of protocol
neutrality, it has to rank up there as one of the worst design decision
in the history of Java APIs. It's one of the most widely adopted APIs
yet NOBODY has used with another protocol aside from http...
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Mailet sub-packages
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Given all of these additions to the Mail API, (all good stuff,) perhaps
> we should think about making some sub-packages of o.a.mailet?
Actually, I think so, but perhaps not the same way that you anticipate. I'd
like to see us ensure that the base "Mailet" package is protocol neutral.
The current package has started incrementally tying itself to SMTP and MIME.
I'd like us to take a similar approach to the servlet and servlet.http
packages.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Mailet Configuration
Posted by Aaron Knauf <ak...@xtra.co.nz>.
Given all of these additions to the Mail API, (all good stuff,) perhaps
we should think about making some sub-packages of o.a.mailet?
ADK
Danny Angus wrote:
>Ok, I just re-read your original.
>
>My opinion is now that you either do use mailets or you don't.
>Obviously a 1/2 and 1/2 approach is going to be the worst of both worlds.
>
>What I'd also say is why not try to use a mailet approach.
>I say this because we're trying to get the mailet API enhanced to support more sophisticated behaviour, and you have a test case of more sophisticated behaviour.
>
>What we're about to offer, that is relevant, is
>
>a) Mail properties. Matchers and mailets will be able to set and get serializable persistent properties on Mail objects they handle. This allows mailets to work step-wise with Mail exhibiting state.
>
>b) Matcher parameters, enhanced matcher config provided by elevating match from attribute to element in the config.
>
>c) Matcher chains, initially AND (only no OR) matcher chains will pass the mail through the configured matchers and only mail which passes all matchers will reach the mailet.
>
>d) Configurable processor classes. Its my desire, now that the Mailet contract so closely resembles the Processor contract, to see processors added to the API, so that developers can add new processors other than the standard LinearProcessor. This will allow people to support FIFO pipelines, or forking pipelines and other more sophisticated or specialised pipelines.
>
>I hope that this covers all of your requirements, I believe that it does. :-)
>
>d.
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Mailet Configuration
Posted by Danny Angus <da...@apache.org>.
Ok, I just re-read your original.
My opinion is now that you either do use mailets or you don't.
Obviously a 1/2 and 1/2 approach is going to be the worst of both worlds.
What I'd also say is why not try to use a mailet approach.
I say this because we're trying to get the mailet API enhanced to support more sophisticated behaviour, and you have a test case of more sophisticated behaviour.
What we're about to offer, that is relevant, is
a) Mail properties. Matchers and mailets will be able to set and get serializable persistent properties on Mail objects they handle. This allows mailets to work step-wise with Mail exhibiting state.
b) Matcher parameters, enhanced matcher config provided by elevating match from attribute to element in the config.
c) Matcher chains, initially AND (only no OR) matcher chains will pass the mail through the configured matchers and only mail which passes all matchers will reach the mailet.
d) Configurable processor classes. Its my desire, now that the Mailet contract so closely resembles the Processor contract, to see processors added to the API, so that developers can add new processors other than the standard LinearProcessor. This will allow people to support FIFO pipelines, or forking pipelines and other more sophisticated or specialised pipelines.
I hope that this covers all of your requirements, I believe that it does. :-)
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Mailet Configuration
Posted by Serge Sozonoff <se...@globalbeach.com>.
Hi Danny,
1/ *don't* access James for config, that is officially discouraged, and Not
Supported, it may well not be possible in the next release
So, basically it is up to my mailets to manage "fancy" configuration for
themselves?
I guess (as you suggested) I can write my own config file and use Avalon
Configuration to deal with it.
Moving forward we are going to have to take a stance here and either offer a
configuration service to mailets or not because as it stands now we are
offering IMO an incomplete solution.
I know that there has been some talk on this issue before, I will have to
revisit the messages now that I am getting more familiar with things.
2. OK
> Why can't you split this all up into seperate mailet/matchers in their own
linear processor? :
On the 22.01 I wrote an email to the dev list discussing my idea and I did
mention that I had thought (maybe not enough) about using the seperate
mailet/matcher aproach, I was kinda hoping for some feedback Re. that mail
:-)
Maybe I can use the mailet/matcher aproach, I had orginally broken down the
process into three things.
Match -> Parse -> Process.
Match would basically indicate if this message is a bounce of type X and can
be parsed by the related parser (Their is a tight relationship between match
and parse)
Parse would parse the message to try and extract the necessary info (Bounce
Type, Status Code, Original recipient etc ....) and create a new instace of
a Bounce object housing this data.
Process would act on the data it recived from the parser. Anyone should be
able to plug in their own processor and do what they like with the data.
eg. Update a DB.
Process would need to receive an instance of Object Bounce from the parse
operation containing the data.
For the moment I have not found a clean way to satisfy these requirements
with the standard mailet/matcher approach.
> Without knowing what your doing its hard to say exactly what the answer
should be.
I tried to describe the process here
http://www.mail-archive.com/james-dev@jakarta.apache.org/msg06017.html
Thanks,
Sergei
----- Original Message -----
From: "Danny Angus" <da...@apache.org>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Monday, January 27, 2003 12:12 PM
Subject: RE: Mailet Configuration
Serge
My 2c..
1/ *don't* access James for config, that is officially discouraged, and Not
Supported, it may well not be possible in the next release.
2/ use the nastylooking hack for now, we can improve mailet/matcher config
if its wanted, or use config files for your mailets I see no reason why that
shouldn't be acceptable.
3/ tell us what you want from the config. look at the mailet plans wiki
page.
Why can't you split this all up into seperate mailet/matchers in their own
linear processor? :
<processor name="root">
<mailet match="RecipientIs=test1@localhost" class="ToProcessor">
<processorname>bounceprocessor</processorname>
</mailet>
</processor>
<processor name="bounce>
<mailet match="All" class="DNSBounce"/>
<mailet match="All" class="....."/>
</processor>
Without knowing what your doing its hard to say exactly what the answer
should be.
d.
> -----Original Message-----
> From: Serge Sozonoff [mailto:serge@globalbeach.com]
> Sent: 27 January 2003 10:17
> To: James Developers List
> Subject: Mailet Configuration
>
>
> Hi Guys,
>
> Continuing on with my BounceHandler mailet idea, I would need to do
> something like this in my configuration block for my mailet
>
> <mailet match="RecipientIs=test1@localhost" class="BounceHandler">
> <bounceHandlers>
> <bounceHandler class="DSNBounce"/>
> <bounceHandler class=".........."/>
> </bounceHandlers>
> <bounceProcessors>
> <bounceProcessor class="DBBounceProcessor">
> <database>.....</database>
> <....>...</...>
> <bounceProcessor>
> </bounceProcessors>
> </mailet>
>
> However the mailet API does not give me access to this sort of thing and I
> have not figured out if I can gain access directly to the James
> Configuration object from my Mailet. I think not.
>
> As a temporary work around I could do something like this:
>
> <mailet match="RecipientIs=test1@localhost" class="BounceHandler">
>
> <bounceHandlers>class=DSNBounce;class=QmailBounce;class=etc</bounc
> eHandlers>
>
> <bounceProcessors>name=DBBounceProcessor;database=......</bouncePr
> ocessors>
> </mailet>
>
> But this is not very elegent and idealy I would at the very
> minimum need to
> pass additional config parameters to the bounceProcessors.
>
> Anyone have any ideas, suggestions?
>
> Thanks,
> Sergei
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Mailet Configuration
Posted by "Noel J. Bergman" <no...@devtech.com>.
Serge,
> I would expect the MailetContext to give me a base path
> so that I could use relative paths
That should be pretty easy, not even going the JNDI route.
We ought to discuss the API, but it ought to be fairly similar to the one in
the Servlet API, and we can use
org.apache.james.context.AvalonContextUtilities to implement it for James.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Mailet Configuration
Posted by Serge Sozonoff <se...@globalbeach.com>.
Hi Danny,
Currently I am coding against Head.
Thanks, Sergei
----- Original Message -----
From: "Danny Angus" <da...@apache.org>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Monday, January 27, 2003 3:28 PM
Subject: RE: Mailet Configuration
Are you developing against the 2.1 branch or the Head?
I think we should be able to add an attribute to mailet context in the HEAD
to allow this.
Hopefully this will let you continue work while we implement better mailet
config, and you can roll your config back into configuration.xml when its
ready.
d.
> -----Original Message-----
> From: Serge Sozonoff [mailto:serge@globalbeach.com]
> Sent: 27 January 2003 14:05
> To: James Developers List
> Subject: Re: Mailet Configuration
>
>
> Hi again Danny,
>
> 2/ .... or use config files for your mailets I see no reason why that
> shouldn't be acceptable.
>
> This would be fine as well, although in this case I would expect the
> MailetContext to give me a base path so that I could use relative paths to
> load my own Mailet config files. I should be able to specify a
> path relative
> to /apps/james or something.
>
> Thoughts?
>
> Thanks, Serge
>
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Mailet Configuration
Posted by Danny Angus <da...@apache.org>.
Are you developing against the 2.1 branch or the Head?
I think we should be able to add an attribute to mailet context in the HEAD to allow this.
Hopefully this will let you continue work while we implement better mailet config, and you can roll your config back into configuration.xml when its ready.
d.
> -----Original Message-----
> From: Serge Sozonoff [mailto:serge@globalbeach.com]
> Sent: 27 January 2003 14:05
> To: James Developers List
> Subject: Re: Mailet Configuration
>
>
> Hi again Danny,
>
> 2/ .... or use config files for your mailets I see no reason why that
> shouldn't be acceptable.
>
> This would be fine as well, although in this case I would expect the
> MailetContext to give me a base path so that I could use relative paths to
> load my own Mailet config files. I should be able to specify a
> path relative
> to /apps/james or something.
>
> Thoughts?
>
> Thanks, Serge
>
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Mailet Configuration
Posted by Serge Sozonoff <se...@globalbeach.com>.
Hi again Danny,
2/ .... or use config files for your mailets I see no reason why that
shouldn't be acceptable.
This would be fine as well, although in this case I would expect the
MailetContext to give me a base path so that I could use relative paths to
load my own Mailet config files. I should be able to specify a path relative
to /apps/james or something.
Thoughts?
Thanks, Serge
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Mailet Configuration
Posted by Danny Angus <da...@apache.org>.
Serge
My 2c..
1/ *don't* access James for config, that is officially discouraged, and Not Supported, it may well not be possible in the next release.
2/ use the nastylooking hack for now, we can improve mailet/matcher config if its wanted, or use config files for your mailets I see no reason why that shouldn't be acceptable.
3/ tell us what you want from the config. look at the mailet plans wiki page.
Why can't you split this all up into seperate mailet/matchers in their own linear processor? :
<processor name="root">
<mailet match="RecipientIs=test1@localhost" class="ToProcessor">
<processorname>bounceprocessor</processorname>
</mailet>
</processor>
<processor name="bounce>
<mailet match="All" class="DNSBounce"/>
<mailet match="All" class="....."/>
</processor>
Without knowing what your doing its hard to say exactly what the answer should be.
d.
> -----Original Message-----
> From: Serge Sozonoff [mailto:serge@globalbeach.com]
> Sent: 27 January 2003 10:17
> To: James Developers List
> Subject: Mailet Configuration
>
>
> Hi Guys,
>
> Continuing on with my BounceHandler mailet idea, I would need to do
> something like this in my configuration block for my mailet
>
> <mailet match="RecipientIs=test1@localhost" class="BounceHandler">
> <bounceHandlers>
> <bounceHandler class="DSNBounce"/>
> <bounceHandler class=".........."/>
> </bounceHandlers>
> <bounceProcessors>
> <bounceProcessor class="DBBounceProcessor">
> <database>.....</database>
> <....>...</...>
> <bounceProcessor>
> </bounceProcessors>
> </mailet>
>
> However the mailet API does not give me access to this sort of thing and I
> have not figured out if I can gain access directly to the James
> Configuration object from my Mailet. I think not.
>
> As a temporary work around I could do something like this:
>
> <mailet match="RecipientIs=test1@localhost" class="BounceHandler">
>
> <bounceHandlers>class=DSNBounce;class=QmailBounce;class=etc</bounc
> eHandlers>
>
> <bounceProcessors>name=DBBounceProcessor;database=......</bouncePr
> ocessors>
> </mailet>
>
> But this is not very elegent and idealy I would at the very
> minimum need to
> pass additional config parameters to the bounceProcessors.
>
> Anyone have any ideas, suggestions?
>
> Thanks,
> Sergei
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>