Who's messing with my classes - IntelliJ! (UPDATED)

So I have the following code in one of my classes:

    public void setName(@NotNull String name) {
        this.name = name;
    }

In some situations when I use them, I get errors like this (I do not want to discuss right now that the annotation is wrong when I am complaining about it throwing errors):

Caused by: java.lang.IllegalArgumentException: Argument 0 for @NotNull
   parameter of org/rhq/core/domain/resource/Resource.setName must not
   be null
        at org.rhq.core.domain.resource.Resource.setName(Resource.java)

 

The @NotNull Annotation is coming from the Jetbrains org.jetbrains.annotations package.

Decompiling Resource.class with jad Resource.class shows this:

    public void setName(String name)
    {
        if(name == null)
        {
            throw new IllegalArgumentException("Argument 0 for @NotNull parameter of org/rhq/core/domain/resource/Resource.setName must not be null");
        } else
        {
            this.name = name;
            return;
        }
    }

So someone is inserting this check for if(name==null) on compile time. As we are building with maven and other team members do not see this, it looks like a local issue. But then, other team members have a very similar environment than I do.

[UPDATE]

I was suspecting IntelliJ already, as my colleague Ian was talking about the @NotNull compiler setting, but I turned that off and on and it had no effect.

After the comment by Scott Vachalek I went over this again -- especially as we are not using the IntelliJ compiler in our maven runs. I enabled the option, and compiled on command line. Nothing happened.

 

 

And then today I was running some unit tests from within IntelliJ and saw the "Looking for classes to compile ..." message in IntelliJ UI and then also messages about compiling. Then ran jad again and saw those checks again.

So it turns out that IntelliJ is compiling my classes with those @NotNull annotations again. And as this is in a maven build, it is putting the resulting classes in the places where a command line compile would also put them. My next command line build will then see that the class files are newer than the sources and not recompile them, but just include them in the resulting artifact.

 

Seemingly common RESTEasy error and a solution

So I was playing with RESTeasy a bit and using the standalone servlet method of exposing REST services was very easy and straightforward.

And then I thought, ok, let me now do the EJB integration on a JBoss AS 4.2.3 - and ran into the following error:

java.lang.RuntimeException: Class is not a root resource.  It, or one of its interfaces must be annotated with @Path: $Proxy862 implements: org.rhq.enterprise.server.rest.ResourceHandlerLocal org.jboss.ejb3.JBossProxy

Which was strange as I did have the @Path annotation present:

@Local
@Produces({"application/json","application/xml","text/plain"})
@Path("/resource")
public interface ResourceHandlerLocal {

Googling around showed, others have/had the same issue; but as so often, no solution was given. After some digging around I found the issue: the error message is a bit misleading, and I was actually missing a @ApplicationPath("/rest") annotation, which defines the "root context" and which is not needed in the simple standalone war case.

So I implemented a subclass of javax.ws.rs.core.Application which is marked with this ApplicationPath annotation and registered it in web.xml:

<!DOCTYPE web-app PUBLIC
 "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
 "http://java.sun.com/dtd/web-app_2_3.dtd" >

<web-app>
    <display-name>RHQ Rest interface</display-name>

    <context-param>
        <param-name>resteasy.jndi.resources</param-name>
        <param-value>rhq/ResourceHandlerBean/local</param-value>
        <description>List of jndi names of EJBs local interfaces that define REST stuff</description>
    </context-param>


    <servlet>
        <servlet-name>Resteasy</servlet-name>
        <servlet-class>
            org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher
        </servlet-class>

        <init-param>
            <param-name>resteasy.scan</param-name>
            <param-value>false</param-value>
        </init-param> <init-param>
            <param-name>javax.ws.rs.Application</param-name>
            <param-value>org.rhq.enterprise.server.rest.RHQApplication</param-value>
        </init-param>
    </servlet>

    <servlet-mapping>
        <servlet-name>Resteasy</servlet-name>
        <url-pattern>/*</url-pattern>
    </servlet-mapping>
</web-app>

And now the REST provider is starting nicely :)

Of course, if you are using JBoss AS 6 or the upcoming AS7, you do not need to go through all this, as they have RESTeasy already integrated and ready to go.

Two nice days at Android DevCamp Stuttgart 2

In Stuttgart, we had an Android Developer Camp organized by the local Google Technology User Group.

This was a two day camp with workshops and a hackathon on the first day and a bar camp style set of sessions on the second one.

Some of the almost 200 plush Androids

On the first day I went to the Hackathon and worked on Android 3 aka Honeycomb migration issues together with Fridger from Openintents. On the second day I was in a few sessions about app mashups, home screen widgets, git and also gave a session that was talking about what I have done in the Android 2->3 migration so far. My hope was to learn from some participants, but it looks like tablets are not yet that popular. Slides of my session are here.

Samsung, who were one of the main sponsors of the event, sent some developer advocates with new 8.9 and 10.1 tablets to play with, which was nice too.

Food was good and the Androids were plenty, so this was a good event. Thanks to all sponsors and the organization team.