No the main mailet in question is 100% custom. It is a mailet that
decides what folder to put the mail item in. I access a completely
separate client database and determine if the sender is a client vs. a
vendor vs. an employee and store the mail in a different folder based on
the result. The client database is completely unrelated to james. It's
just a lookup. Since this mailet is pure custom, I really don't care to
do any more integration into James other than mailet interface. My main
goal was simply to be able to store the database name, id/pw, url, etc
in a database properties file and get it out of the mailet code and/or
the mailet flow xml files. Again, not a big deal.
On 9/16/2019 9:49 PM, Tellier Benoit wrote:
Hi Jerry,
Are you speaking of JDBC mailets (whiteList for instance)
These mailets are currently deprecated (or will be) as they hard code
their database, are not standard, not tested and not documented. Note
that they are considered as 'experimental' ( cf
http://james.apache.org/server/dev-provided-mailets.html ).
I would discourage their use (unless you really need these features) and
call for contribution:
- Write a generic storage API for them
- Rewrite these mailets on top of this storage API
- Provide JPA storage for these storage APIs
- Bind stuff in Guice/Spring
A bit of work, but if you really need it, I would be pleased to provide
such guidance.
On 17/09/2019 09:39, Jerry Malcolm wrote:
A couple of my mailets need to access a different database other than
the base james db. I've got the main db set up in the
james-database.properties file. Currently I'm just hardcoding the
database connection to the other db in the mailet. Just curious if
there's a better architected process where I can define two datasources
in james-database.properties and reference the alternate datasource when
needed. Couldn't see anything as to how to do that. Not a big deal.
Just trying to clean up a few things as I migrate to the new version.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org
For additional commands, e-mail: server-user-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org
For additional commands, e-mail: server-user-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org
For additional commands, e-mail: server-user-h...@james.apache.org
