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
> >>>
> >>
> >>
> >>
> >>
>
>