Continue reading »]]> After I’ve learned about the new Flash scope before a while, I was often f***** by “JSF1095: The response was already committed by the time we tried to set the outgoing cookie for the flash.  Any values stored to the flash will not be available on the next request.“.

After reading all (I think around 15) Pages that google has found about this error, I still had no solution. Some of them thought, it is a RichFaces issue, the other say’s its a PrimeFaces, and so on. But after constructing a lot jsf pages, hoping to find a hint about where the failure comes from, the last idea I had, was debugging through the jsf-impl and glassfish

And there it was: Glassfish chunks the output stream, where each chunk is commited separately. And it looks for me, as if the ELFlash implementation “thinks”, that the complete output is commited after the first chunk was commited, so it gives the message. (while debugging the first chunk was commited after writing the text of an h:outputText component)

The (for me) 100% working solution, was to disable chunking in the glassfish config. This can be done in the admin console via Configuration -> [server-config] -> Network Config -> Protocols -> http-listener-x.

If this is really correct, it also explains, why it was so hard to build a minimal project to reproduce it. If you have a xhtml file blown up with richfaces/icefaces code and ran into the issue, you’ve removed the must from this code to target the problem. And after it works, it seems to be clear, that richfaces/icefaces is the evil part. But by removing nearly the whole code, the file was simply to small to cut it into chunks.

Perhaps this will help you too

Greets from germany
Dirk

Continue reading »]]> One of the new features intruduced with JSF 2 is JSR-303 aka. Bean Validation. With bean validation the input’s are validated against built-in or user defined annotations, placed on the fields, methods or classes.

I’m often in the situation, where I have to validate different values in the same form, depending on what action should be executed. After a lot google’ing and researching, I’ve found the following, pretty easy solution.

Imagine, you have the following managed bean, with the two fields firstname and lastname and a bunch of actions for doing some usefull stuff. But for some obvious reasons one of the actions needs only firstname to be validated, but another action needs firstname and lastname to be validated.

For doing this, we first need the placeholder interfaces for building the two validation groups. I use validate.Both and validate.FirstnameOnly here.

1
2
3
4
5
6
7
8
9
10
11
@ManagedBean

@ViewScoped

public class TestBean implements Serializable {



  @NotNull(groups = {Both.class, FirstnameOnly.class},

           message = "First name must not be empy")

  private String firstname;



  @NotNull(groups = {Both.class},

           message = "Last name must not be empy")

  private String lastname;

Now lets see how to trigger the different validation groups using different commandButtons (or commandLinks, …).
For getting things work, we just add a f:param tag to the commandButtons and assign the full qualified class name of the validation group placeholder interface (If you want more than one, just separate it by comma) to a request parameter (GROUPS in my case).

Now you simply have to attach this value to the validationGroups attribute of the f:validateBean tag.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
<h:form>

  <h:messages/>

  <h:panelGrid columns="2">

    <h:outputText value="First name"/>

    <h:inputText value="#{testBean.firstname}">

      <f:validateBean validationGroups="#{param['GROUPS']}"/>

    </h:inputText>



    <h:outputText value="Last name"/>

    <h:inputText value="#{testBean.lastname}">

      <f:validateBean validationGroups="#{param['GROUPS']}"/>

    </h:inputText>

  </h:panelGrid>



  <h:commandButton value="First and last name"

                   action="#{testBean.someAction}">

    <f:param name="GROUPS" value="validate.Both"/>

  </h:commandButton>



  <h:commandButton value="First name only"

                   action="#{testBean.someAction}">

    <f:param name="GROUPS" value="validate.FirstnameOnly"/>

  </h:commandButton>

</h:form>

If you press the first commandLink now, both fields are validated, and if you press the second, only the first name gets validated.

In simpler cases (also if the current case is really simple), where you just want to exclude some fields from validation, just use the same method for disabling the appropriate validators. This can be done by setting the disabled attribute of the f:validateBean tag using the f:param tag.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
<h:form>

  <h:messages/>

  <h:panelGrid columns="2">

    <h:outputText value="First name"/>

    <h:inputText value="#{testBean.firstname}">

      <f:validateBean />

    </h:inputText>



    <h:outputText value="Last name"/>

    <h:inputText value="#{testBean.lastname}">

      <f:validateBean disabled="#{param['FIRSTNAME_ONLY']}"/>

    </h:inputText>

  </h:panelGrid>



  <h:commandButton value="First and last name"

                   action="#{testBean.someAction}">

    <f:param name="FIRSTNAME_ONLY" value="false"/>

  </h:commandButton>



  <h:commandButton value="First name only"

                   action="#{testBean.someAction}">

    <f:param name="FIRSTNAME_ONLY" value="true"/>

  </h:commandButton>

</h:form>

Continue reading »]]> Overview

In my previous article about configuring a glassfish load balancer, I’ve used the mod_jk connector for the apache webserver.
These time I’m going to show, how to solve this using the mod proxy balancer plugin shipped with the most apache installations. (A “cleaner” way in my oppinion)

A couple of times I’ve tried to get the Sun load balancing plugin working, but without success. This was because of  some operating system issues or other problems.
So after looking around the web, I’ve found some good solutions using apache and the mod_jk connector from the apache tomcat project.

Requirements

• Recent glassfish installation (I use v2.1.1).
• mod_jk tomcat connector.
• Apache tomcat server to get some files from (Use version 5.5.23, others won’t work).
• Apache commons logging
• Apache commons modeler

Installation

1. Configuring the glassfish cluster
   1. Copy the $CATALINA_HOME/server/lib/tomcat-ajp.jar to your $GLASSFISH_HOME/lib directory on each glassfish installation in your cluster.
   2. Also copy the commons-logging.jar and commons-modeler.jar to your $GLASSFISH_HOME/lib directory on each glassfish installation in your cluster.
   3. Now you have to define jvmRoute and com.sun.enterprise.web.connector.enableJK system properties for the cluster (this can be done from the domain administration server)

      asadmin create-jvm-options --target cluster1 "-DjvmRoute=\${AJP_INSTANCE_NAME}"
      asadmin create-jvm-options --target cluster1 "-Dcom.sun.enterprise.web.connector.enableJK=\${AJP_PORT}"

   4. Now you have to define the values for these properties for each instance running in the cluster (this can also be done from the domain administration server).
      This is needed, because the instance name, the user is working on has to be appended to the session id.

      asadmin create-system-properties --target instance1 AJP_INSTANCE_NAME=instance1
      asadmin create-system-properties --target instance1 AJP_PORT=8020

2. Configuring the apache web server
   1. Enable mod_proxy, mod_proxy_http and mod_proxy_balancer on your apache installation.
   2. Create a virtual-host (or use your main server), and copy the following lines to i.
      Be aware, that the route parameters matches the instance names assigned in the previous steps.

      ProxyRequests       Off
      ProxyPreserveHost   On
      
      <Proxy *>
        Order deny,allow
        Allow from all
      </Proxy>
      
      <Location /balancer-manager>    
        SetHandler balancer-manager 
        ProxyPass !  
        Order deny,allow
        Allow from all
      </Location>
      
      <Proxy balancer://cluster>
        BalancerMember http://192.168.0.10:38080 route=instance1
        BalancerMember http://192.168.0.11:38080 route=instance2
        BalancerMember http://192.168.0.12:38080 route=instance3
      </Proxy>
      
      <Location />
        ProxyPass balancer://cluster/ lbmethod=byrequests stickysession=JSESSIONID|jsessionid
      </Location>

   3. Restart all cluster instances and the web server. Your load balancing should be working now.
      Each time a new session is creted by the glassfish, it appends its instance name to the JSESSIONID, so the load balancer can determine on which instance to route the request.
      If one instance crashes, the load balancer will notice this and redirects all requests to another instance. If you have enabled session replication, your old session will be resumed there.

   Further reading

   • enable session replication
   • setting up a glassfish cluster
   • mod proxy balancer documentation

Continue reading »]]> Overview

After I looked around the web, I’ve found a few good howto’s about glassfish cluster configuration, but either they use only single machine clusters or they have some other disadvantages in my eyes. So I’ve decided to write my own article about this.

This article will describes how to set up a two machine cluster which consists of the domain administration server (DAS) and a “normal” node. Thereby the DAS also works as such a normal node.

This article uses Glassfish v2.1.

Before the installation

You have to ensure, that your network is configured properly, especially the dns system. If there are problems, there will be curious problems while setting all up. I’ve done this using the hosts file.

10.0.0.1   das-host
10.0.0.2   node2-host
10.0.0.x   nodex-host

The next thing is the firewall. The nodes communicating using a couple of ports. For setup and testing I’ve configured my firewalls to accept everything from all the other nodes, so there are no problems for the nodes to communicate with each other.

Setting up the DAS

Because the DAS server needs cluster support, we have to configure this first.
There are two ways to do this.

• install the glassfish server using:

  ant -f setup-cluster.xml

• activate cluster support using the admin console
  1. go the the admin console (e.g. http://localhost:4848)
  2. select from the common task: Enable Cluster Support

Now start up the server using:

asadmin start-domain domain1

In the next steps, I will create the cluster, then a node-agent and one instance running on the DAS server using the cli.

In most cases you have to specifiy your admin username and password. This can be done using the –user and –passwordfile parameters, but for simpler reading I will omit this. The server will ask you in this case.

1. Create the cluster:

   asadmin create-cluster cluster1

   This creates a cluster on the local server (the DAS) with the name cluster1.

2. Create the node agent:

   asadmin create-node-agent das-agent

   This will create the node agent for the current node.

3. Create the instance for the current node:

   asadmin create-instance --nodeagent das-agent --cluster cluster1 instance1

   This will create the instance instance1 associated with the node agent das-agent and the cluster cluster1.

4. Now start up the node agent and the associated instance:

   asadmin start-node-agent --syncinstances=true --startinstances=true das-agent

   • –syncinstances=true says that the node agent should synchronize its instances with the central repository of the DAS
   • –startinstances=true says the the node agent should start all its instances (instance1 in our case)

Now the domain administration server is up and running.
The first node is also running.

Setting up the second node

Now come to setup the second node.
Because the second node should only work a “computing” node, we do not need to install the whole application server, just a node agent.
I omit user and password parameters here too. You have to enter the DAS login informations when asked for.

1. Install the node agent:

   ant -f setup-cluster.xml create-node-agent -Ddas.host=das-host -Dnodeagent.name=node2-agent

   • -Ddas.host=das-host sets the hostname of the domain administration server
   • -Dnodeagent.name=node2-agent sets the name of the local node agent
2. Create the new instance:

   asadmin create-instance --host das-host --nodeagent node2-agent --cluster cluster1 instance2

   This will create the new instance associated with the node agent node2-agent and the cluster cluster1. The –host parameter specifies the hostname of the domain administration server.

3. Start the instance:

   asadmin start-node-agent --syncinstances=true --startinstances=true node2-agent

   Now the local node agent starts, synchronizes with the das server and starts all local instances (only instance2 in our case)

Now your cluster is running with two nodes. To add more nodes, just repeat the three above steps as much as you want.

Deploying applications to the cluster

For deploying applications to the cluster, just type on the das server

asadmin deploy --user admin --target cluster1 MyApplication.ear

This will deploy the application to the whole cluster.

For further reading

• Enable glassfish session replication
• create-cluster command
• create-node-agent command
• create-instance command
• start-node-agent command

Continue reading »]]> The Workflow Editor is a part of the net-linx application nxApex. The users of this application are phone directory publishers. Service order is a process to import customer information like address, phone number, placement information, etc and to create and update the existing information in the customer database by creating, deleting or updating this information.

This is a rather complex process and it is different from publisher to publisher. In the past the service order module has been customized for each publisher.

The new workflow editor is used to edit flexible workflows that can be adopted easily by configuration personnel. On the development of this module external student apprentices took part together with experienced internal Java developers.

Workflow Overview

The Workflow Editor is meant for system administrator use only. The information provided in this module is technical and not meant for end user’s view.

The workflow for service order and other DAQ processes is specified in workflow configuration file.
The workflow configuration file contains all workflows. A workflow is always bound to a record type. You can define more than one workflow for a record type. The workflow which should be used must be marked as default.

A workflow can contain the following items: transformation items, validation items, search items and processing items, process flow items, and actions.

All changes made to the record data during the processing of the workflow are discarded after the workflow is finished if not otherwise specified. (See transformation item). Changes made to the administrative data (status, status messages) are saved to the database.

A workflow defines the sequence in which the rules should be processed and the actions depending on the output value of one rule. Rules are for example matching rules.

A workflow consists of a list of workflow items. These workflow items define the rules which should be used and the actions which should be taken on a specific rule output.
If no action is defined for a specific output value is defined, a default action will be used.
The default action for the output values ‘NotUsed’ and ‘Ok’ is ‘Goto Next Item’. The default action for ‘Error’ is ‘Reject Immediate’.
Every action is defined by an action code and a number of parameters.

Continue reading »]]> PathFinder is an application for visualizing path finding algorithms written in by Armin and me.

The source code of pathfinder was published at sourceforge.net (project page).

The application can visualize the whole calculation of the implemented path finding algorithms.
These algorithms are:

• A*
• Depth first
• Breadth first
• Hill climbing
• Beam search
• British museum
• Branch and bound
• Dijkstra
• Depth limited
• Great deluge

Because of a very generic and abstract application design it is very simple to add new algorithms to the repository.

The core data model of PathFinder is a more or less simple graph (nodes connected by edges), that can be overlayed by an image for better visualization (e.g. a map like in the upper picture).
The algorithms try to find a path from a start node to a destination nodes. Depending on the choosen algorithm this path should be the shortest path or just one path. Using the build in graph editor (picture below), the user is able to simply create own graphs.

The most of these algorithms can be heavily parameterized to control the way the algorithm works.
While working, the algorithm notifies the application about each calculation step. So, after the algorithm completes, the user is able to re-run the calculation in every speed or just step by step.
This is great for understandig how a algorithm works or to look for weaknesses in a new algorithm.

After a calculation completes, also some statistics are stored in a history.
Some of these values are:

• Time for calculation
• Steps in the graph model
• Length of the path (and the air distance between start and destination for comparison)
• Count of backtracking nodes (this are nodes visited by the algorithm for calculation but not used in the path)
• The parameters given to the algorithm

Using the history, it is possible to compare differend algorithms or different parameters with each other.
Therefore the pure statistic values can be compared, or the paths can be viewed together on the same graph. So it is very easy to see the differences of algorithms or the impacts of parameters.

The application is written completely in Java (1.6 standard edition) and was part of a projekt at our university.