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?

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 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?

_______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

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).

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

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.

> 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 >

> 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. 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.

> >> >>> 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