Re: [JBoss-dev] notes on Container as abstract collection
Hi, Not sure I've read your message correctly... One thought I've been toying with is that it should be possible to use different protocols to access metods of the same enterprise bean. I am not talking about deploying two almost identical (except for some change on a deployment descriptor) copies of the same bean, one to be called via JRMP and the other via IIOP. I mean deploying just one enterprise bean, which would have both a JRMP and an IIOP container invoker associated to it. Is this what you are getting at? Best, Francisco On Mon, 26 Nov 2001, marc fleury wrote: 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. Marc Fleury President JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] notes on Container as abstract collection
|-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |Francisco Reverbel |Sent: Tuesday, November 27, 2001 5:27 AM |To: marc fleury |Cc: Jboss-Development@Lists. Sourceforge. Net |Subject: Re: [JBoss-dev] notes on Container as abstract collection | | |Hi, | |Not sure I've read your message correctly... One thought I've been toying |with is that it should be possible to use different protocols to access |metods of the same enterprise bean. I am not talking about deploying two |almost identical (except for some change on a deployment descriptor) |copies of the same bean, one to be called via JRMP and the other via |IIOP. I mean deploying just one enterprise bean, which would have both a |JRMP and an IIOP container invoker associated to it. | |Is this what you are getting at? yes, I want the same container to live under 3 different invokers, the JRMP the IIOP the .NET right now we are talking 3 copies and 3 caches that won't be synchronized. The performance will be much better, marcf | |Best, | |Francisco | |On Mon, 26 Nov 2001, marc fleury wrote: | | 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. | | | | Marc Fleury | President | JBoss Group, LLC | | | | ___ | Jboss-development mailing list | [EMAIL PROTECTED] | https://lists.sourceforge.net/lists/listinfo/jboss-development | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] notes on Container as abstract collection
I read this email yesterday. It made sense, but I couldn't follow some of the arguments. Then last night I was laying in bed at about 4am, and I was pissed about finders. The getEntityCollection method on ContainerInvoke is declared to throw a RemoteExceptions even though no implementations throw a RemoteException from this method. And then your message clicked. Why the fuck should the container invoker care about the container internally loading entities into memory? That isn't its job; Its job it to invoke methods on the container and them propagate the results back to the caller. Oh, that is what marc was talking about. I'm excited to see this change when you get it done and I have some question: Are you going to move the ctx cache code from the container invoker to a container level object? Are you going to remove the RemoteExceptions from this code? I think that in general remote exceptions should be removed from all of the internal container code. If there is a generic exception in the container, then it should use an EJBException instead, and if the call happens to be propagated over a remote interface, it can be wrapped with a remote exception at that point. When you get the change in, I'll be more then happy to convert the cmp 2 code quickly. -dain -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Monday, November 26, 2001 3:27 PM To: Jboss-Development@Lists. Sourceforge. Net Subject: [JBoss-dev] notes on Container as abstract collection 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. Marc Fleury President JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists
[JBoss-dev] notes on Container as abstract collection
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. Marc Fleury President JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
