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
