Hi Jerry,

That's really a good question that should see better information and a
refresh on 'packaging.html' page.

Regarding your questions:

 - James consist of APIs
 - Each of these APIs have implementations: file, memory, jpa,
cassandra, etc...
 - Finally we rely on two injections framework for putting things
together: Guice & Spring

Spring is the historical choice: allow the user of full control over
which components can be selected where. Note that here every instalation
will be highly customized and subtle bugs can arise for some unexpected
combinations. This means that even basic features can be failing without
notice upon a bad component combination, and the cardinality of
implementation being too high, we can not write integration tests for
each of them.

Guice was an implementation effort to solve that issue. We define well
defined products matching end user use cases and expectations. We run
integration tests of these combinations as part of the build pipeline
and the end user have 'limited' architectural choices.

I would of course adivse you to use 'Guice'.

Regarding implementations, the reasonable choices are 'jpa' versus
'distributed James' (Cassandra, ElasticSearch, RabbitMQ). Note that
'distributed James' targets deployments that cannot reasonably fit
within a relational database and currently is under development (
consider it experimental)

Finally, the project also gives some 'docker' files to get started
easily. Here the choice depends on you: do you like containers?

That's it for the overview.

Regarding the more specific question:

 - JDBC is on the way to deprecation and is being replaced by JPA
 - Spring JPA -> Guice JPA should be a dropped in replacement once
guice-jpa is setted up with the correct driver (same implementation)
 - I don't know if/how to use JDBC with Guice
 - JDBC -> JPA migration seems unclear to me. Which JDBC data do you have?
 - Custom matcher/mailets are unaffected. If you rely on James packaging
for injections / other stuff like jdbc connection a bit of development
might be needed.
 - Docker choice is fully orthogonal with your other choices.

Also we just released 3.4 :-) You might select it as a target instead of
3.3. No major changes should affect you while you will benefit from
latest enhancements.

Of course, I believe most of the content of this mail should go to the
documentation...

Best regards,

Benoit Tellier

On 06/10/2019 07:46, Jerry Malcolm wrote:
> Back in v3b5, I used James with Spring and with JDBC/mySQL. I realize
> that several new implementation combinations have been added.  I've read
> articles about Guice, Cassandra, Spring, JPA, Docker.  I understand
> basically where each one fits into the world of James. And looking at
> the JAMES package download options, I see that I've got a lot of choices
> with various combinations of these.  What I am having trouble finding
> are details about why I would want one over the other and what the
> advantages/disadvantages are of one over the other.
> 
> It appears that there is an choice of Cassandra vs JPA vs JDBC/(MySQL). 
> Then there is a choice of Spring vs. Guice.  And also there is a choice
> of Docker vs. non-Docker. I'm setting up my new configuration on AWS. 
> My goal is to make it the most 'strategic' implementation for James. 
> But I don't know which choices are the right 'strategic' answers, and if
> the 'right' answer depends on certain criteria, I would like to
> understand the criteria.
> 
> If someone could take a few minutes to provide some decision criteria
> for a) Cassandra/JPA/JDBC; b) Spring/Guice; c) Docker/non-Docker
> 
>         -- What are architectural advantages of one choice over the others
>         -- Are any of the options going to be deprecated soon?
>         -- When would I want to choose one over the other (or NOT choose
> one over the other)?
>         -- If I have an 'old' Spring/JDBC implmentation with a huge
> existing database, does that affect choices? (possibly requiring a
> massive db migration)
>         -- If I have custom matchers/mailets (some of which use JDBC),
> will I have to rewrite those if I choose certain implmentations?
>         -- Are there required fixed combinations (e.g. if you select
> Cassandra, you have to use Docker, etc)?
> 
> Not a showstopper for me.  My first goal is to just get my old
> Spring/JDBC version running on 3.3.  But after that, I'd really like to
> look into moving to the strategic implementation.
> 
> Thanks.
> 
> Jerry
> 
> 
> ---------------------------------------------------------------------
> 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