Re: Concerning JNDI lookingup EJB3.0 beans using its local Home and Component interfaces

[David Blevins <da...@visi.com>]

This is biting us again.  Here's the old thread for reference:

   http://www.nabble.com/-openejb-dev--Concerning-JNDI-lookingup- 
EJB3.0-beans-using-its-local-Home-and-Component-interfaces- 
tf2056868s2756.html

We've had a similar thread since:

   http://www.nabble.com/EJB3-lookup-and-JndiNameStrategy- 
tf2754441s2756.html

The summary for those who don't like to read archives is that EJB 3  
allows for multiple business interaces (local or remote) and this  
creates complications in all sorts of things.  We had simply ignored  
that this was possible and only supported one business interface.

It'd be really nice if we could support creating a single proxy that  
implemented all your business interfaces, so we didn't have to create  
individual proxies for each business interface and then have to come  
up with unique names for each in JNDI.  We will probably have to do  
that anyway, but at the very least it would be nice to try and create  
a proxy that implements all the proxies and put it in JNDI under a  
simpler name.  There are some complications for doing this though,  
i've tried to summarize them here:

   http://cwiki.apache.org/OPENEJB/multiple-business-interface- 
hazzards.html

I immediately thought, "Well that sucks, now I have to remove the  
code I added yesterday for supporting all business interfaces on one  
proxy."  So I immediately started writing the above test cases and  
document on why this was completely impossible to do.

But then I occurred to me that the hazzards of implementing multiple  
business interfaces can only occur if the bean itself does *not*  
implement it's business interfaces.  In all cases where the bean  
implements every business interface, which i think is the norm,  
having one proxy doing the same is completely fine and I think is  
what people would naturally expect.

So the question ultimately comes down to, should we support the idea  
of the all-in-one proxy where possible or do we not support it at all  
because it isn't possible under all circumstances?

I'd personally be inclined to say it is supported we just need to  
check that your bean implements all your business interfaces before  
attempting to create an all-in-one proxy, then log either way about  
what we could or could not do.

Either way you cut it we're still going to need to support the one- 
proxy-per-business-interface approach which means we'll have to have  
a new naming convention for what they're called that likely  
incorporates the name of the business interface in some way.  This is  
where the two quoted threads really come into play.  We should  
probably decide on what we want to do there as we're just about done  
with our "first release" to do list we discussed a while back.

Thoughts all around?  Throw in your $0.02 if you have 'em.  As always  
you don't need to be a committer to share your thoughts -- so pipe  
up! :)

Going to post this to the user list also (edited down) and see if we  
can't get some users to provide us with some preference as well.


-David

Re: Business Interface Proxies (was: Re: Concerning JNDI lookingup EJB3.0 beans using its local Home and Component interfaces)

[David Blevins <da...@visi.com>]

Ok, some updates.

The code that creates intravm proxy handlers and proxies has been  
cleaned and consolidated significantly to the point where we can dig  
deeper into this functionality.

The high-level changes were to:
   - Eliminate all code throughout the system that assumed it knew  
how to create a proxy
   - Have the Container create ProxyInfo objects with only the  
DeploymentInfo and the primary key and leave knowledge of the proxy  
type and interfaces to the Server.

After having gone through the refactoring and cleaning it's clear it  
should have been this way all along as it's not only simpler,  
smaller, and more flexible but it's much more inline with the basic  
concept that the Container and Server are separate.

It's always fun when you get to remove more code than you add and  
*gain* functionality, flexibility, and simplicity.  Love it!

We should be able to support all sorts of proxy styles now (all in  
one, one each, some mix of both maybe, etc.) without any extra burden  
on the containers at all, which is just great.

Next step is to update the naming code to build the proxies we need  
and allow for a flexible way for users to control the names using  
some of the ideas we've discussed.  With the cleaned up code it will  
be way easier for us to change and adjust that part of the puzzle  
without much headache at all.

-David


On Apr 13, 2007, at 2:38 PM, David Blevins wrote:

> Ok, so I'm trying to hack all this together based on the feedback  
> on what might be good ways to handle all-in-one proxies for  
> business interfaces vs the required either way one-proxy-per- 
> interface approaches.
>
> Couple notes, as Manu asked it doesn't look like failing the  
> deployment if all interfaces can be implemented is a compliant  
> option, but we certainly could have a flag that turns this on for  
> those that want to depend upon this feature.  We can still try to  
> implement all interfaces, but if it's not possible best we can do  
> is log it.
>
> As Mohammad mentioned it looks like some sort of ejbName +  
> businessInterface JNDI name is going to be required regardless now  
> as even if we want to support an all-in-one business interface  
> proxy, we still have to support the one-proxy-per-interface  
> approach and that means binding several entries into JNDI for the  
> same bean.  To pull this off we're going to have to make some  
> changes to the JndiNameStrategy concept we have.
>
> Also, these two methods of javax.ejb.SessionContext are *very*  
> related to this whole topic:
>
>     <T> T getBusinessObject(java.lang.Class<T> aClass);
>
>     java.lang.Class getInvokedBusinessInterface();
>
> The first method is obviously a one-proxy-per-interface view of a  
> bean and this should work more compliantly once we get this stuff in.
>
> The second method is a very big pain in that in order to support it  
> we have no choice but to make the proxy remember what "interface"  
> it is and either pass it into the container or make it available on  
> the thread.  It would be great if we could use  
> method.getDeclaringClass() to figure out which business interface  
> was invoked, but unfortunately if there is any sort of shared  
> inheritance among the business interfaces (very common) it won't  
> work reliably.  We're actually doing that now and it really needs  
> to be fixed.
>
> So we may end up having to change our container invoke signature to  
> look like this:
>
>     public Object invoke(Object deployID, Method callMethod, Object  
> [] args, Object primKey, Class interfaceClass) throws  
> OpenEJBException;
>
> I'm personally not particularly fond of doing that but it does fix  
> a few issues around not knowing exactly what kind of proxy called  
> us (remote interface, local interface, service endpoint interface,  
> business interface, exactly what business interface, etc.), so  
> heads up on a potential change to the Container interface.
>
> This change would also allow us to some day "claw back" the  
> interface specific exception handling code that crept into the  
> proxy handlers putting it back into the container and then  
> restoring the idea the proxies only have to understand three  
> exception types (ApplicationException, SystemException, and  
> Error).  Right now the proxy handlers catch those exceptions but  
> then have to convert them into what the spec says is the proper  
> exception for that interface; for example NoSuchObjectException vs.  
> NoSuchObjectLocalException vs. NoSuchEJBException.
>
> Anyway, lots of moving parts in this one.
>
> -David
>
>
> On Apr 12, 2007, at 1:45 PM, Mohammad Nour El-Din wrote:
>
>> Hi All...
>>
>> David, I've answered the question regarding to support all-in-one  
>> proxy or
>> not. And regarding the naming convention of one-proxy-per- 
>> interface, I think
>> we discussed it before on this thread long time a go, and I will  
>> mention my
>> opinion just for refreshment. I suggested not use the deployment- 
>> id as the
>> default JNDI, we should let the use specify it in the openejb- 
>> jar.xml file,
>> or it should be created from the qualified name of the bean's  
>> class and
>> append "/<interface-name". And AFAIR the specs use something like  
>> this for
>> creating default JNDI names for referenced resources.
>>
>> On 4/12/07, David Blevins <da...@visi.com> wrote:
>>>
>>> This is biting us again.  Here's the old thread for reference:
>>>
>>>    http://www.nabble.com/-openejb-dev--Concerning-JNDI-lookingup-
>>> EJB3.0-beans-using-its-local-Home-and-Component-interfaces-
>>> tf2056868s2756.html
>>>
>>> We've had a similar thread since:
>>>
>>>    http://www.nabble.com/EJB3-lookup-and-JndiNameStrategy-
>>> tf2754441s2756.html
>>>
>>> The summary for those who don't like to read archives is that EJB 3
>>> allows for multiple business interaces (local or remote) and this
>>> creates complications in all sorts of things.  We had simply ignored
>>> that this was possible and only supported one business interface.
>>>
>>> It'd be really nice if we could support creating a single proxy that
>>> implemented all your business interfaces, so we didn't have to  
>>> create
>>> individual proxies for each business interface and then have to come
>>> up with unique names for each in JNDI.  We will probably have to do
>>> that anyway, but at the very least it would be nice to try and  
>>> create
>>> a proxy that implements all the proxies and put it in JNDI under a
>>> simpler name.  There are some complications for doing this though,
>>> i've tried to summarize them here:
>>>
>>>    http://cwiki.apache.org/OPENEJB/multiple-business-interface-
>>> hazzards.html
>>>
>>> I immediately thought, "Well that sucks, now I have to remove the
>>> code I added yesterday for supporting all business interfaces on one
>>> proxy."  So I immediately started writing the above test cases and
>>> document on why this was completely impossible to do.
>>>
>>> But then I occurred to me that the hazzards of implementing multiple
>>> business interfaces can only occur if the bean itself does *not*
>>> implement it's business interfaces.  In all cases where the bean
>>> implements every business interface, which i think is the norm,
>>> having one proxy doing the same is completely fine and I think is
>>> what people would naturally expect.
>>>
>>> So the question ultimately comes down to, should we support the idea
>>> of the all-in-one proxy where possible or do we not support it at  
>>> all
>>> because it isn't possible under all circumstances?
>>>
>>> I'd personally be inclined to say it is supported we just need to
>>> check that your bean implements all your business interfaces before
>>> attempting to create an all-in-one proxy, then log either way about
>>> what we could or could not do.
>>>
>>> Either way you cut it we're still going to need to support the one-
>>> proxy-per-business-interface approach which means we'll have to have
>>> a new naming convention for what they're called that likely
>>> incorporates the name of the business interface in some way.   
>>> This is
>>> where the two quoted threads really come into play.  We should
>>> probably decide on what we want to do there as we're just about done
>>> with our "first release" to do list we discussed a while back.
>>>
>>> Thoughts all around?  Throw in your $0.02 if you have 'em.  As  
>>> always
>>> you don't need to be a committer to share your thoughts -- so pipe
>>> up! :)
>>>
>>> Going to post this to the user list also (edited down) and see if we
>>> can't get some users to provide us with some preference as well.
>>>
>>>
>>> -David
>>>
>>>
>>
>>
>> -- 
>> Thanks
>> - Mohammad Nour
>

Business Interface Proxies (was: Re: Concerning JNDI lookingup EJB3.0 beans using its local Home and Component interfaces)

[David Blevins <da...@visi.com>]

Ok, so I'm trying to hack all this together based on the feedback on  
what might be good ways to handle all-in-one proxies for business  
interfaces vs the required either way one-proxy-per-interface  
approaches.

Couple notes, as Manu asked it doesn't look like failing the  
deployment if all interfaces can be implemented is a compliant  
option, but we certainly could have a flag that turns this on for  
those that want to depend upon this feature.  We can still try to  
implement all interfaces, but if it's not possible best we can do is  
log it.

As Mohammad mentioned it looks like some sort of ejbName +  
businessInterface JNDI name is going to be required regardless now as  
even if we want to support an all-in-one business interface proxy, we  
still have to support the one-proxy-per-interface approach and that  
means binding several entries into JNDI for the same bean.  To pull  
this off we're going to have to make some changes to the  
JndiNameStrategy concept we have.

Also, these two methods of javax.ejb.SessionContext are *very*  
related to this whole topic:

     <T> T getBusinessObject(java.lang.Class<T> aClass);

     java.lang.Class getInvokedBusinessInterface();

The first method is obviously a one-proxy-per-interface view of a  
bean and this should work more compliantly once we get this stuff in.

The second method is a very big pain in that in order to support it  
we have no choice but to make the proxy remember what "interface" it  
is and either pass it into the container or make it available on the  
thread.  It would be great if we could use method.getDeclaringClass()  
to figure out which business interface was invoked, but unfortunately  
if there is any sort of shared inheritance among the business  
interfaces (very common) it won't work reliably.  We're actually  
doing that now and it really needs to be fixed.

So we may end up having to change our container invoke signature to  
look like this:

     public Object invoke(Object deployID, Method callMethod, Object  
[] args, Object primKey, Class interfaceClass) throws OpenEJBException;

I'm personally not particularly fond of doing that but it does fix a  
few issues around not knowing exactly what kind of proxy called us  
(remote interface, local interface, service endpoint interface,  
business interface, exactly what business interface, etc.), so heads  
up on a potential change to the Container interface.

This change would also allow us to some day "claw back" the interface  
specific exception handling code that crept into the proxy handlers  
putting it back into the container and then restoring the idea the  
proxies only have to understand three exception types  
(ApplicationException, SystemException, and Error).  Right now the  
proxy handlers catch those exceptions but then have to convert them  
into what the spec says is the proper exception for that interface;  
for example NoSuchObjectException vs. NoSuchObjectLocalException vs.  
NoSuchEJBException.

Anyway, lots of moving parts in this one.

-David


On Apr 12, 2007, at 1:45 PM, Mohammad Nour El-Din wrote:

> Hi All...
>
> David, I've answered the question regarding to support all-in-one  
> proxy or
> not. And regarding the naming convention of one-proxy-per- 
> interface, I think
> we discussed it before on this thread long time a go, and I will  
> mention my
> opinion just for refreshment. I suggested not use the deployment-id  
> as the
> default JNDI, we should let the use specify it in the openejb- 
> jar.xml file,
> or it should be created from the qualified name of the bean's class  
> and
> append "/<interface-name". And AFAIR the specs use something like  
> this for
> creating default JNDI names for referenced resources.
>
> On 4/12/07, David Blevins <da...@visi.com> wrote:
>>
>> This is biting us again.  Here's the old thread for reference:
>>
>>    http://www.nabble.com/-openejb-dev--Concerning-JNDI-lookingup-
>> EJB3.0-beans-using-its-local-Home-and-Component-interfaces-
>> tf2056868s2756.html
>>
>> We've had a similar thread since:
>>
>>    http://www.nabble.com/EJB3-lookup-and-JndiNameStrategy-
>> tf2754441s2756.html
>>
>> The summary for those who don't like to read archives is that EJB 3
>> allows for multiple business interaces (local or remote) and this
>> creates complications in all sorts of things.  We had simply ignored
>> that this was possible and only supported one business interface.
>>
>> It'd be really nice if we could support creating a single proxy that
>> implemented all your business interfaces, so we didn't have to create
>> individual proxies for each business interface and then have to come
>> up with unique names for each in JNDI.  We will probably have to do
>> that anyway, but at the very least it would be nice to try and create
>> a proxy that implements all the proxies and put it in JNDI under a
>> simpler name.  There are some complications for doing this though,
>> i've tried to summarize them here:
>>
>>    http://cwiki.apache.org/OPENEJB/multiple-business-interface-
>> hazzards.html
>>
>> I immediately thought, "Well that sucks, now I have to remove the
>> code I added yesterday for supporting all business interfaces on one
>> proxy."  So I immediately started writing the above test cases and
>> document on why this was completely impossible to do.
>>
>> But then I occurred to me that the hazzards of implementing multiple
>> business interfaces can only occur if the bean itself does *not*
>> implement it's business interfaces.  In all cases where the bean
>> implements every business interface, which i think is the norm,
>> having one proxy doing the same is completely fine and I think is
>> what people would naturally expect.
>>
>> So the question ultimately comes down to, should we support the idea
>> of the all-in-one proxy where possible or do we not support it at all
>> because it isn't possible under all circumstances?
>>
>> I'd personally be inclined to say it is supported we just need to
>> check that your bean implements all your business interfaces before
>> attempting to create an all-in-one proxy, then log either way about
>> what we could or could not do.
>>
>> Either way you cut it we're still going to need to support the one-
>> proxy-per-business-interface approach which means we'll have to have
>> a new naming convention for what they're called that likely
>> incorporates the name of the business interface in some way.  This is
>> where the two quoted threads really come into play.  We should
>> probably decide on what we want to do there as we're just about done
>> with our "first release" to do list we discussed a while back.
>>
>> Thoughts all around?  Throw in your $0.02 if you have 'em.  As always
>> you don't need to be a committer to share your thoughts -- so pipe
>> up! :)
>>
>> Going to post this to the user list also (edited down) and see if we
>> can't get some users to provide us with some preference as well.
>>
>>
>> -David
>>
>>
>
>
> -- 
> Thanks
> - Mohammad Nour

Re: Concerning JNDI lookingup EJB3.0 beans using its local Home and Component interfaces

[Mohammad Nour El-Din <no...@gmail.com>]

Hi All...

David, I've answered the question regarding to support all-in-one proxy or
not. And regarding the naming convention of one-proxy-per-interface, I think
we discussed it before on this thread long time a go, and I will mention my
opinion just for refreshment. I suggested not use the deployment-id as the
default JNDI, we should let the use specify it in the openejb-jar.xml file,
or it should be created from the qualified name of the bean's class and
append "/<interface-name". And AFAIR the specs use something like this for
creating default JNDI names for referenced resources.

On 4/12/07, David Blevins <da...@visi.com> wrote:
>
> This is biting us again.  Here's the old thread for reference:
>
>    http://www.nabble.com/-openejb-dev--Concerning-JNDI-lookingup-
> EJB3.0-beans-using-its-local-Home-and-Component-interfaces-
> tf2056868s2756.html
>
> We've had a similar thread since:
>
>    http://www.nabble.com/EJB3-lookup-and-JndiNameStrategy-
> tf2754441s2756.html
>
> The summary for those who don't like to read archives is that EJB 3
> allows for multiple business interaces (local or remote) and this
> creates complications in all sorts of things.  We had simply ignored
> that this was possible and only supported one business interface.
>
> It'd be really nice if we could support creating a single proxy that
> implemented all your business interfaces, so we didn't have to create
> individual proxies for each business interface and then have to come
> up with unique names for each in JNDI.  We will probably have to do
> that anyway, but at the very least it would be nice to try and create
> a proxy that implements all the proxies and put it in JNDI under a
> simpler name.  There are some complications for doing this though,
> i've tried to summarize them here:
>
>    http://cwiki.apache.org/OPENEJB/multiple-business-interface-
> hazzards.html
>
> I immediately thought, "Well that sucks, now I have to remove the
> code I added yesterday for supporting all business interfaces on one
> proxy."  So I immediately started writing the above test cases and
> document on why this was completely impossible to do.
>
> But then I occurred to me that the hazzards of implementing multiple
> business interfaces can only occur if the bean itself does *not*
> implement it's business interfaces.  In all cases where the bean
> implements every business interface, which i think is the norm,
> having one proxy doing the same is completely fine and I think is
> what people would naturally expect.
>
> So the question ultimately comes down to, should we support the idea
> of the all-in-one proxy where possible or do we not support it at all
> because it isn't possible under all circumstances?
>
> I'd personally be inclined to say it is supported we just need to
> check that your bean implements all your business interfaces before
> attempting to create an all-in-one proxy, then log either way about
> what we could or could not do.
>
> Either way you cut it we're still going to need to support the one-
> proxy-per-business-interface approach which means we'll have to have
> a new naming convention for what they're called that likely
> incorporates the name of the business interface in some way.  This is
> where the two quoted threads really come into play.  We should
> probably decide on what we want to do there as we're just about done
> with our "first release" to do list we discussed a while back.
>
> Thoughts all around?  Throw in your $0.02 if you have 'em.  As always
> you don't need to be a committer to share your thoughts -- so pipe
> up! :)
>
> Going to post this to the user list also (edited down) and see if we
> can't get some users to provide us with some preference as well.
>
>
> -David
>
>


-- 
Thanks
- Mohammad Nour