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

Reply via email to