> -----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
