Skip to main content

Resources in Glassfish

Posted by writtmeyer on March 11, 2008 at 3:00 PM PDT

As mentioned in a previous blog entry I still had to configure resources in order to migrate my webapps from Tomcat to Glassfish.

Since I use asadmin to configure and manage my Glassfish installation I will show in this blog entry how to add resources to your Glassfish domain using asadmin commands only. You can achieve the same results using the web-based admin console or by editing the file domain.xml by hand.

I use a mail resource for sending newsletter registration opt-in mails as well as for delivery of the newsletters themselves.

Adding a mail resource using asadmin is simple:

asadmin create-javamail-resource --mailhost smtp.someHost.de --mailuser someMailUser --fromaddress news@jsptutorial.org mail/MailSession

The result should be:

Command create-javamail-resource executed successfully.

The last argument of the command is the JNDI-name of this resource. This name also had to be configured in the deployment descriptor web.xml to be able to use this resource from within my webapps.

The following code shows how to configure this resource in your web.xml:

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.5" 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/web-app_2_5.xsd">
<!-- ... -->
   <resource-ref>
      <res-ref-name>mail/MailSession</res-ref-name>
      <res-type>javax.mail.Session</res-type>
      <res-auth>Container</res-auth>
      <res-sharing-scope>Shareable</res-sharing-scope>
   </resource-ref>
</web-app>

Given the above configuration the container-specific deployment descriptor sun-web.xml was not necessary. This deployment-descriptor is only needed when the resource name inside your web.xml differs from the correct JNDI-name of the app server.

I also had to configure a datasource. I use a PostgreSQL-database, which I consider to be the best open source database around. To use PostgreSQL (or any other database for that matter) as a datasource in Glassfish I first copied the needed libraries into the $GF_HOME/domains/domain1/lib directory. Then one has to create a connection-pool first before creating a resource which is accessible using a JNDI-name.

To create a connection-pool I used the following asadmin-command:

asadmin create-jdbc-connection-pool --datasourceclassname org.postgresql.ds.PGConnectionPoolDataSource --restype javax.sql.ConnectionPoolDataSource --property portNumber=5432:password=somePWD:user=someUser:serverName=localhost:databaseName=someDbName tutorial_pool

And hopefully we receive the following message:

Command create-jdbc-connection-pool executed successfully.

Glassfish provides the option to ping the database so one can verify that the connection-pool actually provides working connections to your database. I used the following command to ping my database:

asadmin ping-connection-pool tutorial_pool

And I got the following message:

Target exception message: Class name is wrong or classpath is not set for : org.postgresql.ds.PGConnectionPoolDataSource
CLI137 Command ping-connection-pool failed.

Which of course was not surprising given that the pool uses the common classloader which loads the jar files during the startup of a domain. Since Glassfish was already running I had to stop and restart the domain. Afterwards the result was as expected:

Command ping-connection-pool executed successfully.

Using this connection pool I was able to create a JDBC resource:

asadmin create-jdbc-resource --connectionpoolid tutorial_pool jdbc/tutorial_ds

Resulting in the following confirmation of this command.

Command create-jdbc-resource executed successfully.

So far everything went smoothly. But after creating the resources I finally ran into a problem when I tried to switch the ports of my http-listeners. Remember that I had a Tomcat running. So I could not use the productive ports for my listeners right from the onset. Changing them was in itself pretty simple:

asadmin set server.http-service.http-listener.http-listener-1.port=8080

An the message confirming this change is: server.http-service.http-listener.http-listener-1.port = 8080

In the server.log of my domain the following lines were printed as a result of this:

[#|2008-02-26T19:52:12.239+0100|INFO|sun-appserver9.1|javax.enterprise.system.container.web|_ThreadID=14;_ThreadName=httpWorkerThread-4848-0;8085;|WEB0713: Stopping Sun-Java-System/Application-Server HTTP/1.1 on 8085|#]
[#|2008-02-26T19:52:12.427+0100|INFO|sun-appserver9.1|javax.enterprise.system.container.web|_ThreadID=14;_ThreadName=httpWorkerThread-4848-0;8080;|WEB0712: Starting Sun-Java-System/Application-Server HTTP/1.1 on 8080|#]

These lines confirm that the former port of 8085 has been closed and from then on port 8080 is used instead.

Yet Glassfish lost the correct mappings between webapps and virtual servers. When listing and getting the values all appeared to be correct. But it wasn't. I connected to the http-listener ports using telnet prior to switching the ports and directly afterwards. Using the appropriate HTTP-request prior to switching I got the correct starting-page for my app, but afterwards I got the default-app only - no matter which hostname.

I couldn't figure out a way to work around this problem so I finally reverted to restarting Glassfish. Meanwhile I've also found a related bug and posted for both bugs reports on the Glassfish site.

This glitch aside I still consider the migration to have been pretty smooth.

Related Topics >>