Jetty/JBoss? FAQ

How do I deploy a WAR to the '/' context (revised: 02/06/2003)

    You have two choices.

    1. The standard J2EE way - wrap your .war in an .ear and in the .ear's application.xml you can specify the required - Here is the DTD:.application_1_3.dtd

    2. The proprietary JBoss extension - put a jboss-web.xml into your .war's WEB-INF directory and specify the in that. - Here is the DTD: jboss-web_3_0.dtd

    N.B. Standalone Jetty supports a Tomcat-ism. Call the file ROOT.war and deploy this standalone - i.e. without a surrounding ear. (This is CASE-SENSITIVE - careful on Windoze). HOWEVER THIS WILL NOT WORK WITH JBOSS/JETTY. The integration code bypasses this Jetty code and (currently) makes no attempt to replace it. (CHECK THIS).

    Note that a context path specification in a META-INF/application.xml file will take precedence over the WEB-INF/jboss-web.xml specification.

I want my sessions saved while I bounce JBoss - just like Tomcat (revised: 02/06/2003)

I want to disable session tracking via Cookie on Jetty (revised: 02/06/2003)

    To force Jetty not to use a Cookie for this purpose, there is a setUsingCookies method that needs to be called on the WebApplicationHandler object. This can be called from the XML in a WEB-INF/jetty-web.xml file:

 
  false
 


    

So - tell me about Distributable HttpSessions... (revised: 02/06/2003)

    A WebApp may be described as 'distributable' in it's WEB-INF/web.xml.

    The J2EE spec requires that a 'distributable' webapp's sessions may be 'migrated' between nodes of a cluster - i.e. dynamically moved from one webapp instance to another running in a different address space..

    Many AppServers extend this fn-ality from simply allowing explicit migration to providing failover i.e. If one node undergoes a catastrophic failure it's sessions will still be available to other instances of the same WebApp within the cluster. Thus these conversations may be reprised by other nodes with the relevant client.

How do I set up Distributable HttpSession support? (revised: 02/06/2003)

    Ensure that your network allows JavaGroups to multicast as required - see docs on the JavaGroups site. (HINT - JBoss clustering also uses JavaGroups, so if this is working, you are OK).

    Ensure that you are running the 'all' JBoss configuration (run.sh -c all) as 'default' and 'minimal' do not ship with the JavaGroups jar.

    Uncomment the JGStore section (a) in your $JBOSS_HOME/server/all/deploy/jbossweb.sar/META-INF/jboss-service.xml.

    Ensure that you have a tag in the right place in your webapp's WEB-INF/web.xml. Check the DTD.

    Support for distributable functionality is a [deliberately] poorly spec-ed area and as such supported by different vendors in different ways. There will shortly be comprehensive, for-pay documentation about Mort Bay's implementation for Jetty available from this site. Watch this space.

Editing the jboss-service.xml (revised: 02/06/2003)

    (the jbossweb.sar/jetty-plugin.sar was shipped jarred in early 3.0.x releases).

I want to use a Virtual Host (revised: 02/06/2003)

    To define a virtual host, add a line of the following form to your webapp's WEB-INF/jboss-web.xml file. Here is the DTD: jboss-web_3_0.dtd

myvirtualhost

I want to use more than one Virtual Host for a webapp (revised: 02/06/2003)

    Fortunately the proprietary Jetty descriptor (WEB-INF/jetty-web.xml) does - since it is just a thin XML veneer over the Java classes API.

    Try a WEB-INF/jetty-web.xml something like this :

  

  

  

   host1
   host2

  

    

What about JSR77 ? (revised: 06/06/2003)

The integration creates an MBean for each servlet. If you are deploying large numbers of servlets over and over again, in e.g. a development iteration, this can be time-consuming. To disable this feature, set the SupportJSR77 attribute in your jbossweb.sar/META-INF/jboss-service.xml to false.

I want to change where Jetty writes it's temporary files. (revised: 02/06/2003)

I want to change the port that Jetty listens on (revised: 02/06/2003)

    start jboss something like this :

 JAVA_OPTS="-Djetty.port=8085" ./run.sh

    If you are on Windoze, figure out how to pass the above properties into your JVM....

    Or

    edit ..../deploy/jbossweb.sar/META-INF/jboss-service.xml's ConfigurationElement to reflect your needs.

I want to run on 80, not 8080 (revised: 02/06/2003)

I want to run with Apache (revised: 02/06/2003)

    The latest version of the AJP Connector will receive it's jvmRoute attribute from mod_jk (if you are doing sticky load-balancing). It should no longer be set manually via your jboss-service.xml/jetty.xml/jetty-web.xml.

Explain this Java2ClassLoadingCompliance JMX attribute to me (revised: 02/06/2003)

    These different requirements cannot be reconciled and lead to differing behaviours.

    Jetty allows you to choose the strategy you require via this flag.

I want to use SSL (revised: 02/06/2003)

I want to use JAAS (revised: 02/06/2003)

What about Single Sign On (SSO) support ? (revised: 02/06/2003)

OK, I'm up and running, but I get a 404 when I hit 'localhost:8080/' (revised: 02/06/2003)

Everything works fine for a while and then my content suddenly disappears. (revised: 02/06/2003)

    Here is a MacOSX-specific solution:

    Q: JBoss3/Jetty on Mac OS X stops serving JSPs and displays an directory listing instead of my site. What's going on?

    A: On Mac OS X, a file called "/etc/periodic/daily/500.daily" describes how often /tmp files are to be cleaned up. By default, it wipes files after three days.

    If you do not specify a temporary directory explicitly for Jetty/JBoss with the startup parameter "java.io.tmpdir" for Jetty to unpack to, it will default to the temp directory for the system. On Mac OS X, this is "/tmp".

    Modify your JBoss startup script "run.sh" to include a "java.io.tmpdir" system property:

    like so:

 JAVA_OPTS="$JAVA_OPTS -Dprogram.name=$PROGNAME -Djava.io.tmpdir=$JBOSS_HOME/server/default/tmp"
    

    (or wherever you want that is not being wiped clean regularly.)

    Thanks, Damon

Jetty moans about elements in my web.xml not being allowed in this position (revised: 02/06/2003)

    The XML parser is being strict about the ordering of elements (as per spec).

    Look at web-app_2_3.dtd and ensure that the elements in your web.xml appear in exactly the same order.

    You are now assured of MAXIMUM portability for your webapp.

    Or, set the system property : org.mortbay.xml.XmlParser.NotValidating to "true".

Sometimes when I copy apps into .../deploy/ I get "invalid LOC header" errors (revised: 02/06/2003)

java.lang.ClassNotFoundException: org.mortbay.j2ee.session.JGStore - Why ? (revised: 02/06/2003)

    AND

    You have NOT uncommented the JGStore block in .../deploy/jbossweb.sar/META-INF/jboss-service.xml.

    Why is this commented out ?

    ...because it requires JavaGroups, which is only available in the 'all' server configuration.

    So you will need to either 'run.sh -c all' or copy the JavaGroups jar into whichever configuration you are using.

    See this item.

I want to use Jikes to compile my JSPs (revised: 02/06/2003)

JSP Precompilation - What, Why and How ? (revised: 02/06/2003)

    If you include a .jsp in your .war and hit it, Jasper (the JSP engine) will find the JSP, transform it into a .java, compile that into a .class, load and run it, returning the output. The .class file is then cached and reused on subsequent hits.

    This can lead to at least 4 problems.

    1). You might prefer to be notified of compile errors during your development cycle - rather than post deployment.

    2). The first person to hit the page will have to wait a while whilst this process is carried out.

    3). If you are deploying into a heavily loaded site, it is possible that a page may be hit again before the first hit has finished it's on-the-fly preparation. This may result in more than one concurrent attempt at compiling the page, resulting in unecessary load on the server and more than one user waiting a long time for the resource that they have requested.

    4). The more jars JBoss contains/has-deployed, the longer each JSP compilation may take, since to be sure that the JSP is seeing the classes that it expects to find, I have to put every class known to JBoss on the classpath. It looks as if there are related memory and file-descriptor leaks - caveat emptor.

    The way out of all these problems is to PRECOMPILE YOUR JSPs - i.e. Do what Jasper would do lazily, preemptively during your development iteration.

    Doing this results in the further following advantages:

    - your production site may consider the presence of a compiler a security breach. Precompiled JSPs do not need one.

    - dispatch of request to servlet is simpler and therefore quicker since it goes direct from Jetty->Servlet and not Jetty->Jasper->Servlet.

    Here is a mail I sent to jboss-user to help someone who wanted to do this:

    I have just fixed up the JBoss website to precompile JSPs.

    This is a diff showing the code I added to the build.xml and this is a diff showing what I added to the web.xml web.xml

    The comment line in the web.xml MUST be after the last

    JspC will generate some xml and elements which I substitute in at this comment.

    The rest you will have to figure out for yourself - it is well commented.

    You will probably not need some of the workarounds I have had to retrofit.....

    Since adding this item I have found the following :

    1). Throwing a lot of concurrent requests at compile-on-the-fly JSPs can make Jasper simply fall about and complain about files not existing. Remove the load and hit the same page and it is returned no problem - conclusion compile-on-the-fly is simply not an option for enterprise level sites.

    2). The JspC stuff referenced above fails to take into account welcome-files. Jetty will look for a file of the same name (e.g. index.jsp) (so you should make sure something is there - even if it is an empty file) and, if it exists, redirect the request to it. - Of course, you could probably remove the welcome-file directive and map your servlet directly.

    Since writing this item I have discovered a very useful Ant task - xmltask (www.oopsconsultancy.com) which enables you to cut and paste elements between XML files etc. It is particularly useful for reconstituting your web.xml after precompilation.

    There are many reports that Jasper2 does not preserve your JSP directory hierarchy in the resulting package hierarchy - I am awaiting a good solution (there may be a -p option to JspC?). A client of mine has recently sponsored the application of a patch to resolve this issue. It should make it's way into a Tomcat release very soon.

    Giving your include-only JSPs a suffix other than .jsp has been suggested, to avoid having JspC fail to compile them and then generate spurious elements for your web.xml...

    This item needs rationalisation - volunteers ?

Don't delete JSP compilation results between JBoss instances. (revised: 02/06/2003)

 

 
  jsp
   
    scratchdir
    /tmp/TestFAU
   
  
 



    

    (http://groups.yahoo.com/group/jetty-discuss/message/5530)

    This should be put in .war/WEB-INF/jetty-web.xml.

    It effectively hardwires your app to always use the same dir for precompilation. Bouncing JBoss would normally result in the undeploying and redeploying of your webapp, which would clean up all associated working dirs...

    N.B. Some sites run periodic jobs to clean up old files in /tmp - so it might be advisable to choose somewhere else to site this dir...(See this item).

    Thanks, Frode

I'm debugging a JSP and would like to use the Java source generated by Jasper (revised: 02/06/2003)

    session="false"
    

   
    
     
      /documents/*
      /docroot
      
        
      
     
    
   

    

 
  CGI
  org.mortbay.servlet.CGI
  
   cgibinResourceBase
   /home/jules/cgi-bin
  
  
 

 
  CGI
  /*
 

 
  /cgi-bin/*
  /home/jules/www/cgi-bin/
  
   Common Gateway Interface
   /
   org.mortbay.servlet.CGI
   
    /bin:/usr/bin:/usr/local/bin
    
  
 

    

        -Djava.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
        -Djava.naming.provider.url=:
      

        java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
        java.naming.provider.url=:

getClass().getClassLoader()

      Thread.currentThread().getContextClassLoader()