See related discussion on http://markmail.org/thread/yhjfo3vyvfj7fsny
I will use the summary as documentation for the web site :)
Tks,
- Eric
On 10/02/2011 07:48, Norman wrote:
Hi there,
yes we removed the mailetpackages and matcherpackages stuff. This was
mainly done to make it easier later to support OSGI without to much
classloader hacks.
BTW, nice summary :)
Bye,
Norman
Am 10.02.2011 05:35, schrieb agks mehx:
(PS: Thanks Andrew)
Solved - (confirm?)
Digging through the source and diffing between M2 and M3 (trunk), it
looks
like:
- no more mailetpackage specification in mailetcontainer.xml
- exactly one standard package, hard-coded in source code
- standard package applied to mailet classnames without package
prefix
- all custom mailets must be specified with full package prefix
- package prefixed custom mailet names will be searched across the
entire
applicable class path
Relevant code from
org.apache.james.container.spring.bean.factory.mailetcontainer.AbstractLoaderBeanFactory.java:
protected T load(String name) throws ClassNotFoundException {
String fullName;
if (name.indexOf(".")< 1) {
fullName = getStandardPackage() + "." + name;
} else {
fullName = name;
}
// Use the classloader which is used for bean instance stuff
Class<T> c = (Class<T>)
getBeanFactory().getBeanClassLoader().loadClass(fullName);
return (T) getBeanFactory().createBean(c);
}
and
from:
org.apache.james.container.spring.bean.factory.mailetcontainer.MailetLoaderBeanFactory.java:
protected String getStandardPackage() {
return "org.apache.james.transport.mailets";
}
Thanks!
On Wed, Feb 9, 2011 at 6:29 PM, Andrew S. Tomlinson<
[email protected]> wrote:
Yes, I found the same thing - you now need to specify the full class
name.
Andrew S. Tomlinson
Principal - Excelsis Inc
317 Lee Ave, Toronto ON M4E 2P7
T: 416 716 2751
W: http://www.excelsis.ca
---------------------------------------------------------------------
This message contains confidential and proprietary information of the
sender, and is intended only for the person(s) to whom it is addressed.
Any
use, distribution, copying or disclosure by any other person is
strictly
prohibited. If you have received this message in error, please
notify the
e-mail sender immediately, and delete the original message without
making a
copy.
-----Original Message-----
From: agks mehx [mailto:[email protected]]
Sent: February-09-11 10:48 PM
To: James Users List
Subject: Re: mailet package specification changed in M3?
More information: based on a text search in the code base, it looks
like at
least the standard mailet classes are being found because the standard
mailets package is being specified via java code rather than in an xml
configuration file. That code is in
org.apache.james.container.spring.bean.factory.mailetcontainer.MailetLoaderB
eanFactory.java:
@Override
protected String getStandardPackage() {
return "org.apache.james.transport.mailets";
}
Now I guess I should try directly using a custom mailet by
specifying its
fully qualified name in conf/mailetcontainer.xml. If that works fine it
would be good enough for me. I do remember thinking it was not that
elegant
to have to specify a package separately so if this is a recent
change and
it
works I'm more than happy.
On Wed, Feb 9, 2011 at 5:37 PM, agks mehx<[email protected]> wrote:
I remember that one had to specify mailet packages in
conf/mailetcontainer.xml when I first downloaded M2. But now, in M3
snapshot I do not see those entries.
Has something changed? There probably is some place where packages
are
being specified because the standard mailet classes are being
configured
without the full package path in their names (in mailetcontainer.xml)
Please advise - thanks!
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
