Friday, November 30, 2012

My fedora java 7 update

Today I've migrated to java 7 (Oracle version), as our development environment has been "java 7 enabled".

The transition was "rather" smooth, I just had to follow following description: http://fedorasolved.org/Members/zcat/using-sun-java-instead-of-openjdk

When I mentioned "rather", it was not due to description present on the mentioned site :). After I rebooted I could not login to my xfce (or gnome,...), login screen was shown again even after correct password input.

The problem was caused by my laziness. I didn't really read what I copy/pasted :)

After switching to text mode (Ctrl+Alt+F<X>) I've observed some EOF reported problem right after login. And my bash didn't behave :) I had to provide full path when invoking commands.

When thinking of what I've changed, file: /etc/profile.d/sunjava.sh started to be suspicious, after opening it via:
/usr/bin/sudo /usr/bin/vi /etc/profile.d/sunjava.sh
(yes, path didn't work for me somehow :)

my suspect changed to culprit when seeing the content:
export JAVA_HOME=/usr/java/default
export PATH=\$JAVA_HOME/bin:\$PATH
EOF
after fixing it to:
export JAVA_HOME=/usr/java/default
export PATH=$JAVA_HOME/bin:$PATH
and doing the reboot afterwards, via:
/usr/bin/sudo /usr/bin/reboot
all started to work as expected.

So it seems trivial things might become challenges in my hands :)
Now I see why I became a programmer rather than a doctor :)

Friday, November 23, 2012

Maven java.lang.ClassNotFoundException: org.codehaus.plexus.classworlds.launcher.Launcher

Have you ever faced exception like this?
Exception in thread "main" java.lang.NoClassDefFoundError: org/codehaus/plexus/classworlds/launcher/Launcher
Caused by: java.lang.ClassNotFoundException: org.codehaus.plexus.classworlds.launcher.Launcher
        at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
Could not find the main class: org.codehaus.plexus.classworlds.launcher.Launcher.  Program will exit.
My use case was that I had installed maven3 and afterwards tried to use maven2. All the environment variables updates have been setup in:
~/.bashrc
However once trying to use maven2 exception appeared (Even in the new terminal session).
Solution was found based on advice present in: http://cyntech.wordpress.com/2011/03/09/maven-2-error/

Running command:
which mvn
revealed the problem, as I still had in my $PATH the maven3 binary. Even if I appended the maven2, it was there on the later position => maven3 was to be used, but with changed $M2_HOME (reffering to maven 2).

Fixing the $PATH did the job for me.

This might not be your case, therefor as a general sum up of possible root causes, I recommend checking: http://stackoverflow.com/questions/6198677/java-lang-noclassdeffounderror-org-codehaus-plexus-classworlds-launcher-launche

Friday, November 16, 2012

Glassfish 3.1.1 OSE with Hibernate Validator 4.3.0.Final

Goal: Use hibernate validator 4.3.0.Final with Glassfish 3.1.1 OSE.

Lately I came across an issue, that I wasn't able to use the latest stable hibernate validator (hiberante validator 4.3.0.Final) with Glassfish 3.1.1 OSE.

Problem is that older version is beeing used as a glassfish module (glassfish/modules/bean-validator.jar). If you check the contents of the package (in MANIFEST.MF) you'd see that version 4.1.0.Final is beeing used.

OK, so how to deal with that? I've found out that I'm not the only one having issue here.
http://stackoverflow.com/questions/10548931/how-to-upgrade-the-hibernate-validator-4-3-0-final-to-the-glassfish-3-1-2

Suggestion gave me some motivation, as it seems to be possible to achieve :)

As I'm using ear, the simple solution provided in answer was not feasable for me (as it was a war case). OK, let's see how far we can get. There are multiple references (finally I ended up with the following 2 links):
I read the later one, as it seemd like a good idea to learn creating modules deployable to glassfish, however even if I created maven osgi bundle it neither contained all the dependencies required nor the descriptor seemed to be OK. Sounds like a wrong way for me then.

Going back to the 1.st link, I found following svn repository and tried to build things: https://svn.java.net/svn/glassfish~svn/trunk/external/source-build
However only once it has been achieved (and the way there was quite long) I realized that this just rebuilds the hibernate validator with it's dependencies, and that is of course not needed, as these are already built and available in public maven repositories :).

OK, going via next steps in the article, I ended up with the following solution:
  1. checked out glassfish sources
    svn co https://svn.java.net/svn/hk2~svn/branches/hk2-gf-3.1.1/
    
  2. updated bean-validation related pom, see my diff:
    Index: pom.xml
    ===================================================================
    --- pom.xml (revision 4105)
    +++ pom.xml (working copy)
    @@ -54,9 +54,10 @@
              maven-bundle-plugin and hk2-maven-plugin together -->
         <packaging>jar</packaging>
         <properties>
    -      <hibernate-validator.version>4.2.0.Final</hibernate-validator.version>
    +      <hibernate-validator.version>4.3.0.Final</hibernate-validator.version>
           <javax.validation.version>1.0</javax.validation.version>
           <slf4j.version>1.6.1</slf4j.version>
    +      <jboss-logging.version>3.1.0.CR2</jboss-logging.version>
         </properties>
         <name>Validation API (JSR 303) version ${javax.validation.version}, Hibernate Validator version ${hibernate-validator.version} and its dependencies repackaged as OSGi bundle</name>
     
    @@ -89,7 +90,7 @@
                             <Embed-Dependency>
                                 <!-- Only specify root artifacts that need to be embedded, everything else
                                      will be pulled in automatically based on Private-Package settings. -->
    -                            *; artifactId=hibernate-validator|slf4j-api|slf4j-jdk14; inline=true
    +                            *; artifactId=hibernate-validator|jboss-logging|slf4j-api|slf4j-jdk14; inline=true
                             </Embed-Dependency>
                             <Export-Package>
                                  <!-- 
    @@ -105,7 +106,7 @@
     
                             <Private-Package>
                                  <!-- Have a private copy of external non-standard dependencies -->
    -                             org.slf4j.*; com.googlecode.jtype.*; org.joda.time.*; org.jsoup.*
    +                             org.jboss.logging.*; org.slf4j.*; com.googlecode.jtype.*; org.joda.time.*; org.jsoup.*
                             </Private-Package>
     
                             <Import-Package>
    @@ -117,6 +118,12 @@
                                    which is a JPA 2 class.
                                -->
                                org.slf4j; org.slf4j.spi; org.slf4j.helpers; version=${slf4j.version}; resolution:=optional,
    +                           org.jboss.logging; version=${jboss-logging.version}; resolution:=optional,
    +                           org.apache.log4j;resolution:=optional,
    +                           org.jboss.logmanager;resolution:=optional,
    +                           com.ibm.uvm.tools;resolution:=optional,
    +                           com.sun.jdmk.comm;resolution:=optional, 
    +                           javax.jmdns;resolution:=optional,
                                javax.persistence.*; version="2.0"; resolution:=optional,
                                *
                            </Import-Package>
    @@ -263,6 +270,13 @@
             </dependency>
     
     
    + <dependency>
    +  <groupId>org.jboss.logging</groupId>
    +  <artifactId>jboss-logging</artifactId>
    +  <version>${jboss-logging.version}</version>
    +            <optional>true</optional>
    + </dependency>
    +
             <!-- We bundle jdk binding inside this OSGi bundle -->
             <dependency>
                <groupId>org.slf4j</groupId>
    
  3. built:
    cd hk2-gf-3.1.1/external/bean-validator
    mvn clean install
    
  4. copied to glassfish modules and removed old one:
    rm ${GLASSFISH_HOME}/glassfish/modules/bean-validator.jar
    cp hk2-gf-3.1.1/external/bean-validator/target/bean-validator-1.1.15-SNAPSHOT.jar ${GLASSFISH_HOME}/glassfish/modules/
    
  5. done :)

Issues? well, we'll see later, during testing :) But very first try worked perfectly.

Comments? Feel free to share, as I'm not the osgi expert (yet :)), so some of my updates might ... let's say won't make too much sense.