//log//

At the moment I am heavily into playing around with server-sided OSGi, mainly to get knee-deep into the Eclipse RAP plaform for a given use case, and I already had to experience quite some pain resulting from the requirement to have a RAP application packed to a .war file and deployed to a local application server (Glassfish V3 Prelude in our testbed system). The innoopract RAP blog has a short outline on how to do so, even though this way of building and packaging the application is, well, rather clumsy. There eventually is only one really important thing to add:

Deploying the OSGi web application to a tomcat container, there is the chance of enabling the Equinox OSGi Console, a tool which is in my opinion strictly required to do even basic debugging whenever your server-sided equinox application does misbehave in a strange way. While this works fine on Windows it seems, GNU/Linux or Solaris users eventually will suffer here as, there, starting tomcat using the $CATALINA_HOME/bin/catalina.sh start command, the container itself will go to the background and keep on running there, just dumping standard output to a preconfigured log file. Having OSGi console enabled, so, will flood your tomcat logs with “osgi>” prompts but, asides this, not do anything useful (as reading the logfile, say, using tail of course will not allow for providing any input to the console).

To get the console working on one of these platforms, you should have a look at said $CATALINA_HOME/bin/catalina.sh file, which, being a shell script, should be easily customizable to your needs. In there, find this section of code that does perform the tomcat container startup:


[...]
else
"$_RUNJAVA" $JAVA_OPTS "$LOGGING_CONFIG" $CATALINA_OPTS \
-Djava.endorsed.dirs="$JAVA_ENDORSED_DIRS" -classpath "$CLASSPATH" \
-Dcatalina.base="$CATALINA_BASE" \
-Dcatalina.home="$CATALINA_HOME" \
-Djava.io.tmpdir="$CATALINA_TMPDIR" \
org.apache.catalina.startup.Bootstrap "$@" start \
>> "$CATALINA_BASE"/logs/catalina.out 2>&1 &
[...]


Modify this by commenting out the last line like this:


[...]
else
"$_RUNJAVA" $JAVA_OPTS "$LOGGING_CONFIG" $CATALINA_OPTS \
-Djava.endorsed.dirs="$JAVA_ENDORSED_DIRS" -classpath "$CLASSPATH" \
-Dcatalina.base="$CATALINA_BASE" \
-Dcatalina.home="$CATALINA_HOME" \
-Djava.io.tmpdir="$CATALINA_TMPDIR" \
org.apache.catalina.startup.Bootstrap "$@" start \
#>> "$CATALINA_BASE"/logs/catalina.out 2>&1 &
[...]


… and, again, run $CATALINA_HOME/bin/catalina.sh start. Outcomes of this, as obvious to those who dealt with Unix shell scripts before ( 😉 ): Tomcat will start up in foreground in the very terminal you used for invoking this command and also dump all the output to there, so effectively allowing you to control the OSGi console as soon as the osgi> prompt appears. So from here: Happy debugging in finding why your bundles aren’t correctly loaded / started. 😉

Filed under: