I am having a problem with BEA WebLogic. Let me describe the problem:
Problem Description: What I need is to pass some arbitrary piece of data between the RMI client and server, so I want to inject the data on the client and retrieve it on the server (the ultimate goal being able to trace transaction flow across multiple app servers)
CORBA Portable Interceptors fit the bill perfectly and are designed for that specific purpose. The interceptors are CORBA standard and were added to J2EE 1.4 standard. Sun own ORB, IBM WebSphere and JBOSS all support Portable Interceptors. WebLogic does not
I looked at WebLogic documentation and could find no replacement for interception of RMI flow. The last resort is code instrumentation, but I really want to avoid that since I have to support J2SE 1.4 code that is prior to javaagent.
Has anyone ever implemented something similar for WebLogic (v8.1 and up) or can point me to any feature of the product that can help me?
Are you looking to intercept the IIOP stream? This is not a requirement of the EJB specification, and WebLogic Server does not expose the CORBA portable interceptor interfaces. Are you locked into WebLogic Server? If not, then JBoss does support portable interceptors as you say.
SCJP 1.4, SCWCD 1.3, SCBCD 1.3
Sharon Ben Asher
Joined: Feb 07, 2008
thanks, Roger, for the prompt reply.
I understand that PI is not a requirement of the EJB specification. It is, however, part of J2EE 1.4 standard from Sun.
My application needs to support multiple vendors. Someone on another forum pointed me to WebLogic WorkContext which propagates arbitrary context across servers. This seems to fit the bill in terms of functionality, however, it needs to be coded into the client and server, whereas I was looking for external invocation like PI (which is invoked via VM arguments).
Joined: Sep 29, 2002
As we all know, every EJB server is different. So, your build for every target platform will be different, even if it is only the way in which things like JNDI mappings is done.
WebLogic Server context propagation does indeed require both client and server code to work. I think you just have to accept that this is a case of needing to do some proprietary work in order to meet your business requirement.