If you dont want a PC in that deployment, dont put the
persistence.XML
file in the ear. I dont get the problem.
As Dan notice, IDE's (especially Eclipse JPA support) uses the standard
deploy structure to figure out the defaults automatically.
Eclipse JPA sucks because it can't support a persistence.xml in another
location;
Hibernate tools (actually hibernate core) also sucks because of this.
JBoss AS also sucks here if it forces a scan without the option to control
it.
Spring is actually good here since it allows you to use the default
structure or
simply specify your own location.
We should fix AS 5 to have something that can allow it to be disabled
(preferably
without having to change AS 5 structure deployers as Ales suggest)
Hibernate Tools will be adjusted (when I can) to do similar as Spring and
manually
build a persistence unit based on an alternative location.
Eclipse JPA will be harder because they only release once a year so even
if we
could fix it for them we can't see that fix before next summer.
btw. this is not a specific issues for persistence.xml; similar problems
exists
for any configuration file in JEE or any other framework where a specific
location
in the classpath is hardcoded (in either the framework or the tooling)
/max
Sent from my iPhone
On Dec 1, 2008, at 4:22 PM, "Dan Allen" <dan.j.allen(a)gmail.com> wrote:
> One of the changes in JBoss AS 5 that comes as a surprise for many
> Seam developers/users familiar with the behavior of JBoss AS 4 is the
> automatic loading of persistence units from /META-INF/persistence.xml.
> (As expected, we had to change several of the Seam examples to
> accommodate this change). This is one of those configuration by
> exception features in Java EE 5, with one significant exception. While
> the container will locate the /META-INF/persistence.xml file on its
> own, a container that goes by the book will only deploy the
> persistence unit if a resource reference is declared in the descriptor
> file (web.xml or ejb-jar.xml). JBoss AS does not wait for this signal.
>
> In my opinion, there is a problem with the JBoss AS approach. What if
> you have persistence units that you don't want to deploy? One use case
> is that you have persistence units for different environments and a
> configuration file can toggle between them. Another use case is that
> you have another library, such as Spring or Seam, which bootstraps the
> persistence unit instead. Sure, you could rename the file, but then
> you break all the IDE behavior that expects the file to be named
> persistence.xml. Personally, I think there should be some way to
> disable the behavior in JBoss AS and make it look for the persistence
> unit references. I agree to keep the automatic loading as the default,
> but it is pretty inconvenient not to be able to disable it.
>
> Anyone else agree? Disagree? Why?
>
> -Dan
>
> --Dan Allen
> Software consultant | Author of Seam in Action
>
>
http://mojavelinux.com
>
http://mojavelinux.com/seaminaction
>
> NOTE: While I make a strong effort to keep up with my email on a daily
> basis, personal or other work matters can sometimes keep me away
> from my email. If you contact me, but don't hear back for more than a
> week,
> it is very likely that I am excessively backlogged or the message was
> caught in the spam filters. Please don't hesitate to resend a message
> if
> you feel that it did not reach my attention.
> _______________________________________________
> seam-dev mailing list
> seam-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/seam-dev
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev