Re: Orion and Visibroker 4: ClassLoader probs(?)
I have to agree, but in a more general fashion--I wish documentation about
ClassLoaders was more widespread in general, much less how they're used
within the JDK. (Too many people still override loadClass() in a Java2
ClassLoader, which breaks *everything*.)
For what it's worth, Jeff, you can usually get away with just calling the
3-arg Class.forName() method, with the 3rd arg being the ClassLoader coming
from Thread.getContextClassLoader(). Or you can risk it and use the
ClassLoader that loaded you. Your choice. :-)
Ted Neward
Java Instructor, DevelopMentor ( http://www.develop.com )
http://www.javageeks.com/~tneward
-Original Message-
From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
To: Orion-Interest <[EMAIL PROTECTED]>
Date: Tuesday, March 28, 2000 11:37 AM
Subject: RE: Orion and Visibroker 4: ClassLoader probs(?)
>Its too bad that the Sun JNDI docs (and RMI docs) don't make any public
>mention of whether or how they use Thread.getContextClassLoader(); it makes
>it difficult to write application servers and custom frameworks that do
>dynamic class loading to use JNDI and RMI without a bunch of codebase and
>classloader workarounds!
>
>/Jeff
>
>-Original Message-
>From: Ted Neward [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, March 28, 2000 3:55 AM
>To: Orion-Interest
>Subject: Re: Orion and Visibroker 4: ClassLoader probs(?)
>
>
>Actually, unless I miss my guess, this may be a sign that Orion isn't
>setting the Thread's context ClassLoader appropriately. Rosanna Lee (of the
>JNDI list) mentioned in a private email thread that JNDI uses the Thread's
>context ClassLoader to appropriately resolve back to the right ClassLoader
>when doing a lookup-and-classload operation. If the context ClassLoader
>isn't set right, these kinds of errors *could* occur. That, or the Orion
>ClassLoader implementation is overriding loadClass(), according to the JDK
>1.1 rules, instead of overriding findClass(), which is the Java2 way.
>
>Just a wild-*ss guess, but without any sort of confirmation or denial from
>the Orion team, it's about as good as it gets, it seems. Potential
>workaround: do a Class.forName(p.get(Context.INITIAL_CONTEXT_FACTORY))
>before calling into the JNDI InitialContext constructor.
>
>Ted Neward
>Java Instructor, DevelopMentor ( http://www.develop.com )
>http://www.javageeks.com/~tneward
>-Original Message-
>From: Joe Walnes <[EMAIL PROTECTED]>
>To: Orion-Interest <[EMAIL PROTECTED]>
>Date: Wednesday, March 22, 2000 7:05 AM
>Subject: Re: Orion and Visibroker 4: ClassLoader probs(?)
>
>
>>Thanks to Magnus for solving this one.
>>
>>If anyone else runs into this problem, the problem is solved by copying
the
>>appropriate VisiBroker jar files to /path-to-jdk/jre/lib/ext/. Weird
>>behaviour by the VM classloader.
>>
>>-Joe Walnes
>>
>>At 04:49 PM 3/22/00 +, Joe Walnes wrote:
>>>I'm trying to use Orion as a client for some CORBA based objects that are
>>>accessible via Visibroker.
>>>
>>>The following code works as a standalone client, providing the correct
>>>jars are in the classpath and the appropriate system properties are set,
>>>and the ORB is running on the localhost:
>>>
>>>-
>>>
>>>// Get context
>>>Properties p = new Properties();
>>>p.put(Context.INITIAL_CONTEXT_FACTORY,"com.inprise.j2ee.jndi.CtxFactory")
;
>>>p.put(Context.URL_PKG_PREFIXES,"com.inprise.j2ee");
>>>Context context = new InitialContext(p);
>>>
>>>// Lookup CustomerHome
>>>Object ref = context.lookup("customer");
>>>CustomerHome home =
>>> (CustomerHome)
>PortableRemoteObject.narrow(ref,CustomerHome.class);
>>>
>>>-
>>>
>>>However, I'm trying to allow servlets/jsps access to the objects from
>>>within Orion. All the appropriate system properties (-Dxx=yy) where set
on
>>>the command line when starting orion, the appropriate jars where placed
in
>>>orion/lib and the orb was running on localhost.
>>>
>>>In a Servlet running in Orion, when the code got as far as creating the
>>>new InitialContext, a NoClassDefFoundError for
>>>com.inprise.j2ee.jndi.CtxFactory was thrown, however,
>>>Class.forName("com.inprise.j2ee.jndi.CtxFactory") did not throw an error.
>>>
>>>The problem appeared to be a ClassLoader problem, where InitialContext
was
>>>using a different method for loading classes that the servlet was using,
>>>and only seemed to be looking in the
RE: Orion and Visibroker 4: ClassLoader probs(?)
Its too bad that the Sun JNDI docs (and RMI docs) don't make any public
mention of whether or how they use Thread.getContextClassLoader(); it makes
it difficult to write application servers and custom frameworks that do
dynamic class loading to use JNDI and RMI without a bunch of codebase and
classloader workarounds!
/Jeff
-Original Message-
From: Ted Neward [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 28, 2000 3:55 AM
To: Orion-Interest
Subject: Re: Orion and Visibroker 4: ClassLoader probs(?)
Actually, unless I miss my guess, this may be a sign that Orion isn't
setting the Thread's context ClassLoader appropriately. Rosanna Lee (of the
JNDI list) mentioned in a private email thread that JNDI uses the Thread's
context ClassLoader to appropriately resolve back to the right ClassLoader
when doing a lookup-and-classload operation. If the context ClassLoader
isn't set right, these kinds of errors *could* occur. That, or the Orion
ClassLoader implementation is overriding loadClass(), according to the JDK
1.1 rules, instead of overriding findClass(), which is the Java2 way.
Just a wild-*ss guess, but without any sort of confirmation or denial from
the Orion team, it's about as good as it gets, it seems. Potential
workaround: do a Class.forName(p.get(Context.INITIAL_CONTEXT_FACTORY))
before calling into the JNDI InitialContext constructor.
Ted Neward
Java Instructor, DevelopMentor ( http://www.develop.com )
http://www.javageeks.com/~tneward
-Original Message-
From: Joe Walnes <[EMAIL PROTECTED]>
To: Orion-Interest <[EMAIL PROTECTED]>
Date: Wednesday, March 22, 2000 7:05 AM
Subject: Re: Orion and Visibroker 4: ClassLoader probs(?)
>Thanks to Magnus for solving this one.
>
>If anyone else runs into this problem, the problem is solved by copying the
>appropriate VisiBroker jar files to /path-to-jdk/jre/lib/ext/. Weird
>behaviour by the VM classloader.
>
>-Joe Walnes
>
>At 04:49 PM 3/22/00 +, Joe Walnes wrote:
>>I'm trying to use Orion as a client for some CORBA based objects that are
>>accessible via Visibroker.
>>
>>The following code works as a standalone client, providing the correct
>>jars are in the classpath and the appropriate system properties are set,
>>and the ORB is running on the localhost:
>>
>>-
>>
>>// Get context
>>Properties p = new Properties();
>>p.put(Context.INITIAL_CONTEXT_FACTORY,"com.inprise.j2ee.jndi.CtxFactory");
>>p.put(Context.URL_PKG_PREFIXES,"com.inprise.j2ee");
>>Context context = new InitialContext(p);
>>
>>// Lookup CustomerHome
>>Object ref = context.lookup("customer");
>>CustomerHome home =
>> (CustomerHome)
PortableRemoteObject.narrow(ref,CustomerHome.class);
>>
>>-
>>
>>However, I'm trying to allow servlets/jsps access to the objects from
>>within Orion. All the appropriate system properties (-Dxx=yy) where set on
>>the command line when starting orion, the appropriate jars where placed in
>>orion/lib and the orb was running on localhost.
>>
>>In a Servlet running in Orion, when the code got as far as creating the
>>new InitialContext, a NoClassDefFoundError for
>>com.inprise.j2ee.jndi.CtxFactory was thrown, however,
>>Class.forName("com.inprise.j2ee.jndi.CtxFactory") did not throw an error.
>>
>>The problem appeared to be a ClassLoader problem, where InitialContext was
>>using a different method for loading classes that the servlet was using,
>>and only seemed to be looking in the base jars in the orion dir. I added
>>the appropriate jndi/corba/iiop/orb classes to orion/jndi.jar and the code
>>succesfully managed to lookup the required object. Hurrah!
>>
>>However, the object returned by context.lookup() is of type
>>org.omg.CORBA.portable.ObjectImpl which needs to be narrowed to
>>appropriate type before casting. This always throws a ClassCastException,
>>even though the ObjectImpl says it is the correct type. I'm stuck!
>>
>>I've been trying to get round this problem for days now unsuccesfully. I
>>can access the corba objects as standalone java apps, and from within Sun
>>Web Server, mod_jserv and jRun with no problem, just not Orion.
>>
>>Can anyone help, or shed some light on what the problem may be. I suspect
>>the problem is related to ClassLoader.
>>
>>Could one of the Orion team explain how the ClassLoader works in the
>>server please.
>>
>>Note, in this case Orion is simply being used as a web-server for serving
>>jsp/servlets. EJB/JTS/etc is not required, and the JNDI service is
>>replaced by that that Visibroker supplies.
>>
>>Thanks in advance
>>
>>-Joe Walnes
>
Re: Orion and Visibroker 4: ClassLoader probs(?)
Actually, unless I miss my guess, this may be a sign that Orion isn't
setting the Thread's context ClassLoader appropriately. Rosanna Lee (of the
JNDI list) mentioned in a private email thread that JNDI uses the Thread's
context ClassLoader to appropriately resolve back to the right ClassLoader
when doing a lookup-and-classload operation. If the context ClassLoader
isn't set right, these kinds of errors *could* occur. That, or the Orion
ClassLoader implementation is overriding loadClass(), according to the JDK
1.1 rules, instead of overriding findClass(), which is the Java2 way.
Just a wild-*ss guess, but without any sort of confirmation or denial from
the Orion team, it's about as good as it gets, it seems. Potential
workaround: do a Class.forName(p.get(Context.INITIAL_CONTEXT_FACTORY))
before calling into the JNDI InitialContext constructor.
Ted Neward
Java Instructor, DevelopMentor ( http://www.develop.com )
http://www.javageeks.com/~tneward
-Original Message-
From: Joe Walnes <[EMAIL PROTECTED]>
To: Orion-Interest <[EMAIL PROTECTED]>
Date: Wednesday, March 22, 2000 7:05 AM
Subject: Re: Orion and Visibroker 4: ClassLoader probs(?)
>Thanks to Magnus for solving this one.
>
>If anyone else runs into this problem, the problem is solved by copying the
>appropriate VisiBroker jar files to /path-to-jdk/jre/lib/ext/. Weird
>behaviour by the VM classloader.
>
>-Joe Walnes
>
>At 04:49 PM 3/22/00 +, Joe Walnes wrote:
>>I'm trying to use Orion as a client for some CORBA based objects that are
>>accessible via Visibroker.
>>
>>The following code works as a standalone client, providing the correct
>>jars are in the classpath and the appropriate system properties are set,
>>and the ORB is running on the localhost:
>>
>>-
>>
>>// Get context
>>Properties p = new Properties();
>>p.put(Context.INITIAL_CONTEXT_FACTORY,"com.inprise.j2ee.jndi.CtxFactory");
>>p.put(Context.URL_PKG_PREFIXES,"com.inprise.j2ee");
>>Context context = new InitialContext(p);
>>
>>// Lookup CustomerHome
>>Object ref = context.lookup("customer");
>>CustomerHome home =
>> (CustomerHome)
PortableRemoteObject.narrow(ref,CustomerHome.class);
>>
>>-
>>
>>However, I'm trying to allow servlets/jsps access to the objects from
>>within Orion. All the appropriate system properties (-Dxx=yy) where set on
>>the command line when starting orion, the appropriate jars where placed in
>>orion/lib and the orb was running on localhost.
>>
>>In a Servlet running in Orion, when the code got as far as creating the
>>new InitialContext, a NoClassDefFoundError for
>>com.inprise.j2ee.jndi.CtxFactory was thrown, however,
>>Class.forName("com.inprise.j2ee.jndi.CtxFactory") did not throw an error.
>>
>>The problem appeared to be a ClassLoader problem, where InitialContext was
>>using a different method for loading classes that the servlet was using,
>>and only seemed to be looking in the base jars in the orion dir. I added
>>the appropriate jndi/corba/iiop/orb classes to orion/jndi.jar and the code
>>succesfully managed to lookup the required object. Hurrah!
>>
>>However, the object returned by context.lookup() is of type
>>org.omg.CORBA.portable.ObjectImpl which needs to be narrowed to
>>appropriate type before casting. This always throws a ClassCastException,
>>even though the ObjectImpl says it is the correct type. I'm stuck!
>>
>>I've been trying to get round this problem for days now unsuccesfully. I
>>can access the corba objects as standalone java apps, and from within Sun
>>Web Server, mod_jserv and jRun with no problem, just not Orion.
>>
>>Can anyone help, or shed some light on what the problem may be. I suspect
>>the problem is related to ClassLoader.
>>
>>Could one of the Orion team explain how the ClassLoader works in the
>>server please.
>>
>>Note, in this case Orion is simply being used as a web-server for serving
>>jsp/servlets. EJB/JTS/etc is not required, and the JNDI service is
>>replaced by that that Visibroker supplies.
>>
>>Thanks in advance
>>
>>-Joe Walnes
>
Re: Orion and Visibroker 4: ClassLoader probs(?)
Thanks to Magnus for solving this one.
If anyone else runs into this problem, the problem is solved by copying the
appropriate VisiBroker jar files to /path-to-jdk/jre/lib/ext/. Weird
behaviour by the VM classloader.
-Joe Walnes
At 04:49 PM 3/22/00 +, Joe Walnes wrote:
>I'm trying to use Orion as a client for some CORBA based objects that are
>accessible via Visibroker.
>
>The following code works as a standalone client, providing the correct
>jars are in the classpath and the appropriate system properties are set,
>and the ORB is running on the localhost:
>
>-
>
>// Get context
>Properties p = new Properties();
>p.put(Context.INITIAL_CONTEXT_FACTORY,"com.inprise.j2ee.jndi.CtxFactory");
>p.put(Context.URL_PKG_PREFIXES,"com.inprise.j2ee");
>Context context = new InitialContext(p);
>
>// Lookup CustomerHome
>Object ref = context.lookup("customer");
>CustomerHome home =
> (CustomerHome) PortableRemoteObject.narrow(ref,CustomerHome.class);
>
>-
>
>However, I'm trying to allow servlets/jsps access to the objects from
>within Orion. All the appropriate system properties (-Dxx=yy) where set on
>the command line when starting orion, the appropriate jars where placed in
>orion/lib and the orb was running on localhost.
>
>In a Servlet running in Orion, when the code got as far as creating the
>new InitialContext, a NoClassDefFoundError for
>com.inprise.j2ee.jndi.CtxFactory was thrown, however,
>Class.forName("com.inprise.j2ee.jndi.CtxFactory") did not throw an error.
>
>The problem appeared to be a ClassLoader problem, where InitialContext was
>using a different method for loading classes that the servlet was using,
>and only seemed to be looking in the base jars in the orion dir. I added
>the appropriate jndi/corba/iiop/orb classes to orion/jndi.jar and the code
>succesfully managed to lookup the required object. Hurrah!
>
>However, the object returned by context.lookup() is of type
>org.omg.CORBA.portable.ObjectImpl which needs to be narrowed to
>appropriate type before casting. This always throws a ClassCastException,
>even though the ObjectImpl says it is the correct type. I'm stuck!
>
>I've been trying to get round this problem for days now unsuccesfully. I
>can access the corba objects as standalone java apps, and from within Sun
>Web Server, mod_jserv and jRun with no problem, just not Orion.
>
>Can anyone help, or shed some light on what the problem may be. I suspect
>the problem is related to ClassLoader.
>
>Could one of the Orion team explain how the ClassLoader works in the
>server please.
>
>Note, in this case Orion is simply being used as a web-server for serving
>jsp/servlets. EJB/JTS/etc is not required, and the JNDI service is
>replaced by that that Visibroker supplies.
>
>Thanks in advance
>
>-Joe Walnes
