GlassFish and PostgreSQL

To setup a PostgreSQL database connection in GlassFish is quite simple. There is one point which required special attention. First, it looks sufficient for the GlassFish DataPool configuration to only define the parameters “DatabaseName”, “User” and “Password”. By default, the URL has the value:

jdbc:postgresql://localhost/?loginTimeout=0&socketTimeout=0&prepareThreshold=5&unknownLength=2147483647&tcpKeepAlive=false&binaryTransfer=true&disableColumnSanitiser=false

But it is very important that the URL contains also the DatabaseName after the hostname:

jdbc:postgresql://localhost/[YOURDATABASENAME]?loginTimeout=0&socketTimeout=0&prepareThreshold=5&unknownLength=2147483647&tcpKeepAlive=false&binaryTransfer=true&disableColumnSanitiser=false

Otherwise it can happen that GlassFish losts the connection and is unable to find any tables. When you change your pool configuration don’t forget to restart GlassFish.

EclipseLink – DataSources!

If you configure postgresql in GlassFIsh or WildFly it seems to be very important that the additional property ‘url’ is always set with the corresponding jdbc connection url. Even if the setup wizzard (wildfly) did not fill this param!

GlassFish performance analyzing with VisualVM

This is a short overview how to do a performance analyze in GlassFish using VisualVM. When GlassFish is running and you start VisualVM it will typically connect to GlassFish. You see a local node of your GlassFish instance.

visualvm01

If GlassFish Server is not found than you need to verfy your profiler settings n GlassFish Web Console.

Now you can test the performance of your application deployed on GlassFish. Continue reading “GlassFish performance analyzing with VisualVM”

WildFly – HotDeployment

Today I extended the functionality of the manik-hot-deploy Plugin for Eclipse. The goal of this plugin is to provide an easy way for autodeployment and also hotdeployment (incremental deployment) in maven based Java Enterprise Projects.

With this Eclipse plugin you can add a configuration to your maven based JEE project to enable an autodeploy mechanism. Each time you build your maven jee project the artefacts will be automatically deployed on your application server.

Until version 1.3 only GlassFish was supported. But now I am also supporting the new WildFly Application server from Red Hat. This was a little bit tricky because in different to GlassFish WildFly did not extract (unzip) an artifact during the deployment process. But for hotdeployment you need access to the extracted web module folders. With a trick in the maven ear plugin you can create EAR artifacts with unpacked web modules. Simply add the following configuration to your ear pom.xml:

....
<build>
 <plugins>
  <plugin>
   <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-ear-plugin</artifactId>
  <version>2.6</version>
 <configuration>
 <unpackTypes>war</unpackTypes>
    </configuration>
 </plugin>

   ...

With a new option in the manik-hot-deploy plugin you can now enable the feature to autodeploy extracted versions of ear and web modules and activate the WildFly autodeployment mechanism.

Read more about mani-hot-deploy on GitHub.

 

Glassfish and Active Directory

Running JEE Applications on Glassfish can be easily connected to an existing Microsoft Active Directory Structure.

To authenticate a JEE application against Active Directory (AD) you can setup a LDAPRealm in Glassfish. Use the folowing example settings:

  •  JAAS Context: ‘ldapRealm’
  • Direcotry : ldap://your-ad-server:389
  • Base DN: ‘DC=mycompany,DC=local’

Additional to these standard connection settings (you should use your own environment configuration) you need to add the following additioanl Properties:

  • search-filter = (&(objectClass=user)(sAMAccountName=%s))
  • group-search-filter = (&(objectClass=group)(member=%d))
  • search-bind-dn = some-technical-account (do not use distinguished name)
  • search-bind-password = your-technical-account-password
  • java.naming.referral = follow

The property ‘java.naming.referral = follow’ is necessary in most cases to avoid internal exceptions during a search request.

Thats it.

HOW TO CONFIGURE AN  EXTERNAL JNDI RESOURCE

You can also use the AD to lookup additional ldap attributes from you application code. There for you need to add a external JNDI Resource which can be configured from the GlassFish console. Use the following example settings:

  • JNDI Name : you-custom-resource-name
  • Resource Type: javax.naming.ldap.LdapContext
  • Factory CLass: com.sun.jndi.ldap.LdapCtxFactory
  • JNDI Lookup: ‘DC=mycompany,DC=local’

Also here you should add some additional properties:

  • java.naming.provider.url = ldap://your-ad-server:389
  • java.naming.security.authentication = simple
  • java.naming.security.principal = some-technical-account (do not use distinguished name)
  • java.naming.security.credentials = your-technical-account-password
  • java.naming.referral = follow

The property ‘java.naming.referral = follow’ again is important here.

To lookup the external resource from your application you can use the either a annotation:

@Resource(name = "you-custom-resource-name")
private DirContext ldapConn;

You can also do a programatic lookup like this:

Context initCtx = new InitialContext();
ldapCtx = (LdapContext) initCtx.lookup("you-custom-resource-name");

 

Glassfish – 3.1.X – CDIExtension not found

Today I run into a problem when trying to deploy a EAR with more than one web modules using CDI. Deploying such a EAR on Glassfish 3.1.1 or 3.1.2 will fail with the following exception:

Root exception is javax.naming.NameNotFoundException: CDIExtension not found

As you can read in this posting this is a known bug.

http://www.java.net/forum/topic/glassfish/glassfish/gf-311-jdk1716-linux-64bit-application-running-windows-7-does-not-deploy-linux

 

http://java.net/jira/browse/JERSEY-601

 

You can solve the problem when setting the system-property “com.sun.jersey.server.impl.cdi.lookupExtensionInBeanManager=true”.

This can be done from the GlassFish server console.

  • Select the node ->Configuration->server-config->JVM Settings
  • change to the tab ‘JVM Options’
  • add a new entry
    -Dcom.sun.jersey.server.impl.cdi.lookupExtensionInBeanManager=true
  • restart your server

This will solve the deployment problem.

 

JSF 2.0 and the xmlns:c namespace

If you are working with JSF 2.0 there is a important change concerning the JSF core tags (<c:….>). These tags will not work if you are using the following namespace declaration:

<ui:composition xmlns="http://www.w3.org/1999/xhtml"
    xmlns:ui="http://java.sun.com/jsf/facelets"
    xmlns:f="http://java.sun.com/jsf/core"  
    xmlns:c="http://java.sun.com/jstl/core" 
    xmlns:h="http://java.sun.com/jsf/html">

This works in JSF 1.2 but well, but did no longer work in JSF 2.0. The reason is that the namespace uri for the jstl/core has changed. Use the following namespace definition if you are working with jsf 2.0

<ui:composition xmlns="http://www.w3.org/1999/xhtml"
    xmlns:ui="http://java.sun.com/jsf/facelets"
    xmlns:f="http://java.sun.com/jsf/core"  
    xmlns:c="http://java.sun.com/jsp/jstl/core"
    xmlns:h="http://java.sun.com/jsf/html">

 

GlassFish – Heapsize settings

After playing around with some VM settings in my GlassFish 3.1.1 environment (development and productive) I came to a setup which brings up my glassfish server much faster. Here are my settings

Development (3GB RAM)

-client
-XX:+AggressiveHeap
-Xmx1024m
-Xms1024m
-Xss128k
-XX:+DisableExplicitGC

 

Productiv (4GB Ram)

-server
-XX:+AggressiveHeap
-Xmx2048m
-Xms2048m
-Xss128k
-XX:+DisableExplicitGC

Here is also a useful link for further performance settings:

http://jfarcand.wordpress.com/2009/11/27/putting-glassfish-v3-in-production-essential-surviving-guide/

 

 

GlassFish – EJB timer service not available

Today I had a situation where after a hardware crash my GlassFish Server did not work correctly. Specially the timer service did no longer work. The server log shows a lot of errors about

...EJB Timer Service not available

In the easiest case the reason why the timer service did not start are old db.lck files.

You can check this by stopping the server and then look for any lock files in the domain folder

../lib/databases/ejbtimer/

After removing the files

dbex.lck  
db.lck

you can restart the server and every thing should work again.

See also the following thread if this did not work for you:

http://forums.java.net/node/666385