RE: [JBoss-dev] http transport
On Wed, 26 Jun 2002, Bill Burke wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury Sent: Wednesday, June 26, 2002 12:55 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] http transport |Seems like I don't need an HTTPInvoker. Only an HTTPInvokerProxy and a |InvokerServlet, that forwards invocations to the local invoker. If I use the JMX bus directly, |understand it, the proxy must provide a TransactionPropagationContext |instance to each Invocation. This has to be imported in the servlet |before the invocation is forwarded to the LocalInvoker. The transaction is not mandatory, but if it is there then yes it has to be imported (this is a weakness, necessary I am told (?) of the current transaction engine design). This weakness needs to be corrected. |Also, there must be a HTTPProxyFactory, that binds an HTTPInvokerProxy |into jndi for every ejb. An then, there's the setup / integration. I need |some MBean, that sets up the proxy factory and deploys the servlet. I am thinking, bill, we should do a factory bind in JNDI that knows what I think we may have to use JNDI properties to implement this i.e. jndi.properties: java.naming.factory.initial=org.jnp.interfaces.HTTPNamingContextFactory java.naming.provider.url=http://yomama.com/JrmpInvoker Also, this may be the best solution anyways. I really want to avoid any proprietary configuration on the client side. Coding the protocol into the jndi-name is a good idea, but I'm still not confident with this approach. I see it this way: o the server hosts components and makes them accessible through rmi, iiop, http, .. (different invokers) o serverside interceptors and container are configured per component on the server. Invokers are configured as part of the server configuration. o that's the server's part. nothing more! o the client / caller does a lookup in its local jndi namespace with a coded name. The coded name is declared somewhere as an ejb-ref, res-ref, *-ref o the declaration of this *-ref is parameterized in a jboss specific descriptor (jboss.xml): + protocoll (InvokerProxy) + identifier of the target component (jndi-name) + both, the protocol and the address of the component can be coded into a single jndi-name, by using a special url context factory for every protocol or by using a subcontext + client side interceptors (there are interceptors, that can _never_ be configured on the server / per component / per invoker (think of a recording interceptor) I also agree that this whole proxy mess needs to be non-EJB specific and generic to MBeans. The first step though is creating an HTTPInvokerProxy and HTTPInvoker. The HTTPInvoker is a servlet or httpd. There's no lookup of this invoker, only invocations, that are sent to the servlet. how many remote calls are involved in a simple acces to a bean method: 1. lookup 2. create 3. bean why not skip the first one? just give the client a proxy, wether the target component is accessible or not. the invocation of create can fail anyway. there's no way, how we could assure, that a create works, if the lookup has worked. thus imo there's no problem, if we skip the lookup. That's like communication happens in real life. If I send you a message, you won't give me the pencil, I have to use. I don't lookup your address at your door. I look it up in my private addressbook. If I send the message, I don't know, if the address is correct. However, I'll notice if it was incorrect. Holger --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] http transport
Just a small point: do we agree that independing on the protocol used to communicate with JNDI, the proxy needs to be obtained in a specific way (like now, through standard TCP) to bootstrap. -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]De la part de Bill Burke Envoye : jeudi, 27 juin 2002 10:11 A : [EMAIL PROTECTED] Objet : RE: [JBoss-dev] http transport Holger, your ideas are very interesting and thought provoking. Although I disagree with a lot of them (read further), I believe that this is a good conversion and something very cool will come out of it. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Holger Engels Sent: Thursday, June 27, 2002 2:36 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] http transport On Wed, 26 Jun 2002, Bill Burke wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury Sent: Wednesday, June 26, 2002 12:55 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] http transport |Seems like I don't need an HTTPInvoker. Only an HTTPInvokerProxy and a |InvokerServlet, that forwards invocations to the local invoker. If I use the JMX bus directly, |understand it, the proxy must provide a TransactionPropagationContext |instance to each Invocation. This has to be imported in the servlet |before the invocation is forwarded to the LocalInvoker. The transaction is not mandatory, but if it is there then yes it has to be imported (this is a weakness, necessary I am told (?) of the current transaction engine design). This weakness needs to be corrected. |Also, there must be a HTTPProxyFactory, that binds an HTTPInvokerProxy |into jndi for every ejb. An then, there's the setup / integration. I need |some MBean, that sets up the proxy factory and deploys the servlet. I am thinking, bill, we should do a factory bind in JNDI that knows what I think we may have to use JNDI properties to implement this i.e. jndi.properties: java.naming.factory.initial=org.jnp.interfaces.HTTPNamingContextFactory java.naming.provider.url=http://yomama.com/JrmpInvoker Also, this may be the best solution anyways. I really want to avoid any proprietary configuration on the client side. Coding the protocol into the jndi-name is a good idea, but I'm still not confident with this approach. I see it this way: That's not what I meant. IMHO, coding the protocol into the jndi-name is a hack. i.e. ctx.lookup(http/foo) I think how you communicate to jndi should be described in the jndi.properties file. But how you get references to other objects should be different. I would rather have one of these possible solutions: 1. Depending the transport type, a different value for foo is returned. If you do a ctx.lookup(foo) and you're talking HTTP, you get a foo HTTP proxy back to communicate. 2. Let the application developer decide how things are mapped in JNDI. For instance, we can recommend that they bind a invoker-proxy binding into jndi as http/foo , iiop as iiop/foo. Am I making sense? o the server hosts components and makes them accessible through rmi, iiop, http, .. (different invokers) o serverside interceptors and container are configured per component on the server. Invokers are configured as part of the server configuration. Right now, client and container and invoker configurations are all separate. This allows us to have multiple transports per EJB(later per MBean too). o that's the server's part. nothing more! Not true at all. The server has to have knowledge of the client-side interceptors. Where you idea breaks down is when an method returns a different EJB or a collection of EJBs of different types. How will your ideas work then? How will the correct client-side interceptor chain and transport and endpoint be attached to the EJB refs contained in these arbitrary collection objects? When I was implementing the multi-invoker stuff, I played with the idea of having generic EJB refs, but the idea fell apart in this scenario. Also, many server-side interceptors require a mirror client-side interceptor to work. Security, Transactions and especially Clustering fall into this category. o the client / caller does a lookup in its local jndi namespace with a coded name. The coded name is declared somewhere as an ejb-ref, res-ref, *-ref o the declaration of this *-ref is parameterized in a jboss specific descriptor (jboss.xml): + protocoll (InvokerProxy) + identifier of the target component (jndi-name) + both, the protocol and the address of the component can be coded into a single jndi-name, by using a special url context factory for every protocol or by using a subcontext
RE: [JBoss-dev] http transport
On Thu, 27 Jun 2002, Bill Burke wrote: Holger, your ideas are very interesting and thought provoking. Although I disagree with a lot of them (read further), I believe that this is a good conversion and something very cool will come out of it. Actually I've already learned from this discussion ;-) That's not what I meant. IMHO, coding the protocol into the jndi-name is a hack. i.e. ctx.lookup(http/foo) I think how you communicate to jndi should be described in the jndi.properties file. But how you get references to other objects should be different. I would rather have one of these possible solutions: 1. Depending the transport type, a different value for foo is returned. If you do a ctx.lookup(foo) and you're talking HTTP, you get a foo HTTP proxy back to communicate. 2. Let the application developer decide how things are mapped in JNDI. For instance, we can recommend that they bind a invoker-proxy binding into jndi as http/foo , iiop as iiop/foo. Am I making sense? You mean no url provider, but jndi.properties (=environment)? OK. But I can't live with global jndi.properties. I need them on a per *-ref basis, because the components I connect are spreaded across several different application servers. o the server hosts components and makes them accessible through rmi, iiop, http, .. (different invokers) o serverside interceptors and container are configured per component on the server. Invokers are configured as part of the server configuration. Right now, client and container and invoker configurations are all separate. This allows us to have multiple transports per EJB(later per MBean too). o that's the server's part. nothing more! Not true at all. The server has to have knowledge of the client-side interceptors. Where you idea breaks down is when an method returns a different EJB or a collection of EJBs of different types. How will your ideas work then? How will the correct client-side interceptor chain and transport and endpoint be attached to the EJB refs contained in these arbitrary collection objects? When I was implementing the multi-invoker stuff, I played with the idea of having generic EJB refs, but the idea fell apart in this scenario. Good point! Never thought of that. However, the result of an invocation are handles or something similar, right?. Can we put the configuration, that is comming from the server into these handles? Thus a proxy is partially configured from the client (client chooses the transport and might in very few cases add its own interceptors) and mostly from the information, that comes with the handle? Also, many server-side interceptors require a mirror client-side interceptor to work. Security, Transactions and especially Clustering fall into this category. This just goes against location transparency and I can't see why anybody would want to hard-code the address of each component in their system, or to manage and know what protocols and what bindings and what client-side interceptors are required. Client side configuration just does not scale. Too many config files in separate places to manage. People want centralized config, especially ISVs. I want to keep these addresses out of my code, thus only use *-refs (call it nicknames). But these nicknames have to be mapped to something, that fully identifies the target. For the server doesn't know the client, but the client knows, what components are there on the server, this mapping has to be done on the client? I cant send an email to a nickname. I have to lookup the email address. OK, you convinced me, that most of the interceptor chain has to be configured from the server. My point is now, that I don't want the lookup in the server's jndi-namespace, before invoking the create method. 1. an invoker proxy is choosen on the client 2. the client knows the address of the invoker (always the same) 3. the client knows what component it wants to connect to (jndi-name) 4. this is all, we need to know, in order to send the create invocation 5. the jndi-name is passed with the invocation of create. the result is a handle carrying all information, that is required to setup the client side interceptor chain. What am I missing? Holger --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] http transport
Yes. But if we need to bootsrap the jndi communication, we can skip this jndi lookup and just send the create invocation to the invoker. How the invokers can be accessed must either be wellknown or somehow configured on the client. yes, the problem is that I am not sure (in fact I am pretty sure that it is not possible with RMI/JRMP) that it is possible to have well-known ports for a very simply reason: SocketFactory can be set for the RMI invoker on the server side for example. If I remember well, this well-known thing is possible with CORBA. Please, please tell me, for what do we need server side jndi content on the client? ?!? MyHome home = ctx.lookup (MyHome.JNDI_NAME); ?!? Do I understand your question? --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] http transport
Snip ... You mean no url provider, but jndi.properties (=environment)? OK. But I can't live with global jndi.properties. I need them on a per *-ref basis, because the components I connect are spreaded across several different application servers. It would seem that you would still want a global JNDI directory with 1 point of entry. This could be a JNDI mbean that does nothing else than sit infront of all of your other application servers and keeps references to all the other beans in the other applcation severs JNDI directories. When a request came in it could lookup the actual reference, wrap in up in a proxy and hand it back. The proxy would then know which application server it would talk to. I think hard coding aliases into *-refs is a bad idea. It would be a maintence nightmare. A global lookup location would be way easier. So your jndi.properties would only have to get you to the global JNDI directory at boot time. These properties could change based on each client logging in and loading a profile. Crawling back under my rock ... --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] http transport
On Thu, 27 Jun 2002, Sacha Labourey wrote: Yes. But if we need to bootsrap the jndi communication, we can skip this jndi lookup and just send the create invocation to the invoker. How the invokers can be accessed must either be wellknown or somehow configured on the client. yes, the problem is that I am not sure (in fact I am pretty sure that it is not possible with RMI/JRMP) that it is possible to have well-known ports for a very simply reason: SocketFactory can be set for the RMI invoker on the server side for example. If I remember well, this well-known thing is possible with CORBA. Please, please tell me, for what do we need server side jndi content on the client? ?!? MyHome home = ctx.lookup (MyHome.JNDI_NAME); ?!? Do I understand your question? That is local jndi. I am looking up the coded name in my local jndi-namespace. The coded name is defined as an ejb-ref in my application-client.xml. what I get is something, that feels like a proxy to the ejb's home. the ejb-ref must be configured with: o an url, that points to the invoker (protocol, server, context) o the jndi-name of the bean o optional client interceptors if I invoke create(..) on this proxy, the invocation is stuffed with the jndi-name and forwarded to the invoker (url). the invoker returns a handle, that contains all configuration, that is required to setup the invoker proxy and the client interceptors. So now tell me, for what do I need the server side jndi content on the client? Maybe, I'm missing something .. connecting to a cluster might need some more configuration (there are more than one servers/invokers). but it's not harder to connect to a clustered invoker than to bootstrap clustered jndi access. restriction: all home methods (create, finders, entity) won't have the interceptor configuration from the server. Holger --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] http transport
On Thu, 27 Jun 2002, Holger Engels wrote: That is local jndi. I am looking up the coded name in my local jndi-namespace. The coded name is defined as an ejb-ref in my application-client.xml. what I get is something, that feels like a proxy to the ejb's home. the ejb-ref must be configured with: o an url, that points to the invoker (protocol, server, context) o the jndi-name of the bean o optional client interceptors if I invoke create(..) on this proxy, the invocation is stuffed with the jndi-name and forwarded to the invoker (url). the invoker returns a handle, that contains all configuration, that is required to setup the invoker proxy and the client interceptors. So now tell me, for what do I need the server side jndi content on the client? Maybe, I'm missing something .. connecting to a cluster might need some more configuration (there are more than one servers/invokers). but it's not harder to connect to a clustered invoker than to bootstrap clustered jndi access. restriction: all home methods (create, finders, entity) won't have the interceptor configuration from the server. Ok, I can see it now. Fetching the complete invoker proxy from the server is the better idea. It works also with other component types (without home interfaces). Still want the mapping from coded names to jndi-names in my application-client.xml and still want to have the possibility to specify additional interceptors for *-refs. Holger --- This sf.net email is sponsored by:ThinkGeek Caffeinated soap. No kidding. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] http transport
On Mon, 24 Jun 2002, Bill Burke wrote: ProxyFactory is not an MBean. Just an object right now. Config code, creates and attaches ProxyFactorys to each EJB. (Each EJB is an mbean though). Still trying to understand .. Seems like I don't need an HTTPInvoker. Only an HTTPInvokerProxy and a InvokerServlet, that forwards invocations to the local invoker. If I understand it, the proxy must provide a TransactionPropagationContext instance to each Invocation. This has to be imported in the servlet before the invocation is forwarded to the LocalInvoker. Also, there must be a HTTPProxyFactory, that binds an HTTPInvokerProxy into jndi for every ejb. An then, there's the setup / integration. I need some MBean, that sets up the proxy factory and deploys the servlet. All that together should be packaged into one single deployment unit, e.g. a sar. Right? Holger --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] http transport
Hello, Seems like I don't need an HTTPInvoker. Only an HTTPInvokerProxy and a InvokerServlet, that forwards invocations to the local invoker. If I your Invoker should directly forward invocations to the JMX MBeanServer and not forward it to another local invoker --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] http transport
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Holger Engels Sent: Wednesday, June 26, 2002 6:19 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] http transport On Mon, 24 Jun 2002, Bill Burke wrote: ProxyFactory is not an MBean. Just an object right now. Config code, creates and attaches ProxyFactorys to each EJB. (Each EJB is an mbean though). Still trying to understand .. Seems like I don't need an HTTPInvoker. Only an HTTPInvokerProxy and a InvokerServlet, that forwards invocations to the local invoker. If I understand it, the proxy must provide a TransactionPropagationContext instance to each Invocation. This has to be imported in the servlet before the invocation is forwarded to the LocalInvoker. No invocation forward. Invoke directly on the EJB Container through the JMX Bus. Take a look at the JRMPInvoker as an example.(Or the local invoker). Also, there must be a HTTPProxyFactory, that binds an HTTPInvokerProxy into jndi for every ejb. An then, there's the setup / integration. I need some MBean, that sets up the proxy factory and deploys the servlet. Yes exactly. I may have time to break out JNDI into an MBean. So I could work on that. All that together should be packaged into one single deployment unit, e.g. a sar. Right? Yes, a sar is perfect for this since there's really no config for this invoker, right? Holger --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] http transport
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Holger Engels Sent: Wednesday, June 26, 2002 6:19 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] http transport On Mon, 24 Jun 2002, Bill Burke wrote: ProxyFactory is not an MBean. Just an object right now. Config code, creates and attaches ProxyFactorys to each EJB. (Each EJB is an mbean though). Still trying to understand .. Seems like I don't need an HTTPInvoker. Only an HTTPInvokerProxy and a InvokerServlet, that forwards invocations to the local invoker. If I understand it, the proxy must provide a TransactionPropagationContext instance to each Invocation. This has to be imported in the servlet before the invocation is forwarded to the LocalInvoker. No invocation forward. Invoke directly on the EJB Container through the JMX Bus. Take a look at the JRMPInvoker as an example.(Or the local invoker). Also, there must be a HTTPProxyFactory, that binds an HTTPInvokerProxy into jndi for every ejb. An then, there's the setup / integration. I need some MBean, that sets up the proxy factory and deploys the servlet. Yes exactly. I may have time to break out JNDI into an MBean. So I could work on that. All that together should be packaged into one single deployment unit, e.g. a sar. Right? Yes, a sar is perfect for this since there's really no config for this invoker, right? Holger --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] http transport
Yes, a sar is perfect for this since there's really no config for this invoker, right? you now what we need? It is an XML file for config with the JAR *inside the xml in a CDATA section (as MIME encoded for example)!! ;) We don't care about the extra-size anyway. So, instead of having an XML insider a JAR we have a JAR inside XML. You want to update the code? OK, remove the CDATA section, add the JAR to extend the classpath and simply deploy the XML file without the CDATA. But then, it is the standard case. --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] http transport
|Seems like I don't need an HTTPInvoker. Only an HTTPInvokerProxy and a |InvokerServlet, that forwards invocations to the local invoker. If I use the JMX bus directly, |understand it, the proxy must provide a TransactionPropagationContext |instance to each Invocation. This has to be imported in the servlet |before the invocation is forwarded to the LocalInvoker. The transaction is not mandatory, but if it is there then yes it has to be imported (this is a weakness, necessary I am told (?) of the current transaction engine design). |Also, there must be a HTTPProxyFactory, that binds an HTTPInvokerProxy |into jndi for every ejb. An then, there's the setup / integration. I need |some MBean, that sets up the proxy factory and deploys the servlet. I am thinking, bill, we should do a factory bind in JNDI that knows what protocol to add in the invoker but the proxy stuff should be generalized, the interface input generalized. This way you would just context.lookup(http/myMBean) or some way to specify what transport you want and we return to you the right invoker in the java stack with the interface _of the MBean_ not just EJB. This way you are talking to you remote server MBean through the HTTP protocol, and tunnelling through anything this way . Java interfaces to web services. simply done, |All that together should be packaged into one single deployment unit, e.g. |a sar. Right? yes marcf |Holger pull this off holger, pull it off, marcf | | | |--- |This sf.net email is sponsored by: Jabber Inc. |Don't miss the IM event of the season | Special offer for OSDN members! |JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] http transport
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury Sent: Wednesday, June 26, 2002 12:55 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] http transport |Seems like I don't need an HTTPInvoker. Only an HTTPInvokerProxy and a |InvokerServlet, that forwards invocations to the local invoker. If I use the JMX bus directly, |understand it, the proxy must provide a TransactionPropagationContext |instance to each Invocation. This has to be imported in the servlet |before the invocation is forwarded to the LocalInvoker. The transaction is not mandatory, but if it is there then yes it has to be imported (this is a weakness, necessary I am told (?) of the current transaction engine design). This weakness needs to be corrected. |Also, there must be a HTTPProxyFactory, that binds an HTTPInvokerProxy |into jndi for every ejb. An then, there's the setup / integration. I need |some MBean, that sets up the proxy factory and deploys the servlet. I am thinking, bill, we should do a factory bind in JNDI that knows what I think we may have to use JNDI properties to implement this i.e. jndi.properties: java.naming.factory.initial=org.jnp.interfaces.HTTPNamingContextFactory java.naming.provider.url=http://yomama.com/JrmpInvoker Also, this may be the best solution anyways. I really want to avoid any proprietary configuration on the client side. protocol to add in the invoker but the proxy stuff should be generalized, the interface input generalized. This way you would just context.lookup(http/myMBean) or some way to specify what transport you want and we return to you the right invoker in the java stack with the interface _of the MBean_ not just EJB. This way you are talking to you remote server MBean through the HTTP protocol, and tunnelling through anything this way . Java interfaces to web services. simply done, I also agree that this whole proxy mess needs to be non-EJB specific and generic to MBeans. The first step though is creating an HTTPInvokerProxy and HTTPInvoker. Maybe based on the invocation type, you could reference a binding specific to that transport meaning, if you do context.lookup(myMBean) on a HTTP protocol, you get the HTTP MBean proxy. I've already done this sort of this with EJBs. |All that together should be packaged into one single deployment unit, e.g. |a sar. Right? yes marcf |Holger pull this off holger, pull it off, marcf | | | |--- |This sf.net email is sponsored by: Jabber Inc. |Don't miss the IM event of the season | Special offer for OSDN members! |JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] http transport
On 2002.06.26 14:11:38 -0400 Bill Burke wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury Sent: Wednesday, June 26, 2002 12:55 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] http transport |Seems like I don't need an HTTPInvoker. Only an HTTPInvokerProxy and a |InvokerServlet, that forwards invocations to the local invoker. If I use the JMX bus directly, |understand it, the proxy must provide a TransactionPropagationContext |instance to each Invocation. This has to be imported in the servlet |before the invocation is forwarded to the LocalInvoker. The transaction is not mandatory, but if it is there then yes it has to be imported (this is a weakness, necessary I am told (?) of the current transaction engine design). This weakness needs to be corrected. JCA 1.5 has a transaction inflow model and a work inflow model. I have initial prototype implementations of these. The work inflow model is designed to allow the app server to manage thread pooling for work requested by external systems. I was wondering if we should use this for all incoming requests. David Jencks |Also, there must be a HTTPProxyFactory, that binds an HTTPInvokerProxy |into jndi for every ejb. An then, there's the setup / integration. I need |some MBean, that sets up the proxy factory and deploys the servlet. I am thinking, bill, we should do a factory bind in JNDI that knows what I think we may have to use JNDI properties to implement this i.e. jndi.properties: java.naming.factory.initial=org.jnp.interfaces.HTTPNamingContextFactory java.naming.provider.url=http://yomama.com/JrmpInvoker Also, this may be the best solution anyways. I really want to avoid any proprietary configuration on the client side. protocol to add in the invoker but the proxy stuff should be generalized, the interface input generalized. This way you would just context.lookup(http/myMBean) or some way to specify what transport you want and we return to you the right invoker in the java stack with the interface _of the MBean_ not just EJB. This way you are talking to you remote server MBean through the HTTP protocol, and tunnelling through anything this way . Java interfaces to web services. simply done, I also agree that this whole proxy mess needs to be non-EJB specific and generic to MBeans. The first step though is creating an HTTPInvokerProxy and HTTPInvoker. Maybe based on the invocation type, you could reference a binding specific to that transport meaning, if you do context.lookup(myMBean) on a HTTP protocol, you get the HTTP MBean proxy. I've already done this sort of this with EJBs. |All that together should be packaged into one single deployment unit, e.g. |a sar. Right? yes marcf |Holger pull this off holger, pull it off, marcf | | | |--- |This sf.net email is sponsored by: Jabber Inc. |Don't miss the IM event of the season | Special offer for OSDN members! |JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] http transport
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Holger Engels Sent: Monday, June 24, 2002 2:37 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] http transport On Fri, 21 Jun 2002, Bill Burke wrote: Holger, in JBoss 3.0 we have client interceptors, and pluggable transports. The invocation has been totally decoupled from the EJB container. The EJB Container is now just an MBean and all EJB invocations go across the JMX bus. Great! JBoss 3.1 takes things a bit further. In 3.1 you can now define multiple invokers (transports) per EJB container. So an EJB container can be configured to receive requests from RMI, IIOP, SOAP, HTTP, whatever all at the same time. We'll want to hook your HTTP invoker into this architecture. Ok, I'm already trying to do that. The files and java packages you'll want to look at are as follows, There's also a detail email I sent out 2 months ago that is copied later on in this email: In server module: Packages org.jboss.invocation, org.jboss.proxy org.jboss.invocation.jrmp.server.JRMPInvoker.java is the main entry point on the server side. It accepts invocation requests and routes them across the JMX bus. I think your HTTP POST protocol can be very simple. Just marshall an Invocation and send it across the wire. The JRMPInvoker is stateless and can route any Invocation. So far, that's straight forward. I' am writing a HTTPInvoker, that deploys a servlet (same hack as jboss.net axis servlet) and forwards invocations to the HTTPInvoker. The invoker feeds them into jmx. For the client side, you'll need to implement a new org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy. This is really the Transport on the client side. You'll also need to implement a org.jboss.proxy.ejb.ProxyFactory. The JBoss clustering can be used as an example since it has extended JRMPInvokerProxy, ProxyFactory and has its own Invoker. see the cluster module. All classes under the above packages. If I understand it correctly, the ProxyFactory is an MBean, running on the server, facturing InvokerProxy instances that are moved to and used on the client (caller side)!? ProxyFactory is not an MBean. Just an object right now. Config code, creates and attaches ProxyFactorys to each EJB. (Each EJB is an mbean though). What sucks is that even if you've implemented this stuff, its not very helpful because JNDI does not have pluggable transports. Maybe I am still missing something, but what if the server configuration You currently can only invoke on JNDI remotely through RMI. JNDI is not currently an MBean, so you can't invoke on it through a different transport. would simply end with the invoker layer. container is server side. invoker is the entry point for the container, thus also server side. remaining config is _client_side_. In 3.1, that's what I'm trying to do. Separate server configuration from client configuration. This is very important when you have multiple invoker types. (SOAP, IIOP, RMI). The client (another bean, application-client, web-application) is always referring an (ejb|ejb-local|..)-ref (coded name) in its private jndi namespace. It is never accessing the server's jndi namespace directly! The ejb-ref is the place for configuration bits that: I agree that ejb-refs are a good place to define some things. If you notice from the multi-invoker testsute test, you'll see from the configuration that based on the Invoker type, you can bind different absolute JNDI bindings for each ejb-ref you have. So, for example, if you invoke on an IIOP invoker, the container will pass this information on to other container it interfaces with. So if you invoke with IIOP and that EJB calls a finder on one of its EJB refs, the proxies returned will be IIOP proxies. Am I making sense? So yes, ejb-refs are a good place to stuff certain kinds of information. o identify the target component o determine the transport protocol o locate the invoker Disagree, discovery is JNDI's responsibility. o setup the client interceptors (terms server and client often used in the sense of callee/caller) This would have some big advantages: o decoupling of client and server This has been done for EJBs at least in 3.1 (invoker-proxy bindings) and needs to be extended to MBeans. o no jndi plugins for different protocols required o jndi is mostly (if not completely) local Not sure if I agree with your JNDI ideas. The whole point of JNDI is to provide a central point to locate objects and services. Maybe I'm misunderstanding your ideas, but with your approach, for each client you would have to hard-code locations of things within ejb-refs. Not very flexible or maintable. o server is responsible for containment and accessibility o client can connect wherever it wants (also to different appservers in different locations with different
RE: [JBoss-dev] http transport
JDK already has built in RMI HTTP tunneling. Why would we need this transport? Here's directions: http://www.dmh2000.com/ApacheTomcatRMI.htm Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Holger Engels Sent: Friday, June 21, 2002 5:00 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] http transport I try to understand, how a http transport can be implemented within jboss .. so what do I need? on the server side: o a connector servlet / extra http deamon, that accepts invocations embedded in http posts. the result of a home invocation is a handle. subsequent invocations (remote interface) contain the handle to identify the target ejb. the servlet is completely stateless. o an mbean service, that manages the servlet / http deamon on the client: o some interceptor (the last one in the chain), that marshalls the invocation as an http post request and demarshalls results / throwables. I call it the 'Transport' o is a special handle implementation required? o usertransaction handling is transparent (part of Invocation)? configuration: o it's the server's job to provide the connector servlet. the servlet doesn't need to be configured. the invocations carry all the information that is required to perform home-/ remote-invocations. o the client will do a lookup first (coded name, declared in the application-client descriptor). it then gets a dynamic proxy passing on the java style invocation to the invocation handler. the invocation handler feeds the invocation into the interceptor chain. this chain has to be configured somehow (during deployment of the application-client jar). o afaik there's no application client deployment at the moment and the client side interceptors are configured from the server, right? so what makes up the whole interceptor chain? we distinguish: o client side interceptors o server side interceptors (synchronization, pooling / caching, security) o symmetric interceptors (encryption / decryption for instance) the overall configuration of the (ordered) interceptor chain is made of component aspects and reference aspects. transport is just another aspect of the reference. authentication: in the smartcc, using the http transport requires a http login module (basic/digest auth) to be configured. the authentication task is performed by the servlet container. the container cares about setting up the security association. dain asked for an http plugin for jndi. my question: why do I need the server side's jndi content on the client if I don't lookup homes? what does a java client need beside what's configured in the application client descriptor. what am i missing? holger --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] http transport
The HTTP RMI tunning is the shits. Firstly there is no option to go with https without getting really ugly. Secondly, the whole cgi-script or servlet which then calls the local rmi listener generates two network calls for lookup. Since jetty is running in the container the servlet lookup should be a local JNDI lookup. If you read Holger's web site (http://smartcc.sourceforge.net) he is trying to cleanup EJB transport issues when firwalls are in the way. I hope somebody with more knowledge than me steps up to the plate. I for 1 will be using this stuff.. On Fri, 2002-06-21 at 08:36, Bill Burke wrote: JDK already has built in RMI HTTP tunneling. Why would we need this transport? Here's directions: http://www.dmh2000.com/ApacheTomcatRMI.htm Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Holger Engels Sent: Friday, June 21, 2002 5:00 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] http transport I try to understand, how a http transport can be implemented within jboss .. so what do I need? on the server side: o a connector servlet / extra http deamon, that accepts invocations embedded in http posts. the result of a home invocation is a handle. subsequent invocations (remote interface) contain the handle to identify the target ejb. the servlet is completely stateless. o an mbean service, that manages the servlet / http deamon on the client: o some interceptor (the last one in the chain), that marshalls the invocation as an http post request and demarshalls results / throwables. I call it the 'Transport' o is a special handle implementation required? o usertransaction handling is transparent (part of Invocation)? configuration: o it's the server's job to provide the connector servlet. the servlet doesn't need to be configured. the invocations carry all the information that is required to perform home-/ remote-invocations. o the client will do a lookup first (coded name, declared in the application-client descriptor). it then gets a dynamic proxy passing on the java style invocation to the invocation handler. the invocation handler feeds the invocation into the interceptor chain. this chain has to be configured somehow (during deployment of the application-client jar). o afaik there's no application client deployment at the moment and the client side interceptors are configured from the server, right? so what makes up the whole interceptor chain? we distinguish: o client side interceptors o server side interceptors (synchronization, pooling / caching, security) o symmetric interceptors (encryption / decryption for instance) the overall configuration of the (ordered) interceptor chain is made of component aspects and reference aspects. transport is just another aspect of the reference. authentication: in the smartcc, using the http transport requires a http login module (basic/digest auth) to be configured. the authentication task is performed by the servlet container. the container cares about setting up the security association. dain asked for an http plugin for jndi. my question: why do I need the server side's jndi content on the client if I don't lookup homes? what does a java client need beside what's configured in the application client descriptor. what am i missing? holger --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] http transport
Good enough for me. Thanks for the info. Holger, we should talk. I can give you pointers on how to integrate the HTTP Invoker into the 3.1 architecture. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Dave Smith Sent: Friday, June 21, 2002 10:21 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] http transport The HTTP RMI tunning is the shits. Firstly there is no option to go with https without getting really ugly. Secondly, the whole cgi-script or servlet which then calls the local rmi listener generates two network calls for lookup. Since jetty is running in the container the servlet lookup should be a local JNDI lookup. If you read Holger's web site (http://smartcc.sourceforge.net) he is trying to cleanup EJB transport issues when firwalls are in the way. I hope somebody with more knowledge than me steps up to the plate. I for 1 will be using this stuff.. On Fri, 2002-06-21 at 08:36, Bill Burke wrote: JDK already has built in RMI HTTP tunneling. Why would we need this transport? Here's directions: http://www.dmh2000.com/ApacheTomcatRMI.htm Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Holger Engels Sent: Friday, June 21, 2002 5:00 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] http transport I try to understand, how a http transport can be implemented within jboss .. so what do I need? on the server side: o a connector servlet / extra http deamon, that accepts invocations embedded in http posts. the result of a home invocation is a handle. subsequent invocations (remote interface) contain the handle to identify the target ejb. the servlet is completely stateless. o an mbean service, that manages the servlet / http deamon on the client: o some interceptor (the last one in the chain), that marshalls the invocation as an http post request and demarshalls results / throwables. I call it the 'Transport' o is a special handle implementation required? o usertransaction handling is transparent (part of Invocation)? configuration: o it's the server's job to provide the connector servlet. the servlet doesn't need to be configured. the invocations carry all the information that is required to perform home-/ remote-invocations. o the client will do a lookup first (coded name, declared in the application-client descriptor). it then gets a dynamic proxy passing on the java style invocation to the invocation handler. the invocation handler feeds the invocation into the interceptor chain. this chain has to be configured somehow (during deployment of the application-client jar). o afaik there's no application client deployment at the moment and the client side interceptors are configured from the server, right? so what makes up the whole interceptor chain? we distinguish: o client side interceptors o server side interceptors (synchronization, pooling / caching, security) o symmetric interceptors (encryption / decryption for instance) the overall configuration of the (ordered) interceptor chain is made of component aspects and reference aspects. transport is just another aspect of the reference. authentication: in the smartcc, using the http transport requires a http login module (basic/digest auth) to be configured. the authentication task is performed by the servlet container. the container cares about setting up the security association. dain asked for an http plugin for jndi. my question: why do I need the server side's jndi content on the client if I don't lookup homes? what does a java client need beside what's configured in the application client descriptor. what am i missing? holger --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss
RE: [JBoss-dev] http transport
On Fri, 21 Jun 2002, Bill Burke wrote: Good enough for me. Thanks for the info. Holger, we should talk. I can give you pointers on how to integrate the HTTP Invoker into the 3.1 architecture. Ok, I need to know, where I can start. If you could answer the questions of my first mail, this would be great. I had a look at the iiop module. I think, the http invoker is less complex. I don't need a proxy compiler, no ior, no naming service, .. how do you call, what I call transport, the last interceptor on the client side, that does the marshalling. that is the point, where the invocation has to be embedded in a http post request? What are the classnames of the IIOP / RMI / SOAP pendants? They serve as a reference for the http implementation. How can I configure jboss to use my implementation of this class? invoker-proxy-binding? unfortunately, I won't be in the office till monday and thus won't read / answer mail until then .. holger -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Dave Smith Sent: Friday, June 21, 2002 10:21 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] http transport The HTTP RMI tunning is the shits. Firstly there is no option to go with https without getting really ugly. Secondly, the whole cgi-script or servlet which then calls the local rmi listener generates two network calls for lookup. Since jetty is running in the container the servlet lookup should be a local JNDI lookup. If you read Holger's web site (http://smartcc.sourceforge.net) he is trying to cleanup EJB transport issues when firwalls are in the way. I hope somebody with more knowledge than me steps up to the plate. I for 1 will be using this stuff.. On Fri, 2002-06-21 at 08:36, Bill Burke wrote: JDK already has built in RMI HTTP tunneling. Why would we need this transport? Here's directions: http://www.dmh2000.com/ApacheTomcatRMI.htm Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Holger Engels Sent: Friday, June 21, 2002 5:00 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] http transport I try to understand, how a http transport can be implemented within jboss .. so what do I need? on the server side: o a connector servlet / extra http deamon, that accepts invocations embedded in http posts. the result of a home invocation is a handle. subsequent invocations (remote interface) contain the handle to identify the target ejb. the servlet is completely stateless. o an mbean service, that manages the servlet / http deamon on the client: o some interceptor (the last one in the chain), that marshalls the invocation as an http post request and demarshalls results / throwables. I call it the 'Transport' o is a special handle implementation required? o usertransaction handling is transparent (part of Invocation)? configuration: o it's the server's job to provide the connector servlet. the servlet doesn't need to be configured. the invocations carry all the information that is required to perform home-/ remote-invocations. o the client will do a lookup first (coded name, declared in the application-client descriptor). it then gets a dynamic proxy passing on the java style invocation to the invocation handler. the invocation handler feeds the invocation into the interceptor chain. this chain has to be configured somehow (during deployment of the application-client jar). o afaik there's no application client deployment at the moment and the client side interceptors are configured from the server, right? so what makes up the whole interceptor chain? we distinguish: o client side interceptors o server side interceptors (synchronization, pooling / caching, security) o symmetric interceptors (encryption / decryption for instance) the overall configuration of the (ordered) interceptor chain is made of component aspects and reference aspects. transport is just another aspect of the reference. authentication: in the smartcc, using the http transport requires a http login module (basic/digest auth) to be configured. the authentication task is performed by the servlet container. the container cares about setting up the security association. dain asked for an http plugin for jndi. my question: why do I need the server side's jndi content on the client if I don't lookup homes? what does a java client need beside what's configured in the application client descriptor. what am i missing? holger --- Sponsored by: ThinkGeek at http
RE: [JBoss-dev] http transport
Holger, in JBoss 3.0 we have client interceptors, and pluggable transports. The invocation has been totally decoupled from the EJB container. The EJB Container is now just an MBean and all EJB invocations go across the JMX bus. JBoss 3.1 takes things a bit further. In 3.1 you can now define multiple invokers (transports) per EJB container. So an EJB container can be configured to receive requests from RMI, IIOP, SOAP, HTTP, whatever all at the same time. We'll want to hook your HTTP invoker into this architecture. The files and java packages you'll want to look at are as follows, There's also a detail email I sent out 2 months ago that is copied later on in this email: In server module: Packages org.jboss.invocation, org.jboss.proxy org.jboss.invocation.jrmp.server.JRMPInvoker.java is the main entry point on the server side. It accepts invocation requests and routes them across the JMX bus. I think your HTTP POST protocol can be very simple. Just marshall an Invocation and send it across the wire. The JRMPInvoker is stateless and can route any Invocation. For the client side, you'll need to implement a new org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy. This is really the Transport on the client side. You'll also need to implement a org.jboss.proxy.ejb.ProxyFactory. The JBoss clustering can be used as an example since it has extended JRMPInvokerProxy, ProxyFactory and has its own Invoker. see the cluster module. All classes under the above packages. What sucks is that even if you've implemented this stuff, its not very helpful because JNDI does not have pluggable transports. This is something we wanted to work on for JBoss 4.0. Make JNDI an MBean, as well as rewrite client-interceptors/server-interceptors/proxy factories and their configurations all in terms of MBeans and MBean invocations and MBean xml descriptors. This is the major vision Marc has put forth. To make JBoss a Unified architecture that can describe any distributed object framework as a set of MBeans and MBean configurations. The classes are there, the configuration isn't. But, just get the HTTP invoker with EJB working, then we can work on JNDI later. Here's what I wrote back in April on the subject: JBoss 3.1 (CVS-HEAD) now has the ability to bind multiple invokers per EJB container. This means that one EJB container can serve up requests from IIOP, RMI, SOAP, your-protocol-here all at the same time. Also, if your EJBs are configured correctly in jboss.xml Beans accessed through bean ejb-refs will automatically and transparently use the correct protocol. Meaning, if you start off on IIOP, you'll stay on IIOP (unless the call is colocated). There have been some fundamental changes to configuration: 1. container-configuration no longer has client-interceptors defined within it. A new invoker to proxy factory binding has the client-interceptor definitions for each proxyfactory/invoker binding combo. 2. Also, container-invoker configuration tag has been removed from container-configuration. 3. jdk1.2.2 support has been removed from standardjboss.xml 4. THere are no more Clustered container-configuration definitions in standardjboss.xml. They're no longer needed Let's take a look at the new standardjboss.xml: jboss invoker-proxy-bindings invoker-proxy-binding nameentity-rmi-invoker/name invoker-mbeanjboss:service=invoker,type=jrmp/invoker-mbean proxy-factoryorg.jboss.proxy.ejb.ProxyFactory/proxy-factory proxy-factory-config client-interceptors home interceptororg.jboss.proxy.ejb.HomeInterceptor/interceptor interceptororg.jboss.proxy.SecurityInterceptor/interceptor interceptororg.jboss.proxy.TransactionInterceptor/interceptor interceptororg.jboss.invocation.InvokerInterceptor/interceptor /home bean interceptororg.jboss.proxy.ejb.EntityInterceptor/interceptor interceptororg.jboss.proxy.SecurityInterceptor/interceptor interceptororg.jboss.proxy.TransactionInterceptor/interceptor interceptororg.jboss.invocation.InvokerInterceptor/interceptor /bean list-entity interceptororg.jboss.proxy.ejb.ListEntityInterceptor/interceptor interceptororg.jboss.proxy.SecurityInterceptor/interceptor interceptororg.jboss.proxy.TransactionInterceptor/interceptor interceptororg.jboss.invocation.InvokerInterceptor/interceptor /list-entity /client-interceptors /proxy-factory-config /invoker-proxy-binding ... The invoker-proxy-binding is a description of the binding between an Invoker and the EJB proxy factory. It also contains the Proxy Factory's configuration. For RMI ejbs, proxy-factory-config contains a list of client-interceptors. If you look at the message-driven-bean invoker-proxy-factory binding, you'll see that the proxy-factory-config contains configuration for setting up JMS. invoker-proxy-binding
