Monday Feb 28, 2011

GlassFish 3.1 and deployment

Glassfish 3.1 and deployment The GlassFish 3.1 is released today! The most important feature of this release is the clustering capability (which provides the feature parity with Glassfish v2.1)! This will allow user to use Glassfish in an enterprise environment.

Let's look at the main features provided in this release from the deployment area:

As part of overall clustering feature, user can now dynamically deploy an application to a cluster, undeploy an application from a cluster, and enable or disable an application on a cluster target. In v3, only the DAS (default server instance) target was supported.

The existing v3 set of the commands are now supported/extended in the clustering environment: create-lifecycle-module, delete-lifecycle-module, list-lifecycle-modules, deploy, undeploy, enable, disable, deploydir, redeploy, list-components, show-component-status, list-applications. And the new commands which are specific to the clustering environment are added on top of the existing set of v3 commands: create-application-ref, delete-application-ref, list-application-refs.

You can take a look at this for a simple example of how to work with the cluster target.

One enhancement we have in 3.1 over 2.1 is now we also support directory deployment with a cluster target provided the application bits are accessible by the target instances.

The next feature I want to talk about is the application versioning feature. This feature is developer by the external contributor Serli.

With the application versioning feature, the user will be able to deploy multiple versions of the application to the Glassfish. And the user can easily upgrade or rollback to one version of the application using the basic set of the commands (deploy/enable/disable). Currently only one version of the application can be enabled at one time in the runtime.

You can view this screencast to see how this feature is working.

We also enhanced the application rolling upgrade by taking advantage of the application versioning feature. With the enhancement, no cluster instance restart is needed and the dynamic reconfiguration can be left on (no need to turn it off and then on).

In this release, we also provided partial support for the WebLogic deployment descriptors (mainly in the web area). This will allow user to develop web applications with simple WebLogic extensions on Glassfish and then run on WebLogic.

The final thing I want to mention is the new names of the vendor specific deployment descriptors. In the past, we use "sun-" as the prefix for the vendor specific deployment descriptors (and dtds), for example, sun-web.xml, sun-web-app_3_0-0.dtd. From this release,  we will start to use "glassfish-" as the prefix for the vendor specific deployment descriptors (and dtds), for example, glassfish-web.xml, glassfish-web-app_3_0-1.dtd. The old sun-\* deployment descriptors (dtds) are still supported for backward compability, but if you want to use new elements introduced in the most recent dtd, you need to use glassfish-\* set of the dtds.

Thursday Dec 10, 2009

Glassfish v3 and deployment

Glassfish v3 and deployment

The Java EE 6 compatible Glassfish v3 is released today! In addition to provide v2 feature parity, the v3 deployment implements the new Java EE 6 spec requirements which include the deployment of ejb lite (EJBs packaged inside the war), the portable naming (where you can define application name and module name in the deployment descriptors and then use them in JNDI lookup) and etc.

Among many changes that went into v3 deployment, the most important piece is the new pluggable/extensible deployment framework. This pluggable deployment framework allows you to plug in new module/container types with the container SPIs (see Add-On Component Development Guide for more details). The JSR 299 (Context and Dependency Injection) RI was integrated through the framework. The Java EE standard module/container types were also re-written to retro-fit into the framework. This deployment framework also sends application lifecycle events at various points of the deployment to allow application developers to perform tasks (such as application initialization/clean up work) as needed at those points.

In v3, the code paths of the application loading during deployment and server start up have been converged to provide users more consistent behaviors (which also helps make code maintenance easier). As a result, we don't write out the generated deployment descriptors (merged version from the original deployment descriptors and the annotations) by default any more. If you need to use the generated deployment descriptors for debugging purpose, you can use the system property (-Dwriteout.xml=true) to write them out.

Monday Sep 17, 2007

glassfish v2 and deployment

Glassfish v2 is released today! Aside from providing various support for the glassfish internal components (JBI etc), the main focus for deployment in v2 has been user experience:

  • Faster deployment: We have improved deployment performance in several ways, especially in the web redeployment area.

  • More diagnostic error messages: We now provide diagnostic error messages for the most common error use cases.


One highlight in v2 on the user experience is to address the windows locking problem. In v1, one complaint we often heard about is redeployment or undeployment failing due to windows locking. And Tim has written a quite useful tool to diagnose the cause of the file locking. In v2, we have taken a significant further step to address/alleviate this type of problem from the glassfish server side and we have heard great feedback about this!


Another thing that's worth mentioning is we have provided support to integrate with MyEclipse in v2, and now users can deploy to glassfish through MyEclipse (via auto directory deployment).

Thursday Mar 16, 2006

How to connect local context to global jndi context

map local context to global jndi context How do we connect local context (logical jndi name) to global JNDI context (physical jndi name)?
This question got asked quite often and yesterday again. So I thought I'd post the question and my answer here.

Question:
==============
I'm a little lost here. I'm trying to create an MDB, but I'm not sure how to look up the mapped resources - I have a queue and a connection factory defined, but when I use the canonical names, they never resolve. When I use netbeans to create the references, it uses a "Name" attribute, but using that name doesn't resolve either; I guess I'm just not sure how to connect local contexts to the global JNDI context.

Can anyone explain how this works in glassfish for me?


Answer:
============
There are two ways you can map the logical jndi name (the resource reference name that you use to look up in your code, or the local jndi name your referred to) to the physical logic name (the name that you create the resource with, or the global jndi name you referred to).

1. Using the sun specific deployment descriptor files
2. Using the mappedName attribute of the Resource annotation (this is new in Sun Java System Application Server 9.0 / Glassfish)

You can look at this simple mdb test as an example:

In this example, a message connector factory "jms/ejb_ejb30_hello_mdb_QCF" (i.e. the physical jndi name) is created:
asadmin create-jms-resource --restype javax.jms.QueueConnectionFactory jms/ejb_ejb30_hello_mdb_QCF

1. And in the Client code, it uses the mappedName attribute to map the logical jndi name "FooCF" to the physical jndi name "jms/ejb_ejb30_hello_mdb_QCF"
    @Resource(name="FooCF", mappedName="jms/ejb_ejb30_hello_mdb_QCF")
    private static QueueConnectionFactory queueConFactory;

2. Alternatively, you could have this in the Client code without the mappedName attribute:
    @Resource(name="FooCF")
    private static QueueConnectionFactory queueConFactory;

   Then in the sun-application-client.xml, you will provide this mapping
     <resource-ref>
       <res-ref-name>FooCF</res-ref-name>
       <jndi-name>jms/ejb_ejb30_hello_mdb_QCF</jndi-name>
       <default-resource-principal>
         <name>guest</name>
         <password>guest</password>
       </default-resource-principal>
     </resource-ref>


Lastly, in the Sun Java System Application Server 9.0 / Glassfish, we have implemented some runtime defaulting mechanism for global jndi names. When the logical jndi name is the same as physical jndi name, no mapping is needed. You could get more details on this from my runtime defaults blog.

Friday Feb 10, 2006

Runtime defaults in Appserver9/Glassfish

providing runtime defaults in Glassfish     A Java EE application is a logical collection of one or more Java EE modules tied together by application deployment descriptors. In addition to the Java EE standard deployment descriptors, application server vendors use runtime deployment descriptors for configuring features specific to their server. The use of runtime deployment descriptors adds additional complexity in deploying an application to a Java EE application server, as well as making it harder for a user to port applications from one such a server to another.

    To alleviate the users from having to always provide runtime deployment descriptors, we have implemented many runtime defaults in the upcoming Sun Java System Application Server 9.0 Beta release (will be referred as appserver9 below), also available in Glassfish. This will reduce and in some cases eliminate the need for including runtime deployment descriptors in an application. For example, we are now providing defaults for the jndi names of various JNDI environment references (ejb-ref, resource-ref, resource-env-ref, message-destination-ref). In previous versions of Sun Java System Application Server, for example,  Sun Java System Application Server 8.x (will be referred as appserver 8 below), after the JNDI environment references are defined in the standard deployment descriptor, mapping of these environment references to their physical jndi names would need to be defined in the runtime deployment descriptors. This is no longer needed in appserver9 if the physical jndi name is the same as the environment reference name.

    Following is a simple example to illustrate the simplification. It uses the resource reference scenario described in the Tomcat tutorial. It inserts two employees into the Employee table and displays back the second employee.

    The AccessDBServlet use a data resource jdbc/EmployeeDB to talk to the underlying database: 

InitialContext initCtx = new InitialContext();
Context envCtx = (Context) initCtx.lookup("java:comp/env");
DataSource ds = (DataSource) envCtx.lookup("jdbc/EmployeeDB");

    In the standard deployment descriptor (web.xml), it defines this resource-ref entry for the data source:
 <resource-ref>
<description>Employees Database for HR Applications</description>
<res-ref-name>jdbc/EmployeeDB</res-ref-name>
<res-ref-type>javax.sql.DataSource</res-ref-type>
<res-auth>Container</res-auth>
</resource-ref>

    To have this application work on appserver8 or port this application from Tomcat to appserver8, you would need to map the resource reference to the physical jndi name of the jdbc resource created on the server in the runtime deployment descriptor (sun-web.xml).
 <resource-ref>
<res-ref-name>jdbc/EmployeeDB</res-ref-name>
<jndi-name>jdbc/EmployeeDB</jndi-name>
</resource-ref>

    But in appserver9 and Glassfish, you don't need to do any mapping. Especially if this is the only information you needed in the sun-web.xml, now you are runtime deployment descriptor free. 

    You can download the complete source of this example from here (thanks Lance for his help with database setup). There is a build.xml provided in the zip file,  you can use that to create the datasource, create the table, package and deploy the application (the build.xml is only tested on unix platforms, you will need to modify it to make it work for windows). Of course you could also choose to do the tasks manually.

    The main ant targets of the build.xml are as follows:

deploy-jdbc: create the jdbc resource jdbc/EmployeeDB on the server
create-sql: create the Employee table
build: build and package the web application
deploy: deploy the web application to the server
undeploy: undeploy the web application from the server
undeploy-jdbc: delete the jdbc resources jdbc/EmployeeDB from the server

    Before you use the build.xml, you need to edit build.properties with appropriate values. For example, you need to set appserver.home to where you installed the appserver/glassfish, and java.home to where you installed the jdk.

#set this to where you installed the appserver/glassfish
appserver.home=${env.S1AS_HOME}
#set this to where you installed the JDK
java.home=${env.JAVA_HOME}

    To run the sample, assume you have installed the appserver/glassfish at $AS_INSTALL and unzip the example at $EXAMPLE_DIR
    1. Start the appserver9/Glassfish
cd $AS_INTALL/bin
./asadmin start-domain

    2. Start the derby database in network mode (Derby database is integrated with the appserver9/glassfish)
cd $AS_INTALL/bin
./asadmin start-database

    3. Creates the datasource,  create the table, package and deploy the application
cd $EXAMPLE_DIR
ant deploy-jdbc create-sql build deploy
 
    4. Point your browser at 
http://localhost:8080/dbAccess/dbServlet

    5. After you are done, you could undeploy the application, delete the table, delete the resource
cd $EXAMPLE_DIR
ant undeploy delete-sql undeploy-jdbc

    6. Stop the appserver/glassfish
cd $AS_INTALL/bin 
./asadmin stop-domain

    7. Stop the Derby database
cd $AS_INTALL/bin
./asadmin stop-database

Wednesday Jan 25, 2006

First external app-hosting application AtLeap is deployed!

First external app-hosting application is deployed     I've spent some time working on the app-hosting project after the new year and deployed its very first external application AtLeap last week.

    App-hosting project provides the J2EE community an outlet to showcase the applications the developers are working on. The applications will be deployed on Sun's SJSAS appserver which is hosted on a system by LocalWeb in Brazil. Community members are encouraged to submit the J2EE application for deployment. The actual deployment of an application is done by a small team of engineers from Sun. As a member of this team, I had the pleasure of working on the very first application.  The following is an account of my experiences.

   The whole process went pretty smooth. Andrey Grebnev, the owner of the project AtLeap, submitted us the application description. The team agreed to accept his project after some discussion. Andrey then provided us with detailed instructions on how to deploy it. I worked with Renato Weiner from LocalWeb side to configure the hosting machine. Since this is the first external project, it took us a little while to get everything set up. Once we were past that, it was very easy. The instructions that Andrey provided are very straightforward and easy to follow. The actual deployment was like a breeze.

   The AtLeap application (read more about the application) is a framework which allows Java developers to rapidly start their own Web application based on modern (Hibernate, Spring) and prevalent (Struts, XDoclet)libraries. AtLeap has its own rich tag library (more than 60 tags) to provide grid, menu, context menu functionality etc. It also includes multilingual CMS based on established solutions (Lucene, FCKEditor, TinyMCE) with full-text search (including Word, Excel, PDF, PowerPoint).

About

hzhang

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
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