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
