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?