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> 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.
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
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat