Hong Zhang's Blog

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

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.

    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: 


    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:


    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.


    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

    2. Start the derby database in network mode (Derby database is integrated with the appserver9/glassfish)

    3. Creates the datasource,  create the table, package and deploy the application
 
    4. Point your browser at 

    5. After you are done, you could undeploy the application, delete the table, delete the resource

    6. Stop the appserver/glassfish

    7. Stop the Derby database

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