The talk at Herbstcampus is a 70 minute Tapestry introduction and takes place on September 14th.

The both talks at WebAppDays are scheduled on September 27th. The first talk will be a JSF 2.0 vs. Tapestry 5 comparison. It is the same talk I was giving at Jazoon, but this time I’ll be speaking together with Andy Bosch, a man behind JSF Forum. The second talk is a Tapestry only presentation and starts directly after the comparison.

Want to learn Tapestry? Come to Herbstcampus and/or WebAppDays.

See you there!

The new logo emphasizes Tapestry’s strengths: power, speed, innovation, coolness and fun.

.

Wait. Don’t hold your breath. Tapestry wasn’t acquired by Ferrari. It’s just a joke created by a fellow worker Sebastian. I like it very much and going to use it in my presentations to animate the attenders. Do you like it?

The programm looks very interestibng. Here are some of the presentations I’m going to attend:

Blueprint – Modern Dependency Injection for OSGi

Do you really get class loaders?

GPars: Parallel programming concepts for the JVM in Groovy

Cloud Computing with Scala and GridGain

Spring 3.0 – Themes and Trends

Spring ROO – A New Level of Enterprise Java Productivity

And of course the Jazoon Party. See you there!

• Unordered Configuration of type java.util.Collection
• Ordered Configuration of type java.util.List
• Mapped Configuration of type java.util.Map

When creating a service instance the registry creates an empty configuration and passes it to all the available contribution methods for the service. In the following example you can see a contribution method for the service with the id ApplicationDefaults.

public class AppModule {

   public static void contributeApplicationDefaults(
         MappedConfiguration<String, String> config) {

      config.add(SymbolConstants.PRODUCTION_MODE, "false");
   }
}

This approach works fine because a service id is unique inside the service registry. But identifying services by string ids is often error prone. First if you want to contribute to a configuration of a service you need to know the id of the service. For this purpose you have to look into Tapestry sources or call the ServiceStatus page. Second if you refactor your application and rename an id of a service, your contribution won’t work anymore.

As of version 5.2 (I committed the code today) the annotation @Contribute can be used as an alternative for naming convention for contribution methods. The annotation may be placed on an arbitrary named method of a module to identify this method as a contribution method. The value of the annotation is the type of the service to contribute into. The following example is an alternative for the contribution method above. Note that service with id ApplicationDefaults is of type SymbolProvider.

public class AppModule {

   @Contribute(SymbolProvider.class)
   public static void arbitraryName(
         MappedConfiguration<String, String> config) {

      config.add(SymbolConstants.PRODUCTION_MODE, "false");
   }
}

What if you have several implementations of a service interface? For example Tapestry provides several instance of the service SymbolProvider. In this case you have to disambiguate the service instances with marker annotations. In Tapestry the services ApplicationDefaults and FactoryDefaults are marked with annotations @ApplicationDefaults and @FactoryDefaults. We need to modify our contribution method a little bit in order to identify the service to contribute into. For this purpose the @Marker annotation should be placed on the contributor method. The value of the annotation is the class of a marker annotation which was used to disambiguate the service instance. The following contribution method is meant for the instance of SymbolProvider service marked with the annotation @ApplicationDefaults.

public class AppModule {

   @Contribute(SymbolProvider.class)
   @Marker(ApplicationDefaults.class)
   public static void arbitraryName(
         MappedConfiguration<String, String> config) {

      config.add(SymbolConstants.PRODUCTION_MODE, "false");
   }
}

Enjoy!

HiveMind was my first experience with IoC and loved the project. Tapestry IoC is the IoC container for Tapestry 5 and is the successor of HiveMind. It was designed with session learned from HiveMind. The central concept in Tapestry IoC is to eliminate XML-driven approach of HiveMind and build an equivalent system around simple objects and methods.

However if you are a hard core HiveMind user and migrating to Tapestry IoC is not an option then Gaderian might be a project you should look at. The migration guide from HiveMind to Gaderian is available here.