vendredi juil. 23, 2010

Module initialization order in Java EE 6

This blog has moved to alexismp.wordpress.com
Follow the link for the most up-to-date version of this blog entry.

One of the new features in the umbrella Java EE 6 specification is the ability to define the order in which modules (web applications for instance) from a given Java EE application are initialized by the container. This might be useful if you want for example a given module to serve as resource initializer to create a database table before any other module can be accessed (note this does not apply to application client modules). Previously, the order in which Java EE application modules were initialized was unspecified and by default this is still the case in Java EE 6.

To explicitly request modules to be started in a particular order, the application should use <initialize-in-order>true</initialize-in-order> in the the EAR's application.xml deployment descriptor. The container will then start the modules in the order they are declared in that same configuration file (note that application.xml is optional by default and should be placed in the EAR's top-level META-INF/ directory). The short example below shows an EJB singleton creating a database table upon creation and dropping it before destruction. With this setup, the database table should always be accessible to the web application.

InitDB.java (a singleton packaged in OrderMatters-ejb.jar) :

@Singleton
@Startup
public class InitDB {
     @PostConstruct
     void createDBtable() {
         //...
     }

     @PreDestroy
     void dropDBtable() {
         //...
     }
}

The application.xml deployment descriptor for OrderMatters.ear :

<application version="6"
         xmlns="http://java.sun.com/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
            http://java.sun.com/xml/ns/javaee/application_6.xsd">
     <initialize-in-order>true</initialize-in-order>
     <display-name>OrderMatters</display-name>
     <module>
         <ejb>OrderMatters-ejb.jar</ejb>
     </module>
     <module>
         <web>
             <web-uri>OrderMatters-war.war</web-uri>
             <context-root>OrderMatters-war</context-root>
         </web>
     </module>
</application>

Full details are available in the Java EE 6 platform specification, section EE.8.5.4. Of course you can use this today in GlassFish.

As an alternate solution if you're willing to use features in GlassFish 3 beyond what Java EE 6 provides, you may also solve the problem by breaking the application into different OSGi bundles and using a combination of BundleActivator and ServiceTracker as shown in this sample from Sahoo). This can in some cases offer a more suitable and loosely-coupled approach.

mercredi avr. 22, 2009

Different strategies for building different packages (for GlassFish v3)

This blog has moved to alexismp.wordpress.com
Follow the link for the most up-to-date version of this blog entry.

In my previous two posts (related to building packages for GlassFish), I covered the basics of the Update Center for GlassFish v3 and the underlying IPS/pkg(5) technology and what it takes to build a Hibernate package for GlassFish v3.

One key part that is still missing is the process (or social) side of things - how does one get to commit to the glassfish-repo project, and maybe more importantly, how does a community package make its way to the pkg.glassfish.org/v3prelude/contrib/ repository that is wired into every single GlassFish v3 distribution? This part needs a little more fine tuning and I will cover it soon in a dedicated post. In the mean time, I encourage you to join the glassfish-repo project as a developer.

In this post I'll cover the different possible natures for GlassFish v3 packages beyond the (rather simple) Hibernate example described earlier and available here to study. As you will see the spectrum of packages for GlassFish can be quite large.

1/ Frameworks and libraries
Examples include web frameworks, JDBC drivers, and any other technology that simply requires a set of JAR files to be available from the application running in GlassFish. Such JAR libraries should be placed into GLASSFISH_HOME/glassfish/lib. There is no need to restart GlassFish unless this is a new version of a library with the same JAR file name (individual applications may need to be restarted though). Note it is recommended that you do not touch the default GLASSFISH_HOME/glassfish/domains/domain1 domain. This is because putting any IPS-controlled file in that directory and having GlassFish (or the developer) modify or remove it will show up as a "partially installed" package.
This package use-case is the simple approach discussed in the previous Hibernate use-case.

2/ Applications running in GlassFish
Assuming an application packaged in a WAR, JAR, or EAR has no external resource dependency (connection pool, JMS queue, etc..), the IPS package can simply place the artifact in the autodeploy directory of a domain. As stated above the issue is that there is no guaranty that domain1 exists. One approach is to create IPS packages with a dependency on another IPS package responsible for creating a generic "updatecenter" domain (name TBD) thus installing that package/domain if it's not already there. This would also avoid each application shipping with its own domain causing unnecessary space to be used, additional admin tasks to manage the domains, and potential port conflicts. Notable exceptions would be packages requiring considerable setup of the domain (specific jvm options, data-sources or other resources pre-configured, etc.). In this case, shipping the application with a pre-configured domain actually makes more sense.

With the approach of placing the application in the updatecenter/autodeploy directory, removing the package will delete the archive from the autodeploy directory and thus cause the application to be undeployed. Removing the "updatecenter" package will cause the applications depending on it to be no longer available as the domain directory would be deleted. Ideally the domain needs to be stopped first.

3/ Applications independent of GlassFish
Applications running in a separate process can be installed as top level directories and thus be quite independent from the GlassFish v3 runtime bits. Sample packages include monitoring applications, tools, databases, etc. In this case, laying out files at the root of the target/stage staging area will result in a top level install sitting next to GlassFish, similar to JavaDB in the current GlassFish v3 builds. Such a tool can then reference the glassfish v3 install using ../glassfish. You may also want to add binaries to glassfish/bin referencing your application or tool. In the case of JavaDB, there is even an additional ../glassfish/bin/asadmin command (start-database) and that takes us to the next type of GlassFish packages: extensions to the runtime and admin tools.

4/ GlassFish extensions (HK2/OSGi components)
Being modular in its own right, GlassFish supports placing JAR files under the glassfish/modules directory. Of course the artifacts placed there need to adhere to certain rules fairly well documented in the Add-On Component Development Guide (especially the "Writing HK2 Components" and "Adding Container Capabilities" sections). Note you can also extend the admin console, the CLI, and add monitoring capabilities. All of these tasks are quite orthogonal to the (rather lightweight) effort of producing the actual IP package placing the artifacts into the GlassFish modules directory (check the above "Frameworks and libraries" section for how to drop files into a specific directory).

A word on (post-)install scripts
As you can see in the discussion above, it's all about laying out files on disk. GlassFish/IPS packages cannot start/stop processes or run scripts during or after time install by default (if you really need pre/post actions, read this and this). Of course you can (and are actually encouraged) to provide instructions in the package description (in the prototype file), a README.txt file that remains on disk after install, and possibly scripts to be manually executed after the install (to pass some asadmin commands) or prior to some uninstall (like stopping a domain). Remember though that factory configs are best (albeit not always possible).

You should note that the above are merely suggestions for how to build packages for GlassFish v3, not quite best practices at this point, so we're more than happy receiving feedback and suggestions! As you can see the spectrum of packages for GlassFish can be quite large.

There should be at least two more part to this series: how to get your package into the public contrib/ repository and a more complex package example requiring a domain (and thus a dependency on another IPS package).

samedi sept. 08, 2007

SDPY - Most important Java 7 feature

Two years ago, I wrote this piece on "The most important feature for Java 7". It still sounds like the #1 thing I want from Java 7.

mercredi mai 02, 2007

GlassFish v3 screencast follow-up and more

Jerome Dochez, GlassFish architect has a follow-up to the GlassFish v3 screencast.
Bits and documentation now live on http://hk2.dev.java.net/.

In other GlassFish news as we're approaching the GlassFish Day and JavaOne :


• Lighter weight Tomcat has to be more scalable? Think again.
• LoadBalancer administration for GlassFish
• GlassFish only an apt-get away for Dell users

Oh and GFv2 Beta 2 anytime now....

lundi mars 26, 2007

GlassFish v3

I should probably be doing some sort of post-TechDays entry or something about my one-day escape to Oslo, but since GlassFish v3 is born, I'd suggest you take a look at it.

About

This blog has moved

Alexis Moussine-Pouchkine's Weblog

GlassFish - Stay Connected

Search

Archives
« avril 2014
lun.mar.mer.jeu.ven.sam.dim.
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today
Blogroll

No bookmarks in folder

News

No bookmarks in folder