Bugs item #529931, was opened at 2002-03-14 08:53
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=529931&group_id=22866
Category: CatalinaBundle
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Per Nyfelt (per_nyfelt)
Assigned to: Scott M Stark (starksm)
Summary: Java-Webstart download servlet
Initial Comment:
Using the Java WebStart jnlp-servlet.jar fails on
Jboss 3 (but worked on 2.4.0).
The jnlp-servlet.jar that is used to handle version
request in Java webStart fails because of it's
dependency on getRealPath() to cretae File references
e.g.:
// s == /app/lib
File file = new File(_servletContext.getRealPath(s));
This will faile since getRealPath() returns null
resulting in a nullpointer exception which will make
it impossible to download versioned jars.
The documentation for ServletContext says that
getRealPath will return null if the application is
packaged in a war so maybe this is a problem with the
JBoss deployer?
Here's the stackTrace :
ERROR MESSAGES/STACK TRACES THAT OCCUR :
java.lang.NullPointerException
at java.io.File.<init>(File.java:180)
at
com.sun.javaws.servlet.DownloadRequest.<init>
(DownloadRequest.java:55)
at
com.sun.javaws.servlet.JnlpDownloadServlet.handleReques
t
(JnlpDownloadServlet.java:87)
at
com.sun.javaws.servlet.JnlpDownloadServlet.doGet
(JnlpDownloadServlet.java:79)
at javax.servlet.http.HttpServlet.service
(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service
(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.interna
lDoFilter
(ApplicationFilterChain.java:247)
at
org.apache.catalina.core.ApplicationFilterChain.doFilte
r
(ApplicationFilterChain.java:193)
at
org.apache.catalina.core.StandardWrapperValve.invoke
(StandardWrapperValve.java:243)
at
org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:566)
at
org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:472)
at
org.apache.catalina.core.ContainerBase.invoke
(ContainerBase.java:943)
at
org.apache.catalina.core.StandardContextValve.invoke
(StandardContextValve.java:190)
at
org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:566)
at
org.apache.catalina.valves.CertificatesValve.invoke
(CertificatesValve.java:246)
at
org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:564)
at
org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:472)
at
org.apache.catalina.core.ContainerBase.invoke
(ContainerBase.java:943)
at
org.apache.catalina.core.StandardContext.invoke
(StandardContext.java:2343)
at
org.apache.catalina.core.StandardHostValve.invoke
(StandardHostValve.java:180)
at
org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:566)
at
org.apache.catalina.valves.ErrorDispatcherValve.invoke
(ErrorDispatcherValve.java:170)
at
org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:564)
at
org.apache.catalina.valves.ErrorReportValve.invoke
(ErrorReportValve.java:170)
at
org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:564)
at
org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:472)
at
org.apache.catalina.core.ContainerBase.invoke
(ContainerBase.java:943)
at
org.apache.catalina.core.StandardEngineValve.invoke
(StandardEngineValve.java:174)
at
org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:566)
at
org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:472)
at
org.apache.catalina.core.ContainerBase.invoke
(ContainerBase.java:943)
at
org.apache.catalina.connector.http.HttpProcessor.proces
s
(HttpProcessor.java:1012)
at
org.apache.catalina.connector.http.HttpProcessor.run
(HttpProcessor.java:1107)
at java.lang.Thread.run(Thread.java:484)
----------------------------------------------------------------------
Comment By: Jeff Tulley (jtulley)
Date: 2002-06-07 13:16
Message:
Logged In: YES
user_id=341242
I just encountered this using JetSpeed.war. It looks like the
following call is the culprit, as pointed out above:
(ServletConfig) config.getServletContext().getRealPath("");
This returns null in Tomcat 4.0.3 running under JBoss, but not
for Jetty, or the same Tomcat running standalone. For
JetSpeed, this causes it to not be able to load its
turbine.properties file, and the war does not deploy at all.
It looks like the original submitter is correct - this is a
Tomcat "feature", causing a headache for JBoss, which does
not expand the WAR files before executing them. I expanded
my war file, deploying it that way in JBoss, and got around
this bug, but that is hardly the drag-and-drop deploy that
JBoss normally supports.
Could the Tomcat guys be coerced to fixing this "feature"?
----------------------------------------------------------------------
Comment By: Peter Brumm (pbrumm)
Date: 2002-06-07 08:40
Message:
Logged In: YES
user_id=480744
I have the same problem when I deploy my site.
I have found that it only returns null if I use the tomcat version
of jboss. If I use the jetty version everything works great and I
get a large path to my site.
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=529931&group_id=22866
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -
http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
