DraK's Klog

Un collèque m'a fait part d'un bout de code très astucieux avec Ant pour obtenir en quelques lignes une liste de noms de fichiers séparés par des virgules:

Code:

Très pratique pour créer une liste de mappings hibernate !

Merci Nicolas

When something goes wrong with JAAS, it's pretty cumbersome to figure out what's going wrong. To help debugging, Sun's JAAS implementation can be made versbose with the following system property:

java.security.auth.debug=value

Where value can be:

• all (turn on all JAAS debugging)
• logincontext (LoginContext debugging)
• policy (access control policy debugging)
• auth (access control debugging)
• combiner (SubjectDomainCombiner debugging)

Configuring a JBoss cluster is tedious because you need multiple machines, you need to configure multiple files on different machines, multicast, ips, shares, network interfaces and etc ... In order to make it easier to test things when working with JBoss clusters, here are a few tips.

First of all, use a virtual environment ! I use VMware Workstation on my development laptop (with virtual ip 192.168.208.2) and configure two debian virtual machines v1 and v2 on a NAT virtual network (192.168.208.x) with DHCP activated. I use a NAT virtual network so that the debian virtual machines can apt-get update from the internet through the dev machine.

I only configure one virtual machine (J1) with java and samba then copy and paste it in order to obtain the second virtual machine J2.

To avoid having multiple configuration files around, I find it convenient to centralize the whole JBoss directory in a shared folder on my windows development machine. I use c:\jboss shared on \\192.168.208.2\jboss in read only mode, I explain why the read only mode a bit later.

I then mount it using smbfs on each virtual JBoss node. It can be automated by adding the following line to your /etc/fstab:

//192.168.208.2/jboss /mnt/jboss smbfs ro,username=yourname,password=yourpasswd 0 0

The shared JBoss configuration must absolutely be mounted read only because it will be used by multiple JBoss instances which must not concurrently modify the same files.

JBoss needs additional configuration here because by default, JBoss creates 4 working directories under the server configuration directory server/all/:

• log: used by log4j and configrued in conf/log4j.xml
• data: used by hsqldb (i think)
• work: used by tomcat
• tmp: used by the jboss micro kernel

Those directories will actually be used in read write mode so we must tell JBoss to use some other directory, specific to each virtual node for its write needs. I use /var/local/jboss.

JBoss allows to do just that with the following property:

jboss.server.home.dir=/var/local/jboss

On the command line, you would pass the property that way:

./bin/run.sh -Djboss.server.home.dir=/var/local/jboss

But to avoid having to remember that and to take advantage of the configuration being centralized on the shared directory on the dev machine, edit the c:\jboss\bin\run.conf file and add the following line at the end:

JAVA_OPTS="$JAVA_OPTS -Djboss.server.home.dir=/var/local/jboss"

Now, you're setup, on each virtual node, you can start the jboss instance directly from the shared mount:

/mnt/jboss/bin/run.sh -c all

The shared /mnt/jboss directory structure will not be modified, all working files will be put in node specific /var/local/jboss sub directories !

Finally, just as you did for the conf/run.conf file, to modify the configuration of cluster nodes, just edit the files directly using the windows editor of your choice under the c:\jboss directory ... All cluster nodes will use those files. Dependencing on whether they are hot deployed or not, you may need to restart all instances of course.

Btw, if someone knows how to restart all nodes in the cluster partition, the tip would be helpfull

Enjoy !

Very handy to make sure architectural rules are not broken.

I didn't even know JBoss had a compensation framework ... very promising.

Macker is a build-time architectural rule checking utility for Java developers. It's meant to model the architectural ideals programmers always dream up for their projects, and then break -- it helps keep code clean and consistent. You can tailor a rules file to suit a specific project's structure, or write some general "good practice" rules for your code. Macker doesn't try to shove anybody else's rules down your throat; it's flexible, and writing a rules file is part of the development process for each unique project.

JAXWS permet aussi de consommer et de fournir des web services de type REST. Ces slides expliquent très clairement comment faire l'un et l'autre.

Like most things relating to Enterprise Architecture, the answer to the question of how to design a Service in a Service-Oriented Architecture (SOA) is "it depends".

Bill Burke proposes a solution based on JMS Dead Letter Queues to transition to failure state upon failure in a jBPM action.

A database refactoring tool, it is not clear though whether it supports schema comparison. It looks like it does, but it is not stated explicitely.

Worth a look.