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
It's great for container construction, etc were there are definite
user supplied "parameters" or "configuration data". For the
CoreContext and other very internal objects with no configurable
properties or implementations, there's really no upside to not
constructing them ourselves.
-David
