OK I am almost done rewriting the proxy and container invoker stack, this is not about that but the container understanding.
First off a small API change in the stuff that remains namely the CI getEJB types that today return typed EJB interfaces, I want to return Objects to allow for optimization between proxy and container, more on that later. I will get numbers. The note is on the current understanding of container as a one one mapping with invokers. One of the goals of the current design is to completely detach the invoker stack from the container one. An EJB is nothing but a collection of predefined behavior (transaction and security) with guaranteed cache on the server. In the theoretical world what we use to invoke the container stack should be transparent. I.e. the same contianer with the same series of cached object shouldn't care whether we use IIOP or JRMP or webservices. In our implementation it is not the case, some of the calls namely the lifecycle ones (create/find) are typed in the sense that they hardcode the creation of the proxies with the one invocation stack that is supposed to be calling them. There is a one one mapping in invocation and container through this link. It is a weak link. It also clearly draws the line for a association with the invocation as opposed to the container invoker. I have coded in the new proxy and invocation the support for an absolutely "generic" container representation. For all practical purposes the JNDI name is good the bottom line being that the same container stack as we understand it today can be called through 2 invocation stacks as 2 different containers sharing the same cache. The power would be really to have the centralized caches, as dedicating a cache and a container to a given invocation stack is a limitation of the current design. So the support is there, and by associating the invocation with an identifier, we are then capable from any stack inside of saying "look I am involved with creators and I need to know your stack, personally I don't care (I don't have a pointer) but you care, that is where you came from and it is where you are returning to" we do have that information it is in the right place (the invocation not the container) and i will move it. As a byproduct of the generic association we are also able to retrieve relevant CL from any stack that touches that invocation. In short the invocation is it. PS: In the immediate future I want to get the current proxy and invocation working with the legacy ContainerInvoker, this way I do keep support for local stuff and the IIOP stuff unchanged, as is, and the creation mechanisms are unchanged as well. I just wanted to share the first insight into generic invokers that made sense to me :) documenting as scott says. " It seems you feel our work is not a benefit to the public? Replicants are like any other machine, they are either a benefit or a hazard, if they are a benefit it is not my problem." xxxxxxxxxxxxxxxx Marc Fleury President JBoss Group, LLC xxxxxxxxxxxxxxxx _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
