Hi,
On Tue, Aug 26, 2014 at 8:12 PM, Arun Gupta <arun.gupta_at_gmail.com> wrote:
> There is clear evidence that nobody is using @DataSourceDefinition in
> production code. See the conversation at:
>
> https://twitter.com/arungupta/status/504039335688404992
>
> Seems like its good only for demos.
I hate to be at the disagreeing side lately ;) but I disagree.
At zeef.com we definitely are using @DataSourceDefinition in production
(albeit the xml variant of this in application.xml). In our development
process development and configuration is done within the same team. Inside
each deployable application we have a directory with sub-directories
holding the config for every stage. The advantage is that everybody is able
to see which config applies to which stage and can keep the config in sync
with the actual code.
At m4n.nl where I worked before we had a similar setup, although before we
introduced that we had the separate config that was advocated at the time
as a best practice. This separate config didn't really work well for us; it
was frequently out of sync with the code, configuration kept growing and
old keys that no code was using anymore kept piling up (because the
developers didn't saw the configuration and the sysop didn't necessarily
saw the code). Worse, when there were live issues it wasn't clear which
values the live code was actually using. Did a thread pool had more threads
than there were connections, or the other way around?
So the concept of defining a data source from within the app, which
@DataSourceDefinition facilitates, is crucial for our process.
Another important thing is that @DataSourceDefinition/the data-source
element remains stable by virtue of the spec. Some vendors unfortunately
often change the way their proprietary data source is configured, or even
worse, remove a way altogether. One version a data source is specified in
XML format 1, half a version later it's in incompatible format 2, then it's
a deployable artifact, then it's not a deployable artifact anymore, and
then surprise it is again. One version the data source even though
proprietary can be embedded in an EAR, then the next version it can't be
embedded anymore. One version it has to be defined in separate XML file,
then one version later it goes into one big configuration file (with of
course has yet again a different XML format), etc etc.
The biggest issue however with the current
@DataSourceDefinition/data-source element is that it's not directly
configurable. This was my main motivation for creating
https://java.net/jira/browse/JAVAEE_SPEC-19
In the meantime I solved the configuration problem a little by using a data
source wrapper that reads configuration based on a parameter and uses that
to configure the real data source. This data source wrapper is then
registered using the data-source element. I outlined the approach here:
http://jdevelopment.nl/switching-data-sources-datasourcedefinition
There is some more room for improvement in @DataSourceDefinition though.
Specifically there are now vendor specific properties that are supposed to
go to the data source (e.g. for the Postgres or MySql driver), but there is
no mechanism for setting vendor specific properties for the container (e.g.
for JBoss or GlassFish). Things like transaction recovery or some advanced
pooling settings are intended for the container, not the data source, but
there now is no good way to configure that other than by some naming
convention.
Long story short (TL;DR):
* @DataSourceDefinition is definitely used in production
* Configuration is issue, but can be solved today. (I hope that config JSR
does this even better)
* Room for general improvements
Kind regards,
Arjan
> I'd urge platform EG and other EGs
> in Java EE 8 to strongly consider adding a similar annotation.
>
> Cheers
> Arun
>
> --
> http://blog.arungupta.me
> http://twitter.com/arungupta
>