Re: FormAuthentication
Thanks for the suggestion, but it ended up being my fault again. I think I'll wait a little tiny bit longer before asking for help next time. I always seem to figure it out shortly after I ask for help. I just need to pretend like I asked for help and then maybe the answer will come to me. :-) --David Nicolas Chalumeau wrote: Do you use the ant task or the maven plugin ? For the ant task add in your catifywar : roles="RoleBase"/> For the maven plugin I provide a patch but it is the same thing to do : http://issues.apache.org/jira/browse/CACTUS-224 Nicolas, 2005/9/1, David Turley <[EMAIL PROTECTED]>: Hi, it's me again... I'm trying to get the FormAuthentication to work. I'm having problems though. (Of course I'm having problems! Why else would I be writing!) When I try to run my test, my test fails and tells me it couldn't connect to the secured redirector. The console says "[Access Denied] NULL user". I haven't had any luck getting this to work. I'm using StrutsTestCase, so I asked for help in their user forum, but that forum is all but dead and I haven't gotten a response. I searched for any threads in there about authentication and all I found was another guy with a similar problem that hadn't had his question answered either... Thanks for any help you can provide. --David Turley - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
FormAuthentication
Hi, it's me again... I'm trying to get the FormAuthentication to work. I'm having problems though. (Of course I'm having problems! Why else would I be writing!) When I try to run my test, my test fails and tells me it couldn't connect to the secured redirector. The console says "[Access Denied] NULL user". I haven't had any luck getting this to work. I'm using StrutsTestCase, so I asked for help in their user forum, but that forum is all but dead and I haven't gotten a response. I searched for any threads in there about authentication and all I found was another guy with a similar problem that hadn't had his question answered either... Thanks for any help you can provide. --David Turley - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Database dilemma
Hello everyone, I'm testing some struts actions that modify some rows in the database, but I don't want those modifications to stick, because then I have to set everything back to the way it was to get my database back to a known state. You'd think that if I changed a row, I could just change it back, but whoever designed this database put triggers all over the place, so if you change one thing explicitly, you change several other things implicitly. So I thought that it would be nice if I could execute everything within the context of a transaction. To do this I would need to change the code that gets the connections to the database to get only one connection, set it so that autocommit is off, and return that connection whenever a connection is needed. So I have a copy of the class that has all the database access code in it that has those modifications, but I only want to use this class for testing, obviously. Is there a way to use one version of the class for testing and the other for production? I could do it with ant, I suppose and just exclude the one and include the other, but is there an easier way? One that I can use when I run my tests manually? Or is there some other better alternative for what I'm trying to do? Thanks, David P.S. Sorry if this is a little off topic. I just don't know who else to ask, and you are all so helpful :-). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: More problems: Error finding class ...
Okay, I gave in and put everything in the WEB-INF/classes directory. It works that way. Thanks for your help! --David Kenney Westerhof wrote: On Mon, 29 Aug 2005, David Turley wrote: Well client side it works fine, your setup is OK. However, you got a ServletException, indicating a server side error. And server side, those classes really can't be found. Even if they're in WEB-INF/classes/. Say you have com.mycompany.TestClass in WEB-INF/classes/test-classes/com/mycompany/TestClass.class. The webservice can't find that class because it's in the wrong dir. It looks for WEB-INF/classes/com/mycompany/TestClass.class. So in the server-side war you can only have those classes in WEB-INF/classes DIRECTLY, no extra directories! I suggest you just put all jars in WEB-INF/classes. Doesn't really matter where they are; if you are debugging, you can see the source location anyway which tells you immediately what kind of source it is. -- Kenney Hi Kenney, You said that if I'm running the classes straight from Eclipse (which I am) I could add WEB-INF/classes as a src directory. I have the test source directories added as source directories with the correct output folders. Here are the lines from my .classpath file: Is that sort of what you meant? Should that work? It doesn't, unfortunately. If you can't see anything wrong with that, I'll just have Eclipse output my test classes into WEB-INF/classes... I'd rather not. Maybe I'm just stubborn. When I think something SHOULD work, I want it to :-). Kenney Westerhof wrote: On Mon, 29 Aug 2005, David Turley wrote: Hi David, If you deploy that war, the classes NEED to be in WEB-INF/classes. You could also jar them up and put them in WEB-INF/lib/. Those are the only two places classes should be placed in web applications. If you run those classes directly from eclipse, you could add WEB-INF/test-classes as a source folder (or, if you have a separate source folder for the test-classes sources, modify .classpath and specify an output=".../WEB-INF/test-classes" to the correct line; can't edit them from within eclipse). But, in the war, they really NEED to be in the classpath or else the Webapp classloader won't find them! And it really doesn't matter where your classes are, as long as your sources are nicely organized. HTH, Kenney Hello again, Yes, I'm still having problems, and most of them have nothing to do with computers. But this one does. When I first started playing with Cactus, I was just running things from Eclipse and the JUnit test runner, but then I wanted to automate things, so I spent a lot of time working with Ant. At first I had put my test classes in the same directories as the classes they were testing, but I decided that was messy and decided to make separate src and class directories for the test classes. That works great with ant because you could have your test classes on mars as long as you could tell ant where to find them. Not so with the JUnit integration in Eclipse. It cannot find my test classes. It worked fine when they were going to the WEB-INF/classes directory, but now they're in WEB-INF/test-classes and I get the following when I try to run tests: javax.servlet.ServletException: Error finding class [com.cleanbrain.cleantelligent.presentation.action.LoadActionCactusTest] using both the Context classloader and the webapp classloader. Possible causes include: - Your webapp does not include your test classes, - The cactus.jar is not located in your WEB-INF/lib directory and your Container has not set the Context classloader to point to the webapp one followed by the rest of the stack trace. Well, the cactus.jar is in the correct place. That's about all I know. I don't know much (anything) about classloaders, so maybe that's my problem. Maybe it's just another I.D.10T. error. :-) I'm learning Thanks, David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Kenney Westerhof http://www.neonics.com GPG public key: http://www.gods.nl/~forge/kenneyw.key - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Kenney Westerhof http://www.neonics.com GPG public key: http://www.gods.nl/~forge/kenneyw.key - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: More problems: Error finding class ...
Hi Kenney, You said that if I'm running the classes straight from Eclipse (which I am) I could add WEB-INF/classes as a src directory. I have the test source directories added as source directories with the correct output folders. Here are the lines from my .classpath file: output="web/WEB-INF/test-classes/cactus-classes" kind="src" path="test/cactus-src"/> output="web/WEB-INF/test-classes/junit-classes" kind="src" path="test/junit-src"/> Is that sort of what you meant? Should that work? It doesn't, unfortunately. If you can't see anything wrong with that, I'll just have Eclipse output my test classes into WEB-INF/classes... I'd rather not. Maybe I'm just stubborn. When I think something SHOULD work, I want it to :-). Kenney Westerhof wrote: On Mon, 29 Aug 2005, David Turley wrote: Hi David, If you deploy that war, the classes NEED to be in WEB-INF/classes. You could also jar them up and put them in WEB-INF/lib/. Those are the only two places classes should be placed in web applications. If you run those classes directly from eclipse, you could add WEB-INF/test-classes as a source folder (or, if you have a separate source folder for the test-classes sources, modify .classpath and specify an output=".../WEB-INF/test-classes" to the correct line; can't edit them from within eclipse). But, in the war, they really NEED to be in the classpath or else the Webapp classloader won't find them! And it really doesn't matter where your classes are, as long as your sources are nicely organized. HTH, Kenney Hello again, Yes, I'm still having problems, and most of them have nothing to do with computers. But this one does. When I first started playing with Cactus, I was just running things from Eclipse and the JUnit test runner, but then I wanted to automate things, so I spent a lot of time working with Ant. At first I had put my test classes in the same directories as the classes they were testing, but I decided that was messy and decided to make separate src and class directories for the test classes. That works great with ant because you could have your test classes on mars as long as you could tell ant where to find them. Not so with the JUnit integration in Eclipse. It cannot find my test classes. It worked fine when they were going to the WEB-INF/classes directory, but now they're in WEB-INF/test-classes and I get the following when I try to run tests: javax.servlet.ServletException: Error finding class [com.cleanbrain.cleantelligent.presentation.action.LoadActionCactusTest] using both the Context classloader and the webapp classloader. Possible causes include: - Your webapp does not include your test classes, - The cactus.jar is not located in your WEB-INF/lib directory and your Container has not set the Context classloader to point to the webapp one followed by the rest of the stack trace. Well, the cactus.jar is in the correct place. That's about all I know. I don't know much (anything) about classloaders, so maybe that's my problem. Maybe it's just another I.D.10T. error. :-) I'm learning Thanks, David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Kenney Westerhof http://www.neonics.com GPG public key: http://www.gods.nl/~forge/kenneyw.key - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
More problems: Error finding class ...
Hello again, Yes, I'm still having problems, and most of them have nothing to do with computers. But this one does. When I first started playing with Cactus, I was just running things from Eclipse and the JUnit test runner, but then I wanted to automate things, so I spent a lot of time working with Ant. At first I had put my test classes in the same directories as the classes they were testing, but I decided that was messy and decided to make separate src and class directories for the test classes. That works great with ant because you could have your test classes on mars as long as you could tell ant where to find them. Not so with the JUnit integration in Eclipse. It cannot find my test classes. It worked fine when they were going to the WEB-INF/classes directory, but now they're in WEB-INF/test-classes and I get the following when I try to run tests: javax.servlet.ServletException: Error finding class [com.cleanbrain.cleantelligent.presentation.action.LoadActionCactusTest] using both the Context classloader and the webapp classloader. Possible causes include: - Your webapp does not include your test classes, - The cactus.jar is not located in your WEB-INF/lib directory and your Container has not set the Context classloader to point to the webapp one followed by the rest of the stack trace. Well, the cactus.jar is in the correct place. That's about all I know. I don't know much (anything) about classloaders, so maybe that's my problem. Maybe it's just another I.D.10T. error. :-) I'm learning Thanks, David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Running Cactus tests in Eclipse
Please disregard that last email... It WAS something stupid. So stupid it would be too embarrassing to relate the problem. I realized the problem almost immediately after sending the message, but it was too late to call it back... Give me the prize for stupidity today :-). --David P.S. Sorry to flood your inbox with virtually pointless messages... David Turley wrote: Okay, that makes sense. Thanks. Unfortunately that's not my only problem. For some reason I'm getting the following stack trace when I try to run my test cases: java.net.MalformedURLException: no protocol: /app/ServletRedirector at java.net.URL.(URL.java:537) at java.net.URL.(URL.java:434) at java.net.URL.(URL.java:383) at org.apache.cactus.internal.client.connector.http.HttpClientConnectionHelper.connect_aroundBody0(HttpClientConnectionHelper.java:78) at org.apache.cactus.internal.client.connector.http.HttpClientConnectionHelper.connect_aroundBody1$advice(HttpClientConnectionHelper.java:306) at org.apache.cactus.internal.client.connector.http.HttpClientConnectionHelper.connect(HttpClientConnectionHelper.java) at org.apache.cactus.internal.client.connector.http.DefaultHttpClient.callRunTest(DefaultHttpClient.java:162) at org.apache.cactus.internal.client.connector.http.DefaultHttpClient.doTest_aroundBody0(DefaultHttpClient.java:80) at org.apache.cactus.internal.client.connector.http.DefaultHttpClient.doTest_aroundBody1$advice(DefaultHttpClient.java:306) at org.apache.cactus.internal.client.connector.http.DefaultHttpClient.doTest(DefaultHttpClient.java) at org.apache.cactus.internal.client.connector.http.HttpProtocolHandler.runWebTest(HttpProtocolHandler.java:159) at org.apache.cactus.internal.client.connector.http.HttpProtocolHandler.runTest_aroundBody0(HttpProtocolHandler.java:80) at org.apache.cactus.internal.client.connector.http.HttpProtocolHandler.runTest_aroundBody1$advice(HttpProtocolHandler.java:306) at org.apache.cactus.internal.client.connector.http.HttpProtocolHandler.runTest(HttpProtocolHandler.java) at org.apache.cactus.internal.client.ClientTestCaseCaller.runTest(ClientTestCaseCaller.java:144) at org.apache.cactus.internal.AbstractCactusTestCase.runBareClient(AbstractCactusTestCase.java:215) at org.apache.cactus.internal.AbstractCactusTestCase.runBare(AbstractCactusTestCase.java:133) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:478) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:344) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) I have put all the servlet mapping stuff in my web.xml, but the error is the same with it in as it is without it. Anyone have any ideas why this is happening? It's probably something totally stupid I'm forgetting to do, but I can't figure it out :-P. Thanks, David Romain Thouvenin wrote: The cactus.properties file must be in the classpath. So you may change the file location and/or the build path in Eclipse so that it works. Hope it helps, Romain David Turley a écrit : At one point I was able to run my Cactus tests in Eclipse by starting up tomcat and running the tests as JUnit tests. Since then I changed my directory structure a bit to make things more sensible and convenient for the Ant integration, and now when I try to run an individual test in Eclipse, it complains about the cactus.contextURL. I have a cactus.properties file in my project's base directory, but something (the error and the fact that it doesn't work...;-) tells me that's not the right place... Where should I put it? What should I do with it? Is there another way to quickly run a test? It takes too long to build and cactify a war to make it convenient. Also, is anyone working on the Eclipse integration? I saw someone ask about downloading it a month ago or so, but there was never any response to his email. Thanks, David Turley - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Running Cactus tests in Eclipse
Okay, that makes sense. Thanks. Unfortunately that's not my only problem. For some reason I'm getting the following stack trace when I try to run my test cases: java.net.MalformedURLException: no protocol: /app/ServletRedirector at java.net.URL.(URL.java:537) at java.net.URL.(URL.java:434) at java.net.URL.(URL.java:383) at org.apache.cactus.internal.client.connector.http.HttpClientConnectionHelper.connect_aroundBody0(HttpClientConnectionHelper.java:78) at org.apache.cactus.internal.client.connector.http.HttpClientConnectionHelper.connect_aroundBody1$advice(HttpClientConnectionHelper.java:306) at org.apache.cactus.internal.client.connector.http.HttpClientConnectionHelper.connect(HttpClientConnectionHelper.java) at org.apache.cactus.internal.client.connector.http.DefaultHttpClient.callRunTest(DefaultHttpClient.java:162) at org.apache.cactus.internal.client.connector.http.DefaultHttpClient.doTest_aroundBody0(DefaultHttpClient.java:80) at org.apache.cactus.internal.client.connector.http.DefaultHttpClient.doTest_aroundBody1$advice(DefaultHttpClient.java:306) at org.apache.cactus.internal.client.connector.http.DefaultHttpClient.doTest(DefaultHttpClient.java) at org.apache.cactus.internal.client.connector.http.HttpProtocolHandler.runWebTest(HttpProtocolHandler.java:159) at org.apache.cactus.internal.client.connector.http.HttpProtocolHandler.runTest_aroundBody0(HttpProtocolHandler.java:80) at org.apache.cactus.internal.client.connector.http.HttpProtocolHandler.runTest_aroundBody1$advice(HttpProtocolHandler.java:306) at org.apache.cactus.internal.client.connector.http.HttpProtocolHandler.runTest(HttpProtocolHandler.java) at org.apache.cactus.internal.client.ClientTestCaseCaller.runTest(ClientTestCaseCaller.java:144) at org.apache.cactus.internal.AbstractCactusTestCase.runBareClient(AbstractCactusTestCase.java:215) at org.apache.cactus.internal.AbstractCactusTestCase.runBare(AbstractCactusTestCase.java:133) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:478) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:344) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) I have put all the servlet mapping stuff in my web.xml, but the error is the same with it in as it is without it. Anyone have any ideas why this is happening? It's probably something totally stupid I'm forgetting to do, but I can't figure it out :-P. Thanks, David Romain Thouvenin wrote: The cactus.properties file must be in the classpath. So you may change the file location and/or the build path in Eclipse so that it works. Hope it helps, Romain David Turley a écrit : At one point I was able to run my Cactus tests in Eclipse by starting up tomcat and running the tests as JUnit tests. Since then I changed my directory structure a bit to make things more sensible and convenient for the Ant integration, and now when I try to run an individual test in Eclipse, it complains about the cactus.contextURL. I have a cactus.properties file in my project's base directory, but something (the error and the fact that it doesn't work...;-) tells me that's not the right place... Where should I put it? What should I do with it? Is there another way to quickly run a test? It takes too long to build and cactify a war to make it convenient. Also, is anyone working on the Eclipse integration? I saw someone ask about downloading it a month ago or so, but there was never any response to his email. Thanks, David Turley - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Running Cactus tests in Eclipse
Hi Lawrence, Thanks for the info. I'll keep my eye on WTP and watch for Cactus integration. --David Lawrence Mandel wrote: Hi David, Wanted to let you know the Eclipse Web Tools Platform (WTP) project [1] has started working on Eclipse integration for Cactus. I've recently had some mailing list discussions (on cactus-dev) with the Cactus team (well, really with Vincent) about how Cactus and WTP can collaborate on this. The short story is there isn't currently much in the way of Cactus tooling in WTP but WTP should be able to pick up the slack on Cactus integration in Eclipse in the coming WTP releases. [1] http://www.eclipse.org/webtools Lawrence Mandel Software Developer IBM Rational Software Phone: 905 - 413 - 3814 Fax: 905 - 413 - 4920 [EMAIL PROTECTED] David Turley <[EMAIL PROTECTED]> 08/26/2005 04:51 PM Please respond to "Cactus Users List" To Cactus Users List cc Subject Running Cactus tests in Eclipse At one point I was able to run my Cactus tests in Eclipse by starting up tomcat and running the tests as JUnit tests. Since then I changed my directory structure a bit to make things more sensible and convenient for the Ant integration, and now when I try to run an individual test in Eclipse, it complains about the cactus.contextURL. I have a cactus.properties file in my project's base directory, but something (the error and the fact that it doesn't work...;-) tells me that's not the right place... Where should I put it? What should I do with it? Is there another way to quickly run a test? It takes too long to build and cactify a war to make it convenient. Also, is anyone working on the Eclipse integration? I saw someone ask about downloading it a month ago or so, but there was never any response to his email. Thanks, David Turley - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Running Cactus tests in Eclipse
At one point I was able to run my Cactus tests in Eclipse by starting up tomcat and running the tests as JUnit tests. Since then I changed my directory structure a bit to make things more sensible and convenient for the Ant integration, and now when I try to run an individual test in Eclipse, it complains about the cactus.contextURL. I have a cactus.properties file in my project's base directory, but something (the error and the fact that it doesn't work...;-) tells me that's not the right place... Where should I put it? What should I do with it? Is there another way to quickly run a test? It takes too long to build and cactify a war to make it convenient. Also, is anyone working on the Eclipse integration? I saw someone ask about downloading it a month ago or so, but there was never any response to his email. Thanks, David Turley - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: More coverage issues
Great, thanks!
Bret Kumler wrote:
There's a work around.
Copy all the cobertura jars into tomcat/common/lib and it works.
It's definitely a cobertura bug.
They're working on a solution.
-Original Message-----
From: David Turley [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 25, 2005 10:30 AM
To: Cactus Users List
Subject: Re: More coverage issues
Yeah, it doesn't work. It was worth a try though, right?
David Turley wrote:
Yeah, I saw it too. I haven't tried it, but I don't think it would
work anyway. My cobertura.ser file goes empty before the report task
is even called, so having it sleep for a while wouldn't change that.
It goes empty right after Tomcat shuts down. But I'll give it a try
for kicks and giggles and let you know in a few minutes.
--David Turley
Bret Kumler wrote:
I have the same problem as you.
I noticed on the cobertura mailing list there's mention of the EOF
and
they say to try a sleep call before the report call.
Have you tried it?
-Original Message-
From: David Turley [mailto:[EMAIL PROTECTED] Sent: Thursday, August
25, 2005 8:08 AM
To: Cactus Users List
Subject: More coverage issues
I took Bret Kumler's suggestion and got Cobertura. I'm having a bit
of a problem with it though. I don't think cobertura is dumping the
coverage information soon enough after running the cactus tests. The
tests run and then Tomcat starts shutting down and then I get the
following error:
[cactus] INFO: Illegal access: this web application instance has been
stopped already (the eventual following stack trace is caused by an
error thrown for debugging purposes as well as to attempt to
terminate the thread which caused the illegal access, and has no
functional
impact)
When I get that error, my cobertura.ser file is suddenly empty and
the report fails with an EOFException.
Anyone have any thoughts on how to fix this? Apparently the coverage
information isn't dumped until the JVM exits. Is there a way to have
the tests run on a different fork than the container control part of
the
task?
In case anyone cares to see it, here's part of my build.xml:
file="${cactus.test.classes.dir}/cobertura.ser"
/>
includes="**/*CactusTest.class"/>
--David Turley
P.S. To Bret Kumler, I didn't have any problems with Struts and
StrutsTestCase when I switched to Cobertura. I could post more of my
build.xml if you'd like, but I don't know that it would be much
help...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This e-mail message and any attachments may contain private,
confidential, proprietary or privileged material of GoldenGate
Software, Inc. that is for the sole use of the intended recipient(s)
of this e-mail message. Any review, copying or distribution or other
use of this e-mail message or any attachments hereto by anyone other
than the intended recipient(s) is strictly prohibited. If you are
not the intended recipient(s) of this e-mail message, please contact
GoldenGate Software, Inc. (415-777-0200) immediately and permanently
delete the original e-mail message and any copies of this e-mail
message and all attachments, if any.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This e-mail message and any attachments may contain private, confidential,
proprietary or privileged material of GoldenGate Software, Inc. that is for the
sole use of the intended recipient(s) of this e-mail message. Any review,
copying or distribution or other use of this e-mail message or any attachments
hereto by anyone other than the intended recipient(s) is strictly prohibited.
If you are not the intended recipient(s) of this e-mail message, please contact
GoldenGate Software, Inc. (415-777-0200) immediately and permanently delete the
original e-mail message and any copies of this e-mail message and all
attachments,
Re: More coverage issues
Yeah, it doesn't work. It was worth a try though, right?
David Turley wrote:
Yeah, I saw it too. I haven't tried it, but I don't think it would
work anyway. My cobertura.ser file goes empty before the report task
is even called, so having it sleep for a while wouldn't change that.
It goes empty right after Tomcat shuts down. But I'll give it a try
for kicks and giggles and let you know in a few minutes.
--David Turley
Bret Kumler wrote:
I have the same problem as you.
I noticed on the cobertura mailing list there's mention of the EOF and
they say to try a sleep call before the report call.
Have you tried it?
-----Original Message-
From: David Turley [mailto:[EMAIL PROTECTED] Sent: Thursday, August
25, 2005 8:08 AM
To: Cactus Users List
Subject: More coverage issues
I took Bret Kumler's suggestion and got Cobertura. I'm having a bit
of a problem with it though. I don't think cobertura is dumping the
coverage information soon enough after running the cactus tests. The
tests run and then Tomcat starts shutting down and then I get the
following error:
[cactus] INFO: Illegal access: this web application instance has been
stopped already (the eventual following stack trace is caused by an
error thrown for debugging purposes as well as to attempt to
terminate the thread which caused the illegal access, and has no
functional
impact)
When I get that error, my cobertura.ser file is suddenly empty and
the report fails with an EOFException.
Anyone have any thoughts on how to fix this? Apparently the coverage
information isn't dumped until the JVM exits. Is there a way to have
the tests run on a different fork than the container control part of the
task?
In case anyone cares to see it, here's part of my build.xml:
file="${cactus.test.classes.dir}/cobertura.ser"
/>
includes="**/*CactusTest.class"/>
--David Turley
P.S. To Bret Kumler, I didn't have any problems with Struts and
StrutsTestCase when I switched to Cobertura. I could post more of my
build.xml if you'd like, but I don't know that it would be much help...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This e-mail message and any attachments may contain private,
confidential, proprietary or privileged material of GoldenGate
Software, Inc. that is for the sole use of the intended recipient(s)
of this e-mail message. Any review, copying or distribution or other
use of this e-mail message or any attachments hereto by anyone other
than the intended recipient(s) is strictly prohibited. If you are
not the intended recipient(s) of this e-mail message, please contact
GoldenGate Software, Inc. (415-777-0200) immediately and permanently
delete the original e-mail message and any copies of this e-mail
message and all attachments, if any.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: More coverage issues
Yeah, I saw it too. I haven't tried it, but I don't think it would work
anyway. My cobertura.ser file goes empty before the report task is even
called, so having it sleep for a while wouldn't change that. It goes
empty right after Tomcat shuts down. But I'll give it a try for kicks
and giggles and let you know in a few minutes.
--David Turley
Bret Kumler wrote:
I have the same problem as you.
I noticed on the cobertura mailing list there's mention of the EOF and
they say to try a sleep call before the report call.
Have you tried it?
-Original Message-
From: David Turley [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 25, 2005 8:08 AM
To: Cactus Users List
Subject: More coverage issues
I took Bret Kumler's suggestion and got Cobertura. I'm having a bit of
a problem with it though. I don't think cobertura is dumping the
coverage information soon enough after running the cactus tests. The
tests run and then Tomcat starts shutting down and then I get the
following error:
[cactus] INFO: Illegal access: this web application instance has been
stopped already (the eventual following stack trace is caused by an
error thrown for debugging purposes as well as to attempt to terminate
the thread which caused the illegal access, and has no functional
impact)
When I get that error, my cobertura.ser file is suddenly empty and the
report fails with an EOFException.
Anyone have any thoughts on how to fix this? Apparently the coverage
information isn't dumped until the JVM exits. Is there a way to have
the tests run on a different fork than the container control part of the
task?
In case anyone cares to see it, here's part of my build.xml:
file="${cactus.test.classes.dir}/cobertura.ser"
/>
includes="**/*CactusTest.class"/>
--David Turley
P.S. To Bret Kumler, I didn't have any problems with Struts and
StrutsTestCase when I switched to Cobertura. I could post more of my
build.xml if you'd like, but I don't know that it would be much help...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This e-mail message and any attachments may contain private, confidential,
proprietary or privileged material of GoldenGate Software, Inc. that is for the
sole use of the intended recipient(s) of this e-mail message. Any review,
copying or distribution or other use of this e-mail message or any attachments
hereto by anyone other than the intended recipient(s) is strictly prohibited.
If you are not the intended recipient(s) of this e-mail message, please contact
GoldenGate Software, Inc. (415-777-0200) immediately and permanently delete the
original e-mail message and any copies of this e-mail message and all
attachments, if any.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
More coverage issues
I took Bret Kumler's suggestion and got Cobertura. I'm having a bit of
a problem with it though. I don't think cobertura is dumping the
coverage information soon enough after running the cactus tests. The
tests run and then Tomcat starts shutting down and then I get the
following error:
[cactus] INFO: Illegal access: this web application instance has been
stopped already (the eventual following stack trace is caused by an
error thrown for debugging purposes as well as to attempt to terminate
the thread which caused the illegal access, and has no functional impact)
When I get that error, my cobertura.ser file is suddenly empty and the
report fails with an EOFException.
Anyone have any thoughts on how to fix this? Apparently the coverage
information isn't dumped until the JVM exits. Is there a way to have
the tests run on a different fork than the container control part of the
task?
In case anyone cares to see it, here's part of my build.xml:
file="${cactus.test.classes.dir}/cobertura.ser"
/>
includes="**/*CactusTest.class"/>
--David Turley
P.S. To Bret Kumler, I didn't have any problems with Struts and
StrutsTestCase when I switched to Cobertura. I could post more of my
build.xml if you'd like, but I don't know that it would be much help...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Directory deleting weirdness
Hi Vincent, Thanks for responding. Right now it isn't totally critical that I have that directory, so I'll raise that point to in the Cargo list and wait and see what happens. Personally I don't really like the fact that our app copies this folder straight into the webapps directory, but I didn't write it that way. Maybe I can convince the person who did that it should be changed:-). Not likely though. I'm at the bottom of our short hierarchy, so my input is sometimes ignored. Time for a new job, maybe... Thanks for your help! --David Turley Vincent Massol wrote: Hi David, -Original Message- From: David Turley [mailto:[EMAIL PROTECTED] Sent: lundi 22 août 2005 20:17 To: Cactus Users List Subject: Directory deleting weirdness Hello all, My application relies on a directory we put into the TOMCAT_HOME/webapps folder. When the cactus ant task creates the temporary installation of tomcat5x, that directory is, of course, not included. So I decided that I would copy the folder into the temp directory. If I copy it manually, it works just fine, but if I copy it using the ant task, the task deletes the directory I just copied... Can anyone explain this little anomaly or how I can overcome it? The directory created by Cactus is under Cactus Ant tasks control and you should not tamper with it. The Cactus Ant task will delete it every time you run a container. There's currently no way to tell the Cactus Ant tasks to also copy a directory. Your best bet ATM is not to use the Ant task or to use it with a container. You could also try using the . All of this will required more work from you unfortunately. You should also know that Cactus is currently undergoing a refactoring in that it is migrating to Cargo (http://cargo.codehaus.org). So all container-related features of Cactus will be removed and will be handled by Cargo in the next version of Cactus. Your use case is currently not taken into account by Cargo and you may want to raise to the Cargo user list to that it is included in the future. Thanks -Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Directory deleting weirdness
Hello all, My application relies on a directory we put into the TOMCAT_HOME/webapps folder. When the cactus ant task creates the temporary installation of tomcat5x, that directory is, of course, not included. So I decided that I would copy the folder into the temp directory. If I copy it manually, it works just fine, but if I copy it using the ant task, the task deletes the directory I just copied... Can anyone explain this little anomaly or how I can overcome it? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Code Coverage and Cactus
Thank you very much for your help. I think I've got it working now! Thanks again, David Turley Quentin Pouplard wrote: Hi David, David Turley wrote: I think I see the problem now, but I still need some help with fixing it. I also run some regular junit tests, so the coverage information for those tests has been going into the jcoverage.ser file created by the instrumenation phase, but the cactus task is trying to put its coverage information into that file as well. How do I create a second jcoverage.ser file and put my cactus coverage information into it? I think that would solve my problem. That's not an issue, after instrumentation you have one jcoverage.ser (empty), you can copy it where you need it (in the classes directory of your war and in the folder containing your instrumented classes used to run junit test). After that there is a merge task (that comes with jcoverage) that you can use to create one jcoverage.ser file. I just add to merge them to a temporary file then copy it to the working dir (because the report task doesn't seem to allow custom jcoverage.ser file location). I hope this will help. Regards, Quentin ps: by the way, jcoverage.ser file just looks like a serialized hashmap, there is no magic here! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Code Coverage and Cactus
I think I see the problem now, but I still need some help with fixing it. I also run some regular junit tests, so the coverage information for those tests has been going into the jcoverage.ser file created by the instrumenation phase, but the cactus task is trying to put its coverage information into that file as well. How do I create a second jcoverage.ser file and put my cactus coverage information into it? I think that would solve my problem. Thanks, David Turley Quentin Pouplard wrote: Hi David, David Turley wrote: Oh, I noticed you said that you merge all the jcoverage.ser files... I only get one jcoverage.ser file. How do you get more than one and where are they located? I don't have the detail right now, I will look at it tomorrow, but the first thing I wonder is when exactly do you include the generated jcoverage.ser file in your war? I take some time to realize how jcoverage works but the main idea is that instrumenting does the following task: - instrument the code to add code to feed jcoverage.ser file - generate an empty jcoverage.ser file containing counter initialized to zero. I have more than one jcoverage.ser file because I run both cactus test and "classic" unit test, so I have the jcoverage on the tomcat side and the one on the client side, I merge them to get a single report showing me the global coverage for my tests. Hope it will help, Quentin Pouplard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Code Coverage and Cactus
Oh, I noticed you said that you merge all the jcoverage.ser files... I only get one jcoverage.ser file. How do you get more than one and where are they located? Quentin Pouplard wrote: David Turley wrote: Has anyone had any success with jcoverage or emma with cactus? We successfuly run jcoverage with cactus, basically our ant script does the following: - instrument the classes - make a war with instrumented classes - launch cactus test with this war - collect all the jcoverage.ser file - merge them and create the report It works for us. We use tomcat as server and nothing special. Maybe if you could give us more info, I would be able (or anyone else) to help more. Best regards, Quentin Pouplard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Code Coverage and Cactus
Here are the parts of my build.xml I think are relevant:
excludes="WEB-INF/,SESSIONS.ser,**/*.iml" />
includes="**/*.class,**/*.properties" />
destfile="${dist.home}/${app.name}.war">
includes="**/*CactusTest.class"/>
includes="**/*CactusTest.class"/>
Here's the process, and it's virtually identical to yours. I initialize
some directories, compile my classes, instrument them, make my war with
the instrumented classes, launch cactus with that war. That's when I
check the jcoverage.ser file in an editor. Most of the time the file
exists but is empty, but occasionally it stuff in it and everything is
fine and dandy... It's when it's empty that I get an EOFException in
the reports phase... I have run the exact same thing twice in a row and
the first time everything would work and the next time it doesn't. Do
you see anything in there that would cause this kind of behavior?
Quentin Pouplard wrote:
David Turley wrote:
Has anyone had any success with jcoverage or emma with cactus
We successfuly run jcoverage with cactus, basically our ant script does
the following: - instrument the classes - make a war with instrumented
classes - launch cactus test with this war - collect all the
jcoverage.ser file - merge them and create the report
It works for us. We use tomcat as server and nothing special.
Maybe if you could give us more info, I would be able (or anyone else)
to help more.
Best regards,
Quentin Pouplard
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Code Coverage and Cactus
Hello everyone, I am trying to get code coverage to work with my cactus tests, but I'm having trouble. I tried JCoverage (gpl version, of course) first and followed the instructions in another thread, but it seemed to be fairly sporadic. It would work one run and fail the next with absolutely no change made. I have no idea why. So then I decided to give Emma a try. Unfortunately when it tries to dump the coverage information after the cactus tests, I get java.lang.ThreadDeath... Apparently the thread is dying before emma can dump the data. There's a new ant task for emma that allows you to dump whenever you want. I was hoping to use that before cactus shut tomcat5 down again, but the cactus task doesn't allow me to nest the emma task... Is there a way to execute that emma task before cactus shuts tomcat down? Has anyone had any success with jcoverage or emma with cactus? Thanks, David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ServletRedirector context
Pedro, Thanks for the suggestion. That will help a lot with some of the other issues I'm having. It turns out that the problem was with my server.xml. I shouldn't really say it's "my" server.xml because someone else wrote it, hence the problem, but I should have caught it much earlier. They set the context docBase to a full path instead of a relative path, so it wasn't using the temp directory created by the cactus task. The context.xml suggestion will be very helpful because most of my coworkers use Windows and I use Linux, so everything is in different places. Thanks again for your help! --David Pedro Nevado wrote: David, I do not use server.xml for my datasource connection: you can define it in a context.xml file (ROOT.xml, p.e); so you do not need to change your server.xml, or work with an ad-hoc server.xml, either. The URL I use for see test results in my browser is something like: http://localhost:8080/mycontext/ServletTestRunner?suite=com.myclassactiontes t. In case you may find it useful, this is my ant script: At least one test failed after making report! -Mensaje original- De: David Turley [mailto:[EMAIL PROTECTED] Enviado el: martes, 16 de agosto de 2005 16:33 Para: Cactus Users List Asunto: Re: ServletRedirector context Update: In the cactus ant task, I was specifying a server.xml file instead of using the default. I did this because if I don't, I get the following complaint: [cactus] java.lang.RuntimeException: Exception looking up data source: Name jdbc is not bound in this Context But then the test redirectors initialize correctly and everything. It's as if I have a choice between my jdbc connection and the test redirectors working. What do I need to do to get both to work? By the way, where is the "default" server.xml located? The server.xml I specify is in TOMCAT_HOME/conf/... At first I thought that would be the default, but apparently not. Once again, any help on this would be appreciated. The lack of help thusfar has been discouraging, but I understand that you all have your own lives and your own projects and don't give a rats behind about my project ;-). Thanks, David David Turley wrote: Correction: "I have tried to browse to that location and I get 404'd. If I browse to http://localhost:8081/app/ServletRedirector?Cactus_Service=RUN_TEST, however, I get a blank page. " I meant when I browse to http://localhost:8081/ServletRedirector?Cactus_Service=RUN_TEST, which lacks the /app, which is the context my application runs under. David Turley wrote: More information about the problem: When trying to run the ant cactus task with ant debug mode on, after the Tomcat starts up, I get the following repeatedly until it times out. [cactus] Checking if server is up ... [cactus] Failed to connect to [http://localhost:8081/app/ServletRedirector?Cactus_Service=RUN_TEST] (Connection refused) Then I get the timeout message: Failed to start the container after more than [18] ms. Trying to connect to the [http://localhost:8081/app/ServletRedirector?Cactus_Service=RUN_TEST] test URL yielded a [-1] error code. Please run in debug mode for more details about the error. I have tried to browse to that location and I get 404'd. If I browse to http://localhost:8081/app/ServletRedirector?Cactus_Service=RUN_TEST, however, I get a blank page. I turned on cactus logging but didn't see anything new about the error. Anyone have any clues for me? Do you need more information to help me? Let me know. Thanks, David Turley - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --
Re: ServletRedirector context
Update: In the cactus ant task, I was specifying a server.xml file instead of using the default. I did this because if I don't, I get the following complaint: [cactus] java.lang.RuntimeException: Exception looking up data source: Name jdbc is not bound in this Context But then the test redirectors initialize correctly and everything. It's as if I have a choice between my jdbc connection and the test redirectors working. What do I need to do to get both to work? By the way, where is the "default" server.xml located? The server.xml I specify is in TOMCAT_HOME/conf/... At first I thought that would be the default, but apparently not. Once again, any help on this would be appreciated. The lack of help thusfar has been discouraging, but I understand that you all have your own lives and your own projects and don't give a rats behind about my project ;-). Thanks, David David Turley wrote: Correction: "I have tried to browse to that location and I get 404'd. If I browse to http://localhost:8081/app/ServletRedirector?Cactus_Service=RUN_TEST, however, I get a blank page. " I meant when I browse to http://localhost:8081/ServletRedirector?Cactus_Service=RUN_TEST, which lacks the /app, which is the context my application runs under. David Turley wrote: More information about the problem: When trying to run the ant cactus task with ant debug mode on, after the Tomcat starts up, I get the following repeatedly until it times out. [cactus] Checking if server is up ... [cactus] Failed to connect to [http://localhost:8081/app/ServletRedirector?Cactus_Service=RUN_TEST] (Connection refused) Then I get the timeout message: Failed to start the container after more than [18] ms. Trying to connect to the [http://localhost:8081/app/ServletRedirector?Cactus_Service=RUN_TEST] test URL yielded a [-1] error code. Please run in debug mode for more details about the error. I have tried to browse to that location and I get 404'd. If I browse to http://localhost:8081/app/ServletRedirector?Cactus_Service=RUN_TEST, however, I get a blank page. I turned on cactus logging but didn't see anything new about the error. Anyone have any clues for me? Do you need more information to help me? Let me know. Thanks, David Turley - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ServletRedirector context
Correction: "I have tried to browse to that location and I get 404'd. If I browse to http://localhost:8081/app/ServletRedirector?Cactus_Service=RUN_TEST, however, I get a blank page. " I meant when I browse to http://localhost:8081/ServletRedirector?Cactus_Service=RUN_TEST, which lacks the /app, which is the context my application runs under. David Turley wrote: More information about the problem: When trying to run the ant cactus task with ant debug mode on, after the Tomcat starts up, I get the following repeatedly until it times out. [cactus] Checking if server is up ... [cactus] Failed to connect to [http://localhost:8081/app/ServletRedirector?Cactus_Service=RUN_TEST] (Connection refused) Then I get the timeout message: Failed to start the container after more than [18] ms. Trying to connect to the [http://localhost:8081/app/ServletRedirector?Cactus_Service=RUN_TEST] test URL yielded a [-1] error code. Please run in debug mode for more details about the error. I have tried to browse to that location and I get 404'd. If I browse to http://localhost:8081/app/ServletRedirector?Cactus_Service=RUN_TEST, however, I get a blank page. I turned on cactus logging but didn't see anything new about the error. Anyone have any clues for me? Do you need more information to help me? Let me know. Thanks, David Turley - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ServletRedirector context
More information about the problem: When trying to run the ant cactus task with ant debug mode on, after the Tomcat starts up, I get the following repeatedly until it times out. [cactus] Checking if server is up ... [cactus] Failed to connect to [http://localhost:8081/app/ServletRedirector?Cactus_Service=RUN_TEST] (Connection refused) Then I get the timeout message: Failed to start the container after more than [18] ms. Trying to connect to the [http://localhost:8081/app/ServletRedirector?Cactus_Service=RUN_TEST] test URL yielded a [-1] error code. Please run in debug mode for more details about the error. I have tried to browse to that location and I get 404'd. If I browse to http://localhost:8081/app/ServletRedirector?Cactus_Service=RUN_TEST, however, I get a blank page. I turned on cactus logging but didn't see anything new about the error. Anyone have any clues for me? Do you need more information to help me? Let me know. Thanks, David Turley - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ServletRedirector context
My cactus.contextURL is set to /app, but for some reason the servlet redirector is being mapped to /ServletRedirector . So when I run the Ant Cactus task, it tries to find it at /app/ServletRedirector, but it isn't there. I tried putting the servletredirector tag into the cactifywar task and setting the mapping to /app/ServletRedirector, but then the cactus task looked for it at /app/app/ServletRedirector. I guess I'm just missing something. Any help would be appreciated. Thanks, David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Cactus Ant container server parameter
According to the current Ant Integration documentation, it is possible to run cactus tests for a war that has been deployed to a remote server using the server parameter in your containerset, as in Apparently this functionality is not available in version 1.7, and the documentation is for 1.8dev. When can I expect 1.8 to be released? Can I get a development build that has this functionality? Speaking of which, I can't seem to find a "nightly" build any later than November of last year... Is there a way to get a current nightly build? --David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
