Drop By!

It seems to me that there are basically two ways to get started with the examples of the Jersey distribution (see also Java Webservices – Relationship between JAX-WS, JAX-RS, Metro and Jersey) in Glassfish.

First you can use the Glassfish’s update center executing:
$path/updatecenter/bin$ ./updatetool
like described for example in Japod’s blog.
But currently only version 0.4 is available here.

The other way is : download and unzip the newest version of Jersey. In the root directory of the unzipped archive you will find an
ant script, execute it like this:
$path/jersey-0.5-ea$ ant  -f jersey-on-glassfish.xml -Dgf.home=$HOME/bin/glassfish install
with appropriate gf.home property supplied.

If you get an error message similiar to this one:

BUILD FAILED
/home/kostja/Development/jersey/jersey-0.5-ea/jersey-on-glassfish.xml:103: The following error occurred while executing this line:
/home/kostja/Development/jersey/jersey-0.5-ea/jersey-on-glassfish.xml:43: /home/kostja/Development/jersey/jersey-0.5-ea/examples/GlassfishDB not found.

     <!-- copy-example example.name="GlassfishDB"/>
     <update-nb-prop nb.prop.file="${gf.home}/jersey/examples/GlassfishDB/nbproject/project.properties"/ -->

Be aware! This procedures will only install the examples and won’t add auto-magically the jersey jars to Glassfish’s runtime classpath. So
you have to take care by yourself to include the jars to the build target, see the provided examples for the jars needed:

glassfish/jersey/examples/SimpleServlet/nbproject/build-impl.xml:

    <target depends="init" name="library-inclusion-in-archive" unless="dist.ear.dir">
        <copy file="${file.reference.activation.jar}" todir="${build.web.dir}/WEB-INF/lib"/>
        <copy file="${file.reference.jsr250-api.jar}" todir="${build.web.dir}/WEB-INF/lib"/>
        <copy file="${file.reference.persistence-api-1.0.jar}" todir="${build.web.dir}/WEB-INF/lib"/>
        <copy file="${file.reference.asm-3.1.jar}" todir="${build.web.dir}/WEB-INF/lib"/>
        <copy file="${file.reference.jsr311-api.jar}" todir="${build.web.dir}/WEB-INF/lib"/>
        <copy file="${file.reference.jersey.jar}" todir="${build.web.dir}/WEB-INF/lib"/>
    </target>

glassfish/jersey/examples/SimpleServlet/nbproject/project.properties:

# some of this properties are set by jersey-on-glassfish.xml
# during installation
ashome.jersey.lib.dir=../../lib
ashome.lib.dir=../../../lib
...
file.reference.jsr250-api.jar=${ashome.jersey.lib.dir}/jsr250-api.jar
...
file.reference.jersey.jar=${ashome.jersey.lib.dir}/jersey.jar
...
javac.classpath=${file.reference.servlet.jar}\:${file.reference.activation.jar}\:${file.reference.jsr250-api.jar}\:
${file.reference.persistence-api-1.0.jar}\:${file.reference.asm-3.1.jar}\:${file.reference.jsr311-api.jar}\:
${file.reference.jersey.jar}

Have you ever wondered about the relationship of different actors within Java’s Webservice Stack? I did. The key to the right answers you may find watching this list of Glassfish projects.

So there seems to be a simple formula (RI = reference implementation):

JAX-WS = JAVA-API( XML-based Webservices, means mainly WSDL/SOAP though REST is possible too )
RI(JAX-WS) = { javax.xml.ws.**.* , core Web services support } = JAX-WS “RI” [is subset of] Metro
Metro = JAX-WS “RI” + WSIT/Tango ( WSIT/Tango provides support for Security, Reliability, Transactions and Interoperability with .NET 3.0 )

JAX-RS = JAVA-API( RESTful Web Services )
RI(JAX-RS) = { javax.ws.rs.**.* } = Jersey

JAX-WS 2.1 along with JAXB 2.1 is integrated in JDK 6 Update 4 release as is JAX-WS in JDK 6. It is part of Java EE 5 as well. To use Metro 1.1 on JDK6 U4, you just have to put the Metro jars in the classpath. Metro is integrated with Glassfish Application Server.
It is possible to run REST Services with JAX-WS using the appropriate Binding like described in RESTful Web Services.

JAX-RS is yet not finally released (see Schedule). If you are using NetBeans IDE 6.0, you do not need to download the Jersey distribution. Instead, install the RESTful Web Services plugin from the Plugin Manager under the Tools menu. Developing RESTful Webservices is much easier here. Implementing RESTful Web Services in Java provides a good start.

If you are looking for the Metro libraries, either get them from GlassFish (webservices*.jar) , or download them from Metro distribution.

Some nice slides for an Metro/Jersey overview : Metro and Jersey.

To use Metro in your application you will need this jars (see also Metro FAQ):

$METRO_HOME/lib/webservices-rt.jar 
$METRO_HOME/lib/webservices-api.jar 
$METRO_HOME/lib/webservices-extra-api.jar 
$METRO_HOME/lib/webservices-extra.jar

It seems that we finally have got this simple feature for classpath (see Bug ID: 4339262).

Now it is possible to use wildcards in classpath definition:
javac -cp libs/* -verbose -encoding UTF-8 src/mypackage/*.java  -d build/classes

This is a citation from man:java (java-6-sun, linux):

-cp classpath
Specify a list of directories, JAR archives, and ZIP archives to search for class files. Class path entries are separated by colons (:). Specifying -classpath or -cp overrides any setting of the CLASSPATH environment variable.

If -classpath and -cp are not used and CLASSPATH is not set, the user class path consists of the current directory (.).

As a special convenience, a class path element containing a basename of * is considered equivalent to specifying a list of all the files in the directory with the extension .jar or .JAR (a java program cannot tell the difference between the two invocations).

For example, if directory foo contains a.jar and b.JAR, then the class path element foo/* is expanded to a A.jar:b.JAR, except that the order of jar files is unspecified. All jar files in the specified directory, even hidden ones, are included in the list. A classpath entry consisting simply of * expands to a list of all the jar files in the current directory. The CLASSPATH environment variable, where defined, will be similarly expanded. Any classpath wildcard expansion occurs before the Java virtual machine is started — no Java program will ever see unexpanded wildcards except by querying the environment. For example; by invoking System.getenv(“CLASSPATH”).

To see your currently used user directory go to Help – About – Details.

To override the default settings in the file netbeans-install-dir/etc/netbeans.conf you can create a directory etc/ in /home/myhome/.netbeans/6.0 ( with 6.0 being the version number of your NetBeans installation). Then use the default netbeans.conf file from netbeans-install-dir/etc/netbeans.conf as a template to create a user specific settings in /home/myhome/.netbeans/6.0/etc/netbeans.conf (see How do I make my custom startup parameters permanent? ).

For instance you could change you user name (used in templates):

# Options used by NetBeans launcher by default, can be overridden by explicit
# command line switches:
netbeans_default_options="-J-client -J-Xss2m -J-Xms256m -J-XX:PermSize=64m -J-XX:MaxPermSize=200m -J-Xverify:none -J-Duser.name='My Name' -J-Dapple.laf.useScreenMenuBar=true -J-Dswing.aatext=true --fontsize 14"

(… or use Tools -> Template Manager -> User configuration properties .)

Read more about startup parameter for Netbeans IDE in FaqStartupParameters .

It seems there are basically two ways to set the correct author name (opposed to the system user name Eclipse is using per default) in Eclipse as it appears for example within the autogenerated javadoc comments.

First using -vmargs settings:
eclipse -clean -showlocation  -vmargs -Xms512m -Xmx900m  -XX:PermSize=128m  -XX:MaxPermSize=128m -Duser.name="Your full name"

The other one is just by  changing the associated templates in Window -> Preferences -> Java -> Editor -> Templates -> @author , hardcoding the author’s name.

Found this interesting article Complement testing with code inspections which lists and explains 11 common mistakes.

Hier einige freie Bücher von Galileo Computing auf deutsch.

Integrationshandbuch Microsoft-Netzwerk
Ubuntu GNU/Linux
C von A bis Z
Java ist auch eine Insel – umfangreich
Praxisbuch Objektorientierung – enthällt auch moderne Konzepte wie IoC und Dependency Injection (siehe Spring Framework)
JavaScript und Ajax – ist für Ende November versprochen

The Handle System provides an open source implementation of the Handle System protocol (read the license: 4263537/5024).

I was curious to see and learn from the code. Also I am developing webservices using Axis2 and Spring to wrap the Handles Client API. See also Adam Smith’s Article about Developing Handle System Web Services at Cornell University and the source code Cornell University published just yesterday – handle_services.

For that you need more information then provided by the written documentation. This kind of information you can find by studying the source code directly. Furthermore one also might wish to extend the provided resolution mechanism of the included proxy. So I decided to have the source code in the same workspace in Eclipse as my webservice project. How to set up an independend handle server at localhost to play with dummy handles for testing purposes I described here.

Download the hdl6.2.4.tar.gz file from Handle Software Download. From that archive you will need the src.zip (source code) und handle.jar files. Extract the src.zip file . From the handle.jar you will need to extract a library to compile the handle source:

• run jar to extract the package net.cnri: jar xvf handle.jar net/cnri
• build a new jar from the extracted files and folders: jar cvf cnriutil.jar net

You will also need the Java Servlet library ( jsdk.jar). Download it from here: SPECIFICATIONS – Download class files 2.3, rename the downloaded zip file to jsdk.jar.

How to import the code into a Eclipse Java project? There are two issues here – getting the libs right and the not eclipse-friendly project structure. This is the way it worked for me with Eclipse 3.2:

• Created a new, empty Project “hs2k” : File -> New Project , check “Use project folder as root for sources and class file”
• Imported the Handle source: Import -> General -> File System -> Browse to the hdl6.2.4/src folder and select all resources there, check “Create selected folders only”
• Configuring Build path: in Source-tab – set “Default Output Folder” to “hs2k/build”
• There were still errors because some libs are missing in the source code distribution.
• Getting the libs:
  • Created new folder “lib” under the projects root
  • Imported the cnriutil.jar and jsdk.jar into hs2k/lib folder
  • Adding the jars in lib to projects build path: Properties -> Java Build Path -> Libraries -> Add JARs

After that I had still some errors due to 6.0 compiler compliance level. Problem were variables called enum. Enum is a reserved Java keyword now. So I renamed the variables to enm.

There are two advices you can find in the build.xml and build.properties files – setting “maintainerMode = true” and override the build.properties by using user.properties. To use user.properties correctly I had to edit the build.xml file:

<!-- include user.properties file for custom config -->
<property file="user.properties">
<property file="build.properties">

The user.properties:

target = 1.6
# maintainerMode = true

I couldn’t use the maintainer Mode cause the appropriate root_info were not available in the source code. Still I could compile the source code by using the appropriate ant tasks in Eclipse and make server and clients run like described in this post.

… or rather compiled versus interpreted languages. If you use static final sometype varname in Java to define constants belonging to some class and you are using them in other classes you will have to recompile that classes too after changing the value of the constant.The constants get compiled into every class that use them. A problem which does not exist with interpreted languages. In Java you can use enums in some cases instead.

Was looking around to find a simple method to find the fullpath or explicit path for the script running.
After a while of searching I found this useful simple snippet: bash, full filename.
And used it like this in the beginning of the script:

PRG="$0"
OLDPWD=`pwd`
B=`basename $PRG`
P=`dirname $PRG`
#  echo BASE:$B  PATH:$P
cd $P
if [ `pwd` != "/" ]
then
FULLNAME=`pwd`/$B
else
FULLNAME=/$B
fi
echo $FULLNAME
cd $OLDPWD
echo `pwd`

… simple but effectiv.