Re: 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: File locations: EAR, WAR, XML datasource
On Mon, Dec 31, 2007 at 01:20:58PM -, 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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? 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
