Hello,
I have gotten back to this task after a few weeks doing other things!
I have finally gotten Jetty to come up under Java 1.3 on the mainframe. My application logon page comes up but the JSP does not compile. I tested out the Demo JSP's and they don't compile either. The demo servlets work just fine.
I brought up Jetty on my PC and pointed to the 1.3 JDK and was able to compile the JSP's. When I had the wrong path to the JDK, I was getting similar errors. But, I have checked the java.home & it seems OK.
Would appreciate any help!
Thanks,
Nalini
I am getting errors such as follows:
@16:14:22.562 EVENT Started org.mortbay.jetty.Server@8bc43fc
16:19:00.712 EVENT Error compiling file: /tmp/Jetty__8080__examples/js@p/snp/snoop_jsp.java [javac] Compiling 1 source file
[javac] javac: invalid argument: `ƒ“
JSPs don't compile under Jetty - using Java 1.3
Nalini,
We have tested Jetty with JDK 1.4, but not 1.3 under JZOS.
It sounds like there is some problem in Jetty whereby it is trying to compile the JSPs under the wrong codepage.
Can you refresh my memory as to which version of Jetty that you are running?
One possible alternative would be to precompile your JSPs before deploying the code to the mainframe. This also has the advantange of allowing your application to startup much more quickly.
See: http://jetty.mortbay.org/jetty/faq?s=900-Content&t=JSP
We have tested Jetty with JDK 1.4, but not 1.3 under JZOS.
It sounds like there is some problem in Jetty whereby it is trying to compile the JSPs under the wrong codepage.
Can you refresh my memory as to which version of Jetty that you are running?
One possible alternative would be to precompile your JSPs before deploying the code to the mainframe. This also has the advantange of allowing your application to startup much more quickly.
See: http://jetty.mortbay.org/jetty/faq?s=900-Content&t=JSP
-
Guest
The version of Jetty is Jetty-5.1.2.
I will see about how to do the precompile of the JSP's.
I saw the garbage characters in the javac statement. Hmm. So, it is the Codepage. I played with some of the parameters, but I don't remember how to set codepage. Let me think about that, too.
Thanks -- Nalini
I will see about how to do the precompile of the JSP's.
I saw the garbage characters in the javac statement. Hmm. So, it is the Codepage. I played with some of the parameters, but I don't remember how to set codepage. Let me think about that, too.
Thanks -- Nalini
-
Guest
OK. So, now I have spent all morning trying to get the JSP's to precompile. At least, I have learned a good deal about ANT. Interesting. I can get my source code to compile fine, but not JSP's. I tried Tomcat 5.0 and also Tomcat 4.1 because the Ant doc itself says they have problems with Tomcat 5. Hmm.
But you know what, as I remember from poking around, there is compiled JAVA code in the tomcat work areas which correspond to the JSP's. So, now I just grabbed one of those and tried putting it up in the web-inf/classes for my application. The FAQ you pointed me to appears to say that is where Jetty will look for it. It did not seem to work. Is that the right place to put it?
Thanks,
Nalini
But you know what, as I remember from poking around, there is compiled JAVA code in the tomcat work areas which correspond to the JSP's. So, now I just grabbed one of those and tried putting it up in the web-inf/classes for my application. The FAQ you pointed me to appears to say that is where Jetty will look for it. It did not seem to work. Is that the right place to put it?
Thanks,
Nalini
The output from precompiling the JSPs should be .java source code for a servlet class that corresponds to each jsp. Your build process then compiles these as if they were normal servlet classes. Were you able to get this to work?
The ant task for precompiling will also create a fragment of xml that can be included in your web.xml. This will map each xxx.jsp to the precompiled servlet class. This is how Jetty knows to use the precompiled servlet when a ".jsp" URL is requested.
The ant task for precompiling will also create a fragment of xml that can be included in your web.xml. This will map each xxx.jsp to the precompiled servlet class. This is how Jetty knows to use the precompiled servlet when a ".jsp" URL is requested.
Hello,
I'm not sure if anyone has found any other discoveries while using Jetty.
Well, I have been experimenting with several versions of Jetty from versions 4.2.21 through 5.1.3.
Currently, we’re using the latest build of jetty 4.2.24 (as of April 15,2005) and Java version 1.3.
In order to compile JSP pages, I’ve discovered that depending on the version of Jetty, you may have to create to the following directories in Jetty’s home directory:
work
temp
-- I think, starting with version 4.2.23 of jetty, the work directory is utilized. Also, included (whenever they do exists) in the class path are the following application directories:
WEB-INF\classes
WEB-INF\lib
We also have included the following JVM options:
-Djava.io.tmpdir=${JETTY_HOME}/temp
-Djetty.home=${JETTY_HOME}
Next, within our Server.xml file we’ve included the “all web application”, in order to reference our modified weddefault.xml file.
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<!-- Add a all web application within the webapps directory. -->
<!-- + No virtual host specified -->
<!-- + Look in the webapps directory relative to jetty.home or . -->
<!-- + Use the webdefault.xml resource for the defaults descriptor -->
<!-- + Upack the war file -->
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<Set name="rootWebApp">banklife</Set>
<!-- which means, some other application becomes the root home application at “/” -->
<Call name="addWebApplications">
<Arg></Arg>
<Arg><SystemProperty name="jetty.home" default="."/>/webapps/</Arg>
<Arg><SystemProperty name="jetty.home" default="."/>/etc/webdefault.xml</Arg>
<Arg type="boolean">true</Arg>
</Call>
Within our webdefault.xml file, we are using an alternate java compiler
<servlet>
<servlet-name>jsp</servlet-name>
<servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class>
<init-param>
<param-name>logVerbosityLevel</param-name>
<param-value>DEBUG</param-value>
</init-param>
<init-param>
<param-name>fork</param-name>
<param-value>false</param-value>
</init-param>
<init-param>
<param-name>compiler</param-name>
<param-value>javac1.3</param-value>
</init-param>
<load-on-startup>3</load-on-startup>
</servlet>
Please note, that the javac1.3 is an internal reference to
com.sun.tools.javac.Main - class so that the external "javac" process isn't invoked.
PS.
I have tried using Jetty 5.1.3 on the mainframe, but had problems resolving the following XSD files:
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd
Although, I've been able reference the local versions of the *.dtd files.
However, with this the version of Jetty, the stderr appears to properly use the default codepages.
I'm not sure if anyone has found any other discoveries while using Jetty.
Well, I have been experimenting with several versions of Jetty from versions 4.2.21 through 5.1.3.
Currently, we’re using the latest build of jetty 4.2.24 (as of April 15,2005) and Java version 1.3.
In order to compile JSP pages, I’ve discovered that depending on the version of Jetty, you may have to create to the following directories in Jetty’s home directory:
work
temp
-- I think, starting with version 4.2.23 of jetty, the work directory is utilized. Also, included (whenever they do exists) in the class path are the following application directories:
WEB-INF\classes
WEB-INF\lib
We also have included the following JVM options:
-Djava.io.tmpdir=${JETTY_HOME}/temp
-Djetty.home=${JETTY_HOME}
Next, within our Server.xml file we’ve included the “all web application”, in order to reference our modified weddefault.xml file.
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<!-- Add a all web application within the webapps directory. -->
<!-- + No virtual host specified -->
<!-- + Look in the webapps directory relative to jetty.home or . -->
<!-- + Use the webdefault.xml resource for the defaults descriptor -->
<!-- + Upack the war file -->
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<Set name="rootWebApp">banklife</Set>
<!-- which means, some other application becomes the root home application at “/” -->
<Call name="addWebApplications">
<Arg></Arg>
<Arg><SystemProperty name="jetty.home" default="."/>/webapps/</Arg>
<Arg><SystemProperty name="jetty.home" default="."/>/etc/webdefault.xml</Arg>
<Arg type="boolean">true</Arg>
</Call>
Within our webdefault.xml file, we are using an alternate java compiler
<servlet>
<servlet-name>jsp</servlet-name>
<servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class>
<init-param>
<param-name>logVerbosityLevel</param-name>
<param-value>DEBUG</param-value>
</init-param>
<init-param>
<param-name>fork</param-name>
<param-value>false</param-value>
</init-param>
<init-param>
<param-name>compiler</param-name>
<param-value>javac1.3</param-value>
</init-param>
<load-on-startup>3</load-on-startup>
</servlet>
Please note, that the javac1.3 is an internal reference to
com.sun.tools.javac.Main - class so that the external "javac" process isn't invoked.
PS.
I have tried using Jetty 5.1.3 on the mainframe, but had problems resolving the following XSD files:
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd
Although, I've been able reference the local versions of the *.dtd files.
However, with this the version of Jetty, the stderr appears to properly use the default codepages.
Status Update.
I finally had the chance re-install the latest build (as of April 7) of Jetty 5.1.3
In my opinion, this appears to be cleanest version of Jetty yet. Stderr messages all are coming out OK. Best of all, I’m now able to compile the JSP pages without having to modify the default settings of the webdefault.xml file.
(Though, because of response times, it is still recommended to precompile all the JSP pages in advance. On my Pentium 2/Win 98 machine, it took around 15 seconds, but on the mainframe, the process time was just under 2 minutes.)
The only exception I had to make, while run under JDK 1.3 was include the following system property on startup:
-Dorg.mortbay.util.FileResource.checkAliases=false
(this because I was annoyed by check Alias process on my PC)
I finally had the chance re-install the latest build (as of April 7) of Jetty 5.1.3
In my opinion, this appears to be cleanest version of Jetty yet. Stderr messages all are coming out OK. Best of all, I’m now able to compile the JSP pages without having to modify the default settings of the webdefault.xml file.
(Though, because of response times, it is still recommended to precompile all the JSP pages in advance. On my Pentium 2/Win 98 machine, it took around 15 seconds, but on the mainframe, the process time was just under 2 minutes.)
The only exception I had to make, while run under JDK 1.3 was include the following system property on startup:
-Dorg.mortbay.util.FileResource.checkAliases=false
(this because I was annoyed by check Alias process on my PC)