Use DI in dropwizard component
Closed this issue · 4 comments
The dropwizard component (mostly) will manually create objects. Once it uses DI, then object construction and dependency injection, generally, can be made more consistent.
Hi Aaron,
could you please elaborate on how to configure Cassandra persistence (from project trellis-extensions) instead of Postgres persistence in the Dropwizard TrellisApplication?
The CassandraResourceService seems to use CDI for configuration. That is why I pose this question here.
Thanks, Christoph
@christophknabe this is the correct issue to discuss this. At present, there is no mechanism for using a Cassandra-based persistence layer with the Dropwizard-packaged Trellis application. You are correct that the Cassandra implementation relies on CDI.
In principle, once this issue is resolved, then is will be possible to more easily combine the Cassandra layer and the Dropwizard packaging. That said, I would encourage you to look at the Quarkus-based Cassandra package (trellisldp/trellis-cassandra at DockerHub or at https://github.com/trellis-ldp/trellis-extensions/packages/114466).
Using that package, the following configuration properties are available: https://github.com/trellis-ldp/trellis-extensions/blob/master/platform/quarkus/src/main/resources/application.properties#L11-L19
When using environment variables, convert these property names to UPPER CASE and change all - and . characters to _. So trellis.cassandra.contact-address would become TRELLIS_CASSANDRA_CONTACT_ADDRESS
There is also a larger issue with the dropwizard component in Trellis, given that the development emphasis has been centered on using Quarkus for quite some time. Quarkus is faster, there is less code for handling integration with Trellis and it is a much more active project than Dropwizard. Dropwizard also doesn't really support Java11, so depending on where that project stands w/r/t Java11 when Trellis moves completely to Java11 (#962), the Dropwizard support may have to be a special case or it will need to be removed altogether.
TL;DR: if you are able to choose, I would highly recommend using Quarkus over Dropwizard for application packaging.
@acoburn Thank you very much for the detailed explanation. We at Spoter.ME elected the Dropwizard TrellisApplication, because it has a long README, in contrary to the Quarkus TrellisApplication. So we supposed the Dropwizard application is more mature.
But as we are still early on our journey we would like to follow your recommendation. The switch to Quarkus application packaging should not need too much work.
@christophknabe that's a good reminder to me to add more documentation!
Having spent the last year building systems that extend Trellis with a Quarkus layer, I hope you find -- as I have -- that the extensibility (and performance) of a Quarkus-based system to be far superior.