users@glassfish.java.net

org.omg.CORBA.NO_IMPLEMENT: This is a locally constrained object

From: <forums_at_java.net>
Date: Tue, 7 Jun 2011 15:59:00 -0500 (CDT)

Hi all,

I encountered a problem that I'm trying to track down, but I'm having some
difficulty. Along the way, I noticed the following in
com/sun/jts/jtsxa/OTSResourceImpl.java (revision 47353) [1] :

... 488.private static org.omg.CORBA.NO_IMPLEMENT no_implement = 489.new
org.omg.CORBA.NO_IMPLEMENT("This is a locally constrained object."); 490.
491. 492.public org.omg.CORBA.Object _duplicate() { 493.throw no_implement;
494.} ...
 

So the class staticallly instantiates an Exception and then throws this
exception in various unimplemented methods (presumably to avoid the cost of
instantiating a new exception?). This makes debugging difficult, though,
since the stack trace that results from this exception gives the stack for
the instantiation of this exception, not where the exception really occurred:

org.omg.CORBA.NO_IMPLEMENT: This is a locally constrained object. vmcid: 0x0
minor code: 0 completed: No at
com.sun.jts.jtsxa.OTSResourceImpl.<clinit>(OTSResourceImpl.java:488) at
com.sun.jts.jta.TransactionState.startAssociation(TransactionState.java:285)
at com.sun.jts.jta.TransactionImpl.enlistResource(TransactionImpl.java:212)
at
com.sun.enterprise.transaction.JavaEETransactionImpl.enlistResource(JavaEETransactionImpl.java:641)
at
com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.enlistXAResource(JavaEETransactionManagerSimplified.java:1300)
at
com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.enlistResource(JavaEETransactionManagerSimplified.java:360)
at
com.sun.enterprise.resource.rm.SystemResourceManagerImpl.enlistResource(SystemResourceManagerImpl.java:103)
at
com.sun.enterprise.resource.pool.PoolManagerImpl.getResource(PoolManagerImpl.java:208)
... at
com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:117)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597) at
com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)
 

Granted, this is an internal class that end-user developers needn't know much
about, but the stack trace doesn't help provide me with a clue about how the
system came to call the method that caused the exception to be throw.

Any glassfish developers reading this? Thoughts/rationale? I'll be happy to
file an issue if it warrants it.

Thanks,

--Chris


[1]
http://java.net/projects/glassfish/sources/svn/content/branches/3.1.1/transaction/jts/src/main/java/com/sun/jts/jtsxa/OTSResourceImpl.java?rev=47353

--
[Message sent by forum member 'christopherrued']
View Post: http://forums.java.net/node/810426