Yes, I was wondering about that option too.
On 27 Aug 2014, at 12:05, John D. Ament <john.d.ament_at_gmail.com> wrote:
> Well, knowing that we already support these definitions within various descriptors, is it possible to standardize on having these XML's deployed standalone from the in-archive descriptors?
>
>
> On Wed, Aug 27, 2014 at 5:26 AM, Pete Muir <pmuir_at_bleepbleep.org.uk> wrote:
> Agreed.
>
> I/we (Red Hat) think that it’s far better to deploy the datasource as a separate piece of configuration to your application (either via the server config or a deployable artefact) and then reference it using @Resource or JNDI.
>
> Where possible we try to recommend to our users to go with a standards based approach to building apps, but this is (unfortunately) an area where we have to recommend a JBoss/WildFly specific configuration.
>
> Pete
>
> On 27 Aug 2014, at 09:02, Mark Struberg <struberg_at_yahoo.de> wrote:
>
> > I agree with Romain and others that @DataSourceDefinition is mostly useless.
> >
> >
> > Arjan, so you have the passwords of all your stages checked in to SCM and in your EAR/WAR in plaintext?
> > What is your ops team and the security guys saying about it?
> >
> > And how do you treat different databases? Or an application which runs at a customer and you don't have any credentials at all? This solution just doesn't scale...
> >
> >
> >
> >
> >> 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.
> >
> >
> > Old trick. I wrote something similar 4 years ago for CODI [1][2] (it's actually much older, a colleague and I first wrote this around 2006).
> > But we decided to ditch it and not move it over to DeltaSpike as it doesn't work on all containers when it comes to JTA. Even if you do a ConfigurableXaDataSource. The problem is that some containers evaluate the settings even before your app is booted (for doing JPA instrumentation, etc). Creates funny NPEs...
> >
> >
> > We moved to configure the DataSource on the containers (here I agree with you that the config is freaking different for each container) and use @Resource for injection. This is the only way which works well on (almost) all containers.
> >
> > And forget about JNDI. It just stinks. A DataSource configured on the container pops up on a different location for almost every container. The JNDI location sometimes even changes between different versions of the same container.
> >
> >> 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.
> >
> > Fully agree, but I think this should not be fixed as the whole approach is imo broken.
> > So let's review and then deprecate this annotation based config.
> >
> >
> > LieGrue,
> > strub
> >
> >
> >
> >
> > [1] https://github.com/apache/myfaces-extcdi/blob/trunk/jee-modules/jpa-module/api/src/main/java/org/apache/myfaces/extensions/cdi/jpa/api/datasource/DataSourceConfig.java
> >
> > [2] https://github.com/apache/myfaces-extcdi/blob/trunk/jee-modules/jpa-module/impl/src/main/java/org/apache/myfaces/extensions/cdi/jpa/impl/datasource/ConfigurableDataSource.java
> >
> >
> >
> >
> > On Tuesday, 26 August 2014, 23:06, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> >>
> >>
> >> 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
> >>>
> >>
> >>
> >>
> >>
>
>