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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
> > >
> > >
> >
> >
> >
>
