Best way to deploy on Glassfish V3

Question

What is the best way to deploy my web project (or ear project) to remote server and glassfish?

How to use ant-deploy.xml and build-impl.xml that netbeans create for this purpose?

Using autodeploy folder and separately adding sun-resources.xml to the GF Or Using ant and....

Would you please explain me step by step?

Regards

Answer 1

1. Short answer first

Use a combination of:

1. maven, to drive the whole construction and deployment process (profiles and resource filtering will be very valuable features for you)
2. shell scripts that use the asadmin command (an alternative to one of the glassfish maven plugins
3. jenkins to trigger maven builds, either on a periodic basis or as a result of new code being pushed to your version management system.
4. Netbeans has excellent integration both with Glassfish and maven and is my favorite Java EE IDE:

2. Now, some background...

To answer this question, it is useful to take a broader perspective and to consider the whole development/deployment life-cycle. The actual deployment of a .war or .ear archive in Glassfish is only one step of the cycle.

If you want to be really effective, you need to consider a combination of tools and practices for automating the construction and the deployment of your software applications. This is especially true if you work in a "real-world" environment with developer machines, continuous integration machines, QA machines and production machines.

I will elaborate a bit on these items in the following paragraphs. In particular, I will explain why I think that today, custom shell scripts driven by maven are better than the glassfish maven plugins available in the community.

3. Build management with maven

For many people doing java development, maven is a well-known tool. For the others, here is a very brief introduction. The goal of maven is to automate the construction of software artifacts. It is a framework (in the same sense as an object-oriented framework), which means that:

1. it defines a standard way to build, package and test software
2. it provides you with extension points to attach custom behavior around this standard way

In essence, when you use maven, you describe what kind of software artifact you are building (is it a .jar, is it a .war, is it an android app, etc.). By default, maven expects to find source files, test files and resources in specific locations. By default, maven knows that building the software requires to go through different phases: compilation, unit testing, packaging, deployment, integration testing, documentation generation, etc.

Another thing that maven does for you (and which is often the first reason for using the tool) is dependency management. Maven specifies a way to identify libraries (with a name and a version), which are made available through repositories (there are both public, global repositories and private repositories). With maven, you specify things like "I depend on magiglib version 1.2.2". When you ask maven to do the build, it will automatically fetch the lib, store it in a local repository and use it for the construction and the packaging. No need to deal with manual transfers of .jar files, no risk to introduce bugs because different version of the same lib are used by different developers or at different stages.

Last but not least, maven offers the ability to customize the construction of your software, depending on the target deployment machine. Think about the following use cases:

• During development, think that every developer may have a different installation (mysql may not listen on the same TCP port, glassfish may not be installed in the same directory, passwords will be different, etc.).

• A development machine is obviously different from a continuous integration environment, which is itself different from a QA or a production environment (again, just think about networking, file system, credentials).

Maven supports these use cases with the combination of variables, profiles and resource filtering:

• A variable is, well, a variable just like in any kind of programming environment. When you use maven, you write an XML configuration file (pom.xml) and you can use variables in it. That makes your build system configurable and dynamic. The port on which mysql listens or the directory in which glassfish is installed can be defined as variables.
• A profile is a way to give values to a set of maven variables. Typically, every developer will have a profile, every environment (from continuous integration to production) will have a profile, etc.
• Resource filtering allows you to reference maven variables in your source files, resource files and configuration files. For instance, in a java file, you can have the following string ${myvar} embedded. If you configure maven to do resource filtering, then it will replace ${myvar} with the value of the maven myvar variable (which may be defined in the current profile).

Maven is an extremely powerful tool, and as such has a learning curve. If you use Netbeans, you can actually create a maven-driven project with a couple of clicks and benefit from the basic features (e.g. dependency management). For advanced topics, there is very good documentation available. I will not go into further details here.

4. glassfish plugin... or not?

Once you have understood the value of maven and decided to use it, the next question is how you can use it to do the actual deployment of the .war or .ear archive into Glassfish (locally or remotely). This is where you have a number of options and where we have learned quite a few things over the years (we have been using maven with glassfish for several years now).

The first thing that you can do is to use one of the glassfish maven plug-in. There are different plug-ins available. They have quite different capabilities and different levels of support. It turns out that the most powerful plug-in is actually not supported anymore and does not work with Glassfish 3 out of the box. The plugin was interesting, because it made it possible not only to deploy archives into Glassfish, but also to create resources (jdbc pools, jms queues, etc.). It also made it possible to create glassfish domains on the fly (very useful to run integration tests and make sure that a fresh domain was used for that). Anyways, the new plugins (that are described in the product documentation) are not that powerful and purely focus on the deployment task.

In the build system that we created and made evolve over the years, we were able to achieve a lot of control and flexibility by combining the glassfish maven plugin with profiles and resource filtering. The solution works, is solid, yet is quite complex (our pom.xml and settings.xml has grown a lot and has become heavy).

So, if I was setting up a new build system from scratch, I would probably do things a bit differently. If you look at the code of the glassfish maven plugins, you will see that they are pretty much wrappers around the asadmin command line tool provided by Glassfish (and it is because the parameters and behavior of asadmin has changed from one glassfish version to the other that the maven plug-ins have been broken).

5. The way forward

What I would do is:

• write a set of shell scripts to create glassfish domains, create resources (jdbc, jms, etc.), deploy .war and .ear. The scripts would use asadmin to interact with glassfish (it is possible to use asadmin both locally and remotely);

• embed maven variables in these scripts and use resource filtering to dynamically create environment-specific versions of the scripts;

• use the maven exec plug-in to run the scripts at different stages of the maven build cycle (integration test, run, custom goals, etc.).

Answer 2

I have found that several methods work well depending on your scenario:

Deployment when you have access to the filesystem of a running Glassfish 3:

Glassfish allows for automatic hot-deployment of resources placed in the right location "inside" the files of a running Glassfish. The default location for Glassfish 3.1.2.2 is glassfish-3.1.2.2/glassfish/domains/domain1/autodeply. I've previously found that under Windows it occasionally does not discover that a file has been updated, so first a removal and awaiting the undeployment before deploying in again, may be necessary.

Manual deployment to a remote Glassfish 3

The administrator page (default port 4848) contains a deployment section allowing users to upload and deploy, disable and enable, and undeploy applications. This is what I've found to be the most robust for manual maintenance.

It also does not require full access to the underlying server.

Automatic deployment to a remote Glassfish 3

The cargo project allows for automatic deployment to a suitably configured Glasfish instance.

The following command executed with a pom.xml describing a war deployment will (as of 2012-10-17) download and execute a glassfish with the current project deployed to it.

mvn clean verify -Dcargo.maven.containerId=glassfish3x -Dcargo.maven.containerUrl=http://dlc.sun.com.edgesuite.net/glassfish/3.1.2.2/release/glassfish-3.1.2.2-web.zip  org.codehaus.cargo:cargo-maven2-plugin:run

(along with a small snippet in pom.xml telling cargo additional details about the glassfish location)

Part of a Maven development build, like jetty:run

Maven support has been good with Glassfish 3. The primary benefit is that you do not need to download and unpack and start Glassfish manually - maven can do it all automatically.

See http://embedded-glassfish.java.net/ for instructions.

I've only used this briefly, but it appear to be a nice alternative to the IDE-centric solutions.

Answer 3

More os independent way to deploy app:

<presetdef name="asadmin">
  <java jar="${glassfish.home}/modules/admin-cli.jar" fork="true" jvm="${java.home}/bin/java" >
    <arg line="--port ${glassfish.admin.port}" />
  </java>
</presetdef>
<target name="deploy">
  <asadmin failonerror="true">
    <arg value="deploy" />
    <arg value="--force=true" />
    <arg value="${ear.file}" />
  </asadmin>
</target>

you colud use asadmin preset with any asadmin tasks...

Answer 4

Well, you could manually deploy your app via the admin console.

Or you could use the asadmin command. A remote deployment in its simplest from would look like:

asadmin deploy --user=<adminuser> --host=<hostname> <path to jar/war/ear>

And this could be shell scripted, or wrapped in Ant, or Maven.

Or you could use more specialized tools (the Ant Task, the maven glassfish plugin, the maven asadmin plugin, Cargo).

It all depends on your context, there is no single answer and there are many possibilities. If you don't know what you're looking for, just use the Ant build scripts created by NetBeans.

Answer 5

Adding points to Answer from @Pascal Thivent, (I hope it would helpful for others with similar question)

1)It is just mouse click to start,stop,deploy the application with Netbeans.

2)Besides working with Eclipse or Netbeans or your favorite IDE

2.1)On Windows dev environment: start with command-line tools like asadmin during your development. 2.2)On Linux dev environment: use shell scripts and automate the deployment process.

2.3)Use autodeploy and Netbeans remote deployment in dev environment. 2.4)use scripted or command-line remote deployment is based on the need

3)You come up with a most appropriate approach like develop a 'build script' based on the project needs & interest, and other considerations like organisational process.

Without maven or ant, just adding necessary jars manually is not bad idea at all. After adding jars, deploy from admin console or just use build script.

Maven fails some times with JavaEE jars..but you have solutions in SO. I go with Maven some times based on existing sample project and organisational process. I also use ant that comes default with Netbeans Java EE project.

Answer 6

You can use ant task to deploy war file to glassfish-V3;

Build.xml content;

<target name="deploy"
    description="deploys application to glassfish">
    <exec failonerror="true" executable="cmd">
     <arg value="/c" />
     <arg value="asadmin --user ${gfUser} --passwordfile ${gfPassFile} --host ${host} deploy build/${war}" />
    </exec>
</target>