[wildfly-dev] Favour jboss-persistence.xml if present

[Klein, Christopher]

> > On Jan 29, 2014, at 3:33 PM, Scott Marlow <smarlow at redhat.com> wrote:
> >
> >> On 01/29/2014 04:24 PM, Brian Stansberry wrote:
> >>> On 1/29/14, 3:20 PM, Scott Marlow wrote:
> >>>> On 01/29/2014 03:17 PM, Jason Greene wrote:
> >>>>
> >>>>> On Jan 29, 2014, at 2:11 PM, Scott Marlow <smarlow at redhat.com>
> wrote:
> >>>>>
> >>>>>> On 01/29/2014 02:44 PM, David M. Lloyd wrote:
> >>>>>>> On 01/29/2014 01:39 PM, Klein, Christopher wrote:
> >>>>>>> Hey guys,
> >>>>>>> I already filled out a feature request in JIRA
> (https://issues.jboss.org/browse/WFLY-2816).
> >>>>>>>
> >>>>>>> We have the situation that our development environment
> (currently JBoss AS 7.1.1) differs from the production instance (WebSphere
> 8.5). Our persistence.xml has to be adjusted for production environment:
> different jta-data-source, different properties. The dirty solution for this
> problem would be to generate separate build artifacts for both
> environments. As you can imagine I don't like the idea of having two binaries
> just because of a few different settings. Other options (WildFly or
> WebSphere specific JPA properties; extending Hibernate persistence
> provider) do not work.
> >>>>>>>
> >>>>>>> A much nicer solution would be: WildFly checks on deployment
> process for the existence of a jboss-persistence.xml. If it does, the jboss-
> persistence.xml is used for configuring the JPA subsystem. Otherwise it falls
> back to the standard persistence.xml. The jboss-persistence.xml would use
> the XML schema from persistence.xml.
> >>>>>>>
> >>>>>>> I lookup into the WildFly sources and this change should be an easy
> patch which I would provide.
> >>>>>>>
> >>>>>>> So here are my questsions:
> >>>>>>> 1. Are you generally interested in accepting such a pull request or is
> it a feature you don't want?
> >>>>>>> 2. Does another solution exists to my problem apart from
> generating different artifacts which makes this pull request needless?
> >>>>>>
> >>>>>> It sounds like a reasonable idea that actually applies generally.
> >>>>>> If I recall correctly, we have something of a mix today of
> >>>>>> descriptors which override versus supplementing existing
> >>>>>> configuration.  But overall the unofficial policy for new
> >>>>>> descriptors has been to add them in to jboss-all.xml as
> subdescriptors, FWIW.
> >>>>>
> >>>>> I'm not sure that jboss-all.xml would be a good place for the
> >>>>> persistence unit definitions.
> >>>>
> >>>> I would agree that this is probably impractical.
> >>>>
> >>>>>
> >>>>> I think that the proposed jboss-persistence.xml (or
> >>>>> wildfly-persistence.xml) could be helpful for anyone that wants to
> >>>>> only develop on WildFly but deploy on other application servers.
> >>>>> I suppose this could help someone that wants to migrate off of
> >>>>> WildFly as well (to prepare for a switch to something else).  Is
> >>>>> that what you mean by the proposed solution applying generally?
> >>>>
> >>>> It does sound a lot like a vendor specific alt-dd feature. We have some
> other solutions as well that might be relevant:
> >>>>
> >>>> 1) Deployment overlay feature - This allows you to override the
> descriptors in a deployment without modifying the deployment. These are
> added in a separate management op with a match pattern, and preserved
> outside the lifecycle of the deployment. Available in WildFly 8 and EAP 6.2
> (can’t recall if it made EAP 6.1).
> >>>
> >>> I was just reading
> >>> https://docs.jboss.org/author/display/WFLY8/Deployment+Overlays
> but
> >>> I'm not sure that would help with this use case.  Since the
> >>> deployment will fail due to the persistence.xml targeting WebSphere
> >>> (persistence unit property
> >>> "hibernate.transaction.manager_lookup_class" is set to
> "org.hibernate.transaction.WebSphereExtendedJTATransactionLookup").
> >>
> >> The persistence.xml that is the deployment overlay would not include
> >> those settings. The deployment overlay feature hides the original
> >> persistence.xml in the deployment archive from the deployment
> >> processors; they only see the overlay.
> >
> > Thanks Brian, I missed that the deployment overlay is created before
> > deploying.  So that could help someone crack open an archive and
> > replace the persistence.xml with one that will work.
> 
> Right exactly. The disadvantage is every update to the descriptor requires an
> updates overlay.
> 
> Just thinking out loud that we could do a proprietary alt-dd thing in jboss-
> all.xml where we allow you to set replacement names. E.g web.xml=other-
> web.xml etc.
> 
> Then we just parse this before anything else and it would apply AFTER
> overlay.

I wasn’t aware of the overlay feature and it would indeed solve my problem, but I think it has the following disadvantages:

-  The write-once-deploy-everywhere concept is a little bit broken. Every time I want to deploy the WAR into a new WildFly server I have to add the overlay command line. 
- As already mentioned, a change in persistence.xml means changing the overlay file in every application server. Just redeploying with a jboss-persistence.xml is much easier.
- As a developer just by looking at the source code I don't get it instantly that the settings in persistence.xml won't be used by WildFly. Having a jbos-persistence.xml in the same directory shows me that WildFly uses other settings without reading the whole documentation. Using the overlay seems to be counterintuitively.

I looked upon the WildFly sources, did a small hack and tested it yesterday - only to showing you what I want to achieve: https://github.com/schakko/wildfly/tree/WLDFLY-2816

> >
> >>
> >>> What might help is if we could ignore (or auto-magically remove
> >>> during
> >>> deployment) certain persistence unit property settings that we know
> >>> will cause the deployment to fail.
> >>>
> >>>>
> >>>> 2) Property Substituion - There is a flag you can optionally enable in
> standalone/domain.xml that allows descriptors to contain property
> expressions. However, this only works for this use case if all venders are
> using the same expression language (unlikely). I just thought I would
> mention it.
+1
During my research how to solve the problem I wrote a very simple persistence provider which extends Hibernate (https://gist.github.com/schakko/8703966). This provider allows you to define properties like 

	<!-- If env var applicationserver.runtime equals jboss, rewrite this setting -->
	<property name="?(applicationserver.runtime=jboss)hibernate.transaction.manager_lookup_class" value="" />

But this hasn't helped me to reference another jta-data-source :-/