If I were you, I'd use only mailet configuration properties for this. On 17/09/2019 10:18, Jerry Malcolm wrote: > 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 >
--------------------------------------------------------------------- To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org For additional commands, e-mail: server-user-h...@james.apache.org