You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Manu George <ma...@gmail.com> on 2006/12/01 21:02:09 UTC
Re: Container coding tasks
Hi David B,Jacek,Mohammad
I have a doubt in this JIRA. There is a class called
EntityManagerFactoryCache which is an object factory already present
in OEJB. It also has variables to store all the
EntityManagerFactories. Should this be used to store all the
factories. If it is used then shouldn't the cache variable be static?.
If this is used then the first time a person looks up the
EntityManagerFactories it will take some time. Is this acceptable or
should this process be done during deployment?
Thanks
Manu
On 11/30/06, Manu George <ma...@gmail.com> wrote:
> Hi Jacek,
> Point Taken. I just need to get a bit familiar with
> persistence.xmls and get an idea on how JPA works with EJB. Some user
> level knowledge of openJPA also is required I guess. Will start
> working on the JIRA.
>
> Thanks
> Manu
>
> On 11/29/06, Jacek Laskowski <ja...@laskowski.net.pl> wrote:
> > On 11/29/06, Manu George <ma...@gmail.com> wrote:
> > > Hi David B,
> > > I will be happy to take this up. I guess I need to go
> > > through the JPA spec/OpenJPA before starting on this as I have not yet
> > > done that. This issue will give me the drive to do that :-).
> >
> > I don't think you'll need to o into the details of (Open)JPA. As far
> > as I understand it, the point Dave made was that everything that's
> > required is in openejb-persistence and the last missing puzzle is to
> > plug it into JNDI tree.
> >
> > Jacek
> >
> > --
> > Jacek Laskowski
> > http://www.jaceklaskowski.pl
> >
>
Re: Container coding tasks
Posted by David Blevins <da...@visi.com>.
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 <da...@visi.com> 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
>> >
>>
>>
>
Re: Container coding tasks
Posted by Manu George <ma...@gmail.com>.
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.
Thanks
Manu
On 12/5/06, David Blevins <da...@visi.com> 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
> >
>
>
Re: Container coding tasks
Posted by David Blevins <da...@visi.com>.
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
>
Re: Container coding tasks
Posted by David Blevins <da...@visi.com>.
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?
>
I'll also note that none of that code is set in stone and we very
well may want to ripe it into two parts: 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
Re: Container coding tasks
Posted by David Blevins <da...@visi.com>.
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?
-David
Re: Container coding tasks
Posted by Manu George <ma...@gmail.com>.
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.
Pls give your comments on the above
Thanks
Manu
On 12/4/06, Dain Sundstrom <da...@iq80.com> wrote:
> On Dec 3, 2006, at 11:11 PM, David Blevins wrote:
>
> >
> > On Dec 3, 2006, at 10:09 PM, Manu George wrote:
> >
> >> Hi David,
> >> I have already done that. I will get the
> >> EntityManagerFactory But for getting the entity manager I need to
> >> write a class OpenEJBManagedRuntime implements ManagedRuntime which
> >> looks up the transaction manager of openejb and gives it to
> >> openjpa. I
> >> got that done too.
> >
> > OpenJPA already has an implementation for OpenEJB, but now that you
> > mention it I remember it's using
> > org.openejb.OpenEJB.getTransactionManager() which is now
> > org.apache.openejb.OpenEJB. I've just checked back in an
> > org.openejb.OpenEJB class for compatibility. I'll drop them a note
> > to update this class to the latest:
> >
> > http://incubator.apache.org/openjpa/docs/openjpa-0.9.0-incubating/
> > javadoc/org/apache/openjpa/ee/AutomaticManagedRuntime.html
>
> I was playing with the JPA stuff last night and had to bid the
> transaction manager into java:TransactionManager. The tests in
> openejb-presistence do this with a special java: naming handler:
>
> https://svn.apache.org/repos/asf/incubator/openejb/trunk/openejb3/
> container/openejb-persistence/src/test/java/org/apache/openejb/
> persistence/java/javaURLContextFactory.java
>
> It would be nice if we could give the JPA implementation the
> transaction manager directly.
>
> -dain
>
Re: Container coding tasks
Posted by Dain Sundstrom <da...@iq80.com>.
On Dec 3, 2006, at 11:11 PM, David Blevins wrote:
>
> On Dec 3, 2006, at 10:09 PM, Manu George wrote:
>
>> Hi David,
>> I have already done that. I will get the
>> EntityManagerFactory But for getting the entity manager I need to
>> write a class OpenEJBManagedRuntime implements ManagedRuntime which
>> looks up the transaction manager of openejb and gives it to
>> openjpa. I
>> got that done too.
>
> OpenJPA already has an implementation for OpenEJB, but now that you
> mention it I remember it's using
> org.openejb.OpenEJB.getTransactionManager() which is now
> org.apache.openejb.OpenEJB. I've just checked back in an
> org.openejb.OpenEJB class for compatibility. I'll drop them a note
> to update this class to the latest:
>
> http://incubator.apache.org/openjpa/docs/openjpa-0.9.0-incubating/
> javadoc/org/apache/openjpa/ee/AutomaticManagedRuntime.html
I was playing with the JPA stuff last night and had to bid the
transaction manager into java:TransactionManager. The tests in
openejb-presistence do this with a special java: naming handler:
https://svn.apache.org/repos/asf/incubator/openejb/trunk/openejb3/
container/openejb-persistence/src/test/java/org/apache/openejb/
persistence/java/javaURLContextFactory.java
It would be nice if we could give the JPA implementation the
transaction manager directly.
-dain
Re: Container coding tasks
Posted by David Blevins <da...@visi.com>.
On Dec 3, 2006, at 10:09 PM, Manu George wrote:
> Hi David,
> I have already done that. I will get the
> EntityManagerFactory But for getting the entity manager I need to
> write a class OpenEJBManagedRuntime implements ManagedRuntime which
> looks up the transaction manager of openejb and gives it to openjpa. I
> got that done too.
OpenJPA already has an implementation for OpenEJB, but now that you
mention it I remember it's using
org.openejb.OpenEJB.getTransactionManager() which is now
org.apache.openejb.OpenEJB. I've just checked back in an
org.openejb.OpenEJB class for compatibility. I'll drop them a note
to update this class to the latest:
http://incubator.apache.org/openjpa/docs/openjpa-0.9.0-incubating/
javadoc/org/apache/openjpa/ee/AutomaticManagedRuntime.html
-David
> But need to resolve some errors coming in other
> modules due to my changes :-( . Will post a patch as soon as I resolve
> those errors.
>
> Thanks
> Manu
>
> On 12/4/06, David Blevins <da...@visi.com> wrote:
>>
>> On Dec 3, 2006, at 1:53 PM, Manu George wrote:
>>
>> > Hi David B ,
>> > I got it working i.e am able to get the
>> EntityManagerFactory
>> > from JNDI. In the persistence.xml I have to give the jta
>> datasource as
>> > java:openejb/connector/Default JDBC Database for the default
>> > datasource
>> > Is this approach acceptable? Or should it be in the
>> > java:comp/env/jdbc/datasource format?
>>
>> Excellent! That's a great first run. It is supposed to be of the
>> java:comp/env variety, but using "java:openejb/connector/Default JDBC
>> Database" will work just fine to start with. We'll likely have to
>> rework the code a bit to support the java:comp/env thing.
>>
>> Anyone want to update the Enc*Bean tests to test lookup of
>> PersistenceUnits?
>>
>> -David
>>
>> > Thanks
>> > Manu
>> >
>> > On 12/2/06, David Blevins <da...@visi.com> wrote:
>> >>
>> >> On Dec 1, 2006, at 12:02 PM, Manu George wrote:
>> >>
>> >> > I have a doubt in this JIRA. There is a class
>> called
>> >> > EntityManagerFactoryCache which is an object factory already
>> >> present
>> >> > in OEJB. It also has variables to store all the
>> >> > EntityManagerFactories.
>> >>
>> >> You probably don't want to use that object. Likely somewhere
>> in the
>> >> EjbJarBuilder you'll use the PersistenceDeployer.loadPersistence
>> >> method directly to get all the EntityManagerFactories. Then
>> you'll
>> >> probably want to pass that map into the constructor of the
>> >> EnterpriseBeanBuilder and then into the constructor of the
>> >> JndiEncBuilder.
>> >>
>> >> In the JndiEncBuilder you'll add a new method to process all the
>> >> PersistenceUnitInfo objects in JndiEncInfo. Of course the
>> >> PersistenceUnitInfo class doesn't exist yet, let me just create
>> that
>> >> to make this first one easy. Ok, see this commit:
>> >>
>> >> http://svn.apache.org/viewvc?view=rev&revision=481478
>> >>
>> >> (ignore that change to JndiEncBuilder, that was unrelated)
>> >>
>> >> You'll need to implement the method
>> >> JndiEncInfoBuilder.buildPersistenceUnitRefInfos() created with
>> that
>> >> commit.
>> >>
>> >> > I also noticed that there are two Reference interfaces in OEJB
>> >> > in org.apache.openejb.core.ivm.naming and
>> org.apache.openejb.naming
>> >> > packages. What is the significance of having two? Why don't any
>> >> of the
>> >> > references extend from the javax.naming package?
>> >>
>> >> Our current JNDI implementation is just a bit obtuse. I
>> predict at
>> >> some point in the future we may ditch it for the xbean-naming
>> >> implementation which is a bit nicer. Till then just create an
>> >> implementation of org.apache.openejb.core.ivm.naming.Reference and
>> >> pass the EntityManagerFactory right in the constructor.
>> >>
>> >> We may want to switch it to create the EntityManagerFactory inside
>> >> the getObject method of the Reference class, but this is good
>> enough
>> >> for now. We'll see what the TCK has to say about it when the time
>> >> comes.
>> >>
>> >> -David
>> >>
>> >>
>> >>
>> >>
>> >
>>
>>
>
Re: Container coding tasks
Posted by Manu George <ma...@gmail.com>.
Hi David,
I have already done that. I will get the
EntityManagerFactory But for getting the entity manager I need to
write a class OpenEJBManagedRuntime implements ManagedRuntime which
looks up the transaction manager of openejb and gives it to openjpa. I
got that done too. But need to resolve some errors coming in other
modules due to my changes :-( . Will post a patch as soon as I resolve
those errors.
Thanks
Manu
On 12/4/06, David Blevins <da...@visi.com> wrote:
>
> On Dec 3, 2006, at 1:53 PM, Manu George wrote:
>
> > Hi David B ,
> > I got it working i.e am able to get the EntityManagerFactory
> > from JNDI. In the persistence.xml I have to give the jta datasource as
> > java:openejb/connector/Default JDBC Database for the default
> > datasource
> > Is this approach acceptable? Or should it be in the
> > java:comp/env/jdbc/datasource format?
>
> Excellent! That's a great first run. It is supposed to be of the
> java:comp/env variety, but using "java:openejb/connector/Default JDBC
> Database" will work just fine to start with. We'll likely have to
> rework the code a bit to support the java:comp/env thing.
>
> Anyone want to update the Enc*Bean tests to test lookup of
> PersistenceUnits?
>
> -David
>
> > Thanks
> > Manu
> >
> > On 12/2/06, David Blevins <da...@visi.com> wrote:
> >>
> >> On Dec 1, 2006, at 12:02 PM, Manu George wrote:
> >>
> >> > I have a doubt in this JIRA. There is a class called
> >> > EntityManagerFactoryCache which is an object factory already
> >> present
> >> > in OEJB. It also has variables to store all the
> >> > EntityManagerFactories.
> >>
> >> You probably don't want to use that object. Likely somewhere in the
> >> EjbJarBuilder you'll use the PersistenceDeployer.loadPersistence
> >> method directly to get all the EntityManagerFactories. Then you'll
> >> probably want to pass that map into the constructor of the
> >> EnterpriseBeanBuilder and then into the constructor of the
> >> JndiEncBuilder.
> >>
> >> In the JndiEncBuilder you'll add a new method to process all the
> >> PersistenceUnitInfo objects in JndiEncInfo. Of course the
> >> PersistenceUnitInfo class doesn't exist yet, let me just create that
> >> to make this first one easy. Ok, see this commit:
> >>
> >> http://svn.apache.org/viewvc?view=rev&revision=481478
> >>
> >> (ignore that change to JndiEncBuilder, that was unrelated)
> >>
> >> You'll need to implement the method
> >> JndiEncInfoBuilder.buildPersistenceUnitRefInfos() created with that
> >> commit.
> >>
> >> > I also noticed that there are two Reference interfaces in OEJB
> >> > in org.apache.openejb.core.ivm.naming and org.apache.openejb.naming
> >> > packages. What is the significance of having two? Why don't any
> >> of the
> >> > references extend from the javax.naming package?
> >>
> >> Our current JNDI implementation is just a bit obtuse. I predict at
> >> some point in the future we may ditch it for the xbean-naming
> >> implementation which is a bit nicer. Till then just create an
> >> implementation of org.apache.openejb.core.ivm.naming.Reference and
> >> pass the EntityManagerFactory right in the constructor.
> >>
> >> We may want to switch it to create the EntityManagerFactory inside
> >> the getObject method of the Reference class, but this is good enough
> >> for now. We'll see what the TCK has to say about it when the time
> >> comes.
> >>
> >> -David
> >>
> >>
> >>
> >>
> >
>
>
Applied OPENEJB-383 ENC: persistence-unit-ref
Posted by Dain Sundstrom <da...@iq80.com>.
Manu,
I applied the test patch and closed the issue. The patch was very
clean... good work.
Thanks for the patch!
-dain
On Dec 19, 2006, at 12:20 PM, Dain Sundstrom wrote:
> I'll take this one.
>
> -dain
>
> On Dec 12, 2006, at 3:30 AM, Manu George wrote:
>
>> Hi David B,
>> I have attached a patch patch[2]_r485581_OPENEJB-383.patch
>> for the change mentioned below. Sorry r485581 in the name should be
>> actually r486099. copy paste error :)
>>
>> Regards
>> Manu
>>
>> On 12/12/06, Manu George <ma...@gmail.com> wrote:
>>> Hi David B,
>>> I will be happy to do it.
>>>
>>> Thanks
>>> Manu
>>>
>>> On 12/12/06, David Blevins <da...@visi.com> wrote:
>>> > On Dec 11, 2006, at 2:39 AM, Manu George wrote:
>>> >
>>> > > Hi Dave B,
>>> > > I have attached a modified patch for your review.
>>> The file
>>> > > is patch[1]_r485581_OPENEJB-383.patch and all the tests pass
>>> with this
>>> > > patch.
>>> > > Pls let me know if there are any problems with the approach.
>>> >
>>> > The patch looks great. It's been committed and is in svn now!
>>> >
>>> > I'm going to move the Customer entity into
>>> org.apache.test.beans were
>>> > we put are other 'test-generic' beans. Also going to split that
>>> > EncStatelessBean.lookupResource into two methods
>>> (lookupResource and
>>> > lookupPersistenceUnit) and add it to all the Enc*Beans and make
>>> a new
>>> > test method in the *JndiEncTests classes. If you'd rather do the
>>> > work, let me know and I'll save it for you.
>>> >
>>> > -David
>>> >
>>> > >
>>> > > Thanks
>>> > > Manu
>>> > >
>>> > > On 12/7/06, Manu George <ma...@gmail.com> wrote:
>>> > >> Hi Dave B,
>>> > >> I have attached a patch for JIRA OPENEJB-383.
>>> Please review
>>> > >> when convenient and let me know your comments. There is a
>>> test for
>>> > >> stateless session beans included.
>>> > >>
>>> > >> Thanks and Regards
>>> > >> Manu
>>> > >>
>>> > >> On 12/6/06, Manu George <ma...@gmail.com> wrote:
>>> > >> > Hi Dave B,
>>> > >> > If you have not spent time reviewing the
>>> code pls
>>> > >> don't.
>>> > >> > I have made a blunder in it. I will post the final patch
>>> > >> hopefully by
>>> > >> > tomorrow.
>>> > >> >
>>> > >> > Thanks
>>> > >> > Manu
>>> > >> >
>>> > >> > On 12/6/06, Manu George <ma...@gmail.com> wrote:
>>> > >> > > Hi Dave B,
>>> > >> > > It has been a good learning for me working on
>>> > >> this with
>>> > >> > > you. I want to thank you for the patience shown and the
>>> > >> explanations.
>>> > >> > > Thanks for the advice regarding Resource Finder. I was
>>> facing the
>>> > >> > > exact errors that you mentioned and trying to resolve them
>>> > >> which was
>>> > >> > > eating up my time :(. I have not yet implemented this in
>>> the
>>> > >> spring
>>> > >> > > assembler and so the test i wrote for testing this fail on
>>> > >> running
>>> > >> > > using the Spring assembler. Now I am facing some new test
>>> > >> failures in
>>> > >> > > Cmp beans after an svn up. I think they are related to
>>> some other
>>> > >> > > check-ins. Anyway I am attaching a patch of whatever is
>>> done
>>> > >> up till
>>> > >> > > now i.e
>>> > >> > > PersistenceUnitRef for classic assembler + some
>>> modification
>>> > >> in spring
>>> > >> > > assembler(DeploymentsFactory).
>>> > >> > >
>>> > >> > > Also there is a test which will fail for spring
>>> Assembler but
>>> > >> work for
>>> > >> > > others. Please have a look and comment. I guess after david
>>> > >> jencks
>>> > >> > > post abt this being already implemented in Geronimo, this
>>> > >> > > implementation may not be required. So shall I stop
>>> working on
>>> > >> it? or
>>> > >> > > create the final patch (after finding out the cause of
>>> the new
>>> > >> errors,
>>> > >> > > refactoring and maybe spring assembler integration(a
>>> pointer
>>> > >> from you
>>> > >> > > on where to look will make things easier).) and post
>>> > >> > >
>>> > >> > > P.S. The JndiEncBuilder.findEntityManagerFactory method
>>> is not
>>> > >> yet
>>> > >> > > fully implemented. I saw the method for ejbLink resolution
>>> > >> but if I
>>> > >> > > follow that approach i think it will not work here.
>>> > >> > >
>>> > >> > > Thanks
>>> > >> > > Manu
>>> > >> > >
>>> > >> > > On 12/6/06, David Blevins <da...@visi.com> wrote:
>>> > >> > > >
>>> > >> > > > On Dec 5, 2006, at 11:49 AM, David Jencks wrote:
>>> > >> > > >
>>> > >> > > > >
>>> > >> > > > > On Dec 5, 2006, at 11:01 AM, David Blevins wrote:
>>> > >> > > > >
>>> > >> > > > >>
>>> > >> > > > >> On Dec 5, 2006, at 10:47 AM, David Jencks wrote:
>>> > >> > > > >>
>>> > >> > > > >>>
>>> > >> > > > >>> On Dec 3, 2006, at 4:11 PM, David Blevins wrote:
>>> > >> > > > >>>
>>> > >> > > > >>>>
>>> > >> > > > >>>> On Dec 3, 2006, at 1:53 PM, Manu George wrote:
>>> > >> > > > >>>>
>>> > >> > > > >>>>> Hi David B ,
>>> > >> > > > >>>>> I got it working i.e am able to get the
>>> > >> > > > >>>>> EntityManagerFactory
>>> > >> > > > >>>>> from JNDI. In the persistence.xml I have to give
>>> the jta
>>> > >> > > > >>>>> datasource as
>>> > >> > > > >>>>> java:openejb/connector/Default JDBC Database for
>>> the
>>> > >> default
>>> > >> > > > >>>>> datasource
>>> > >> > > > >>>>> Is this approach acceptable? Or should it be in the
>>> > >> > > > >>>>> java:comp/env/jdbc/datasource format?
>>> > >> > > > >>>>
>>> > >> > > > >>>> Excellent! That's a great first run. It is
>>> supposed
>>> > >> to be of
>>> > >> > > > >>>> the java:comp/env variety,
>>> > >> > > > >>>
>>> > >> > > > >>> I disagree. As I understand it, the jpa EMF is
>>> > >> something you
>>> > >> > > > >>> configure in the server, not per ejb. Thus the
>>> > >> datasource it
>>> > >> > > > >>> uses should not change depending on which ejb
>>> happens to
>>> > >> be using
>>> > >> > > > >>> it.
>>> > >> > > > >>
>>> > >> > > > >> Took a closer look at the tck and it looks like you're
>>> > >> right. I
>>> > >> > > > >> assume then that the way you specify a global data
>>> source
>>> > >> name is
>>> > >> > > > >> vendor specific and no spec defined?
>>> > >> > > > >
>>> > >> > > > > That's right! seems a little odd to me, but it's
>>> > >> specifically
>>> > >> > > > > container dependent. In g. I'm using an abstract name
>>> > >> query, which
>>> > >> > > > > typically means "name=MyDataSource"
>>> > >> > > >
>>> > >> > > > Huh, had I been completely aware of that during the ejb3
>>> > >> expert group
>>> > >> > > > I could have used that as an additional argument for my
>>> > >> proposed app-
>>> > >> > > > based JNDI ENC (i.e. being able to configure a JNDI
>>> tree for
>>> > >> a whole
>>> > >> > > > ejb-jar like you can for servlets). Maybe for EJB 3.1.
>>> > >> > > >
>>> > >> > > > >> On the same note was the code that creates EMFs in
>>> > >> openejb3 useful
>>> > >> > > > >> when you created the one in geronimo/openejb2? Hope
>>> > >> there was
>>> > >> > > > >> something in there you could reuse.
>>> > >> > > > >
>>> > >> > > > > Yes, it was very helpful. One piece that is still
>>> missing
>>> > >> from the
>>> > >> > > > > deployer code is the part that looks around for any
>>> stray
>>> > >> > > > > persistence.xml files you might have hidden in your
>>> app.
>>> > >> Do I
>>> > >> > > > > recall correctly that you have some code that does
>>> this?
>>> > >> You might
>>> > >> > > > > even have offered to put that code in the g.
>>> deployer, but a
>>> > >> > > > > pointer to it would also be great :-)
>>> > >> > > >
>>> > >> > > > No need to offer what's already yours :) You want the
>>> > >> ResourceFinder:
>>> > >> > > >
>>> > >> > > > http://svn.apache.org/repos/asf/geronimo/xbean/trunk/
>>> > >> xbean-finder/
>>> > >> > > > src/main/java/org/apache/xbean/finder/ResourceFinder.java
>>> > >> > > >
>>> > >> > > > Originally written by me in OpenEJB and moved into
>>> XBean around
>>> > >> > > > JavaOne. Check out the
>>> ResourceFinderTest.testUrlConstructor
>>> > >> ().
>>> > >> > > > Though, I have been wanting to do something like in
>>> > >> ClassFinder in
>>> > >> > > > ResourceFinder, namely being able to say 'search this
>>> > >> classloader,
>>> > >> > > > but not the parent classloader' or 'search this
>>> classloader and
>>> > >> > > > parent classloaders up until this particular parent
>>> > >> classloader'.
>>> > >> > > > But you can essentially get that same result with some
>>> work
>>> > >> passing
>>> > >> > > > in the URLs you want to search.
>>> > >> > > >
>>> > >> > > > Anyway, if it turns out your more after then classloader
>>> > >> "range" type
>>> > >> > > > of thing rather than the explicit URL list searching,
>>> just
>>> > >> let me
>>> > >> > > > know cause I've been looking for a reason to plumb
>>> that in.
>>> > >> > > >
>>> > >> > > > -David
>>> > >> > > >
>>> > >> > > >
>>> > >> > >
>>> > >> > >
>>> > >> > >
>>> > >> >
>>> > >>
>>> > >
>>> >
>>> >
>>>
Re: Container coding tasks
Posted by Dain Sundstrom <da...@iq80.com>.
I'll take this one.
-dain
On Dec 12, 2006, at 3:30 AM, Manu George wrote:
> Hi David B,
> I have attached a patch patch[2]_r485581_OPENEJB-383.patch
> for the change mentioned below. Sorry r485581 in the name should be
> actually r486099. copy paste error :)
>
> Regards
> Manu
>
> On 12/12/06, Manu George <ma...@gmail.com> wrote:
>> Hi David B,
>> I will be happy to do it.
>>
>> Thanks
>> Manu
>>
>> On 12/12/06, David Blevins <da...@visi.com> wrote:
>> > On Dec 11, 2006, at 2:39 AM, Manu George wrote:
>> >
>> > > Hi Dave B,
>> > > I have attached a modified patch for your review.
>> The file
>> > > is patch[1]_r485581_OPENEJB-383.patch and all the tests pass
>> with this
>> > > patch.
>> > > Pls let me know if there are any problems with the approach.
>> >
>> > The patch looks great. It's been committed and is in svn now!
>> >
>> > I'm going to move the Customer entity into org.apache.test.beans
>> were
>> > we put are other 'test-generic' beans. Also going to split that
>> > EncStatelessBean.lookupResource into two methods (lookupResource
>> and
>> > lookupPersistenceUnit) and add it to all the Enc*Beans and make
>> a new
>> > test method in the *JndiEncTests classes. If you'd rather do the
>> > work, let me know and I'll save it for you.
>> >
>> > -David
>> >
>> > >
>> > > Thanks
>> > > Manu
>> > >
>> > > On 12/7/06, Manu George <ma...@gmail.com> wrote:
>> > >> Hi Dave B,
>> > >> I have attached a patch for JIRA OPENEJB-383. Please
>> review
>> > >> when convenient and let me know your comments. There is a
>> test for
>> > >> stateless session beans included.
>> > >>
>> > >> Thanks and Regards
>> > >> Manu
>> > >>
>> > >> On 12/6/06, Manu George <ma...@gmail.com> wrote:
>> > >> > Hi Dave B,
>> > >> > If you have not spent time reviewing the code
>> pls
>> > >> don't.
>> > >> > I have made a blunder in it. I will post the final patch
>> > >> hopefully by
>> > >> > tomorrow.
>> > >> >
>> > >> > Thanks
>> > >> > Manu
>> > >> >
>> > >> > On 12/6/06, Manu George <ma...@gmail.com> wrote:
>> > >> > > Hi Dave B,
>> > >> > > It has been a good learning for me working on
>> > >> this with
>> > >> > > you. I want to thank you for the patience shown and the
>> > >> explanations.
>> > >> > > Thanks for the advice regarding Resource Finder. I was
>> facing the
>> > >> > > exact errors that you mentioned and trying to resolve them
>> > >> which was
>> > >> > > eating up my time :(. I have not yet implemented this in the
>> > >> spring
>> > >> > > assembler and so the test i wrote for testing this fail on
>> > >> running
>> > >> > > using the Spring assembler. Now I am facing some new test
>> > >> failures in
>> > >> > > Cmp beans after an svn up. I think they are related to
>> some other
>> > >> > > check-ins. Anyway I am attaching a patch of whatever is done
>> > >> up till
>> > >> > > now i.e
>> > >> > > PersistenceUnitRef for classic assembler + some modification
>> > >> in spring
>> > >> > > assembler(DeploymentsFactory).
>> > >> > >
>> > >> > > Also there is a test which will fail for spring Assembler
>> but
>> > >> work for
>> > >> > > others. Please have a look and comment. I guess after david
>> > >> jencks
>> > >> > > post abt this being already implemented in Geronimo, this
>> > >> > > implementation may not be required. So shall I stop
>> working on
>> > >> it? or
>> > >> > > create the final patch (after finding out the cause of
>> the new
>> > >> errors,
>> > >> > > refactoring and maybe spring assembler integration(a pointer
>> > >> from you
>> > >> > > on where to look will make things easier).) and post
>> > >> > >
>> > >> > > P.S. The JndiEncBuilder.findEntityManagerFactory method
>> is not
>> > >> yet
>> > >> > > fully implemented. I saw the method for ejbLink resolution
>> > >> but if I
>> > >> > > follow that approach i think it will not work here.
>> > >> > >
>> > >> > > Thanks
>> > >> > > Manu
>> > >> > >
>> > >> > > On 12/6/06, David Blevins <da...@visi.com> wrote:
>> > >> > > >
>> > >> > > > On Dec 5, 2006, at 11:49 AM, David Jencks wrote:
>> > >> > > >
>> > >> > > > >
>> > >> > > > > On Dec 5, 2006, at 11:01 AM, David Blevins wrote:
>> > >> > > > >
>> > >> > > > >>
>> > >> > > > >> On Dec 5, 2006, at 10:47 AM, David Jencks wrote:
>> > >> > > > >>
>> > >> > > > >>>
>> > >> > > > >>> On Dec 3, 2006, at 4:11 PM, David Blevins wrote:
>> > >> > > > >>>
>> > >> > > > >>>>
>> > >> > > > >>>> On Dec 3, 2006, at 1:53 PM, Manu George wrote:
>> > >> > > > >>>>
>> > >> > > > >>>>> Hi David B ,
>> > >> > > > >>>>> I got it working i.e am able to get the
>> > >> > > > >>>>> EntityManagerFactory
>> > >> > > > >>>>> from JNDI. In the persistence.xml I have to give
>> the jta
>> > >> > > > >>>>> datasource as
>> > >> > > > >>>>> java:openejb/connector/Default JDBC Database for the
>> > >> default
>> > >> > > > >>>>> datasource
>> > >> > > > >>>>> Is this approach acceptable? Or should it be in the
>> > >> > > > >>>>> java:comp/env/jdbc/datasource format?
>> > >> > > > >>>>
>> > >> > > > >>>> Excellent! That's a great first run. It is supposed
>> > >> to be of
>> > >> > > > >>>> the java:comp/env variety,
>> > >> > > > >>>
>> > >> > > > >>> I disagree. As I understand it, the jpa EMF is
>> > >> something you
>> > >> > > > >>> configure in the server, not per ejb. Thus the
>> > >> datasource it
>> > >> > > > >>> uses should not change depending on which ejb
>> happens to
>> > >> be using
>> > >> > > > >>> it.
>> > >> > > > >>
>> > >> > > > >> Took a closer look at the tck and it looks like you're
>> > >> right. I
>> > >> > > > >> assume then that the way you specify a global data
>> source
>> > >> name is
>> > >> > > > >> vendor specific and no spec defined?
>> > >> > > > >
>> > >> > > > > That's right! seems a little odd to me, but it's
>> > >> specifically
>> > >> > > > > container dependent. In g. I'm using an abstract name
>> > >> query, which
>> > >> > > > > typically means "name=MyDataSource"
>> > >> > > >
>> > >> > > > Huh, had I been completely aware of that during the ejb3
>> > >> expert group
>> > >> > > > I could have used that as an additional argument for my
>> > >> proposed app-
>> > >> > > > based JNDI ENC (i.e. being able to configure a JNDI
>> tree for
>> > >> a whole
>> > >> > > > ejb-jar like you can for servlets). Maybe for EJB 3.1.
>> > >> > > >
>> > >> > > > >> On the same note was the code that creates EMFs in
>> > >> openejb3 useful
>> > >> > > > >> when you created the one in geronimo/openejb2? Hope
>> > >> there was
>> > >> > > > >> something in there you could reuse.
>> > >> > > > >
>> > >> > > > > Yes, it was very helpful. One piece that is still
>> missing
>> > >> from the
>> > >> > > > > deployer code is the part that looks around for any
>> stray
>> > >> > > > > persistence.xml files you might have hidden in your app.
>> > >> Do I
>> > >> > > > > recall correctly that you have some code that does this?
>> > >> You might
>> > >> > > > > even have offered to put that code in the g.
>> deployer, but a
>> > >> > > > > pointer to it would also be great :-)
>> > >> > > >
>> > >> > > > No need to offer what's already yours :) You want the
>> > >> ResourceFinder:
>> > >> > > >
>> > >> > > > http://svn.apache.org/repos/asf/geronimo/xbean/trunk/
>> > >> xbean-finder/
>> > >> > > > src/main/java/org/apache/xbean/finder/ResourceFinder.java
>> > >> > > >
>> > >> > > > Originally written by me in OpenEJB and moved into
>> XBean around
>> > >> > > > JavaOne. Check out the
>> ResourceFinderTest.testUrlConstructor
>> > >> ().
>> > >> > > > Though, I have been wanting to do something like in
>> > >> ClassFinder in
>> > >> > > > ResourceFinder, namely being able to say 'search this
>> > >> classloader,
>> > >> > > > but not the parent classloader' or 'search this
>> classloader and
>> > >> > > > parent classloaders up until this particular parent
>> > >> classloader'.
>> > >> > > > But you can essentially get that same result with some
>> work
>> > >> passing
>> > >> > > > in the URLs you want to search.
>> > >> > > >
>> > >> > > > Anyway, if it turns out your more after then classloader
>> > >> "range" type
>> > >> > > > of thing rather than the explicit URL list searching, just
>> > >> let me
>> > >> > > > know cause I've been looking for a reason to plumb that
>> in.
>> > >> > > >
>> > >> > > > -David
>> > >> > > >
>> > >> > > >
>> > >> > >
>> > >> > >
>> > >> > >
>> > >> >
>> > >>
>> > >
>> >
>> >
>>
Re: Container coding tasks
Posted by Manu George <ma...@gmail.com>.
Hi David B,
I have attached a patch patch[2]_r485581_OPENEJB-383.patch
for the change mentioned below. Sorry r485581 in the name should be
actually r486099. copy paste error :)
Regards
Manu
On 12/12/06, Manu George <ma...@gmail.com> wrote:
> Hi David B,
> I will be happy to do it.
>
> Thanks
> Manu
>
> On 12/12/06, David Blevins <da...@visi.com> wrote:
> > On Dec 11, 2006, at 2:39 AM, Manu George wrote:
> >
> > > Hi Dave B,
> > > I have attached a modified patch for your review. The file
> > > is patch[1]_r485581_OPENEJB-383.patch and all the tests pass with this
> > > patch.
> > > Pls let me know if there are any problems with the approach.
> >
> > The patch looks great. It's been committed and is in svn now!
> >
> > I'm going to move the Customer entity into org.apache.test.beans were
> > we put are other 'test-generic' beans. Also going to split that
> > EncStatelessBean.lookupResource into two methods (lookupResource and
> > lookupPersistenceUnit) and add it to all the Enc*Beans and make a new
> > test method in the *JndiEncTests classes. If you'd rather do the
> > work, let me know and I'll save it for you.
> >
> > -David
> >
> > >
> > > Thanks
> > > Manu
> > >
> > > On 12/7/06, Manu George <ma...@gmail.com> wrote:
> > >> Hi Dave B,
> > >> I have attached a patch for JIRA OPENEJB-383. Please review
> > >> when convenient and let me know your comments. There is a test for
> > >> stateless session beans included.
> > >>
> > >> Thanks and Regards
> > >> Manu
> > >>
> > >> On 12/6/06, Manu George <ma...@gmail.com> wrote:
> > >> > Hi Dave B,
> > >> > If you have not spent time reviewing the code pls
> > >> don't.
> > >> > I have made a blunder in it. I will post the final patch
> > >> hopefully by
> > >> > tomorrow.
> > >> >
> > >> > Thanks
> > >> > Manu
> > >> >
> > >> > On 12/6/06, Manu George <ma...@gmail.com> wrote:
> > >> > > Hi Dave B,
> > >> > > It has been a good learning for me working on
> > >> this with
> > >> > > you. I want to thank you for the patience shown and the
> > >> explanations.
> > >> > > Thanks for the advice regarding Resource Finder. I was facing the
> > >> > > exact errors that you mentioned and trying to resolve them
> > >> which was
> > >> > > eating up my time :(. I have not yet implemented this in the
> > >> spring
> > >> > > assembler and so the test i wrote for testing this fail on
> > >> running
> > >> > > using the Spring assembler. Now I am facing some new test
> > >> failures in
> > >> > > Cmp beans after an svn up. I think they are related to some other
> > >> > > check-ins. Anyway I am attaching a patch of whatever is done
> > >> up till
> > >> > > now i.e
> > >> > > PersistenceUnitRef for classic assembler + some modification
> > >> in spring
> > >> > > assembler(DeploymentsFactory).
> > >> > >
> > >> > > Also there is a test which will fail for spring Assembler but
> > >> work for
> > >> > > others. Please have a look and comment. I guess after david
> > >> jencks
> > >> > > post abt this being already implemented in Geronimo, this
> > >> > > implementation may not be required. So shall I stop working on
> > >> it? or
> > >> > > create the final patch (after finding out the cause of the new
> > >> errors,
> > >> > > refactoring and maybe spring assembler integration(a pointer
> > >> from you
> > >> > > on where to look will make things easier).) and post
> > >> > >
> > >> > > P.S. The JndiEncBuilder.findEntityManagerFactory method is not
> > >> yet
> > >> > > fully implemented. I saw the method for ejbLink resolution
> > >> but if I
> > >> > > follow that approach i think it will not work here.
> > >> > >
> > >> > > Thanks
> > >> > > Manu
> > >> > >
> > >> > > On 12/6/06, David Blevins <da...@visi.com> wrote:
> > >> > > >
> > >> > > > On Dec 5, 2006, at 11:49 AM, David Jencks wrote:
> > >> > > >
> > >> > > > >
> > >> > > > > On Dec 5, 2006, at 11:01 AM, David Blevins wrote:
> > >> > > > >
> > >> > > > >>
> > >> > > > >> On Dec 5, 2006, at 10:47 AM, David Jencks wrote:
> > >> > > > >>
> > >> > > > >>>
> > >> > > > >>> On Dec 3, 2006, at 4:11 PM, David Blevins wrote:
> > >> > > > >>>
> > >> > > > >>>>
> > >> > > > >>>> On Dec 3, 2006, at 1:53 PM, Manu George wrote:
> > >> > > > >>>>
> > >> > > > >>>>> Hi David B ,
> > >> > > > >>>>> I got it working i.e am able to get the
> > >> > > > >>>>> EntityManagerFactory
> > >> > > > >>>>> from JNDI. In the persistence.xml I have to give the jta
> > >> > > > >>>>> datasource as
> > >> > > > >>>>> java:openejb/connector/Default JDBC Database for the
> > >> default
> > >> > > > >>>>> datasource
> > >> > > > >>>>> Is this approach acceptable? Or should it be in the
> > >> > > > >>>>> java:comp/env/jdbc/datasource format?
> > >> > > > >>>>
> > >> > > > >>>> Excellent! That's a great first run. It is supposed
> > >> to be of
> > >> > > > >>>> the java:comp/env variety,
> > >> > > > >>>
> > >> > > > >>> I disagree. As I understand it, the jpa EMF is
> > >> something you
> > >> > > > >>> configure in the server, not per ejb. Thus the
> > >> datasource it
> > >> > > > >>> uses should not change depending on which ejb happens to
> > >> be using
> > >> > > > >>> it.
> > >> > > > >>
> > >> > > > >> Took a closer look at the tck and it looks like you're
> > >> right. I
> > >> > > > >> assume then that the way you specify a global data source
> > >> name is
> > >> > > > >> vendor specific and no spec defined?
> > >> > > > >
> > >> > > > > That's right! seems a little odd to me, but it's
> > >> specifically
> > >> > > > > container dependent. In g. I'm using an abstract name
> > >> query, which
> > >> > > > > typically means "name=MyDataSource"
> > >> > > >
> > >> > > > Huh, had I been completely aware of that during the ejb3
> > >> expert group
> > >> > > > I could have used that as an additional argument for my
> > >> proposed app-
> > >> > > > based JNDI ENC (i.e. being able to configure a JNDI tree for
> > >> a whole
> > >> > > > ejb-jar like you can for servlets). Maybe for EJB 3.1.
> > >> > > >
> > >> > > > >> On the same note was the code that creates EMFs in
> > >> openejb3 useful
> > >> > > > >> when you created the one in geronimo/openejb2? Hope
> > >> there was
> > >> > > > >> something in there you could reuse.
> > >> > > > >
> > >> > > > > Yes, it was very helpful. One piece that is still missing
> > >> from the
> > >> > > > > deployer code is the part that looks around for any stray
> > >> > > > > persistence.xml files you might have hidden in your app.
> > >> Do I
> > >> > > > > recall correctly that you have some code that does this?
> > >> You might
> > >> > > > > even have offered to put that code in the g. deployer, but a
> > >> > > > > pointer to it would also be great :-)
> > >> > > >
> > >> > > > No need to offer what's already yours :) You want the
> > >> ResourceFinder:
> > >> > > >
> > >> > > > http://svn.apache.org/repos/asf/geronimo/xbean/trunk/
> > >> xbean-finder/
> > >> > > > src/main/java/org/apache/xbean/finder/ResourceFinder.java
> > >> > > >
> > >> > > > Originally written by me in OpenEJB and moved into XBean around
> > >> > > > JavaOne. Check out the ResourceFinderTest.testUrlConstructor
> > >> ().
> > >> > > > Though, I have been wanting to do something like in
> > >> ClassFinder in
> > >> > > > ResourceFinder, namely being able to say 'search this
> > >> classloader,
> > >> > > > but not the parent classloader' or 'search this classloader and
> > >> > > > parent classloaders up until this particular parent
> > >> classloader'.
> > >> > > > But you can essentially get that same result with some work
> > >> passing
> > >> > > > in the URLs you want to search.
> > >> > > >
> > >> > > > Anyway, if it turns out your more after then classloader
> > >> "range" type
> > >> > > > of thing rather than the explicit URL list searching, just
> > >> let me
> > >> > > > know cause I've been looking for a reason to plumb that in.
> > >> > > >
> > >> > > > -David
> > >> > > >
> > >> > > >
> > >> > >
> > >> > >
> > >> > >
> > >> >
> > >>
> > >
> >
> >
>
Re: Container coding tasks
Posted by Manu George <ma...@gmail.com>.
Hi David B,
I will be happy to do it.
Thanks
Manu
On 12/12/06, David Blevins <da...@visi.com> wrote:
> On Dec 11, 2006, at 2:39 AM, Manu George wrote:
>
> > Hi Dave B,
> > I have attached a modified patch for your review. The file
> > is patch[1]_r485581_OPENEJB-383.patch and all the tests pass with this
> > patch.
> > Pls let me know if there are any problems with the approach.
>
> The patch looks great. It's been committed and is in svn now!
>
> I'm going to move the Customer entity into org.apache.test.beans were
> we put are other 'test-generic' beans. Also going to split that
> EncStatelessBean.lookupResource into two methods (lookupResource and
> lookupPersistenceUnit) and add it to all the Enc*Beans and make a new
> test method in the *JndiEncTests classes. If you'd rather do the
> work, let me know and I'll save it for you.
>
> -David
>
> >
> > Thanks
> > Manu
> >
> > On 12/7/06, Manu George <ma...@gmail.com> wrote:
> >> Hi Dave B,
> >> I have attached a patch for JIRA OPENEJB-383. Please review
> >> when convenient and let me know your comments. There is a test for
> >> stateless session beans included.
> >>
> >> Thanks and Regards
> >> Manu
> >>
> >> On 12/6/06, Manu George <ma...@gmail.com> wrote:
> >> > Hi Dave B,
> >> > If you have not spent time reviewing the code pls
> >> don't.
> >> > I have made a blunder in it. I will post the final patch
> >> hopefully by
> >> > tomorrow.
> >> >
> >> > Thanks
> >> > Manu
> >> >
> >> > On 12/6/06, Manu George <ma...@gmail.com> wrote:
> >> > > Hi Dave B,
> >> > > It has been a good learning for me working on
> >> this with
> >> > > you. I want to thank you for the patience shown and the
> >> explanations.
> >> > > Thanks for the advice regarding Resource Finder. I was facing the
> >> > > exact errors that you mentioned and trying to resolve them
> >> which was
> >> > > eating up my time :(. I have not yet implemented this in the
> >> spring
> >> > > assembler and so the test i wrote for testing this fail on
> >> running
> >> > > using the Spring assembler. Now I am facing some new test
> >> failures in
> >> > > Cmp beans after an svn up. I think they are related to some other
> >> > > check-ins. Anyway I am attaching a patch of whatever is done
> >> up till
> >> > > now i.e
> >> > > PersistenceUnitRef for classic assembler + some modification
> >> in spring
> >> > > assembler(DeploymentsFactory).
> >> > >
> >> > > Also there is a test which will fail for spring Assembler but
> >> work for
> >> > > others. Please have a look and comment. I guess after david
> >> jencks
> >> > > post abt this being already implemented in Geronimo, this
> >> > > implementation may not be required. So shall I stop working on
> >> it? or
> >> > > create the final patch (after finding out the cause of the new
> >> errors,
> >> > > refactoring and maybe spring assembler integration(a pointer
> >> from you
> >> > > on where to look will make things easier).) and post
> >> > >
> >> > > P.S. The JndiEncBuilder.findEntityManagerFactory method is not
> >> yet
> >> > > fully implemented. I saw the method for ejbLink resolution
> >> but if I
> >> > > follow that approach i think it will not work here.
> >> > >
> >> > > Thanks
> >> > > Manu
> >> > >
> >> > > On 12/6/06, David Blevins <da...@visi.com> wrote:
> >> > > >
> >> > > > On Dec 5, 2006, at 11:49 AM, David Jencks wrote:
> >> > > >
> >> > > > >
> >> > > > > On Dec 5, 2006, at 11:01 AM, David Blevins wrote:
> >> > > > >
> >> > > > >>
> >> > > > >> On Dec 5, 2006, at 10:47 AM, David Jencks wrote:
> >> > > > >>
> >> > > > >>>
> >> > > > >>> On Dec 3, 2006, at 4:11 PM, David Blevins wrote:
> >> > > > >>>
> >> > > > >>>>
> >> > > > >>>> On Dec 3, 2006, at 1:53 PM, Manu George wrote:
> >> > > > >>>>
> >> > > > >>>>> Hi David B ,
> >> > > > >>>>> I got it working i.e am able to get the
> >> > > > >>>>> EntityManagerFactory
> >> > > > >>>>> from JNDI. In the persistence.xml I have to give the jta
> >> > > > >>>>> datasource as
> >> > > > >>>>> java:openejb/connector/Default JDBC Database for the
> >> default
> >> > > > >>>>> datasource
> >> > > > >>>>> Is this approach acceptable? Or should it be in the
> >> > > > >>>>> java:comp/env/jdbc/datasource format?
> >> > > > >>>>
> >> > > > >>>> Excellent! That's a great first run. It is supposed
> >> to be of
> >> > > > >>>> the java:comp/env variety,
> >> > > > >>>
> >> > > > >>> I disagree. As I understand it, the jpa EMF is
> >> something you
> >> > > > >>> configure in the server, not per ejb. Thus the
> >> datasource it
> >> > > > >>> uses should not change depending on which ejb happens to
> >> be using
> >> > > > >>> it.
> >> > > > >>
> >> > > > >> Took a closer look at the tck and it looks like you're
> >> right. I
> >> > > > >> assume then that the way you specify a global data source
> >> name is
> >> > > > >> vendor specific and no spec defined?
> >> > > > >
> >> > > > > That's right! seems a little odd to me, but it's
> >> specifically
> >> > > > > container dependent. In g. I'm using an abstract name
> >> query, which
> >> > > > > typically means "name=MyDataSource"
> >> > > >
> >> > > > Huh, had I been completely aware of that during the ejb3
> >> expert group
> >> > > > I could have used that as an additional argument for my
> >> proposed app-
> >> > > > based JNDI ENC (i.e. being able to configure a JNDI tree for
> >> a whole
> >> > > > ejb-jar like you can for servlets). Maybe for EJB 3.1.
> >> > > >
> >> > > > >> On the same note was the code that creates EMFs in
> >> openejb3 useful
> >> > > > >> when you created the one in geronimo/openejb2? Hope
> >> there was
> >> > > > >> something in there you could reuse.
> >> > > > >
> >> > > > > Yes, it was very helpful. One piece that is still missing
> >> from the
> >> > > > > deployer code is the part that looks around for any stray
> >> > > > > persistence.xml files you might have hidden in your app.
> >> Do I
> >> > > > > recall correctly that you have some code that does this?
> >> You might
> >> > > > > even have offered to put that code in the g. deployer, but a
> >> > > > > pointer to it would also be great :-)
> >> > > >
> >> > > > No need to offer what's already yours :) You want the
> >> ResourceFinder:
> >> > > >
> >> > > > http://svn.apache.org/repos/asf/geronimo/xbean/trunk/
> >> xbean-finder/
> >> > > > src/main/java/org/apache/xbean/finder/ResourceFinder.java
> >> > > >
> >> > > > Originally written by me in OpenEJB and moved into XBean around
> >> > > > JavaOne. Check out the ResourceFinderTest.testUrlConstructor
> >> ().
> >> > > > Though, I have been wanting to do something like in
> >> ClassFinder in
> >> > > > ResourceFinder, namely being able to say 'search this
> >> classloader,
> >> > > > but not the parent classloader' or 'search this classloader and
> >> > > > parent classloaders up until this particular parent
> >> classloader'.
> >> > > > But you can essentially get that same result with some work
> >> passing
> >> > > > in the URLs you want to search.
> >> > > >
> >> > > > Anyway, if it turns out your more after then classloader
> >> "range" type
> >> > > > of thing rather than the explicit URL list searching, just
> >> let me
> >> > > > know cause I've been looking for a reason to plumb that in.
> >> > > >
> >> > > > -David
> >> > > >
> >> > > >
> >> > >
> >> > >
> >> > >
> >> >
> >>
> >
>
>
Re: Container coding tasks
Posted by David Blevins <da...@visi.com>.
On Dec 11, 2006, at 2:39 AM, Manu George wrote:
> Hi Dave B,
> I have attached a modified patch for your review. The file
> is patch[1]_r485581_OPENEJB-383.patch and all the tests pass with this
> patch.
> Pls let me know if there are any problems with the approach.
The patch looks great. It's been committed and is in svn now!
I'm going to move the Customer entity into org.apache.test.beans were
we put are other 'test-generic' beans. Also going to split that
EncStatelessBean.lookupResource into two methods (lookupResource and
lookupPersistenceUnit) and add it to all the Enc*Beans and make a new
test method in the *JndiEncTests classes. If you'd rather do the
work, let me know and I'll save it for you.
-David
>
> Thanks
> Manu
>
> On 12/7/06, Manu George <ma...@gmail.com> wrote:
>> Hi Dave B,
>> I have attached a patch for JIRA OPENEJB-383. Please review
>> when convenient and let me know your comments. There is a test for
>> stateless session beans included.
>>
>> Thanks and Regards
>> Manu
>>
>> On 12/6/06, Manu George <ma...@gmail.com> wrote:
>> > Hi Dave B,
>> > If you have not spent time reviewing the code pls
>> don't.
>> > I have made a blunder in it. I will post the final patch
>> hopefully by
>> > tomorrow.
>> >
>> > Thanks
>> > Manu
>> >
>> > On 12/6/06, Manu George <ma...@gmail.com> wrote:
>> > > Hi Dave B,
>> > > It has been a good learning for me working on
>> this with
>> > > you. I want to thank you for the patience shown and the
>> explanations.
>> > > Thanks for the advice regarding Resource Finder. I was facing the
>> > > exact errors that you mentioned and trying to resolve them
>> which was
>> > > eating up my time :(. I have not yet implemented this in the
>> spring
>> > > assembler and so the test i wrote for testing this fail on
>> running
>> > > using the Spring assembler. Now I am facing some new test
>> failures in
>> > > Cmp beans after an svn up. I think they are related to some other
>> > > check-ins. Anyway I am attaching a patch of whatever is done
>> up till
>> > > now i.e
>> > > PersistenceUnitRef for classic assembler + some modification
>> in spring
>> > > assembler(DeploymentsFactory).
>> > >
>> > > Also there is a test which will fail for spring Assembler but
>> work for
>> > > others. Please have a look and comment. I guess after david
>> jencks
>> > > post abt this being already implemented in Geronimo, this
>> > > implementation may not be required. So shall I stop working on
>> it? or
>> > > create the final patch (after finding out the cause of the new
>> errors,
>> > > refactoring and maybe spring assembler integration(a pointer
>> from you
>> > > on where to look will make things easier).) and post
>> > >
>> > > P.S. The JndiEncBuilder.findEntityManagerFactory method is not
>> yet
>> > > fully implemented. I saw the method for ejbLink resolution
>> but if I
>> > > follow that approach i think it will not work here.
>> > >
>> > > Thanks
>> > > Manu
>> > >
>> > > On 12/6/06, David Blevins <da...@visi.com> wrote:
>> > > >
>> > > > On Dec 5, 2006, at 11:49 AM, David Jencks wrote:
>> > > >
>> > > > >
>> > > > > On Dec 5, 2006, at 11:01 AM, David Blevins wrote:
>> > > > >
>> > > > >>
>> > > > >> On Dec 5, 2006, at 10:47 AM, David Jencks wrote:
>> > > > >>
>> > > > >>>
>> > > > >>> On Dec 3, 2006, at 4:11 PM, David Blevins wrote:
>> > > > >>>
>> > > > >>>>
>> > > > >>>> On Dec 3, 2006, at 1:53 PM, Manu George wrote:
>> > > > >>>>
>> > > > >>>>> Hi David B ,
>> > > > >>>>> I got it working i.e am able to get the
>> > > > >>>>> EntityManagerFactory
>> > > > >>>>> from JNDI. In the persistence.xml I have to give the jta
>> > > > >>>>> datasource as
>> > > > >>>>> java:openejb/connector/Default JDBC Database for the
>> default
>> > > > >>>>> datasource
>> > > > >>>>> Is this approach acceptable? Or should it be in the
>> > > > >>>>> java:comp/env/jdbc/datasource format?
>> > > > >>>>
>> > > > >>>> Excellent! That's a great first run. It is supposed
>> to be of
>> > > > >>>> the java:comp/env variety,
>> > > > >>>
>> > > > >>> I disagree. As I understand it, the jpa EMF is
>> something you
>> > > > >>> configure in the server, not per ejb. Thus the
>> datasource it
>> > > > >>> uses should not change depending on which ejb happens to
>> be using
>> > > > >>> it.
>> > > > >>
>> > > > >> Took a closer look at the tck and it looks like you're
>> right. I
>> > > > >> assume then that the way you specify a global data source
>> name is
>> > > > >> vendor specific and no spec defined?
>> > > > >
>> > > > > That's right! seems a little odd to me, but it's
>> specifically
>> > > > > container dependent. In g. I'm using an abstract name
>> query, which
>> > > > > typically means "name=MyDataSource"
>> > > >
>> > > > Huh, had I been completely aware of that during the ejb3
>> expert group
>> > > > I could have used that as an additional argument for my
>> proposed app-
>> > > > based JNDI ENC (i.e. being able to configure a JNDI tree for
>> a whole
>> > > > ejb-jar like you can for servlets). Maybe for EJB 3.1.
>> > > >
>> > > > >> On the same note was the code that creates EMFs in
>> openejb3 useful
>> > > > >> when you created the one in geronimo/openejb2? Hope
>> there was
>> > > > >> something in there you could reuse.
>> > > > >
>> > > > > Yes, it was very helpful. One piece that is still missing
>> from the
>> > > > > deployer code is the part that looks around for any stray
>> > > > > persistence.xml files you might have hidden in your app.
>> Do I
>> > > > > recall correctly that you have some code that does this?
>> You might
>> > > > > even have offered to put that code in the g. deployer, but a
>> > > > > pointer to it would also be great :-)
>> > > >
>> > > > No need to offer what's already yours :) You want the
>> ResourceFinder:
>> > > >
>> > > > http://svn.apache.org/repos/asf/geronimo/xbean/trunk/
>> xbean-finder/
>> > > > src/main/java/org/apache/xbean/finder/ResourceFinder.java
>> > > >
>> > > > Originally written by me in OpenEJB and moved into XBean around
>> > > > JavaOne. Check out the ResourceFinderTest.testUrlConstructor
>> ().
>> > > > Though, I have been wanting to do something like in
>> ClassFinder in
>> > > > ResourceFinder, namely being able to say 'search this
>> classloader,
>> > > > but not the parent classloader' or 'search this classloader and
>> > > > parent classloaders up until this particular parent
>> classloader'.
>> > > > But you can essentially get that same result with some work
>> passing
>> > > > in the URLs you want to search.
>> > > >
>> > > > Anyway, if it turns out your more after then classloader
>> "range" type
>> > > > of thing rather than the explicit URL list searching, just
>> let me
>> > > > know cause I've been looking for a reason to plumb that in.
>> > > >
>> > > > -David
>> > > >
>> > > >
>> > >
>> > >
>> > >
>> >
>>
>
Re: Container coding tasks
Posted by Manu George <ma...@gmail.com>.
Hi Dave B,
I have attached a modified patch for your review. The file
is patch[1]_r485581_OPENEJB-383.patch and all the tests pass with this
patch.
Pls let me know if there are any problems with the approach.
Thanks
Manu
On 12/7/06, Manu George <ma...@gmail.com> wrote:
> Hi Dave B,
> I have attached a patch for JIRA OPENEJB-383. Please review
> when convenient and let me know your comments. There is a test for
> stateless session beans included.
>
> Thanks and Regards
> Manu
>
> On 12/6/06, Manu George <ma...@gmail.com> wrote:
> > Hi Dave B,
> > If you have not spent time reviewing the code pls don't.
> > I have made a blunder in it. I will post the final patch hopefully by
> > tomorrow.
> >
> > Thanks
> > Manu
> >
> > On 12/6/06, Manu George <ma...@gmail.com> wrote:
> > > Hi Dave B,
> > > It has been a good learning for me working on this with
> > > you. I want to thank you for the patience shown and the explanations.
> > > Thanks for the advice regarding Resource Finder. I was facing the
> > > exact errors that you mentioned and trying to resolve them which was
> > > eating up my time :(. I have not yet implemented this in the spring
> > > assembler and so the test i wrote for testing this fail on running
> > > using the Spring assembler. Now I am facing some new test failures in
> > > Cmp beans after an svn up. I think they are related to some other
> > > check-ins. Anyway I am attaching a patch of whatever is done up till
> > > now i.e
> > > PersistenceUnitRef for classic assembler + some modification in spring
> > > assembler(DeploymentsFactory).
> > >
> > > Also there is a test which will fail for spring Assembler but work for
> > > others. Please have a look and comment. I guess after david jencks
> > > post abt this being already implemented in Geronimo, this
> > > implementation may not be required. So shall I stop working on it? or
> > > create the final patch (after finding out the cause of the new errors,
> > > refactoring and maybe spring assembler integration(a pointer from you
> > > on where to look will make things easier).) and post
> > >
> > > P.S. The JndiEncBuilder.findEntityManagerFactory method is not yet
> > > fully implemented. I saw the method for ejbLink resolution but if I
> > > follow that approach i think it will not work here.
> > >
> > > Thanks
> > > Manu
> > >
> > > On 12/6/06, David Blevins <da...@visi.com> wrote:
> > > >
> > > > On Dec 5, 2006, at 11:49 AM, David Jencks wrote:
> > > >
> > > > >
> > > > > On Dec 5, 2006, at 11:01 AM, David Blevins wrote:
> > > > >
> > > > >>
> > > > >> On Dec 5, 2006, at 10:47 AM, David Jencks wrote:
> > > > >>
> > > > >>>
> > > > >>> On Dec 3, 2006, at 4:11 PM, David Blevins wrote:
> > > > >>>
> > > > >>>>
> > > > >>>> On Dec 3, 2006, at 1:53 PM, Manu George wrote:
> > > > >>>>
> > > > >>>>> Hi David B ,
> > > > >>>>> I got it working i.e am able to get the
> > > > >>>>> EntityManagerFactory
> > > > >>>>> from JNDI. In the persistence.xml I have to give the jta
> > > > >>>>> datasource as
> > > > >>>>> java:openejb/connector/Default JDBC Database for the default
> > > > >>>>> datasource
> > > > >>>>> Is this approach acceptable? Or should it be in the
> > > > >>>>> java:comp/env/jdbc/datasource format?
> > > > >>>>
> > > > >>>> Excellent! That's a great first run. It is supposed to be of
> > > > >>>> the java:comp/env variety,
> > > > >>>
> > > > >>> I disagree. As I understand it, the jpa EMF is something you
> > > > >>> configure in the server, not per ejb. Thus the datasource it
> > > > >>> uses should not change depending on which ejb happens to be using
> > > > >>> it.
> > > > >>
> > > > >> Took a closer look at the tck and it looks like you're right. I
> > > > >> assume then that the way you specify a global data source name is
> > > > >> vendor specific and no spec defined?
> > > > >
> > > > > That's right! seems a little odd to me, but it's specifically
> > > > > container dependent. In g. I'm using an abstract name query, which
> > > > > typically means "name=MyDataSource"
> > > >
> > > > Huh, had I been completely aware of that during the ejb3 expert group
> > > > I could have used that as an additional argument for my proposed app-
> > > > based JNDI ENC (i.e. being able to configure a JNDI tree for a whole
> > > > ejb-jar like you can for servlets). Maybe for EJB 3.1.
> > > >
> > > > >> On the same note was the code that creates EMFs in openejb3 useful
> > > > >> when you created the one in geronimo/openejb2? Hope there was
> > > > >> something in there you could reuse.
> > > > >
> > > > > Yes, it was very helpful. One piece that is still missing from the
> > > > > deployer code is the part that looks around for any stray
> > > > > persistence.xml files you might have hidden in your app. Do I
> > > > > recall correctly that you have some code that does this? You might
> > > > > even have offered to put that code in the g. deployer, but a
> > > > > pointer to it would also be great :-)
> > > >
> > > > No need to offer what's already yours :) You want the ResourceFinder:
> > > >
> > > > http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-finder/
> > > > src/main/java/org/apache/xbean/finder/ResourceFinder.java
> > > >
> > > > Originally written by me in OpenEJB and moved into XBean around
> > > > JavaOne. Check out the ResourceFinderTest.testUrlConstructor().
> > > > Though, I have been wanting to do something like in ClassFinder in
> > > > ResourceFinder, namely being able to say 'search this classloader,
> > > > but not the parent classloader' or 'search this classloader and
> > > > parent classloaders up until this particular parent classloader'.
> > > > But you can essentially get that same result with some work passing
> > > > in the URLs you want to search.
> > > >
> > > > Anyway, if it turns out your more after then classloader "range" type
> > > > of thing rather than the explicit URL list searching, just let me
> > > > know cause I've been looking for a reason to plumb that in.
> > > >
> > > > -David
> > > >
> > > >
> > >
> > >
> > >
> >
>
Re: Container coding tasks
Posted by Manu George <ma...@gmail.com>.
Hi Dave B,
I have attached a patch for JIRA OPENEJB-383. Please review
when convenient and let me know your comments. There is a test for
stateless session beans included.
Thanks and Regards
Manu
On 12/6/06, Manu George <ma...@gmail.com> wrote:
> Hi Dave B,
> If you have not spent time reviewing the code pls don't.
> I have made a blunder in it. I will post the final patch hopefully by
> tomorrow.
>
> Thanks
> Manu
>
> On 12/6/06, Manu George <ma...@gmail.com> wrote:
> > Hi Dave B,
> > It has been a good learning for me working on this with
> > you. I want to thank you for the patience shown and the explanations.
> > Thanks for the advice regarding Resource Finder. I was facing the
> > exact errors that you mentioned and trying to resolve them which was
> > eating up my time :(. I have not yet implemented this in the spring
> > assembler and so the test i wrote for testing this fail on running
> > using the Spring assembler. Now I am facing some new test failures in
> > Cmp beans after an svn up. I think they are related to some other
> > check-ins. Anyway I am attaching a patch of whatever is done up till
> > now i.e
> > PersistenceUnitRef for classic assembler + some modification in spring
> > assembler(DeploymentsFactory).
> >
> > Also there is a test which will fail for spring Assembler but work for
> > others. Please have a look and comment. I guess after david jencks
> > post abt this being already implemented in Geronimo, this
> > implementation may not be required. So shall I stop working on it? or
> > create the final patch (after finding out the cause of the new errors,
> > refactoring and maybe spring assembler integration(a pointer from you
> > on where to look will make things easier).) and post
> >
> > P.S. The JndiEncBuilder.findEntityManagerFactory method is not yet
> > fully implemented. I saw the method for ejbLink resolution but if I
> > follow that approach i think it will not work here.
> >
> > Thanks
> > Manu
> >
> > On 12/6/06, David Blevins <da...@visi.com> wrote:
> > >
> > > On Dec 5, 2006, at 11:49 AM, David Jencks wrote:
> > >
> > > >
> > > > On Dec 5, 2006, at 11:01 AM, David Blevins wrote:
> > > >
> > > >>
> > > >> On Dec 5, 2006, at 10:47 AM, David Jencks wrote:
> > > >>
> > > >>>
> > > >>> On Dec 3, 2006, at 4:11 PM, David Blevins wrote:
> > > >>>
> > > >>>>
> > > >>>> On Dec 3, 2006, at 1:53 PM, Manu George wrote:
> > > >>>>
> > > >>>>> Hi David B ,
> > > >>>>> I got it working i.e am able to get the
> > > >>>>> EntityManagerFactory
> > > >>>>> from JNDI. In the persistence.xml I have to give the jta
> > > >>>>> datasource as
> > > >>>>> java:openejb/connector/Default JDBC Database for the default
> > > >>>>> datasource
> > > >>>>> Is this approach acceptable? Or should it be in the
> > > >>>>> java:comp/env/jdbc/datasource format?
> > > >>>>
> > > >>>> Excellent! That's a great first run. It is supposed to be of
> > > >>>> the java:comp/env variety,
> > > >>>
> > > >>> I disagree. As I understand it, the jpa EMF is something you
> > > >>> configure in the server, not per ejb. Thus the datasource it
> > > >>> uses should not change depending on which ejb happens to be using
> > > >>> it.
> > > >>
> > > >> Took a closer look at the tck and it looks like you're right. I
> > > >> assume then that the way you specify a global data source name is
> > > >> vendor specific and no spec defined?
> > > >
> > > > That's right! seems a little odd to me, but it's specifically
> > > > container dependent. In g. I'm using an abstract name query, which
> > > > typically means "name=MyDataSource"
> > >
> > > Huh, had I been completely aware of that during the ejb3 expert group
> > > I could have used that as an additional argument for my proposed app-
> > > based JNDI ENC (i.e. being able to configure a JNDI tree for a whole
> > > ejb-jar like you can for servlets). Maybe for EJB 3.1.
> > >
> > > >> On the same note was the code that creates EMFs in openejb3 useful
> > > >> when you created the one in geronimo/openejb2? Hope there was
> > > >> something in there you could reuse.
> > > >
> > > > Yes, it was very helpful. One piece that is still missing from the
> > > > deployer code is the part that looks around for any stray
> > > > persistence.xml files you might have hidden in your app. Do I
> > > > recall correctly that you have some code that does this? You might
> > > > even have offered to put that code in the g. deployer, but a
> > > > pointer to it would also be great :-)
> > >
> > > No need to offer what's already yours :) You want the ResourceFinder:
> > >
> > > http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-finder/
> > > src/main/java/org/apache/xbean/finder/ResourceFinder.java
> > >
> > > Originally written by me in OpenEJB and moved into XBean around
> > > JavaOne. Check out the ResourceFinderTest.testUrlConstructor().
> > > Though, I have been wanting to do something like in ClassFinder in
> > > ResourceFinder, namely being able to say 'search this classloader,
> > > but not the parent classloader' or 'search this classloader and
> > > parent classloaders up until this particular parent classloader'.
> > > But you can essentially get that same result with some work passing
> > > in the URLs you want to search.
> > >
> > > Anyway, if it turns out your more after then classloader "range" type
> > > of thing rather than the explicit URL list searching, just let me
> > > know cause I've been looking for a reason to plumb that in.
> > >
> > > -David
> > >
> > >
> >
> >
> >
>
Re: Container coding tasks
Posted by Manu George <ma...@gmail.com>.
Hi Dave B,
If you have not spent time reviewing the code pls don't.
I have made a blunder in it. I will post the final patch hopefully by
tomorrow.
Thanks
Manu
On 12/6/06, Manu George <ma...@gmail.com> wrote:
> Hi Dave B,
> It has been a good learning for me working on this with
> you. I want to thank you for the patience shown and the explanations.
> Thanks for the advice regarding Resource Finder. I was facing the
> exact errors that you mentioned and trying to resolve them which was
> eating up my time :(. I have not yet implemented this in the spring
> assembler and so the test i wrote for testing this fail on running
> using the Spring assembler. Now I am facing some new test failures in
> Cmp beans after an svn up. I think they are related to some other
> check-ins. Anyway I am attaching a patch of whatever is done up till
> now i.e
> PersistenceUnitRef for classic assembler + some modification in spring
> assembler(DeploymentsFactory).
>
> Also there is a test which will fail for spring Assembler but work for
> others. Please have a look and comment. I guess after david jencks
> post abt this being already implemented in Geronimo, this
> implementation may not be required. So shall I stop working on it? or
> create the final patch (after finding out the cause of the new errors,
> refactoring and maybe spring assembler integration(a pointer from you
> on where to look will make things easier).) and post
>
> P.S. The JndiEncBuilder.findEntityManagerFactory method is not yet
> fully implemented. I saw the method for ejbLink resolution but if I
> follow that approach i think it will not work here.
>
> Thanks
> Manu
>
> On 12/6/06, David Blevins <da...@visi.com> wrote:
> >
> > On Dec 5, 2006, at 11:49 AM, David Jencks wrote:
> >
> > >
> > > On Dec 5, 2006, at 11:01 AM, David Blevins wrote:
> > >
> > >>
> > >> On Dec 5, 2006, at 10:47 AM, David Jencks wrote:
> > >>
> > >>>
> > >>> On Dec 3, 2006, at 4:11 PM, David Blevins wrote:
> > >>>
> > >>>>
> > >>>> On Dec 3, 2006, at 1:53 PM, Manu George wrote:
> > >>>>
> > >>>>> Hi David B ,
> > >>>>> I got it working i.e am able to get the
> > >>>>> EntityManagerFactory
> > >>>>> from JNDI. In the persistence.xml I have to give the jta
> > >>>>> datasource as
> > >>>>> java:openejb/connector/Default JDBC Database for the default
> > >>>>> datasource
> > >>>>> Is this approach acceptable? Or should it be in the
> > >>>>> java:comp/env/jdbc/datasource format?
> > >>>>
> > >>>> Excellent! That's a great first run. It is supposed to be of
> > >>>> the java:comp/env variety,
> > >>>
> > >>> I disagree. As I understand it, the jpa EMF is something you
> > >>> configure in the server, not per ejb. Thus the datasource it
> > >>> uses should not change depending on which ejb happens to be using
> > >>> it.
> > >>
> > >> Took a closer look at the tck and it looks like you're right. I
> > >> assume then that the way you specify a global data source name is
> > >> vendor specific and no spec defined?
> > >
> > > That's right! seems a little odd to me, but it's specifically
> > > container dependent. In g. I'm using an abstract name query, which
> > > typically means "name=MyDataSource"
> >
> > Huh, had I been completely aware of that during the ejb3 expert group
> > I could have used that as an additional argument for my proposed app-
> > based JNDI ENC (i.e. being able to configure a JNDI tree for a whole
> > ejb-jar like you can for servlets). Maybe for EJB 3.1.
> >
> > >> On the same note was the code that creates EMFs in openejb3 useful
> > >> when you created the one in geronimo/openejb2? Hope there was
> > >> something in there you could reuse.
> > >
> > > Yes, it was very helpful. One piece that is still missing from the
> > > deployer code is the part that looks around for any stray
> > > persistence.xml files you might have hidden in your app. Do I
> > > recall correctly that you have some code that does this? You might
> > > even have offered to put that code in the g. deployer, but a
> > > pointer to it would also be great :-)
> >
> > No need to offer what's already yours :) You want the ResourceFinder:
> >
> > http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-finder/
> > src/main/java/org/apache/xbean/finder/ResourceFinder.java
> >
> > Originally written by me in OpenEJB and moved into XBean around
> > JavaOne. Check out the ResourceFinderTest.testUrlConstructor().
> > Though, I have been wanting to do something like in ClassFinder in
> > ResourceFinder, namely being able to say 'search this classloader,
> > but not the parent classloader' or 'search this classloader and
> > parent classloaders up until this particular parent classloader'.
> > But you can essentially get that same result with some work passing
> > in the URLs you want to search.
> >
> > Anyway, if it turns out your more after then classloader "range" type
> > of thing rather than the explicit URL list searching, just let me
> > know cause I've been looking for a reason to plumb that in.
> >
> > -David
> >
> >
>
>
>
Re: Container coding tasks
Posted by Manu George <ma...@gmail.com>.
Hi Dave B,
It has been a good learning for me working on this with
you. I want to thank you for the patience shown and the explanations.
Thanks for the advice regarding Resource Finder. I was facing the
exact errors that you mentioned and trying to resolve them which was
eating up my time :(. I have not yet implemented this in the spring
assembler and so the test i wrote for testing this fail on running
using the Spring assembler. Now I am facing some new test failures in
Cmp beans after an svn up. I think they are related to some other
check-ins. Anyway I am attaching a patch of whatever is done up till
now i.e
PersistenceUnitRef for classic assembler + some modification in spring
assembler(DeploymentsFactory).
Also there is a test which will fail for spring Assembler but work for
others. Please have a look and comment. I guess after david jencks
post abt this being already implemented in Geronimo, this
implementation may not be required. So shall I stop working on it? or
create the final patch (after finding out the cause of the new errors,
refactoring and maybe spring assembler integration(a pointer from you
on where to look will make things easier).) and post
P.S. The JndiEncBuilder.findEntityManagerFactory method is not yet
fully implemented. I saw the method for ejbLink resolution but if I
follow that approach i think it will not work here.
Thanks
Manu
On 12/6/06, David Blevins <da...@visi.com> wrote:
>
> On Dec 5, 2006, at 11:49 AM, David Jencks wrote:
>
> >
> > On Dec 5, 2006, at 11:01 AM, David Blevins wrote:
> >
> >>
> >> On Dec 5, 2006, at 10:47 AM, David Jencks wrote:
> >>
> >>>
> >>> On Dec 3, 2006, at 4:11 PM, David Blevins wrote:
> >>>
> >>>>
> >>>> On Dec 3, 2006, at 1:53 PM, Manu George wrote:
> >>>>
> >>>>> Hi David B ,
> >>>>> I got it working i.e am able to get the
> >>>>> EntityManagerFactory
> >>>>> from JNDI. In the persistence.xml I have to give the jta
> >>>>> datasource as
> >>>>> java:openejb/connector/Default JDBC Database for the default
> >>>>> datasource
> >>>>> Is this approach acceptable? Or should it be in the
> >>>>> java:comp/env/jdbc/datasource format?
> >>>>
> >>>> Excellent! That's a great first run. It is supposed to be of
> >>>> the java:comp/env variety,
> >>>
> >>> I disagree. As I understand it, the jpa EMF is something you
> >>> configure in the server, not per ejb. Thus the datasource it
> >>> uses should not change depending on which ejb happens to be using
> >>> it.
> >>
> >> Took a closer look at the tck and it looks like you're right. I
> >> assume then that the way you specify a global data source name is
> >> vendor specific and no spec defined?
> >
> > That's right! seems a little odd to me, but it's specifically
> > container dependent. In g. I'm using an abstract name query, which
> > typically means "name=MyDataSource"
>
> Huh, had I been completely aware of that during the ejb3 expert group
> I could have used that as an additional argument for my proposed app-
> based JNDI ENC (i.e. being able to configure a JNDI tree for a whole
> ejb-jar like you can for servlets). Maybe for EJB 3.1.
>
> >> On the same note was the code that creates EMFs in openejb3 useful
> >> when you created the one in geronimo/openejb2? Hope there was
> >> something in there you could reuse.
> >
> > Yes, it was very helpful. One piece that is still missing from the
> > deployer code is the part that looks around for any stray
> > persistence.xml files you might have hidden in your app. Do I
> > recall correctly that you have some code that does this? You might
> > even have offered to put that code in the g. deployer, but a
> > pointer to it would also be great :-)
>
> No need to offer what's already yours :) You want the ResourceFinder:
>
> http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-finder/
> src/main/java/org/apache/xbean/finder/ResourceFinder.java
>
> Originally written by me in OpenEJB and moved into XBean around
> JavaOne. Check out the ResourceFinderTest.testUrlConstructor().
> Though, I have been wanting to do something like in ClassFinder in
> ResourceFinder, namely being able to say 'search this classloader,
> but not the parent classloader' or 'search this classloader and
> parent classloaders up until this particular parent classloader'.
> But you can essentially get that same result with some work passing
> in the URLs you want to search.
>
> Anyway, if it turns out your more after then classloader "range" type
> of thing rather than the explicit URL list searching, just let me
> know cause I've been looking for a reason to plumb that in.
>
> -David
>
>
Re: Container coding tasks
Posted by David Blevins <da...@visi.com>.
On Dec 5, 2006, at 11:49 AM, David Jencks wrote:
>
> On Dec 5, 2006, at 11:01 AM, David Blevins wrote:
>
>>
>> On Dec 5, 2006, at 10:47 AM, David Jencks wrote:
>>
>>>
>>> On Dec 3, 2006, at 4:11 PM, David Blevins wrote:
>>>
>>>>
>>>> On Dec 3, 2006, at 1:53 PM, Manu George wrote:
>>>>
>>>>> Hi David B ,
>>>>> I got it working i.e am able to get the
>>>>> EntityManagerFactory
>>>>> from JNDI. In the persistence.xml I have to give the jta
>>>>> datasource as
>>>>> java:openejb/connector/Default JDBC Database for the default
>>>>> datasource
>>>>> Is this approach acceptable? Or should it be in the
>>>>> java:comp/env/jdbc/datasource format?
>>>>
>>>> Excellent! That's a great first run. It is supposed to be of
>>>> the java:comp/env variety,
>>>
>>> I disagree. As I understand it, the jpa EMF is something you
>>> configure in the server, not per ejb. Thus the datasource it
>>> uses should not change depending on which ejb happens to be using
>>> it.
>>
>> Took a closer look at the tck and it looks like you're right. I
>> assume then that the way you specify a global data source name is
>> vendor specific and no spec defined?
>
> That's right! seems a little odd to me, but it's specifically
> container dependent. In g. I'm using an abstract name query, which
> typically means "name=MyDataSource"
Huh, had I been completely aware of that during the ejb3 expert group
I could have used that as an additional argument for my proposed app-
based JNDI ENC (i.e. being able to configure a JNDI tree for a whole
ejb-jar like you can for servlets). Maybe for EJB 3.1.
>> On the same note was the code that creates EMFs in openejb3 useful
>> when you created the one in geronimo/openejb2? Hope there was
>> something in there you could reuse.
>
> Yes, it was very helpful. One piece that is still missing from the
> deployer code is the part that looks around for any stray
> persistence.xml files you might have hidden in your app. Do I
> recall correctly that you have some code that does this? You might
> even have offered to put that code in the g. deployer, but a
> pointer to it would also be great :-)
No need to offer what's already yours :) You want the ResourceFinder:
http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-finder/
src/main/java/org/apache/xbean/finder/ResourceFinder.java
Originally written by me in OpenEJB and moved into XBean around
JavaOne. Check out the ResourceFinderTest.testUrlConstructor().
Though, I have been wanting to do something like in ClassFinder in
ResourceFinder, namely being able to say 'search this classloader,
but not the parent classloader' or 'search this classloader and
parent classloaders up until this particular parent classloader'.
But you can essentially get that same result with some work passing
in the URLs you want to search.
Anyway, if it turns out your more after then classloader "range" type
of thing rather than the explicit URL list searching, just let me
know cause I've been looking for a reason to plumb that in.
-David
Re: Container coding tasks
Posted by David Jencks <da...@yahoo.com>.
On Dec 5, 2006, at 11:01 AM, David Blevins wrote:
>
> On Dec 5, 2006, at 10:47 AM, David Jencks wrote:
>
>>
>> On Dec 3, 2006, at 4:11 PM, David Blevins wrote:
>>
>>>
>>> On Dec 3, 2006, at 1:53 PM, Manu George wrote:
>>>
>>>> Hi David B ,
>>>> I got it working i.e am able to get the
>>>> EntityManagerFactory
>>>> from JNDI. In the persistence.xml I have to give the jta
>>>> datasource as
>>>> java:openejb/connector/Default JDBC Database for the default
>>>> datasource
>>>> Is this approach acceptable? Or should it be in the
>>>> java:comp/env/jdbc/datasource format?
>>>
>>> Excellent! That's a great first run. It is supposed to be of
>>> the java:comp/env variety,
>>
>> I disagree. As I understand it, the jpa EMF is something you
>> configure in the server, not per ejb. Thus the datasource it uses
>> should not change depending on which ejb happens to be using it.
>
> Took a closer look at the tck and it looks like you're right. I
> assume then that the way you specify a global data source name is
> vendor specific and no spec defined?
That's right! seems a little odd to me, but it's specifically
container dependent. In g. I'm using an abstract name query, which
typically means "name=MyDataSource"
>
>> Same for EM.
>>
>> All or most of this stuff is all working in geronimo/openejb2. It
>> might be useful to look at as a reference or even consider sharing
>> code.
>
> I will. On the same note was the code that creates EMFs in
> openejb3 useful when you created the one in geronimo/openejb2?
> Hope there was something in there you could reuse.
Yes, it was very helpful. One piece that is still missing from the
deployer code is the part that looks around for any stray
persistence.xml files you might have hidden in your app. Do I recall
correctly that you have some code that does this? You might even
have offered to put that code in the g. deployer, but a pointer to it
would also be great :-)
thanks
david jencks
>
>
> -David
>
>
>>
>> thanks
>> david jencks
>>
>>> but using "java:openejb/connector/Default JDBC Database" will
>>> work just fine to start with. We'll likely have to rework the
>>> code a bit to support the java:comp/env thing.
>>>
>>> Anyone want to update the Enc*Bean tests to test lookup of
>>> PersistenceUnits?
>>>
>>> -David
>>>
>>>> Thanks
>>>> Manu
>>>>
>>>> On 12/2/06, David Blevins <da...@visi.com> wrote:
>>>>>
>>>>> On Dec 1, 2006, at 12:02 PM, Manu George wrote:
>>>>>
>>>>> > I have a doubt in this JIRA. There is a class
>>>>> called
>>>>> > EntityManagerFactoryCache which is an object factory already
>>>>> present
>>>>> > in OEJB. It also has variables to store all the
>>>>> > EntityManagerFactories.
>>>>>
>>>>> You probably don't want to use that object. Likely somewhere
>>>>> in the
>>>>> EjbJarBuilder you'll use the PersistenceDeployer.loadPersistence
>>>>> method directly to get all the EntityManagerFactories. Then
>>>>> you'll
>>>>> probably want to pass that map into the constructor of the
>>>>> EnterpriseBeanBuilder and then into the constructor of the
>>>>> JndiEncBuilder.
>>>>>
>>>>> In the JndiEncBuilder you'll add a new method to process all the
>>>>> PersistenceUnitInfo objects in JndiEncInfo. Of course the
>>>>> PersistenceUnitInfo class doesn't exist yet, let me just create
>>>>> that
>>>>> to make this first one easy. Ok, see this commit:
>>>>>
>>>>> http://svn.apache.org/viewvc?view=rev&revision=481478
>>>>>
>>>>> (ignore that change to JndiEncBuilder, that was unrelated)
>>>>>
>>>>> You'll need to implement the method
>>>>> JndiEncInfoBuilder.buildPersistenceUnitRefInfos() created with
>>>>> that
>>>>> commit.
>>>>>
>>>>> > I also noticed that there are two Reference interfaces in OEJB
>>>>> > in org.apache.openejb.core.ivm.naming and
>>>>> org.apache.openejb.naming
>>>>> > packages. What is the significance of having two? Why don't
>>>>> any of the
>>>>> > references extend from the javax.naming package?
>>>>>
>>>>> Our current JNDI implementation is just a bit obtuse. I
>>>>> predict at
>>>>> some point in the future we may ditch it for the xbean-naming
>>>>> implementation which is a bit nicer. Till then just create an
>>>>> implementation of org.apache.openejb.core.ivm.naming.Reference and
>>>>> pass the EntityManagerFactory right in the constructor.
>>>>>
>>>>> We may want to switch it to create the EntityManagerFactory inside
>>>>> the getObject method of the Reference class, but this is good
>>>>> enough
>>>>> for now. We'll see what the TCK has to say about it when the time
>>>>> comes.
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Container coding tasks
Posted by David Blevins <da...@visi.com>.
On Dec 5, 2006, at 10:47 AM, David Jencks wrote:
>
> On Dec 3, 2006, at 4:11 PM, David Blevins wrote:
>
>>
>> On Dec 3, 2006, at 1:53 PM, Manu George wrote:
>>
>>> Hi David B ,
>>> I got it working i.e am able to get the EntityManagerFactory
>>> from JNDI. In the persistence.xml I have to give the jta
>>> datasource as
>>> java:openejb/connector/Default JDBC Database for the default
>>> datasource
>>> Is this approach acceptable? Or should it be in the
>>> java:comp/env/jdbc/datasource format?
>>
>> Excellent! That's a great first run. It is supposed to be of the
>> java:comp/env variety,
>
> I disagree. As I understand it, the jpa EMF is something you
> configure in the server, not per ejb. Thus the datasource it uses
> should not change depending on which ejb happens to be using it.
Took a closer look at the tck and it looks like you're right. I
assume then that the way you specify a global data source name is
vendor specific and no spec defined?
> Same for EM.
>
> All or most of this stuff is all working in geronimo/openejb2. It
> might be useful to look at as a reference or even consider sharing
> code.
I will. On the same note was the code that creates EMFs in openejb3
useful when you created the one in geronimo/openejb2? Hope there was
something in there you could reuse.
-David
>
> thanks
> david jencks
>
>> but using "java:openejb/connector/Default JDBC Database" will work
>> just fine to start with. We'll likely have to rework the code a
>> bit to support the java:comp/env thing.
>>
>> Anyone want to update the Enc*Bean tests to test lookup of
>> PersistenceUnits?
>>
>> -David
>>
>>> Thanks
>>> Manu
>>>
>>> On 12/2/06, David Blevins <da...@visi.com> wrote:
>>>>
>>>> On Dec 1, 2006, at 12:02 PM, Manu George wrote:
>>>>
>>>> > I have a doubt in this JIRA. There is a class called
>>>> > EntityManagerFactoryCache which is an object factory already
>>>> present
>>>> > in OEJB. It also has variables to store all the
>>>> > EntityManagerFactories.
>>>>
>>>> You probably don't want to use that object. Likely somewhere in
>>>> the
>>>> EjbJarBuilder you'll use the PersistenceDeployer.loadPersistence
>>>> method directly to get all the EntityManagerFactories. Then you'll
>>>> probably want to pass that map into the constructor of the
>>>> EnterpriseBeanBuilder and then into the constructor of the
>>>> JndiEncBuilder.
>>>>
>>>> In the JndiEncBuilder you'll add a new method to process all the
>>>> PersistenceUnitInfo objects in JndiEncInfo. Of course the
>>>> PersistenceUnitInfo class doesn't exist yet, let me just create
>>>> that
>>>> to make this first one easy. Ok, see this commit:
>>>>
>>>> http://svn.apache.org/viewvc?view=rev&revision=481478
>>>>
>>>> (ignore that change to JndiEncBuilder, that was unrelated)
>>>>
>>>> You'll need to implement the method
>>>> JndiEncInfoBuilder.buildPersistenceUnitRefInfos() created with that
>>>> commit.
>>>>
>>>> > I also noticed that there are two Reference interfaces in OEJB
>>>> > in org.apache.openejb.core.ivm.naming and
>>>> org.apache.openejb.naming
>>>> > packages. What is the significance of having two? Why don't
>>>> any of the
>>>> > references extend from the javax.naming package?
>>>>
>>>> Our current JNDI implementation is just a bit obtuse. I predict at
>>>> some point in the future we may ditch it for the xbean-naming
>>>> implementation which is a bit nicer. Till then just create an
>>>> implementation of org.apache.openejb.core.ivm.naming.Reference and
>>>> pass the EntityManagerFactory right in the constructor.
>>>>
>>>> We may want to switch it to create the EntityManagerFactory inside
>>>> the getObject method of the Reference class, but this is good
>>>> enough
>>>> for now. We'll see what the TCK has to say about it when the time
>>>> comes.
>>>>
>>>> -David
>>>>
>>>>
>>>>
>>>>
>>>
>>
>
Re: Container coding tasks
Posted by David Jencks <da...@yahoo.com>.
On Dec 3, 2006, at 4:11 PM, David Blevins wrote:
>
> On Dec 3, 2006, at 1:53 PM, Manu George wrote:
>
>> Hi David B ,
>> I got it working i.e am able to get the EntityManagerFactory
>> from JNDI. In the persistence.xml I have to give the jta
>> datasource as
>> java:openejb/connector/Default JDBC Database for the default
>> datasource
>> Is this approach acceptable? Or should it be in the
>> java:comp/env/jdbc/datasource format?
>
> Excellent! That's a great first run. It is supposed to be of the
> java:comp/env variety,
I disagree. As I understand it, the jpa EMF is something you
configure in the server, not per ejb. Thus the datasource it uses
should not change depending on which ejb happens to be using it.
Same for EM.
All or most of this stuff is all working in geronimo/openejb2. It
might be useful to look at as a reference or even consider sharing code.
thanks
david jencks
> but using "java:openejb/connector/Default JDBC Database" will work
> just fine to start with. We'll likely have to rework the code a
> bit to support the java:comp/env thing.
>
> Anyone want to update the Enc*Bean tests to test lookup of
> PersistenceUnits?
>
> -David
>
>> Thanks
>> Manu
>>
>> On 12/2/06, David Blevins <da...@visi.com> wrote:
>>>
>>> On Dec 1, 2006, at 12:02 PM, Manu George wrote:
>>>
>>> > I have a doubt in this JIRA. There is a class called
>>> > EntityManagerFactoryCache which is an object factory already
>>> present
>>> > in OEJB. It also has variables to store all the
>>> > EntityManagerFactories.
>>>
>>> You probably don't want to use that object. Likely somewhere in the
>>> EjbJarBuilder you'll use the PersistenceDeployer.loadPersistence
>>> method directly to get all the EntityManagerFactories. Then you'll
>>> probably want to pass that map into the constructor of the
>>> EnterpriseBeanBuilder and then into the constructor of the
>>> JndiEncBuilder.
>>>
>>> In the JndiEncBuilder you'll add a new method to process all the
>>> PersistenceUnitInfo objects in JndiEncInfo. Of course the
>>> PersistenceUnitInfo class doesn't exist yet, let me just create that
>>> to make this first one easy. Ok, see this commit:
>>>
>>> http://svn.apache.org/viewvc?view=rev&revision=481478
>>>
>>> (ignore that change to JndiEncBuilder, that was unrelated)
>>>
>>> You'll need to implement the method
>>> JndiEncInfoBuilder.buildPersistenceUnitRefInfos() created with that
>>> commit.
>>>
>>> > I also noticed that there are two Reference interfaces in OEJB
>>> > in org.apache.openejb.core.ivm.naming and
>>> org.apache.openejb.naming
>>> > packages. What is the significance of having two? Why don't any
>>> of the
>>> > references extend from the javax.naming package?
>>>
>>> Our current JNDI implementation is just a bit obtuse. I predict at
>>> some point in the future we may ditch it for the xbean-naming
>>> implementation which is a bit nicer. Till then just create an
>>> implementation of org.apache.openejb.core.ivm.naming.Reference and
>>> pass the EntityManagerFactory right in the constructor.
>>>
>>> We may want to switch it to create the EntityManagerFactory inside
>>> the getObject method of the Reference class, but this is good enough
>>> for now. We'll see what the TCK has to say about it when the time
>>> comes.
>>>
>>> -David
>>>
>>>
>>>
>>>
>>
>
Re: Container coding tasks
Posted by David Blevins <da...@visi.com>.
On Dec 3, 2006, at 1:53 PM, Manu George wrote:
> Hi David B ,
> I got it working i.e am able to get the EntityManagerFactory
> from JNDI. In the persistence.xml I have to give the jta datasource as
> java:openejb/connector/Default JDBC Database for the default
> datasource
> Is this approach acceptable? Or should it be in the
> java:comp/env/jdbc/datasource format?
Excellent! That's a great first run. It is supposed to be of the
java:comp/env variety, but using "java:openejb/connector/Default JDBC
Database" will work just fine to start with. We'll likely have to
rework the code a bit to support the java:comp/env thing.
Anyone want to update the Enc*Bean tests to test lookup of
PersistenceUnits?
-David
> Thanks
> Manu
>
> On 12/2/06, David Blevins <da...@visi.com> wrote:
>>
>> On Dec 1, 2006, at 12:02 PM, Manu George wrote:
>>
>> > I have a doubt in this JIRA. There is a class called
>> > EntityManagerFactoryCache which is an object factory already
>> present
>> > in OEJB. It also has variables to store all the
>> > EntityManagerFactories.
>>
>> You probably don't want to use that object. Likely somewhere in the
>> EjbJarBuilder you'll use the PersistenceDeployer.loadPersistence
>> method directly to get all the EntityManagerFactories. Then you'll
>> probably want to pass that map into the constructor of the
>> EnterpriseBeanBuilder and then into the constructor of the
>> JndiEncBuilder.
>>
>> In the JndiEncBuilder you'll add a new method to process all the
>> PersistenceUnitInfo objects in JndiEncInfo. Of course the
>> PersistenceUnitInfo class doesn't exist yet, let me just create that
>> to make this first one easy. Ok, see this commit:
>>
>> http://svn.apache.org/viewvc?view=rev&revision=481478
>>
>> (ignore that change to JndiEncBuilder, that was unrelated)
>>
>> You'll need to implement the method
>> JndiEncInfoBuilder.buildPersistenceUnitRefInfos() created with that
>> commit.
>>
>> > I also noticed that there are two Reference interfaces in OEJB
>> > in org.apache.openejb.core.ivm.naming and org.apache.openejb.naming
>> > packages. What is the significance of having two? Why don't any
>> of the
>> > references extend from the javax.naming package?
>>
>> Our current JNDI implementation is just a bit obtuse. I predict at
>> some point in the future we may ditch it for the xbean-naming
>> implementation which is a bit nicer. Till then just create an
>> implementation of org.apache.openejb.core.ivm.naming.Reference and
>> pass the EntityManagerFactory right in the constructor.
>>
>> We may want to switch it to create the EntityManagerFactory inside
>> the getObject method of the Reference class, but this is good enough
>> for now. We'll see what the TCK has to say about it when the time
>> comes.
>>
>> -David
>>
>>
>>
>>
>
Re: Container coding tasks
Posted by Manu George <ma...@gmail.com>.
Hi David B ,
I got it working i.e am able to get the EntityManagerFactory
from JNDI. In the persistence.xml I have to give the jta datasource as
java:openejb/connector/Default JDBC Database for the default datasource
Is this approach acceptable? Or should it be in the
java:comp/env/jdbc/datasource format?
Thanks
Manu
On 12/2/06, David Blevins <da...@visi.com> wrote:
>
> On Dec 1, 2006, at 12:02 PM, Manu George wrote:
>
> > I have a doubt in this JIRA. There is a class called
> > EntityManagerFactoryCache which is an object factory already present
> > in OEJB. It also has variables to store all the
> > EntityManagerFactories.
>
> You probably don't want to use that object. Likely somewhere in the
> EjbJarBuilder you'll use the PersistenceDeployer.loadPersistence
> method directly to get all the EntityManagerFactories. Then you'll
> probably want to pass that map into the constructor of the
> EnterpriseBeanBuilder and then into the constructor of the
> JndiEncBuilder.
>
> In the JndiEncBuilder you'll add a new method to process all the
> PersistenceUnitInfo objects in JndiEncInfo. Of course the
> PersistenceUnitInfo class doesn't exist yet, let me just create that
> to make this first one easy. Ok, see this commit:
>
> http://svn.apache.org/viewvc?view=rev&revision=481478
>
> (ignore that change to JndiEncBuilder, that was unrelated)
>
> You'll need to implement the method
> JndiEncInfoBuilder.buildPersistenceUnitRefInfos() created with that
> commit.
>
> > I also noticed that there are two Reference interfaces in OEJB
> > in org.apache.openejb.core.ivm.naming and org.apache.openejb.naming
> > packages. What is the significance of having two? Why don't any of the
> > references extend from the javax.naming package?
>
> Our current JNDI implementation is just a bit obtuse. I predict at
> some point in the future we may ditch it for the xbean-naming
> implementation which is a bit nicer. Till then just create an
> implementation of org.apache.openejb.core.ivm.naming.Reference and
> pass the EntityManagerFactory right in the constructor.
>
> We may want to switch it to create the EntityManagerFactory inside
> the getObject method of the Reference class, but this is good enough
> for now. We'll see what the TCK has to say about it when the time
> comes.
>
> -David
>
>
>
>
Re: Container coding tasks
Posted by David Blevins <da...@visi.com>.
On Dec 1, 2006, at 12:02 PM, Manu George wrote:
> I have a doubt in this JIRA. There is a class called
> EntityManagerFactoryCache which is an object factory already present
> in OEJB. It also has variables to store all the
> EntityManagerFactories.
You probably don't want to use that object. Likely somewhere in the
EjbJarBuilder you'll use the PersistenceDeployer.loadPersistence
method directly to get all the EntityManagerFactories. Then you'll
probably want to pass that map into the constructor of the
EnterpriseBeanBuilder and then into the constructor of the
JndiEncBuilder.
In the JndiEncBuilder you'll add a new method to process all the
PersistenceUnitInfo objects in JndiEncInfo. Of course the
PersistenceUnitInfo class doesn't exist yet, let me just create that
to make this first one easy. Ok, see this commit:
http://svn.apache.org/viewvc?view=rev&revision=481478
(ignore that change to JndiEncBuilder, that was unrelated)
You'll need to implement the method
JndiEncInfoBuilder.buildPersistenceUnitRefInfos() created with that
commit.
> I also noticed that there are two Reference interfaces in OEJB
> in org.apache.openejb.core.ivm.naming and org.apache.openejb.naming
> packages. What is the significance of having two? Why don't any of the
> references extend from the javax.naming package?
Our current JNDI implementation is just a bit obtuse. I predict at
some point in the future we may ditch it for the xbean-naming
implementation which is a bit nicer. Till then just create an
implementation of org.apache.openejb.core.ivm.naming.Reference and
pass the EntityManagerFactory right in the constructor.
We may want to switch it to create the EntityManagerFactory inside
the getObject method of the Reference class, but this is good enough
for now. We'll see what the TCK has to say about it when the time
comes.
-David
Re: Container coding tasks
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 12/1/06, Manu George <ma...@gmail.com> wrote:
> Also if I use this method I will have to create a
> PersistenceUnitReference object that should know how to get the
> respective factory from the cache. But I should keep a singleton
> instance of EntityManagerFactoryCache somewhere if I don't make the
> cache variable static.
>
> I also noticed that there are two Reference interfaces in OEJB
> in org.apache.openejb.core.ivm.naming and org.apache.openejb.naming
> packages. What is the significance of having two? Why don't any of the
> references extend from the javax.naming package?
I think we'll have to wait for Dave's or others' comments as I have no idea why.
(It still worth sending questions here even though one might be
tempted to send them directly to Dave - others will learn it with you
so chances are there will be more Dave's in the near future - and
believe me I'm not only talking about Dave B. ;-))
Jacek
--
Jacek Laskowski
http://www.jaceklaskowski.pl
Re: Container coding tasks
Posted by Manu George <ma...@gmail.com>.
Hi David B, Jacek,Mohd,
Continuing from the prev mail. Sorry for the two mails
Also if I use this method I will have to create a
PersistenceUnitReference object that should know how to get the
respective factory from the cache. But I should keep a singleton
instance of EntityManagerFactoryCache somewhere if I don't make the
cache variable static.
I also noticed that there are two Reference interfaces in OEJB
in org.apache.openejb.core.ivm.naming and org.apache.openejb.naming
packages. What is the significance of having two? Why don't any of the
references extend from the javax.naming package?
Thanks
Manu
On 12/2/06, Manu George <ma...@gmail.com> wrote:
> Hi David B,Jacek,Mohammad
> I have a doubt in this JIRA. There is a class called
> EntityManagerFactoryCache which is an object factory already present
> in OEJB. It also has variables to store all the
> EntityManagerFactories. Should this be used to store all the
> factories. If it is used then shouldn't the cache variable be static?.
> If this is used then the first time a person looks up the
> EntityManagerFactories it will take some time. Is this acceptable or
> should this process be done during deployment?
>
> Thanks
> Manu
>
>
>
> On 11/30/06, Manu George <ma...@gmail.com> wrote:
> > Hi Jacek,
> > Point Taken. I just need to get a bit familiar with
> > persistence.xmls and get an idea on how JPA works with EJB. Some user
> > level knowledge of openJPA also is required I guess. Will start
> > working on the JIRA.
> >
> > Thanks
> > Manu
> >
> > On 11/29/06, Jacek Laskowski <ja...@laskowski.net.pl> wrote:
> > > On 11/29/06, Manu George <ma...@gmail.com> wrote:
> > > > Hi David B,
> > > > I will be happy to take this up. I guess I need to go
> > > > through the JPA spec/OpenJPA before starting on this as I have not yet
> > > > done that. This issue will give me the drive to do that :-).
> > >
> > > I don't think you'll need to o into the details of (Open)JPA. As far
> > > as I understand it, the point Dave made was that everything that's
> > > required is in openejb-persistence and the last missing puzzle is to
> > > plug it into JNDI tree.
> > >
> > > Jacek
> > >
> > > --
> > > Jacek Laskowski
> > > http://www.jaceklaskowski.pl
> > >
> >
>