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

On Jan 29, 2014, at 3:33 PM, Scott Marlow <smarlow(a)redhat.com&gt; 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(a)redhat.com&gt; 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.

> >> 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. >>> >>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>> -- >>> Jason T. Greene >>> WildFly Lead / JBoss EAP Platform Architect >>> JBoss, a division of Red Hat >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev