frozen class creating JMS Session

[hosier.david]

I'm having the same issue posted in this older thread: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=157162.

We too are getting an Exception indicating a frozen class when attempting to create a JMS Session in a NetBeans RCP application. This is against a JBoss 5.1 server. And to answer the question posed in the other thread, it is on the client side that we are seeing the errors. Or at least that's how I'm reading the stack trace. I posted this question in the JBoss Messaging forum, and they sent me over here. I'm hoping someone can offer even the slightest hint here...we've been banging our head over this for about 4 days now. This issue only occurs in our NetBeans app. The same exact code works fine elsewhere, and we have other code in several places that opens JMS Sessions just fine.

[exec] Caused by: java.lang.RuntimeException: org.jboss.aop.advice.org.jboss.jms.client.container.SessionAspect_z_handleRedeliver_2030193044: frozen class (cannot edit)
 [exec] at javassist.ClassPool.checkNotFrozen(ClassPool.java:568)
 [exec] at javassist.ClassPool.makeClass(ClassPool.java:746)
 [exec] at javassist.ClassPool.makeClass(ClassPool.java:731)
 [exec] at org.jboss.aop.instrument.TransformerCommon.makeClass(TransformerCommon.java:239)
 [exec] at org.jboss.aop.advice.PerVmAdvice.generateInterceptor(PerVmAdvice.java:145)
 [exec] at org.jboss.aop.advice.PerVmAdvice.generateOptimized(PerVmAdvice.java:56)
 [exec] at org.jboss.aop.advice.AdviceFactory.create(AdviceFactory.java:106)
 [exec] at org.jboss.aop.Advisor.createInterceptorChain(Advisor.java:1323)
 [exec] at org.jboss.aop.Advisor.pointcutResolved(Advisor.java:1937)
 [exec] at org.jboss.aop.MethodMatchInfo.applyBinding(MethodMatchInfo.java:152)
 [exec] at org.jboss.aop.MethodMatchInfo.simplePopulateBindings(MethodMatchInfo.java:113)
 [exec] at org.jboss.aop.MethodMatchInfo.populateBindings(MethodMatchInfo.java:96)
 [exec] at org.jboss.aop.Advisor.finalizeMethodChain(Advisor.java:1548)
 [exec] at org.jboss.aop.ClassAdvisor.finalizeChains(ClassAdvisor.java:741)
 [exec] at org.jboss.aop.ClassAdvisor.createInterceptorChains(ClassAdvisor.java:609)
 [exec] at org.jboss.aop.ClassAdvisor$1.run(ClassAdvisor.java:306)
 [exec] at java.security.AccessController.doPrivileged(Native Method)
 [exec] at org.jboss.aop.ClassAdvisor.attachClass(ClassAdvisor.java:276)
 [exec] at org.jboss.aop.AspectManager.initialiseClassAdvisor(AspectManager.java:748)
 [exec] at org.jboss.aop.AspectManager.getAdvisor(AspectManager.java:729)
 [exec] at org.jboss.jms.client.delegate.ClientSessionDelegate.<clinit>(ClientSessionDelegate.java)
 [exec] ... 55 more

[kabirkhan]

Hmm, I've never used Netbeans, so I have no idea what it does special.

If org.jboss.aop.advice.org.jboss.jms.client.container.SessionAspect_z_handleRedeliver_2030193044 is part of the messaging client jar, try removing it to see if that makes any difference. This class and similarly named classes:

org.jboss.aop.advice + <FullClassName>_ + <methodName>_ + <methodHash>

are generated as an aop interceptors per advice method. Maybe this is getting done more than once for some reason in your environment?

[hosier.david]

Well, apparently our application works just fine when deployed as a JNLP app, which is how we deploy as part of the product. It only fails when running the application standalone from the command line or inside NetBeans. It's probably some kind of bug in one of the NetBeans classloaders. I assume that when these classes are generated by AOP, they should subsequently be seen by classloader and that a second pass through the aop interceptor should be able to notice that it does not need to create the class again. Is that a correct assessment? If so, then that would lead me to believe that one of the NetBeans classloaders is not making this class visible when run standalone for whatever reason.

[tcoats130]

I'm experiencing this same problem - did you ever identify a fix or workaround?  If so, would you please share?

I see the problem with a module that plugs into an existing NetBeans RCP application when it attempts to connect to the JBoss Messaging Service (from JBoss-5.1.0GA).  This same code runs fine if it is built/run as a plain Java application.

[hosier.david]

We never figured it out.  I still have the same hunch as I stated in my previous comment, but since it's not an issue in production we just couldn't justify the time to really dig into it.  You might take my thought regarding the NetBeans Classloaders and see if you can get answer on that front over at the NetBeans forums.  My guess is that it's really an issue with how NetBeans handles dynamically created classes that aren't known at application launch time, but I'm not a NetBeans developer, so I really don't know what goes on inside NB.  Sorry I don't have an answer for you.

[markgargan]

Hey Kabir,

           We encountered the same problem this morning, basically it's what you mentioned below, the mechanism

org.jboss.aop.advice + <FullClassName>_ + <methodName>_ + <methodHash>

perhaps has been changed to this. but in the version of

PerVmAdvice that we were using, jboss-aop-client-5.0.0.GA.jar that comes with the jboss

downloadable from the redhat site it's

ClassLoader cl = SecurityActions.getClassLoader(aspect.getClass());

String name = "org.jboss.aop.advice." + aspect.getClass().getName() + "_z_" + adviceName + "_" + System.identityHashCode(cl);

which doesn't cater for situations where the method is overloaded as the adviceName defaults to the methodName and the hashCode fo the classloader
will be the same. The above redeliver method appears in the ClientSessionDelegate class which implements the SessionDelegate interface within the jboss-messaging module.

The SessionDelegate interface has three method signatures overloaded redeliver, createTextMessage and createObjectMessage.

I renamed the overloaded methods (they are all delegated to from the JBossSession class), refactored the ClientSessionDelegate class, rebuilt the jar
and placed in our app and the problem didn't re-occur.

I've attached a copy of the jar with the amended classes, JBossSession, ClientSessionDelegate and SessionDelegate.

I didn't go through the process of resigned the classes in the MANIFEST.MF just in case.

Mark.

[sudipmanpuria]

Hi Mark

Thank you very much for sharing the amended jar file.

Me and my team heart fully acknowledge your help.

Sudip