Re: File locations: EAR, WAR, XML datasource
> 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
Reply to: