Hi David... On 12/25/06, David Blevins <[EMAIL PROTECTED]> wrote:
On Dec 22, 2006, at 4:39 PM, Mohammad Nour El-Din wrote: > On 12/23/06, David Blevins <[EMAIL PROTECTED]> wrote: >> >> >> On Dec 21, 2006, at 4:05 AM, Mohammad Nour El-Din wrote: >> >> > On 12/20/06, David Blevins <[EMAIL PROTECTED]> wrote: >> >> >> >> >> >> On Dec 19, 2006, at 4:04 AM, Mohammad Nour El-Din wrote: >> >> >> >> > Hi DBlevins and All... >> >> > >> >> > Regarding the OPENEJB-368, I came out with two ideas to get this >> >> > JIRA done, >> >> > one which is simple and straight forward but I doubt it is the >> >> > accurate one, >> >> > the other needs more code change and it took me a while to >> >> > investigate for >> >> > it, the two approaches are: >> >> > >> >> > 1. For each EJBContext.lookup method call an InitialContext >> >> > instance >> >> > is created and used for looking-up the resource bound to >> the >> >> > provided JNDI name (The simple solution). >> >> >> >> I'd go with simple! :) >> >> >> >> > 2. Each EJBContext is instantiated with the initial naming >> >> > context or the JNDI provider that will be provided to the >> >> > responsible >> >> > container, much like the way TransactionManager and >> >> > SecurityService are >> >> > provided to the current implementation of the different >> >> > EJBContext(s) >> >> > through the corresponding container type, and then this >> naming >> >> > context\provider will be used for each call to the >> >> > EJBContext.lookup method. (The more complex one). >> >> > >> >> >> >> Yea, that code used to be simpler too. I was on a rampage to >> remove >> >> static references to the OpenEJB class and the static call to >> get the >> >> TransactionManager turned into it being passed in on the >> >> constructor. If it wasn't for the fact that we then had to >> pass the >> >> TransactionManager along to several pieces of code that before >> didn't >> >> reference it, it'd say it was a change for the better. We >> might just >> >> revert to something similar to what we had before. >> >> >> >> -David >> > >> > >> > So I would go with the simple solution, but as a reference for the >> > future, I >> > have a crazy idea which I don't know how to implement right now but >> > I think >> > it will relief the code from being dependent on each other >> > statically, why >> > not to have some sort of a registry or IoC like implementation >> so each >> > container type can declare what services it needs to start its >> > work, like >> > the TransactionManager and SecurityService, and such services or >> > managers >> > can be registered by the type of the interface it supports and >> can be >> > looked-up by this interface and injected into the requesting >> > container, and >> > we let the constructor of such containers to have only the normal >> > constructor parameters like ID, etc... . >> > This is much like Maven and Spring works, I don't know how this >> > would be >> > implemented and its impact on the current code, but this why I >> > raised the >> > idea of moving to OSGi if you remember, so if you have any hints or >> > thoughts >> > about this I'd like to here it from you, and of course I'd like to >> > work on >> > it :). >> >> That's not such a crazy idea, and in fact is already there. :) >> >> See for example this chunk of xml: >> >> <ServiceProvider id="Default CMP Container" >> provider-type="Container" >> constructor="id, transactionManager, >> securityService, deployments, CmpEngineFactory, Engine, >> ConnectorName" >> class- >> name="org.apache.openejb.core.cmp.CmpContainer"> >> >> ...from this file: >> >> http://svn.apache.org/repos/asf/incubator/openejb/trunk/openejb3/ >> container/openejb-core/src/main/resources/META-INF/ >> org.apache.openejb/ >> service-jar.xml > > > Yeah I know this xml file, it is the complex way I talked to you > about, what > I meant with the complex way is that we define a new *constructor* > parameter, lets say it would be *namingContext*, and the > implementation of > this *namingContext* will be attached to a JVM property, just like the > *TransactionManager* and *SecurityService* implementations, and > then this > implementation will be used by the *ObjectRecipe* used to construct > different types of containers, and the containers will use this > implementation to construct new instances of EJB Contexts, and then > I can > use this name context for the implementation of the > EJBContext.lookupmethod,take a look at this > http://svn.apache.org/repos/asf/incubator/openejb/trunk/openejb3/ > container/openejb-core/src/main/java/org/apache/openejb/assembler/ > classic/ContainersBuilder.java, > within *buildContainer* method, this is why I asked you for your > opinion > first time cause this way needs more code change than the simple > way, what > do you think ??? go-on with this or stick with the simple way ? General rule of thumb is if there is a simple way and a complex way, always implement the simple way first and treat the complex way as a separate task. The complex way can be implemented next or later or kept on the back burner. I have lot's of ideas on the back burner I've been waiting to implement :)
Nice to know that :) I'm curious what your thoughts are on OPENEJB-127 'Expanded types for
env-entries in JNDI' as that's one area where users *will* want to plug in more things like converters, etc for supporting more data types that can then be injected into beans. It'd be great to get this one in. Users will love it.
Well I didn't take a look at it yet, have been busy lately, but going to finish OPENEJB-368 and I will totally concentrate on it. -David
-- Thanks - Mohammad Nour
