On Dec 5, 2006, at 1:28 AM, Manu George wrote:
Hi David,
Yes you are right as always :-). I missed that I could
use the loadPersistence method instead of deploy. I plan to add an
overloaded deploy(URLClassLoader) and do a findResource on the
URLClassLoader to get it right.
Definitely don't do that. We had some of that code and it just never
works when the classloader structure is flat and there are
persistence.xml files everywhere or when the parent classloader
happens to have a persistence.xml or two and you and up getting those
as well.
So all of it was yanked and what we now do is to create a
ResourceFinder using the classloader *and* the URL as the constructor
parameters. Then you can use the ResourceFinder instance to get the
persistence.xml files that exist only in the URL you passed in.
Check out DeploymentLoader, it uses ResourceFinder a ton.
-David
On 12/5/06, David Blevins <[EMAIL PROTECTED]> wrote:
On Dec 4, 2006, at 1:38 PM, David Blevins wrote:
>
> On Dec 4, 2006, at 1:32 PM, David Blevins wrote:
>
>> On Dec 4, 2006, at 1:11 PM, Manu George wrote:
>>
>>> Hi David B,
>>> I have the patch ready for the Persistence-Unit-Ref. On
>>> writing a test and adding the persistence.xml to the
>>> openejb-itests-beans what happens is some other tests start
failing.
>>> eg: StatelessContainerTest. The reason for this is that the
>>> persistence.xml from openejb-itests-beans gets picked up by the
>>> PersistenceDeployer when it runs tests in other modules that have
>>> dependency on this module. Then it tries to deploy it again and
>>> results in errors. So I think for tests in other modules some
>>> mechanism should be there to prevent persistence.xmls from parent
>>> modules to be picked up.
>>>
>>> Another thing that I notice is that the persistence deployer
deploys
>>> each persistence.xml twice as
>>> cl.getResources("META-INF/persistence.xml") always returns two
>>> urls to
>>> the same resource. This results in the loadPersistence method
being
>>> called twice. Shouldn't this be changed?
>>>
>>> Thirdly what if in two different jars there are two different
>>> EntityManagerFactories with the same name. We should be able to
>>> refer
>>> to them by relative paths. I think this is not supported by the
>>> PersistenceDeployer now.
>>
>> Hmmm. I still think you should use the
>> PersistenceDeployer.loadPersistence method directly to get all the
>> EntityManagerFactories as I noted before. I think that'd address
>> everything you mentioned.
>>
>> Thoughts?
>>
>
> to ripe it into two parts
s/ripe/rip/
(typing too fast)
-David
> : one part in the config that creates the infos and passes them
> through to the Assembler, and another part in the Assembler that
> creates the EntityManagerFactories and puts them into JNDI.
> Anyway, It's fine for now using the PersistenceDeplployer in the
> Assembler.
>
> -David
>
