Re: Class load problem

2001-05-10 Thread Bob Davison



On 08/05/2001 21:39:31 Hawkins, Keith (Keith) wrote:
> I have a servlet that uses the Sun's jndi classes to access a LDAP
> database.
>
> I have a test program that can run my servlet's jndi access methods
> without any problem.
>
> When I install and run the servlet under tomcat,  the class loader
> throws a ClassNotFoundException
> for the com.sun.jndi.ldap.LdapCtxFactory class.
> (Stack trace shown below.)
>
> I have the jndi jar files in the WEB-INF/lib directory along with the
> jar file for my servlet code.
>
> Why can't tomcat load the same classes that my test program can if the
> same jar files are used in both cases?
>
> How can I determine the classpath that is in effect when my servlet is
> attempting to load the class?
>
> (I tried using System.getProperty("java.class.path") but the results
> didn't even show the jar file containing
>  my servlet classes, so I know this is not showing me the true
> classpath)
>
-- snip

Keith, I haven't tried this out but I think the following will help ...

Tomcat doesn't use the classpath to load classes in WEB-INF/lib or
WEB-INF/classes, it uses a special classloader that just monitors those
directories.  When JNDI attempts to load the LDAP service provider classes it
uses the current thread's contextClassLoader which, unfortunately, Tomcat
doesn't setup correctly.  There is a class
org.apache.tomcat.request.Jdk12Interceptor which does set the context class
loader correctly for each request so you should add this as a request
interceptor to your server.xml file.

.../Bob


-
Visit our Internet site at http://www.reuters.com

Any views expressed in this message are those of  the  individual
sender,  except  where  the sender specifically states them to be
the views of Reuters Ltd.



Re: Objects in Vector are loosing type

2001-05-04 Thread Bob Davison



On 04/05/2001 07:38:57 ?iso-8859-1?Q?Endre_St=F8lsvik?= wrote:
> On Thu, 3 May 2001, Milt Epstein wrote:
>
> | Maybe your app could use some reorganizing.
>
> Yeah, maybe, Milt.
>
> Why don't you ask the developers, then? I actually believe that all things
> I said in those mails about reloading in TC3.x and TC4 are correct.
>
> And the reason for me having to restart every time is that I basically
> have made a "server" running "on top of tomcat", and there's basically
> only 3 servlets running, but with lots of helper classes and stuff around.
>
> The reason for _always_ getting a ClassCastException is that I have all my
> user information stored in a User object. This won't ever reload (that is,
> serialize/deserialize, or in some other way being "cast" over to the new
> classloader), and when i retrieve it from the HttpSession, it's _always_
> ClassCastException'ing.
>
> I'm not the only one making such "complicated" apps. The exact same story
> about the "User object" have been mentioned a couple of times on this
> list.
>
> And that's how it is.
>
> ;)
>
>
> --
> Mvh,
> Endre
>

I just started using Tomcat (3.2.1) the other day for development and found the
"nearly but not quite" state of the servlet reloading to be frustrating so I had
a look at the code and have come up with a few hacks that seem to get it working
for me, session objects as well.  The main problem seems to be that class
reloading is being handled on the servlet level rather than the context level.

I am sure that it is not robust and certainly doesn't take into account
destroying a servlet on one thread while it is use on another, but it is fine
for development.  Try it out and let me know if it helps with those
ClassCastException blues :-)

Sorry about the code folks, I know that this isn't tomcat-dev but I am not a
tomcat developer and there seem to be a few people on this list suffering with
the same problem.


File: org/apache/tomcat/core/ContextManager.java
method internalService(), just before the line that reads

if( req.getWrapper() == null ) {

add

req.getContext().handleReload(req);

--

File: org/apache/tomcat/core/Context.java
new method

void handleReload(Request req) {
if( reloadable
&& servletL != null
&& servletL.shouldReload() ) {
Enumeration e = servlets.elements();
while( e.hasMoreElements() ) {
try {
ServletWrapper wrapper = (ServletWrapper)e.nextElement();
if( !wrapper.isInternal() ) {
wrapper.destroy();
}
} catch(Exception ex) {
log("Error in destroy: ", ex);
}
}
servletL.reload();
try {
contextM.doReload(req, this);
} catch(TomcatException te) {
log("Error in reload", te);
}
}
}



File: org/apache/tomcat/core/ServletWrapper.java

method doDestroy(), at the end add:

servlet = null;
servletClass = null;


method handleReload(), comment out everything (beware there are already /* */
comments in there...)


.../Bob


-
Visit our Internet site at http://www.reuters.com

Any views expressed in this message are those of  the  individual
sender,  except  where  the sender specifically states them to be
the views of Reuters Ltd.