Running A Test Directly From a war File

[sengsational]

I have a test class in the same place as my servlet that I want to run
outside of the web container, but I can't get the command line right
to run the test class.

Inside my war file, it looks like this:

WEB-INF
classes
com.some.myapp
MyServlet.class
MyTest.class


So I changed to the directory that contained the war file and did
this:

C:\myapp\war>java -cp .;myapp.war WEB-INF/classes/
com.some.myapp.MyTest
Exception in thread "main" java.lang.NoClassDefFoundError: WEB-INF/
classes/com/some/myapp/MyTest (wrong name: com/some/myapp/MyTest)

I sort of knew that "WEB-INF/classes/com.some.myapp.MyTest" wasn't
going to work (it actually wasn't my first try). I tried:

java -cp .;myapp.war;WEB-INF/classes com.some.myapp.MyTest

but that came up with the plain NoClassDefFoundError (without the
"wrong name").

Then I tried this:
java -cp .;WEB-INF/classes -jar myapp.war com.some.myapp.MyTest

And got this:
Failed to load Main-Class manifest attribute from myapp.war

So I added:

Main-Class: com.some.myapp.MyTest

to the manifest.mf file repackaged and ran this:

java -cp .;WEB-INF/classes -jar myapp.war

and got a plain NoClassDefFoundError (without the "wrong name").

So the question is...

Can I run MyTest.class if it's packed in a war file like it is (under
WEB-INF/classes)?

--Dale--

 

[Mark Space]

Can I run MyTest.class if it's packed in a war file like it is (under
WEB-INF/classes)?

I don't think so. Running a .jar requires that the MANIFEST.INF file be
configured correctly. However, I think the web container also requires
a correctly configured MANIFEST.INF file, which conflicts with the
needed settings for running from a command line.

I think you could change out the MANIFEST.INF file in the .war file
completely and get it to go, but this may not be terribly practical
either with out some sort of automated process keeping both versions of
the MANIFEST.INF file updated correctly. JUnit might be able to do this
automatically when building with an IDE.

I haven't looked at this in detail, so the above is just speculation.
You should look carefully at your manifest file to determine if it can
be massaged into something that works or not. Good luck.

 

[sengsational]

I don't think so.  Running a .jar requires that the MANIFEST.INF file be
configured correctly.  However, I think the web container also requires
a correctly configured MANIFEST.INF file, which conflicts with the
needed settings for running from a command line.

The "manifest.mf" file didn't have anything important in it. I was
careful with addint to the file (as indicated here:
http://mindprod.com/jgloss/jar.html#MANIFEST). I put a Main-Class:
and a Class-Path: in there, like this:

Class-Path: WEB-INF/classes/ ./ classes/
Main-Class: com.some.myapp.MyTest

Which didn't work. I also took MyTest out of the package and put

Main-Class: MyTest

Which also didn't work.

It's hard to accept that Java "just can't do it". Roedy?

--Dale--
PS: java version "1.6.0_03"

 

[none]

I have a test class in the same place as my servlet that I want to run
outside of the web container, but I can't get the command line right
to run the test class.

Inside my war file, it looks like this:

WEB-INF
classes
com.some.myapp
MyServlet.class
MyTest.class


So I changed to the directory that contained the war file and did
this:

C:\myapp\war>java -cp .;myapp.war WEB-INF/classes/
com.some.myapp.MyTest
Exception in thread "main" java.lang.NoClassDefFoundError: WEB-INF/
classes/com/some/myapp/MyTest (wrong name: com/some/myapp/MyTest)

I sort of knew that "WEB-INF/classes/com.some.myapp.MyTest" wasn't
going to work (it actually wasn't my first try). I tried:

java -cp .;myapp.war;WEB-INF/classes com.some.myapp.MyTest

but that came up with the plain NoClassDefFoundError (without the
"wrong name").

Then I tried this:
java -cp .;WEB-INF/classes -jar myapp.war com.some.myapp.MyTest

And got this:
Failed to load Main-Class manifest attribute from myapp.war

So I added:

Main-Class: com.some.myapp.MyTest

to the manifest.mf file repackaged and ran this:

java -cp .;WEB-INF/classes -jar myapp.war

and got a plain NoClassDefFoundError (without the "wrong name").

So the question is...

Can I run MyTest.class if it's packed in a war file like it is (under
WEB-INF/classes)?

--Dale--
From - Thu

The basic Java Runtime Environment only kons how to load classes from
jar file and not war file. So you can't use war files outside an
Application server (tomcat, jboss and so on).

Main difference between jar and war is the place where classes are
stored: at root in a jar, in WEB-INF/classes in a war.


Does your MyTest tests the MyServlet servlet ?

 

[Lew]

The "manifest.mf" file didn't have anything important in it. I was
careful with addint to the file (as indicated here:
http://mindprod.com/jgloss/jar.html#MANIFEST). I put a Main-Class:
and a Class-Path: in there, like this:

Class-Path: WEB-INF/classes/ ./ classes/
Main-Class: com.some.myapp.MyTest

Which didn't work. I also took MyTest out of the package and put

Main-Class: MyTest

Which also didn't work.

It's hard to accept that Java "just can't do it". Roedy?

--Dale--
PS: java version "1.6.0_03"

Web applications don't and shouldn't have a main() method. Does yours?

Java EE programs depend on a host (pun intended) of services provided by the
servlet container. What are you giving your app to provide those services?

 

[sengsational]

The basic Java Runtime Environment only kons how to load classes from
jar file and not war file. So you can't use war files outside an
Application server (tomcat, jboss and so on).

Main difference between jar and war is the place where classes are
stored: at root in a jar, in WEB-INF/classes in a war.

Does your MyTest tests the MyServlet servlet ?

Thanks for the reply. I agree with the difference you mention.

Most of my web apps do a whole bunch of non-servlet stuff...
The purpose of having it as a web application is so that users
may start and monitor these non-servlet operations. So, no,
the MyTest does not test anything having to do with the
web container.

Web applications don't and shouldn't have a main() method. Does yours?

Java EE programs depend on a host (pun intended) of services provided by the
servlet container. What are you giving your app to provide those services?

Thanks for the reply Lew. My test method does have a main() method,
but of course that goes unused during execution by the web container,
and would only come into play if I could run this from the command
line.

The the test class is (roughly) several variables that normally would
have come from the web page (but I hard coded them), plus a copy of
the code from the doPost method of the "real application", which has
been slightly modified to run outside the web container.

Although you didn't ask directly, I'll also add that my testing
productivity is what I'm trying to manage here... I can test through
the web container fine on my local machine, but when it comes to
deploying and testing on unix servers, it's a slower process to
deploy and test. Once I get everything working perfectly through
the command line, then I can just copy what I have in the test
program over to the servlet and the only thing left to debug would
be getting the inputs from the jsp to the servlet.

--Dale--

 

[Lew]

Although you didn't ask directly, I'll also add that my testing
productivity is what I'm trying to manage here... I can test through
the web container fine on my local machine, but when it comes to
deploying and testing on unix servers, it's a slower process to
deploy and test. Once I get everything working perfectly through
the command line, then I can just copy what I have in the test
program over to the servlet and the only thing left to debug would
be getting the inputs from the jsp to the servlet.

Instead of hacking your code to be different from its production version for
test, how about a Java EE test framework, such as Cactus, which extends JUnit?
<http://jakarta.apache.org/cactus/index.html>

 

[Mark Space]

Instead of hacking your code to be different from its production version
for test, how about a Java EE test framework, such as Cactus, which
extends JUnit?
<http://jakarta.apache.org/cactus/index.html>

Also I think the OP should consider getting VMWare and doing system
testing locally with a local Unix instance. This might be a lot faster
and easier than testing on a remote system. If the OP could develop
some module tests that go between the unit testing and full system test,
he'd have a more robust test suite.