Loading...

server-user@james.apache.org

[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: Deploying Custom Mailets Eric Charles Wed Jul 20 01:00:09 2011

On 19/07/11 20:40, Charley Watson wrote:
Eric,

Thanks for the tip... The fully qualified class name trick works...

Q1: Is this a bug or by design?  My mailetcontainer.xml has a package space 
matching my mailet in the mailet-packages element.

This is by design.

The current mailetcontainer.xml does not mention the package space anymore and documentation .

https://svn.apache.org/repos/asf/james/app/trunk/src/main/config/james/mailetcontainer.xml


The documentation (still to be deployed) is updated and mentions following changes:
https://svn.apache.org/repos/asf/james/server/trunk/src/site
- 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
- Composite matchers

https://svn.apache.org/repos/asf/james/server/trunk/src/site/xdoc/config-mailetcontainer.xml


Q2: What dependencies are guaranteed for mailets in the out-of-the-box 
configuration for James?  I added the following but don't know if they comply 
with the deployment scheme and class discovery employed by James:

<james-home>/conf/lib/apache-mailet-2.4.jar
<james-home>/conf/lib/james-stuff-0.0.1-SNAPSHOT.jar (my customizations)
<james-home>/conf/lib/mail-1.4.3.jar (depended on by apache-mailet)
<james-home>/conf/lib/mailet-3.0.jar (depended on by my custom binary)

Seems like some of these 'extra' deployments might cause security exceptions 
when encountered by classloaders...


You don't have to add apache-mailet-2.4.jar, mail-1.4.3.jar nor mailet-3.0.jar in conf/lib. All needed mailet stuff (with correct version) is already in /lib and will be loaded by James.

My custom code extends GenericMailet following an example in the docs--if there 
is a better preferred method to implement mailets that help would be 
appreciated.


No, that's the canonical way to implement mailets.
You could also extend any mailet and override some methods.

Thanks,

Charley Watson
Systems Engineer

-----Original Message-----
From: Eric Charles [mailto:[EMAIL PROTECTED]
Sent: Monday, July 18, 2011 9:54 PM
To: James Users List
Subject: Re: Deploying Custom Mailets

Hi,

Could you try using the full classname (with the package) in you mailetcontainer.xml? 
Putting the jar with all its dependencies in<james-home>/conf/lib should work.

Btw, documentation is updated but still needs to be deployed.

Thx.

On 18/07/11 23:59, Charley Watson wrote:
Howdy,

I'm running a James 3.0 M2 build on Redhat--

I've read a number of articles on deploying custom mailets to 3.0 instances--none of 
them use a standard method to discover the<my-custom-mailet>.jar.. Is there a 
prescribed method?

Here's the symptoms I'm experiencing..

Invoking<james-home>/bin/james start

mailetcontainer.log shows the matcher before<my-custom-mailet>   being loaded; 
then a server failure logs a shutdown.

Invoking<james-home>/bin/james console (I get better logging this way)

The wrapper logging shows the "Requested mailet not found:<my-custom-mailet>"

The spring context appears to be eager loading so I expect that something is 
wrong with my deployment classpath and the discovery order.

A) jar is deployed to<james-home>/lib
B) CLASSPATH_PREFIX is set to include<path-to-my-custom-mailet>.jar
in<james-home>/bin/setenv.sh

I have also tried

A) Deploying to<james-home>/conf/lib (with and without the CLASSPATH_PREFIX).

The docs on deploying a custom mailet appear to be out-of-date as they include 
references to sar files which appears to be 2.3 legacy kruft.

Any knowledge pointers to working examples of custom-mailets greatly 
appreciated.

Thanks for any help,

CW

Charley Watson
Systems Engineer







--
Eric Charles
http://about.echarles.net

---------------------------------------------------------------------
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]



--
Eric Charles
http://about.echarles.net

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]