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 <[EMAIL PROTECTED]> 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
