jjviana's Blog

JavaOne Day 1: don´t be Pwned!

There is one talk I would like to comment on today: "Don't Be Pwned: A Very Short Course on Secure Programming in Java".

This talk, presented by Robert Seacord  and Dean Sutherland from SEI/CERT, was the scariest Java talk I have ever been to.

Do you believe the software you write is secure enough?  Believing it or not, I suggest you take some time to read through the CERT Oracle Secure Coding Standard for Java. It is a guide prepared by the guys at CERT that describe the main concerns you should have when writing secure code in Java. Or to put it in another way, it describes the many ways you are probably writing insecure code right now.

I never imagined how dangerous class inheritance can be in bypassing security managers, or how simple it is to crash most JVM versions by feeding them specially crafted floating-point numbers. Even if you don´t memorize all the guide rules, reading it is definitely an eye opener.

This will be required literature for all my team members and students from now on.

Heroku Java Support: Simple? or Simplistic?

Heroku, the PaaS cloud owned by salesforce.com, announced a few days ago support for the Java language. In the process they declared Java EE to be irrelevant in the cloud world. Is that so?

I try to embrace anything that helps me develop, test or deploy code faster. Cloud Computing has the potential to bring radical improvements to all these areas, hence I have been following its developments closely over the last couple of years.

Cloud platforms come in different flavours, the main ones being IaaS (Infrastructure as a Service) an PaaS (Platform as a Service). IaaS clouds, like Amazon EC2 or Rackspace Cloud, provide infrastructure building blocks (CPUs, storage space, ip addresses, firewalls, etc.) in a programatic way. In a way, they transform infrastructure in code. You can then lay the software stack you need over these building blocks: operating systems, databases,virtual machines, programming languages etc. Lots of decisions to make.

PaaS clouds, like Google AppEngine or Heroku, would like to make some of these decisions for you.They restrict the menu of available stack components to a few supported configurations. In return, they relief you from the burden of having to manage these components. You stop thinking about "servers" and think instead about "applications" , "components" or other logical deployment units.

I am a big fan of IaaS clouds, but have yet to be convinced of the usefulness of PaaS. Take Heroku for example: their announcement about Java support revolves around the revolutionary idea of embedding Jetty inside your application so that your web application contains the web server, and not the other way around. They go to some lengths in criticizing Java EE for its complexity and to show how this containerless approach is going to make your life easier.

The problem is, this approach is not new: I have personally written applications using this architecture for a while now, going as far back as 2002. The idea of going containerless has a certain lure, but as the application grows  you start to realize its drawbacks. The moment you need a connection pool, or  transaction control, or manageability, or security, you start to recreate the container inside your application, one third-party library at a time. Fast forward a few releases and now your application is a collection of 150Mb of conflicting jar files.You have recreated something like the Java EE container inside your application, at a great cost and zero standardization.

PaaS vendors: as a User, I don´t want my platform to be simple, I want it to make my life simpler. These are different goals.

Simple != Simplistic.

RainToolkit 1.3 is available

Just a quick note to annountce the availability of RainToolkit 1.3.

It can be downloaded at:  http://www.logicstyle.com/raintoolkit.html

If you manage Amazon EC2 resources from the command-line, Rain Toolkit can make your life easier by automating a lot of common repetitive tasks.

New features in this release include:

• Support for micro instances
• Support for EBS instances
• Support for Amazon Virtual Private Cloud (VPC)

Rain Toolkit is written in Java, using the AWS Java SDK and is released under the GPL v2 license.

mvn classpath:hell

Apache maven is supposed to solve the classpath hell; or so I´ve been told...

Started using maven 2 in a multi-pom project. One of the requirements is to be able to deploy EAR files to Weblogic.

After looking around it seemed like the most stable way of doing this with maven and Weblogic 10.x is to use the Weblogic Ant task. Not ideal since we are migrating away from Ant, but still okay.

So I happily added the maven antrun plugin to my pom.xml file:

 <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-antrun-plugin</artifactId>
        <version>1.6</version>

        <executions>
          <execution>
            <phase>integration-test</phase>
            <configuration>
              <tasks>
                 <path id="wlappc.classpath">
                <fileset file="${wlFullClient}" />
        </path>

            <taskdef name="wldeploy"
              classname="weblogic.ant.taskdefs.management.WLDeploy" 
            classpathref="wlappc.classpath" />
         <wldeploy action="deploy" verbose="true" debug="true"         
           upload="true" name="Myapp" source="myservice-ear-1.0-SNAPSHOT.ear" 
           user="${deployUser}" password="${deployPassword}" adminurl="${deployURL}" targets="${deployTargets}" />

           ...

Great! Now I can easily deploy my ear file before the integration tests are run.

But now, after all tests are run and Maven then tries to deploy the generated artifact to the remote repository, it fails with the misterious error:

[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error deploying artifact: Failed to transfer file: http://172.30.12.31:8081/nexus/content/repositories/snapshots/groupid/gr.... Return code is: 401

After a few hours of debugging the repository user permissions and the repository installation itself (http error 401 is a permission denied error after all) I was almost giving up hope when it occurred to me to test disabling the antrun plugin execution. Suddently the repository deployment started working again.

It turns our there is something in wlfullclient.jar (the weblogic admin client used by the ant task) that is messing up with the maven deployment plugin. Since there is no way to isolate the classpath between the plugins I had to choose to either deploy to the integration application server or to deploy to the remote repository. I ended up choosing (for now) disabling the remote repository deployment for the EAR artifact:

 <plugin>
               <artifactId>maven-deploy-plugin</artifactId>
               <configuration>
                 <skip>true</skip>
              </configuration>
            </plugin>

   <plugin>

This is hardly an appropriate solution, as now I have to manually manage the copy of these files to the production system.

For a build system that is supposed to get rid of the classpath hell, Maven is turning out to be for me a classpath devil itself (that is not my first classpath problem with Maven ).