Archive

Archive for the ‘Java’ Category

wagon-svn

June 2nd, 2009 No comments

wagon-svn to rozszerzenie do Maven2 które umożliwia publikowanie bibliotek do zdalnego repozytorium SVN. Może być ono szczególnie użyteczne dla osób korzystających z Google Code, na przykład dla mnie J. Instalacja biblioteki jest prosto, nie będę jej opisywał, gdyż zrobiło to już kilku boglerów, na przykład Don Brown.

W skrócie, maven2 pozwala określić jakie biblioteki potrzebne są do skompilowania naszej aplikacji. Biblioteki dostępne są w repozytoriach. Aby umieścić nasz projekt w repozytorium możemy korzystać właśnie z wagon-svn.

Z mojego odkrycia cieszę się niezmiernie, gdyż pamiętam że rok temu jeszcze nie było z tym tak prosto.

Categories: Maven Tags:

Tworzenie aplikacji Xuggle Red5 z użyciem Maven2

February 11th, 2009 No comments

Chciałbym zaprosić do mojego projektu jakubiak-red5, którego celem jest połączenie następujących technologii: Red5, Xuggle, Maven2. Xuggle umożliwia obróbkę obrazów wideo w czasie rzeczywistym. Red5 to serwer aplikacji multimedialnych. Maven2 do najwspanialsze narzędzie organizujące proces budowania aplikacji. Chcę mieć to wszystko razem!!!

Mój projekt to w zasadzie skrypt budujący. Jest to instrukcja dla Maven2 jak zbudować serwer Red5 i część (Javową) biblioteki Xuggle. Działa to w następujący sposób. W repozytorium SVN znajduje się struktura projektu Maven wraz z plikami pom.xml. Kod źródłowy bibliotek nie Red5 i Xuggle nie ulega zmianie, gdyż jest połączony z kodem źródłowym oryginalnych projektów z wykorzystaniem svn:externals. Aby zbudować biblioteki wystarczy wpisać mvn clean install. Zakładam że każdy programista Javy już kocha, lub pokocha Mavena w przyszłości dlatego nie będę o nim pisał.

Wynikiem pracy mojego projektu są zależności które można użyć w nowym projekcie – nowej aplikacji Red5 (Red5+Xuggle).

Do boju!

Potrzebne jest Xuggle. Instalacja Xuggle jest prosta w stosunku do tego co potencjału tej biblioteki (przynajmniej pod Windows). Setup.exe.

Kolejna instalacja to Red5. Polecam wypróbować wersje 0.8RC2. Znowu setup.exe. Dla Windows potrzebna jest 32bitowa Java.

Jeszcze binarna Maven2. Pobrać, rozpakować, wypróbować.

Na koniec trzeba pobrać źródła mojego projektu.

svn checkout http://jakubiak-red5.googlecode.com/svn/trunk/ jakubiak-red5-read-only

 

To polecenie pobierze źródła mojego projektu oraz źródła serwera Red5 a także część źródeł projektu Xuggle. Nastał czas na testową kompilację:

cd jakubiak-red5-pom/
mvn clean install
cd ../jakubiak-xuggle-pom/
mvn clean install

 

Zanim ujrzymy ten cudowny komunika przyjdzie nam pobrać z Internetu trochę zależności których z różnych powodów może brakować w repozytoriach Mavena i nie są automatycznie pobierane.

Czas na testy. Trzeba opublikować zbudowane moim skryptem przykłady na serwerze Red5, po prostu skopiować katalogi.

cp -r jakubiak-red5-oflaDemo/target/jakubiak-red5-oflaDemo-0.8-SNAPSHOT/ ../../Program\ Files\ \(x86\)/Red5/webapps/
cp -r jakubiak-xuggle-xuggler-red5-videotranscoder/target/jakubiak-xuggle-xuggler-red5-videotranscoder-1.0-SNAPSHOT/ ../../Program\ Files\ \(x86\)/Red5/webapps/
net start Red5

 

Trzeba uruchomić przeglądarkę Internetową i pobawić się przykładami: http://localhost:5080/demos/ofla_demo.html, http://localhost:5080/demos/publisher.html

Jeżeli chcemy zobaczyć Xuggle w akcji to w programie Publisher łączymy się z aplikacją videotranscoder: rtmp://localhost/videotranscoder a nazwę odtwarzanego strumienia podajemy z prefixem xuggle_.

Moja biblioteka Jakubiak-red5 zastępuje w po części standardowy proces budowania. Red5 i Xuggle budowane są przy użyciu Apache Ant i Ivy (mam dreszcze). Ja buduję je z Maven2. Jest z tym trochę roboty, jednak na pewno się to opłaci. Dzięki temu łatwo jest mi zbudować aplikacji łączącą wiele ciekawych technologii, np.: JPA, Spring. Mogę też zbudować aplikację WAR zawierającą Red5, Xuggle którą odpalę na Apache Tomcat 6. Mogę też przyjemnie pracować z Eclipse IDE.

Najważniejsze, moja biblioteka nie modyfikuje źródeł projektów Xuggle i Red5!

Alternatywą dla mojego skryptu budującego jest dodanie bibliotek JAR Red5 i Xuggle wprost do repozytorium Maven. Jednak w ten sposób ciężko jest zbudować wersję WAR aplikacji Red5. Wersja WAR jest niezmiernie przydatna, napiszę o tym jeszcze kiedyś.

Categories: Java Tags:

Jak uruchomić Xuggle na Red5

January 29th, 2009 No comments
Dziś udało mi się uruchomić demo Xuggle serwerze Red5. Cieszę się z tego niezmiernie, ponieważ te technologie będą odgrywały dużą rolę w przyszłości Internetu. Napisałem już jak działa połączenie Xuggle i Red5. Teraz opisze, jak uruchomiłem Xuggle i Red5 na swoim komputerze z Windows Vista 64bit. Zacząłem od pobrania i instalacji najnowszej wersji serwera Red5 – 0.8RC2. Zainstalowałem też oczywiście aplikację Xuggle. Wersje dla Windows instaluje się trywialnie, poleceniem Setup.exe i restart komputera. Następnie zbudowałem szkielet aplikacji webowej WAR składający się z plików: Potrzebne pliki można pobrać stąd:
  1. http://xuggle.googlecode.com/svn/trunk/repo/share/java/xuggle/xuggle-xuggler-red5/xuggle-xuggler-red5-1.17.117.jar
  2. http://xuggle.googlecode.com/svn/trunk/java/xuggle-xuggler-red5/web/videotranscoder/WEB-INF/red5-web.properties
  3. http://xuggle.googlecode.com/svn/trunk/java/xuggle-xuggler-red5/web/videotranscoder/WEB-INF/red5-web.xml
  4. http://xuggle.googlecode.com/svn/trunk/java/xuggle-xuggler-red5/web/videotranscoder/WEB-INF/web.xml
Następnie wgrałem moją aplikację do katalogu webapps serwera Red5. Korzystając z 32bitowej wersji Javy uruchomiłem serwer Red5. Ustawiłem też zmienne środowiskowe:  
$ export | grep HOME
declare -x JAVA_HOME="C:\\Program Files\\Java\\jdk1.6.0_10"
declare -x RED5_HOME="C:\\Program Files (x86)\\Red5"
declare -x XUGGLE_HOME="C:\\Program Files (x86)\\Xuggle"
    Uruchomiłem Red5: red5.bat. Do testowania użyłem aplikacji demo z serwera Red5 – Publisher. http://localhost:5080/demos/publisher.html. Zwróciłem uwagę, by łączyć się do aplikacji videotranscoder a nie oflaDemo. Pozostałe ustawienia bez zmian. Uruchamiam kamerę i mikrofon i rozpoczynam emisję wideo. Nazwa strumienia antek. Aby zobaczyć efekt działania Xuggle uruchamiam oglądanie wideo. Nazwa: xuggle_antek. Po kilku godzinach prób i przy pomocy Art Clarke udało się. Zobaczyłem swoją drugą twarz! Dzięki Art! W następnym odcinku opiszę jak programować Xuggle używając Eclipse i Maven 2. Najpierw jednak muszę się tego nauczyć i coś zjeść.
Categories: Java Tags:

Red5 – instalacja panelu administratora

January 28th, 2009 4 comments

W największym skrócie Red5 to serwer internetowych aplikacji multimedialnych. Aktualnie przeżywa on okres intensywnego rozwoju. Właśnie udało mi się uruchomić panel administratora, a ponieważ nie jest to sprawa trywialna więc opiszę ją tu by dobrze zapamiętać.

A więc najnowszą wersje Red5 0.8RC2 pobieram ze strony Xuggle. Instaluję zgodnie z instrukcją, czyli rozpakowuję i ustawiam zmienną środowiskową RED5_HOME. Następnie uruchomiam aplikację Installer: http://localhost:5080/installer/, instaluję aplikację admin i restartuję Red5. Następnie, jak to opisano na forum, rejestruję się: http://localhost:5080/admin/register.html. Po rejestracji ponownie restartuję Red5. Teraz już mogę się zalogować: http://localhost:5080/demos/adminPanel.html

W panelu administratora mogę przejrzeć listę włączonych aplikacji, zobaczyć aktualnie podłączonych klientów, sprawdzić transfer.

A teraz wracam do nauki tematu Xuggle – Red5.

Categories: Java, Red5 Tags:

Xuggle

January 26th, 2009 3 comments

Dziś, z zawodową ciekawością zacząłem przyglądać się projektowi Xuggle.

Xuggle umożliwia kodowanie, dekodowanie i obróbkę wideo w czasie rzeczywistym!!! Xuggle może być kluczem do połączenia potęgi biblioteki FFmpeg z potęgą Javy. Korzystając z Xuggle uda się napisać odtwarzacz filmów wideo w Javie i dodatkowo wyposażyć go w funkcje do edycji video. Wyczytałem (i mam zamiar to przetestować), że Xuggle współpracuje z serwerem Red5. Red5 + Xuggle otwiera świat możliwości w dziedzinie aplikacji video – internetowych. Będę w tym temacie.

Categories: Java, Red5 Tags:

Wyłączenie testów maven poprzez konfigurację

July 25th, 2008 No comments

Aby wyłączyć cykl testów z procesu budowania aplikacji wystarczy uruchomić maven z opcją:

mvn –Dmaven.test.skip=true clean install

Jednak to nie do końca mi pasuje. Potrzebuję wyłączyć testy poprzez konfigurację. Plik settings.xml wygląda tak:

<?xml version=“1.0″ encoding=“UTF-8″?>

<settings xmlns=“http://maven.apache.org/POM/4.0.0″ xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”

    xsi:schemaLocation=“http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd”>

    <profiles>

        <profile>

            <id>skiptest</id>

            <properties>

                <maven.test.skip>true</maven.test.skip>

            </properties>

        </profile>

        <profile>

            <id>test</id>

            <properties>

                <maven.test.skip>false</maven.test.skip>

            </properties>

        </profile>

    </profiles>

    <activeProfiles>

        <activeProfile>skiptest</activeProfile>

    </activeProfiles>

</settings>

Używając tej konfiguracji maven uruchomi się bez testów. Oczywiście włączenie testów jest możliwe:

mvn –Ptest clean install

Nie należy nadużywać automatycznego wyłączania testów z cyklu budowania aplikacji. Moja konfiguracja jest dozwolona tylko w szczególnych przypadkach.

Categories: Java Tags:

Jetty i crontab

April 10th, 2008 No comments
Zmodyfikowałem skrypt startowy Jetty tak, żeby serwer mógł startować z crontab’a. To trywialny kod, ale ponieważ słabo znam bash’a więc się z niego cieszę (moje modyfikacje na samym dole).
vs9624:~# cat /etc/init.d/jetty.sh
#!/bin/sh
#
# Startup script for jetty under *nix systems (it works under NT/cygwin too).
#
# Configuration files
#
# /etc/default/jetty
#   If it exists, this is read at the start of script. It may perform any
#   sequence of shell commands, like setting relevant environment variables.
#
# $HOME/.jettyrc
#   If it exists, this is read at the start of script. It may perform any
#   sequence of shell commands, like setting relevant environment variables.
#
# /etc/jetty.conf
#   If found, and no configurations were given on the command line,
#   the file will be used as this script's configuration.
#   Each line in the file may contain:
#     - A comment denoted by the pound (#) sign as first non-blank character.
#     - The path to a regular file, which will be passed to jetty as a
#       config.xml file.
#     - The path to a directory. Each *.xml file in the directory will be
#       passed to jetty as a config.xml file.
#
#   The files will be checked for existence before being passed to jetty.
#
# $JETTY_HOME/etc/jetty.xml
#   If found, used as this script's configuration file, but only if
#   /etc/jetty.conf was not present. See above.
#
# Configuration variables
#
# JAVA_HOME
#   Home of Java installation.
#
# JAVA
#   Command to invoke Java. If not set, $JAVA_HOME/bin/java will be
#   used.
#
# JAVA_OPTIONS
#   Extra options to pass to the JVM
#
# JETTY_HOME
#   Where Jetty is installed. If not set, the script will try go
#   guess it by first looking at the invocation path for the script,
#   and then by looking in standard locations as $HOME/opt/jetty
#   and /opt/jetty. The java system property "jetty.home" will be
#   set to this value for use by configure.xml files, f.e.:
#
#    /webapps/jetty.war
#
# JETTY_CONSOLE
#   Where Jetty console output should go. Defaults to first writeable of
#      /dev/console
#      /dev/tty
#
# JETTY_PORT
#   Override the default port for Jetty servers. If not set then the
#   default value in the xml configuration file will be used. The java
#   system property "jetty.port" will be set to this value for use in
#   configure.xml files. For example, the following idiom is widely
#   used in the demo config files to respect this property in Listener
#   configuration elements:
#
#    
#
#   Note: that the config file could ignore this property simply by saying:
#
#    8080
#
# JETTY_RUN
#   Where the jetty.pid file should be stored. It defaults to the
#   first available of /var/run, /usr/var/run, and /tmp if not set.
#
# JETTY_PID
#   The Jetty PID file, defaults to $JETTY_RUN/jetty.pid
#
# JETTY_ARGS
#   The default arguments to pass to jetty.
#

usage()
{
    echo "Usage: $0 {start|stop|run|restart|check|supervise} [ CONFIGS ... ] "
    exit 1
}

[ $# -gt 0 ] || usage

TMPJ=/tmp/j$$

##################################################
# Get the action & configs
##################################################

ACTION=$1
shift
ARGS="$*"
CONFIGS=""

##################################################
# Find directory function
##################################################
findDirectory()
{
    OP=$1
    shift
    for L in $* ; do
        [ $OP $L ] || continue
        echo $L
        break
    done
}


##################################################
# See if there's a default configuration file
##################################################
if [ -f /etc/default/jetty ] ; then
  . /etc/default/jetty
fi

##################################################
# See if there's a user-specific configuration file
##################################################
if [ -f $HOME/.jettyrc ] ; then
  . $HOME/.jettyrc
fi


##################################################
# Jetty's hallmark
##################################################
JETTY_INSTALL_TRACE_FILE="start.jar"


##################################################
# Try to determine JETTY_HOME if not set
##################################################
if [ -z "$JETTY_HOME" ]
then
  JETTY_HOME_1=`dirname "$0"`
  JETTY_HOME_1=`dirname "$JETTY_HOME_1"`
  if [ -f "${JETTY_HOME_1}/${JETTY_INSTALL_TRACE_FILE}" ] ;
  then
     JETTY_HOME=${JETTY_HOME_1}
  fi
fi


##################################################
# if no JETTY_HOME, search likely locations.
##################################################
if [ "$JETTY_HOME" = "" ] ; then
  STANDARD_LOCATIONS="           \
        $HOME                    \
        $HOME/src                \
        ${HOME}/opt/             \
        /opt                     \
        /java                    \
        /usr/share               \
        /usr/share/java          \
        /usr/local               \
        /usr/local/share         \
        /usr/local/share/java    \
        /home                    \
        "
  JETTY_DIR_NAMES="              \
        Jetty                    \
        jetty                    \
        Jetty-*                  \
        jetty-*                  \
        "

  JETTY_HOME=
  for L in $STANDARD_LOCATIONS
  do
     for N in $JETTY_DIR_NAMES
     do
         if [ -d $L/$N ] && [ -f "$L/${N}/${JETTY_INSTALL_TRACE_FILE}" ] ;
         then
            JETTY_HOME="$L/$N"
            echo "Defaulting JETTY_HOME to $JETTY_HOME"
         fi
     done
     [ ! -z "$JETTY_HOME" ] && break
  done
fi

##################################################
# No JETTY_HOME yet? We're out of luck!
##################################################
if [ -z "$JETTY_HOME" ] ; then
    echo "** ERROR: JETTY_HOME not set, you need to set it or install in a standard location"
    exit 1
fi

#####################################################
# Check that jetty is where we think it is
#####################################################
if [ ! -r $JETTY_HOME/$JETTY_INSTALL_TRACE_FILE ]
then
   echo "** ERROR: Oops! Jetty doesn't appear to be installed in $JETTY_HOME"
   echo "** ERROR:  $JETTY_HOME/$JETTY_INSTALL_TRACE_FILE is not readable!"
   exit 1
fi


###########################################################
# Get the list of config.xml files from the command line.
###########################################################
if [ ! -z "$ARGS" ]
then
  for A in $ARGS
  do
    if [ -f $A ]
    then
       CONF="$A"
    elif [ -f $JETTY_HOME/etc/$A ]
    then
       CONF="$JETTY_HOME/etc/$A"
    elif [ -f ${A}.xml ]
    then
       CONF="${A}.xml"
    elif [ -f $JETTY_HOME/etc/${A}.xml ]
    then
       CONF="$JETTY_HOME/etc/${A}.xml"
    else
       echo "** ERROR: Cannot find configuration '$A' specified in the command line."
       exit 1
    fi
    if [ ! -r $CONF ]
    then
       echo "** ERROR: Cannot read configuration '$A' specified in the command line."
       exit 1
    fi
    CONFIGS="$CONFIGS $CONF"
  done
fi


##################################################
# Try to find this script's configuration file,
# but only if no configurations were given on the
# command line.
##################################################
if [ -z "$JETTY_CONF" ]
then
  if [ -f /etc/jetty.conf ]
  then
     JETTY_CONF=/etc/jetty.conf
  elif [ -f "${JETTY_HOME}/etc/jetty.conf" ]
  then
     JETTY_CONF="${JETTY_HOME}/etc/jetty.conf"
  fi
fi

##################################################
# Read the configuration file if one exists
##################################################
CONFIG_LINES=
if [ -z "$CONFIGS" ] && [ -f "$JETTY_CONF" ] && [ -r "$JETTY_CONF" ]
then
  CONFIG_LINES=`cat $JETTY_CONF | grep -v "^[:space:]*#" | tr "\n" " "`
fi

##################################################
# Get the list of config.xml files from jetty.conf
##################################################
if [ ! -z "${CONFIG_LINES}" ]
then
  for CONF in ${CONFIG_LINES}
  do
    if [ ! -r "$CONF" ]
    then
      echo "** WARNING: Cannot read '$CONF' specified in '$JETTY_CONF'"
    elif [ -f "$CONF" ]
    then
      # assume it's a configure.xml file
      CONFIGS="$CONFIGS $CONF"
    elif [ -d "$CONF" ]
    then
      # assume it's a directory with configure.xml files
      # for example: /etc/jetty.d/
      # sort the files before adding them to the list of CONFIGS
      XML_FILES=`ls ${CONF}/*.xml | sort | tr "\n" " "`
      for FILE in ${XML_FILES}
      do
         if [ -r "$FILE" ] && [ -f "$FILE" ]
         then
            CONFIGS="$CONFIGS $FILE"
         else
           echo "** WARNING: Cannot read '$FILE' specified in '$JETTY_CONF'"
         fi
      done
    else
      echo "** WARNING: Don''t know what to do with '$CONF' specified in '$JETTY_CONF'"
    fi
  done
fi

#####################################################
# Run the standard server if there's nothing else to run
#####################################################
if [ -z "$CONFIGS" ]
then
    CONFIGS="${JETTY_HOME}/etc/jetty.xml"
fi


#####################################################
# Find a location for the pid file
#####################################################
if [  -z "$JETTY_RUN" ]
then
  JETTY_RUN=`findDirectory -w /var/run /usr/var/run /tmp`
fi

#####################################################
# Find a PID for the pid file
#####################################################
if [  -z "$JETTY_PID" ]
then
  JETTY_PID="$JETTY_RUN/jetty.pid"
fi

#####################################################
# Find a location for the jetty console
#####################################################
if [  -z "$JETTY_CONSOLE" ]
then
  if [ -w /dev/console ]
  then
    JETTY_CONSOLE=/dev/console
  else
    JETTY_CONSOLE=/dev/tty
  fi
fi


##################################################
# Check for JAVA_HOME
##################################################
if [ -z "$JAVA_HOME" ]
then
    # If a java runtime is not defined, search the following
    # directories for a JVM and sort by version. Use the highest
    # version number.

    # Java search path
    JAVA_LOCATIONS="\
        /usr/bin \
        /usr/local/bin \
        /usr/local/java \
        /usr/local/jdk \
        /usr/local/jre \
        /opt/java \
        /opt/jdk \
        /opt/jre \
    "
    JAVA_NAMES="java jre kaffe"
    for N in $JAVA_NAMES ; do
        for L in $JAVA_LOCATIONS ; do
            [ -d $L ] || continue
            find $L -name "$N" ! -type d | grep -v threads | while read J ; do
                [ -x $J ] || continue
                VERSION=`eval $J -version 2>&1`
                [ $? = 0 ] || continue
                VERSION=`expr "$VERSION" : '.*"\(1.[0-9\.]*\)"'`
                [ "$VERSION" = "" ] && continue
                expr $VERSION \< 1.2 >/dev/null && continue
                echo $VERSION:$J
            done
        done
    done | sort | tail -1 > $TMPJ
    JAVA=`cat $TMPJ | cut -d: -f2`
    JVERSION=`cat $TMPJ | cut -d: -f1`

    JAVA_HOME=`dirname $JAVA`
    while [ ! -z "$JAVA_HOME" -a "$JAVA_HOME" != "/" -a ! -f "$JAVA_HOME/lib/tools.jar" ] ; do
        JAVA_HOME=`dirname $JAVA_HOME`
    done
    [ "$JAVA_HOME" = "" ] && JAVA_HOME=

    echo "Found JAVA=$JAVA in JAVA_HOME=$JAVA_HOME"
fi


##################################################
# Determine which JVM of version >1.2
# Try to use JAVA_HOME
##################################################
if [ "$JAVA" = "" -a "$JAVA_HOME" != "" ]
then
  if [ ! -z "$JAVACMD" ]
  then
     JAVA="$JAVACMD"
  else
    [ -x $JAVA_HOME/bin/jre -a ! -d $JAVA_HOME/bin/jre ] && JAVA=$JAVA_HOME/bin/jre
    [ -x $JAVA_HOME/bin/java -a ! -d $JAVA_HOME/bin/java ] && JAVA=$JAVA_HOME/bin/java
  fi
fi

if [ "$JAVA" = "" ]
then
    echo "Cannot find a JRE or JDK. Please set JAVA_HOME to a >=1.2 JRE" 2>&2
    exit 1
fi

JAVA_VERSION=`expr "$($JAVA -version 2>&1 | head -1)" : '.*1\.\([0-9]\)'`

#####################################################
# See if JETTY_PORT is defined
#####################################################
if [ "$JETTY_PORT" != "" ]
then
  JAVA_OPTIONS="$JAVA_OPTIONS -Djetty.port=$JETTY_PORT"
fi


#####################################################
# Are we running on Windows? Could be, with Cygwin/NT.
#####################################################
case "`uname`" in
CYGWIN*) PATH_SEPARATOR=";";;
*) PATH_SEPARATOR=":";;
esac


#####################################################
# Add jetty properties to Java VM options.
#####################################################
JAVA_OPTIONS="$JAVA_OPTIONS -Djetty.home=$JETTY_HOME "

#####################################################
# This is how the Jetty server will be started
#####################################################
RUN_CMD="$JAVA $JAVA_OPTIONS -jar $JETTY_HOME/start.jar $JETTY_ARGS $CONFIGS"

#####################################################
# Comment these out after you're happy with what
# the script is doing.
#####################################################
#echo "JETTY_HOME     =  $JETTY_HOME"
#echo "JETTY_CONF     =  $JETTY_CONF"
#echo "JETTY_RUN      =  $JETTY_RUN"
#echo "JETTY_PID      =  $JETTY_PID"
#echo "JETTY_CONSOLE  =  $JETTY_CONSOLE"
#echo "JETTY_ARGS     =  $JETTY_ARGS"
#echo "CONFIGS        =  $CONFIGS"
#echo "JAVA_OPTIONS   =  $JAVA_OPTIONS"
#echo "JAVA           =  $JAVA"


##################################################
# Do the action
##################################################
case "$ACTION" in
  start)
        echo "Starting Jetty: "

        if [ -f $JETTY_PID ]
        then
            echo "Already Running!!"
            exit 1
        fi

        echo "STARTED Jetty `date`" >> $JETTY_CONSOLE

        nohup sh -c "exec $RUN_CMD >>$JETTY_CONSOLE 2>&1" >/dev/null &
        echo $! > $JETTY_PID
        echo "Jetty running pid="`cat $JETTY_PID`

        ;;

  stop)
        PID=`cat $JETTY_PID 2>/dev/null`
        echo "Shutting down Jetty: $PID"
        kill $PID 2>/dev/null
        sleep 2
        kill -9 $PID 2>/dev/null
        rm -f $JETTY_PID
        echo "STOPPED `date`" >>$JETTY_CONSOLE
        ;;

  restart)
        $0 stop $*
        sleep 5
        $0 start $*
        ;;

  supervise)
       #
       # Under control of daemontools supervise monitor which
       # handles restarts and shutdowns via the svc program.
       #
         exec $RUN_CMD
         ;;

  run|demo)
        echo "Running Jetty: "

        if [ -f $JETTY_PID ]
        then
            echo "Already Running!!"
            exit 1
        fi

        exec $RUN_CMD
        ;;

  check)
        echo "Checking arguments to Jetty: "
        echo "JETTY_HOME     =  $JETTY_HOME"
        echo "JETTY_CONF     =  $JETTY_CONF"
        echo "JETTY_RUN      =  $JETTY_RUN"
        echo "JETTY_PID      =  $JETTY_PID"
        echo "JETTY_CONSOLE  =  $JETTY_CONSOLE"
        echo "JETTY_PORT     =  $JETTY_PORT"
        echo "CONFIGS        =  $CONFIGS"
        echo "JAVA_OPTIONS   =  $JAVA_OPTIONS"
        echo "JAVA           =  $JAVA"
        echo "CLASSPATH      =  $CLASSPATH"
        echo "RUN_CMD        =  $RUN_CMD"
        echo

        if [ -f $JETTY_RUN/jetty.pid ]
        then
            echo "Jetty running pid="`cat $JETTY_RUN/jetty.pid`
            exit 0
        fi
        exit 1
        ;;

  cron)
        PID_FILE=$JETTY_RUN/jetty.pid
        if [ -f $PID_FILE ]
        then
          PID=$(cat $PID_FILE)
          NAME=$(ps -o comm= -p $PID)
          if [ "java" = "$NAME" ]
          then
                echo `date` "Jetty running"
                exit 0
          fi
        fi
        echo `date` "Jetty is not working now, trying to start server"
        $0 start $*
        exit 1
        ;;



*)
        usage
        ;;
esac

exit 0
Categories: Java Tags:

Testowanie zdalnych metod w Flex

March 14th, 2008 No comments
Moim zadaniem jest przetestowanie działania zdalnych metod Java uruchamianych w Flex, np.:
netConnection.call( "calculatorService.add", new Responder( onAdd ), 2, 2 );
Do tworzenia testów jednostkowych w Flex zalecana jest biblioteka FlexUnit. Wkładając ten kod do FlexUnit, zauważmy, że nie radzi on sobie z metodami asynchronicznymi – chyba że je specjalnie zaznaczymy:
netConnection.call( "calculatorService.add", new Responder( addAsync(onAdd,5000) ), 2, 2 );
Jednak to jeszcze nie działa. Metoda addAsync dostosowana jest do pracy z zdarzeniami. Próbując uruchomić ten kod otrzymam błąd: TypeError: Error #1034: Type Coercion failed: cannot convert "4" to flash.events.Event. Poradziłem sobie z tym w następujący sposób:
netConnection.call("calculatorService.add", new Responder( myAddAsync( testSum ) ), 2, 2 );

public function testSum(a:Number):void {
  assertEquals(4,a);
}

// 
public function myAddAsync(f:Function):Function {
  // wyciąga dane z eventa
  var f1:Function = function(e:DynamicEvent):void { 
    f.call(this,e.result);
  }
  // buduje asynchroniczną funkcję, operującą na zdarzeniach
  var f2:Function = addAsync(f1, 5000);
  // pakuje odpowiedź serwera do zdarzenia
  var f3:Function = function(a:*):void {
    var e:DynamicEvent = new DynamicEvent("MyDynamicEvent");
    e.result = a;
    f2.call(this, e);
  }
  return f3;
}
Ta ostatnia funkcja wygląda dość dziwnie – ale robi to co musi. Daje mi możliwość budowania testów integracyjnych – współpraca Flex’a z serwerem Red5.
Categories: FLEX, Java, Red5 Tags:

Red5 + Flex + JPA – mapowanie encji

March 12th, 2008 No comments

Udało mi się zamapować klasę Java (reprezentującą encję JPA) do klasy Flash AS3. Serwerem jest RED5, protokołem RTMP, kodowanie obiektów AMF0. Miałem dwa problemy:

  • wybór dostawcy JPA,
  • typ Number we Flashu,

Zacząłem od OpenJPA. Napotkałem na następujący problem. Obiekty klas Java nie zawsze były mapowane do odpowiedników AS3. Otóż gdy OpenJPA pobiera encje z bazy to zwraca klasy Proxy dziedziczące po klasach encji. RED5 nie potrafi sobie z tym poradzić, i nie wie jak ma mapować klasy Proxy dla Flasha. Doraźnym rozwiązaniem problemu jest wybór innego dostawcy JPA – Hibernate. Fajnie, że tak można.

Drugi problem, to mapowanie typu Number. Typ Number występuje w Flashu i teoretycznie nie należy mu przypisywać wartości NULL. Gdy ustawię w Flashu typ Number na NULL i wyślę go do serwera RED5, to w Javie otrzymam 0 (zero) – prawie to samo a działa bardzo źle. Doraźnym rozwiązaniem problemu jest dla mnie zastąpienie typu Number typem String w klasach AS3.

Categories: FLEX, Java, JPA, Red5 Tags:

Blog Jacka Laskowskiego

February 2nd, 2008 1 comment
Przypominam o wybitnym blogu technicznym dotyczącym Javy, prowadzonym przez Jacka Laskowskiego. Otóż, jest konkurs, w którym startuje blog Jacka. Warto na niego głosować, bo zrobił wyjątkowo dużo dla społeczności programistów związanych z językiem Java. Jak na razie liczba oddanych głosów jest żenująco niska. Źle by było, żeby Jacek się zniechęcił i przestał publikować. Ze swojego telefonu wysłałem SMS’a, teraz skrycie wyślę SMS’a z telefonu żony. Zagłosuj na Jacka – to naprawdę dobry blog.
Categories: Java Tags: