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 "Stanley,Michael P." <ms...@mitre.org> on 2001/06/26 18:34:21 UTC
MailetConfig
I've been reading James code for the last several days (I've even begun
drawing up some UML to help get better understanding of it). Just to
begin I would like to say that this is a great project, and I am excited
to offer my help. I will be putting in some time to help with this
project.
It seems that MailetConfig is implemented in the very core and has only
one implementation 'INLINE'. This seems to be good for most mailets
that are used, however I can forsee it leading to problems and I also
think that this approach almost wastes the abstraction of having a
MailetConfig interface. And the way it seems to be implemented is that
you choose an implementation and it is for all mailets.
Ok, to get to the point, I am suggestioning maybe there would be a way
to allow each Mailet to choose how to implement its configuration.
(i.e. INLINE, EXTERNAL (in a another file), JDBC, JOHNNY_X, etc). Why
do I think this is important? Say you have a Mailet that gets repeated
(i.e listserv) and its configuration starts getting long, this could
potentially could make a config.xml file unreadable. Now if each
listserv was able to point to an external file for its configuration
this wouldn't be the case. There are two ways to approach this, the
listserv could add a configuration child file that knows where to look
or it can benefit from a more global abstraction where the deployer has
the freedom to choose its configuration.
Proposed possible approach.
when I mailet is entered in config.xml it could look something like this
<mailet match="CommandForListserv=james@localhost"
class="AvalonListservManager">
<configFile>listserves/james@localhost.xml</configFile>
</mailet>
<mailet match="CommandForListserv=james@localhost"
class="AvalonListservManager" config="INLINE">
<membersPath> file://var/users/list-james </membersPath>
</mailet
<mailet match="CommandForListserv=james@localhost"
class="AvalonListservManager" config="EXTERNAL">
<configFile>listserves/james@localhost.xml</configFile>
</mailet>
This shows how the Default config is INLINE so this won't break existing
structures.
What are peoples thoughts on this? I would like to here some opinions
before attempting patches.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Adding a mailet to the system
Posted by Steve Crossan <st...@runtime-collective.com>.
You don't need to add your mailet and matcher to the JAMES.jar file, but
you do need to do a couple of small edits to the JAMES.conf.xml file.
Do a search in this file for the tag <mailetpackages> and in here add a
new mailetpackage something like
<mailetpackage>com.yourcompany.mailets.</mailetpackage>
and same thing in the <matcherpackages> tag which is just below.
Then you just need to add the matching rule, probably in the tag
<processor name="transport"> or possibly in <processor name="root"> if
it's doing something a bit higher up the chain (if you look through this
code you should get an idea of how it works). Anyway, within one of these
tags you need to add your own <mailet> tag something like
<mailet match="MyMatcher" mailet="MyMailet">
<paramName1>paramValue2</paramName1>
<paramName2>paramValue2</paramName2>
<notice>some logging if you like</notice>
</mailet>
Then that should be it, as long as the class root for your compiled class
is in the classpath when james is started up.
HTH
Steve
http://www.runtime-collective.com
t: 01273 234290
f: 01273 234291
m: 0789 984 1684
On Wed, 27 Jun 2001, Enzo Maggi wrote:
>
> Hi,
>
> I'm working in in the integration of james into an application server
> (under developement - http://www.koinettivity.org) that uses the mail as
> one of the possible front-ends.
>
> I'm just adding a matcher and a mailet in the james system, that
> intercept special addresses mapped to koinettivity applications and that
> react accordingly.
> As far as I can see, I cannot do that without rebuilding the JAMES.jar
> file with the new matcher & mailet *and* touching the JAMES.conf.xml
> file.
>
> I was not able to find a way to put somewhere my jar file containing
> MyMatcher.class, MyMailet.class and then add a line in the
> JAMES.conf.xml to change the flow accordingly. As far as I can see, a
> new jar should correspond to a new .conf.xml..
>
> Sorry if the subject have already been discussed; I've humbly spent the
> last week browsing the code and reading the doc :-)
>
> Thanks in advance for any help,
>
> Enzo
>
>
> -- Enzo Maggi - Mandrakesoft
> http://www.mandrakesoft.com
>
> ---------------------------------------------------------------------
> 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
Adding a mailet to the system
Posted by Enzo Maggi <en...@mandrakesoft.com>.
Hi,
I'm working in in the integration of james into an application server
(under developement - http://www.koinettivity.org) that uses the mail as
one of the possible front-ends.
I'm just adding a matcher and a mailet in the james system, that
intercept special addresses mapped to koinettivity applications and that
react accordingly.
As far as I can see, I cannot do that without rebuilding the JAMES.jar
file with the new matcher & mailet *and* touching the JAMES.conf.xml
file.
I was not able to find a way to put somewhere my jar file containing
MyMatcher.class, MyMailet.class and then add a line in the
JAMES.conf.xml to change the flow accordingly. As far as I can see, a
new jar should correspond to a new .conf.xml..
Sorry if the subject have already been discussed; I've humbly spent the
last week browsing the code and reading the doc :-)
Thanks in advance for any help,
Enzo
-- Enzo Maggi - Mandrakesoft
http://www.mandrakesoft.com
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: MailetConfig
Posted by Serge Knystautas <se...@lokitech.com>.
----- Original Message -----
From: "Stanley,Michael P." <ms...@mitre.org>
> I see, and I agree. I'm a little confused on how James handles the
> protocols i.e. file:// jdbc:// town://
> any suggestions on where I should look that will clear this up for me.
> It appears that repositories are choosen out of protocol, type, and
> model. Is this accurate?
These various "protocols" get mapped to a particular class, e.g., file://
for a mail repository gets mapped to AvalonMailRepository or
AvalonSpoolRepository, and town:// gets mapped to TownSpoolRepository. If
it's for a user repository, there are different classes they get mapped to.
I would think that perhaps you do the same thing for configuration, i.e.,
define a new kind of pluggable interface and have these various "protocols"
map to appropriate classes. I'm not 100% sure on how you'd go about it and
would look at how the current code does the user and mail repositories.
As for what directory the file:// come from, the appropriate class
determines this (i.e., AvalonMailRepository).
> I saw this problem and I even posted something a few days ago addressing
> it. what I see James missing is the ability to shutdown and restart
> from a command line or something? My question now is because James is
> built on Avalon Phoenix now is this something that Phoenix should
> provide for blocks deployed on it. In otherwords, should Phoenix itself
> be shutdown and restarted (not desireable because say you have unrelated
> servers running on the same phoenix foundation and you just want to
> restart one). I think Phoenix should offer a way to shutdown
> (disassemble) specific blocks, and restart them dynamically. Any
> thoughts here? Should I address this to the Avalon mailing list (I
> should probably join that huh)?
I'm very weak on how Avalon actually works. Maybe others can help here (I
would recommend joining that listserv).
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: MailetConfig
Posted by "Stanley,Michael P." <ms...@mitre.org>.
>
>
>> Currently I have UML for several Mailets (namely listserv stuff and
>> toRepository) and am currenlty working on the org.apache.mailet package.
>
Well my time just got spread a little bit thinner. Management just
through me on another project, so this is going to eat a little more of
my time. However, I will continue daily activity I just don't know when
people will start seeing major results from me :-( sorry.
> I hope the UML can be viewed using Visio (god help me) for those of us
> who are not running Linux right now.
Sorry, no Vision here. I'm currenlty using DIA, and writing class UML
diagrams (just to clarrify). I will provide postscript and png copies
as well so viewing will not be a problem. If you want to edit them
however run Linux, and get DIA, or re-write them in Visio (I guess you
can also fuss around with the graphics png copy in Adobe if you feel
bold).
Mike
>
> John
>
>
> ---------------------------------------------------------------------
> 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: MailetConfig
Posted by "John S. Gage" <jg...@epo.som.sunysb.edu>.
>Currently I have UML for several Mailets (namely listserv stuff and
>toRepository) and am currenlty working on the org.apache.mailet package.
I hope the UML can be viewed using Visio (god help me) for those of us who
are not running Linux right now.
John
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: MailetConfig
Posted by "Stanley,Michael P." <ms...@mitre.org>.
Serge Knystautas wrote:
> First of all, thanks! All support is greatly appreciated.
No problem! This project has a lot of potential and a great foundation
of code. Throughout my progress i might have some questions (namely
with stuff that is more Avalon related) I don't have a solid handle on
that yet, but will begin looking into it more.
> If you can, I
> think the UML you've drawn up could help other developers trying to get a
> handle on the code.
Its still alot of work in progress, but when I finish everything I'll be
more than happy to send it in. Currently I have UML for several Mailets
(namely listserv stuff and toRepository) and am currenlty working on the
org.apache.mailet package. I then plan on doing a simple overview of
James with core, services and transport. This I think should clear up a
lot.
> As for the external configuration, I agree the flexibility would be nice.
> I'm not sure on the syntax though. I would prefer to have an attribute on
> the mailet element indicate where the alternate configuration comes from,
> i.e., I think it is confusing to have a nested element dictating
> configuration information in the same place you would otherwise specify
> inline parameters.
I see, and I agree. I'm a little confused on how James handles the
protocols i.e. file:// jdbc:// town://
any suggestions on where I should look that will clear this up for me.
It appears that repositories are choosen out of protocol, type, and
model. Is this accurate?
>
> <mailet config="file:///listserves/james@localhost.xml">
> </mailet>
I like this approach.
question:
file:///listserves is in respect to what directory. I notice
file://var/mail is in respect to <james root>/apps/james ? This is
because of Phoenix, correct? Now should I follow the same approch or
should config files be all rooted to <james root>/apps/james/conf ?
>
> If we could accomplish both these wishes in one approach, I'd prefer that.
Cool.
>
> All of this also gets slightly more complicated because James doesn't know
> how to reload the configuration without a restart. Right now, the external
> source could change, and James wouldn't know to take effect. This may or
> may not be desirable.
I saw this problem and I even posted something a few days ago addressing
it. what I see James missing is the ability to shutdown and restart
from a command line or something? My question now is because James is
built on Avalon Phoenix now is this something that Phoenix should
provide for blocks deployed on it. In otherwords, should Phoenix itself
be shutdown and restarted (not desireable because say you have unrelated
servers running on the same phoenix foundation and you just want to
restart one). I think Phoenix should offer a way to shutdown
(disassemble) specific blocks, and restart them dynamically. Any
thoughts here? Should I address this to the Avalon mailing list (I
should probably join that huh)?
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: MailetConfig
Posted by Charles Benett <ch...@benett1.demon.co.uk>.
"Stanley,Michael P." wrote:
>
> > I would also like to see a slight shift in terminology. Mailets can be
> > used by different matchers in different processors, so calling the xml
> > element mailet is a bit confusing.
>
> >
> > I'd prefer something like (for external config)
> >
> > <stage name="MyStage" config="file:///listserves/james@localhost.xml">
> > </stage>
> >
> > and for inline config, instead of:
> > <mailet match="RemoteAddrNotInNetwork=127.0.0.1,192.168.1"
> > class="ToProcessor">
> > <processor> spam </processor>
> > </mailet>
> >
> > have:
> > <stage name="StopOpenRelays" config="INLINE">
> > <match class="RemoteAddrNotInNetwork">
> > <allowedNetworks="127.0.0.1,192.168.1"/>
> > </match>
> > <mailet class="ToProcessor">
> > <processor> spam </processor>
> > </mailet>
> > </stage>
>
> I like this. I like this alot because it opens up the possiblity of
> having multiple matchers for a set of mailets or a a set of mailets for
> a single matcher. Or even combined.
>
> For example (note: INLINE is the default config)
>
> <stage name="james-dev">
> <match class="RecipientIs">
> <recipient>james-dev@jakarta.apache.org</recipient>
> </match>
> <mailet class="ToListservArchive">
> <path>jdbc://something/cool</path>
> </mailet>
> <mailet class="ListserveClass">
> <!-- listserve options -->
> </mailet>
> </stage>
>
> <stage name="extraStuff" config="file://somewhere/else.xml"/>
>
> <stage name="MyForwardingAddress" config="INLINE">
> <match class="RecipientIs">
> <recipient>admin@jakarta.apache.org</recipient>
> </match> <match class="RecipientIs">
> <recipient>webmaster@jakarta.apache.org</recipient>
> </match> <match class="RecipientIs">
> <recipient>cvs-admin@jakarta.apache.org</recipient>
> </match>
> <mailet class="ForwardMail">
> <!-- neccessary options -->
> </mailet>
> <mailet class="ToStage">
> <stage>finalStage</stage>
> </mailet>
> </stage>
>
> <stage name="evenMorePossiblities"
> config="jdbc://tableofMailetConfigObjects"/>
>
> This is just a rough picture of how things could begin to look. I've
> tried to show some useful features added with this terminology. I'd
> like to run with this and maybe begin it some time next week. Any thoughts?
Sounds great - go for it.
Check out the package org.apache.avalon.excalibur.pipeline, its an easy
way to build pipelines of stages where a stage can be a pipeline. (Gosh,
someone must have thought of this before ... :-) )
>
> >
> > This is slightly more verbose in the config but less confusing, I think.
> > It also allows log messages to specify exactly which use of a mailet or
> > matcher is reporting something.
> > and, it gives us more flexibility going forward, in case, e.g. someone
> > comes up with boolean matchers or multiple mailets per match.
>
> exactly! This is what I tried to demonstrate above :-)
>
> > One factor is getting James to restart - or more accurately reconfigure
> > the spool manager block. This should be handled by a Phoenix service but
> > I'm not sure how.
>
> Nor am I. We will need to talk to work with the Phoenix developers on
> this one,
because it is a very important and powerful feature.
Agreed,
>
> >
> > The second is that Avalon/ Phoenix has (I think) a Camelot system for
> > containers so that mailets could be like WARs in a servlet container.
> > That could be cool, but might be a lot of work.
>
> I definitely would be cool MARs :) anyway I don't know anything about
> the Camelot system (yet) but I don't think that this would be too
> dificult to add support for. With the introduction to stages and
> external configurations it becomes even easier. All a Meta file would
> need to do is point to its Mailet Package path(s) and its Stage config
> file(s) and maybe some other useful information.
I think this is the step after stages.
Charles
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: MailetConfig
Posted by "Stanley,Michael P." <ms...@mitre.org>.
> I would also like to see a slight shift in terminology. Mailets can be
> used by different matchers in different processors, so calling the xml
> element mailet is a bit confusing.
>
> I'd prefer something like (for external config)
>
> <stage name="MyStage" config="file:///listserves/james@localhost.xml">
> </stage>
>
> and for inline config, instead of:
> <mailet match="RemoteAddrNotInNetwork=127.0.0.1,192.168.1"
> class="ToProcessor">
> <processor> spam </processor>
> </mailet>
>
> have:
> <stage name="StopOpenRelays" config="INLINE">
> <match class="RemoteAddrNotInNetwork">
> <allowedNetworks="127.0.0.1,192.168.1"/>
> </match>
> <mailet class="ToProcessor">
> <processor> spam </processor>
> </mailet>
> </stage>
I like this. I like this alot because it opens up the possiblity of
having multiple matchers for a set of mailets or a a set of mailets for
a single matcher. Or even combined.
For example (note: INLINE is the default config)
<stage name="james-dev">
<match class="RecipientIs">
<recipient>james-dev@jakarta.apache.org</recipient>
</match>
<mailet class="ToListservArchive">
<path>jdbc://something/cool</path>
</mailet>
<mailet class="ListserveClass">
<!-- listserve options -->
</mailet>
</stage>
<stage name="extraStuff" config="file://somewhere/else.xml"/>
<stage name="MyForwardingAddress" config="INLINE">
<match class="RecipientIs">
<recipient>admin@jakarta.apache.org</recipient>
</match> <match class="RecipientIs">
<recipient>webmaster@jakarta.apache.org</recipient>
</match> <match class="RecipientIs">
<recipient>cvs-admin@jakarta.apache.org</recipient>
</match>
<mailet class="ForwardMail">
<!-- neccessary options -->
</mailet>
<mailet class="ToStage">
<stage>finalStage</stage>
</mailet>
</stage>
<stage name="evenMorePossiblities"
config="jdbc://tableofMailetConfigObjects"/>
This is just a rough picture of how things could begin to look. I've
tried to show some useful features added with this terminology. I'd
like to run with this and maybe begin it some time next week. Any thoughts?
>
> This is slightly more verbose in the config but less confusing, I think.
> It also allows log messages to specify exactly which use of a mailet or
> matcher is reporting something.
> and, it gives us more flexibility going forward, in case, e.g. someone
> comes up with boolean matchers or multiple mailets per match.
exactly! This is what I tried to demonstrate above :-)
> One factor is getting James to restart - or more accurately reconfigure
> the spool manager block. This should be handled by a Phoenix service but
> I'm not sure how.
Nor am I. We will need to talk to work with the Phoenix developers on
this one, because it is a very important and powerful feature.
>
> The second is that Avalon/ Phoenix has (I think) a Camelot system for
> containers so that mailets could be like WARs in a servlet container.
> That could be cool, but might be a lot of work.
I definitely would be cool MARs :) anyway I don't know anything about
the Camelot system (yet) but I don't think that this would be too
dificult to add support for. With the introduction to stages and
external configurations it becomes even easier. All a Meta file would
need to do is point to its Mailet Package path(s) and its Stage config
file(s) and maybe some other useful information.
One thing that comes to mind and needs to be worked out though
(eventually, for now its one day at a time) is Namespacing. It will
quickly become a neccessity in a dynamic system like this. Just
something to think about.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: MailetConfig
Posted by Charles Benett <ch...@benett1.demon.co.uk>.
Serge Knystautas wrote:
>
> First of all, thanks! All support is greatly appreciated. If you can, I
> think the UML you've drawn up could help other developers trying to get a
> handle on the code.
>
> As for the external configuration, I agree the flexibility would be nice.
> I'm not sure on the syntax though. I would prefer to have an attribute on
> the mailet element indicate where the alternate configuration comes from,
> i.e., I think it is confusing to have a nested element dictating
> configuration information in the same place you would otherwise specify
> inline parameters.
>
> So instead what about something like...
>
> <mailet match="CommandForListserv=james@localhost"
> class="AvalonListservManager"
> config="file:///listserves/james@localhost.xml">
> </mailet>
>
> or I might even suggest putting not only the mailet configuration, but the
> mailet class and match in as well. e.g.,
>
> <mailet config="file:///listserves/james@localhost.xml">
> </mailet>
I would also like to see a slight shift in terminology. Mailets can be
used by different matchers in different processors, so calling the xml
element mailet is a bit confusing.
I'd prefer something like (for external config)
<stage name="MyStage" config="file:///listserves/james@localhost.xml">
</stage>
and for inline config, instead of:
<mailet match="RemoteAddrNotInNetwork=127.0.0.1,192.168.1"
class="ToProcessor">
<processor> spam </processor>
</mailet>
have:
<stage name="StopOpenRelays" config="INLINE">
<match class="RemoteAddrNotInNetwork">
<allowedNetworks="127.0.0.1,192.168.1"/>
</match>
<mailet class="ToProcessor">
<processor> spam </processor>
</mailet>
</stage>
This is slightly more verbose in the config but less confusing, I think.
It also allows log messages to specify exactly which use of a mailet or
matcher is reporting something.
and, it gives us more flexibility going forward, in case, e.g. someone
comes up with boolean matchers or multiple mailets per match.
> Just off the top of my head. Someone a few months ago was asking about how
> to configure a processor dynamically (in your words, externally instead of
> inline). For instance, rather than creating 10 lines for 10 listservs in
> the xml conf file referencing an external configuration, have a single
> element reference an external configuration that would configuration 10 (or
> however many) mailets for a dynamic list of listservs.
>
> If we could accomplish both these wishes in one approach, I'd prefer that.
>
> All of this also gets slightly more complicated because James doesn't know
> how to reload the configuration without a restart. Right now, the external
> source could change, and James wouldn't know to take effect. This may or
> may not be desirable.
One factor is getting James to restart - or more accurately reconfigure
the spool manager block. This should be handled by a Phoenix service but
I'm not sure how.
The second is that Avalon/ Phoenix has (I think) a Camelot system for
containers so that mailets could be like WARs in a servlet container.
That could be cool, but might be a lot of work.
Good luck,
Charles
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: MailetConfig
Posted by Serge Knystautas <se...@lokitech.com>.
First of all, thanks! All support is greatly appreciated. If you can, I
think the UML you've drawn up could help other developers trying to get a
handle on the code.
As for the external configuration, I agree the flexibility would be nice.
I'm not sure on the syntax though. I would prefer to have an attribute on
the mailet element indicate where the alternate configuration comes from,
i.e., I think it is confusing to have a nested element dictating
configuration information in the same place you would otherwise specify
inline parameters.
So instead what about something like...
<mailet match="CommandForListserv=james@localhost"
class="AvalonListservManager"
config="file:///listserves/james@localhost.xml">
</mailet>
or I might even suggest putting not only the mailet configuration, but the
mailet class and match in as well. e.g.,
<mailet config="file:///listserves/james@localhost.xml">
</mailet>
Just off the top of my head. Someone a few months ago was asking about how
to configure a processor dynamically (in your words, externally instead of
inline). For instance, rather than creating 10 lines for 10 listservs in
the xml conf file referencing an external configuration, have a single
element reference an external configuration that would configuration 10 (or
however many) mailets for a dynamic list of listservs.
If we could accomplish both these wishes in one approach, I'd prefer that.
All of this also gets slightly more complicated because James doesn't know
how to reload the configuration without a restart. Right now, the external
source could change, and James wouldn't know to take effect. This may or
may not be desirable.
Serge
----- Original Message -----
From: "Stanley,Michael P." <ms...@mitre.org>
To: <ja...@jakarta.apache.org>
Sent: Tuesday, June 26, 2001 12:34 PM
Subject: MailetConfig
> I've been reading James code for the last several days (I've even begun
> drawing up some UML to help get better understanding of it). Just to
> begin I would like to say that this is a great project, and I am excited
> to offer my help. I will be putting in some time to help with this
> project.
>
> It seems that MailetConfig is implemented in the very core and has only
> one implementation 'INLINE'. This seems to be good for most mailets
> that are used, however I can forsee it leading to problems and I also
> think that this approach almost wastes the abstraction of having a
> MailetConfig interface. And the way it seems to be implemented is that
> you choose an implementation and it is for all mailets.
>
> Ok, to get to the point, I am suggestioning maybe there would be a way
> to allow each Mailet to choose how to implement its configuration.
> (i.e. INLINE, EXTERNAL (in a another file), JDBC, JOHNNY_X, etc). Why
> do I think this is important? Say you have a Mailet that gets repeated
> (i.e listserv) and its configuration starts getting long, this could
> potentially could make a config.xml file unreadable. Now if each
> listserv was able to point to an external file for its configuration
> this wouldn't be the case. There are two ways to approach this, the
> listserv could add a configuration child file that knows where to look
> or it can benefit from a more global abstraction where the deployer has
> the freedom to choose its configuration.
>
> Proposed possible approach.
>
> when I mailet is entered in config.xml it could look something like this
>
>
> <mailet match="CommandForListserv=james@localhost"
> class="AvalonListservManager">
> <configFile>listserves/james@localhost.xml</configFile>
> </mailet>
>
> <mailet match="CommandForListserv=james@localhost"
> class="AvalonListservManager" config="INLINE">
> <membersPath> file://var/users/list-james </membersPath>
> </mailet
>
> <mailet match="CommandForListserv=james@localhost"
> class="AvalonListservManager" config="EXTERNAL">
> <configFile>listserves/james@localhost.xml</configFile>
> </mailet>
>
> This shows how the Default config is INLINE so this won't break existing
> structures.
>
> What are peoples thoughts on this? I would like to here some opinions
> before attempting patches.
>
> Mike
>
>
> ---------------------------------------------------------------------
> 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: MailetConfig
Posted by Danny Angus <da...@thought.co.uk>.
are you reverse engineering the UML form the code?
and .. what format(s) is your output likely to be?
I've recently discovered the excellent magic draw UML tool
http://www.magicdraw.com (java based so x-platform) which will reverse
engineer code sets into UML XML files and also output Rose-format project
files.
I'm planning to use it in our work here, because the vanilla XML (not
zipped) works a treat with cvs, and it seems to me that that would be a
major factor in an OS project.
Unfortunately I'm still using an evaluation licence, pitting it against Rose
and Together, and James is too big for the eval version.
However it takes less than five minutes to generate the *whole* UML from
code, *and* produce a class diagram of the whole shooting match (if your
classpath settings are straight, as always).
(just a thought)
d.
> -----Original Message-----
> From: Stanley,Michael P. [mailto:mstanley@mitre.org]
> Sent: Tuesday, June 26, 2001 5:34 PM
> To: james-dev@jakarta.apache.org
> Subject: MailetConfig
>
>
> I've been reading James code for the last several days (I've even begun
> drawing up some UML to help get better understanding of it). Just to
> begin I would like to say that this is a great project, and I am excited
> to offer my help. I will be putting in some time to help with this
> project.
>
> It seems that MailetConfig is implemented in the very core and has only
> one implementation 'INLINE'. This seems to be good for most mailets
> that are used, however I can forsee it leading to problems and I also
> think that this approach almost wastes the abstraction of having a
> MailetConfig interface. And the way it seems to be implemented is that
> you choose an implementation and it is for all mailets.
>
> Ok, to get to the point, I am suggestioning maybe there would be a way
> to allow each Mailet to choose how to implement its configuration.
> (i.e. INLINE, EXTERNAL (in a another file), JDBC, JOHNNY_X, etc). Why
> do I think this is important? Say you have a Mailet that gets repeated
> (i.e listserv) and its configuration starts getting long, this could
> potentially could make a config.xml file unreadable. Now if each
> listserv was able to point to an external file for its configuration
> this wouldn't be the case. There are two ways to approach this, the
> listserv could add a configuration child file that knows where to look
> or it can benefit from a more global abstraction where the deployer has
> the freedom to choose its configuration.
>
> Proposed possible approach.
>
> when I mailet is entered in config.xml it could look something like this
>
>
> <mailet match="CommandForListserv=james@localhost"
> class="AvalonListservManager">
> <configFile>listserves/james@localhost.xml</configFile>
> </mailet>
>
> <mailet match="CommandForListserv=james@localhost"
> class="AvalonListservManager" config="INLINE">
> <membersPath> file://var/users/list-james </membersPath>
> </mailet
>
> <mailet match="CommandForListserv=james@localhost"
> class="AvalonListservManager" config="EXTERNAL">
> <configFile>listserves/james@localhost.xml</configFile>
> </mailet>
>
> This shows how the Default config is INLINE so this won't break existing
> structures.
>
> What are peoples thoughts on this? I would like to here some opinions
> before attempting patches.
>
> Mike
>
>
> ---------------------------------------------------------------------
> 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