Do we want to add some info for the common transaction params?
I mean, this is common between the XA/local transactional connectors, so we might break it out, or we can just treat it as another property and not give it special typing.
I think the current ideas are adequate, although maybe we want to add more typing info. What do you think?
- <xsl:when test="track-connection-by-tx">
The Axis notion of custom providers would render a WS deployment J2EE incompatible, so we cannot support it in JBossWS. What is your use case?
There are 2 backend components, both EJB-based, one on JBoss and one on WebLogic, all being exposed as Web Services through JBoss. The WebLogic component has a client for creating remote instances of stubs to the EJBs, to allow passing additional parameters.
I need a custom provider that would invoke the client to create the stub instance, and invoke the WS operation on WebLogic through the stub. I've been trying to extend RPCProvider, treating the stub as a JSE. But the PortComponentMetaData is not included in jboss-ws4ee-client.jar, making it impossible for me to retrieve the SEI, or to extend InvokerProviderJSE.
Could a custom handler be used instead of a custom provider, with the handleRequest method returning false?
Can you connect to your WebLogic EJB from a JBoss EJB? Then you could create a gateway SLSB in JBoss that receives the client requests and routs them to WebLogic.
Or am I missing the point?
But InvokerProviderEJB forces an "invoke" on the SLSB method in the RequestEnvelope, which implies that every method in the WebLogic EJBs would have to be hard-coded in the gateway EJB on JBoss.
In one word, the solution is a static proxy as opposed to a dynamic proxy - not practical with hundreds of operations in several Web Services, with overloaded operations *across* Web Services.
Hence my earlier question: Could a custom handler be used instead of a custom provider, with the handleRequest method returning false?