So, you're saying to make things totally transparent? I don't think you can do this because the consider that you want to client code to be transparent to what transport you are using IIOP, RMI, whatever and you want to use the same JNDI name. What I'm saying is that I think beans need to be able to control what JNDI names are bound to what transport.
Although this is a great idea, I don't think it is flexible enough. Bill > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of marc > fleury > Sent: Thursday, March 21, 2002 8:49 PM > To: Francisco Reverbel; Bill Burke > Cc: Jboss-Dev > Subject: RE: [JBoss-dev] ProxyFactory/JRMPInvoker needs redesign? > > > | 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
