On Wed, Aug 27, 2014 at 1:09 PM, Romain Manni-Bucau <rmannibucau_at_gmail.com>
wrote:
> I wouldn't go this way without config jsr otherwise we'll add another
> layer which will conflict with some other jsr. The making it more
> standard should be easier and can even be part of config jsr 1.1 I
> guess.
>
I've discussed this option off list with various stakeholders of the config
JSR and this indeed seems to be one of the wishes;
Use the exact syntax that's already available for the in-archive
descriptors, and provide that externally. It doesn't even have to be
specifically about data sources. Just have the ability to add (and
optionally override and perhaps even subtract) any descriptor fragment, and
the ability to define data source externally comes automatically.
>
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
> 2014-08-27 13:06 GMT+02:00 Pete Muir <pmuir_at_bleepbleep.org.uk>:
> > 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
> >> >>>
> >> >>
> >> >>
> >> >>
> >> >>
> >>
> >>
> >
>