You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-user@james.apache.org by agks mehx <ag...@gmail.com> on 2011/02/10 04:37:47 UTC
mailet package specification changed in M3?
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!
Re: mailet package specification changed in M3?
Posted by agks mehx <ag...@gmail.com>.
Thanks. I am glad you simplified it. I clearly remember thinking it was
weird to have to specify a list of packages with potential for name
collisions. I am glad you cleaned it up so soon. :-)
On Wed, Feb 9, 2011 at 9:25 PM, Eric Charles <er...@apache.org> wrote:
> 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<
>>> andrew.tomlinson@excelsis.ca> 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:agksmehx@gmail.com]
>>>> 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<ag...@gmail.com> 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: server-user-unsubscribe@james.apache.org
>>>> For additional commands, e-mail: server-user-help@james.apache.org
>>>>
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-user-help@james.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
> For additional commands, e-mail: server-user-help@james.apache.org
>
>
Re: mailet package specification changed in M3?
Posted by Eric Charles <er...@apache.org>.
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<
>> andrew.tomlinson@excelsis.ca> 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:agksmehx@gmail.com]
>>> 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<ag...@gmail.com> 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: server-user-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-user-help@james.apache.org
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
> For additional commands, e-mail: server-user-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
Re: mailet package specification changed in M3?
Posted by Norman <no...@apache.org>.
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<
> andrew.tomlinson@excelsis.ca> 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:agksmehx@gmail.com]
>> 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<ag...@gmail.com> 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: server-user-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-user-help@james.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
Re: mailet package specification changed in M3?
Posted by agks mehx <ag...@gmail.com>.
(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 <
andrew.tomlinson@excelsis.ca> 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:agksmehx@gmail.com]
> 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 <ag...@gmail.com> 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: server-user-unsubscribe@james.apache.org
> For additional commands, e-mail: server-user-help@james.apache.org
>
>
RE: mailet package specification changed in M3?
Posted by "Andrew S. Tomlinson" <an...@excelsis.ca>.
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:agksmehx@gmail.com]
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 <ag...@gmail.com> 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: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
Re: mailet package specification changed in M3?
Posted by agks mehx <ag...@gmail.com>.
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.MailetLoaderBeanFactory.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 <ag...@gmail.com> 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!
>