Aaron Mulder wrote: > On 8/11/06, Jeff Genender <[EMAIL PROTECTED]> wrote: >> Isn't this the same problem we (and other app servers) have with Spring >> and Commons Logging? If you are duplicating the persistence units, then >> it should be handled the same way its handled for Spring, yes? > > What way is that?
Server --> EAR --> WAR Based upon the delegation model, the version of Commons Logging or Spring was utilized at the Server or EAR level if it existed. The issue was that the Spring calls would utilize the Server/EAR (since already loaded) and the WAR calls would get CNFEs since the server/EAR had no downward view into the WAR. Thus our reason to play with the filtering of classes for modules. With regard to duplicating PUs, in theory, it shouldn't make a difference if the PU was already loaded in a parent loader. But unless the spi jar uses some sort of mechanism using static declarations or componanents like Spring, then it really shouldn't be an issue. If it is, I think its reasonable to claim storage of duplicate PUs in the same package causing the problem (again, like the Spring Commons Logging problem). > > Thanks, > Aaron > >> Aaron Mulder wrote: >> > So what happens if an EJB JAR has a persistence.xml and a web app in >> > the same EAR has a separate persistence.xml? If we just look in the >> > class loader, when we go to deploy the web app, we'll see them both >> > because the EJB JAR is added to the parent classpath of the WAR. Is >> > there a good way to distinguish "resource in my ClassLoader" from >> > "resources in my ClassLoader tree"? >> > >> > Thanks, >> > Aaron >>
