Terracotta Discussion Forums

Hey, All,

I'm trying to get a proof-of-concept to work in our enterprise application, running on WebLogic 9.2. The POC shares four fields within a delegate class deployed and used in an EJB as part of an EAR file.

I've modified my start script to use the JVM arguments and properties per the TC DSO documentation, and it appears to recognize everything and starts to parse the tc-config.xml file (deployed in a domain-level classpath location). However, I get an InvalidClassException almost immediately for the class javax.xml.namespace.QName:

"Caused by: java.io.InvalidClassException: javax.xml.namespace.QName; local class incompatible: stream classdesc serialVersionUID = 4418622981026545151, local class serialVersionUID = -9120448754896609940"

Is it even possible to instrument classes deployed within a JEE EAR file? If so, are there unique configuration/deployment steps that must be taken?

One other thing to mention is that we've developed a custom WebLogic security provider. Is there any reason this might cause a problem?

I welcome any thoughts you might have about these questions or what I'm trying to do. Please let me know if I can provide any additional details or clarification.

Thanks!

cramer

Hi there,

WLS 9.2 is not a supported weblogic platform at the moment, we only officially suport 8.1. That said, it is conceivable that some things might work in 9.2+. I'm downloading the 900MB install right now to give it a try :-)

Is there a stack trace associated with that InvalidClassException? I'm mostly wondering if the exception happens in weblogic code or terracotta code.

I wonder if perhaps you have tc.jar in CLASSPATH, or as part of you application/ear? If so, you should remove it.

Tim,

Thanks for the reply.

I've attached a couple of files, including the start script and the stack trace of the error. I don't see TC code in the stack trace, so it may be an incompability surfacing. (Any comments re: the fact that we're using a custom security provider?)

Also, any idea when you might certify against WLS 9.2?

Thanks, again!

cramer

Oh, I almost forgot. I didn't include tc.jar in either the CLASSPATH or the EAR file.

cramer

Sorry I forget to answer some of the question...

It should be possible to instrument classes in an EAR. We hook into every single classloader that exists in the VM.

The custom security provider might be an issue, but I don't think it would be the cause of the InvalidClassException. I'm not actually sure what you mean by that exactly. Do you mean something that deals with code permission, or something that deals with authentication/authorization (ala JAAS). Both could be problematic, just in different ways :-)

I'll have to ping someone else about the timeline for WLS9

Tim,

Thanks for the additional info. I may have removed the security provider (the JAAS variety) as a potential root cause. I tried simply bringing up one of the sample domains with the same TC modifications to the startup and the same tc-config.xml file. It generated the same InvalidClassException and at the same place in the WLS code.

So, at this point, it's looking like it might be a simple matter of incompatibility. If you end up trying things out on 9.2, I'd be interested in hearing your result.

Thanks, again!

cramer

So I fired up WLS9.2 + Terracotta 2.2.1 on win32 w/o any issues. I didn't try to do any object sharing, but the server started okay at least

The InvalidClassException is almost certainly the result of some old version of the XML namespace classes sitting around somewhere.

Can you maybe try adding this to your startup script

Code:

-XX:+TraceClassLoading

That should produce a lot of output -- you're looking to see which jar(s) javax.xml.namespace.QName is loaded from. I think it might be possible to see a line for that class name more than once if more than one classloader loads it.

Here's a dev2dev link with a similar issue:
http://forums.bea.com/bea/message.jspa?messageID=600036067&tstart=0

Tim,

Thanks for the help! It DID turn out to be the known issue with javax.xml.namespace.QName described in the dev2dev forum thread you pointed me to. Applying the -Dcom.sun.xml.namespace.QName.useCompatibleSerialVersionUID=1.0 option resolved the issue for me.

cramer

I'm trying with Terracotta 2.5.2 and WebLogic 9.2 and got the same problem/exception. Where do you add -Dcom.sun.xml.namespace.QName.useCompatibleSerialVersionUID=1.0? I tried adding it to JAVA_OPTS of start.sh included in WLS9.2 directory of configuration-sandbox. Any idea?

That system property needs to go in the java invocation of the VM experiencing the exception. With managed servers, you might need to be modifying the startManagedWeblogic script.

I would use ps to make sure it is actually getting passed as expected (I assume since you said start.sh was your script that you are on some form of unix machine).

Another place to look is in the terracotta client log file (the location of the log is printed on the console at startup time). We log all system properties there, so you can tell for sure whether the VM has that option set.

FYI, I'm trying the session configurator GUI to start application from there based on WEbLogic 9.2. For this, I don't see any client log file.