[prev in list] [next in list] [prev in thread] [next in thread] 

List:       james-user
Subject:    Re: mailet package specification changed in M3?
From:       agks mehx <agksmehx () gmail ! com>
Date:       2011-02-10 7:36:53
Message-ID: AANLkTi=60wrdTP8THoL8FQ838XmVen5oX+_nAeAwiqS+ () mail ! gmail ! com
[Download RAW message or body]


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 <eric@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<agksmehx@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
>
>


[prev in list] [next in list] [prev in thread] [next in thread]