Wednesday, October 31, 2007 10:00 PM | rahel luethy | 2 comment(s)

simple jaxb

at work, we use the java architecture for xml binding (jaxb) for almost all of our xml input/output. our approach consists of the following steps:

1. we start with the definition of a schema
2. use ant to compile java classes from this schema (via xjc)
3. have a dedicated conversion layer where we translate back and forth between the generated java classes and our business objects.

we have deliberately chosen this architecture because we need total control over xml format changes (1.), want to automate the process as much as possible (2.), and want to keep all xml-related code in a dedicated layer (3.).

this approach works really well for a big project. however, if all you need is reading a simple xml and accessing its data from your java classes (or vice-versa: dumping parts of your java objects to xml), you'd probably want to use something less heavy-weight.

what's quite cool, is that you can also use jaxb for such simple tasks. when the jaxb compiler generates java classes, it uses annotations like @XmlRootElement to map from java types to xml elements. manually annotating your java classes can thus serve as a very simple marshalling/unmarshalling strategy, which doesn't involve a schema, nor an xjc task, nor any further manual work.

here's an example of a simple java → xml → java round-trip:

import java.io.StringReader; import java.io.StringWriter; import javax.xml.bind.JAXBContext; import javax.xml.bind.JAXBException; import javax.xml.bind.Marshaller; import javax.xml.bind.Unmarshaller; import javax.xml.bind.annotation.XmlAttribute; import javax.xml.bind.annotation.XmlRootElement; public class SimpleJAXB { public static void main(String[] args) throws JAXBException { JAXBContext context = JAXBContext.newInstance(Foo.class); Foo foo = new Foo(); foo.setText("bar"); System.out.println("original:\n\t" + foo); StringWriter result = new StringWriter(); Marshaller marshaller = context.createMarshaller(); marshaller.marshal(foo, result); String xml = new String(result.getBuffer()); System.out.println("marshalled:\n\t" + xml); Unmarshaller unmarshaller = context.createUnmarshaller(); Object o = unmarshaller.unmarshal(new StringReader(xml)); System.out.println("unmarshalled:\n\t" + o); } @XmlRootElement private static class Foo { @XmlAttribute private String text; public void setText(String text) { this.text = text; } @Override public String toString() { return "[" + Foo.class.getSimpleName() + "] " + text; } } }

the fact that jaxb 2.0 is part of java 6 makes this approach even more attractive.

server hiccups

apologies for the recent server problems — i finally switched to a new web hosting provider yesternight, so things should be smooth again now.

Tuesday, October 16, 2007 1:06 PM | rahel luethy | 0 comment(s)

linux init scripts

a while ago i posted an example of how to set up samba shares on linux. today, i wanted to configure my box to launch the corresponding smb service automatically upon system startup. it's been a while since i've last fiddled with any of the linux init scripts, and things seem to have changed (at least on Novell/SUSE). i am pretty certain that a lot of purists probably hate how Novell has reinvented the init-script architecture, but to be honest, the new approach is rather convenient. here's how it works:

/etc/init.d contains one init script per service. /etc/init.d/smb is the samba service we are interested in (btw: this is the script that you would also launch if you were starting the service manually). each of these scripts has a well defined structure. among other things, it contains a comment header called INIT INFO, which describes how the service should behave if it is launched as part of an init process. this is how the header looks like for smb:

### BEGIN INIT INFO
# Provides: smb
# Required-Start: $network $remote_fs syslog
# X-UnitedLinux-Should-Start: cupsd winbind nmb
# Required-Stop:
# Default-Start: 3 5
# Default-Stop: 0 1 2 6
# Description: Samba SMB/CIFS file and print server
### END INIT INFO


most importantly, the header lists what other services are required for this one to run, and in what runlevels it should be active in. enabling the service is then just a matter of launching the chkconfig helper script, which will interpret the header information and will adjust the symbolic links of the concerned runlevel directories:

chkconfig smb on

in the case at hand, the smb service will be started automatically whenever the system enters runlevel 3 or 5.