Tuesday Nov 13, 2007

I Want To See My JSP's Generated Servlet Source!!

It is difficult to see the servlets that get generated from  your JSP files.

If you politely ask NetBeans it will tell you something like "You have to run the file first".  And this is after you run the file!

Anyways once you know how -- it is easy.  Read on...

Background:

When you deploy a web module (or a Web App that has a web module in it) by default it will not compile the jsp's as part of the deployment process.  Instead, the jsp will be compiled "just in time" by the web container the first time the web module is accessed long after deployment completes.

We need to tell the jsp-compiler to keep the generated files instead of deleting them.  This is the "keepgenerated" option to the jsp-compiler.  You set this option by editing the default-web.xml file in the domain's config directory.  Search for "keepgenerated" and you will see the xml that needs editing just below the enormous comment.  It should look like this when you're done editing

   <servlet>
    <servlet-name>jsp</servlet-name>
    <servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class>
    <init-param>
      <param-name>keepgenerated</param-name>
      <param-value>true</param-value>
   
</init-param>
    <load-on-startup>3</load-on-startup>
  </servlet>

You would think that that is enough to get your generated source, but it is not.  The web-container orchestrated jsp compile is either ignoring the keepgenerated option -- or the generated files are well-hidden.

But it will work if you ask the GF Deployment code to do the compiling for you like so:

asadmin deploy --precompilejsp=true some.war

 ALL of your jsp generated servlet source will be located in:

your-domain-dir/generated/jsp/j2ee-modules\\YourModule/org/apache/jsp

___________________________

In summary:

(1) setup the keepgenerated option in default-web.xml and then forget about it

(2) For every deployment use the --precompilejsp=true option


I spent far too much time figuring this out so I am sharing my results here.  

As I was stepping through the deployment source code I thought "Wow, this is pretty nice code".  Then I realized "HEY!  I wrote this code!  It's been about 5 years but there it still is!" 

Monday Jun 11, 2007

Let's Get This Glassfish Party Going!

This is the first chapter in a n-chapter tutorial on how to exploit Glassfish capabilities. I learned long ago that the only way I can really cement into my head a hunk of technology is to just do it. I came up with a useful application for web technology. In this series we will be building an application that will slowly but surely use these areas of javaee. They are in the approximate order that we will tackle in the project.
  • HTTP File downloading (HyperText Transfer Protocol)
  • Servlets
  • JSPs (Java Server Pages)
  • User Authentication - Basic, then File Realms, then JDBC Realms
  • Derby Database
  • JNI (Java Naming Interface)
  • EJB 3.0 (Enterprise Java Beans)
  • JPA (Java Persistence API)
  • EJB Timer Service
  • Struts
  • JSP Tag Libraries
  • MDB (Message Driven Beans)

Chapter 0: The Application Description

Dr. Dean Edell has an interesting radio talk show on KGO radio in San Francisco. His show is from 1 to 2 PM Monday through Friday. KGO posts an mp3 file for the show once a day. KGO takes it down, forever, after 24 hours. KGO does not maintain an archive of old shows. I like to burn the shows onto CDs and listen to them in my car. What this application will do is:
  • Automatically download the mp3 at 11:38 PM every night, Monday through Friday and save them to a subdirectory of docroot on my Glassfish Application Server.
  • Maintain user accounts for people that wish to download the files. New accounts will be accepted and added to the list on demand.
  • The application will persist which files have been downloaded for each user. When a user is authenticated he will see his own custom list of programs he has yet to download.
  • A list of all available programs will also be available in case of trouble (like the dog eating the Dean Edell CDs)

This sounds like a lot of overkill for such modest sounding requirements. But making it 100% automatic is a bit challenging. Besides, the whole point of this is to create an application - any application -- in order to learn how to do all this stuff. We will start simple but thorough and correct. We will constantly change and modify it to use the cutting edge Java EE technology as the tutorial progresses.

Stay Tuned for the next installment, Chapter 1:

Write a stand alone Java application that will download the mp3 file. The OS will be in charge of running this application via a chron/at job.

About

ByronNevins

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today