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 :). -- Thanks - Mohammad Nour
