Main | Next page »

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

JEE6 and packaging 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....

[Read More]

Eclipse Juno - JST & Glassfish

The J2EE Server Tools providing a comfortable way to integrate the Java EE Servers (e.g. GlassFish) into the Eclipse IDE. For the latest release of Eclipse (4.2 - Juno) the integration is a little bit tricky. 

First you need to instal the JST plugin via menu "Help>install new Software" and search for "server". Select the "JST Server Adapters" and install it.

Next you need to add a extra update site to install the latest GlassFish adapters. Add the followin Update Site URL:

http://download.java.net/glassfish/eclipse/juno

Read also the following blog from Vince Kreamer for deails:

https://blogs.oracle.com/vkraemer/entry/internal_3_1_2_runtime

 

 

 

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.

 

 

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

Disabling Glassfish-specific (Non-portable) JNDI names

Today I run into a problem with my EJB 3.1 application after I tried to deploy more than one app with the same EJB module on the same glassfish domain. This results in a JNDI-Naming conflict telling you, that the EJB name is already bound. But since the new concept of JEE6 global portable jndi names this should not happen? 

Here is a discussion about the problem: http://home.java.net/node/702307

The solution is quite simple as Glassfish provides a new property to disable the generation of the glassfish-specific non-portable  jndi names (which were only provided because of backward compatibility. Simply add the param 'disable-nonportable-jndi-names' with the value 'true' directly into the EJB-Container additional-property section. This will avoid the create of thus names.

See also the following pages for more deails about this topic:

http://download.oracle.com/docs/cd/E18930_01/html/821-2417/gkhtw.html

http://download.oracle.com/docs/cd/E18930_01/html/821-2418/beanx.html#gkndi

http://download.oracle.com/docs/cd/E18930_01/html/821-2416/gglpq.html

RichFaces and Glassfish 3.1

I had some trouble after migration from Glassfish V3.0.1 to Glassfish V3.1 with most of my Richfaces applications using RichFaces 3.3.3.Final. 

There are some post how to configure you Web app with RichFaces 3.3 to get running on JEE6. After all I come to the conclusion that there are some facts you should care about. 

 

1. Use RichFaces 3.3.3.Final  (richfaces-ui-3.3.3.Final.jar, richfaces-impl-3.3.3.Final.jar, richfaces-api-3.3.3.Final)
2. Use jsf-faclets 1.1.15.B1 (jsf-faclets-1.1.15.B1.jar
3. add the 'org.ajax4jsf.application.AjaxViewHandler' to your faces-config.xml file

So my Maven Dependencies looking like that:

 

.....		
<dependency>
	<groupId>com.sun.facelets</groupId>
	<artifactId>jsf-facelets</artifactId>
	<version>1.1.15.B1</version>
</dependency>
<!-- RichFaces -->
<dependency>
	<groupId>org.richfaces.ui</groupId>
	<artifactId>richfaces-ui</artifactId>
	<version>3.3.3.Final</version>
</dependency>
<dependency>
	<groupId>org.richfaces.framework</groupId>
	<artifactId>richfaces-impl</artifactId>
	<version>3.3.3.Final</version>
</dependency> 
  .....

 My faces-config.xml :

....
<application>
	<locale-config>
		<default-locale>en</default-locale>
		<supported-locale>en</supported-locale>
	</locale-config>
	<view-handler>com.sun.facelets.FaceletViewHandler</view-handler>		
	<view-handler>org.ajax4jsf.application.AjaxViewHandler</view-handler>
</application>
.....
		 

 in the web.xml I added the following param:

     <context-param> <param-name>javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER</param-name> <param-value>true</param-value> </context-param>  

With this configuration the application runs on Glassfish 2.1 (JEE5) as also on Glassfish 3.1(JEE6)

 

Glassfish Debug Mode no longer working in Eclipse

I was faced with a strange problem in my eclipse. When I start my glassfish out from eclipse in debug mode the debugger did no work properly. When I set a breakpoint the eclipse ide stops but was unable to open the corresponding java source file. So the code line of a breakpoint was not shown in the editor. So it was impossible to use the debugger.

The reason was because of a bug in an early jdk 1.6 version. I was running the glassfish with OpenJDK 6. And after I changed the glassfish server launch settings in my eclipse IDE from OpenJDK to sun-jdk  1.6.0_22-b04 the debugger works fine again.

here are the details about that issue:

http://ubuntuforums.org/showthread.php?t=1147960

https://bugs.eclipse.org/bugs/show_bug.cgi?id=279137

Incremental deplyoment for Glassfish Server

One of the most frustrating things of Eclipse is the poor support for Maven JEE projects by the Web Tools Plattform (WTP). Especially the  incremental deployment, which is a cool feature of Glassfish Server is not supported by wtp. This was the reason why I started a new project with a small Eclipse Plugin to speedup maven based development of JEE apps in Eclipse:

See the manik-hot-deploy project site: http://code.google.com/p/manik-hot-deploy/ 

If you have any comments ore suggestions about this plugin let me know! 

 

AXIOM jar Conflict in Glassfish 2.1.1

 

Today I found the reason why my ear/web application did not work in Glassfish V 2.1.1. (it works in V 2.1.0) The app deploys but when I try to open the Web context URL I see the following exception in glassfish server.log:

Exception
sending context initialized event to listener instance of class
com.sun.faces.config.ConfigureListener
com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! This
parser does not support specification "null" version "null" at
com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:215)

After some searching I think that the problem was forced by some additional libraries which I provided in my web module.

So after I removed my axiom-api dependency (maven 1.2.7) and I removed xercesImpl-2.6.2 the app works fine again.

RichFaces on Glassfish

Today I run into a deployment problem during I tried to install my RichFaces Application on Glassfish. The situation was realy crazy. At the first look everything works well. But when I tried to add the rich:tree component into one of my pages the page causes an error on my glassfish server.
Even when I select a Node of my Tree Component I got an  

NoClassDefFoundError: org/apache/xerces/xni/parser/XMLConfigurationException

First I tried to add the newest xerces version into my web app. But this generates more and more problems as the xerces lib conflicts with the xerces parser provided by glassfish.

After playing arround with the richfaces config params in the web.xml I found that the nikohtml library was the problem why glassfish did not run the application properply

I have had used the following additional richfaces configuration in my web.mxl (I did no know why)

   <context-param>
        <param-name>org.ajax4jsf.xmlparser.ORDER</param-name>
        <param-value>NEKO, TIDY</param-value>
    </context-param>

And this leads into a problem with the xerces parser included into glassfish.
The solution easy. I simply replaced the NEKO with TIDY

So now I use the following configuration in my web.xml

    <context-param>
        <param-name>org.ajax4jsf.xmlparser.ORDER</param-name>
        <param-value>TIDY</param-value>
    </context-param>

And now the tree component works perfect !

An usefull link will also be this blog:

http://www.javaplex.com/blog/optimizing-jsf-richfaces-applications/

Glassfish & OpenID - JSR-196 with OpenID4Java

Today I implemented a new ServerAuthModule based on JSR-196 using the OpenID4Java library. OpenID4Java is a open source library supporting the Client side authentication process to login a user with an OpenID.

OpenID is an open standard that allows a User to sign into web sites through a single URL (a single digital identity). This URL can be a personal home page, a blog or a web service (e.g from a OpenID Provider like myopenid, Google or yahoo.com) that the user is already using. In any case the user must register only once with his OpenID service provider and therefore he need only one password. Another advantage of using OpenID in your web application is the exemption of hosting and managing user accounts and password informations. You can read more about the details on openid.net.

Please note that I have started a project site to provide a platform for further discussion and development. You will also find souce code from the OpenID-JSR-196 Login Module and a wiki page on the project site:
http://code.google.com/p/openid4java-jsr196/
You are welcome to join this project.

Using JSR-196 and OpenID

There are different solutions available to enable a Web Application to login users with there OpenID account. One of the most auspicious mechanisms to integrate OpenID in JEE Applications is the jsr-196. This authentication service allows web containers to use different login modules - like an external openid provider. JSR-196 is part of Glassfish Server so a Login Mechanism based on the jsr-196 is very easy to use in a JEE or Web application. Ron Monzillo who is the specification lead gives a good overview about the jsr-192 on his blog  "concepts behind JRS-196".

How to Install the OpenID4JavaAuthModule

The OpenID4JavaAuthModule I have written is easy to install. To enable your JEE Web application for OpenID you need a Server plattform supporting JSR-196. The following section will describe the installation steps for a Glassfish Application Server. Glassfish supports JSR-196. But there may be also other web containers supporting JSR-196.

To install the OpenID4Java AuthModule you first need to download the following parts:

• imixs-openid-0.0.3-SNAPSHOT
  Includes my new JSR-196 ServerAuthModule implementation based on the openid4java library.
  
• openid4java-0.9.5.jar
  Includes the official openid4java library and additional tools provided by the OpenID4Java Group.
  

Copy the imixs-openid-0.0.2-SNAPSHOT.jar into the Glassfish Lib folder

[GLASSFISHHOME]/lib/

Extract the the openid4java zip archive and copy the following jars into your Glassfish Domain lib/ext/ folder.

• openid4java-0.9.5.jar
• commons-codec-1.3.jar
• commons-httpclient-3.0.1.jar
• commons-logging-1.03.jar 

The glassfish domain specific /lib folder is located on the following path:

[GLASSFISHHOME]/domains/domain1/lib/ext/

where domain1 is your prefered domain (domain1 is the default domain typical used).

Notice: The tree commons-* libraries are appache utilities which are used by openid4java.

Configuration of the OpenID4JavaAuthModule

Now you can configure the OpenID4JavaAuthModule using the GlassFish Admin Console following the next steps:

1. Make sure the GlassFish Application Server is running. If it is not already running, you can start it using the following command:

      <GF_HOME>bin/asadmin start-domain domain1
   

   where <GF_HOME> is the directory where you installed GlassFish

2. Open the GlassFish Admin Console by pointing your browser to the URL: http://localhost:4848/.
3. Login to the Admin Console by entering your ID and password.
4. Expand the Configuration node at the bottom of the left-hand pane.
5. Navigate to the Security node, expand it, and click MessageSecurity.
   
   
   
   
   
6. Under Message Security Configurations, either open the HttpServlet layer if it already exists, or create it if it doesn't exist by clicking the New button. Clicking the button opens the New Message Security Configuration window.

If you can not see the HttpServlet node you need to create the layer


 Click the "New" button and you can than start to configure the new provider in one step. To do that:


• Set the following in the New Message Security Configuration window:

  Provider Type: server
  Provider ID: OpenIDProvider
  Class Name: org.imixs.openid.openid4java.OpenID4JavaAuthModule

  Do not check the Default Provider: Enabled check box.

   

• Click the OK button. This saves the settings and opens the Message Security Configurations window.
• Click on HttpServlet in the Authentication Layer column.
• Select the Providers tab. This opens the Provider Configuration window.
• Select OpenIDProvider in the Provider ID column you just created. This opens the Edit Provider Configuration window.
• Click the Save button to complete the configuration of the provider.

If the HttpServlet layer already exists, you open first the provider list and add a new Provider:

• Open the HttpServlet layer by selecting it in the Message Security Configurations window.
• Select the Providers tab to open the Provider Configuration window.
  
  
  
  
  
• Click the New button to open the New Provider Configuration window.
• In the Provider Configuration area of the window, set the following:

  Provider Type: server
  Provider ID: OpenIDProvider
  Class Name: org.imixs.openid.openid4java.OpenID4JavaAuthModule

  Do not check the Default Provider: Enabled check box.

For the first configuration this is a little bit confusing as you need to create the HttpServlet Layer. But in general the hole configuration is very simple. 

Also note that the provider configuration utility also provides a dialog box that you can use to configure additional properties. We will use this properties to configure out OpenIDProvider for our applications.

Configure additional Properties

After adding the new OpenIDProvider like described before you can start using the provider in your web application. But there a also a few additional properties which can be configured for each provider instance. You can add these properties by using the box "additional properties at the end of you configuration page:

 

The different properties and there usage are described below:

assign.groups

This property is the most important one. It defines which group will be assigned to a user how has logged on with his OpenID. Typical this is a default group used in your web application. 

debug.stages

This property allows you define different debug stages. So you can follow the different phases during the logon process on the server log. Remove this property to turn the debug modus off to switch off debugging.

loginpage

Per default the login module will prompt the user with a simple login page where he can enter his OpenID. You can replace this default page with a individual page supported by your web application (similar to a form based authentication). I will discus this later.

(The other params - verfiymode and debug - shown in the screenshot are deprecated and can be left)

 

Configuration of your Web Application

Now I will explain how you can configure your web application to use openid as a login mechanism. If you have installed the OpenID Login module like described before this step is quiet easy. 

web.xml & sun-web.xml

The first thing what you should do is remove existing tag login-config like basic or form-based authentification configuration from the web.xml if available. Using JSR-196 you now only need the security-constraint configuration.

This is an example of the security-constraint seciton in my web.xml

....
	<security-constraint>
		<display-name>Access Manager Security Constraint</display-name>
		<web-resource-collection>
			<web-resource-name>AUTHENTICATED_RESOURCE
			</web-resource-name>
			<url-pattern>/pages/*</url-pattern>
		</web-resource-collection>
		<auth-constraint>
			<role-name>org.imixs.ACCESSLEVEL.AUTHORACCESS
			</role-name>
		</auth-constraint>
	</security-constraint>
	
	<security-role>
		<role-name>org.imixs.ACCESSLEVEL.AUTHORACCESS
		</role-name>
	</security-role>
.....

Next you need to link your openid provider configured on glassfish admin client with you web application in the sun-web.xml. 

Therefor you need to add the attriubte "httpservlet-security-provider" with the name of your openid provider. The the following example of my sun-web.xml file:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sun-web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Application Server 9.0 Servlet 2.5//EN" "http://www.sun.com/software/appserver/dtds/sun-web-app_2_5-0.dtd">
<sun-web-app error-url="" httpservlet-security-provider="OpenIDProvider">

	<context-root>/openidtestclient</context-root>

	<security-role-mapping>
		<role-name>org.imixs.ACCESSLEVEL.AUTHORACCESS</role-name>
		<group-name>Author</group-name>
	</security-role-mapping>

	<class-loader delegate="true" />
	<jsp-config>
		<property name="keepgenerated" value="true">
			<description>Keep a copy of the generated servlet class java
				code.</description>
		</property>
	</jsp-config>
</sun-web-app> 

That's it!

Now You will see a default login page if you try to login to your web application

Role Mapping

Notice that we mapped also our default group "Author" to a application specific role name. The group "Author" was configured in the OpenIDProvider property "assign.groups". So each user how have successful authenticated against his OpenID Provider will default to this group and the role  "org.imixs.ACCESSLEVEL.AUTHORACCESS". You can change this settings to the requirements of your application.

Login Form

If you did not specific a login form with the additional property "loginpage" the OpenID Login Module will answer an unautenticated request with an simple login form as shown above.

You can implement you own login form if you like and use this form as the default form for your openidProvider module. 

There for add the property "loginpage"  to your provider configuration and support a valid Page inside your application or a simple HTTP page located on a web server.

This is a simple example for a individual login form based on JSF :

	<form method="get"
		action="#{facesContext.externalContext.requestContextPath}/openid_login">
		<f:facet name="header">
			<h:outputLabel value="#{global.login_title} " />
		</f:facet>
		<h:panelGrid columns="2">
			<h:outputLabel value="#{global.username}:" />
			<h:inputText id="openid_identifier" />

			<h:inputHidden id="return_to"
				value="#{loginMB.serverURI}#{facesContext.externalContext.requestContextPath}/pages/notes.jsf" />

		</h:panelGrid>
		<input type="submit" value="#{global.login}" />


		<!-- BEGIN ID SELECTOR -->
		<script type="text/javascript" id="__openidselector"
			src="https://www.idselector.com/selector/e0ed3a269b77fa785de90aeaa20fa0f985746767"
			charset="utf-8"></script>
		<!-- END ID SELECTOR -->
		<script type="text/javascript">
			var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
			document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
			</script>
						<script type="text/javascript">
			var pageTracker = _gat._getTracker("UA-3469303-6");
			pageTracker._trackPageview();
		</script>
	</form>
 

Your form need to care about three things:

1. The form action method need to point to the method path "/openid_login". This path indicates the OpenIDLogin Module to start an OpenID Login process.
2. The users Input field to enter his OpenID URL should be named "openid_identifier". Make sure that the "name" and "ID" attribute are set to "openid_identifier"
3. The form must support a hidden field "return_to" with points to a page where the user is redirected after login process succeed.
   

 

The ID Selector Script is just a funny script provided by http://www.idselector.com to support the user with a nice widget to simplify using openid.

Conclusion

You can see that using JSR-196 and OpenID4Java is a very comfortable way to support a new and easy to use login mechanism for web applications. For Internet applications openid opens you web site to millions of users. It is easy to use and you don't have to handle all the stuff with managing userids and passwords.

If you have any suggestions or comments let me know.

You can download the source file of my Implementation also from here.

I also want to thank the OpenID4Java Team for there work.

Please note that I have started a project site on googlecode to publish the sources and provide a platform to discuss and exchange experience. You are welcome to join this project.

 http://code.google.com/p/openid4java-jsr196/

Glassfis: Using saxon XSL Processor instat of xerces

Glassfish Application server provides an Xerces XSL Processor. This processor did only support XSL 1.0 but no XSL 2.0 which comes with a lot of additional functions.

So in a Web Application which is doing some XML/XSL transformation the xerces processor will be used per default. To change this behavior you can simply copy the saxon processor into the /lib folder of your web module.

Or if you are using maven add the following dependency into your pom.xml

<dependency>
        <groupId>net.sf.saxon</groupId>
        <artifactId>saxon</artifactId>
        <version>8.7</version>
  </dependency> 

Thats it. Now your web module will run with saxon xml/xsl and you can work with all the cool XSL 2.0 functions.

AWStats and Glassfish

AWStats is a free powerful tool that generates graphically web server statistics. This log analyzer works also in combination with the Glassfish Application Server.

To get the web statistic out form the glassfish server there are a few things to be payed attention for after you have installed AWStats successfully on your server. 

First off all you need to activate the Access Log in Glassfish. The Access Log is switched off per default.

 

Also it maks sense to use a new feature from glassfish which allows to generate a kind of standard log file format called Apache combined log format. This Log format gets out much more informations from a web server statistic. See Jan Luehe's Blog for details.

You can activate the Access Log in Glassfish using the Glassfish Console.

 

To activate the combined log format enter 'combined' in the Format Field.

Next it is also necessary to tell AWStats how to access the daily logfiles generated by glassfish server and which log file format (Apache combined log format) should be used by AWStats. Therefor it is necessary to edit the awstats.config file of your webdomain (on linux the config files are located in /etc/awstats/).

Edit the config File and change two important properties to optimize AWSats to work with glassfish:

LogFile

This property defines the location of the AccessLog files. These files are typical stored in the logs/access folder form the glassfish domain. Set these property like this:

LogFile="/usr/glassfish/domains/domain1/logs/access/server_access_log.%YYYY-0-%MM-0-%DD-0.txt"

where /usr/glassfish/ should point to your glassfish install directory. 

LogFormat

The second property is the LogFormat. This property has a default setting of "4" which indicates to use the Apache common log format. Change this Property to "1" to indicate to use the Apache combined log format.

After this changes the Web statistic of your glassfish server should look cool and gives you all the informations you are looking for.

Tags

Search

Up to 10 Recent Entries

• How to use a jQuery Dialog in JSF 2.0
• using @MultipartConfig in a servlet in GlassFish 3.2.2
• Eclipse Juno (4.2) for Maven Developers
• jQuery Dialog - Submit form with ajax
• Bootstrap and jQuery UI
• JSF f:ajax - how to locate components outside the current context
• Ubuntu - R-E-I-S-U-B: Reboot Even If System Utterly Broken
• Wortmann Terra Mobile 1450 II running Ubuntu!
• The Imixs Workflow project
• Eclipse Juno - slow....

Feeds

• All
• /General
• /Maven
• Comments

Categories

• All
• General
• Maven

Bookmarks

• imxis Workflow Blog (en)
• Imixs Workflow
• imixs Workflow Blog (de)
• imixs.com
• Google +