Re: Cactus-Ant Integration: Context startup failed due to Error filterStart
=true/
batchtest
fileset dir=${src.cactus.dir}
include name=**/Test*.java/
exclude name=**/Test*All.java/
/fileset
/batchtest
/cactus
!-- Generate the JUnit Reports --
mkdir dir=${target.report}/html /
junitreport todir=${target.testreports}
fileset dir=${target.testreports}
includes=TEST-*.xml/
report todir=${target.testreports}/html
format=frames/
/junitreport
/target
I am using
ANT: apache-ant-1.6.5
JAVA: jdk1.5.0_06
CACTUS : jakarta-cactus-13-1.7.2
TOMCAT: jakarta-tomcat 5.5
Thank you for your help!
_
Express yourself instantly with MSN Messenger! Download today - it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
-
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]
Re: CactifyWarTask cannot be found
On Fri, 7 Jul 2006, Mohsen Saboorian wrote:
Hi,
I've just downloaded the 1.7.2 releases for both J2EE version 1.2 and 1.3,
and went into samples/servlet and ran 'ant'.
It worked fine.
My ant version is Apache Ant version 1.6.2 compiled on July 16 2004
Can you add the following to line 152 of the build.xml (for the 1.2
version) - just before the taskdef?
property name=debug.cactus.classpath refid=cactus.classpath/
echoCactus Classpath: ${debug.cactus.classpath}/echo
The output I get is:
[echo] Cactus Classpath:
/var/tmp2/jakarta-cactus-12-1.7.2/lib/servletapi-2.2.jar:/var/tmp2/jakarta-cactus-12-1.7.2/lib/aspectjrt
-1.2.1.jar:/var/tmp2/jakarta-cactus-12-1.7.2/lib/cactus-1.7.2.jar:/var/tmp2/jakarta-cactus-12-1.7.2/lib/cactus-ant-1.7.2.jar:/var/tmp2
/jakarta-cactus-12-1.7.2/lib/cargo-0.5.jar:/var/tmp2/jakarta-cactus-12-1.7.2/lib/commons-httpclient-2.0.2.jar:/var/tmp2/jakarta-cactus
-12-1.7.2/lib/commons-logging-1.0.4.jar:/var/tmp2/jakarta-cactus-12-1.7.2/lib/junit-3.8.1.jar
Maybe you see some discrepancies here..
-- Kenney
Hi,
I'm really confused with a problem with the cactifization ant task.
I've followed with previous related subjects here, but none of them
had my answer.
I'm using Cactus 1.7.2. there is a servlet sample inside the binary
dist. when I try to run the ant task, it gives me:
taskdef A class needed by class
org.apache.cactus.integration.ant.CactifyWarTask cannot be found:
org/codehaus/cargo/module/webapp/WarArchive
I'm sure that cargo.jar is in the class path since there is a path
defined in the build.xml:
path id=cactus.classpath
path refid=project.classpath/
pathelement location=${aspectjrt.jar}/
pathelement location=${cactus.jar}/
pathelement location=${cactus.ant.jar}/
pathelement location=${cargo.jar}/
pathelement location=${commons.httpclient.jar}/
pathelement location=${commons.logging.jar}/
pathelement location=${junit.jar}/
/path
also ${carg.jar} points to a correct location.
here is the line which gives me error:
taskdef resource=cactus.tasks classpathref=cactus.classpath/
What is the problem?
-
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]
Re: ServletRedirector: java.lang.NoClassDefFoundError: org.aspectj.lang.Signature
) 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:421) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run( RemoteTestRunner.java:305) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main( RemoteTestRunner.java:186) Any help would be appreciated -- 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]
RE: PLAIN SIMPLE JSP TESTING
On Sun, 14 May 2006, Vincent Massol wrote: Cactus is meant to execute JUnit tests in a J2EE container. JSP Pages are not unit tests. True although Cactus can also perform tests of JSP because it has the ability to change the server-side objects used by the JSPs. See http://jakarta.apache.org/cactus/writing/howto_jsp.html. Indeed - my reply was a bit too short and gave the wrong impression. I apologize. Lucky for me I wasn't entirely wrong - you still need to write a unit test to test a JSP page :) [snip] -- Kenney - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: problem getting test results
On Wed, 1 Mar 2006, Paulo R C Siqueira wrote: Do you have the log for the server side? The internal server error there should give you more information about what went wrong on the server (a NullPointerException usually gives a status 500...) -- Kenney Hi Kazuhito, Thanks again for the answer! :) I tried to run the test with junit.textui.TestRunner. The result was exactly the same... That exception was raised on the server side and an Internal Server Error on the client side. This is the error on the client side: org.apache.cactus.util.ChainedRuntimeException: Failed to get the test results at [http://127.0.0.1:8080/myapp/ServletRedirectorSecure] at org.apache.cactus.internal.client.connector.http.DefaultHttpClient.doTest_aroundBody0(DefaultHttpClient.java:92) 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) org.apache.cactus.internal.client.ParsingException: Not a valid response [500 Internal Server Error] at org.apache.cactus.internal.client.connector.http.DefaultHttpClient.callGetResult(DefaultHttpClient.java:211) at org.apache.cactus.internal.client.connector.http.DefaultHttpClient.doTest_aroundBody0(DefaultHttpClient.java:87) 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) My Environment: Linux kernel 2.4.26 Sun jdk 1.5.0_05_b5 JBoss-4.0.3 Cactus-1.7.1 Any more ideas? :S Thanks again! You might try run test without NetBeans to know whether Cactus works with your target container (JBoss-4.0.3). I had tried following steps last weekend and it worked fine: (1) create cactified-war with a simple test (2) start JBoss (3) deploy the cactified-war file to JBoss manually (4) run test by using junit.textui.TestRunner: java junit.textui.TestRunner My environment is as follows: Linux kernel 2.6.8 Sun jdk 1.5.0_06 JBoss-4.0.3SP1 Cactus-1.7.1 Once you found a working configuration, you can use that for other tests, and can narrow the problem you have encountered. Regards, Kazuhito SUGURI _ Paulo gangrel-br R C Siqueira Sun Certified Programmer for the Java 2 Platform 1.4 Mogi das Cruzes - SP - Brazil Contact: (11) 8149-5046 - Yahoo! Search D� uma espiadinha e saiba tudo sobre o Big Brother Brasil. -- 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]
Re: Changing a property in the context
On Mon, 23 Jan 2006, Javier Gutierrez wrote: Hi, Hello. I am trying to change a context property for the unit test of a Servel. First, I wrote next code: Servel = servlet? ServletContextWrapper context = (ServletContextWrapper ^^^ ) config.getServletContext(); context.setInitParameter (dataconexion, tralalala); However, when initiating my Servlet with: myServlet.init (config); ^^ context != config.. what is config? dit you set the parameter there? The property was unchanged. Looking at the code of AbstractServletConfigWrapper I have found that it return a new copy of the context when calling getServletContext(), so my change is not stored in the configuration. That might be, but that's not what's causing this. is there any way to change a property of the context ? Yup, you did it right. However, you are probably reading the value from the ServletCONFIG object, not the ServletCONTEXT object, and you didn't set it there.. Hope this helps! -- Kenney How can I do it? Thank you very much. __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com - 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]
Re: execution errors
On Wed, 11 Jan 2006, Laurent Morvillier wrote:
Hi,
Do you have any files/directories in c:\projects\cactus_results\?
In particular, any TEST-*.xml files? What's the content?
I think that in both cases you'll end up with
c:\projects\cactus_results\TEST-com.reuters.kgl.test.player.TestScenario.xml
telling you about why the test has failed. Can you post the contents
of that file, if it exists?
Where does the target.testreports.dir property come from? Do you use it
somewhere else too (cactus.properties or something?)
-- Kenney
Hi
I am currently trying to run my cactus tests on Weblogic using the ant
tasks:
cactus
earfile=${app.build.dir}/kgr_laumorvi_cactussified.ear fork=yes
failureproperty=tests.failed
classpath
path refid=cactus.classpath/
pathelement location=${httpunit.jar}/
pathelement location=${nekohtml.jar}/
pathelement
location=${app.cactus.classbindir}/
/classpath
containerset timeout=3
weblogic7x if=cactus.home.weblogic7x
dir=${cactus.home.weblogic7x}
todir=${target.testreports.dir}/weblogic7x
server=${server.url} port=${cactus.port}
output=${target.testreports.dir}/weblogic7x.out
configXml=${weblogic.configxml}/
/containerset
formatter type=xml/
batchtest
fileset dir=${app.cactus.src}
include name=**/Test*.java/
/fileset
/batchtest
/cactus
Here is what I get when I try to run the batchtest specifying the todir
attribute in the weblogic7x tag:
[cactuswar] Building war:
C:\Work\KGL\KGL_ClientFW\cactus406579718cactus.war
[cactuswar] Warning: selected war files include a WEB-INF/web.xml which
will be ignored (please use webxml attribute to war task)
[cactifyear] Building ear:
C:\Work\KGL\KGL_ClientFW\build\kgr_laumorvi_cactussified.ear
[cactus]
-
[cactus] Running tests against WebLogic 7.x @
http://ptxsknetdev02:7050
[cactus]
-
[cactus] java.io.FileNotFoundException:
C:\Projects\cactus_results\weblogic7x\TEST-com.reuters.kgl.test.player.T
estScenario.xml (The system cannot
find the path specified)
[cactus] TEST com.reuters.kgl.test.player.TestScenario FAILED
Here is what I get when I remove this attribute:
[cactuswar] Building war:
C:\Work\KGL\KGL_ClientFW\cactus406579718cactus.war
[cactuswar] Warning: selected war files include a WEB-INF/web.xml which
will be ignored (please use webxml attribute to war task)
[cactifyear] Building ear:
C:\Work\KGL\KGL_ClientFW\build\kgr_laumorvi_cactussified.ear
[cactus]
-
[cactus] Running tests against WebLogic 7.x @
http://ptxsknetdev02:7050
[cactus]
-
[cactus] log4j:WARN No appenders could be found for logger
(org.apache.cactus.internal.configuration.ConfigurationInitializer).
[cactus] log4j:WARN Please initialize the log4j system properly.
[cactus] TEST com.reuters.kgl.test.player.TestScenario FAILED
Both solutions fail. I just don't understand why I get both errors.
I tried with or without the configXml attribute and both results does
not change.
I use WebLogic Server 8.1 SP4 and I already succeeded in running the
test manually so the problem is not here.
Thanks a lot for your precious help.
Laurent MORVILLIER
To find out more about Reuters visit www.about.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.
--
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]
Re: Remote testing with Cactus
On Tue, 8 Nov 2005, Sam Smith wrote: I'm not too experienced, but here's how I think it works: - you create a 'cactified' ear or war on the client machine - deploy that to the server (j2ee or servlet container). The server will now deploy the .war (inside the .ear or separate) and make it available via HTTP (http://servername:port/webapp-context/). It contains a jsp or servlet provided by cactus that can run tests in the server. - locally run the cactus ant task. It connects to the remote machine using HTTP, sends some commands to the special servlet/jsp, and parses the results that servlet/jsp produces. I think this is on the site, btw. -- Kenney What we did was place an Ant script on the remote machine that runs the Cactus tests. The Ant script on the local machine would build everything, place in on the remote machine, then telent to the remote machine and run the Ant script that runs the Cactus tests. That's one way to do it anyway...if there isn't a better way. Sam On 11/8/05, Shay Thompson [EMAIL PROTECTED] wrote: I can see where to specify the url, but am I missing the hostname? The cactus task seems to be for local use only. Kenney Westerhof wrote: On Mon, 7 Nov 2005, Shay Thompson wrote: Isn't that just a matter of specifying the hostname/url to the cactus task? -- Kenney I'm trying to setup some tests so that I can run them on remote machines but I'm not sure how to do this with Cactus. Here's the process I want. 1. Compile and package my tests into a war 2. Deploy the war onto JBoss 3. Use the Ant cactus task to call my tests and have them run on JBoss 4. Get the results This works great when run on the local machine, but I'd like to be able to do step 3 on a remote machine. Is there some instructions somewhere out there on how to do this? I couldn't find anything usefull. Steps 1 2 I can handle, it's just step 3 I don't know about. Thanks, Shay -- ... hey, it works on my machine. Shay Thompson - Lead Computer Scientist Adobe Systems, Inc. - Bedrock QE Team Voice: x34728 or 612.251.5415 - 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] -- ... hey, it works on my machine. Shay Thompson - Lead Computer Scientist Adobe Systems, Inc. - Bedrock QE Team Voice: x34728 or 612.251.5415 -- 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]
Re: Cactus/Maven problem
On Tue, 25 Oct 2005, Lewis, Lonnie R wrote: Hi, A ChainedRuntimeException is typically thrown from Ant, IIRC, which indicates a client side problem - it probably can't connect or something. Have you tried running the tests without maven? Maybe you can run with -X and see more of the stacktrace - it should mention the reason. Also, files ending up in the WAR that you didn't specify (you did a maven clean:clean?) are probably the result of the cactifyEar ant task. But logging.properties files on the server might just not help you since this seems to be a client side problem. Hope this helps a bit - maybe you can post the stacktrace here? -- Kenney First post, please be kind :-). I'm running Cactus under Maven. I'm getting the common [cactus] org.apache.cactus.util.ChainedRuntimeException: Failed to get the test results at [http://localhost:8080/MyApp-cactus/test/filterRedirector.jsp]; error. Reading other postings, I'm trying to solve it by getting the logging set up properly (I'm getting the also common [cactus] log4j:WARN Please initialize the log4j system properly. message). So I'm trying to get the logging_server.properties and logging_client.properties files put in the right place. I can't seem to get this to work right; the changes I put in these property files didn't seem to fixed the logging problem (could be I'm just not putting the files in the right place). So, I checked the generated WAR file (MyApp.war); my properties files are in there. Strangely, when I checked the generated cactus war file (MyApp-cactus.war) they are there in addition to another set of logging_server.properties and logging_client.properties files. If I look at extra set, they appear to be a default implementation; all loggers commented out. These may be files I created a while ago, but they no longer exist on my hard drive (I deleted them long ago). Well not if file form anyway, they may exist in some jar, war, ear, or other archive somewhere but I can't find them. I deleted my .maven work area (with the cache and repository directories) and let maven rebuild it. Also strangely, I had another file that I created and later deleted that is still appearing in my WAR files. Many questions here, is this a maven problem or a cactus problem? Is this documented somewhere and I just can't find it (if so, sorry for not RTFMing well enough)? Is there a trick I'm just not getting to getting the logging working so I can track down my real problem? By the way, thanks for all the work you guys put into this product. I (we) really appreciate it. -Lonnie -- 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]
RE: Cactus/Maven problem
On Wed, 26 Oct 2005, Lewis, Lonnie R wrote: Hm. That's odd. From examining the sourcecode, it doesn't handle DTD. (not sure which version you're using). It trims the output and checks if it starts with webresult, but a DOCTYPE declaration is found instead. I can only think of the following two causes: - cactus added support for a DOCTYPE and you're using a newer version of cactus on the server than on the client; - you've got some weird tomcat settings that add DOCTYPE automatically. Btw, if you point your browser at that url (where you get the blank page), and you do 'view source', i think you'll see the webresult tag. Again, I'm not sure what causes this, perhaps some more experienced user/developer can help you with that. -- Kenney Thanks for the reply, Kenney. Running clean:clean as you suggested cleaned up the problem files. Thanks for the tip. Here is the stack trace: [cactus] Testcase: testDoRequiredBrowser took 15.753 sec [cactus]Caused an ERROR [cactus] Failed to get the test results at [http://localhost:8080/MyTest-cactus/test/filterRedirector.jsp] [cactus] org.apache.cactus.util.ChainedRuntimeException: Failed to get the test results at [http://localhost:8080/MyTest-cactus/test/filterRedirector.jsp] [cactus]at org.apache.cactus.internal.client.connector.http.DefaultHttpClient.doTes t_aroundBody0(DefaultHttpClient.java:92) [cactus]at org.apache.cactus.internal.client.connector.http.DefaultHttpClient.doTes t_aroundBody1$advice(DefaultHttpClient.java:288) [cactus]at org.apache.cactus.internal.client.connector.http.DefaultHttpClient.doTes t(DefaultHttpClient.java) [cactus]at org.apache.cactus.internal.client.connector.http.HttpProtocolHandler.run WebTest(HttpProtocolHandler.java:159) [cactus]at org.apache.cactus.internal.client.connector.http.HttpProtocolHandler.run Test_aroundBody0(HttpProtocolHandler.java:80) [cactus]at org.apache.cactus.internal.client.connector.http.HttpProtocolHandler.run Test_aroundBody1$advice(HttpProtocolHandler.java:288) [cactus]at org.apache.cactus.internal.client.connector.http.HttpProtocolHandler.run Test(HttpProtocolHandler.java) [cactus]at org.apache.cactus.internal.client.ClientTestCaseCaller.runTest(ClientTes tCaseCaller.java:144) [cactus]at org.apache.cactus.internal.AbstractCactusTestCase.runBareClient(Abstract CactusTestCase.java:215) [cactus]at org.apache.cactus.internal.AbstractCactusTestCase.runBare(AbstractCactus TestCase.java:133) [cactus] org.apache.cactus.internal.client.ParsingException: Not a valid response. First 100 characters of the reponse: [ [cactus] [cactus] [cactus] [cactus] [cactus] [cactus] [cactus] [cactus] [cactus] [cactus] !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN http://www.w3.org] From what I've read, I agree that the problem is connecting to Tomcat. I also get this error in the sysout: [cactus] - [cactus] Running tests against Tomcat 5.0.28 @ http://localhost:8080 [cactus] - [cactus] [VERBOSE] Starting up container [cactus] [DEBUG] Finding class org.apache.cactus.integration.ant.container.ContainerRunner [cactus] [DEBUG] Class org.apache.cactus.integration.ant.container.ContainerRunner loaded from ant loader [cactus] [DEBUG] Class java.net.HttpURLConnection loaded from parent loader [cactus] [DEBUG] Class java.lang.Runnable loaded from parent loader [cactus] [DEBUG] Class java.lang.InterruptedException loaded from parent loader [cactus] [DEBUG] Failed to connect to [http://localhost:8080/MyTest-cactus/ServletRedirector?Cactus_Service=RU N_TEST] (Connection refused: connect) As these test are running, I can bring up a browser and enter in the URL: http://localhost:8080/MyTest-cactus/ServletRedirector?Cactus_Service=RUN _TEST I get a blank page, but no error. I have also tried: http://localhost:8080/ MyTest-cactus/test/filterRedirector.jsp I also get a response, but it is an error containing: Missing service name parameter [Cactus_Service] in HTTP request. I don't know, any ideas? Thanks again. -Lonnie -Original Message- From: Kenney Westerhof [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 26, 2005 3:45 AM To: Cactus Users List Subject: Re: Cactus/Maven problem On Tue, 25 Oct 2005, Lewis, Lonnie R wrote: Hi, A ChainedRuntimeException is typically thrown from Ant, IIRC, which indicates a client side problem - it probably can't connect or something. Have you tried running the tests without maven? Maybe you can run with -X and see more of the stacktrace - it should mention the reason. Also, files ending up in the WAR that you didn't specify (you did a maven clean:clean?) are probably the result
Re: Strage problem with Cactus on Weblogic 8.1 with Cactus being deployed on multiple Ears on the same JVM (Windows NT)
On Mon, 10 Oct 2005, Nader - Sanabel wrote: Hi, Sounds like a bug (either in weblogic or cactus). Which version of cactus are you using? Could you try to make 2 identical ears, only containing one war each, with different web contexts? Perhaps a small war with just one testcase.. And can you tell us if the problem is reproducible that way? If so, can you file a JIRA issue and attach your testcase? (this way we have a very small testcase to reproduce it). Maybe you can also try to test this on another container (like jboss) if you have that lying around, and see wheter it's a cactus issue or a weblogic issue. Thanks! PS: I'm not too experienced with cactus yet, sorry I couldn't be of more help so far - maybe somebody else knows if this is a known issue (checked the archives/JIRA?) -- Kenney Hello, I have two Ears each one has a War module that contains Cactus tests, each war has a distinct war context When only one of the EARs, any one, is deployed tests are found and can be executed, whenever I deploy both of the ears Junit tests becomes accessible only on one of them (the first invoked one after a restart of the server) where as test included in the other war becomes invisble and Cactus reports class not found exception. Strange !!! Your help will be very appreciated Nader Soukouti www.sanabel-solutions.com Sanabel Sarl WTC II Geneva - Switzerland - 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]
Re: More problems: Error finding class ...
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]
Re: More problems: Error finding class ...
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: classpathentry excluding=**/CVS/ kind=src path=src/ classpathentry excluding=**/CVS/ output=web/WEB-INF/test-classes/cactus-classes kind=src path=test/cactus-src/ classpathentry excluding=**/CVS/ 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] -- 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]
