Hi Vincent (and others),
Thanks for all your advice. Once I got past the chores of the work
week and actually got to spend some time restructuring our app into
a WAR, things worked fine.
The problem was that ServletTestCaller wasn't being loaded by
the Resin classloader, because it was in the system CLASSPATH.
Once I put the cactus jars into WEB-INF/lib, I was all set.
I would assume that I could get it all to work without using
the WARs, as long as the classes were being loaded by Resin's
classloader, and not the system's.
Thanks again,
-- Dirk
Vincent Massol wrote:
>
> Hi Dirk,
>
> ----- Original Message -----
> From: "Dirk Pranke" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, August 14, 2001 4:50 AM
> Subject: configuration problem for cactus & resin
>
> > Hi all,
> >
> > I'm new to this list, and I'm having a problem configuring Cactus
> > to work with Resin. I apologize if this is an obvious problem, but
> > from my reading of the docs, I was a little unclear on how things
> > worked.
>
> no problem and we are working on the docs to make them more clear ... :)
>
> >
> > I'm using Cactus 1.0, Resin 1.2.3, and Sun's 1.3.1 JVM running on
> > Redhat 6.2. I'm also using Apache and mod_caucho as a front end
> > to Resin. (I tried Cactus 1.1, but that didn't change anything).
> >
> > My application is not using WARs or web.xml; instead, all my classes
> > are simply located in the server application directory, which is
> > set by resin's <http-server><app-dir> tags in resin.conf.
>
> ok, but why don't you use WAR as this is the standard way of doing it
> nowadays ? Not using WARs is not supported ... :) ... but I'll still try to
> help you .... :)
>
> >
> > Up until recently, I've had everything working just fine. However,
> > Resin did not notice when I changed .class files, and I needed to
> > stop and restart Resin every time something changed. It turned out
> > that this was because the above directory was listed in my CLASSPATH
> > as well as resin's <http-server><app-dir> parameter. Taking the
> > directory out of the classpath solved the problem, which makes sense,
> > because Resin was treating it as a system class.
> >
> > Unfortunately, this caused Cactus to stop working. It fails with
> > java.lang.ClassNotFound exceptions, like the following:
>
> This is actually a Resin question, not a Cactus one but I'll try to make
> some guesses (but you should ask it on the Resin mailling list). In order to
> do class reloading, Resin must have a special classloader that monitors
> this app-dir directory and reload classes when they change. However this
> classloader probably also inherits from the system classloader (as you
> mentioned above).
>
> There are several files/jars that ned to be somehow in your server
> "classpath" :
> - your test classes
> - your classes under test
> - commons-cactus.jar
> - junit.jar
>
> These need to be either in your app-dir directory or in your system
> classpath (I don't know if the special Resin classloader will also manage
> jars put in app-dir).
>
> >
> > % java atlantes.command.TestUpdatePassword
> > TestUpdatePassword:
> > 1..2
> > not ok 1 testNoParams(atlantes.command.TestUpdatePassword)
> > There were 2 errors:
> > 1) testNoParams(atlantes.command.TestUpdatePassword)
> > java.lang.ClassNotFoundException: atlantes.command.TestUpdatePassword
> > at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
> > at java.security.AccessController.doPrivileged(Native Method)
> > at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> > at java.lang.ClassLoader.loadClass(ClassLoader.java:297)
> > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:286)
> > at java.lang.ClassLoader.loadClass(ClassLoader.java:253)
> > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313)
> > at java.lang.Class.forName0(Native Method)
> > at java.lang.Class.forName(Class.java:120)
> > at
> org.apache.commons.cactus.server.ServletTestCaller.callTestMethod(ServletTes
> tCaller.java:102)
> > at
> org.apache.commons.cactus.server.ServletTestCaller.doTest(ServletTestCaller.
> java:200)
> > at
> org.apache.commons.cactus.server.ServletTestRedirector.doPost(ServletTestRed
> irector.java:149)
> > at javax.servlet.http.HttpServlet.service(HttpServlet.java:115)
> > at javax.servlet.http.HttpServlet.service(HttpServlet.java:83)
> > at com.caucho.server.http.Invocation.service(Invocation.java:296)
> > at
> com.caucho.server.http.CacheInvocation.service(CacheInvocation.java:121)
> > at
> com.caucho.server.http.RunnerRequest.handleRequest(RunnerRequest.java:333)
> > at
> com.caucho.server.http.RunnerRequest.handleConnection(RunnerRequest.java:266
> )
> > at com.caucho.server.TcpConnection.run(TcpConnection.java:140)
> > at java.lang.Thread.run(Thread.java:484)
> > ...
> >
> > From reading the cactus documentation, it seems as though having the
> > test classes be in <app-dir> but not the actual CLASSPATH environment
> > variable should be sufficient. The directory is in my
> > client-side CLASSPATH, but I would think that that is irrelevant, since
> > the request is obviously getting to the server. Also that
> cactus.properties is
> > in <app-dir>, but not CLASSPATH.
>
> cactus.properties need only be in the client classpath as it is only used to
> do the HTTP connection from the client part to the Cactus Redirector.
>
> >
> > However, from looking at the stack trace, I'm guessing that cactus is
> using
> > the java class loader and not the caucho class loader, and so it won't
> know
> > about the <app-dir> location. I could be wrong, obviously.
>
> That's what I thought also ... but ...
> The ServletTestCaller is using reflection to call your test method. As it is
> loader by the Resin classloader, it will also use the Resin classloader to
> try to find the class to instanciate.
>
> Ok, I think I understand:
>
> So that would mean that the ServletTestCaller is actually not loaded by the
> Resin classloader ! Meaning that it is _not_ in your app-dir path. Is that
> correct ?
>
> If the Resin classloader does not handle jars in app-dir, there is only one
> solution : use webapps and WARs.
>
> >
> > Surely this should work, and I'm just missing something obvious, but what?
>
> yes, use webapps ... :-)
>
> >
> > Thanks in advance,
> You're welcome
> -Vincent
