blog feed

Consuming @GenericType REST-webservices with jersey-client

2012-08-30T00:59:02Z

… but jersey always complained about a missing message body reader:

SEVERE: A message body reader for Java class java.util.List, 
and Java type java.util.List<MyClass>, 
and MIME media type application/json was not found

Turns out you have to add a matching provider to your <pre>com.sun.jersey.api.client.Client</pre>:

ClientConfig clientConfig = new DefaultClientConfig();
clientConfig.getClasses().add(JacksonJsonProvider.class);
client = Client.create(clientConfig);
WebResource r = client.resource(endpoint);
List<MyClass> list = r.accept(MediaType.APPLICATION_JSON).
    get(new GenericType<List&ltMyClass>>() {
  });

Thanks to cobusbernard on stackoverflow for that one. I hope this’ll save somebody some time as it’s a bit hard to find.

choosing CDI @Alternatives at runtime

2011-11-30T12:12:31Z

I just could’nt believe I was the only person having this problem I searched the web for a solution, even made threads at the Weld Users Forum and at stackoverflow, but nobody was able to help me - so after sinking way to much time into the JSR-299 spec and weld source code I came up with this:

Goal: we want to choose different sets of @Alternatives depending on the environment our war file is deployed to. First thing we do is create an @Alternative @Stereotype to hold our meta-information and also in order to just add one type to the beans.xml <alternatives> section instead of adding each @Alternative seperately:

@Alternative
@Stereotype
@Retention(RUNTIME)
@Target(TYPE)
public @interface EnvironmentAlternative {
    EnvironmentType[] value();
}

EnvironmentType is just an enum detailing the different - wait for it… environment types:

public enum EnvironmentType {
    DEVELOPMENT, TESTING, STAGING, PRODUCTION;
}

We need to make sure to have a single @Default implementation for each interface, CDI will abort during deployment otherwise. All other implementations get annotated with our nnw stereotype:

@Default
public class MockupFoo implements Foo {
  ...
}

@EnvironmentAlternative({STAGING, PRODUCTION})
public class FooImpl implements Foo {
  ...
}

As EnvironmentAlternative is an alternative stereotype MockupFoo is now choosen by the CDI container for all injection points. After we add the following lines to our beans.xml FooImpl is choosen instead:

<alternatives>
  <stereotype>com.example.EnvironmentAlternative</stereotype>
</alternatives>

Not exactly what we wanted, but there’s something we can do about that: ever heard of CDI extensions? They are a way to extend CDI (duh) by observing CDI lifecycle events. Writing one is quite easy, just extend the Extension interface:

The extension itself is not very complicated: the processAnotated method gets called for each annotated type the container processes, and if it is annotated as @EnvironmentAlternative AND the current environemnt is NOT in the specified environments we call the event’s veto() method, this prevents the type from being processed any further. Easy! The only thing left to do is create a file called javax.enterprise.inject.spi.Extension in your app’s META-INF/services directory containing a single line: our extension’s fully qualified classname.

In a real application of course instead of hardcoding the currentEnv field you’d have to decide how to obtain the current environment type, I just use a system property in our different glassfish installations that I create with

  nsn@nsn: ~> asadmin create-system-properties ENVIRONMENT=DEVELOPMENT

and then simply obtain via

    String propertyValue = System.getProperty("ENVIRONMENT");
    currentEnv = EnvironmentType.valueOf(propertyValue);

In our current project my team and I use this method to be able to build our application once, then deploy it to different environments and have it behave differently there. The only problem I wasn’t able to solve with this technique is choosing which @Decorators are enabled, as if I just veto() a @Decorator that is explicitly enabled in the beans.xml the container complains about not being able to find that class. If anybody comes up with a solution to this please contact me somehow, for now our @Decorators themselves are responsible for when they are active and when not.

configuring jee apps with cdi

2011-11-07T13:32:51Z

Goal: we want to maintain all our config params in the source code during development, but still be able to change them during compile- or even runtime later in the application’s lifespan. We will achieve this by using JSR-299 dependency injection:

First we create a @Qualifier to label all our config params with:

@Target(value = { FIELD, METHOD })
@Retention(value = RUNTIME)
@Dependent
@Inherited
@Qualifier
public @interface ConfigValue {
}

We’ll certainly need additional information about the config param: a symbolic name, a default value and a description about how the param is going to be used. Unfortunately we can’t just add methods to our qualifier-interface as CDI matches producer methods exactly - we cannot use the qualifier to specify more meta-information. So we have the choice to either create a seperate annotation for each piece of meta-information we want to be able to specify, or just create a single annotation type and add all needed methods there. Since Java does not allow null as default values in annotations (somehow null is not a ‘constant expression’, whatever…) I decided to create one annotation for all mandatory data, and then create an annotation for each piece of optional information:

@Target(value = { FIELD, METHOD })
@Retention(value = RUNTIME)
@Inherited
public @interface ConfigParams {
    /**
     * the {@link ConfigValue}'s default value, always a String, if a non-String
     * {@link ConfigValue} is annotated with a preset that cannot be converted
     * an exception is thrown in the producer method and 'svn blame' is going to
     * be used against you
     */
    String preset();

    /**
     * describes what the {@link ConfigValue} is used for, at this specific
     * injection point
     */
    String purpose();
}

/**
  * specifies an optional symbolic name for a {@link ConfigValue}
  */
@Target(value = { FIELD })
@Retention(value = RUNTIME)
@Inherited
public @interface ConfigKey {
    /**
     * the symbolic name to be used
     */
    String value();
}

ConfigParams holds all mandatory information (default value and a short description on how the param is going to be used), while ConfigKey is optional and specifies a symbolic name for a ConfigValue. This is necessary because our producer service chooses the fully qualified classname and fieldname as a default name for a ConfigValue, and the ConfigKey allows us to use the same ConfigValue at different locations in our project. Now we just need to write @Produces methods for each annotated type, we’ll just implement Strings for now:

@ApplicationScoped
public class ConfigurationService {
    @Inject
    private ConfigStore store;

    @Produces
    @ConfigValue
    public String makeConfigString(InjectionPoint injectionPoint) throws ConfigMetaInfoException {
        // extract meta information
        ConfigParams params = injectionPoint.getAnnotated().getAnnotation(ConfigParams.class);
        if (params == null) {
            throw new ConfigMetaInfoException("ConfigParams annotation missing at injection point "
                    + injectionPoint.toString());
        }

        // key?
        String key = calcDefaultName(injectionPoint);
        ConfigKey cfgKey = injectionPoint.getAnnotated().getAnnotation(ConfigKey.class);
        if (cfgKey != null) {
            key = cfgKey.value();
        }

        // ask store for value
        String rv = store.getConfigValue(key, params.preset());
        // log.info(String.format("config %s => %s", key, rv));

        return rv;
    }
}

The ConfigStore interface defines a store for @ConfigValues, in my current project this is a @Singleton bean that uses JPA to persist config params to a database. Let’s just use a Hashmap in memory to demonstrate:

/**
 * default {@link ConfigStore} implementation, stores config values locally in a
 * HashMap, does not persist changes anywhere but in memory
 * 
 * @author nsn
 * 
 */
@Dependent
@Default
public class MockupConfigStoreImpl implements ConfigStore {
    private HashMap<String, String> values;

    /**
     * initializes the values map
     */
    @PostConstruct
    public void init() {
        values = new HashMap<String, String>();
    }

    @Override
    public String getConfigValue(String key, String preset) {
        if (values.containsKey(key)) {
            return values.get(key);
        }
        values.put(key, preset);
        return preset;
    }

}

A real ConfigStore would probably need to provide a getAllValues() method that returns all ConfigValues, each with all their injection points, default value and meaning meta-information. This method could then be used to create a simple web-frontend to actually set the config params.

This is the way my team and I manage our current project’s configuration, and so far we like it a lot more than the .properties files we used for the Wizard101 website.

Good riddance PHP

2011-11-06T03:22:21Z

For 8 years I was a PHP developer. I contributed to the XP-Framework and in my thesis I even integrated the Zend-Engine into the Java-VM. I know what I am talking about - and I say: don’t use PHP!. Ever. Technologically PHP is at least 10 years behind the rest of the “web”-languages. The underlying Zend-Engine contains some of the worst C-code I’ve ever seen. There are countless sites explaining in great detail why and where the language is broken.

And I simply can not think of a single reason to chose PHP over any other language for “web programming”: Java, Ruby, Python - even Perl are more stable, have better performance, better libraries and better communities to learn from.

so: Good riddance PHP - and fuck you!

every keyboard sucks

2011-11-01T15:12:22Z

For the longest time now I typed on an excellent Enermax Aurora - it is very well made, flat (which is good for my wrists) and yet has good key resistence and feedback. But one thing always bothered me: it doesn’t have a US key layout but rather some strange mix of US and UK - most notably it has a “large” return key, which displaces the backspace and backslash/pipe keys. I’ve also grown to love the built-in USB hub.

So when I now needed a new keyboard to replace the old, crappy and filthy standard cherry piece of crap at home I naturally wanted to buy the successor: the enermax Acrylux. Unfortunately it is absolutely impossible to buy an Acrylux with en_US layout here in germany - damn!

So I lamented for a while and then ordered the cherry easyhub. It arrived, but the fact that the keys are huge, very close together and worst of all: aren’t beveled make it very difficult to type on, and my rate of error skyrocketed. Also the keys have nothing on the Aurora’s and feel rather flimsy in comparison.

I then ordered a cherry STRAIT… what a piece of crap! It is built to look like the stylish apple keyboards (which I know almost nothing about), but falls short in all other areas: it feels flimsy as hell and lacks feedback on whether you actually pressed a key or not - horrible! Also the insert/delete/home/end/… block is rotated 90 degrees - catastrophic for a vim-lover-yet-insert-lamer like me.

So: does anybody know a flat keyboard with a decent feel to the keys that I can actually buy an american layout version of here in germany? I’d rather have a corded version, and a built-in USB-hub is a bonus. Any pointers?