FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Java

 
 
LinkBack Thread Tools
 
Old 12-29-2007, 10:59 AM
Daniel Pocock
 
Default File locations: EAR, WAR, XML datasource

Hi,

Are there standard directory locations for the following types of files
which are normally deployed to a J2EE container:


- EAR and WAR files

- XML datasource files

By default, containers like JBoss look inside their own directory
structure (e.g. /opt/jboss/server/default/deploy) - however, they can be
configured to look in a central location (e.g. /usr/share/java/deploy
perhaps). This would enable WAR files and EAR files to be packaged
without worrying about whether the user will install Jonas, JBoss,
Tomcat or something else.


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.


Regards,

Daniel

--


-----------------------------------------------------------------------
Ready Technology Limited
Incorporated in England and Wales, 4940731
Registered office: Devonshire House, 60 Goswell Rd, London, EC1M 7AD
-----------------------------------------------------------------------


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-29-2007, 02:21 PM
Michael Koch
 
Default File locations: EAR, WAR, XML datasource

On Sat, Dec 29, 2007 at 12:59:53PM +0100, Daniel Pocock wrote:
>
>
>
> Hi,
>
> Are there standard directory locations for the following types of files
> which are normally deployed to a J2EE container:
>
> - EAR and WAR files
>
> - XML datasource files
>
> By default, containers like JBoss look inside their own directory structure
> (e.g. /opt/jboss/server/default/deploy) - however, they can be configured
> to look in a central location (e.g. /usr/share/java/deploy perhaps). This
> would enable WAR files and EAR files to be packaged without worrying about
> whether the user will install Jonas, JBoss, Tomcat or something else.
>
> 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?


Cheers,
Michael


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-29-2007, 02:32 PM
Daniel Pocock
 
Default File locations: EAR, WAR, XML datasource

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.


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).


Regards,

Daniel

--


-----------------------------------------------------------------------
Ready Technology Limited
Incorporated in England and Wales, 4940731
Registered office: Devonshire House, 60 Goswell Rd, London, EC1M 7AD
-----------------------------------------------------------------------


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-29-2007, 04:13 PM
Michael Koch
 
Default 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?

> 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.


Cheers,
Michael


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-31-2007, 12:20 PM
"Daniel Pocock"
 
Default 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



--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-31-2007, 01:07 PM
Michael Koch
 
Default File locations: EAR, WAR, XML datasource

On Mon, Dec 31, 2007 at 01:20:58PM -0000, Daniel Pocock wrote:
> 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)

Thanks for this summary. I will comment inline.

> >> 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

Can datasources in /etc/java/datasource be hot deployed. I know about
wars and ears. But I dont know about datasource xml files. Can you give
an example.

> 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.

Perhaps it would be a good idea to create a tool called
udate-java-containers that checks what needs to be done (and does it) or
can do nothing if not needed/wanted.

Another problem is probably hot-undeployment. Can we handle
deinstallation of Debian packages with wars/ears/datasource descriptors
automatically? Here can the update-java-containers helper probably help
too.

What do you think?


Cheers,
Michael


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-01-2008, 10:21 AM
Marcus Better
 
Default File locations: EAR, WAR, XML datasource

Daniel Pocock wrote:
> JBoss and Tomcat detect new deployments automatically.

It probably doesn't make sense to auto-deploy a new webapp to all installed
servers. Probably the user wants to select which server to deploy to,
similar to the traditional installation where the servers have separate
directories.

An option would be to install webapps in a shared directory
like /usr/share/java/webapps, but _not_ configure app servers to use this
automatically. Instead we can provide an option in /etc/default/jboss etc
to auto-deploy from the shared directory (off by default).

Marcus



--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-02-2008, 08:16 AM
Daniel Pocock
 
Default File locations: EAR, WAR, XML datasource

Marcus Better wrote:

Daniel Pocock wrote:


JBoss and Tomcat detect new deployments automatically.



It probably doesn't make sense to auto-deploy a new webapp to all installed
servers. Probably the user wants to select which server to deploy to,
similar to the traditional installation where the servers have separate
directories.

An option would be to install webapps in a shared directory
like /usr/share/java/webapps, but _not_ configure app servers to use this
automatically. Instead we can provide an option in /etc/default/jboss etc
to auto-deploy from the shared directory (off by default).




Ultimately, here is the use case I am looking at:

- a user decides they want a particular package (e.g. xwiki, a WAR file)

- they type apt-get install xwiki

- the package depends on other packages: j2ee-war-container and
jdbc-driver, and it recommends relational-database


- apt satisfies those dependencies by installing Tomcat, MySQL JDBC
driver, and MySQL server


- during the xwiki package installation, the install script sees that
the MySQL JDBC package is installed, and it offers to create a
datasource for that driver (and create a database too) - the user
accepts this option


- finally, the user is told that their Tomcat may require a restart

Now let us consider one modification to this use case: the user already
has JBoss installed. In this case, JBoss already satisfies the
dependency j2ee-war-container, so apt doesn't try to install Tomcat.


I realise that there are users who want much more control over their
application servers - I am one of them. Nonetheless, I think that what
I'm proposing is feasible, even if it may take a little thought and time
to fully implement. If Debian provides this infrastructure, then there
is a real possibility that vendors will want to release their products
on Debian, as the users will deploy them more easily.


Also, there is no need for any of this to be mandatory - for instance,
the user would still have the option of manually installing JDBC driver
JAR files, and manually configuring the application server to create a
datasource.


Datasource creation is server specific - but maybe we can offer a
generalised approach, and each packaged application server can
(eventually) provide a script to implement it?


Regards,

Daniel



--


-----------------------------------------------------------------------
Ready Technology Limited
http://www.readytechnology.co.uk
Incorporated in England and Wales, 4940731
Registered office: Devonshire House, 60 Goswell Rd, London, EC1M 7AD
-----------------------------------------------------------------------


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-04-2008, 08:30 AM
Michael Koch
 
Default File locations: EAR, WAR, XML datasource

> Ultimately, here is the use case I am looking at:
>
> - a user decides they want a particular package (e.g. xwiki, a WAR file)
>
> - they type apt-get install xwiki

Easy.

> - the package depends on other packages: j2ee-war-container and
> jdbc-driver, and it recommends relational-database

Easy.

> - apt satisfies those dependencies by installing Tomcat, MySQL JDBC driver,
> and MySQL server

Easy.

> - during the xwiki package installation, the install script sees that the
> MySQL JDBC package is installed, and it offers to create a datasource for
> that driver (and create a database too) - the user accepts this option

The hard part. See below...

> - finally, the user is told that their Tomcat may require a restart

If we go that far we can this for the user too.

> Now let us consider one modification to this use case: the user already has
> JBoss installed. In this case, JBoss already satisfies the dependency
> j2ee-war-container, so apt doesn't try to install Tomcat.

Easy, normal APT job.

> I realise that there are users who want much more control over their
> application servers - I am one of them. Nonetheless, I think that what I'm
> proposing is feasible, even if it may take a little thought and time to
> fully implement. If Debian provides this infrastructure, then there is a
> real possibility that vendors will want to release their products on
> Debian, as the users will deploy them more easily.
>
> Also, there is no need for any of this to be mandatory - for instance, the
> user would still have the option of manually installing JDBC driver JAR
> files, and manually configuring the application server to create a
> datasource.
>
> Datasource creation is server specific - but maybe we can offer a
> generalised approach, and each packaged application server can (eventually)
> provide a script to implement it?

I would like to have this all designed and all features check that they
are implementable before we start to implement it. This way we make sure
that dont need to stop after doing half the job because the other half
is not solvable. E.g. the creation of container specific datasource
definitions looks really complicated to me.


Cheers,
Michael


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 07:33 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org