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");

 

JSF 2.0 – ajax suggestion box

Since JSF 2.0 has introduced the ajax support it is quite simple to implement functional widgets like a suggestion input box. The following short tutorial shows how to build your own suggestion widget using JSF 2.0 and it’s ajax capabilities.

1. THE HTML FORM

First you need a simple input field where the user can type in a search phrase. This can be done wit the h:inputText element. After the user typed in some character a suggestion widget should start a backend search and provide the user with a list of suggestions (you can see this behaviour when searching for something on google.com). To connect your inputText element with a backend component you can use the new build-in ajax feature provided by JSF 2.0. So your input element looks something like this:

<h:panelGroup layout="block" style="margin-bottom:5px;">
     <h:inputText value="#{suggestController.input}">
        <f:ajax event="keyup"  render="suggest_box" /> 
     </h:inputText>
</h:panelGroup>

 

2. DEFINE THE SUGGEST BOX

With the ‘render’ attribute of the f:ajax tag you specify which part of your page should be rerendered after the ajax event was fired. In this case an element with the ID ‘suggest_box’ will be updated. This is the part where you can display the results of your backend search:

<h:panelGroup id="suggest_box">
	<ul>
		<ui:repeat var="entry" value="#{suggestController.result}">
			<li>#{entry}</li>
		</ui:repeat>
	</ul>
</h:panelGroup>

 

To bind you backend component (suggestController) to the event just use the listener tag:

 <f:ajax event="keyup" render="suggest_box"
	listener="#{suggestController.search}" >
</f:ajax>

Your suggest controller implementation can look like this:

....
public void search(AjaxBehaviorEvent event) {
	....
	result=new ArrayList<String>();
	....
}

public List<String> getResult() {
	return result;
}

If you are working with EL 2.2 support (GlassFish 3.1) you can also pass params as method arguments:

<f:ajax event="keyup" render="suggest_box"
	listener="#{suggestController.search('abc')}" >
</f:ajax>
public void search(String param) {
       ..
}

 

3) LAYOUT

Now you can do some layout stuff. Typically the suggestion box should only be displayed with a user typed in a search phrase. And the suggestion box should hidden if the focus is lost. This can be done with some css definition:

.suggestbox {
	position: relative;
}

.suggestbox .resultlist {
	display: block;
	position: absolute;
	z-index: 1;
	left: 2px;
	top: 22px;
	border: 1px solid #CCC;
	background-color: #EEE;
}

To hide the resultlist you can use the f:ajax event ‘blur’

 <f:ajax event="blur" render="suggest_box"
                    listener="#{suggestController.reset}" />

The listener is bound to a backend method which resets the result list. So you can display the complete box in order of the current result. This is the complete code:

JSF Code:

<h:panelGroup layout="block">
	<!-- Process references -->
	<h:panelGroup layout="block" style="margin-bottom:5px;">
		<h:inputText value="#{suggestController.input}">
			<f:ajax event="keyup" render="suggest_box"
				listener="#{suggestController.search('')}" />
			<f:ajax event="blur" render="suggest_box"
				listener="#{suggestController.reset}" />
		</h:inputText>
	</h:panelGroup>
	<h:panelGroup id="suggest_box">
		<h:panelGroup id="suggest_resultlist"
			rendered="#{! empty suggestController.result}">
			<ul>
				<ui:repeat var="entry" value="#{suggestController.result}">
					<li>#{entry}</li>
				</ui:repeat>
			</ul>
		</h:panelGroup>
	</h:panelGroup>
</h:panelGroup>

 SuggestController:

@Named("suggestController")
@RequestScoped
public class SuggestController implements Serializable {

	private static final long serialVersionUID = 1L;
	private List<String> result=null;
	private String query = null;
	private String input =null;
	
	public SuggestController() {
		super();
		result = new ArrayList<String>();
	}

	public String getQuery() {
		return query;
	}

	public void setQuery(String query) {
		this.query = query;
	}

	public String getInput() {
		return input;
	}

	public void setInput(String input) {
		this.input = input;
	}
	
	public void reset(AjaxBehaviorEvent event) {
		 result=new ArrayList<String>();
	}
	
	public void search(String query) {
    	result=new ArrayList<String>();
		result.add("Hallo "  + System.currentTimeMillis());
		result.add("World "+ + System.currentTimeMillis());

	}
	
	public List<String> getResult() {
		return result;
	}

}

4) DELAY AJAX EVENTS

Maybe you run into a problem with the onblur ajax call to hide your overlay section. If the section contains h:command links or buttons the action and actionListeners will not be called because the ajax blur event hides the overlay to early.

With a trick from BalusC you can delay the blur event a little bit. So just add the following jQuery code into your page:

$(document).ready(function() {
	$(".suggestinput").each(function(index, input) {
	    var onblur = input.onblur;
	    input.onblur = null;
	
	    $(input).on("blur", function(event) {
	        delay(function() { onblur.call(input, event); }, 300);
	    });
	    // turn autocomplete of
	    $(this).attr('autocomplete','off');
	});

});

var delay = (function() {
    var timer = 0;

    return function(callback, timeout) {
        clearTimeout(timer);
        timer = setTimeout(callback, timeout);
    };
})();

 

JEE6 – How to package an EAR – Part II.

As I explained in my previous blog entry about JEE6 ear packaging, there is a flexible and powerful way to deploy EARs containing JEE component libraries.

Using maven makes it much easy to build such ear deployment units. The interessting part of the pom.xml of the ear module looks something like this:

 

<build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-ear-plugin</artifactId>
                <version>2.6</version>
                <configuration>
                    <version>6</version>
                    <modules>
                        <webModule>
                            <groupId>myweb</groupId>
                            <artifactId>imixs-web</artifactId>
                            <contextRoot>/test</contextRoot>
                        </webModule>
                        <ejbModule>
                            <groupId>myejb</groupId>
                            <artifactId>imixs-ejb</artifactId>
                        </ejbModule>
                        <JarModule>
                            <groupId>org.imixs.workflow</groupId>
                            <artifactId>imixs-workflow-engine</artifactId>
                            <bundleDir>/</bundleDir>
                        </JarModule>                        
                    </modules>
                </configuration>
            </plugin>
        </plugins>
 ....

In this example the artefact ‘imixs-workflow-engine’ is a component library containingg EJBs. You can refere to those libraries from your ejb module (in this example ‘myejb’) by using the ‘manifestEntries’ tag in your maven ejb module configuration. This is what I explained here.

But what if you need some more additional external libraries containing non-jee-components (simple pojo’s like for example apache commons-xx.jars) ?

You can add those dependencies to your ear pom.xml – so these jars will also become part of the ear root directory. But now you need to add them again to the manifest file of your ejb module if you need access to these libraries. And this will result in a strange situation because indirect dependencies will make it impossible for you to manage your manifest file manually.

I run in this situation when a need the apache fop-1.0 library in one of my ejb components.

But the solution is again quite simple when using maven and the ear-plugin. The plugin provides a configuration tag named ‘defaultLibBundleDir’. And you simply need to the the value to ‘lib’ to get all your libraries moved in the default lib directory of an ear:

<plugin>
       <groupId>org.apache.maven.plugins</groupId>
       <artifactId>maven-ear-plugin</artifactId>
       <version>2.6</version>
       <configuration>
            <version>6</version>
            <defaultLibBundleDir>lib</defaultLibBundleDir>
            <modules> 
         .....
  ....
</plugin>

But you need to be careful because also your jee-component libraries will be moved into that location if you did not overwrite the default behaviour now.  You can do this by declaring each of your jee component libraries as a ‘JarModule’ where you specifiy the ‘bundleDir’ with ‘/’:

....
<module>
 ....
  <JarModule>
       <groupId>org.imixs.workflow</groupId>
       <artifactId>imixs-workflow-core</artifactId>
       <bundleDir>/</bundleDir>
  </JarModule>
</module>
...

This will result in a ear structure where your own jee-components will become part of the root of your ear, and all other library dependencies will be moved to the /lib directory of your ear. So any libary can be seen from your ejb, web and component modules. And you jee-component.jars will still be parsed for JEE annotations during deployment.

I hope this helps you to build you own custom enterprise applications using all the strength of JEE.

 

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">

 

JSF 2.0 – The action event model

If you are working with JSF 2.0 there are different ways to interact with backend methods and passing params to action methods. A useful link for this topic can also seen here.

So for example if you have a JSF page with the following command link you use different ways to bound your backing bean:

<h:commandLink action="#{workflowController.editAction(workitem)}"
               actionListener="#{workflowController.doEdit}">
         <h:outputText value="click me" />
         <f:setPropertyActionListener
               target="#{workflowController.workitem}" value="#{workitem}" />
</h:commandLink>

The important thing here is the order which the jsf framework will trigger the differnt methods of the backingBean ‘worklfowController’

  1. The actionListener method will be called
  2. The setPropertyActionListener will trigger the setter method of the property ‘workitem’
  3. The action method with a custom param will be called

So in this case you backingBean can look something like this – note that there are two different ways to pass a param:

 

   // first the actionListener method will be called   
   public void doEdit(ActionEvent event) throws Exception {
        // do something...
       .....
    }

   // next the setter for the property will be called
   public void setWorkitem(Data aworkitem) {
        // do something    
   }

   // last the action method will be called
   public String editAction(String action) {
        // do something
        return action;      
    }

 

JUnit and Glassfish 3.1.1 – remote ejb tests

Trying to run a JUnit Test with remote EJB lookups from a GlassFish server 3.1.1 it is a little bit tricky. It seems to me that it is not possible to get the maven dependencies working. The gf_client.jar can not be included using a dependency, although the artefact can be located using the glassfish repository from java.net :

    .....
      <!-- Glassfish -->
          <repository>
                 <id>glassfish-repository</id>
                 <name>Java.net 
                 Repository for Glassfish</name>
                <url>http://download.java.net/maven/glassfish</url>
          </repository>
.....

..and adding a dependecy:

    ...
    <dependency>
            <groupId>org.glassfish.appclient</groupId>
            <artifactId>gf-client</artifactId>
            <version>3.1.1</version>
            <scope>test</scope>
        </dependency>
....

But after all this wont work for me. So the best way is to add the gf_client.jar directly into your classpath.

The gf_client.jar is located in your Glassfish Installation at

$GLASSFISH_HOME/glassfish/lib/gf-client.jar

 

Now you can write a JUnit test with a remot ejb lookup. See the following example for a remote lookup to Imixs Entity Service

 public class TestEntityService {
    EntityServiceRemote entityService = null;

    @Before
    public void setup() {
        try {
            // set jndi name
            String ejbName = "java:global/imixs-workflow-web-sample-0.0.5-SNAPSHOT/EntityService!org.imixs.workflow.jee.ejb.EntityServiceRemote";
            InitialContext ic = new InitialContext();
            entityService = (EntityServiceRemote) ic.lookup(ejbName);
        } catch (Exception e) {
            e.printStackTrace();
            entityService = null;
        }
    }

    @Test
    @Category(org.imixs.workflow.jee.ejb.EntityServiceRemote.class)
    public void testService() {
        Assert.assertNotNull(entityService);
        //....

    }

Note: To run this JUnit test you have to first deploy your test application. After that you junit test can be run.

TESTING SECURED EJBS

If your remote ejb is annotated with the security annotation @RolesAllowed you need to authenticate your remote lookup.

In GlassFish this can be done using the programmatic Login. To setup a programmatic login in your JUnit test first create a File named ‘auth.conf’. The content of that file should look like this:

default { 
com.sun.enterprise.security.auth.login.ClientPasswordLoginModule required debug=false; 
};

Now you can add the programmatic login into your test setup

     @Before
    public void setup() {

        try {
            // set jndi name
            String ejbName = "java:global/imixs-workflow-web-sample-0.0.5-SNAPSHOT/EntityService!org.imixs.workflow.jee.ejb.EntityServiceRemote";
            // setup programmatic login for GlassFish 3
            System.setProperty("java.security.auth.login.config", "/home/rsoika/eclipse_37/imixs-workflow/imixs-workflow-engine/src/test/resources/auth.conf"); 
            ProgrammaticLogin programmaticLogin = new ProgrammaticLogin(); 
            // set password
            programmaticLogin.login("Anna", "anna"); 
            InitialContext ic = new InitialContext();
            entityService = (EntityServiceRemote) ic.lookup(ejbName);
        } catch (Exception e) {
            e.printStackTrace();
            entityService = null;
        }
    }

Note: the username/password is defined in this case in a file realm which is the default security realm of my GlassFish

Here are some helpful links:

http://glassfish.java.net/javaee5/ejb/EJB_FAQ.html#StandaloneRemoteEJB

http://www.coderanch.com/t/476090/EJB-JEE/java/EJB-Realms-Remote-Clients

 

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

Rest Service and the HTTPServletReqeust Object

Today I got a strange problem with my REST service which needs a HttpServletRequest object to perform the RemoteUser name.

First I injected the HttpServletRequest as a field into my RestService-Class

....
@Path("/")
@Produces({ "text/html", "application/xml", "application/json" })
@Stateless
public class SystemRestService {
 ...   
	@javax.ws.rs.core.Context
	private static HttpServletRequest servletRequest;
.....

This works fine on my local glassfish server 3.1.1. But after I deployed this into my productive environment (glassfish 3.1) the field ‘servletRequest’ was always null.

The problem here is that injecting the HttpServletRequest into an instance field can become very soon stale. The solution is to annotating a method parameter to assure that the request object is obtained in connection to processing a request.

... 	
@GET
	@Path("/profile.json")
	@Produces("application/json")
	public String getUserByID(@QueryParam("uid") String user,
			@QueryParam("items") String items,@Context HttpServletRequest servletRequest) {
.....

See also this discussion on the coderanch:

http://www.coderanch.com/t/510941/Web-Services/java/Print-Client-IP#2649412