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 +0000, 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
>>
>
