|But we don't have an "abstract" EJB/ProxyFactory... my point is that we could... at least for the java client parts
|We have an EJB/JRMP/ProxyFactory. And an EJB/IIOP/ProxyFactory. | |The EJB/JRMP/ProxyFactory does not care about the IIOP invoker. |And the EJB/IIOP/ProxyFactory does not care about the JRMP invoker. | |See what I mean? yes in the case of C clients where you generate (whatever it is that you generate) but for Java clients, we can abstract that Invoker away . |The EJB/JRMP/ProxyFactory and the JRMP invoker are tied together. no, see proposal where the invocation is abstracted |Same thing for the EJB/IIOP/ProxyFactory and the IIOP invoker. yes marcf | |Best, | |Francisco | |PS: I think the most important thing is that proxy factory info | must be passed along with each invocation. | | |> The MBean/ProxyFactory binds the MBean interface under JMX name |in JNDI with |> RMI invoker |> |> we drop the clusteredRMI invoker |> |> the EJB/PF binds the home under "cluster/JNDIhome" with RMI/clustered |> The MBean/PF binds the MBean under cluster/JMXname (whatever the |name) with |> clustered invoker. |> |> This way we don't need to configure anything in xml, the only |difference is |> the naming. |> |> I guess we could specify a default "invoker" under which the |"bare name" is |> found. So you say "cluster" for the invoker, meaning that instead of |> straight RMI you get cluster RMI under the JNDI name of the bean. |> |> Something like that. |> |> marcf |> |> |> |3 - When a request arrives at some invoker, the invoker stuffs |> | info on its proxy factory within the invocation object if |> | passes to the MBean server. This is also crucial: proxy factory |> | info must get to the container at each invocation!!! To see why |> | this is neccessary, think of a container executing a method that |> | returns an EJBObject. |> | |> | What kind of beast should the container return? A JRMP proxy? |> | A CORBA IOR? |> | |> | Well, the container must ask this thing to some proxy factory. |> | Which proxy factory? The one associated with the current |> | invocation! In other words, proxy factory info is contextual data |> | that changes from invocation to invocation and must be passed along |> | with the invocation. The container does not know any of its proxy |> | factories. Nor does it know any of its invokers. |> | |> |Does this stuff make sense to you guys? |> | |> |Cheers, |> | |> |Francisco |> | |> |On Thu, 21 Mar 2002, Bill Burke wrote: |> | |> |> |> |> |> |> > -----Original Message----- |> |> > From: marc fleury [mailto:[EMAIL PROTECTED]] |> |> > Sent: Thursday, March 21, 2002 7:02 PM |> |> > To: Bill Burke; Jboss-Dev |> |> > Subject: RE: [JBoss-dev] ProxyFactory/JRMPInvoker needs redesign? |> |> > |> |> > |> |> > This is the last piece of the puzzle, |> |> > |> |> > |> |> |> |> Not the last piece. Still need multiple invokers to one |container....But |> |> we're getting closer. |> |> |> |> > |> |> > |-----Original Message----- |> |> > |From: [EMAIL PROTECTED] |> |> > |[mailto:[EMAIL PROTECTED]]On |> |Behalf Of Bill |> |> > |Burke |> |> > |Sent: Wednesday, March 20, 2002 2:59 PM |> |> > |To: Jboss-Dev |> |> > |Subject: [JBoss-dev] ProxyFactory/JRMPInvoker needs redesign? |> |> > | |> |> > | |> |> > |Hey, |> |> > | |> |> > |Jason made a good point. If you want to use a different |> |invoker for your |> |> > |container you currently have to provide a new container |> |configuration and |> |> > |also specify the new invoker in jboss.xml. This is too much |> |> > configuration. |> |> > |> |> > clearly |> |> > |> |> > |A better design might be as follows. |> |> > | |> |> > |1. The ProxyFactory becomes an mbean. |> |> > |> |> > ok |> |> > |> |> > |2. EJB Containers deal with ProxyFactories, not invokers, |so no more |> |> > |<home-invoker> or <bean-invoker> configurations. |> |> > |> |> > well yeah that was kind of funky. |> |> > |> |> > |So, the code for the container on deployment would look as follows: |> |> > | |> |> > |1. container looks up <home-proxy-factory> mbean in the |> |> > registry. This xml |> |> > |attribute can be overriden in jboss.xml and defaults to the |> |> > |RmiProxyFactory. |> |> > |> |> > ok. |> |> > |> |> > |2. Casts the mbean to a ProxyFactory |> |> > |3. calls: proxyFactory.bindProxies(jndiName, ...) |> |> > | |> |> > |The MBEAN configuration of the ProxyFactory would look as |> |follows. The |> |> > |ProxyFactory contains information about what invoker to use. |> |Also notice |> |> > |> |> > ok in a first phase, I would let that configuration be "free" |> |in the sense |> |> > that I would take ALL the invokers and just bind the right stuff |> |> > |> |> > marcf |> |> > |> |> > |that client interceptors are defined here as well. Really, only |> |> > the proxy |> |> > |factory cares about client interceptors. The IIOP Proxy |Factory for |> |> > |instance, will probably not deal with client interceptors |> |because it will |> |> > |probably be passing back a CORBA Object reference to the client |> |> > rather than |> |> > |a serialized Java Proxy class. |> |> > | |> |> > | <mbean code="org.jboss.invocation.jrmp.server.RmiProxyFactory" |> |> > | name="jboss:service=invoker,type=jrmp"> |> |> > | <attribute name="RMIObjectPort">4444</attribute> |> |> > | <!-- |> |> > | <attribute |> |name="invoker">jboss:service=invoker,type=jrmp</attribute> |> |> > | <attribute name="clientInterceptors"> |> |> > | <home> |> |> > | |> |> > <interceptor>org.jboss.proxy.ejb.HomeInterceptor</interceptor> |> |> > | |> |> > <interceptor>org.jboss.proxy.SecurityInterceptor</interceptor> |> |> > | |> |> > |<interceptor>org.jboss.proxy.TransactionInterceptor</interceptor> |> |> > | |> |> > |<interceptor>org.jboss.invocation.InvokerInterceptor</interceptor> |> |> > | </home> |> |> > | <bean> |> |> > | |> |> > |<interceptor>org.jboss.proxy.ejb.EntityInterceptor</interceptor> |> |> > | |> |> > <interceptor>org.jboss.proxy.SecurityInterceptor</interceptor> |> |> > | |> |> > |<interceptor>org.jboss.proxy.TransactionInterceptor</interceptor> |> |> > | |> |> > |<interceptor>org.jboss.invocation.InvokerInterceptor</interceptor> |> |> > | </bean> |> |> > | <list-entity> |> |> > | |> |> > ||<interceptor>org.jboss.proxy.ejb.ListEntityInterceptor</interceptor> |> |> > | |> |> > <interceptor>org.jboss.proxy.SecurityInterceptor</interceptor> |> |> > | |> |> > |<interceptor>org.jboss.proxy.TransactionInterceptor</interceptor> |> |> > | |> |> > |<interceptor>org.jboss.invocation.InvokerInterceptor</interceptor> |> |> > | </list-entity> |> |> > | </attribute> |> |> > | </mbean> |> |> > | |> |> > | |> |> > |The good thing about this is that everything is separated. |> |> > | |> |> > |1. JRMPInvoker knows how to invoke on MBeans from an RMI request. |> |> > |2. RmiProxyFactory knows how to create EJB proxies for RMI clients |> |> > |3. standardjboss.xml knows how to configure the EJB container |> |> > and does not |> |> > |worry about how the container is invoked upon. |> |> > |4. The EJB Container knows how to serve up MBean EJB requests. |> |> > It doesn't |> |> > |worry about proxy creation nor does it manage how requests are |> |> > routed from |> |> > |the client. |> |> > | |> |> > |Let me know what you think and I'll implement it. (Well, |eventually |> |> > |implement it :) |> |> > | |> |> > |Bill |> |> > | |> |> > | |> |> > |_______________________________________________ |> |> > |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 |> |> | | |_______________________________________________ |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
