Re: Deploying Custom Mailets

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]