Hi,

I am having problems deploying an EAR file that contains a nested WAR
file in JBoss. The nested WAR file uses Stripes. I tried this with
stripes-1.5.2 and stripes-1.5.3 against jboss-4.2.2-GA and
jboss-4.2.3.GA. The folder structure of my minimalistic test EAR looks
like this:

StripesInEar.ear/
StripesInEar.ear/net
StripesInEar.ear/net/nigmann
StripesInEar.ear/net/nigmann/foo
StripesInEar.ear/net/nigmann/foo/SomeSharedClass.class
StripesInEar.ear/net/nigmann/foo/bar
StripesInEar.ear/net/nigmann/foo/baz
StripesInEar.ear/StripesInEar.war
StripesInEar.ear/StripesInEar.war/WEB-INF
StripesInEar.ear/StripesInEar.war/WEB-INF/lib
StripesInEar.ear/StripesInEar.war/WEB-INF/lib/commons-logging-1.1.1.jar
StripesInEar.ear/StripesInEar.war/WEB-INF/lib/cos.jar
StripesInEar.ear/StripesInEar.war/WEB-INF/lib/stripes.jar
StripesInEar.ear/StripesInEar.war/WEB-INF/web.xml
StripesInEar.ear/StripesInEar.war/WEB-INF/classes
StripesInEar.ear/StripesInEar.war/WEB-INF/classes/net
StripesInEar.ear/StripesInEar.war/WEB-INF/classes/net/nigmann
StripesInEar.ear/StripesInEar.war/WEB-INF/classes/net/nigmann/foo
StripesInEar.ear/StripesInEar.war/WEB-INF/classes/net/nigmann/foo/bar
StripesInEar.ear/StripesInEar.war/WEB-INF/classes/net/nigmann/foo/bar/www
StripesInEar.ear/StripesInEar.war/WEB-INF/classes/net/nigmann/foo/bar/www/FooBarActionBean.class
StripesInEar.ear/StripesInEar.war/WEB-INF/classes/net/nigmann/foo/baz
StripesInEar.ear/StripesInEar.war/WEB-INF/classes/net/nigmann/foo/baz/www
StripesInEar.ear/StripesInEar.war/WEB-INF/classes/net/nigmann/foo/baz/www/FooBazActionBean.class
StripesInEar.ear/META-INF
StripesInEar.ear/META-INF/application.xml

Since there are several packages that contain Stripes action beans, I
defined the 'ActionResolver.Packages' init parameter as
'net.nigmann.foo' instead of listing every sub-package ('bar' and
'baz') separately.

When the application gets deployed in this "open" or flat structure,
everything works perfectly fine. Stripes picks up the action beans in
WEB-INF/classes  and the application works.

However, when the application gets deployed as a single EAR file that
contains a single WAR file, ResolverUtil.java chokes. The contents of
the EAR file, StripesInEar.war, look like this:

./META-INF
./META-INF/MANIFEST.MF
./META-INF/application.xml
./net
./net/nigmann
./net/nigmann/foo
./net/nigmann/foo/bar
./net/nigmann/foo/baz
./net/nigmann/foo/SomeSharedClass.class
./StripesInEar.war


When deploying this single file with the above contents, the
ResolverUtil is throwing an un-caught NullPointerException when
looking at the resources of the EAR itself, which aborts the
deployment. I was able to narrow it down to line 282 of
ResolverUtil.java. The call to 'url.openStream()' succeeds, the
BufferedReader in the next line gets created, but the call to 'read()'
on the BufferedReader fails.

As long as the action beans live in WEB-INF/classes, simply catching
and ignoring that NullPointerException fixed the problem. The
exception is thrown while trying to locate the packages from the
(outer) EAR itself. After that, it goes into the packages stored in
WEB-INF/classes and successfully loads and maps my Stripes action
beans.

Has anyone seen this before? Am I doing something wrong or does the
ResolverUtil.java need a look-over? I have this little sample
application in a 1 MB tarball that contains the files above, sources,
deployment log snippets, an ant script and a Readme.txt with more
details, if anyone would like to take a look:
http://www.nigmann.net/StripesInEar.tgz

Thank you.

Bernd.

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Stripes-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-users

Reply via email to