Generating Java classes from relaxng

We convert our relaxngs to xsd using trang and then use xjc to create java objects.

locate trang, you will likely have this already if you have spring or eclipse

run trang like this:

java -jar /Users/jw12/trang-20091111/trang.jar sources.rng sources.xsd

find xjc on your system, if you use java you are likely to have xjc already: locate xjc

the one I’m using came with netbeans /Applications/NetBeans/glassfish-3.0.1/glassfish/bin/xjc

use xjc on the xsd file just generated specifying the package with -p:

sh /Applications/NetBeans/glassfish-3.0.1/glassfish/bin/xjc sources.xsd -p org.biodas.jdas.schema.sources

Note that because relaxng is much more descriptive than xsd conflicts and approximations may occur. We removed interleave elements from the rng schemas for generating our java classes so that we didn’t have to test for different types when using the generated java classes. this is because interleave means the classes don’t know if the list of child elements is going to contain a specific type of object as the objects can occur in any order – thus generating a for example getMaintanerOrCoodinate() method. We want seperat getMaintainer() and getCoordinate() methods and removing interleave does that. In the DAS specification it doesn’t specify whether the child elements should be returned in order, however the official W3C xml core data model characterizes element children as:

An ordered list of child information items, in document order. This list contains element….

WE also believe the vast majority of xml writers will produce the elements in order…


Add properties to proserver sources document

in your configuration eg proserver.ini add a properties line with -> seperated key value pairs each sep by ;
 title = CATH Domains
 properties = spec -> DAS/1.6E ; label -> eFamily

In this case the spec option tells the DAS registry that this data source is a 1.6 version. This can be used on a per source basis.

Note: you can also situate your proserver.ini file and call it something else by starting proserver with the -c option and specifying where the config file you want to run is.

Adapters in JDAS

The reason for having the adapters package in JDAS is so that getting objects of specific types from the JAXB generated classes is easier. So for example for the registry code I want to get all sources that have a query_uri that has the server url at the start. The two methods below illustrate without adapters and the same method with adapters:

private List<SOURCE> getDas1SourcesForServerUrl(String serverUrl) {
// SOURCES newSources=new SOURCES();
List<SOURCE> serverSources = new ArrayList<SOURCE>();
List<SOURCE> sourceList = storedSources.getSOURCE();
for (SOURCE source : sourceList) {
List<Object> objects = source.getMAINTAINEROrVERSION();
for (Object object : objects) {
if (object instanceof VERSION) {
System.out.println("version found");
VERSION version = (VERSION) object;
for (Object object1 : version
if (object1 instanceof CAPABILITY) {
if (cap.getQueryUri().startsWith(serverUrl)) {
.println("server url found "
+ serverUrl + "in "
+ cap.getQueryUri());
System.out.println("serverUrl found" + source.getUri());
return sourceList;

with adapters:
public List<SOURCE> getSourcesForServerUrl(String serverUrl) {
List<SOURCE> serverSources = new ArrayList<SOURCE>();
List<SOURCE> sourceList = storedSources.getSOURCE();
for (SOURCE source : sourceList) {
try {
SourceAdapter sourceA = new SourceAdapter(source);
List<VersionAdapter> versionAdapters = sourceA.getVersion();
for (VersionAdapter vA : versionAdapters) {
List<CAPABILITY> caps = vA.getCapabilities();
if (caps.size() > 0) {
if (caps.get(0).getQueryUri().startsWith(serverUrl)) {
} catch (ValidationException e) {
// TODO Auto-generated catch block
return serverSources;

although its not much shorter I’m sure you will agree it is easier to read.

Jackson JSON library now uses JAXB xml annotations to create JSON format responses!

Fantastic stuff!!

RestClient is also useful java open source project for testing REST services alternative content negotiation….

Experience Using JDAS with eclipse

I’m using eclipse (STS spring version) to prototype a new DAS Registry which will be more modular and more REST based.

The other aim is to use the new JDAS library (JAXB based rng-> XSD-> JAXB-> Java DAS objects) rather than the old Dasobert library (hand written handlers and objects).

steps to getting it into eclipseSTS:

add repository to the svn view.

checkout project (right click)

configure using the project wizard

choose normal Java Project as the type in the wizard

set the build path to get dependencies based on maven

right click on pom.xml and select maven install

right click on the project and select m2 maven then select maven dependency management (gets rid of any red errors remaining on classes so adds libraries to eclipse project classpath from the maven pom.xml)

My first issue came after getting the project from SVN when trying to install using the maven pom.xml. Errors occured and the project would not build in eclipse or Netbeans error:

[INFO] Error building POM (may not be this project's POM).
Project ID: org.apache.maven.plugins:maven-surefire-plugin
 POM Location: /homes/[jw12]/.m2/repository/org/apache/maven/plugins/maven-surefire-plugin/2.6/maven-surefire-plugin-2.6.pom
Reason: Not a v4.0.0 POM. for project org.apache.maven.plugins:maven-surefire-plugin at /homes/[jw12]/.m2/repository/org/apache/maven/plugins/maven-surefire-plugin/2.6/maven-surefire-plugin-2.6.pom
[INFO] ------------------------------------------------------------------------
 [INFO] For more information, run Maven with the -e switch
 [INFO] ------------------------------------------------------------------------
 [INFO] Total time: 1 second
 [INFO] Finished at: Thu Jun 30 10:31:15 BST 2011
 [INFO] Final Memory: 3M/81M
 [INFO] ------------------------------------------------------------------------

Changing the version tag from <version>2.6</version> of the surefire plugin solved this so it now looks like this:


so now right clicking on the pom in eclipse and selecting “maven install” succesfully installs the project getting all the dependencies.

Users can now register BigFile files such as BAM, BIGWIG or BIGBED

You can now add bigfile formats such as BAM, BIGBED and BIGWIG using the bigfile-bam, bigfile-bigbed and bigfile-bigwig capabilities. These files are not served from a DAS server but are just available from the web (Thus the urls for these “sources” are not expected to have other capabilities such as a sources command or a format command). People can use the meta data associated with a DAS source or in this case a bigfile to advertise the availability of the file to other researchers. The additional information includes a coordinate system e.g. GRCh_37, Chromosome, Homo sapiens so others know what is the correct sequence to attach the files to. Also descriptions and helpUrls etc.

To register a bigfile login and then go to the register a service page Register new  select the second option “registering a plain file..” then add the meta data for your data file.

Once you have registered your file it will appear in the listSources page – you can filter to show only the bigfile format of the appropriate type using the capabilities dropdown.

Dasregistry Version 4.0 now released – new login

The new version of the DAS Registry has done away with open_id as authentication in favour of good old username and passwords. This makes registering easier for users and as at the last DAS workshop normal https usernames and passwords was accepted as authentication methods for other DAS servers. This move was also prompted by the removal of “sticky” sessions from the Sanger Servers which forced a rewrite of the way the registry logins worked.

Users who already have accounts can follow the instructions on the usual login page in order to set thier passwords.