> On Sat, Dec 29, 2007 at 04:32:54PM +0100, Daniel Pocock wrote: >> >>>> I've looked in the Debian Java FAQ (EJB and Servlet sections) and also >>>> the Wiki (link below) and couldn't find an existing answer to this >>>> question. >>>> >>>> http://wiki.debian.org/FileSetsAndLocations >>>> >>>> Also, defining such a directory would probably mean we need to define >>>> some dependencies, such as `j2ee-war-container', and >>>> `j2ee-ejb-container'. These dependencies would be satisfied by >>>> packages >>>> such as Tomcat, and could be used to ensure that two conflicting >>>> containers were not installed. >>>> >>> >>> We dont have such a directory (yet). I wonder if its possible to have >>> some. There are still small differences/incompatibilities between >>> different containers. Sure, there is a small common denominator. But >>> does really worlds applications only use this common denominator? >>> >>> >> There is a saying: `build it and they will come' >> >> In practice, many applications built for one container don't always work >> in >> others. Some vendors focus on two containers rather than just one. >> >> However, if Debian can show a mature approach to this situation, then at >> least some application vendors may consider the portability of their >> applications. > > Okay, let us discuss this a bit further. This dir should be independant > of /usr/share/java and all containers, tomcat, jetty, glassfish, jboss > need to be configured/patched to use this directory. Does all these > containers recognize new jars, ears, wars automatically? does some need > to be restart or triggered in another way?
JBoss and Tomcat detect new deployments automatically. In JBoss, you can specify a list of directories where deployments are to be found - $JBOSS_HOME/server/default/jboss-service.xml (search for URLDeploymentScanner) > >> Maybe we should go one step further: a deployment directory for packaged >> EAR files, and a deployment directory for locally created EAR files >> (/usr/local/share/java/deploy). > > Thats a good idea. Thats then a directory that can be created on > installation of a certain package like java-common as it may not be > included in some package directly. We would potentially have three directories: /usr/lib/java/deploy - for packaged EAR and WAR files /usr/local/lib/java/deploy - for locally built EAR and WAR files /etc/java/datasource - for locally maintained datasource XML files Two virtual packages: j2ee-war-container - for Tomcat and other non-EJB containers j2ee-ejb-container - for full EJB containers (EJB2.x, EJB3.x, etc) When a container is packaged (e.g. Tomcat, JBoss) - it's configuration files must be modified to search the directories. - hot deployment should be disabled by default (see below) Detection of new packages (J2EE hot deployment): - This page has various comments on the issue: http://www.theserverside.com/news/thread.tss?thread_id=26044 - Given the slow startup time of application servers, and the potential disruption to live applications, I don't think we should restart them automatically when a .deb containing a new EAR is installed - Each package probably needs to display a warning to say `Now that you've installed this EAR file, you must restart your container. Some containers detect new deployments automatically and don't need to be restarted.' Similar comments should be in the README.Debian file. - One potential problem: hot deployment will detect the EAR file as soon as it is unpacked - before the Debian scripts are run. This is not so bad however - if the datasource hasn't been created yet, a good container will suspend the hot deployment of the EAR until all dependencies are satisfied. J2EE doesn't mandate hot deployment, but many containers offer it. People often have it enabled in development servers and not always in production servers. Perhaps we should leave it up to people to enable it manually if they understand the consequences for package installation. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
