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

[Scott Marlow]

On 01/29/2014 04:51 PM, Jason Greene wrote:
>
>
>> 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.

Being able to use alternative files in the deployment sounds like a nice 
compliment to the deployment overlay feature.  Could this be done 
transparently to the deployment processors or would each processor get 
involved in using the replacement name?

>
>
>>
>>>
>>>> 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 at 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 at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev