|OK. So that's the current state? What's the Handler in this context - is |that the JRMPInvokerProxy, for example?
no we are talking about 3.0 the "handler" is one of the proxy classes with EJB behavior but disconnected from the transport (JRMP-Proxy was 2.0). The current state is that this has been factored and that the "proxy" should really be split in interceptors allowing for pluggability of writers to the "payload". They expose invoke(Invocation) |So this is basically just moving the code that sets the security and |transaction contexts from the JRMPInvokerProxy and setting them in the |appropriate interceptors instead? yes, precisely. The trick is on the server setup and factories though. |What is the current situation with the IIOP transport and how will that |fit in with the generic proxy stuff and this stack of interceptors? you can use IIOP from the proxies. However most IIOP won't come from java clients hence no proxy. But yes the RMI/IIOP "java invoker" is kosher with that picture and will use the RMIIIOP port. |Presumably there will just be an IIOPInvoker instead, which will perform yes in the case of java client. | > The factorization right behind it is on the server side. Where we | > expose the "ProxyFactory" (already there in a primitive form) and | > that PF can export any combination of (interfaces, stack of client | > interceptors, transport) and generates the client for it. | > |Do you mean the proxy.ejb.ProxyFactory? So this would provide a return a |proxy object which contained the appropriate client-side invocation |stack, based on the above jboss.xml configuration? yes precisely. |Would you be able to have multiple client-invocation stacks per container? sure we already have most of that behavior in place. (multiple invokers). note however that if there is an interceptor that is needed on the server then all clients must have it as well. Thus the invoker "stack" can only vary in transport, not in behavior introduced by the plugins. | > This way for ANY MBean SAR that you deploy on the server you can | > create proxies that exposes a pluggable behavior example you would | > deploy your SAR and create clients with <my proxy behavior that I | > wrote for my client> <security> <... no tx> <soap> | > | > and the connectors on the server side will know to route your | > message to the right mbean with the right security integration and | > no tx for example. Voila instant framework distribution. | > |Ummm. So here you're talking about deploying Mbeans as server components |which can be invoked by a remote client? I don't quite understand what |the advantage is. Why would you want to remotely invoke an Mbean rather |than just using an existing technology such as EJB to wrap it? You are correct we would need the transaction and security interceptors on the server side as well (which goes back to my call for real detached interceptors) but that is a bit early. I guess what I am saying is that the first example would be the EJB themselves (just rename the Proxy and split it up), then put the ProxyFactory that takes the stacks. It would provide a simple way for users to extend the client behavior by adding their custom information to the "Invocation" through interceptors they can easily configure. |Won't binding them into JNDI be sufficient? Are you likely to need |finders for MBeans? Are there many situations where you would have |"keyed" MBeans? I thought they were basically services - though I'm sure |Juha can come up with many other uses for them :). they are essentially singletons yes. But since the first application of this would be the "EJBs" themselves I think we don't need to worry about the registration. We only provide a ProxyFactory with externalized client interceptor stacks. That's all. It's an MBean people can use. It is pretty powerful, let them come and ask for the registration.. just the factory would be a huge step. |Sorry for all the questions, but I usually need things spelt out to get |an understanding of what's going on. aren't you supposed to be working on something else ;-) marcf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
