Jason Proctor wrote:
however i can say that our application involves a decent chunk of
crypto, my mailet intercepts every message routed to James, and the
mailet code works fine if i invoke it from another environment. ie, i
wrote a command line tool which pretends to be James and calls my mailet.
What release of James are you using?
James 2.3.0 includes crypto mailets and it does explicitly set the
preferred key stores and something similar. This may conflict with your
code...
our API, which the mailet calls, is pretty solid, having been tested by
our clients and test scripts and all that. my attempts at debugging the
problem so far haven't produced any results - the path through the code
seems to be identical.
And what is the problem? An exception? A different behaviour? What?
so my questions are -- is there anything weird about the James
environment from a coding standpoint? are there things that should not
be done from a mailet?
No. The only thing is that mailets must be threadsafe.
James 2.3.0a1 (James-trunk) uses a different way to provide classloader
for mailets than James 2.2.0.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
