I guess I'm too tired... Before I go sleep let me clarify what I said about EJB proxy factories. They have the purpose of producing protocol-dependent "references" to EJBObjects and EJBHomes, right? An JRMP/EJB/ProxyFactory produces serializad JRMP proxies, an IIOP/EJB/ProxyFactory produces IORs.
A proxy factory is tied to an invoker. See? I understand that this way of seeing things leads to an environment somewhat more static than the one in Marc's vision... Everything is set at bean deployment time. After a bean is deployed you cannot attach an additional factory/invoker to it. You have to undeploy it, change something in the environment to make one more factory/invoker available, and then redeploy the bean. Must sleep now. 'till tomorrow... Cheers, Francisco On Thu, 21 Mar 2002, marc fleury wrote: > | whatever.) This is crucial: proxy factories and invokers must > | know each other!!! The container, however, should not know > | any of them. > > Invokers register in the registry under a given pattern, > > proxyfactories lookup the invokers at deployment time and bind an invoker > for EACH of them. > > They also register a listener to invoker registration deregistration on the > JMX bus and bind/unbind the home at registration time. > > Scenario. > > One EJB, one MBean > one RMI invoker > > the EJB/ProxyFactory binds the HOME under JNDI name with RMI invoker > 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
