Mit ‘Automatic Installation’ getaggte Beiträge

So,

it was quite for some time now. (12 days :)) My vacations are over and I have to develop GAB (Automatic Binding for Guice) in my spare time, but no problem so far. This means my evenings will be longer. 🙂

First good news: GAB is now listed as official 3rd-Party Extension for Google Guice!
Second good news: I release v0.7! 🙂

The blog was quite, but github was under fire 🙂

So what’s changed so far?

Summary:

  • Added Automatic Binding of AOP Interceptors
  • Added Automatic Binding Configurations for java.util.Properties
  • Added Automatic Binding Configurations Apache Commons Configurations
  • Added rocoto (Simple Configuration) to the Integrations
  • Improved JavaDoc, JUnit-Tests and Examples

Added Automatic Binding of AOP Interceptors

This Feature is one of the coolest things. 🙂 You can use your existing AOP-Alliance compatible MethodInterceptors. Just annotate them with @Interceptor and they will be bound automatically.
But Guice needs some more Informations:

  • Which Classes should be monitored
  • Which Methods of this Class should be intercepted

Normally you would pass a Matcher-Object to the Guice-Binder. Due the fact that this should happen automatically, I introduced two Annotations, which will mark the Methods, which returns the Matcher-Object. @ClassMatcher and @MethodMatcher

@Interceptor
public class AnnotatedMethodInterceptor{
    @Invoke
    public Object invoke(MethodInvocation invocation) throws Throwable {
	return invocation.proceed();
    }

    @ClassMatcher
    public Matcher<? super Class<?>> getClassMatcher() {
	return Matchers.any();
    }

    @MethodMatcher
    public Matcher<? super Method> getMethodMatcher() {
	return Matchers.annotatedWith(Intercept.class);
    }
}

This Example is a complete Implementation of a MethodInterceptor. There are different ways you could go. Use your existing MethodInterceptors, which implement The MethodInterceptor Interface.
If you choose this way, you need to annotate at least two Methods for the Matchers.

The second way can be, that you extend my abstract GuiceMethodInterceptor Class, so you need no Annotations.

Or you are going the complete dynamic way, like the one displayed above. Just annotate the Matcher-Methods and the Method which should be invoked, if a monitored Method matches the Criterias.

Added Automatic Binding Configurations for java.util.Properties

GAB is now able, to bind your needed Configurations automatically. 🙂

You just need one annotation, which informs GAB, if you want a Named- and/or Lazy-Binding and where it find the Configuration File (Classpath, File, URL)

@Configuration(name="config", path="/configuration.properties", pathType=PathType.CLASSPATH)
public class Example{
    @Inject @Named("config")
    private Properties config;
...
}

Added Automatic Binding Configurations Apache Commons Configurations

Or are you more a Friend of Apache Commons Configurations?

@Configuration(name="config", bind=PropertyListConfiguration.class, path="http://devsurf.de/guice/configuration.plist", pathType=PathType.URL)
public class Example{
    @Inject @Named("config")
    private PropertyListConfiguration config;

...or...

    @Inject @Named("config")
    private Configuration config;
}

Added rocoto (Simple Configuration) to the Integrations

So you don’t want a Properties or Configuration-Object? You could use the rocoto-Extension (rocoto-googlecode and homepage). This allows you to direct inject your values into an Object. GAB will do the Rest for your. (Automatically Binding/Installation of rocoto-Features)

@Configuration(path="/configuration.properties", pathType=PathType.CLASSPATH)
public class ExampleImpl implements Example {
    @Inject @Named("message")
    private String message;
    
    @Override
    public String sayHello() {
	return "sayHello() - "+message;
    }
}

No boilerplates anymore! 🙂

Checkout the Examples

So I just can say, check out the Examples and JUnit-Test! You will find several Examples, how to use the different Modules.

Straight to v1.0

The Release of the v1.0 is not so far away. At the moment it is planned for the End of October. Why so long? I’ll make sure that it is not only tested on Windows. I’m going to create a Web Application for Remote Configurations. So you can keep the Customer specific Things out of your Applications. This one will be tested at least under Windows/Linux and Tomcat/Glassfish.

After finishing that, I’ll release! Promised! 🙂

Btw: I tested the last release with the Google Guice 3.0-Branch. Works like a charm! Using only JSR330-Annotations leads to no heavy dependencies to Guice. (and if you want to remove all Source Code-Dependencies – checkout the JNDI-Example for Guice)

Advertisements
		<dependency>
			<groupId>de.devsurf.injection.guice.integrations</groupId>
			<artifactId>de.devsurf.injection.guice.integrations.guicyfruit</artifactId>
			<version>0.6.2-SNAPSHOT</version>
		</dependency>

This will add the JSR250Module of the GuicyFruit-Extension to your Classpath and the Scanner will find the Module, because it is marked with @GuiceModule.
So you can annotate your Classes with @PostConstruct, @PreDestroy and/or @Resource.

In my git-Repository you will also find an Example-Folder, where all Features are used. From automatic Binding of Classes, over automatic installation of Modules, to using JNDI and/or Multiple-Bindings.

I’ll show it in the next Example how to use it.

In our Example we have one Interface „Example“ 🙂 :

public interface Example {
    String sayHello(); //will be called in our Application
    void inform(); //will be called through @PostConstruct
}

Our Implementation is as easy and boring as you would expect it 🙂 :

public class ExampleImpl implements Example {  
    @PostConstruct  
    public void inform(){  
	System.out.println("inform about post construction!");  
    }  
    
    @Override  
    public String sayHello() {  
	return "yeahhh!!!";  
    }  
}

and for completeness a Module, which will be installed automatically which will bind our Interfact to the Implementation:

@GuiceModule
public class ExampleModule extends AbstractModule {   
    @Override
    protected void configure() {  
	bind(Example.class).to(ExampleImpl.class);
    }
}

You see how difficult it is? 🙂

Oh and I forgot our Application. We will use the StartupModule, which only wants to know about the ClasspathScanner-Implementation and which Packages should be scanned.
After creating an Injector, we will retrieve an Instance of our DynamicModule, which is bound to the ScannerModule.
Last but not least, this Module can be used to create a new Injector.

public static void main(String[] args) throws IOException {  
	StartupModule startupModule = StartupModule.create(VirtualClasspathReader.class, ExampleApp.class.getPackage().getName(), JSR250Module.class.getPackage().getName());  
	Injector injector = Guice.createInjector(startupModule);  
  
	Module m = Modules.combine(startupModule, injector.getInstance(DynamicModule.class));  
	injector = Guice.createInjector(m); 

	System.out.println(injector.getInstance(Example.class).sayHello());  
}

Attention: At the Moment there is something I don’t understand. When I use my original Injector to create a ChildInjector, all Interface-to-Class-Bindings work like a charm. But I install a Module, which will bind a TypeListener or something else, they are not recognized.
I’m not sure if this is a Bug or a wanted behavior. So we are only able to use GuicyFruit, if we create a new Injector with the Help of the DynamicModule.

Guicefy JNDI

If you are working a lot with JNDI and/or JavaEE you often have to work with a Context. A good description about the Use Case can be found on the GuicyFruit Wiki. I’ll only describe how you can use it with my Extension.

First of all you will need a „jndi.properties“ with the ContextFactory, our Class for the ClasspathScanner and which Packages should be scanned. (sounds familiar? :))

java.naming.factory.initial = ...integrations.guicyfruit.GuicyInitialContextFactory
guice.classpath.scanner = ...scanner.asm.VirtualClasspathReader
guice.classpath.packages = ...

After that you need to create a new Context and lookup your Instances with the help of it. The Rest is magic. 🙂 (behind the scene there is the normal automatic binding and installation of modules/beans)

public static void main(String[] args) throws Exception {  
	InitialContext context = new InitialContext();  
	Example example = (Example) context.lookup(Example.class.getName());  
  	
	System.out.println(example.sayHello());  
}

On the road to Version 1.0 I have to invest a little bit in the rocoto-Integration and further Tests/Documentation.

The work on Automatic Injection/Binding for Guice is in heaviy progress. I added the possibility to use the JSR330 and/or Google Guice Annotations.

So you can create a Named-Binding due using the @Named-Annotation. Due the fact, that the Guice-Named Annotation is not able to annotate a Class, I only support the javax.inject.Named-Annotation.
If you annotate a Class with it, it will result in

binder.bind(interface).annotatedWith(Names.named(annotation.name())).to(annotatedClass)

To declare a Singleton you can use the @Singleton of the JSR330 and/or the Google Guice-Annotation.

binder.bind(interface).to(annotatedClass).in(Scopes.SINGLETON)
/* for named resources */
binder.bind(interface).annotatedWith(Names.named(annotation.name())).to(annotatedClass).in(Scopes.SINGLETON)

After I submitted this feature, I want to release a new Version. So I added the Maven Release Plugin and tried to do „mvn release:prepare“ and „mvn release:perform“.
What a big mistake. 🙂

My Environment?

  • Windows 7
  • Github Account
  • git 1.7.x + msysgit
  • Maven 2.2.x

I faced several problems. First of all I didn’t recognize, that I don’t had the distribution section, due the fact that the most Maven Repository are only working if you have a project there, I decided to use the Sonatype Repository.
I just can recommend to every github User which needs one, get your account there!
You create a Account, create a JIRA ticket and after one Day you can upload to OSS. The big advantage is, you can stage your releases. So release your version and if your think your are done, bring it from a Stage-Level to a Release and it wil be synched to Maven Central.

Have a look at the Usage Guide

After adding a „settings.xml“ to my „~\.m2“ Folder, I also decided to encrypt it, because you have to store your Sonatype-Account Settings there.

How-to do it? Maven Encrypt Password

What I also can recommend is, that you create a Root-Project, which inherits from the Sonatype-POM. You need this step, because they already configured the plugins, which you need for you. Parent POM Settings

After this step you need to configure GPG. For releasing to Maven Central you have to sign your Releases and Snapshots. For me the easiest way was, to remove all gpg*.exe Files from my Git-Installation.
I installed a newer Version: gpg4win.
Nevertheless the easiest way (whatevery gpg you use) you should create a certificate and import it with gpg –import mycertificate.asc.
The problem with the Git gpg was, that it search for my certificates in ~\.gnupg. But I don’t have this directory. You can overwrite the directory with passing -Dgpg.homedir= when using mvn release:*.

All the problems I had are related to the Unix-Environment for Windows. Due the fact, that it uses Unix-Folder Path, but partly working with Windows-Paths Style, I had a lot of problems.

  • Not finding POMs (your pom is outside of the repository
  • StringIndexOutOfBoundsException when using the Release Plugin Version 2.0

How could I overcome these issues?
I’m working with git-bash, but the first thing I do is, type cmd. So you have your whole Environment, but working in Windows-Style.
If I’m working with git, I’m using the Bash-Style not the Windows one.
You also need the git-bash because I didn’t get it up and running to use the ssh-agent under Windows. But if you are starting the git-bash this will work, because it ask you while startup about your Passphrase. How-to start SSH-Agent

EDIT: The problems with Windows, Maven, msysgit is how you start your git-bash. Start your bash with the Help of the Windows Command. Doing it this way, the Letter is „F:“ (or whatever :)). Starting directly the git-bash it is „f:“.

EDIT 2: When using the Command Line + Git-Bash, you should change to your local drive with „F:“. The major point is the Uppercase of the Letter!!! Without it, the Maven-Release-Plugin 2.0 will fail.

Some Tips&Tricks:

  • Use -DautoVersionSubmodules=true if you have multiple Modules, but want just one Version Number

I hope my comments, can help you a little bit, while working with Maven, git/Github and Windows.

If you have questions, don’t hesitate to ask me. 🙂