> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of
> Francisco Reverbel
> Sent: Thursday, March 21, 2002 8:37 PM
> To: Bill Burke
> Cc: marc fleury; Jboss-Dev
> Subject: RE: [JBoss-dev] ProxyFactory/JRMPInvoker needs redesign?
>
>
> Things are getting clearer for me now...
>
> What we really need is multiple proxy factories per container.
> Suppose we agree in some way to achieve this. Something like
> Bill's proposal, augmented to allow a N to 1 relationship
> between proxy factories and container. Then, if we do things
> right, everything else will follow:
>
> 1 - At bean deployment time one container and multiple proxy
> factories are created (say a JRMP one and an IIOP one).
> All factories know the JMX objectname of their container.
> The creation of each factory registers the bean home with
> the corresponding naming context:
>
> - The creation of a JRMP proxy factory registers a JRMP proxy
> for the bean home with JNDI/JRMP;
>
> - The creation of an IIOP proxy factory registers an IOR for
> the bean home with the CORBA naming service.
>
I think there will be a need for 2 separate IIOP proxy factories. One proxy
factory will create an IOR and register it with the CORBA naming service.
The other will do the same as the JRMP proxy factory except the transport
will be IIOP rather than. I think the second JRMP proxy factory will be
important so that java clients can use IIOP as the transport and take
advantage of client interceptors.
> 2 - Each proxy factory creates the invoker it needs. The proxy
> factory keeps a reference to this invoker. Moreover, the invoker
> keeps a reference to its proxy factory. (The proxy factory
> passes a reference to itself when it creates the invoker, or
> whatever.) This is crucial: proxy factories and invokers must
> know each other!!! The container, however, should not know
> any of them.
>
I think we want to avoid having the invokers know about the proxy factory if
at all possible. Well, maybe there is no other way. I was hoping that
invokers would be MBean invokers and wouldn't know that they were talking to
an EJB container or just another mbean. But I also think we want to keep
container configuration separate from knowledge from the transport layer.
Or maybe all MBean invokers have proxy factories anyways? Yeah, I guess all
MBeans could have proxy factories associated with them.
> 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?
>
Makes sense. I think I know how to implement this. Do you all mind giving
me some time to implement it? Let's say until April 1 since I'm going to be
at JBoss One?
Right now, for configuration, I'm going to assume in jboss.xml that you have
to specify both the invoker mbean name, proxy factory mbean name, and if
applicable, the jndi name for the HOME. The default will be the
JRMPInvoker, RMIPRoxyFactory, and the <ejb-name>. In the future we can
decide if we want funkier defaults like Marc suggested in his other email.
I think it is important to be able to specify the proxy factory and invoker
to give ultimate flexibility. Then again, maybe each invoker is only
associated with a Proxy Factory Factory in MBean configuration. You only
specify the invoker in jboss.xml, then the container asks the
ProxyFactoryFactory for an instance of a ProxyFactory.
So instead of just one JRMPInvoker for both MBeans and EJB containers, you'd
have 2 different invokers. One for MBeans the other for EJB containers.
(It would really be the same object type, just configured differently.).
Am I making sense, or am I just babbling?
Bill
> 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
