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 <[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
> > >
> > >
> >
> >
> >
>



Reply via email to