You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Mohammad Nour El-Din <no...@gmail.com> on 2006/12/19 13:04:44 UTC
Regarding OPENEJB-368 implementation
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).
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).
I need you to comment on this before I go through the implementation.
--
Thanks
- Mohammad Nour
Re: Regarding OPENEJB-368 implementation
Posted by David Blevins <da...@visi.com>.
On Dec 27, 2006, at 8:22 PM, Mohammad Nour El-Din wrote:
> On 12/27/06, David Blevins <da...@visi.com> wrote:
>>
>>
>> On Dec 25, 2006, at 5:12 PM, Mohammad Nour El-Din wrote:
>>
>> > On 12/25/06, David Blevins <da...@visi.com> wrote:
>> >
>> >> 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.
>>
>> Cool, that's no problem. Future note though, we should only take
>> jira issues we plan to immediately work on. If we took issues we
>> wanted to "reserve" for ourselves, then I'd have 'em all :) But of
>> course that wouldn't be fair to anyone else. ;)
>
>
> Sorry :(, I will put that in my mind, and I am sorry again
Nothing to be sorry about :)
-David
Re: Regarding OPENEJB-368 implementation
Posted by Mohammad Nour El-Din <no...@gmail.com>.
On 12/27/06, David Blevins <da...@visi.com> wrote:
>
>
> On Dec 25, 2006, at 5:12 PM, Mohammad Nour El-Din wrote:
>
> > On 12/25/06, David Blevins <da...@visi.com> wrote:
> >
> >> 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.
>
> Cool, that's no problem. Future note though, we should only take
> jira issues we plan to immediately work on. If we took issues we
> wanted to "reserve" for ourselves, then I'd have 'em all :) But of
> course that wouldn't be fair to anyone else. ;)
Sorry :(, I will put that in my mind, and I am sorry again
-David
>
>
--
Thanks
- Mohammad Nour
Re: Regarding OPENEJB-368 implementation
Posted by David Blevins <da...@visi.com>.
On Dec 25, 2006, at 5:12 PM, Mohammad Nour El-Din wrote:
> On 12/25/06, David Blevins <da...@visi.com> wrote:
>
>> 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.
Cool, that's no problem. Future note though, we should only take
jira issues we plan to immediately work on. If we took issues we
wanted to "reserve" for ourselves, then I'd have 'em all :) But of
course that wouldn't be fair to anyone else. ;)
-David
Re: Regarding OPENEJB-368 implementation
Posted by Mohammad Nour El-Din <no...@gmail.com>.
Hi David...
On 12/25/06, David Blevins <da...@visi.com> wrote:
>
>
> On Dec 22, 2006, at 4:39 PM, Mohammad Nour El-Din wrote:
>
> > On 12/23/06, David Blevins <da...@visi.com> wrote:
> >>
> >>
> >> On Dec 21, 2006, at 4:05 AM, Mohammad Nour El-Din wrote:
> >>
> >> > On 12/20/06, David Blevins <da...@visi.com> 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
Re: Regarding OPENEJB-368 implementation
Posted by David Blevins <da...@visi.com>.
On Dec 22, 2006, at 4:39 PM, Mohammad Nour El-Din wrote:
> On 12/23/06, David Blevins <da...@visi.com> wrote:
>>
>>
>> On Dec 21, 2006, at 4:05 AM, Mohammad Nour El-Din wrote:
>>
>> > On 12/20/06, David Blevins <da...@visi.com> 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 :)
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.
-David
Re: Regarding OPENEJB-368 implementation
Posted by Mohammad Nour El-Din <no...@gmail.com>.
On 12/23/06, David Blevins <da...@visi.com> wrote:
>
>
> On Dec 21, 2006, at 4:05 AM, Mohammad Nour El-Din wrote:
>
> > On 12/20/06, David Blevins <da...@visi.com> 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 ?
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
>
>
--
Thanks
- Mohammad Nour
Re: Regarding OPENEJB-368 implementation
Posted by David Blevins <da...@visi.com>.
On Dec 21, 2006, at 4:05 AM, Mohammad Nour El-Din wrote:
> On 12/20/06, David Blevins <da...@visi.com> 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
Re: Regarding OPENEJB-368 implementation
Posted by Mohammad Nour El-Din <no...@gmail.com>.
On 12/20/06, David Blevins <da...@visi.com> 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
Re: Regarding OPENEJB-368 implementation
Posted by David Blevins <da...@visi.com>.
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