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 Norman Maurer <no...@apache.org> on 2010/12/17 08:13:28 UTC
[PROPOSAL] Remove mailetpackages configuration directive
Hi there,
I know many proposal this week but its time to "break" stuff now ;)
I would like to propose that we remove the "mailetpackages" and
"matcherpackages" configuration option from the mailetcontainer.xml
file. This would force the users to use the full classname ( with
package) on every matcher/mailet configuration.
So something like this:
<mailet match="org.apache.james.transport.matchers.All"
class="org.apache.james.transport.mailets.ToProcessor">
I think how we do it at the moment just is an ugly hack and give use
not really anything back (except that we don't need to write the
packagename everytime). Its also error-phrone as its possible that two
packages contain the same classname. As mailets and matchers are
pluggable by the users/dev this could happen really easy. Also the
implementation is just a hack (IMHO).
Just a snipped:
for (final String packageName:packages) {
final String className = packageName + mailetName;
try {
final Mailet mailet =
(Mailet)factory.newInstance(Thread.currentThread().getContextClassLoader().loadClass(className));
final MailetConfigImpl configImpl = new MailetConfigImpl();
configImpl.setMailetName(mailetName);
configImpl.setConfiguration(configuration);
configImpl.setMailetContext(mailetContext);
mailet.init(configImpl);
return mailet;
} catch (ClassNotFoundException cnfe) {
//do this so we loop through all the packages
}
}
I know the change is somewhat heavy but I think if we want todo it now
is the time before a final 3.0 will get cut.
Wdyt ?
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PROPOSAL] Remove mailetpackages configuration directive
Posted by Eric Charles <er...@apache.org>.
+1
Eric
On 17/12/2010 08:13, Norman Maurer wrote:
> Hi there,
>
> I know many proposal this week but its time to "break" stuff now ;)
>
> I would like to propose that we remove the "mailetpackages" and
> "matcherpackages" configuration option from the mailetcontainer.xml
> file. This would force the users to use the full classname ( with
> package) on every matcher/mailet configuration.
>
> So something like this:
>
> <mailet match="org.apache.james.transport.matchers.All"
> class="org.apache.james.transport.mailets.ToProcessor">
>
>
> I think how we do it at the moment just is an ugly hack and give use
> not really anything back (except that we don't need to write the
> packagename everytime). Its also error-phrone as its possible that two
> packages contain the same classname. As mailets and matchers are
> pluggable by the users/dev this could happen really easy. Also the
> implementation is just a hack (IMHO).
>
> Just a snipped:
>
> for (final String packageName:packages) {
> final String className = packageName + mailetName;
> try {
> final Mailet mailet =
> (Mailet)factory.newInstance(Thread.currentThread().getContextClassLoader().loadClass(className));
>
> final MailetConfigImpl configImpl = new MailetConfigImpl();
> configImpl.setMailetName(mailetName);
> configImpl.setConfiguration(configuration);
> configImpl.setMailetContext(mailetContext);
> mailet.init(configImpl);
>
> return mailet;
> } catch (ClassNotFoundException cnfe) {
> //do this so we loop through all the packages
> }
> }
>
> I know the change is somewhat heavy but I think if we want todo it now
> is the time before a final 3.0 will get cut.
>
> Wdyt ?
> Norman
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PROPOSAL] Remove mailetpackages configuration directive
Posted by Norman Maurer <no...@apache.org>.
Hi Stefano,
comments inside...
2010/12/17 Stefano Bagnara <ap...@bago.org>:
> I find useful to have automatic search of mailets and the current way
> is not so bad (as we only do this once at the start). But we don't use
> the same method for other components (like the protocol handlers) and
> maybe the current method is not OSGi friendly (is this a motivation
> for your proposal?).
Thats the point. We use the "full name" everywhere else so I just try
to make it consistent. And you are right the current implementation is
not really "OSGI friendly". And like I said name clashes could hit
devs easily with the current implementation..
>
> That said I'm fine with a simplification here, but maybe we should at
> least keep a default package so that basic mailets don't need the full
> package and most configurations are easier to read.
>
> org.apache.james.transport.mailets (for mailets)
> org.apache.james.transport.matchers (for matchers)
Like stated above I would be more in favor to have it consistent all
the way around. But I think we could do what you propose too.. Like
check if the "name" contains a "." and if not just append the
"default" package before try to load it..
>
> Talking about future the good way would be mailets autoregistering to
> the container so that the container already knows what mailets are
> available without the class instantiation attempts. And maybe it would
> also help users/developers to see what mailets are available in the
> environment (not sure what's the best way to do this, just loud
> thinking).
Exactly what I had in mind.. See the commit log:
Log:
Get rid of InstanceFactory when loading UsersRepository,
VirtualUserTable and DomainList. This is done a
BeanFactoryPostProcessor which parse the configuration file for each
of these and register a bean for it in the spring context. Something
similar should be done when loading Mailets/Matchers and
CommandHandler/LineHandler/ConnectHandler/Hook implementations
>
> Stefano
>
> 2010/12/17 Norman Maurer <no...@apache.org>:
>> Hi there,
>>
>> I know many proposal this week but its time to "break" stuff now ;)
>>
>> I would like to propose that we remove the "mailetpackages" and
>> "matcherpackages" configuration option from the mailetcontainer.xml
>> file. This would force the users to use the full classname ( with
>> package) on every matcher/mailet configuration.
>>
>> So something like this:
>>
>> <mailet match="org.apache.james.transport.matchers.All"
>> class="org.apache.james.transport.mailets.ToProcessor">
>>
>>
>> I think how we do it at the moment just is an ugly hack and give use
>> not really anything back (except that we don't need to write the
>> packagename everytime). Its also error-phrone as its possible that two
>> packages contain the same classname. As mailets and matchers are
>> pluggable by the users/dev this could happen really easy. Also the
>> implementation is just a hack (IMHO).
>>
>> Just a snipped:
>>
>> for (final String packageName:packages) {
>> final String className = packageName + mailetName;
>> try {
>> final Mailet mailet =
>> (Mailet)factory.newInstance(Thread.currentThread().getContextClassLoader().loadClass(className));
>>
>> final MailetConfigImpl configImpl = new MailetConfigImpl();
>> configImpl.setMailetName(mailetName);
>> configImpl.setConfiguration(configuration);
>> configImpl.setMailetContext(mailetContext);
>> mailet.init(configImpl);
>>
>> return mailet;
>> } catch (ClassNotFoundException cnfe) {
>> //do this so we loop through all the packages
>> }
>> }
>>
>> I know the change is somewhat heavy but I think if we want todo it now
>> is the time before a final 3.0 will get cut.
>>
>> Wdyt ?
>> Norman
Bye,
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PROPOSAL] Remove mailetpackages configuration directive
Posted by Stefano Bagnara <ap...@bago.org>.
I find useful to have automatic search of mailets and the current way
is not so bad (as we only do this once at the start). But we don't use
the same method for other components (like the protocol handlers) and
maybe the current method is not OSGi friendly (is this a motivation
for your proposal?).
That said I'm fine with a simplification here, but maybe we should at
least keep a default package so that basic mailets don't need the full
package and most configurations are easier to read.
org.apache.james.transport.mailets (for mailets)
org.apache.james.transport.matchers (for matchers)
Talking about future the good way would be mailets autoregistering to
the container so that the container already knows what mailets are
available without the class instantiation attempts. And maybe it would
also help users/developers to see what mailets are available in the
environment (not sure what's the best way to do this, just loud
thinking).
Stefano
2010/12/17 Norman Maurer <no...@apache.org>:
> Hi there,
>
> I know many proposal this week but its time to "break" stuff now ;)
>
> I would like to propose that we remove the "mailetpackages" and
> "matcherpackages" configuration option from the mailetcontainer.xml
> file. This would force the users to use the full classname ( with
> package) on every matcher/mailet configuration.
>
> So something like this:
>
> <mailet match="org.apache.james.transport.matchers.All"
> class="org.apache.james.transport.mailets.ToProcessor">
>
>
> I think how we do it at the moment just is an ugly hack and give use
> not really anything back (except that we don't need to write the
> packagename everytime). Its also error-phrone as its possible that two
> packages contain the same classname. As mailets and matchers are
> pluggable by the users/dev this could happen really easy. Also the
> implementation is just a hack (IMHO).
>
> Just a snipped:
>
> for (final String packageName:packages) {
> final String className = packageName + mailetName;
> try {
> final Mailet mailet =
> (Mailet)factory.newInstance(Thread.currentThread().getContextClassLoader().loadClass(className));
>
> final MailetConfigImpl configImpl = new MailetConfigImpl();
> configImpl.setMailetName(mailetName);
> configImpl.setConfiguration(configuration);
> configImpl.setMailetContext(mailetContext);
> mailet.init(configImpl);
>
> return mailet;
> } catch (ClassNotFoundException cnfe) {
> //do this so we loop through all the packages
> }
> }
>
> I know the change is somewhat heavy but I think if we want todo it now
> is the time before a final 3.0 will get cut.
>
> Wdyt ?
> Norman
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org