Oliver Gierke

Jürgenized

2013-03-14T18:16:00+01:00

Jürgenization | noun | jərgenajzeʃən

The process of turning code to solve a problem at hand that might look sufficient at the first glance into rock solid, quality assured, perfectly documented and extensible code. This process might consist of a complete rewrite of the code that originally made it into the process (Karma level 0) to only minor modifications (Karma level 10), usually depending on how often the author of the code to be jürgenized has made it through the process yet.

The term originates from Jürgen Höller, Spring framework lead developer, coining this kind process to deal with code contributions about to make it into the Spring framework. To get your code into the core codebase, you and the code get jürgenized.

Nowadays the term usually relates to the process of code quality assurance, in particular around Spring eco-system projects.

Websites VS. APIs

2013-02-21T00:00:00+01:00

I’ve been recently pulled into some Twitter conversations about the quality of the new open data portal “launched” by the German government available at govdata.de. I put launched in quotation marks as the launch has been a rather rocky one critized through out the web.

I in particular made fun of the very verbose api resource the portal exposes. If you do a GET on it all you get returned is a:

{ "version" : 1 }

What I was trying to point at - and I think most of my Twitter followers are aware that I am into the field of REST web services a bit - is that it’s absolutely sad that it’s 2013 and we still see “APIs” published to the web that lack any kind of hypermedia elements. My initial tweet caused a bit of response and started some interesting conversation.

Ina Schiefendecker (I assume to be related to the GovData project as she is working for Fraunhofer FOKUS, responsible for implementing the portal) pointed me to the documentation:

Just have a look: http://t.co/cA4Q0pXzKQ or http://t.co/Qd114XnfbG

I replied that adding hypermedia elements to the responses would turn the chunks of data into a usable API, which she responded to with:

If you want hypermedia take the portal, if you want to program take the API

My initial reaction to this was a deep *sigh* and thinking that the team apparently hasn’t understood the value of hypermedia in API design. But taking a step back, this statement contains an interesting aspect:

For the GovData team the website is something different than the API

Why is that the case? If it’s on the web, embrace the web, period. Why would you choose the web as the platform of choice if the first thing you do right after that is starting to ignore it’s core traits? Hypermedia is essential to way the web works, thus so should it be to your web site and APIs you expose to the web.

To me it feels like implementation aspects leaking through at this point. According to some leaked stack traces, the portal is built with JBoss, Liferay and JSF (sigh), the API with CKAN. Totally different technology stacks, but does that impose a real conceptual difference to a web site and a web API?

Playing devil’s advocate a bit one now could ask:

If a web site is the same as an API and you have a website, why do you need something you call “a dedicated API” at all?

The core point here is what makes up “dedicated” in the first place. To stay with REST terms, in my opinion “dedicated” is embodied in the representation design for different client types. Even for well designed websites you usually serve a representation that consists of certain elements that serve the purpose of being displayed to a user through a browser. This is essentially a core principle of REST: you choose a media type tailored for a specific use case to optimize on bandwidth, performance and client (the browser in this case) usability. And so do web APIs, except the driving factors being others: potentially much more focused on limiting bandwidth usage, the numer of requests necessary and ease of extracting data from responses. You also do so when exposing your web site content to feed readers by choosing Atom or RSS. But in the end it’s all about designing representations for clients with different requirements. So here’s what it boils down to:

Both your website and your API benefit from being considered ‘the same thing’ with different representations.

There’s absolutely no point in differentiating between the apparently different things “website” and “web API”, especially when it comes to the aspect of hypermedia: if it’s on the web, embrace the web.

Edit - 2013-04-30: Oliver Wolf has a great presentation on active VS. passive APIs on speakerdeck.com. It uses the issues with GovData (or the CKAN API to be precise) to suggest improvements to the APIs.

Whoops! Where did my architecture go

2013-01-15T00:00:00+01:00

I am currently travelling conferences and Java User Groups with a talk called “Whoops! Where did my architecture go?”. It discusses approaches to create and maintain logical architectues in Java code bases, challenges, tools and tries to outline some ideas how one can accomplish this. A core part of the argumentation is the discussion about the importance of Java packages. Jens Schauder has written a blog post about that topic recently and I felt I had some things to add. The more I though about it I got the conclusion that a comment I envision would exceed the length of a reasonable reply I thought I’ll write up a blog post. I will point to the slides of the presentation in places where it comes in handy. The talk is also based on a lot of sample code which we will get to a bit later. The code can be found on GitHub.

I’d like to take a step back at first and briefly discuss some general concepts and ideas that will be necessary to understand the approach I’ll present later. I’ll use the Java software development space as posterchild for this to make sure we can build relations into the day-to-day practice but the concepts apply to software systems in other languages, too.

Divide and conquer

A core principle of complex problem solving is “divide and conquer”. We split up a complex problem into smaller ones and approach those smaller ones individually. In Java software this is usually done in several artifact levels: deployment units (WARs, JARs), packages and classes eventually. As a side effect of that we create dependencies between these artifacts and we need some means to manage them.

As a consequence of that we create artifacts with different (in)stability metrics (see Wikipedia for details). This metric essentially expresses the risk of a change made to an artifact. Assume we have two artifacts A and B, A depending on B. A change in A will never affect B, whereas a change in B potentially breaks A. Thus, there’s value in potentially splitting up a big artifact into two smaller ones with a defined dependency direction as it reduces the risk of a change in (in my just given case) A. If a dependency from B to A is introduced, both artifacts essentially become a single one from an “the effect of change” point of view as we cannot touch one without potentially affecting the other.

Layers

A practical example of this aproach is the layered architecture pattern where you split up you system in presentation layer, service layer and repository layer with directed dependencies from top to bottom. The exact number and names don’t really matter. Still you can see that you can definitely change the presentation layer without any chance of breaking something in the repsoitory layer given you haven’t violated the dependency rules.

Layering is a reasonably understood by developers as it’s decomposes the software system by by a technical aspect. It’s tought in university, probably practitioned in most of the development shops out there. So here’s the interesting question:

If we understand and value the benefits of the general approach of slicing code horizontally, why do we so horribly neglect that approach when it comes to vertical decomposition, i.e. business functionality?

I know this is a bold question, but it’s essentially what I’ve seen through most of the code reviews I’ve done in the last couple of years. In general, I’d even argue that splitting up business functionality in dedicated slices and monitoring and making sure the allowed defined dependencies are not violated is much more important for long-term maintainability of software. This is mostly do the cost of a change correlating to the risk of a change.

Slices

Take a CRM system as example: you’ll probably have a Core slice that contains some code that other slices will depend on. You’ll find a Customer management slice, that keeps track of customers, their addresses etc. On top of that you might then build a Contract management slice that clearly needs to know about the Customer and use the Core slice as well (see this slide).

Architecture VS. Codebase

So let’s assume we defined both slices and layers as architectural concepts, how do we make sure these architecture concepts are embodied in our Java codebase? What we usually do is creating naming conventions and map our layers and slices into package and class names. There are some great tools like Sonargraph and Structure 101 available out there that help you at doing exactly that. Being a happy day-to-day user of Sonargraph I still asked myself: “How far could we actually get with plain Java (language, compiler runtime) means only?”.

We already identified that controlling dependencies between code artifacts is key to reduce the risk of change effectively. Let’s have a look how this is approached in general. A key aspect to dependency control is that an artifact is able to explicitly express a dependency. Interestingly we have solutions to do exactly that for two of the three artifact levels (JARs, packages, classes) mentioned above.

Deployment units are usually managed through either Gradle, Maven or Ivy. At the class level dependency injection comes into play as a core aspect of it is to expose dependencies through either constructor arguments or setters (an interesting post on this at Jens Schauders blog again). Still this is not entirely sufficient cause at runtime the type space in the JVM is flat and a class can potentially “ask” for a dependency it shouldn’t be able to and get it injected. This is where the aforementioned tools would step in again and veto at build time. But yeah, we wanted to see how far we can get without them.

At this point, I’d like to throw in another question:

Dear Java developer, have you ever wondered why you make your class’ properties private by default but the class itself public by default? Hint: ‘Because my IDE generates it this way’ is not a valid answer.

The observation that should lead you to is that Java developers usually just skip packages as means to control visibility of types. We practice information hiding in classes/properties (we actually don’t as most developers run “Generate getters and setters” right away) but don’t on the classes-in-a-package level. We just discovered that inside a JAR we essentially have to manage which type can see which other type as the class space of public types is flat in a JVM. Essentially this means that if a class is not public (i.e. package private), we don’t have to dependency manage it on the global level but within the package only.

Packages

The reason packages are usually not used as dependency managment mean is that designing packages is not a trivial task, even you use an architecture tool like Sonargraph to help you. An aspect of that is that there are hardly any guidelines on how to do it and thus various kinds of crazy patterns have evolved over the years. Arbitrarily restricting the number of classes in a package is just - arbitrary (actually one of the few points I disagree with Jens Schauder’s blog post). Simply grouping all exception types into a exceptions package is not really reasonable either as it groups types by technical commonalities which usually doesn’t provide any architectural benefit.

Assuming we’d like to map our previously defined architecture onto Java packages, here’s what you’ll probably see something like this. You find actual code backing this approach in the packages-before project of this GitHub repo:

….account.domain
….account.presentation
….account.repository
….account.service
….core.domain
….customer.domain
….customer.presentation
….customer.service
….customer.repository

This is not bad in general but there are a few things to consider here. First, having the slice first is a good idea as you can easily separate or externalice and entire chunk of functionality. Remember that in our example, the account slice was not depended on by anything else so we should be able to remove this package and all of it’s sub folders to ditch the features implemented in the slice and the app should still work with the customer features only.

Second, you see that the core slice does not have code in any of the actual layers, but a domain package only. This essentially shows that we expose something that can be considered an implementation detail to the public: the layering. That might be considered not too important but it has a consequence that completely subverts our idea of reducing the number of types to manage. Let’s have a more detailed look at that:

….customer.domain
  + Customer
….customer.service
  + CustomerManagement
  + CustomerManagementImpl
  + CustomerNumberGenerator
….customer.repository
  + CustomerRepository

Assume the following: CustomerRepository is simply persisting Customer instances. The core part of the service implementation is generating customer numbers when a new Customer is created. This creates the need to make sure all customers are created through the service interface to make sure this behavior gets applied. Unfortunately, CustomerRepository needs to be a public type so that it can be referred to from the service implementation. This opens it up to be an injection candidate into virtually any other component of the system, which is exactly what we want to avoid. So what if we ditched the layer packages entirely? (The code can be found here.)

….customer
  + Customer
  + CustomerManagement
  o CustomerManagementImpl
  o CustomerNumberGenerator
  o CustomerRepository

We end up with less then a half of public types to manage. CustomerRepository cannot be used from anywhere else as the Java compiler prevents us from doing so. CustomerNumberGenerator and the layering in general becomes an implementation detail. Architecturally this creates stronger gates between the slices (the packages actually) and thinner ones between the layers (simple class-to-class dependencies) as illustrated in this slide (compare to the slide before to see the difference).

Summary

The basic approach I recommend is to move the vertical slices into the focus of the package naming and try to model them in a way that the public API of a slice is as tiny as possible in the first place. This is of course no silver bullet approach as packages can grow significantly and it might make sense to extract certain types into a sub-package or the like which then usually leads you to the need to use an architecture management tool. The core idea here is to try to use the means of visibility control that are available in Java to write code that is not a giant potential dependency mess in the first place. Packages can actually help you to achieve exactly that.

Hello World

2012-12-16T00:00:00+01:00

When my former Wordpress-based blog crashed quite a while ago, I didn’t really bother to set it up again as I was to busy with other things. But as I felt the urge to go beyond Twitter posts to elaborate on certain topics in the recent time I thought I’d give it yet another spin.

The course of re-setting up the blog essentially consisted of two aspects: selecting a new blog software, and trying to recover as many of the formerly written blog posts as I could. After some research on Twitter I tried Jekyll and Jekyll Bootstrap in particular. It’s a Ruby-based website or blog generator that’s entirely file-based and (in my case) Markdown-driven.

I could extract some of my former blog posts from a very ancient backup I found and have tried to polish the more relevant posts to be present under their former URIs. Unfortunately there seems to be a minor gap between the time when the blog came down and the last backup so that I seem to have lost a hand full of posts.

Going forward I’ll probably drop a few blog posts now and then on topics that might be too unrelated to be posted on the official SpringSource blog, esp. as I think there’ll might be some music content popping up once in a while.

Spring, logging and JMX

2010-10-01T20:16:06+02:00

Pretty much every application out in the wild is using logging to some extend. As applications tend to have bugs (yes, yours as well) it’s a common requirement to alter log levels at runtime. As JMX (Java Management Extensions) is a standard to monitor and manage applications it seems to be a reasonable approach to expose the loggers used in an application via JMX to allow tuning of log levels via a JMX client like jconsole. So let’s take a look on how you enable JMX with Spring.

<context:mbean-server />
<context:mbean-export />

The first element from the context namespace sets up a JMX server so that MBeans can be registered. The second element activates automatic export of all Spring beans the either leverage Spring JMX support (annotation based) or Spring beans that satisfy the JMX naming scheme (a class implementing an interface named ${classname}MBean). Fortunately Log4J ships with a LoggerDynamicMBean that exports a Logger instance to the JMX infrastructure. It’s API is not really built with dependency injection in mind but due to the flexibility of the Spring XML configuration language we could register this MBean as follows:

<bean class="org.apache.log4j.jmx.LoggerDynamicMBean">
  <constructor-arg>
    <bean class="org.apache.log4j.Logger" factory-method="getLogger">
      <constructor-arg value="org.springframework.jmx" />
    </bean>
  </constructor-arg>
</bean>

Running this in combination with the XML snippet above now exposes the logger for org.springframework.jmx as JMX MBean.

XML Hell? Go make it clear and nice!

Declaring the MBean for a single logger requires quite an amount of XML and is boilerplate to a large degree. The two things that are unique in this case is that we want to expose a Log4J logger and the logger name of org.springframework.jmx. So what if we could expose the logger with something like this:

<jmx:logger type="Log4J" name="org.springframework.jmx" />

We can! I’ve created a small sample project project containing a custom JMX namespace and put it up on Github. The README file contains instructions how to play around with the Sample class, altering the log level via jconsole and see results in the console output. Right now it’s pretty much just a proof of concept and could be improved in a few corners. We should support other logging libraries and we could transparently register and whcih is not the case currently. Feel free to suggest or add extensions!

Enabling Hibernate criteria query statistics with AspectJ

2010-09-15T20:16:06+02:00

In the #java.de IRC channel someone pointed me to this request for enhancement in Hibernate recently. The bottom line here is that Hibernate’s statistics feature that can be used to capture persistence metrics (information about query executions and execution times and so on) does not include queries triggered through using the criteria API.

This is quite a a reasonable request for enhancement in my opinion and it’s quite surprising that the ticket has been open for over 2 years now, especially as the solution seems to be simply adding a method to CriteriaLoader class, as Chuck May points out. So supposed you want to use this feature now. The only option seems to be patching Hibernate (sort of doable), building it (a huge magnitude more complex – no offense, building Spring is not trivial either) and the use and maintain that patched version over further releases. Isn’t there another way to get that feature into Hibernate? Of course there is… AspectJ. As the fix seems to be simply adding a method to an existing class we can leverage AspectJ inter-type declarations to add this special method from the outside. Here’s the aspect code:

public privileged aspect CriteriaStatisticsAspect {
  public String CriteriaLoader.getQueryIdentifier() {
    return "[CRITERIA] " + getSQLString();
  }
}

It’s pretty easy to understand I think as the method declaration only slightly differs from a normal Java one (no pun intended). You actually only have to explicitly mention the type you want to add the method to. To weave this aspect into Hibernate you simply add the Maven AspectJ plugin to your pom.xml and tell it to consider the Hibernate JARs too by adding a weaveDependencies block to the configuration section of the plugin.

To ease the burden of getting started with this approach I have uploaded the sample code to Github, also containing a test case to demonstrate this actually works. Upgrading to another Hibernate versions should work seamlessly as the aspect gets woven into the never version then. As soon as the feature gets actually implemented (let’s hope it won’t take another two years ;) simply throw away the aspect.

Conference autumn 2010

2010-09-10T20:16:06+02:00

As summer’s fading out more or less, it’s time to take a look at upcoming times. Autumn is usually quite packed with conferences and this seems to continue this year.

I’ll kick off my conference autumn by speaking at WebAppDays in Düsseldorf (Sept. 27th/28th) presenting Roo as rapid java application development framework as well as giving an overview about tcServer, the SpringSource commercial edition of Tomcat. To not make this a marketing talk entirely, I will concentrate on how developers can benefit from tcServer usage during development and in production.

Next stop for me the is GearConf, Düsseldorf (Oct. 11th/12th), a conference dedicated to the more soft topics of software development like processes and teams. This year I’ll be talking about Mylyn and how it can help developers to be more productive and ease context switches.

If you register quickly there’s still the chance to get discount for both of these conferences. As they are rather small ones, it’s quite intensive as hallroom conversations take place pretty much everytime and everywhere so that the knowledge exchange rate is typically quite high.

The main event this autum of course is Devoxx 2010, Antwerp. Personally I’ll be holding the Mylyn talk there but there’s a ton of other speakers and talks to check out. As SpringSource is also official sponsor of the app a lot of my colleagues will also speak there, e.g Jürgen Höller on Spring 3.1, Ben Alex on Roo, Christian Dupuis on tooling for Spring and Grails.

Right in between those events I will promote upcoming Hades 2.0 release at JUG Cologne Nov. 8th. Chances are high that we have published the release then already. I am currently speaking to a few other JUGs as well, so you can be sure Hades will be near your place, too. :)

Anyway, I’m really looking forward to these events. Hope to see a lot of familiar faces and hopefully also some new ones (chances are not bad). Feel free to get in touch and let’s have a beer (malt for me, whatever you like for you :)

Hades 2.0.0.RC2 introduces transactional DAOs

2010-06-22T20:16:06+02:00

Our latest Hades release of the 2.0 branch is introducing transactionality of DAO instances as main new feature. Of course you can read up the reference documentation for some general guidelines but I want to use the chance to give a more detailed look into why we introduce this and how some details work.

These days, some kind of back-to-the-basics approach regarding architecture layering is widely accepted as best practices. Thus you don’t want to introduce a layer just because of some merely technical needs. A typical candidate layer for being obsolete is the service layer. Especially in web applications where you pretty much store entities that are equipped with rich behavior themselves the service layer is quite an artificial one that only demarcates transactions but then delegates to the underlying data access layer. Using Hades in such an application you had needed the additional transaction demarcation somewhere as it didn’t deal with transactions itself out of the box. So the only option to get rid of a service layer was to use e.g. @Transactional at a Spring MVC controller e.g. which is rather a sub-optimal solution.

So actually we were quite reluctant to the idea of applying transactions to Hades DAO instances as there were some crucial points to consider:

Actually a DAO layer might not be at the right level of abstraction. Usually you define transactions on a more business related method than a plain save(…) or findByUsername(…). So if we enable transactions at DAO methods we have to make sure that they seamlessly can be expanded to more coarse grained methods and the DAOs take part in those transactions.
If we apply transactions we don’t want to imply our transaction model to the user’s application. As Spring provides various means to define transactions, we don’t want to take that decision from the developer. So in case she wants to decide for a particular model, she has to be able to do so, no matter what we chose.
Although the transactional behavior that we define for CRUD methods might be okay for 90% of the use cases there has to be a way to override the defaults and replace them by some custom one.
As Spring 3.0 supports multiple transaction managers via @Transactional we have to make sure we participate in the right transaction depending on in which context the DAO is used.
It has to be easy to define transaction configuration for DAO interfaces containing the finder methods.

We decided to use @Transactional annotations at the GenericJpaDao implementation class and activate annotation based transactions for the proxies explicitly through the GenericDaoFactoryBean. This means that the CRUD operations of the DAO instances will be transactional if called standalone or participate in a transaction in case there’s already one running for the current transaction manager (read up details on multiple transaction managers here). So it doesn’t matter if you declare your transactional boundaries via @Transactional, too, or use e.g. XML configuration or even TransactionTemplate. This gets us solutions for issues 1 and 2.

Issue 5 is quite easy to solve as you can simply annotate the finder methods of your DAO interface (or the interface itself) with @Transactional and transactions get applied as you are used to with Spring.

The actual tricky part is issue 3. The main idea here is to simply redeclare the CRUD method originally declared in GenericDao inside your concrete DAO interface and reconfigure transactions as you like. So supposed you want to get rid of the readOnly flag at readByPrimaryKey(…) set to true (as we chose to default the transaction configuration to, as this applies some performance optimizations on the persistence provider as well as the JDBC driver), you can do this as follows:

public interface UserDao extends GenericDao<User, Long> {

  @Override
  @Transactional
  User readByPrimaryKey(Long key);
}

Getting this to work needs some reflection magic as we of course still have to delegate the call to that method to the GenericJpaDao instance but according to the Java Reflection API it of course does only implement GenericDao.readByPrimaryKey(…) and not UserDao. readByPrimaryKey(…). Long story short, we can find out the method that has to be invoked so we can hand this reconfiguration model to the user and gain much flexibility on this side.

Issue 4 is not that interesting as we simply have to configure our internal TransactionInterceptor to lookup the appropriate PlatformTransactionManager instance in a lazy-loading-like fashion but that all happens under the covers and you don’t need to take care of this.

So let me quickly summarize what 2.0.0.RC2 brings you in regard of transactions:

Transactional CRUD methods (everything declared in GenericDao) with appropriate defaults (readOnly flag set to true on read-only methods) that automatically take part in more coarse grained transactions if necessary
The ability to use @Transactional for your concrete DAO interfaces
The ability to reconfigure the transactional behavior of the CRUD methods by simply redeclaring a method inside the concrete DAO interface

Changing a project's artifactId in Sonar

2010-06-10T20:16:06+02:00

Sonar is a great tool to take care of code quality in your software projects. I use it heavily to monitor the open source projects I am involved with. When working on getting Hades published into Maven central I had to polish it’s pom.xml and felt the need to align the parent project’s artifact to our chosen OSGi compatible package notation for artifacts. So prior to releasing it to Maven central I changed the artifact id from hades-parent to org.synyx.hades.parent. Everything fine until I pushed the metrics of the 1.5.1 release into Sonar.

Sonar created a new project, as it cannot know about my refactoring. So what to do? I spoke to Simon Brandhof and apparently there’s no feature in Sonar to change the artifact id via the user interface. So I opened a JIRA issue for it, feel free to vote for it if you like. Meanwhile we could achieve this by manually altering the kee column inside the PROJECTS table. It contains entries of the form ${groupId}:${artifactId}(:${branchName}) for entries of type PRJ (i guess that stands for project. Altering these entries solved the problem.

Thanks to Simon and Verschdl for help!

Hades 1.5 released

2010-04-11T20:16:06+02:00

As you probably already might have noticed, yesterday we released Hades 1.5. Alongside with that the firs 2.0 release candiate sees the light of the day, too. Let me just take some lines to elaborate on the specialty of this release.

Why 1.5?

The first question that might arise is why this release is 1.5 whereas it’s predecessor was 1.1.2. Originally the release was planned as 1.2 but as it introduces some long-ranging features and changes we thought it might be worth indicating that in a larger step of version numbers. As 2.0 is already taken for our JPA 2 upgrade, 1.5 was the choice to go. So what do I mean with “long-ranging”?

Since it’s beginning Hades relied on two major interfaces: GenericDao and Persistable where as especially the latter raised some discussions here and there. Although it is not that of a big deal to implement a 3rd party interface with an entity class it was indeed a hurdle for adoption. So why was it introduced in the first place. GenericDao had the aim to abstract between creation and updates of objects. Although there slight semantic differences this maps to the difference between using EntityManager methods persist(…) and merge(…). To know what to call when save(…) is being called on GenericDao we have to be able to differentiate between a new and an existing entity. As this algorithm might vary from entity to entity, we chose to leave the burdon to decide that to the entity developer by implementing the interface.

Although implementing this interface should not be a big deal actually, we (and the developer community) were not really satisfied with that solutions as the technical infrastructure slightly leaks into the domain abstraction which is somewhat suboptimal kindly speaking. The good news is: as of Hades 1.5 there is no need to implement Persistable anymore. The DAO implementation now uses a reflective approach to lookup the id property of the entity and inspects its value. If it is null, the entity is regarded as new or as already existing otherwise. So that’s the default. If you need to tweak the semantics of new, simply implement Persistable as the algorithm will be simply calling isNew() on you instance then. So in effect, the interface comes into play if explicitly needed and not in any other case.

That’s the big news. Behind that we have a few new features regarding the XML namespace to be used in Spring applications. In case you have multiple EntityManagerFactory beans declared (e.g. in case you work with more than one JPA persistence unit), you can now point the dao-config and dao elements to a specific EMF bean by using entity-manager-factory-ref attribute. Furthermore using exclude-filter and include-filter (probably known from Spring’s context namespace) can be used to tune DAO auto configuration in a more fine grained way. Besides that we have done a general overhaul to the query creation subsystem and now also allow keywords like Between, LessThan and GreaterThan in method names. To round things up we’ve fixed a few minor bugs here and there. For more details read the changelog or the updated reference documentation.

Hades 2.0

Alongside this important step we make another one. JPA 2.0 specification was released a while ago and most existing JPA 1 application wil definately benefit from an upgrade as the new spec version really fills gaps the old one left to workaround for the developers. So what is our approach to the new spec. From a Hades point of view the most intresting part of the new spec is the criteria API as user’s probably will base their custom DAO implementations on it. Furthermore upgrading (Spring) applications demands applications to upgrade to Spring 3.0 and a new major version of the persistence provider of choice we choose to dedicate a 2.0 version of Hades to it.

So the first release candidate builds on top of Spring 3.0.2 as well as Hibernate 3.5, EclipseLink 2.0 as well as OpenJPA 2.0 Beta 3. We will probably wait for our final release until OpenJPA is final, too, but as the majority of users are split between Hibernate and EclipseLink we think that rolling out a release candidate is a good way to get feedback and battle proof the new version. The major change inside Hades 2.0 is that we dropped support of the read-by-example way to access entities. This had to be implemented in a provider specific way so that we could even simplify the codebase in that regard. Furthermore the DAO abstraction is now clearly centered around GenericDao and not blurred with additional interfaces.

So if you can upgrade to Spring 3.0.x and the JPA 2 ready persistence provider already, give Hades 2.0 a try. It should be a drop in replacement in this case. Having that said, it’s probably worth mentioning that even Hades 1.5 can be used with JPA 2.0 but requires more extensive pom configuration on the developer side (as Spring 2.5.6 does not support JPA 2). As you’d end up with a dependency setup similar to the one decalred in 2.0 you’re probably better of just upgrading to Hades 2.0.

Neglected classes in Spring - Part III

2010-04-07T20:16:06+02:00

Java web application developers often face the need to inject a regular Spring bean into a non-Spring-managed artifact like a Servlet or a JSP tag.. If you browse the web for you find various quite outdated solutions to it. No offense, by the time being these were quite appropriate solutions. One of them you’ll probably will find is the following:

public class MyServlet extends HttpServlet {

  private MyService service;

  @Override
  public void init(ServletConfig config) {

    ServletContext context =
      config.getServletContext();

    ApplicationContext ctx =
      WebApplicationContextUtils.
        getRequiredWebApplicationContext(context);

    service = ctx.getBean(MyService.class);
  }
}

Let’s recap what we just have done. First we need to get access to the ServletContext of the web application. A Spring WebApplicationContext that was registered by a ContextLoaderListener will be registered in the ServletContext under a special name the framework knows, so that WebApplicationContextUtils can then look it up and hand it out to you to manually retrieve Spring beans from it.

Okay, that get’s the job done. But we can reduce the effort and go a much nicer way, that reduces the amount of boilerplate even more. Spring 2.5.1 introduced a tiny helperclass SpringBeanAutowiringSupport which is residing in org.springframework.web.context.support spending a rather unregarded life. It offers a method processInjectionBasedOnCurrentContext(Object target) that automatically injects Spring beans to properties of the given target using the usual annotation driven suspects (@Autowired, @Resource, @Inject). So our sample code turns into something like this:

public class MyServlet extends HttpServlet {

  @Inject
  private MyService service;

  @Override
  public void init() {
    SpringBeanAutowiringSupport.
      processInjectionBasedOnCurrentContext(this);
  }
}

Done. Note, that we override the init method without the ServletConfig parameter as the called method looks up the actual ApplicationContext from a static map held in ContextLoader which inherits from. If you need to lookup beans from an ApplicationContext tied to a particular ServletContext you can use processInjectionBasedOnServletContext(Object target, ServletContext servletContext) and hand it the appropriate instances.

P.S.: Thanks to Eberhard Wolff for pointing me at this.

REST based web applications with Spring 3

2010-04-01T20:16:06+02:00

Yesterday I gave a talk on REST based web applications with Spring 3.

REST based web applications with Spring 3 from Oliver Gierke

You can also grab the sample code at GitHub.

New challenges

2010-02-10T19:16:06+01:00

It’s been official for a few days now, so I thought I could drop a public note about me joining SpringSource Germany (division of VMware) as Senior Consultant beginning March 1st this year. Time to look back on three exciting years at Synyx and an outlook of what’s about to come.

I joined Synyx almost exactly 3 years ago. Since then I had an exciting time with awesome folks, a wide variety of customers, projects and conferences. As I dealt with enterprise Java software a ton, of course Spring has been a crucial part of my daily job, no matter if it was the core framework, the software eco system and people around it or the open source project Hades that I lead, which is based on Spring and carries Spring principles and values to the domain of easing data access with JPA.

Besides that, the crucial part to me is that Spring and SpringSource as a company have always provided pragmatic solutions to real world problems that are of quality far beyond average. As I already became more and more involved with the Spring codebase, too, I am thrilled to join the team to even more close to the heart of the – to me – core principle of software engineering: pragmatic, high quality solutions to real world problems.

To wrap things up, I’d like to say thank you to all the fellow developers, customers and people in general I met during my time at Synyx. If you need custom first class Java based business software, like to work with people that don’t hesitate to think out of the box – Synyx is the shop you’re looking for.

It’s been a pleasure! And it will be…

Neglected classes in Spring - Part II

2010-01-24T19:16:06+01:00

If you have worked with Spring 2.5 annotation based web MVC framework you know that it allows you to freely design you controller method signatures:

@RequestMapping(value = "users", method = GET)
public String showUsers(Model model) {
  model.addAttribute("users",
    userManagement.getUsers());
  return "users";
}

As you can see we use a parameter of type Model that will we automatically get an instance handed by Spring. For a complete list of supported parameter and return types see Spring reference documentation on that topic.

But why do I mention that? The title says “neglected classes”, not “things I also could have read up in the reference docs”. The crucial thing here is to know that the list of supported types is not fixed and there is an SPI to write your class allowing to get a parameter injected automatically.

Pagination

The first example I want to come up with is pagination. The OpenSource framework Hades provides dedicated support to allow paginated access to databases via JPA. The core abstractions achieving this is the Pageable interface in combination with the PageRequest implementation class. But there is still the question on how to create instances of PageRequest from an incoming request. A naive might be the following:

@RequestMapping(value = "/users", method = GET)
public String showUsers(Model model, WebRequest request) {

  Integer size = // extract size from request
  Integer page = // extract page from request
  Sort sort = // extract sort options from request

  Pageable pageable =
    new PageRequest(page, size, sort);

  model.addAttribute("users",
    userManagement.getUsers(pageable));
  return "users";
}

What’s wrong with this? First, it shouldn’t be the controllers task to extract pagination information from the request. Second, even if we’d move this code into a utility class, we’d be forced to get WebRequest injected into every controller method that wants to use pagination, which breaks the abstraction level gained.

So what about rather something like this:

@RequestMapping(value = "/users", method = GET)
public String showUsers(Model model,
  Pageable pageable) {
  model.addAttribute("users",
    userManagement.getUsers(pageable));
  return "users";
}

public class PageableArgumentResolver implements WebArgumentResolver {

  @Override
  public Object resolveArgument(
    MethodParameter methodParameter,
    NativeWebRequest webRequest) throws Exception {

    // implement extraction logic here
  }
}

Inside the implementation your first task is to determine, whether you can return the given MethodParameter or return a WebArgumentResolver.UNRESOLVED. Our resolver would have to check if the target type is a Pageable and extract the request parameters then.

Accessing the current user

A very often faced problem in web controllers is that one actually has to know which user has triggered the request. This could be of course done programatically inside the controller method similar to the naive approach shown above. What about this approach:

@RequestMapping(value = "/myaccount", method = GET)
public String showUsers(Model model,
  @CurrentUser UserDetails userDetails) {
  model.addAttribute("user",
    userManagement.getUser(userDetails.getId());
  return "user";
}

Similar to the plain type based WebArgumentResolver implementation for Pageable the implementation here would check for the custom CurrentUser annotation and then access e.g. Spring Security API to access the currently logged in user. The additional annotation is “necessary” in this case, as one could also have a UserDetails used as ModelAttribute, but that depends on the detailed requirements of your application.

Summary

WebArgumentResolver allows providing your own custom controller method parameters to centralize either lookup or extraction logic, that would otherwise be scattered through your controller code.

Article on Hades in current issue of German JavaMagazin

2009-06-04T07:03:20+02:00

The June issue of the German JavaMagzin features an article about Hades written by myself. I sketch out issues implementing persistence layers briefly and introduce solutions to these issues using Hades. Furthermore fellow developer Alexander Hanschkeintroduced Java User Group Mannheim in yet another article, too. Check out the current issue and get your copy.

Beyond that, we at Synyx decided to give the part of our homepage that deals with our OpenSource projects a brush up. Check out http://www.synyx.org to start diggin into the projects, read up our developer’s blogs and keep in touch via the project tracker. Kudos to Philip Reiman who did most of the work.

Diggin' into Spring 3 transactional test facilities

2009-05-28T20:16:06+02:00

Today I devoted my day to a general check in how far Hades can be run with the latest Spring 3 milestone. After managing the typical Maven foo I had a project profile up and running that builds Hades against Spring 3 M3 and executes the tests against it. In case you try to migrate some of your code, too, and wonder where spring-agent JAR has gone: its org.springframework.instrument now. But back to topic.

The build went fine but unfortunately some of my test cases broke when executed under M3. I noticed that things started to get fuzzy with the first test case that was supposed to throw an exception. I have some test cases that look as follows:

@Test(expected=DataAccessException.class)
public void checkDoesNotCascadeIfNotConfigured() {

  // Setup some persistent object graph that is
  // supposed to throw an exception

  userDao.saveAndFlush(user);
}

The key thing to notice here is that I flush the database as the constraint violation I want to expose is only checked at the time the data gets pushed to the database actually. Stepping through the code of Spring testing library in a first level of detail, I realized that the exception is thrown correctly and even detected as the one that is supposed to be thrown. Nevertheless the test method was marked as failed with the exception supposed to be thrown. Furthermore all upcoming tests failed with a duplicate key exception as setting up the test fixture failed right in the beginning. What the heck was going on?

It seemed obvious to me that there would have to be something wrong with the transaction management, so I digged a little further in that direction. Finally I found out this one: in this commit Jürgen Höller added a transactionStatus.flush() during the rollback of a transaction after test execution. This of course raises the exception I wanted to raise a second time but - unfortunately - after the moment the first exception had already been checked to be the expected one. Thus the second exception bubbles up causing the test and the rollback to fail.

As I spoke to Jürgen we found out that the flush was implemented due to a improvement filed in JIRA. Fortunately there is already another ticket that adresses the issue. Waiting for RC1 to see this fixed…

Hades itself seems to be Spring 3 ready already, so if you play around with both of ‘em, I’d be happy to address any issues you face.

Using Spring's @Configurable in three easy steps

2009-05-25T20:57:53+02:00

As you might not be aware of, besides injecting dependencies into beans Spring is able to inject dependencies into objects that are not instantiated by Spring. This becomes especially handy if you’re stuck to Domain Driven Design leveraging a rich domain model over an anemic one. As there’s been some buzz around that functionality on twitter, I just put some small quickstart project together that has rather stripped down character but shows all the necessary steps nevertheless. The links to the sources as well as the binaries are attached below. Here is what you essentially have to do.

1. Equip your domain class with `@Configurable`

The domain class in the sample is org.synyx.samples.spring.atconfigurable.domain.User. Note that we can inject the referenced service by just stating an @Autowired property. No setter needed, no pollution of the domain class’ interface.

2. Enable injecting capabilities in your configuration file

The maven project I have created states a dependency to spring-context that allows two critical declarations: <context:spring-configured /> activates injection into domain classes not managed by Spring. Note that I use <context:component-scan /> in the application-context.xml to pick up the User class as well as GreetingServiceImpl from the service package.

3. Enable load-time weaving

To actually get the injection working you need to weave some Spring aspects in your domain class. While you could do this by compile time weaving, i chose load time weaving as it is much simpler to set up in development environment. To get it up and running you declare <context:load-time-weaver aspectj-weaving="autodetect"/> that pretty much tells Spring to look around for some available load time weaver an use it. The cruicial part now is to activate a Java agent for your runtime that now weaves the aspects into the domain class during class loading. In my case this is done by activating the agent via a command line argument for Maven’s Surefire plugin.

This way you can easily enrich domain objects maybe persisted by Hibernate with domain services managed by Spring

Resources

Hades 0.5.0 released

2009-05-22T16:40:40+02:00

Let me prodly announce version 0.5.0 of Hades. As our project home gives you the quick overview and access to the latest binaries, sources and documentation I want to use this post to elaborate a little bit on the changes in 0.5.0 as well as the future roadmap.

Streamlining of the Spring namespace

Version 0.5.0 one more time simplyfies the XML required to setup Hades DAOs with Spring. The only required attribute at the dao-config element now is base-package which aligns pretty much from the base-package Spring users know from Spring’s context namespace. As with this namespace you can use Ant style wildcards to form package patterns to allow more flexibility. E.g. <hades:dao-config base-package="com.acme.**.dao" /> would scan all packages starting with com.acme and ending on dao for Hades DAO interfaces and create the appropriate instances for them.

OSGi ready

There was a bug in 0.4 MANIFEST.MF that trapped a few users from using Hades in an OSGi environment. 0.5.0 is fully OSGi compatible and ships with a sample application that can be dropped into a Spring-DM OSGi platform (e.g. SpringSource DM Server). The sample app gives an overview about Hades functionality and exposes a User DAO as OSGi service. Check out the sample application here.

Programatic API

Most users will happily use Hades in combination with Spring namespace configuration. Programatic use of Hades was always possible albeit only through a rather untyped GenericDaoFactoryBean that implements Springs FactoryBean interface. With 0.5.0 Hades provides a GenericDaoFactory that provides an interface that suits needs for programatic access. Now you can create DAO instances by simply invoking GenericDaoFactory.create(em).getDao(UserDao.class);

Miscellaneous

We aligned our versioning and artifact naming OSGi conventions.

Roadmap

As we consider Hades to be mature, we’re going to release a version 1.0 next. Timeframe is about end of June. We will stay on JPA 1.0 for this 1.0 branch of Hades. So with the release of Hades 1.0 we will also open up a 2.0 branch that will contain features that required JPA 2.0.

Achieving application modularity with Hera

2009-05-17T16:04:27+02:00

The latest episode of the JavaPosse podcast presents a session of the this year’s JavaPosse roundup on Scala and application modularity. Although I attended the conference I did not attend this session, which is rather sad in retrospect as the attendees discuss a lot of things I also deal with.

As a note aside I want to mention, that I am of course aware of OSGi and it’s capabilities, that prvide a very sophisticated and mature solution to this problem. Nevertheless using OSGi introduces a fair amount of additional complexity and - despite its maturity - still lacks tool support to a large extend. Thus I won’t discuss anything OSGi related here.

Bill Venners opens the session by describing how Scala’s traits can be used to mix in functionality into objects at their construction time and wants to know how this can help solving problems regarding modularity in currently in-the-field Java. As I am facing these kinds of issues in my everyday development I will briefly describe the solution I came up with.

The concept of binding

At some point Joel Neely brings the discussion to an interesting point. There is an example the group elaborates on dealing with a piece of software that contains a certain part with customer specific code that will change for each deployed instance of that software. A second example they discuss is somewhat similar but deals with tax calculating rules in various US states that can differ from state to state.

Both examples should be factored out into modules as I think, but the distinction which of the modules shall be used by the application has to be made at different times. Joel uses the term “binding time” to describe this situation. In the case of the customer specific code binding time is application packaging time actually. Stepping one step back it boils down to the availability of the module JAR in the applications classpath. Using a dependency management system like Maven you actually would have a Maven project for customer A that declares a dependency to the application core plus the JAR with customizations for customer A and the same for customer B but with a different customizations JAR. This way you also avoid shiping customer specific code to a different customer.

Aligning object creation to the classpath configuration

Besides the availability of types, organizing the object web an application consists of is the second part of the challenge. Spring serves this purpose quite well and supports a variety of configuration formats and options. A first step to real application modularity is aligning ApplicationContext creation to the before mentioned usage of the classpath to assemble modules.

Springs XML configuration is widely regarded as very static as typically changing something in the bean wiring means editing some of the config files. But using

<import resource="classpath*:com/acme/**/my-context.xml" />

in config files of a core application allows to transparently add beans from configuration files named my-context.xml under a package com.acme to an ApplicationContext. This way determining the application classpath leads to the creation of certain Spring beans without actually touching any configuration files as long as module JARs declare their beans in my-context.xml and thus aligns availability of beans in the ApplicationContext to the classpath configuration.

Client side binding

This leads us to the question how an extensible object gets access to the instance that is created from an module JAR’s my-context.xml. Referencing by bean id does not seem to be a good idea as this would imply to much on the module author and entirely break if there is more than one bean to be referenced. This is where Hera comes into play. It provides a Spring namespace to dynamically lookup beans from an ApplicationContext and let them be bound to a collecting bean. Thus by defining

<hera:list id="foo" class="my.plugin.Interface" />

all beans implementing my.plugin.Interface would be collected into a ListFactoryBean and could be referenced by other beans. In effect this will allow you to dynamically inject dependency in your beans just by configuring your classpath. For our customer sample you would create two modules with classes implementing Interface and use your build system to package one into the one assembly the other one into the other. No Spring reconfiguration needed - configure your app by stating it’s dependencies.

Binding at runtime

As this serves fine for our customer code example what about the taxes example. To find a suitable answer for this problem you actually would have to add all the JARs for the different states and decide at runtime which one to use dependeing on the state the user originates from. Here’s how you’d approach this using Hera. The first step is to let your TaxCalculator extend Hera’s Plugin<T> interface, that adds a supports(T delimiter) method to allow determining if the plugin is suitable in a given context. The delimiter type in our example could be a State enum or the User type itself. Thus the plugin itself can decide which states it provides tax calculation for.

At the client side aquiring a simple list of all the TaxCalculator instances is not sufficient anymore. You probably want to gain a little more detailed access to certain instances. Thus instead of the list element you now use a

<hera:registry id="foo" class="my.plugin.TaxCalcuator" />

to obtain an instance of PluginRegistry<TaxCalculator, User> that allows you to access the plugin instance in various way, returning defaults if no plugin found for given delimiter and so on. See the JavaDoc for details.

Bringin the parts together

Now suppose you have a set of tax modules for the states as well as some for european countries. Then you can “configure” one instance of your application by declaring customer A customizations JAR as well as the US tax jars in the pom.xml for customer A. The same applies to customer B where you might choose the set of european tax jars.

Summary

OSGi of course is still the way to go if you’re looking for a really sophisticated Java module system. If you are not willing or able to bear the increased complexity and can live without runtime swapping of JARs and visibility constraints enforced at runtime the combination of Maven, Spring and Hera provides a powerful development environment for modular Java applications.

Unit testing annotation based Spring MVC controllers

2009-05-17T08:18:54+02:00

Although it took me a while to get used to them, I now pretty much like the annotation based programming model for controllers in Spring MVC. The major advantage over the traditional inheritance based approach is, that the methods, that are bound to requests are simple public methods, that can easily be unit tested.

So while unit testing the behaviour of the method is fine, one actually might want to test the mapping of URLs. Current Spring code requires you to invoke AnnotationHandlerMethodAdapter, that is responsible for detecting the method to be invoked AND invoking it. This is rather suboptimal as there is actual a private class contained in it that does the method lookup only. I already filed a request for enhancement to extract that class and thus offer an easy way to test URL mappings.

But that does not mean, that pure mapping testing is impossible right now. As long as you can live with executing the body of the controller methods you’re fine anyway. If that causes too much preparation overhead or you simply don’t like (as I do) there is a solution for you: mocking.

Suppose you have a controller class like this:

@Controller
public class MyController {

  @RequestMapping("/users")
  public void foo(HttpServletResponse response) {
    // Controller code goes here...
  }
}

Now you can set up a mock of this controller using EasyMock classextensions or another mocking framework of your choice and thus only check the URL mappings of your controller:

public class RequestMappingTest {

  MockHttpServletRequest request;
  MockHttpServletResponse response;
  MyController controller;
  AnnotationMethodHandlerAdapter adapter;

  @Before
  public void setUp() {

    controller = EasyMock.createNiceMock(
      MyController.class);

    adapter = new AnnotationMethodHandlerAdapter();
    request = new MockHttpServletRequest();
    response = new MockHttpServletResponse();
  }

  @Test
  public void testname() throws Exception {

    request.setRequestURI("/users");

    controller.foo(response);
    EasyMock.expectLastCall().once();
    EasyMock.replay(controller);

    adapter.handle(request, response, 
      controller);

    EasyMock.verify(controller);
  }
}

You probably want to factor out basic behaviour into a common superclass to easily write mapping tests for all of your controllers.

Hera 0.4 released

2009-03-30T15:50:48+02:00

It’s been a silent release, nevertheless I want to post a tiny shout about it. Hera is a small plugin library that allows you to create pluggable architectures based on Spring using build time configuration. You might want to find out details by skimming my introducing blog post about it.

Version 0.4 is not a very feature rich release as there is actually only one new one. With this release you can leverage the Core Spring’s ordering capabilities (either through implementing Ordered or by annotating your plugin classes with @Order) to fix the order of plugins in the registry. Furthermore we made PluginRegistry an interface with 0.4 and provide a SimplePluginRegistry (without ordering capabilities) that is completely independent of Spring and a OrderAwarePluginRegistry that will be used when you use the Hera Spring namespace.

Feel free to check out the new release at http://hera.synyx.org and give feedback!

Java Posse Roundup 2009 - Part I

2009-03-05T10:53:16+01:00

The first two days are over, time to wrap up the first half of it. The actual conference started on Tuesday but the day before there was a Hackathon on alternative languages on the JVM. But let me start from scratch.

My flight to the states was actually quite nice although it took me almost 24h to finally get to Crested Butte, Colorado. Crested Butte is situated in the western Rocky Mountains about 4h south west from Denver. It’s named after the mountain right next to the city and very nice place to do wintersports of all kinds.

Monday

Monday was really messed up because of the jetlag, but that really just turned out in the evening. We had a so called Hackathon the entire day. We split up into few groups exploring features of Scala, JavaFx, Fan as well as Groovy/Grails. In the morning I joined the Groovy/Grails group and met Todd Costella, Alf Kristian Støyle and D.J. Hagberg. We discussed various intentions why you might want to introduce a scripting languages, pitfalls of doing so and so on. After that we kickstarted some grails application. And tried to investigate a little more on that. Intrestingly it didn’t take us that much time to find the first serious things. if you want to take a look at the summarizing presentation we gave, check out the JavaPosse Youtube channel.

In the afternoon we went back to Posse house joining the Scala and JavaFx folks. Tor Norby was some kind of hosting the JavaFx group. They decided to programm some kind of stopwatch that counts down from 5 minutes and changes background and audio the further it targets the 0. They did a kinda ugly prototype just to explore the languages features while Joe Nuxoll (another JavaPosse member) designed a much more pleasing interface with Photoshop. The kinda awesome thing is, that you can simply export the Photoshop file, import it into JavaFx Netbeans plugin and you will be able to manipulate all the layers named jfx:*.

The reason the build this thing was the so called Lightning Talks that we use to do in the evenings. The idea is that you have exactly 5 minutes - not a single second more - to present whatever you like. So you esentially have to sell your point in these 5 minutes, which is kinda hard, as we have seen the last two days ;). If you want to check out these lightning talks, go to JavaPosse Youtube channel.

Tuesday

Tuesday morning we were introduced to the concept of Open Space Conferences. It boils down to rather some kind of discussion thing instead of the one-guy-talks-one-hundred-are-sleeping thing you are used from other conferences. Bruce Eckel who some of you might be familiar with ganve some short intro into that and then we putÂ our session suggestions for the days on a whiteboard.

The first session was on (measuring) productivity. Intrestingly we did not discuss any tools at all but rather discovered that communication and processes very much are the critical point. The second one was on application modularity. We briefly covered plugin architectures, OSGi, (plain) Spring based ones and so on…

In the afternoon I decided not to go skiing so I went to Bruce Eckels house joining the guys who wrote a JavaFx as well as Flex port of Dick Walls JFlubber. These coding dojos are really kind of an seance thing. Although I rather prepared my lightning talk for Wednesday there is an amazing spirit kreeping up there.

In the evening we had the first “real” lightning talks that were actually quite impressing as you can see that some of these guys are pretty much into it and know how to sell their point in 5 minutes. A key thing is that there is absolutely no topic scope given so we had a lightning talk on Selenium as well as a “How did I get 3/4 of the man I was” by Bill Pugh speaking about his diet where he lost a lot of weight. So all that stuff is kinda funny and really geeky…

Wednesday

This morning we started of with a session on developer communication skills, pointed out problems of non colocated teams and all those kinds of stuff. The second one was on Maven. We got actually into bashing it a lot of times but every now and then we emphasized that it actually does a great job except the pitfalls we had discussed. I hope I could convince Dick to take a look at the m2Eclipse plugin. The last session before lunch target developer productivity, how to setup workplaces and so on. Unfortunately I couldn’t attend it entirely as my snowboard lessons kicked rigth of at 1pm. This one was awesome, too. I actually had booked a group lesson but was the only one showing up. So I spend 1 and a half hour in the playgrounds and had 2 (rather sloppy) rides downhill then.

In the evenings there were a lot of further lightningtalks. I had my first one on Hades. I probably will do another one tomorrow. Topic: Coding and Music - Passion and Profession. I actually want to point out some analogies between being a developer and being a musician.

Summing up the first days

Actually there is not that much to say except that it’s awesome. Everyone here is so passionated, talented and into it, I can hardly believe it. Just to give you an impression: Take the last conference you attended. Take the 3 most intresting hallway discussions you had there. Imagine this kind of thing happen 5 days and yo will pretty much get the sense of what this event here is about. I’m really looking forward to the last few days…

Hades 0.4 released

2009-02-26T16:34:58+01:00

Passionatedly practicing conference driven development I’d like to announce version 0.4 of the DAO implementation library Hades.

Eclipse plugin

Using Hades namespace configuration in Spring applications can now be simplyfied by installing the Hades Eclipse Plugin from our update site. The plugin will extend Spring IDE to know the Hades namespace, parse the DAO beans correctly and thus provide the content assist you from from Spring Core’s namespaces. As you can see below it is even able to resolve the classpath scanned DAO instances.

Automatic detection of JPA persistence provider

As of version 0.4 Hades is able to detect the JPA persistence provider you use by inspecting the EntityManager instance. Thus no explicit configuration is necessary anymore.

So feel free to take a look at and provide feedback.

Heading Java Posse Roundup 2009

2009-02-26T16:15:17+01:00

2 more days and I will make my way to Crested Butte, Colorado to join this year’s Java Posse Roundup. Not having attended an “Uncoference” before I really look forward to this style of conference as the concept sounds promising. The week will be packed with geek activities but also leave room for leisure as Crested Butte is situated in a large skiing area actually. Last year’s pictures look awesome.

I’ll try to post here now and then to reflect what’s going on over there but i guess Twitter frequency will be much higher.

Integrating Hades into existing applications

2009-02-06T19:11:58+01:00

Today I’ve got an email by Thomas Braun who considered to play around with Hades. He is facing an application with an existing data access layer based on Spring’s HibernateDaoSupport class. This raised the question of how to integrate Hades into the app without changing existing code.

Thomas was using AnnotationSessionFactoryBean to create the SessionFactory from annotation metadata. As Hades relies on JPA EntityManager interface the basic question was how to use it next to the SessionFactory while avoiding duplicate metadata evaluation and thus two entity handling infrastructure.

The solutions is unexpectedly simple. Supposed you use LocalContainerEntityManagerFactoryBean as you normally would do in plain JPA setup and register it under entityManagerFactory in your Spring configuration file you can configure DAOs based on HibernateDaoSupport as follows:

<bean class="your.dao.based.on.HibernateDaoSupport">
  <property name="sessionFactory">
    <bean factory-bean="entityManagerFactory"
      factory-method="getSessionFactory" />
  </property>
</bean>

The key here is, that HibernateEntityManagerFactory (which is the type that will be created by the LCEMFB if you use the HibernateVendorAdaptor) offers a method getSessionFactory to get access to the underlying SessionFactory instance.

Once again nice to see how easy Spring helps integrating applications, existing code with new approaches.

Clean Code - Review Part I

2009-01-23T20:37:03+01:00

As I have twittered already, I am reading “Clean Code” by Robert C. Martin right now. I expected the book to be a very fundamental one. Although there are a few parts I do not entirely agree with, I just rummaged throught chapter 11 “Systems” on my way home and was surprised how condensed Robert summarizes principles constructing software systems that I usually promote discussing such topics with colleagues.

1. Separate constructing a system frum using it

Detractors of the Spring framework very often claim, configuring a system construction using XML sucks because of lacking type safety et cetera. I don’t want to get into discussion do detailed, but Spring’s way of describing system construction is not tied to XML at all (see Spring JavaConfig). For Robert the startup process of an application actually a concern. A view I kinda like as such, as you then can easily argument in terms of Separation of Concerns as well as the Single Responsibility Principle.

2. Dependency Injection

DI is widely accepted these days, besides the myth that you always need a fully fledged container to use DI in your application. Robert shows some nice examples and points out that the conceptual idea is much more important that the tool you use.

3. Cross cutting concerns / AOP

Systems usually face logic that - coded in plain OO - is tangled though all the codebase. Adressing these issues with AOP leads to much more concise and extendable systems. Robert presents the concept from a very high level point of view and briefly introduces various AOP implementations, advising simple proxy based solutions like Spring AOP or JBoss AOP as suffient for most cases.

4. Incremental design

Robert emphasizes the importance of natural growth of designs. Big upfront designs often appear to be overengineered and too technical that does not abstract business domain on an appropriate level. Which leads us to…

5. Domain specific languages

I also don’t want to open this pandora’s box but clearly second the opinion that you have to find abstractions that are clean, simple and thightly wrapped around the domain to deal with, whether is a technical domain.

Summary

Robert boils down the chapter to the following paragraph:

An optimal system architecture consists of modualrized domains of concern, each of which is implemented with Plain Old Java Objects (or other) objects. The different domains are integrated together with minimally invasive Aspects or Aspect-like tools. This architecture can be test-driven, just like code.

I really just scratch the surface of what the chapter actually covers, but even this single chapter boils the topic down to its essences quite well. Nice to see all these concepts, priciples and attitudes distilled in a few pages.

If you like, check out the book @ Amazon.

The DAO is dead! Long live the DAO!

2009-01-14T21:30:09+01:00

Episode 121 of Software Engineering Radio deals with the topic of OR Mappers. Michael Plöd introduces the concept of object-relational mapping technologies, discusses advantages and disadvantages. The content of the episode is very basic to a large extend, which makes it ideal to get an introducing idea of the topic.

The reason I discuss this here is a discussion Arno (the interviewer) is introducing regarding the necessity of the DAO (Data Access Object) Pattern, if you use OR Mappers. Michael thinks that the DAO Pattern still has the right to exist and I decidedly second that. Let me explain why…

First, let’s take a look at the origin of the DAO Pattern, the problems it was meant to address in times it was invented. According to Wikipedia DAO is defined as follows:

…a Data Access Object (DAO) is an object that provides an abstract interface to some type of database or persistence mechanism, providing some specific operations without exposing details of the database.

In the days it was invented “persistence mechanism” was equal to “JDBC and SQL”. This of coure has changed a lot if you use an OR Mapper or even another abstraction layer above it like JPA. As they provide a more object oriented view on persistence or even a standardized interface. Nevertheless I definately propose the DAO for a lot of reasons. In the podcast Michael coins two main reasons, that I will briefly will describe here. Furthermore I’m going to add some other ones.

Separation of persistence logic and business logic

Using JPA in your service class directly (whether it is a Statless Session Bean or Spring bean) works well as long as you can rely on the really basic CRUD methods: create, update, delete, read. Reading persistent objects already is not that simple anymore.

Tangled code / More sophisticated API

I have never seen an application that did only read all objects at once. You always need to select objects based on a given criteria, sort, page results and so on. If you try to set this up with JPA API or a vendor specific one you tangle your code with persistence code probably even proprietary API (if you use OR Mapper API directly). Furthermore you can easily mix and match persistence technology, if it becomes handy. I’ve seen few projects that use OR Mappers for classic data access and low level JDBC code to perform bulk operations.

Exchange implementation

This is the “Yessss… but who does this?” argument. The answer is: You do! Or at least you should. Unit testing your business logic you should be able to easily mock or stub out your data access code.

Don’t repeat the DAO!

Another aspect of the problem is that CRUD code as well as DAO implementations tend to be boilerplate. Repeated code here and there. Using a DAO layer allows you to gently generalize the code and thus reduce the amount of coded needed to implement it.

Hades to help!

Why am I so passionate about this? If you read my blog now and then you know that I lead project Hades that addresses exactly these issues. So if you ever have experienced one of the issues mentioned above, take a glance at Hades and play around with it if you like.

If you are from Frankfurt/Main area you have the chance to get introduced to it tomorrow evening where I will give a talk on Hades (and the DAO question) on 2009’s first DevDusk - Technology for Techies, a bimonthly meeting of passionated geeks, nerds, techies, whatever you wnt to call them. Would be nice to see you there.

Subtleties on java.lang.Enum

2009-01-12T07:32:01+01:00

As i twittered a few days ago, I stumbled over a subtle issue in the core Java library. Not as extreme as here but one to raise ones eyebrows, too.

I just wanted to write a small method to access an enum value by its String representation or use a default, if the conversion fails:

public static <T extends Enum<T>> T toEnum(String value, T default) {

  // Checking values omitted
  return (T) Enum.valueOf((Class) defaultValue.getClass(), StringUtils
    .upperCase(value))
}

Of course, I wrote a unittest to verify the behaviour and it worked fine. Nevetheless using this class in my application threw an exception for a different (than the one in the testcase) Enum type, claiming the type handed to the valueOf(…) method was not an Enum?

What? I’ve handed over an Enum as default value and you tell me, it is not of an Enum type. I digged down into the details. Looked like Enums with methods broke the code, Enums without methods worked. Seems like the compiler works with anonymous inner classes when creating byte code. The solution to the problem is using getDeclaringClass() instead, as the JavaDoc reveals.

Although I understand that Enums with methods are implemented with inner classes, I do not understand why these inner classes do not extend Enum<T>. Futhermore I cannot believe that the behaviour of getClass() changes depending on whether you use methods in your Enum or not. Strange thing…

Below you find a small test case to reproduce the issue. Be sure you have JUnit in version 4 or above on the classpath.

public class EnumSample {

  private enum Foo {
    FOO;
  }

  private enum Bar {

    BAR {
      @Override
      public void doSomething() {
        System.out.println("INVOKED!");
      }
    };

    public abstract void doSomething();
  }

  @SuppressWarnings("unchecked")
  private <T extends Enum<T>> T toEnum(String value, T defaultValue) {
    return (T) Enum.valueOf(defaultValue.getClass(), value);
  }

  @Test
  public void useSimpleEnum() {
    toEnum("FOO", Foo.FOO);
  }

  @Test(expected = IllegalArgumentException.class)
  public void useComplexEnum() {
    toEnum("BAR", Bar.BAR);
  }
}

Hades at Java User Group Karlsruhe

2008-12-18T14:11:22+01:00

Yesterday I gave a presentation about Hades at the Java User Group Karlsruhe. It was preceeded by an introduction to Aspect Oriented Programming by David Linsin and Florian Waibel of Netpioneer that showed the usage of AOP to define system architecture constraints.

You can download the slides as well as the sample code here or all stuff at the JUG Karlsruhe Google group.

JavaC issues implementing generics

2008-12-15T15:02:20+01:00

Attenting Devoxx last week, I had the chance to talk to Joshua Bloch about an compiler issue I had a while ago implementing static factory method pattern from his book. Take this as example:

public class PluginRegistry <T extends Plugin<S>, S> {
  public static <T extends Plugin<S>, S>
    PluginRegistry<T, S> create() {
    return new PluginRegistry();
  }
}

PluginRegistry<Plugin<String>, String> registry =
  PluginRegistry.create();

Don’t try to get the details, there are only three important things:

Two generic parametrizations, where one is a derived one from the other
The static factory method as suggested to ease using this generic class in Josh Blochs “Effective Java 2” (Item 1)
The last line takes advantage of this method to create an instance of the registry.

The strange thing is, this compiles within Eclipse but does not on plain javac. I mailed Alex Buckley about the issue and after some back and forth he discovered a strange issue with javac.

To let the cat out of the bag: its a bug in javac. Actually according to Maurizio Cimadamore it is a coeffect of some bugs that are actually already marked as fixed (6192945, 6369605, 6193815). I’ll leave out the bloody details, here is, what it boils down to:

Javac somehow only tries to lookup types forward in this case. It infers T == Plugin<String>, but complains that for it Plugin<String> is not a subtype of Plugin<S> (as it has not inferred S yet). Guess what, if you simply switch the generic parameters, it compiles like a charm:

public class PluginRegistry <T extends Plugin<S>, S> {
  public static <S, T extends Plugin<S>>
    PluginRegistry<T, S> create() {
    return new PluginRegistry();
  }
}

PluginRegistry<Plugin<String>, String> registry =
  PluginRegistry.create();

(Note the order of the generic types in the method signature)

Tell me if it’s just me, but now the method signature somehow looks “wrong” to me. As the types are not being derived in the order they are declared at the method. Nevertheless, I at least compiles both on javac and the Eclipse compiler. So keep an eye on stuff like this, if you implement generic types ;). I’ll give you an update if there are further things happen on this.

Spring 3.0 M1 is out now for Maven users, too

2008-12-12T04:17:06+01:00

After the announcement of the release of Spring 3.0 M1 Jürgen Höller blog comments complained the artifacts not to be available in a Maven repository. Actually, according to Chris Beams, it now is. Take a look at his blog comment. I’m leaching it from the servers right now…

Devoxx 2008

2008-12-11T18:30:16+01:00

I’m taking a break currently, skipping one of the talks here. Devoxx is actually the most exciting conference I ever attended and I want to take the chance to recap some of the impressions I got here. After 4 days of non-daylight, lots of coffee and coke, I really have to say that I liked it very much. I will see a presentation by Stephan Janssen on the new Parleys.com as well as some other ones tomorrow but as The days were so fully packed, I’ll try to organize stuff a little.

Monday

The first university day, I especially remember a talk of Ted Neward and Bill Vinner on Scala. They gave an impressive introduction on it explaining some of the philosophical stuff, as well a lot of hands on demos. Ted coined a nice quote, when someone was about to ask if he could turn a Scala class into an EJB he answered:

No, I will not make this an EJB! Get out!

Of course he was not serious (well, actually I don’t know).

Tuesday

Tuesday started out with a presentation of Holly Cummins and Kirk Pepperdine on Java performance tools. The talk had quite a balanced weight between theoretical introduction and tools in action to discover and track performance bottlenecks.

In the lunch break I had my quicky session on Hades, with actually worked out quite well. Actually I stripped it down to be more demo centric the night before. You can download the slides here.

The Pro Spring 2.5 talk actually summed up all the neat features introduced in 2.5. One thing I got stuck on was the fact that you can use @Autowired on a property of type List and it will get all Spring beans injected implementing the Foo interface. Of course this raises the question of how Spring can detect the generic type at runtime. Seems like org.sfw.core.GenericCollectionTypeResolver does the trick.

Wednesday

The session day ended with a talk of Stefan Tilkov on REST Webservices. He could not have given a better and shorter REST introduction than he did. He very nicely unfolded the - sometimes absurd - concepts and abuses SOAP does to HTTP. Just two small examples: have you ever thought about the SOAP notion of an endpoint? As the web is build to be interconnected, the term is just ridiculous. The same applies to tunneling every call through POST or GET, not only freeing HTTP verbs from all its semantics, but intentionally abusing them. As Stefan said:

It’s like overriding a plus method, with formatting your harddrive.”

Note, that same as to the quote of Ted - exeggeration serves descriptiveness. ;)

Yesterday evening was a BOF session of JUG leaders. As I’m not an official leader of any but helping the Mannheim JUG to kickstart these days, I took the chance to map names to faces a little. Some kind of networking activity. Belgian JUG leader Stephan Janssen raised the idea to get more interconnected between local JUGs as well as on European scale. Synchronizing scedules or even build some kind of umbrella organization could help get more famous speakers to smaller JUGs and help attracting more meeting members as well as speakers, too.

Thursday

Today started with the keynote of Josh Bloch who introduced the Generics and Enum chapters from his book. Unfortunately I read it already so there were no big surprises. Josh was followed by Mark Reinhold who spoke about the process of modularizing the JRE into profiles.Â Furthermore he gave more detailled insights into the release plan for Java 7, which shall be released in early 2010. The main topics I can remember were

no closures (jihaa! let’s simply talk another 3 years about it)</li>
no Properties
no reimplemented Generics
small language changes: ** multiple exceptions in catchclause: catch (Foo, Bar e) ** null-safe object traversal: a?.foo()?.bar()? -> returns null if one of the values in between is null ** type inference: Map<String, Object> map = new HashMap(); <- gets new HashMap<String, Object>(); automatically
modularity on language level

Furthermore Mark mentioned that Sun is thinking about dropping backwards compatibility in one of the next version for the sake of cleaning things up. I suspect that to happen with Java 8, as Alex explicitly rejected changes to the Generics implementation which could be done in a clean rewrite.

More detailled information can be found in Hamlet D’Arcy’s blog, who I occasionally met discussing the language changes with Josh Bloch at the whiteboards.

After that I had a lot of hallway conversions as it is nice to get the chance to talk to people being directly involved. With Josh Bloch I discussed a possible bug in either the Eclipse or Sun compiler, I discovered implementing the static factory method pattern from his Effective Java 2. I’m about to hand this one over to Alex Buckley an try to keep track on it.

Furthermore I had a chat with Michael Keith of Oracle about EclipseLink as we had some issues with it implementing support for it in Hades. Here I will also keep in touch with him, hoping to fix the problems.

The most funny part - as I could have predicted - was the Java Posse Live recording. Carl Quinn and Dick Wall were leading it, Tor Norbye and Joe Nuxoll got connected via iChat. I turned out that Tor’s internet connection was not the best and so there was no sound from his side. The guys recapped the stuff they saw so far and it was fun as expected. Ocassionally I met Carl and Dick in the hallways and we had the chance to have a quick chat. As I proudly wore my JavaPosse tshirt, they noticed that the Java code printed on it would not compile actually. If you also own one and haven’t noticed already - go and take a look. I will do so, too.

The day finished with a talk of Stephan Janssen about the future of Parleys.com. Perleys is a platform to publish talks and provide functionality like comments and bookmarks around them. The 3.0 version of it will come with a new publisher module, that eases the post processing of the talks a lot easier. Furthermore channels are to be introduced and you can rent your one space in it. The will be free access for all Java Groups

Hades 0.3 is out

2008-12-06T21:19:00+01:00

I am pleased to announce version 0.3 of Hades, an open source project I lead. The release bundles a new ExtendedGenericDao implementation based on EclipseLink as well as some major package refactorings. For more information and a detailed changelog see the project homepage.

On the way to Devoxx

2008-12-06T17:55:04+01:00

Tomorrow some colleagues and me will be travelling to Antwerp, Belgium to attend this years Devoxx (formerly known as JavaPolis / Javoxx) conference. I really look forward to this as conferences are always a good change to sniff the latest news and currents as well as meeting a lot of fellow developers. Furthermore I will give a short intro into Hades on Tuesday.

I will try to sum up every day with a small blog post as I did on SpringOne Europe already.

Is REST the next Spring?

2008-12-04T18:25:11+01:00

Browsing the latest JavaMagazin leader written by Stefan Tilkov, I stumbled about a phrase in his abstract, that triggered some thought I wanna share with you. Stefan claims REST to be a more lightweight approach to web services than SOAP.

First I have to admit, that I clearly favour REST style webservices over SOAP one, too. The projects I worked with them were clearly less cluttered, less overheaded, and the API much more close to the domain concepts compared to those rumbling with SOAP. But back to the headline statement.

REST webservices - as well as Spring - claims to simplify its technical domain. Spring does for the much broader scope of Java EE development, REST webservices do for loosely connecting software systems. The key concept of both is to concentrate on very core concepts, achieving power through simplicity.

Spring leverages POJO development, the very basic component model of Java Beans. REST webservices do so by cleanly emphasizing the power of REST (as the name suggests).

The last analogy I see is that Spring was not born out of a clinical spec but does is rather based on experiences in real world project. So do REST webservices. Currently there are “only” best practices to REST development, whereas SOAP was backed by a specification since day one. A spec that did not really fit well to real world development introducing way too much overhead. As we saw what influence open source projects like Spring and Hibernate had on EJB 3.0, perhaps we can hope for a much more simplified and natural SOAP 2.0 or even REST WS 1.0?

So you can conclude that despite the different technical domains and scopes you can find subtle similarities in history, core ideas and influence on spec based competitors.

Hades on tour

2008-11-18T10:33:17+01:00

There some upcoming talks on Hades I will give on a variety of locations and events. As I don’t want to deprive the dates from you, here we go:

Dec, 9th 2008 - Devoxx Conference, Antwerpen
Dec, 17th 2008 - Java User Group, Karlsruhe
Jan, 15th, 2008 - DevDusk, Frankfurt

Perhaps some of you will attend one of these events. Don’t hesitate to contact me, get in touch and come by to share thought.

The metadata dilemma

2008-11-18T10:24:59+01:00

Java EE development has been packed with lots of metadata since day one. Things have changed a lot over times and we have been provided with more elegant solutions. I don’t want to go deeply into the ongoing debate on Annotations versus XML but rather go one step back and discuss metadata on a more conceptual level.

What is metadata?

Wikipedia names “data about data” and further explains:

In data processing, metadata is definitional data that provides information about or documentation of other data managed within an application or environment.

In case of application development metadata mostly is a model of some functional or nonfunctional aspect of the application domain. JavaEE defines metadata models to express persistence, transactionality, security. These are mostly technical aspects but often tied to business requirements.

To tie or not to tie?

Thus one could raise the question of how to capture the metadata in a way that it’s relation to functional requirements can be derived easily on the on hand and nevertheless be separated from core domain logic to avoid tangling on the other hand.

Spring was rolemodel in stating that the distinction between business and technical aspects are key to maintainable software. Due to its origin (no annotations available those days) it provided a clean component model based on XML to apply technical aspects with AOP means. Thus the separation was logical AND physical.

JavaEE and Spring 2.0 (and upwards) leverage annotations to express metadata concerns as the preferred way (especially in case of JavaEE). Annotations are tied to the actual code and thus mostly compiled into the class files. Here we separate the metadata aspects logically from the actual code but physically tie it to the class.

The is an ongoing debate if this tight coupling is really suitable, especially defining crosscutting concerns (the JavaEE interceptor model) in one place and binding (and thus tangling) them around classes all over the application.

Nevertheless I definately see advantage in defining e.g. security attributes right at the class - or even more public - at the interface of a component. This would tighten the contract between client and implementation much more. From a business perspective I maybe want the user management component only allow an administrator to delete users, completely independent from what the implementation looks like. Thus it would enrich the interface’s semantics.

Problems

I see two issues in this: first, what if the client is not interested in this particular aspect modeled to the interface at all. As the annotation is compiled into the class to be evaluated at runtime, clients would need the annotation JAR in their classpath. Taking persistence as example I actually don’t see no point why a plain client should be bothered to have the JPA JAR in its classpath just to deal with JPA annotated entities. Very often I end up with more JARs in my classpath that are simply required by metadata annotations rather than implementation libraries.

The second thing is the pure amount of annotations. Suppose you want to persist an entity with JPA and serialize it via JAXB. Welcome to annotation hell ;). Oh, I forgot there is a validation JSR based on annotations on its way round the corner. Erm… do you see the problem?

Conclusion?

While the first issue can be somewhat limited by a set of standardized annotations available via the JRE, I can not really see a way out of problem two today. Of course we raised the abstraction of expressing metadata around application logic, the next quest seems to manage the pure amount of metadata created.

What do you think?

Videos of the Four Sided Cube unplugged gig

2008-11-02T19:18:02+01:00

We just played another unplugged gig at fresh!-Club Mannheim last Friday. My wife took videos of some songs with our photo camera. I just mixed that stuff with the recording of the sound guy, who did a very good job (as usual). I like to post “Bad Day’s Rememberance” as sample here. You can find all videos at our YouTube channel.

The smallest plugin system ever

2008-10-09T10:13:58+02:00

I blogged about Hades, an OpenSource project I lead a while ago. Today I want to launch another neat library. Much smaller than Hades but IMHO useful nevertheless.

Developing Spring applications you often come to the point of having a component that should get a list of collaborateurs injected. The component in turn does select one or many of these collaborateurs based on a defined criteria and works with them. This raises a few requirements:

The component should have the easiest possible access to collaborateurs.
Plugins (hey, we got a name for it!) should be addable by just dropping in a JAR file with an implementation of the collaborateurs interface.
I would be nice if we could integrate this with Spring

Here’s the solution I came up with…

I have an interface Plugin<T>, where T defines the criteria or delimiter to select plugins that shall actually be invoked. The only method this interface contains is boolean supports(T delimiter). To define an actual plugin interface you create an interface that extends Plugin, declare the delimiter and add the business methods you want the plugin to provide. E.g.:

public interface NotificationProvider implements Plugin<String> {
  void notify(Notification notification);
}

Your NotificationProvider instances have to implement supports thus decide if they are able to handle the given delimiter or not. In most cases the delimiter might be a parameter of some business method like Notification in this case, but it does not have to be.

The next core abstraction is the PluginRegistry<S extends Plugin<T>, T>. Wow, whatta signature. Instantiating it, it allows you to register Plugins of type S and in turn access the by providing delimiter in various ways. You can ask the registry for the first suitable Plugin, all suitable plugins or ask for mandatory plugins and let the registry throw an exception if none found. See the JavaDoc for details.

Thats a lot of lowlevel code but enables you to define clean plugin interfaces and manage access to plugin instances in an elegant way. So you can easily inject a PluginRegistry into a Spring bean and access plugins as you like.

<bean id="notificationProviders" class="org.synyx.plugin.core.PluginRegistry">
  <property name="plugins">
    <list>
      <bean class="com.acme.notification.EmailNotificationProvider" />
      <bean class="com.acme.notification.JabberNotificationProvider" />
    </list>
  </property>
</bean>

How to create a registry?

Well, thats nice but quite static. What if you would like to allow your colleague to create a JAR file to drop in your classpath and automatically find his NotificationProvider implementation after next application restart.

Note that I do not want to cover exchanging JARs at runtime, rather want to feature some kind of “configuration on packaging” with the least overhead possible.

This is where Spring comes into play again. I implemented a PluginRegistryBeanFactoryPostProcessor (only less than half of the class name length is my fault ;). It will rummage the parsed bean definitions and combine those implementing a certain interface in a PluginRegistry and expose it as a new bean in the application context itself.

<bean class="org.synyx.plugin.support.PluginRegistryBeanFactoryPostProcessor">
  <property name="lists">
    <map>
      <entry key="notificationProviders"
        value="com.acme.notification.NotificationProvider" />
    </map>
  </property>
</bean>

The property name lists is somewhat ugly as it expects a map as parameter. This is because you ca define multiple lists, each entry results in one list or better named PluginRegistry. This is mainly due to the requirement to create multiple PluginRegistrys with one BeanPostProcessor. Maybe we’d drop this providing a more speaking interface but take into account to register one BeanFactoryPostProcessor for one PluginRegistry.

So how do you set up your plugin JARs?

What we can’t free you from is declaring your plugin implementation as a Spring bean. You should define a special configuration file location and name to allow the plugin host to automatically lookup the plugin configuration file via a wildcarded import, e.g.

<import resource="classpath*:com/acme/**/plugin-context.xml" />

Defining this along with the BeanPostProcessor above in your plugin host JAR will allow you to simply drop plugin JARs into your classpath and let them provide plugin implementation. Using maven you simply need to declare the plugin implementation project as dependency, turning Maven pom.xml files into some kind of program instance configuration.

Syntactic sugar

As you might have noticed, registration of the BeanFactoryPostProcessor is somewhat ugly. Besides the enormous name it is a LOT of XML to just define registering all beans implementing Foo under bar. Furthermore the entry’s “key” is actually the bean id the PluginRegistry is registered under, the “value” is actually a type name.

To ease configuration a little I’ve added a Spring namespace implementation , that boils declaring a PluginRegistry down to something like this:

<plugin:registry id="notificationProviders"
  class="com.acme.notification.NotificationProvider" />

You can gain Eclipse classname code completion by adding org/synyx/plugin/core/config/plugin-config.xsd to your XML catalog. If you installed Spring IDE, it should come up with the code completion if you edit the class attribute of the registry element.

Simple lists

The project also includes Spring support for a little stripped down version of the requirements by providing a BeanListBeanFactoryPostProcessor, that simply combines bean implementing a given interface to a list. This is useful if you want to leverage the automatic lookup functionality but do not need to select beans based on a given criteria and thus in turn not need to implement Plugin and use PluginRegistry. Of course there is also a namespace element list, that provides a configuration shortcut to define this BeanFactoryPostProcessor, too.

Summary

The library offers sophisticated support for the little man’s need to dynamically add and remove plugins at packaging time and thus helps to modularize applications where a fully fledged plugin environment like OSGi can not be used or would be overkill to use.

The library is available in version 0.1 under Apache License 2.0 and can be downloaded from the project website or directly accessed via our Maven repository. I haven’t really polished the website nor declared license text in the source files. This is due to change in a few days.

We don’t have an offical name for the library yet, so any suggestion is welcome. It would be nice, if we could find a name based in greek mythology as we at Synyx typically use names from that scope for software projects.

If you have any comments, ideas, critique dont’t hesitate to leave a comment or contact me directly.

Hades 0.2 is out

2008-09-26T20:35:09+02:00

Today we officially released version 0.2 of Hades, a domain class and DAO development library based on JPA and Spring. Hades is mainly based on an idea provided by Eberhard Wolff in Java Magazin. Hades feature list reads as follows:

Implementation of CRUD methods for JPA Entities
Transparent triggering of JPA NamedQueries by finder methods
Dynamic query generation from finder method names
Implementation domain base classes providing basic properties
Support for transparent auditioning (created, last changed)
Easy Spring integration with custom namespace

Version 0.2 mainly brings minor enhancements and polishes. Since today we’re also listed at ohloh.net. So feel free to check out the documentation and play with it a little.

How to feed link SCM paths into your Trac

2008-09-26T13:11:35+02:00

We’re using Trac 0.10.3 in combination with MySQL at work. Trying to setup a new instance and importing the SVN history i faced an ugly duplicate key error trying to insert the revision logs into the database. As this ticketexplains this is due to an index over a part of the SVN path affected. By default Trac only uses the first 111 characters of it. This of course will crash if you have deeply nested folders in your project.

As the ticket describes this is just an index and can easily be dropped with

ALTER TABLE `node_change` DROP PRIMARY KEY;

Developers facing the real world

2008-09-05T12:45:07+02:00

A few minutes ago I once again stumbled on the strange fact, that every now and then I unconciously apply development concepts to my everyday life or at least detect concepts or violations of ‘em. Just now, we decided to order lunch at the chinese restaurant round the corner. Rummaging through the restaurants brochure, guess what was the first meal offered: Pizza Magarita. WTF? This clearly violates the principle of Separation of Concerns and is also known as the God object antipattern.

Validating domain objects

2008-08-11T20:58:20+02:00

Fellow developer David Linsin wrote a blogpost about validation of domain objects recently. I actually wanted to leave him a reply but it got kinda long so I decided to post it here. So this is what came to my mind:

Prototyping some web portal kind of software I’ve encountered a similar situation. Take a User domain object as example for this problem. I decided to have a domain object as well as DTOs for maybe different clients. Why did I decide to do so? Well, the example beautifully shows what is a client specific vie on domain data. To edit the user on a web frontend (no matter if you want to create a new user or edit an existing one) you mostly let the real application user enter a password twice to ensure he enters the one he really wanted to enter. Nevertheless I of course don’t want to extend my domain object to hold a second password field, just because one single client needs it.

Another thing is registration of new users. I might want to ensure unique email addresses as I don’t want to have two users sharing the same mail address (whether this is a good idea or not).

What has this to do with validation. First of all I realized that validation is a client specific thing to a given extend and cannot be restricted do domain objects. Thus the decision to have DTOs the client technology specific exporters (an MVC controller, a WebService Endpoint a.s.o) handle and validate.

In consequence this means that my DTOs are “userfriendly” taking user form input as it is given. They are validated by external validation classes (maybe nicely separated into a hierarchy to avoid implementing common validation logic twice but allowing client specific validation logic where necessary). These also ensure the identity of both given passwords e.g. or the uniqueness of the user’s email address.

My domain objects are much more restrictive then. I tend to reject as much invalid input as possible. An email class definately would reject an invalid email string with an IllegalArgumentException. Doing so in a DTO would make clean error messaging almost impossible.

As the validation subsystem or layer is allowed to depend on the domain layer I try to use eventually exposable validation logic from the domain layer. The regular expression to reject invalid email addresses in the email domain class could be used to nicely capture and reject the email field on the UserDTO in an Spring MVC validator implementation.

Effective bug smashing with test cases

2008-07-01T11:59:50+02:00

There are a lot of opinions buzzing around about how testing and test driven development helps you writing better software. Reading Secrets of the rockstar programmers just now, I’ve stumbled over an intresting interview with Hani Suleiman, co-author of Next Generation Java Testing. As this is a book purely on testing, you could expect him to be a fervent advocat of TDD. Surprisingly, he takes a very pragmatic approach to testing and simply states, that it should be as easy as possible to be done while understanding that deadlines often prevent you from equipping your polished code with the last 20 percent of test coverage.

Nevertheless, the quote, that pinged my mind, was this one:

The user said, “This thing doesn’t work.” You’re gonna test something that potentially doesn’t work. And so, once you have that test, it’s very easy, because you have that verifiable bug.

(Hani Suleiman on testing and bugs)

Let me elaborate on that a little bit. Hani’s observations largely correspond to the way I usually get started swinging my swat. So suppose you have system in state A in your version control system and a bug report claiming that there is something wrong in this state. Starting to find the cause for the bug you typically accept the ticket, indicating that you are currently working on it. Assume you can reproduce the issue with a test case you fix the according code snippets, make sure you get that green bar and commit everything to the VCS again. Finally you mark the ticket as fixed and add “fixed with revision XYZ” as comment to guarantee tracability, that’s it.

That sound really proficient, doesn’t it? Where the hell is the problem? I have to admit, that this is the way I am working currently, and I really feel comfortable with it. So here is, what the quote made me think about:

Comparing the original state of the VCS (revision XYZ - 1) and the fixed state of the VCS (revision XYZ) you only see one more test case and some modified. Who really tells you that the test case did not work before? As you have committed the already working test case along with the changes, you don’t have a possibility to check, whether the test case is really tight enough to reproduce the problem correctly. So wouldn’t it be better to add the following step to the bug fixing heuristic described above:

After you have completed the test case reproducing the issue you check that one in into the VCS (although this is not buildable, due to the failing testcase!)
You add a comment to the ticket that the current revision lets you reproduce the bug
Continue, like described above

Perhaps I am to addicted to traceability but I really like to be able to track what’s going on, what’s going wrong, what could be solved how and so on.

What do you think about this?

SpringOne 2008 - Application platform keynote

2008-06-12T12:00:19+02:00

Adrian Colyer led the send day’s keynote centered about the Spring Source Application Platform. Unfortunately the duck that became famous last year could not be with him this year. Fortunately Rob Harrop - AP lead developer - replaced it quite well ;).

Adrian and Rob coined out the primary challanges of enterprise applications the standard has not resolved. Of course they presented OSGi as the main foundation to build a solution on that could solve these problems: modularity, dynamics and so on.

Rob discussed an intresting point regarding standard JavaEE applications. As soon as you take the app in production you simply lose insight about all that nicely structured services, repositories and architectural concepts of your application. In operation it is only a WAR (no pun intended). OSGi in combination enables you to take these concepts into production a lot more.

Finally they gave some short demo to see hot bundle replacement. All in all a keynote presenting the current state of the application platform, pointing at the paths still to go. Rob and Adrian expect a lot of improvements regarding dependency profiles and provisioning dependencies into the platform.

Spring 2008 - Summing up day one

2008-06-12T11:58:48+02:00

First da of SpringOne was really intresting. I saw a lot of good talks, either to earn new knowledge or ideas to share thoughts about or at least get a feeling that attitudes, ideas and programming habits I cultivate are very much state of the art.

After the session I enjoyed to talk to a few Spring developers discussing ideas and problems I’ve stumbled above. I talked to Christian Dupuis - lead developer of SpringIDE and the Spring Tool Suite - to get tighter integration of a generic DAO library im currentl working on. He gave me useful tips of how to get the IDE to recognize beans i create through a custom namespace. Maybe we can get our hands on this today and get this working.

After that I discussed a problem with Jürgen Höller that kept me quite confused a while ago. I recently ran into the idea to dynamically lookup configuration files fulfilling a certain naming and placing convention on application startup time enabling the app to work with some kind of plugins just by dropping JAR files into the classpath. Stupidly this did not work in Tomcat. I could dig the problem down to Spring asking the classloader for resources named like the part of the wildcarded config file include up to the first wildcard. Unfortunately these are mostly package names, that correspond to folders. Not all JAR packaging mechanisms do create JarEntries for folders thus the classloader does not find these although there are certainly resources in or below that folders. I myself thought this would be inherent to the JarFile datastructure that would mess up things but Jürgen pointed out that these entries can be created by configuring JAR packageing correctly. Guess what - it works. ;)

Finally I have got some opinions about the Spring Source Application Platform licensing model. The key question to me was when is the point, my application has to be GPL. Seems there are a few different opinions on that, even among the Spring Source guys. Eberhard Wolf gave the most definite one IMHO. As long as you work with the platform in-house and develop and run your application on it, you’re fine. The tricky part is when you have customers that want to host the app themselves. As you develop for Spring Source Application Platform your deployment format differs a lot from a standard WAR format (assuming you want to take advantage of OSGi and other platform features). The key notion in this case is “derivative work”. If you provide derivative work from the AP your app has to be GPL, too. Unfortunately there is no clean definition of this term, yet. You actually come into the debate if you have to either deliver AP with your app to the customer (that would match the term IMHO) or your customer decides to host the AP herself and just drops in your application. Actually that shouldn’t cause a lot of trouble because as your customer decides for Spring Source AP, he probably would want to have some dedicated support, taking apps into production.

This issue is really some subtle problem with GPL in general as it uses terms that do not have been judicially debated seemingly.

As you can see, I came back with my brain packed with a lot of cool new ideas. And there is yet another day ;).

5 (or 3) aspects you probably haven't thought about

2008-06-11T20:09:35+02:00

Alef Arendsen started by giving a short introduction into basic AOP concepts. After that he presented a sample project using Hibernate and JDBC data access together. He construted a business case where the Hibernate property of delaying actual data insert to the database until transaction commit. The solution to the problem would be to flush the hibernate session appropriately. But what means appropriately in this case? Who is responsible to execute the flush? Alef constructed an aspect that watches JdbcTemplate operations and executes the flush accordingly.

The next example was about retrieving localized data. Localized in the sense, that Alef wanted to access all car parts available in a given area. He introduced a view localizing the data into the database and let Hibernate work against that view. Finally he let the current area to retrieve the data for be propagated. This was realized applying an advice to transaction begin time to write the session state area context into the database. To prevent duplicate propagation Alef introduced the AspectJ cflow concept allowing to define pointcuts in the context of anoher pointcut. This means you can describe a pointcut to match a transactional method and only get it fired on the first transactional method even if it triggers other transactional methods that would fire the advice again otherwise. The neat thing about this advice application was, that the filter logic is kept in the database. The aspect itself is only the controller for the actually transparent logic.

Alefs last example was first failure capturing adressing the need to trigger logic on the first occurrence of an exception avoiding to handle the exception twice. Once again he made heavy use of cflow ponitcut definitions. Alef also used a custom aspect instatiation model - instance per pointcut call in this case.

This was a really awesome talk as it showed up the enormous power of AOP and the things you actually can achieve with it.

EclipseLink - Hig performance persistence for Spring

2008-06-11T17:57:14+02:00

Rob Harrop and Shaun Smith gave an overview about Oracle Toplinks successor EclipseLink. They started by outlining the problems Rob faced when trying to integrate a JPA provider into SpringSource Application Platform. Shaun then gave a brief overview over EclipseLink which definately exceeds ToplinkEssentials functionality I have used before. It seems to abstract data access in a more broad way including access to XML or JCA.

A major point of the bothy guy’s talk was caching. Shaun presented a demo where a listener constantly triggered a query to the database. It of course was only executed once. Further queries hit the cache as expected. The nice thing about EclipseLink then was that a thread updating the data transparently updated the cached value, so that the changes were reflected in the listener without triggering a new query.

Another hot topic of the presentation was the use of query hints to optimize data access. Rob suggested to have two aspects defined - one to register hints on named queries in a certain business method call context and another one looking up the hints to append when executing the named queries. This sounds quite good and i think i will take some time to reiterate this.

The last amazing topic was a transparent implementation of a database state history. With EclipseLink it is or will (I don’t remember exactly) to query database state at a given point in time. Especi

Thomas Risberg - Persistence tuning for Spring environments

2008-06-11T14:37:31+02:00

Thomas Risberg, Spring JDBC lead developer, held a talk about data access performance tuning using Spring. He focused on different things like optimizing JDBC statements, transaction manager and data source implementation choices and how you you can configure OR mappers properly.

Besides tuning the application Thomas mentioned a few optimization possibilities around your software. Getting to know the tweaks and trick of you particular database, letting the DBA take a look at the table structure and SQL statments generated can bring you forward, too.

Thomas showed a lot of examples to develop and work with data access, pointed out configuration options for various techniques to let you see what’s going on in detail. He also showed some tools that allow detailled analysis of queries. Developing the SpringSource Advanced Pack for Oracle he gave some more detailled insights in Oracle database performance tunings.

Ending the talk with some deep down performance tunings of actual databases I really hope to get slides as the talk included so many tips I’d like our DBAs be aware of.

SpringOne 2008 - Jürgen Höller - Spring 2.5 on it's way to 3.0

2008-06-11T13:26:41+02:00

In the first part of Jürgen’s talk he summarized the main innovations of Spring 2.5. The release brought significant enhancements regarding stereotype annotation configuration of Spring components. He especially focused on the combination of annotation configuration and AspectJ load-time-weaving. He pointed out some nice examples on the use of @Configurable to transparently inject Spring beans into components created outside the bean container and using @Transactional to allow even in-component method calls to be transactionally intercepted.

Jürgen summarized this part of his presentation by giving recomendations for mixing configuration types. Annotation configuration is primarily meant to express stereotype configuration - meaning to express default configuration. You always have the option to override these defaults by external XML configuration.

Personally I really fight to try experimenting with annotation as this throws away all the consistence in configuration I especially liked about Spring. But I think I’ll give it a try as I had to get used to the namespace configuration as well and really like it now. Nevertheless, the variety in configuration options unfortunately raises the hurdle for beginners a lot.

Jürgen continued giving short insights into Spring 3.0 development. It will be entirely based on Java 5 and its first milestone is expected in August. We can expect to see some cleanups resulting from dropping some supprt for old libraries. Nevertheless Spring 3.0 will be fully backwards compatible to 2.5.

SpringOne 2008 - Kickoff

2008-06-11T12:20:15+02:00

We got up early this morning because we had no clue at all how to get to the conference center. After having breakfast with some of the SpringSource guys we somehow managed to get to the Metropolis. It was quite difficult as the only almost direct line from the hotel is so new, that isn’t noted on any train plan. Happy searching!

Rod Johnson, who we accidently met in the hotel’s elevetor this morning, opened SpringOne 2008 with a keynote exceeding two hours. He primarily stated Springs current position in enterprise development and outlined benefits developers and architects gain from using Spring and SpringSource’s enterprise offerings. Keith Donald and Christian Dupuis gave short overviews of Spring development in the web and the SpringSource Tool Suite.

Finally Rod introduced new VP of product management Peter Cooper-Ellis who has been hired by SpringSource recently and was working for BEA over 10 years.

My software engineering book Top 5

2008-06-08T14:03:33+02:00

As I rummage in Eric Evans’ Domain Driven Design again, I thougt I’d collect my favourite software engineering books to provide a list of what you as a software professional should have taken a glance at. Althought it seems to be a hitlist, actually there is no real ranking between the chosen.

Eric Evans - Domain Driven Design

This book focuses on software design and on distilling domain knowledge into it. Thus unlike the GoF book that covers rather technical patterns, DDD tends to be coming from a more business point of view. Eric introduces Entities, Value Objects, Aggregates, Services, Repository (DAO) and so on. I especially like this point of view as it focuses on functional requirements and derives patterns from them. Erics core aim is to tie software design to an ubiquitous language so that developers and business persons speak in the same terms, thus letting the software artifacts created reflect the business more incisively.

Definiately the first book I hand to beginners as it provides a basic pattern catalogue along with a mindset I really think is indispensable - building easy to understand abstractions, care about design, about code, about functional requirements.

[Domain Driven Design @ Amazon](http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1212925819&sr=8-1)

Martin Fowler - Refactoring

Recently I discovered a presentation of Martin Fowler on SOA where he accidentally gave the key rational to refactoring: accept change as intrinsic trait of software development and be prepared to adapt to it. Now refactoring is the key concept that enables you treating your code not to be carved in stone but rather allows you to adopt emerging changes.

Martin introduces a lot of core refactoring concepts and patterns. Most of the can be found in state-of-the-art IDEs like Eclipse or IntelliJ.

[Refactoring @ Amazon](http://http://www.amazon.com/Refactoring-Improving-Existing-Addison-Wesley-Technology/dp/0201485672/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1212925933&sr=1-1)

Johannes Link - Softwaretests mit JUnit

Agile software development builds on various heuristics and methodologies like continuos integration and first of all unit testing or even Test Driven Development (TDD). Trying to become agile without adopting these techniques you will find your self in a mess very fastly. Softwaretests mit JUnit introduces core testing principles and methodologies. Although there are much more sophisticated testing frameworks like TestNG available today the book reads well because of the its very basic starting point. It was published in times when unit testing was not that of a prominent idea. Thus it really gives an introduction from the very first steps.

[Softwaretest mit JUnit @ Amazon](http://www.amazon.com/Softwaretests-mit-JUnit-Johannes-Link/dp/3898643255/ref=sr_1_1?ie=UTF8&s=books&qid=1212925974&sr=1-1)

Steve McConnell - Code Complete

That’s a really huge one. And all on coding? This has to be boring! Well, it isn’t. Code complete is on a much more technical level of abstraction that DDD but it takes a look on code from the same point of view: communication. Steve discusses everyday quests developers fight: method naming, method’s lengths.

This one’s a must-read for every developer IMHO. It was eye-opening to me and influence my attitude towards code totally. Actually the current version is named Code Complete 2, althought it’ just a second edition of the original one. I guess, it’s because of the amount of changes that were made throughout the update.

[Code Complete @ Amazon](http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1212926233&sr=1-1)

Martin Fowler - Patterns of Enterprise Application Architecture

This one is rather technical. Technical in a sense, that it adresses non-functional requirements much more than DDD thus being much more relevant for architecture decisions and development. So you will find patterns like Adaptor, Gateway, Unit of Work, Plugin etc.

In fact, this is not a beginner one but is rather an architects groundwork to build further knowledge and experience on.

[Patterns of Enterprise Application Architecture @ Amazon](http://www.amazon.com/Enterprise-Application-Architecture-Addison-Wesley-Signature/dp/0321127420/ref=sr_1_1?ie=UTF8&s=books&qid=1212926280&sr=1-1)

Reading "Domain Driven Design" again

2008-06-06T14:56:51+02:00

Currently I read Eric Evans’ ”Domain Driven Design” once again. Having done so 3 times already, I discovered a paragraph that reminded me of a blog post written by David Linsin a while ago. Eric writes as follows:

"Well-written code ca be very communicative, but the message it communicates isnot guaranteed to be accurate. Oh, the reality of the **behaviour** caused by a section of code is inescapeable. but a method name can be ambiguous, misleading, or out of date compared to the internals of the method. The assertions in a test are rigorous, but the story told byvariable names and the organization of the code is not. Good programming style keeps this connection as direct as possible, but it is still an exercise in self-discipline. It takes fastidiousness to write code that doesn't just **do** the right thing but also **says** the right thing"

This states that well written code is not about just to look nice in your IDE - it’s about communicating. I e.g. favour an EmailAddress class over a simple String property in a User type cause this simple change distills so much more semantics.

“Domain Driven Design” is a book you can actually start reading from the front if you have reached the end. From time to time I reiterate over the book just to find new influences or judge new knowledge I gained in projects. I can only recommend to take a glance at it. For those of you that shy digging through over 500 pages there is a distilled version at infoq.com that nicely wraps up the book.

There are a few other books that influence my attitude towards coding a lot. Perhaps I’ll find time to provide a Top 5 on my upcoming trip to Antwerp.

Switching language / SpringOne ahead

2008-06-04T21:16:24+02:00

As I am concentrating on IT related posts more and more in this blog, I’ll post in English from now on. Currently I’ve not deciced whether to translate old posts. Depends on how I will find time.

Next Tuesday I’ll hit the road towards Antwerpen where this years SpringOne will take place. I really look forward to meet all the guys and soak up Spring spirit. I’ll post about the sessions I attend.

Clueso - So sehr dabei

2008-06-01T20:23:38+02:00

Zufrüh geflucht. Donnerstag abend schneite die Versandbenachrichtigung in meinen Strompostkasten. “Dann ist die nie und nimmer morgen Mittag da.”, dachte ich und war schon etwas geknickt. Als ich Freitag Mittag nach Hause kam, lag der Benachichtigungszettel im Briefkasten ;). Da ich es allerdings nicht erwarten konnte die Platte schon Freitag zu hören, gabs früh um 6 einfach noch die iTunes Edition. Da das Wochenende gespickt war mit 17 Stunden Autofahren, gab es reichlich Gelegenheit “So sehr dabei” zu sein und Eindrücke zu verarbeiten. Zeit, nach gefühltem 10 Mal hören ResumÃ© zu ziehen.

Das mittlerweile 4. Album von Clueso trägt wie oben schon erwähnt den Namen “So sehr dabei”. Die iTunes Edition enthält ein paar Audiokommentare zu diversen Songs und auch zum Album selbst. Spannend dabei ist, dass der Titel der Platte wohl langezeit vakant war. Der andere Kandidat war “Augen zu”, Track Nummer 2 des Albums. Meiner Meinung nach hat der falsche Titel das Rennen gemacht. Warum? Dazu später mehr.

Grundsätzlich setzt “So sehr dabei” die Richtung fort, die über die letzten 3 Alben deutlich wurde. Ich kann mich noch erinnern, als ein Freund von mir beim Release von “Gute Musik” zu mir kam und meinte, die Platte wäre sehr untypisch für HipHop, eher ein Singer / Songwriter Ding. Wenn wir damals gewusst hätten, wohin sich diese Entwicklung steigert.

“So sehr dabei” ist vor allem deshalb “So sehr anders” weil sie im Gegensatz zu ihren Vorgängern anders entstand. Geschrieben haben Clueso und einige andere Vertraute die Songs hauptsächlich im ostsächsischen Görlitz. Aufgenommen wurde die Scheibe mit der kompletten Band in einer spanischen Finca im Sommer letzten Jahres. Beim ersten Hören mag man allerdings nicht ganz glauben, dass dieses Album im Sommer enstanden ist. Inhaltlich und auch musikalisch wirkt vieles schwerer als in den Vorgängeralben.

Doch genau hier findet sich die erste Stärke der Platte: die Songreihenfolge. Jedes mal, wenn man das Gefühl bekommt, nun hat man aber einen ziemlichen Brocken vorgesetzt bekommen, der erstmal zu verdauen ist, setzen Clueso und Band eine lockeren Kontrapunkt, der das Ganze wieder etwas auflockert. Klar, von der poppigen Frische von “Weit weg” hat man sich wieder etwas entfernt - mir isses recht ;). “Wir woll’n Sommer”, “Mitnehm’” und das seit dem Bundesvision Song Contest deutschlandweit bekannte “Keinen Zentimeter” sind eher die lockeren Songs. Dazwischen finden sich viele zum teil sehr kopflastige Stücke, die jedoch alle wohldurchdacht aneinandergereiht scheinen.

Viele Stücke der Platte scheinen inhaltliche oder musikalische Nachfolger früherer Songs zu sein. “Geisterstadt” - einer meiner Favoriten - erinnert mich musikalisch sehr an “Nacht unterwegs”. Inhaltlich kann man ihn mit “Bleib einfach hier” in eine Reihe stellen.

Kommen wir zur zweiten Stärke der Platte - die Band. Ich weiß gar nicht wie viele Konzerte ich mittlerweile Schon von den Jungs gesehen habe. Es ist einfach jedes Mal aufs neue ein Erlebnis, die 7 zu erleben. Es gibt nicht viele Musiker die in diesem Alter schon so viel Gefühl für das richtige Maß haben. Hier spielt nie jemand zu viel, jeder songdienlich und mut soviel Geschmack. Diese Energie auf CD zu pressen, haben schon viele versucht und die meisten sind daran gescheitert. Für mich ist eben dieses Experiment genau das, was die Platte von den vorherigen unterscheidt, das was “So sehr dabei” zu “So sehr dabei” macht.

Was mir bei “Weit weg” ein wenig gefehlt hat, findet man auf dieser Platte wieder verstärkt. Kleine versteckte Ideen, Witzeleien oder halt überhaupt Sachen, die erst beim 4. oder 5. Hören auffallen. Sei es das leise 50Hz Brummen auf der Akustikgitarre in “Barfuss” (zu hören nach den ersten paar Akkorden im Intro - Kopfhörer und schön aufdrehen”, Philips Tastengeräusche im Intro zu “Augen zu”, Pauls Arschbombe nach “Wir woll’n Sommer”, Philips 5/8tel Outro aus Geisterstadt.

Insgesagt ist “So sehr dabei” eine konsequente Platte. Konsequent in Bezug auf die musikalische Entwicklung, konsequent aber auch in Bezug auf den Faktor Pop, der mit Veranstaltungen wie dem Bundesvision Song Contest natürlich auch vermehrt Einzug in die musikalische Welt von Clueso und Band hält. “Keinen Zentimeter” und “Mitnehm” sind genau das - Pop - trotzdem eigenständig, echt und auf verdammt hohem Niveau. “So sehr dabei” ist keine einfachte Platte. Besonders Fans der neueren jüngeren Generation könnten evtl. etwas überfordert sein angesichts der textlichen und musikalischen Tiefe. Sehen wir das halt als Herrausvorderung und Chance ;).

Einziger Fehler der Platte ist meiner Meinung nach, dass sie nicht “Augen zu” heißt. Ich finde, dass dieser Song ein Spiegelbild der Scheibe ist. “Bandlastige” Strophen, 4 to the floor im Refrain, zum Schluss läuft das ganze zusammen. Auch textlich einer der intensivsten Stücke des Albums. Also - ab, Augen zu, weit weg mit Text & Ton und Guter Musik.

Spass mit Maven Archetypes

2008-04-22T17:37:13+02:00

Wir führen in der Firma nach und nach Docbook als Dokumentationsstandard ein. Mit docbkx steht auch ein Plugin für unser Buildsystem Maven zur Verfügung. Nachdem ich die letzte Woche das Synyx CI in ein XSLT Stylesheet gegossen hatte, versuchte ich aus dem Proof of Concept Maven Projekt einen Archetype zu machen.

Archetypes sind Projektvorlagen in Maven mit denen man bei einem Projektstart on the fly eine Ordnerstruktur generieren und Konfigurationsfiles vorerzeugen kann. Dies verringert den Aufwandand die Infrastruktur einzurichten am Anfang eines Projektes erheblich.

Ein Archetype ist selbst wiederum ein Mavenprojekt, in dem die für ein neues Projekt notwendigen Dateien an eine Bestimmte Stelle im Archetypeprojekt gelegt werden und ein Archetypedeskriptor namens archetype.xml im META-INF abgelegt werden muss. Soweit die Dokumentation die hier zu finden ist.

Nun will das Archetype Plugin von Maven allerdings in den bereitgestellten Dateien typische Mavenplatzhalter wie ${version} durch Parameter ersetzen, die man beim initialisieren des neuen Projektes mitgibt. Es war nun schon nicht einfach herauszufinden, wie ich Maven aber dazu bringe diese Platzhalter einfach Platzhalter sein zu lassen. Nach einer Weile googlen fand ich dann heraus, dass das Dollarzeichen einfach escaped werden muss (\${version}). Dies funktioniert aber nur ab Maven 2.0.8.

Nachdem diese Hürde genommen war musste ich Velocity (was Maven benutzt um diese Platzhalter zu ersetzen) nur noch ausreden die TrueType Fontfiles für unsere Hausschrift zu parsen. Das Problem: für den Archetypedeskriptor gibt es weder DTD noch ein XSD. In den Untiefen des Nabble Forums stieß ich dann auf den Hinweis, das Attribut filtered="true" in den <resource /> Elementen würde genau dies bewerkstelligen.

Was ihr jetzt hier in knapp 5 Minuten gelesen habt, hat mich locker 3 Stunden gekostet^^. Jaja, Dokumentation ist manchmal eben doch hilfreich ;).

Trac 0.10.3 auf MySQL

2008-04-21T15:59:47+02:00

Ich habe mir bei meinem Arbeitgeber für ein paar kleinere Projekte ein Trac eingerichtet, das gegen eine MySQL Datenbank läuft. Das ganze macht besonders im Zusammenspiel mit Mylyn großen Spaß. Gestern fiel mir jedoch auf, dass ein paar der vorbereiteten Ticketqueries nicht funktionierten. Angeblich sei der Query falsch.

Nach kurzer Recherche stieß ich auf einige die das gleiche Problem hatten. Es handelt sich wohl um einen known Bug, der mit Release 0.10.4 behoben sein wird. Denjenigen die - wie ich - nicht so einfach auf diese Version upgraden können, sei geraten einfach die einfachen Hochkommata um Vorkommen von $User in den Queries zu entfernen. Dann tut alles wieder wie erwartet.

Spring Webinar

2008-03-10T20:46:03+01:00

Nächsten Dienstag (18.03.08) werde ich über den IRC des Forums tutorials.de ein Minitutorial zu Thema “Leichtgewichtige JavaEE Entwicklung mit Spring” halten. Der Code basiert zum Großteil auf dem Beispielcode meines Vortrages bei der Java User Group Karlsruhe.

Nähere Informationen zum Vortrag gibts hier.

Agim Emruli - Spring WebFlow

2008-03-03T18:30:33+01:00

Agim schloss die Vortragsreihe mit einer Präsentation zu Spring WebFlow und Spring Faces. Zu Beginn stellte er die zentralen Konuepte Flow und Conversation vor und ging im weiteren auf den Flow scoped PersistenceContext ein, der Persistenzkontexte an einen Flow bindet und somit unnötiges mergen von Domänenklassen an eine Datenbanksession vermeidet, dadurch aber das Risiko erhöht Probleme mit dem Optimistic Locking zu bekommen.

Spring Faces ist ein JSF Integration für Spring WebFlow. Diese erlaubt die nahtlose Integration von JSF Komponenten in Spring WebFlow. Abschließend gab Agim noch Best Practices beim Arbeiten mit beiden Frameworks preis.

Erich Eichinger - Spring .NET

2008-03-03T17:30:16+01:00

Spring ist nicht nur im Javaumfeld beliebt sonder erfreut sich auch in .NET Umgebungen steigendere Beliebtheit. Erich stellte den aktuellen Stand des .NET Ports von Spring vor. Der aktuelle Funktionsumfang des Projekts kann ungefähr mit dem Stand von Spring 1.2 allerdings mit Namespace Support gleichgesetzt werden. Erfahrenen Springanwender sollten sich also ohne große Mühe in Spring .NET zurechtfinden.

Spring .NET beschränkt sich allerdings nicht nur auf den Port bereits existierender Funktionalität aus der Java Version von Spring. Mit der Spring Expression Language (SpEL) entstehen auch interessante Features die wohl früher oder später auch auf die Java Plattform protiert werden. Mit der SpEL lassen sich zum Beispiel Exceptionübersetzungen und Retrymechanismen in DSL Manier formulieren:

on exception is ConcurrentModificationException retry 3x delay 1s

Insgesamt ein recht spannender Vortrag der wieder einmal deutlich macht, wie gut Spring unterschiedliche Technologien und Plattformen abstrahiert.

Arjen Poutsma - Spring WebServices

2008-03-03T16:15:54+01:00

Arjen stellte mit Spring WebServices ein WebService Framework vor, dass explizit den dokumentgetriebenen Contract-First Ansatz addressiert. Hierbei beschränkt man sich jedoch darauf die Messages als XSD zu beschreiben. Das verfassen von WSDL Dateien wird überflüssig. Ebenfalls ist es nicht nötig Stubklassen generieren zu lassen.

Arjen zeigte anhand eines kleines Hotelbuchungsbeispiels die grundätzliche Vorgehensweise und deutete die verschiedenen Integrationsmechanismen an (DOM API oder Object XML Mapping.

Die Dokumentenorientierung und vor allem der Contract-First Ansatz sorgen insbesondere in heterogenen Umgebungen für weitreichendere Kompatibiltät als dies bei Code-First Ansätzen der Fall ist.

Zum Schluss gab Arjen noch einen Einblick in das kommende 1.5 Release. Dieser addressiert vor allem verschiedene Transportmechanismen wie JMS. Auch etwas extravagante Lösungen wie WebServices über SMTP wurde angedeuted. Ohne angeschaltete Validierung, die evtl. auftretenden Spam ausfiltert sollte sowas jedoch wahrscheinlich nicht in Betrieb genommen werden ;)

Mike Wiesner - Spring Security

2008-03-03T14:45:55+01:00

Mike stellte dann das aktuelle M2 Release von Spring Security vor. Hier ging er sehr detailliert auf den in M1 eingeführten Namespace ein, der die Konfiguration des Frameworks erheblich vereinfacht. Die auf der Standard Bean Konfiguration basierende Konfiguration war unheimlich umfangreich und ein Kritikpunkt des 1.x Release. Die Dokumentation des Namespaces war Hauptinhalt des M2 Releases.

Insgesamt ist durch den Namespace die Konfiguration erheblich kürzer und - IMHO noch wichtiger - wesentlich sprechender geworden. Mike stellte einzelne XML Elemente im Detail vor und bot damit mit seinen Folien einen ersten Draft der für die finale Version angekündigte Doku. Abschließend zeigte Mike noch die Verwendung der <authz:... /> Taglibrary vor und gab einen kurzen Einblick in den manuellen Zugriff auf Authentifikationsdaten.

Jürgen Höller - Spring 2.5

2008-03-03T12:25:11+01:00

Als nächstes gab Jürgen Höller Einsichten in neue Features von Spring 2.5. Diese bauen zum Großteil auf Features von 2.0 auf und vereinfachen die Nutzung dieser. Dies betrifft vor allem die Unterstützung der Common Annotations (JSR-250) die auch in JavaEE Verwendung finden.

Desweiteren bietet Spring 2.5 eine verstärkte Unterstützung für JavaEE Plattformen und vereinheitlicht die angebotenen APIs verschiedener Vendors. Für den IBM WebSphere Application Server zum Beispiel wird nun TransactionSuspension unterstützt.

Im Bereich der angewandten AOP liegt in Spring 2.5 der Fokus auf dem Loadtime Weaving, zumindest hat sich in diesem Bereich am meisten getan. Mit <context:load-time-weaver /> wählt Spring automatisch den zur Plattform passenden Loadtime Weaver aus und man kann damit transparent vom einer SE Umgebung in den Tomcat wechseln.

Jürgen ging dann noch kurz auf die unterschiedliche Implementierungs- oder Anwendungsmechanismen von AOP ein. Der proxybasierte Ansatz, den Spring standardmäßig benutzt, sorgt zwar für einen minimalen Overhead, erlaubt jedoch sehr gezieltes Anwenden von Aspekten. Loadtime Weaving bietet hingegen Performancevorteile, birgt jedoch die Gefahr bei ungenauen PoincutDefinitionen unbeabsichtigt Klassen zu advisen.

Im Kontext der Plattformen auf denen Spring eingsetzt wird erläuterte Jürgen dann noch, dass das Weavingkonzept Teil von JavaEE (insbesondere der JPA) ist und somit auf allen JavaEE Servern zur Verfügung steht. Spring ermöglicht es, diesen Mechanismus auf andere Anwendungsbereiche auszudehnen.

Eberhard Wolff - Spring Portfolio

2008-03-03T10:30:33+01:00

Nach eine kurzen organisatorischen Einführung begann Eberhard mit einem Ãœberblick über OSGi, das dynamische Komponentenmodell für Java. Danach stellte er Spring OSGi im Detail vor, das einem die Arbeit mit OSGi etwas erleichtert und die Anwendung völlig unabhängig von OSGi APIs zu prgrammieren. Das Deklarieren von Services, die für andere Bundles sichtbar sein sollen geschieht hierbei wie gewohnt mit einem Spring Namespace.

Als nächstes stellte Eberhard Spring Integration vor, das hilfreiche Unterstützung für EAI Projekte bietet. Er ging auf Kernabstraktionen ein und stellte verschiedene Konfigurationsmechanismen (Plain Java, XML mit Beans, XML mit Namespaces, Annotationen) vor. Interessant dabei war für mich insbesondere, dass Spring Subprojekte alle auf dem gleichen grundsätzlichen Programmiermodell aufsetzen: grundsätzliche Abstraktionen über Interfaces, diverse Basisimplemenierungen für einfache Fälle und die Konfigurationsmöglichkeiten, die ich oben bereits erwähnt hatte.

Als letztes bekamen wir erste Eindrücke in SpringSource Tools. Die Spring Application Managements Suite erlaubt das monitoring von Springanwendungen und liefert Informationen zum ApplicationContext, TransactionManagers usw. Die Spring ToolSuite selbst ist eine auf Eclipse basierende IDE, die zum einen aus der SpringIDE bekannte Unterstützung für Springanwendungen bietet. Darüber hinaus besteht eine verstärkte Integration von Mylyn (das jedoch auch in der reinen Eclipse IDE integriert ist). Die Suite wird darüber hinaus mit Tutorials und weiteren Hilfen und Demos angereichert.

Spring Release Party

2008-03-03T08:36:11+01:00

Gleich gehts auf nach Stuttgart zur Spring Release Party. Diesmal findet die Party nach dem Release von Spring 2.5 vor etwa 4 Monaten. Bei der letzten Party war man ja etwa 6 Monate zu früh ;). Der Event scheint sich zu einem festen Termin bei Spring Releases zu etablieren.

Neue Four Sided Cube Platte am 8.2.2008

2008-02-01T22:03:05+01:00

Was lange währt wird endlich gut. Nächsten Freitag kommt unsere neue LP. Viel Arbeit steckt in dem kleinen Silberling aber auch jede Menge Spass, Leidenschaft und eine verdammt coole Zeit.

Ordern könnt ihr die Platte über die Webseite. Im Rhein-Neckar Raum werden wohl auch die Großhandelsketten versorgt.

Googles Android

2007-11-14T12:04:43+01:00

Vor ein paar Tagen hat Google ein SDK für sein Handybetriebssystem Android veröffentlicht. Gerade eben hatte ich ein wenig Zeit mal damit rumzuzspielen. Der erste Eindruck ist echt klasse…

Ich hatte bereits in ein paar Projekten mit J2ME Erfahrung machen müssen und dabei festgestellt das Handyentwicklung eher Handygefrickel ist. Das Entwickeln auf Basis einer abgespekten JavaSE ist mühsam und zieht eine Reihe zum Teil sehr hässlicher Workarounds nach sich.

Android basiert auf Dalvik, einer virtuellen Maschine, die der Java VM von Sun sehr ähnlich ist. Aus lizenzrechtlichen Gründen meidet Google jedoch das Erwähnen von “Kompatibilität zu Java”. Der Clou an der Sache ist, dass Entwickler trotzdem Javacode schreiben und der vom Javacompiler generierte Bytecode einfach durch einen zweiten Compileschritt auf Darwin lauffähig gemacht wird. Das heißt im Klartext: einfach Java entwickeln (ja, auch Generics, Java 5 For Schleifen usw.) - den rest erledigt das Android SDK oder für diejenigen, die es ganz elegant mögen das Eclipseplugin.

Wer mag kann sich ja mal das Tutorial anschauen. Es liefert einen guten Ãœberblick über die Technologie und das Arbeiten mit dem SDK.

13949712720901ForOSX

2007-11-05T13:43:44+01:00

“Hö, wie bitte?”, dachte ich, als ich diese Zeichenkette im Blog eines Bekannten las. Hintergrund ist folgender: Auf dem aktuellen Apple Betriebssystem “Leopard” gibt es noch keine Java 6. Was für den Ottonormal MacUser (gibt es die überhaupt ? ;) kein großes Problem darstellt, ist für Entwickler relativ problematisch. Die Zeichenkette oben ist nun eine Art Web 2.0 Unterschriftensammlung, Apple dazu zu bewegen recht zeitnah ein Java 6 für Leopard bereitzustellen. Hier also meine Unterschrift…

Four Sided Cube mit neuer Hompage

2007-10-13T18:00:54+02:00

Wie ihr hier sehen könnt haben Four Sided Cube eine neue Webseite. Darauf zu finden ist unter anderem das Recordingtagebuch zum 4. Album, was noch dieses Jahr erscheinen wird. Ich werde da wohl so alle 2 Tage Stories und nette Anekdoten des Recordinggeschehens festhalten. Schaut vorbei…

Domainumzug

2007-09-27T15:56:22+02:00

Wie ihr vielleicht bemerkt habt, läuft die Seite jetzt unter www.olivergierke.de. Der Grund ist ein sehr simpler - ich werde morgen heiraten und den Namen meiner Frau annehmen. Ansonsten habe ich mich endlich mal bequemt, eine aktuelle Worpressversion einzuspielen. ;) Muss los, es gibt noch viel zu tun…

Neues von Four Sided Cube

2007-08-12T13:31:05+02:00

Wie ihr bestimmt schon oben bei den Fotos gesehen habt, gibt es endlich aktuelle Bandfotos von Four Sided Cube. Wir hatten an einem wettertechnisch durchwachsenen Tag viel Spaß am Neckarsteg in Ladenburg. Weitere Arbeiten des Fotografen Jan findet ihr bei Flickr.

Die neuen Bilder sind quasi Startschuss für einen neuen Abschnitt FSC. Wir spielen am 9.9. als Headliner beim Ladenburger Altstadtfest, werden dort schon ein paar neue Songs präsentieren und wahrscheinlich bis dahin auch eine überarbeitete Webseite haben. Danach gehts ins Studio um die Arbeit der letzten Monate festzuhalten. Wenn alles klappt gibt es dann zum diesjährigen FESTival eine neue FSC Scheibe.

Dixie Chicks - Shut up and sing

2007-08-12T13:24:58+02:00

Ein spontaner Kinobesuch gestern Abend führte mich in den Film “Dixie Chicks - Shut up and sing”. Es ist die Geschichte der erfolgreichsten Frauenband weltweit, der Dixie Chicks. Leadsängerin Natalie Maines äußerte am 10. März 2003 bei einem Konzert in London während einer Ansage folgenden Satz:

**"Just so you know, weâ€™re on the good side with yâ€™all. We do not want this war, this violence, and weâ€™re ashamed that the President of the United States is from Texas." - **Natalie Maines

Darauf folgte eine hexenjagdähnliche Hetzkampagne in ganz Amerika. CDs wurden vernichtet, die Countryradiosender boykottierten die Band komplett, es kam sogar zu Morddrohungen gegenüber Natalie.

Der Film schildert eindrucksvoll die faschistoide Meinungsmache der amerikanischen Gesellschaft, wie die Band damit umgeht, sich nicht mundtot machen lässt und die Geschehnisse in ihrem 2006 erschienenen Album “Taking the long way” verarbeitet. Höhepunkt der Platte ist wohl der Song “Not ready to make nice”, der die Geschehnisse emotional dokumentiert und mit 2 Grammys ausgezeichnet wurde.

Der Film läuft aktuell in deutschen Kinos, das Video sowie die Liveperformance bei den Grammyawards (äußerst sehenswert) habe ich unten verlinkt.

[Webseite zum Film](http://www.shutupandsing.de/)
["Not ready to make nice" Musikvideo @ YouTube](http://www.youtube.com/watch?v=fwc5YSAc-7g)
["Not ready to make nice" Live performance bei den Grammy Awards @ YouTube](http://www.youtube.com/watch?v=o-lJu5ibAM8)

Drum Clinic mit Ralf Gustke, Wolfgang Haffner und Felix Lehmann im Rock Shop Karlsruhe

2007-04-28T20:17:57+02:00

Grad eben bin ich zurück von einem Drumworkshop mit den 3 oben genannten Herren. Gute 2 Stunden deilkates Drumming gabs im Rockshop Karlsruhe auf die Ohren. Ausserdem diese oder jene kleine Anekdote.Als erstes betrat Felix Lehrmann die Bühne und spielte zu Rivo Drei Playbacks, die mit schon sehr bekannt waren, dem großen Restlichen Publikum allerdings schon das staunen ins Gesicht zauberten. Ja, der ist erst 22 ;).

Nach ihm kam Wolfgang Haffner auf die Bühne, der wohl so eine Art Kopf der Truppe war. Zumindest erzählte er von einer sehr entspannten Workshopwoche. Die Clinic in Karlsruhe war wohl die letzte der Tour und alle 3 schienen das Ende arg zu bedauern. Lustig waren 2 Anekdoten die er erzählte: das neue Jazzride, was er mit der Firma Meinl zusammen entworfen hat, trägt wohl den Namen “Jazz Club Ride” aufgrund seiner großen liebe zum Nürnberger Fußballverein. Da seine Yamaha Signature Snare auch wegen dieser Liebe in rot schwarz gehalten ist, lässt den Eindruck aufkommen er plane ein komplettes Drumset für den Verein - vielleicht sollte er mal nach einer Finanzspritze fragen ;).

Die zweite lustige Sache, die mir in Erinnerung geblieben ist war ein Kommentar zu den Musikern einer Band in der er trommelt. Die seien alle noch ganz jung, touren wohl mit Madonna und werden “mit Sicherheit nochmal weltberühmt”. Nunja ^^.

Was mich bei Ralfs Performance erwartet konnte ich mir ungefähr denken, da ich seine “World of Groove” DVD im Schrank hab. Ich mag seine Art zu spielen sehr, obwohl er mir heute vieles zuviel zugespielt hat. Gerade im Abschlussteil, in dem die 3 zusammen trommelten, war er doch eindeutig der dominierende Part. Aber hey, er bekommt sicher sonst nicht so oft die Gelegenheit, Soli vor Publikum zu zocken.

Alles in allem ein entspannter Nachmittag, auch wenn es nach einer Stunde arg heiß war im Foyer. Auf der Suche nach einer neuen Hihat hat mich Ralfs “Meinl 13” Fast HiHat” sehr angesprochen. Sehr chrisper sound, werd ich auf jeden Fall mal anspielen…

AOP Logging ist kein Logging - oder wie IT Fachzeitschriften erheblich nachlassen...

2007-04-03T13:27:51+02:00

Als ich mir vor ein paar Tagen die aktuelle JavaSpektrum zugelegt habe, sah der Inhalt ganz vielversprechend aus. Modelbasierte Entwicklung (hieß es bisher nicht immer modellgetriebene Entwicklung?), neues von AspectJ - die Themenliste klang gut. Nachdem ich dann allerdings den zweiten Artikel las, der mit der versprochenen Ãœberschrift relativ wenig zu tun hatte, kam schon eine Art Misstimmung auf. Ein Artikel, der angeblich die Arbeit mit den Eclipse WST dokumentieren sollte, entpuppte sich als kurzer Abriss über Spring, Axis und das Java Caching System. Für das WST blieben dann noch ein paar kurze Zeilen, die allerdings nicht mehr Information beinhalteten als die gemeinhin bekannten Eclipse Tutorials. Dann stieß ich (mal wieder) auf einen Fehler, der meiner Meinung nach penetrant übersehen wird…

Der Artikel über AspectJ ging natürlich auf die Grundlagen aspektorientierter Programmierung ein. Als Anwendungsbeispiel für AOP fällt in jedem Artikel eigentlich das Thema Logging. Was dabei immer verschwiegen wird ist, das mit “Logging mit AOP” nichts anderes gemeint ist als Tracing mit AOP. Das Pointcutmodell von AOP Implementierungen wie AspectJ oder Spring AOP bezieht sich sinnvollerweise auf Methodenaufrufe.

Praktisch bedeutet das, das man mit AOP die Möglichkeit hat Methodenaufrufe abzufangen und Code vor der Ausführung der Methode, nach der Ausführung und im Falle einer Exception auszuführen. Und da liegt auch schon der Hase im Pfeffer begraben. Ich weiß nicht, wie es euch geht, aber in meinem Quellcode stehen Logausgaben nicht nur am Anfang oder Ende einer Methode bzw. im Catchblock. Detaillierteres Logging für den Debugmodus (z.B. in verschiedenen If-Zweigen) ist schlichtweg nicht mit AOP möglich.

Warum diesen Fakt niemand bei seinen Artikeln im Netz oder in Fachzeitschriften klarstellt, bleibt mir schleierhaft. AOP Anfänger (zu denen ich mich auch noch zähle) verwirrt das ganze doch ein wenig…

Recordingworkshop an der Popakademie

2007-01-21T21:59:35+01:00

Am vergangenen Wochenende fand wieder ein Seminarwochenende an der Popakademie statt. Ich hatte mich für den Aufbauworkshop “Recording” angemeldet und freute mich auf ein spannendes Wochenende im Studio. Dozent war Marcus Thiel, freier Mitarbeiter an der Popakademie, Toningeneur und Produzent.Der Samstag begann gemütlich mit einer Vorstellungsrunde und Tasse Kaffee. Danach stellte Marcus nochmal verschiedene Mikrofontypen vor, erläuterte Einsatzbereiche und Preissegmente. Nach dem Essen probierten wir die einzelnen Mikros dann praktisch aus um preisliche sowie bauartbedingte Unterschiede zu erhören. Zum Ende hin besprachen wir kurz Grundlagen von Dynamikprozessoren und Effekten, ehe wir diese an dem “Mannheim Song” von Chris Cosmo wiederum praktisch erhören konnten. Der Song lag ungemischt im Logic und wir konnten die verschiedenen Mittelchen und Wege mal an sauber recordeten Spuren ausprobieren. Insgesamt bot der erste Teil für mich nicht wahnsinnig viel neues, hier und da konnte ich mir jedoch einen Trick abschauen.

Der Sonntag begann ähnlich gemütlich wie der Samstag. Wir probierten verschiedene Mirkofonierungsarten an einer Bassdrum und Snaredrum. Auch hier gab es wieder kleine aber feine Aha Effekte. Spannender für mich wurde es dann als wir eigene Produktionen vorspielten und diskutierten. Hier gab es trotz des technisch hohen Levels gute Anregungen.

Alles in allem ein angenehmes Wochende, dass mir sicherlich nicht vollkommen neues aufgezeigt hat. Allerdings ist es schon nett zu wissen, dass man mit seinem eingeschlagenen Weg, seinen selbst angeeigneten Techniken und Methodiken richtig liegt und insgesamt ein technisch und musikalisch hohes Level fährt.

[Popakademie](http://www.popakademie.de)

Joy Denalane zum Thema "Artist Development" @ Popakademie

2007-01-17T12:32:56+01:00

Gestern war Joy zu Gast in der OpenHouse Reihe der Popakademie. Dort referieren bekannte Größen aus der Musikwelt über bestimmte Themen, ihre Ansichten, Eigenheiten und Erfahrungen. Leider fand die Veranstaltung nicht wie aus anderen OpenHouse Seminaren gewohnt um 19 Uhr statt sondern schon um 18 Uhr. So stand ich also fünf vor sieben vor einer verschlossenen Tür. Arrrgh…Da ab und zu allerdings jemand aus dem Foyer kam, konnte ich wenigstens noch der Diskussionsrunde folgen. Das Thema drehte sich natürlich im groben um Joys Entscheidung auf dem aktuellen Album englisch zu singen, was für sie eine Entscheidung persönliche Entscheidung war. An den kommerziellen Erfolg ihres Erstlingswerks “Mamani” konnte “Born and raised” dadurch auch trotz eines für Soulalben verhältnismäßige hohen Charteinstieges nicht anknüpfen. Dass Joy und Four Music Labelchef Fitz Braum, der ebenfalls anwesend war, dies als okay ansahen macht durchaus einmal mehr die Sonderstellung eines Labels wie Four Music deutlich. Auch in (musik)wirtschaftlich schwierigen Zeiten, setzt das Label auf Kontinuität und artist development, womit wir den Kreis zum Vortragsthema wieder geschlossen hätten ;).

Insgesamt immer wieder nett, mal Meinungen, Erfahrungen und kleine Anekdoten aus “dem Inneren” der Musikbranche zu hören zu bekommen. Joy ist nächste Woche Donnerstag anlässlich des Mannheimer Stadtjubiläums zu Gast in der Alten Feuerwache in Mannheim.

[www.joydenalane.de](http://www.joydenalane.de)

Vortrag - Komponentenbasierte Softwareentwicklung mit PHP

2007-01-12T13:43:37+01:00

Gestern habe ich bei der PHP User Group Frankfurt einen Vortrag zum Thema “Komponentenbasierte Softwareentwicklung mit PHP” gehalten. Dabei habe ich das Dependency Injection Framework Garden vorgestellt und anhand eines Beispieldesigns unsere Weiterentwicklung des Frameworks und die generelle Arbeit mit Dependency Injection gezeigt. Die Vortragsfolien, sowie die Sourcen von Garden findet ihr auf der Webseite der PHPUG.

[PHP User Group Frankfurt](http://www.phpugffm.de)
[Komponentenbasierte Softwareentwicklung mit PHP](http://www.olivergierke.de/wordpress/wp-content/uploads/2007/01/oliver-schlicht-komponentenbasierte-softwareentwicklung-mit-php.pdf)
[Blogeintrag zum Thema](http://phpugffm.de/index.php/archives/126)
[Garden](http://garden.tigris.org)

FESTival 2006 - neues von Four Sided Cube?

2006-12-01T18:02:01+01:00

Am 23.12.2006 findet das alljährliche FESTival als Benefizveranstaltung für das Jugendzentrum Kiste in selbigem in Ladenburg. Diese Jahr sind neben Four Sided Cube die Bands Cages und OIDO mit von der Partie. Ich freu mich auf einen gemütlichen Gig am Tag vor Weihnachten.

In Vorbereitung des Events arbeiten wir bereits seit etlichen Wochen an neuen Songs und werden wohl auch einige davon beim FESTival spielen. Es sind viele interessante Sachen dabei, vielleicht auch die ein oder andere Ãœberraschung ;)

[Webseite zum FESTival](http://festival.foursidedcube.de)

Mein Weg zu Spring

2006-10-21T23:09:08+02:00

Mein erster Blogpost zum Thema Informatik. Während meines Studiums hat sich mein Interesse vor allem im Bereich Serveranwendungen mit Java entwickelt. Zum ersten kam ich damit während des Programmiermethodikpraktikums im Sommersemester ‘05. Wir entwickelten eine Art Studenten- bzw. Tutoriumsverwaltung auf der Basis der EJB 2.1 und JBoss. Der technische Overhead den die Technolgie mit sich brachte erschlug meine Arbeitsgruppe und mich schon ziemlich. Da musste es etwas besseres geben…Auf der Suche nach Alternativen lief mit das Buch “J2EE Development without EJB” von Rod Johnson über den Weg. Zum damaligen Zeitpunkt schon 1 Jahr alt, brachte das Buch eine Alternative zum EJB Stack als Democode mit sich. Was ich damals noch nicht wusste - dieses Stück Code hatte sich bereits zu einem Open Source Framework entwickelt: Spring.

Auch wenn der Buchtitel nach polemischer Abrechnung klingt - er fasst eigentlich nur eine nüchterne Analyse des damaligen Standes der Technik zusammen. Der EJB2.1 Standard zog von der ersten Codezeile an einen riesigen Overhead nach sich und verlangte umständliches Implementieren einer Vielzahl von Interfaces, egal ob man überhaupt Features wie die physische Verteilung von Objekten auf verschiedenen Servern wirklich Nutzen wollte. Desweiteren musste man die Kommunikation zwischen Komponenten von Hand programmieren und verbrachte dadurch mehr Zeit damit, Infrastruktur zu programmieren, als Businesscode zu schreiben.

Spring setzt dem einen komplett anderen Ansatz entgegen. Basierend auf Martin Fowlers Idee der Dependency Inversion / - Injection, übernimmt bei Spring ein Container die Instantiierung der Komponenten und “injiziert” ihnen abhängige Komponenten. Ein weiterer Vorteil ist, das die Komponenten selbst reine POJOs sind und nichts von ihrer Umgebung bzw. Spring wissen. Sie werden dadurch leichter testbar und in unterschiedlichen Infrastrukturen einsetzbar (Tomcat, JBoss, im RichClient etc.).

Bei der Suche nach einer Basistechnologie für meine Bachelorarbeit fiel mein erster Gedanke sofort auf Spring. Die “neue” Art zu programmieren (DI-basiert) erfordert schon ein wenig Eingewöhnungszeit. Hat man das Prinzip jedoch, einmal verinnerlicht möchte man gar nicht mehr ohne ;). Hinzu kommt, dass Spring neben der BeanFactory (dem DI-Container) noch mit einer Reihe von dünnen Abstraktionslayern über viele weit verbreitete APIs und Technologien daher kommt und somit für viele Implementierungsfrage bereits eine Unterstützung bietet. In vielen Fällen reichen bereits 10 Zeilen Konfigurationscode und Spring erledigt den Rest. Um einen Webservice anzusprechen ist zum Beispiel nur ein WSDL Dokument und ein Interface nötig. Der Client arbeitet gegen das Interface, der Stub wird zur Konfigurationszeit von Spring generiert und dem Client per DI injiziert.

Mit EJB 3.0 sei vieles einfacher geworden, argumentiert die EJB Gemeinde. Manche gehen sogar soweit zu meinen, Spring werde dadurch überflüssig. Was dabei oft vergessen wird, das EJB 3.0 eigentlich nur die technischen Gegebenheiten von Spring bzw. Hibernate vom Stand von Ende 2005 übernimmt und dabei sogar auf halber Strecke stehen bleibt. Es gibt zum Beispiel keine Konstruktorinjection, das Konfigurieren von Komponenten mittels Annotations macht sie wieder von der Infrastruktur abhängig. Desweiteren ist die DI auf EJB Komponenten beschränkt - in Spring kann man jedes POJO per DI verarbeiten. Auch das Konfigurieren von AOP ähnlichen Interceptoren per Annotations führt die Idee von AOP eigentlich ad absurdum - Aspekte will ich zentral verwalten und nicht wieder über sämtliche Komponenten im Code verteilen.

Verglichen mit EJB 2.1 ist EJB 3.0 sicher ein Fortschritt. Doch EJB 2.1 war Ende der 90er. Verglichen mit aktuellen Technologien ist der EJB 3.0 Standard eigentlich schon wieder überholt, was vor allem an langen Releasezyklen bei Standardspezifikationen liegt. OpenSource Software, die von einer lebendigen Community lebt hat da die Nase schon vorn. Spring 2.0 ist vor kurzem entschieden und bringt viele Schritte nach vorn mit sich. Eine AspectJ Integration, erste Schritte in Richtung OSGi sowie zahlreiche kleine Verbesserungen hier und da.

Für mich ist Spring eine flexible Variante Serveranwendungen mit Java zu bauen, da es einem Anbietet genau das zu benutzen, was man benötigt, kaum Einfluss auf den Code nimmt und an sich ein recht sauberes Design forciert.

[Springwebsite](http://www.springframework.org)
[Springbuch](http://www.amazon.de/Spring-Frameworks-f%fcr-die-Java-Entwicklung/dp/3898643654/sr=8-1/qid=1161463255/ref=pd_bbs_sr_1/028-5102242-3789349?ie=UTF8) von Eberhard Wolff
[What's new in Spring 2.0](http://static.springframework.org/spring/docs/2.0.x/reference/new-in-2.html)

Wallis Bird

2006-10-15T16:24:10+02:00

Zum ersten Mal gehört hatte ich von Wallis Bird über Christian Vinne, einen Schlagzeuger von der Popakademie Mannheim, den ich über ein paar Ecken kenne. Er hätte da ein paar Gigs mit so einer irischen Sängerin gespielt. Ahja, okay… Als Rainer, Sänger meiner Band “Four Sided Cube” und ebenfalls Popakademiestudent von Wallis erzählte und sie unheimlich spannend fand musste ich mir die Sache natürlich näher ansehen. Myspace gecheckt, ihre Webseite besucht - ja, das klingt nett.

Als Wallis dann letztens hier in der Feuerwache spielte, lies ich mir natürlich nicht die Chance nehmen, mir das mal live anzusehen. Es war ein denkwürdiges Konzert - nicht nur für mich, sondern wohl auch für die Band. Es ging technisch eigentlich alles schief, was schief gehen kann. Dennoch blieben die drei - Wallis (Gitarre & Gesang), Christian (Drums & Vocal entertainment ;) und sein Bruder Michael (Bass) locker. Wallis hatte das Publikum eigentlich von Anfang an auf ihrer Seite. Unheimlich sympathisch, chaotisch und durchgeknallt im positiven Sinne - das hat Unterhaltungswert. Doch was bei manchen in nur übertriebener Selbstdarstellung endet, kanalisiert sie in Songs die so unheimlich vor Emotion strotzen, Spass machen und dabei musikalisch auf einem unglaublich hohen Niveau sind.

Aus musikalischer Sicht gefällt mir besonders, wie die drei mit ungeraden Taktarten spielen und diese aber Publikumsgerecht verpacken. Desweiteren ist es schon erstaunlich wie man mit einer sehr rudimentären Besetzung (Drums, Bass, Akustikgitarre) so vielfältige Songs produzieren kann - keine Song klingt wie der andere. Der rote Faden ist allerdings Wallis’ Stimme. Mir fallen eigentlich bei jedem Song andere Parallelen ein und doch ist da etwas sehr eigenständiges. Am besten ihr hört euch das mal selbst an… Wallis’ aktuelle EP heißt “Branches Untangle” und ist auf ihrer Webseite für nur 7,50â‚¬ käuflich zu erwerben. Pflichtkauf!

[Wallis Bird Homepage](http://www.wallisbird.de)
[Wallis Bird @ Myspace](http://www.myspace.com/wallisbird)

Neues Template

2006-10-15T16:08:22+02:00

Nachdem ich mit WordPress relativ zufrieden bin, lies mir das dunkle Template keine Ruhe. Deshalb hier was frischeres. Den Header werde ich sicher nochmal austauschen. Desweiteren habe ich mich entschlossen, den Blog um Posts über Gedanken zu meiner Arbeit im IT Bereich auszuweiten. Ausserdem habe ich eine Kategorie für Musiktipps eingerichtet, da mir in letzter Zeit jede Menge Künstler begegnet sind, die es verdient haben gefeatured zu werden.

Viel Spass damit…

Barfuss in Bildern

2006-10-01T19:08:54+02:00

Gestern früh fand das Fotoshooting für die Barfuss Platte statt. Ich hatte Nico Becherer, einen befreundeten Musiker und Fotografen, gebeten die Fotos zu schießen und da sich das gute Wetter wahrscheinlich bald dem Ende zu neigt, hatten wir diesen Samstag als Termin unserer Wahl auserkoren. Der Wetterbericht hatte allerdings Regen angesagt.

Nachdem es also zunächst eher düster aussah und ich schon Angst hatte, die ganze Aktion könnte ins Wasser fallen, kam so gegen 10 Uhr doch glatt die Sonne raus ;). Ich hatte passend zum Namen Motive wie Fußabdrücke im Sand, nasse Fußabdrücke auf einem Holzsteg, Füße im Gras usw. im Kopf. Nico hat mir gestern Nacht noch die ersten Ergebnisse geschickt und ich muss sagen, meine Erwartungen wurden übertroffen. Einen kleinen Eindruck von den Bildern könnt ihr in Nico’s Gallerie in der Fotocommunity bekommen. Ich setz mich dann mal an die Coverentwürfe ;)

Bilder vom Gig bei Rock @ Church

2006-09-12T20:49:54+02:00

Kurzes Update… ich habe ein paar Bilder vom Gig am Samstag rausgekramt und die zu ein paar anderen Photos von einem vorherigen Gig bei meinem Myspace Account hochgeladen. Glücklicherweise kann man die Slideshow auch recht leicht in Webseiten einbinden ;) Et voila.

Die Bilder stammen von einer sehr nette Photografin namens Jutta Leiske (www.fokus-eventphotos.de), die regelmäßig uns und andere Bands fotografiert und es dabei eindrucksvoll versteht Konzertatmosphäre einzufangen und festzu halten. Besucht einfach mal die Seite - es lohnt sich.

Hallo mal wieder...

2006-09-02T12:29:50+02:00

Es ist schon wieder 3 Monate her seit dem letzten Update. Wie ihr seht, hab ich das CMS gewechselt. Wollte was einfaches, sportliches. Bisher gefällt mir Wordpress sehr gut ;) Es sind noch nicht alle Contents im neuen System aber ich geb mir mühe, das so schnell wie möglich nachzuholen. Hier kurz die nettesten neuen Features:

links findet ihr immer die aktuellsten Dates, wie sie auch auf der Soulism Seite zu finden sind
unter "Zuletzt im Player" (ebenfalls links) findet ihr Songs, die ich grad so hör... klick drauf führ euch zum jeweiligen Künstler auf www.last.fm. Vielleicht schaut ihr euch den ein oder anderen ja mal an

Momentan find ich eigentlich wenig Zeit für musikalisches, da sich mein Studium dem Ende zuneigt und eine Abschlussarbeit aufwändiger ist, als ich gedacht hatte ;). Deshalb liegt Barfuss momentan kurz vor der Ziellinie auf Eis. Ich hoff, dass ich das Projekt Ende September zuende bringen kann. Mit Four Sided Cube spiel ich heute Abend beim Nachtlabyrinth am Hegehof in Ladenburg. Nächste Woche gibts ein FSC-Allstars Konzert beim Rock @ Church in Ladenburg.

Ãœber die Soulism Plattform hat sich eine Menge getan in den letzten Tagen. Wir haben zwei neue Künstler (Alibi und Profound) die auch gleich auf dem Sampler der “Bandits” (Dresdner Graffiticrew) ordentlich für Furore sorgen. Mit auf dem Sampler sind unter anderem auch Kool Savas und Spax, für den Profound das Instrumental produziert hat. www.bandits-dresden.de

Desweiteren ist seit kurzem ein der 44-Sampler erhältlich, der erstmals alle Dresdner HipHops vereint und geschlossen präsentiert. Weiter Infos findet ihr unter www.fortyfour.biz

Soweit erstmal… REINHAUN!

Es tut sich was

2006-05-01T20:06:28+02:00

Sorry, dass seit dem letzten Update so viel Zeit ins Land gegangen ist, aber mein Studium neigt sich dem Ende zu (und eine Abschlussarbeit schreibt sich nicht von allein ;) und auch musikalisch hat sich einiges getan.

Da das Label Einsdreizehn in seiner alten Form nicht mehr zu betreiben war (vor allem aus zeitlichen Gründen), entschied ich mich, zusammen mit Fridl Schreiter ein neues Baby aus der Taufe zu heben. Soulism - so der Name - soll nun einen etwas anderen Ansatz fahren. Weg von dem “Ein Label hat Künstler, die haben Platten usw” hin zu eine Plattform für erdige Musik mit Seele, die allen offen steht, die sich in gewissen Grundeinstellungen von Soulism wiederfinden. Aufgeteil ist das ganze in die Bereiche Music und Management, wobei ich primär den Music Bereich übernehme und Fridl das Management. Schon in den ersten zwei Monaten haben sich Interessante Connections und Projekte ergeben. Mehr dazu findet ihr allerdings auf der Seite direkt… viel Spass damit und drückt uns die Daumen, dass wir viel bewegen können.

Seit dem Aus von “Barfuss” war ich auf der Suche nach einer neuen Sängerin für das Projekt. Viele Bewerberinnen kamen, gingen… darunter auch viele gute, vor allem Martina Gebelein aus Bayreuth (Gruß ;). Letzendlich haben wir uns allerdings doch wieder für Isabel Haist (die Barfusssängerin) entschieden. Wir werden also die vorhandenen Songs nochmal sauber recorden und dann gibt es in naher Zukunft auch mal hier was zu hören.

Nachdem ich nach dem “Barfuss” Projekt eine Weile auf Bandsuche war, bin ich seit Mitte März bei der Ladenburger Band “Four Sided Cube” als Drummer untergekommen. Die Jungs haben bereits 3 Studioalben veröffentlich und sind nach einigen Umbrüchen in der Band wieder unheimlich motiviert und hungrig auf neues. Wir stecken mitten in den Proben für die ersten Gigs und haben auch schon ein paar Ideen für neue Songs zusammen erarbeitet. Die Jungs sind auch unheimlich aktiv, was die Nachwuchsförderung und das Veranstalten angeht, wo sich sicherlich auch Synergieeffekte mit Soulism ergeben werden… Die ersten Livertermine findet ihr auf www.soulism.de

Es scheint ein spannender Sommer zu werden ;)

Quo vadis 2006?

2005-12-14T12:10:12+01:00

Hallo zusammen,

nach dem das Jahr 2005 sich dem Ende zu neigt, hier noch ein kleines Update, woran ich gerade so sitze und was 2006 bevorsteht. Zusammen mit Fridl (www.rkee.net) bin ich momentan dabei das “alte” Label Einsdreizehn umzustrukturieren. Das Kind wird dazu in “Soulism” umfirmiert. Vorwiegend aus beruflichen Gründen hatte ich kaum noch Zeit, mich um die Administrativen Arbeiten, die so ein Vorhaben mit sich bringt, zu kümmern. Deshalb übernimmt Fridl bei Soulism den Management Teil, die Abteilung Musik leite ich. Wir hoffen, das Projekt dadurch ein wenig schlanker zu bekommen und 2006 ein wenig produktiver als dieses Jahr arbeiten zu können.

Das Soulprojekt, dass ich momentan am laufen haben bzw. hatte erfährt fast ebenso einschneidende Umbrüche. Da Isa, unsere Sängerin, Nachwuchs erwartet und Jörg, ihr Mann und unser Bassist ( ;) ) beruflich auch stark eingespannt ist, haben die zwei sich entschieden uns zu verlassen. Was uns jedoch bleibt sind jede Menge Songideen, die auch teilweise schon recordet sind. Momentan bin ich zusammen mit unserer Keyboarderin auf Musikercasting ;) (in 30min kommen die ersten zum Vorspielen, morgen kommen auch nochmal 3) und hoffen, das Projekt am laufen zu halten. Sollten alle Stricke reißen, basteln Fridl und ich im stillen Kämmerlein weiter an dem Material ;) … 2006 wird Soulism Jahr… so long

SPAX Projekt am Start / Bandtreffenupdate

2005-08-13T16:02:12+02:00

Seit letzten Montag ist das Ergebnis des “Allcityallstars” Projekts von SPAX auf dem Markt. Ich habe hierfür Friedel “RKee” Schreiter bei der Produktion des Titeltracks “Schattenkrieger” unterstützt. Leider gabs kurz vor Mixingschluss ein paar kleine Missverständnisse, so dass unser Streicherarrangement und das von Fridl gespielte Klavier beim Mix etwas stark in den Hintergrund geraten sind. Ein bissl ärgerlich, aber angesichts der über 20 vertretenen Acts und der enormen organisatorischen Arbeit nicht ganz so tragisch. Alles in allem eine angenehme Zusammenarbeit, dessen Ergebnis sich hören lassen kann.

Mehr Informationen findet ihr unter www.allcityallstars.de, zu kaufen gibts die Scheibe im Shop von www.mzee.com

Das Bandtreffenprojekt hat jetzt den Namen “Die üblichen Verdächtigen” bekommen und entwickelt sich prima ;-) Wir werden 2 Sängerinnen und einen Rapper dabei haben, haben bereits Songs ausgewählt und bereiten grad die Probewoche vor. Ich versorg euch demnächst mit weiterein Infos… ;-)

So long…

Clueso Remixcontestergebnisse / Neues Projekt

2005-07-09T14:23:57+02:00

Seit circa 1,5h sind die Ergebnisse des Contests online. Leider haben wir es nicht unter die Topplätze geschafft. Ein besuch von www.start-ab.com lohnt sich jedoch trotzdem - es gibt viele gute Remixe dort.

Zum diesjähigen Bandtreffen habe ich ein recht außergewöhnliches Projekt ins Leben gerufen. Ich werde mich mit 3 befreundeten Musikern (Martin Schneider, Alexander Lau, Friedemann Schreiter) eine Woche vor dem Event in meiner Heimatstadt Forst treffen. Wir werden dort unter dem Namen “Die üblichen Verdächtigen” 4 Tage mit Proben verbringen. Weiterhin mit von der Partie sind die Sängerinnen Raphaela Poltermann, Julia Schöning und der Rapper Dita Rantel. Wir haben vor mit den 3en ein 45 minütiges Programm auszuarbeiten, was dann am Freitag beim Bandreffen präsentiert wird.

Ich freu mich auf eine aufregende Woche und einen geilen Gig ;-)

Bis dann

Remixcontestsong online

2005-06-05T19:54:56+02:00

Da nun alle Remixe zum Contest online sind, hier auch nun mein Beitrag.

Clueso - Pizzaschachteln (113 Remix)

Der Vollständigkeit halber noch die Credits:

Thomas Hübner: Vocals Isabel Haist: Vocals Friedemann Schreiter: Piano Martin Schneider: Gitarre Oliver Schlicht: Drums/Bass/Gitarre/Klavier

Aufnahme, Produktion, Mischung, Mastering: Oliver Schlicht

Mal schauen was draus wird ;-)

Clueso Remix Contest dieses Wochenende

2005-06-04T19:51:14+02:00

Dieses wochenende findet über das Webportal www.start-ab.com ein Remixcontest zu der am Montag erscheinden Single “Pizzaschachteln” des Erfurter FourMusic Artists Clueso statt. Mitsamt den üblichen verdächtigen Martin Schneider (Gitarrensolo) und Friedeman Schreiter (Piano) und der Sängerin Isabel Haist habe ich ein nettes Stück musik zum Song von Clueso produziert. Abgabetermin ist Montag 6 Uhr. Sobald man die Sachen rausgeben darf findet ihr den Song hier auf der Seite…

stay Tuned…

Updates... was geht momentan?

2005-04-01T17:30:30+02:00

Hallo zusammen. Ich hab’s endlich geschafft, mal ein Photo (bzw. mehrere für ne Photomontage ;-) vom kompletten Set zu machen, da wir vor gut 3 Wochen in einen neuen Proberaum in Mannheim gezogen sind. Das Projekt, mit dem ich jetzt da Musik mach hat noch keinen offiziellen Namen - egal, die sind eh Schall und Rauch. Wir bewegen uns musikalisch zwischen Soul, Funk, HipHop, Pop und die ersten Songs klingen vielversprechend. Momentan suchen wir noch ein paar Mitmusiker, die die Sache komplett machen… ich halte euch auf dem Laufenden ;-)

In Sachen Raphaela gehts auch voran: der Martin schreibt seit kurzem fleißig eine art Albumtagebuch auf der Einsdreizehn-Seite (www.einsdreizehn.de) Reinschauen lohnt. Bei meinem Beusch in Forst, in der Woche vor Ostern hab ich wieder einige nette Songideen vom Martin mitgenommen. Das Kind gedeiht momentan recht prächtig…

Morgen kommt meine (ehemalige) Bandkollegin Goeschi zu mir ins Studio - wir recorden ein paar Songs und sammeln Material für zukünftige Releases.

Weiterhin arbeite ich mit RKEE (dem Pianisten aus der Liveband vom Dita Rantel - www.rkee.net) am Feinschliff eine EP für einen Rapper namens Deckah (www.deckah.de). Ich werde die Platte mischen und mastern. Die ersten Demo klingen extrem intressant. Wahrscheinlich werden auch noch ein paar weitere Musiker an dem Projekt teilnehmen.

Ein weiteres Projekt, an dem ich beteiligt bin geht in die heiße Phase. RKEE (siehe oben) hat für SPAX’ Allstars Projekt einen Beat produziert, an dem ich ein wenig mitproduziert hab. Sobald ein genaues Releasedate steht, bekommt ihr Infos ;-)

So, soweit erstmal… Bis zum nächsten mal.

So viel neues...

2005-02-13T14:12:24+01:00

Da sind es schon weider 6 Monate, die ich nun in Mannheim wohne. Ein halbes Jahr musikalische Um- und Neuorientierung. Die Rockband, in die ich hier im Oktober eingestiegen bin wagt sich am 26.02.2005 zum ersten mal aus dem Proberaum. “True Tempest” werden in Wallstadt ihr Bühnendebut feiern. Jedoch werde ich die Band aus musikalischen Gründen nach dem Gig wieder verlassen.

Das zweite Projekt, was momentan läuft ist noch jünger. Eine Funk- / Soulband mit dem Fokus auf eigenen Songs in Richtung Joss Stone, Erykah Badu. Gestern abend haben wir den ersten Song recorded - sehr vielversprechendes Material. Wir suchen noch nach weiteren Musikern, feilen an Songs und schauen wo es uns hintreibt ;-)

So, hier noch der Flyer für den Gig am 26. Vorbeikommen lohnt sich!!

Oliver Gierke

Jürgenized

Websites VS. APIs

For the GovData team the website is something different than the API

Whoops! Where did my architecture go

Divide and conquer

Layers

Slices

Architecture VS. Codebase

Packages

Summary

Hello World

Spring, logging and JMX

XML Hell? Go make it clear and nice!

Enabling Hibernate criteria query statistics with AspectJ

Conference autumn 2010

Hades 2.0.0.RC2 introduces transactional DAOs

Changing a project's artifactId in Sonar

Hades 1.5 released

Why 1.5?

Hades 2.0

Neglected classes in Spring - Part III

REST based web applications with Spring 3

New challenges

Neglected classes in Spring - Part II

Pagination

Accessing the current user

Summary

Article on Hades in current issue of German JavaMagazin

Diggin' into Spring 3 transactional test facilities

Using Spring's @Configurable in three easy steps

1. Equip your domain class with @Configurable

2. Enable injecting capabilities in your configuration file

3. Enable load-time weaving

Resources

Hades 0.5.0 released

Streamlining of the Spring namespace

OSGi ready

Programatic API

Miscellaneous

Roadmap

Links

Achieving application modularity with Hera

The concept of binding

Aligning object creation to the classpath configuration

Client side binding

Binding at runtime

Bringin the parts together

Summary

Unit testing annotation based Spring MVC controllers

Hera 0.4 released

Java Posse Roundup 2009 - Part I

Monday

Tuesday

Wednesday

Summing up the first days

Hades 0.4 released

Eclipse plugin

Automatic detection of JPA persistence provider

Links

Heading Java Posse Roundup 2009

Integrating Hades into existing applications

Clean Code - Review Part I

1. Separate constructing a system frum using it

2. Dependency Injection

3. Cross cutting concerns / AOP

4. Incremental design

5. Domain specific languages

Summary

The DAO is dead! Long live the DAO!

Separation of persistence logic and business logic

Tangled code / More sophisticated API

Exchange implementation

Don’t repeat the DAO!

Hades to help!

Links

Subtleties on java.lang.Enum

Hades at Java User Group Karlsruhe

JavaC issues implementing generics

Spring 3.0 M1 is out now for Maven users, too

1. Equip your domain class with `@Configurable`