Oliver Drotbohm2023-09-15T11:56:06+02:00http://www.odrotbohm.deOliver Drotbohminfo@odrotbohm.deConference Autumn2023-09-01T00:00:00+02:00http://www.odrotbohm.de/2023/09/conference-autumn
<p>I’m currently busy booking travel for quite a few conference and JUG appearances that have been in the pipeline for a while.
It’s gonna be a wild mix of <a href="https://devoxx.be/talk/?id=20287">Spring Modulith</a> talks and workshops, Domain-Driven Design, <a href="jmolecules.org">jMolecules</a> and a Spring get together with members of the core team.
Some of these events are commercial, but others are free to attend.
Be sure to sign up, I would love to see you!</p>
<ul>
<li>28.09. BedCon, Berlin — <a href="https://bed-con.org/2023/programm">Architecturally Evident Java Applications with jMolecules</a></li>
<li>28.09. BedCon, Berlin — <a href="https://bed-con.org/2023/programm">Spring for the Architecturally Curious Developer</a></li>
<li>02.10. Devoxx Belgium, Antwerp — <a href="https://devoxx.be/talk/?id=6753">Spring Modulith – A Deep Dive (3 hour workshop)</a></li>
<li>03.10. Devoxx Belgium, Antwerp — <a href="https://devoxx.be/talk/?id=20287">The Spring BOF</a></li>
<li>05.10. JUG Saarland, Saarbrücken — <a href="https://www.meetup.com/de-DE/java-user-group-saarland-jugsaar/events/296097005/">Spring for the Architecturally Curious Developer</a></li>
<li>07.10. Unkonf, Mannheim — All things jMolecules, Spring, Moduliths and Spring Modulith</li>
<li>19.10. VMware Tanzu Webinar — <a href="https://tanzu.vmware.com/content/webinars/oct-19-emea-spring-boot-3-and-beyond">Spring Boot 3 And Beyond (online)</a></li>
<li>24.10. Accento.dev, Karlsruhe — <a href="https://2023.accento.dev/talks/spring-modulith/">Spring for the Architecturally Curious Developer</a></li>
<li>25.10. Accento.dev, Karlsruhe — <a href="https://2023.accento.dev/trainings/domain-driven-design-java-spring/">Tactical DDD with Java & Spring (1 day workshop)</a></li>
<li>25.10. JUG Karlsruhe — <a href="https://jug-karlsruhe.de/content/architekturexplizite-java-applikationen-mit-jmolecules/">Architecturally Evident Java Applications with jMolecules</a></li>
<li>26.10. JUG Dortmund (tba) — Spring for the Architecturally Curious Developer</li>
</ul>
Sliced Onion Architecture2023-07-25T00:00:00+02:00http://www.odrotbohm.de/2023/07/sliced-onion-architecture
<p>It has been almost exactly 15 years since Jeffrey Palermo posted the first blog of his series on the <a href="https://jeffreypalermo.com/2008/07/the-onion-architecture-part-1/">Onion Architecture</a>.
In that post, he summarized ideas that essentially form a continuation of the <a href="https://alistair.cockburn.us/hexagonal-architecture/">Hexagonal Architecture</a> approach by Alistair Cockburn.
Although I have always thought that both of these approaches to code organization do not necessarily constitute “architectures”, I find them helpful in shaping a mental model about how to structure a code base.
Over the years, I have seen plenty of teams trying to follow those models and running into problems with them.
In this blog post, I would like to summarize a few of those findings and present a refined way of looking at Onion Architecture.</p>
<h1 id="onion-architecture">Onion Architecture</h1>
<p>Let us start with a brief revisit of the original ideas of the approach first.
Code is organized in concentric rings, with <em>the domain</em> at the center of it all.
That part of the code base is supposed to contain all fundamental domain abstractions.
That core is then surrounded by an <em>application</em> ring that — as the name suggests — contains application-specific code.
Jeffrey’s original proposal even divided that ring up into “domain services” and “application services” which usually sparks a lot of discussion within teams which code belongs where.
For now, I will stick to the simplified “application” ring.
Its purpose is to expose application logic in use cases or units of work to other code that form scopes of consistency.</p>
<p><img src="/assets/images/soa/onion-architecture-green.jpeg" alt="Onion Architecture (simplified)" /></p>
<div class="image-caption">Onion Architecture (simplified)</div>
<p>That ring in turn is surrounded by the <em>infrastructure</em> ring that contains code that translates the application-specific interfaces into a particular technology.
On the exposing side, this could be controllers rending a web page or producing representations suitable for a particular style of APIs, such as JSON.
Furthermore, connectors to databases or message brokers reside in that ring.
That way, Jeffrey abstracts away the different kinds of adapters (driving VS. driven) Alistair had introduced in Hexagonal architectures.</p>
<p>The final piece of the puzzle is the definition of dependency directions between the rings: outer rings depend on inner ones, exposing an interface for their dependents to either invoke (a controller working with an application service) or implement (a particular database implementation of a repository interface exposed by the application ring).
While the strict interpretation of the approach suggests that a ring may only depend on the next inner one, in practice, skipping a ring is usually allowed as enforcing the strict layering would result in boilerplate code.</p>
<h1 id="problems">Problems</h1>
<p>Now that we have come to a common understanding of the situation, let us take a look at the challenges with this approach.</p>
<p>A core problem with Onion Architecture — and Hexagonal Architecture as well — is that it treats <em>the domain</em> as a single, opaque block.
It is likely a testament to the time of origin of these architectures that they all extensively focus on the separation of domain code from infrastructure code.
Intermingling the two was the reason for significant code quality issues, especially in enterprises at that time, primarily due to the lack of ability to test code that does not separate these two aspects.</p>
<p>Still, the release of Eric Evans’ “Domain-Driven Design” in the early 2000s already pointed out — and it has become even more obvious in the last couple of years —: the primary source of quality issues within code bases is the lack of alignment with the business and the existence of a <em>functional</em> separation of concerns reflecting that.
This raises the question whether it is a good idea to follow an architectural approach to structuring your codebase that basically ignores your primary challenge.</p>
<p>A slightly more technical issue arises from the raise of abstraction compared to Hexagonal Architecture in the infrastructure ring.
Both the API / web and database / message broker adapters residing in that ring suggests some kind of uniformity to the way they are implemented.
This is often reflected in the approaches to decoupling from the target infrastructure by mapping different models onto each other.</p>
<p>On the database side, the domain model is supposed to be mapped onto a persistence model, which is in turn mapped to a database-specific structure.
This is of course a valid approach in a context in which the target data store is shared by different applications and the team developing one application is exposed to changes to that store.
A scenario pretty common in the mid-2000s.
Nowadays, applications usually own their data store, and we can choose drastically simpler approaches to persistence.
The need to map between different models is often out-prioritized by the desire to keep the model simple and have a model change to immediately reflected in the derived, other models.
For example, we want that renaming a property in an aggregate in the domain model is ideally immediately reflected in the database migration, also renaming the column name to avoid cognitive overload going forward.</p>
<p>On the exposing side of the infrastructure, this is an entirely different discussion, as we cannot arbitrarily change the target model.
It is likely that we don’t even know all our API consumers and would rather want to guard those from changes to our internals as much as possible.
Being able to differentiate between these two scenarios can help to avoid a lot of boilerplate code, especially in the design of the persistence implementation.
While, of course, nothing in Onion Architecture prevents us from making this distinction, putting all infrastructure into the same ring implies a uniformity that can be misleading.</p>
<p>Finally, to round the technical challenges off, assigning all infrastructure adapters to the same logical bucket exempts them from the constrained dependency directions defined between rings.
Repository implementations might depend on controllers without the architectural approach capturing that.</p>
<h1 id="structuring-the-domain">Structuring the Domain</h1>
<p>As I have described above, a fundamental challenge to building maintainable software systems is a functional architecture that supports the needs of the business we build the application for.
To keep things simple for now, let us use the term <em>domain</em> for these individual elements of that functional architecture.
If you followed Domain-Driven Design, that would map to a <em>Bounded Context</em> or a <em>Module</em> within those.
If we are supposed to deal with multiple domains, what would an Onion Architecture working with those look like, and what would that mean for the interaction between the domains?</p>
<p><img src="/assets/images/soa/onion-architecture-multiple-domains.jpeg" alt="Onion Architecture — Multiple Domains" /></p>
<div class="image-caption">Onion Architecture — Multiple Domains</div>
<p>One idea could be to apply the functional architecture solely to the domain core of our arrangement, as shown above.
We could apply Domain-Driven Design to our overall domain, identify different parts within it, and define allowed dependency directions between those.</p>
<p>While that is certainly better than before, all our application and infrastructure code still would be an opaque whole that lacks the structure which we have now established at the core of our architecture.
If we extend on that idea and repeat the structuring exercise for each other ring, we eventually end up with an Onion per domain.</p>
<p><img src="/assets/images/soa/onion-architecture-multiple.jpeg" alt="Onion Architecture — Onion Per Domain" /></p>
<div class="image-caption">Onion Architecture — Onion Per Domain</div>
<p>This is a step in the right direction.
Each Onion is self-contained and focused on <em>one</em> domain and owns their application interfaces and technical adapters.
However, the interaction of the individual domains would now have to be established through the infrastructure.
This might be a good fit if we decided to map the Onions onto individual applications, for example, in a microservices’ arrangement.</p>
<p>Depending on the level of granularity of the domains, this might not be the most optimal projection of our logical architecture into the “physical” world, it will also introduce a lot of complexity and cost in the interaction.
To exchange a simple domain event between the systems, we would have to have the corresponding infrastructure in place (a message broker, for example), have to serialize the event on the sender side and deserialize it on the receiver side.</p>
<p>Summarizing, the lack of focus on the domain in the original Onion Architecture clearly shows, and approaches to address the problem within the realms of the original idea are either unsatisfying or introduce complexity and incentivize a particular deployment arrangement.
Time to elevate this to a new level.</p>
<h1 id="the-sliced-onion-architecture">The Sliced Onion Architecture</h1>
<p>The fundamental augmentation I propose to Onion Architecture is to cut the sides of the Onion.
While this might sound trivial at first, the idea has significant consequences on the precision of the definition of the concepts and the applicability in actual applications.</p>
<p><img src="/assets/images/soa/soa.jpeg" alt="Sliced Onion Architecture" /></p>
<div class="image-caption">Sliced Onion Architecture</div>
<p>First, by cutting the sides, the conceptual separation between code mapping application concepts to external clients (via APIs) and the code mapping to internal infrastructure (such as databases and message brokers) is re-established.
We also implicitly establish the fact that each of these — by default — do not interact with each other at all.
The application ring still protects an individual domain.</p>
<p>That in turn can be exposed to infrastructure in line with the original idea, but is also opened up on its sides for low-friction interaction with similarly shaped parties (see below) and tests.
In the original Onion Architecture approach, they reside in the infrastructure layer, which I have always found a bit weird.
Definitely, they act as clients to the application ring.
However, the adapters in the infrastructure ring need integration testing “from the outside” as well, which would lead to yet another ring surrounding the infrastructure one and does not fit the overall idea very well.
With our refined approach, tests can connect to code from the side and align different kinds of testing depending on the part they primarily interact with.
They could focus on fine-grained tests directly interacting with the APIs exposed by the application ring, or rather resort to more holistic approaches through the infrastructure adapters.</p>
<p>Fundamentally, the Sliced Onion approach is still a suitable arrangement for a deployment as an individual system.
That said, the key benefit of the cut is that we can arrange multiple of these to interact with each other, also in other deployment arrangements.</p>
<p><img src="/assets/images/soa/soa-multiple.jpeg" alt="Sliced Onion Architecture — Multiple Sliced Onions" /></p>
<div class="image-caption">Sliced Onion Architecture — Multiple Sliced Onions</div>
<p>For example, we could place a set of Onions into a singular deployment unit, indicated by the light green box in the graphic above.
This looks pretty similar to our Onion-per-domain approach.
The core benefit of the exposed application ring sides is that we can leverage capabilities provided by the runtime environment to let the individual Sliced Onions interact with each other.
Either through the publication of process-internal events (the light bulbs in hexagons in the graphic below) or the invocation of APIs (the beans in circles).</p>
<p>In the context of a Spring application, for example, that would map onto using its application event mechanism or direct references to a Spring bean exposed by another Sliced Onion.
I usually recommend to favor asynchronous, event-based interaction between the Sliced Onions, as this naturally keeps the scopes of strong consistency within one Onion and thus emphasizes their self-contained nature.
Furthermore, not referring to Spring beans exposed by a foreign Onion allows tests to run scoped to only the Onion under test.</p>
<p><img src="/assets/images/soa/soa-interaction.jpeg" alt="Sliced Onion Architecture — Interaction Patterns" /></p>
<div class="image-caption">Sliced Onion Architecture — Interaction Patterns</div>
<h1 id="modules">Modules</h1>
<p>Once we discuss the interaction between individual Sliced Onions, we can lift the architectural abstraction to <em>modules</em>, as the module’s internal Onion structure does not actually matter anymore and becomes an implementation detail.
Modules expose events or APIs for internal interaction and infrastructure adapters connecting each module to the outside world.
They thus form self-contained elements within the overall application arrangement.
This is, in fact, the core of a <em>modulithic</em> application architecture.</p>
<p><img src="/assets/images/soa/soa-modules.jpeg" alt="Sliced Onion Architecture — Modules" /></p>
<div class="image-caption">Sliced Onion Architecture — Modules</div>
<p>Moduliths are a great starting point to evolve an application’s architecture as they have natural, low-cost seams built in, which are helpful in case we have to restructure the overall arrangement.
For one, we can move code between the individual modules with manageable effort, as internal interaction is not exposed to third parties.
Refactoring tools of our IDEs become powerful assistants.</p>
<p>Furthermore, those seams can be used to split up a system at a later stage if the actual organization or technical need arises.
Especially, modules solely interacting via (asynchronous) events can be lifted into another deployable by moving the code into a new project.
Events previously already published internally could be externalized into some messaging infrastructure, and the original application could integrate with the new arrangement by deploying the corresponding infrastructure adapters on the listening module.</p>
<p><img src="/assets/images/soa/soa-modules-split.jpeg" alt="Sliced Onion Architecture — Split Up" /></p>
<div class="image-caption">Sliced Onion Architecture — Split Up</div>
<p>That said, the fully modulithic arrangement we started from might just be enough to ensure evolvability of our system, and we might never actually get to a split up in the first place.</p>
<h1 id="summary">Summary</h1>
<p>The Sliced Onion Architecture augments the original approach’s idea by adding stronger focus to the domain and its functional structure.
Slicing the Onion vertically allows applying the idea to a broader set of deployment options, and forms a cornerstone of an evolvable architecture in the context of modulithic application arrangements.</p>
Moduliths 1.1 released2021-07-02T00:00:00+02:00http://www.odrotbohm.de/2021/07/moduliths-1.1-released
<p>I’d like to announce the availability of Moduliths 1.1 GA.
Moduliths is a toolkit to create modular, monolithic applications based on Spring Boot.
The release ships with significant improvements and new features:</p>
<ul>
<li>Module detection SPI - <a href="https://github.com/odrotbohm/moduliths/issues/137">#137</a></li>
<li>Improvements to Module Canvas
<ul>
<li>Custom component grouping - <a href="https://github.com/odrotbohm/moduliths/issues/130">#130</a></li>
<li>Event listeners report type they’re interested in - <a href="https://github.com/odrotbohm/moduliths/issues/132">#132</a></li>
<li>Origins of published events - <a href="https://github.com/odrotbohm/moduliths/issues/139">#139</a></li>
<li>Javadoc of event listeners included - <a href="https://github.com/odrotbohm/moduliths/issues/143">#143</a></li>
</ul>
</li>
<li>Spring <code class="language-plaintext highlighter-rouge">ApplicationListener</code> implementations detected as event listeners - <a href="https://github.com/odrotbohm/moduliths/issues/145">#145</a></li>
<li>Support for jMolecules - <a href="https://github.com/odrotbohm/moduliths/issues/127">#127</a>
<ul>
<li>Support for <code class="language-plaintext highlighter-rouge">@DomainEventHandler</code> - <a href="https://github.com/odrotbohm/moduliths/issues/159">#159</a></li>
<li>Support for jMolecules <code class="language-plaintext highlighter-rouge">Repository</code> interface - <a href="https://github.com/odrotbohm/moduliths/issues/163">#163</a></li>
</ul>
</li>
<li>Improved <code class="language-plaintext highlighter-rouge">PublishedEvents</code> API - <a href="https://github.com/odrotbohm/moduliths/issues/124">#124</a>, <a href="https://github.com/odrotbohm/moduliths/issues/125">#125</a>, <a href="https://github.com/odrotbohm/moduliths/issues/126">#126</a></li>
<li>Transactional event publication registry - <a href="https://github.com/odrotbohm/moduliths/issues/121">#121</a></li>
</ul>
<p>Let me walk you through the most significant additions in a bit more detail.</p>
<h2 id="transaction-event-publication-registry">Transaction event publication registry</h2>
<p>Probably the biggest feature of this release is the addition of an event publication registry for transactional events.
By default, Spring’s transactional event listeners are invoked after transaction commit, which means that a listener failing to execute properly will have lost the event and there’s no way to recover from that.</p>
<p>The registry added in Moduliths 1.1 will write a publication log for all events to be consumed by transactional event listeners.
It will write that log within the original business transaction.
The execution of the transactional event listeners is then decorated to mark the publications as completed if they successfully execute.
In case of a failure, the log entry will stay untouched and API is provided to access outstanding event publications for re-submission or escalation.
I’ve discussed the topic in the “A Deep Dive into Spring Application Events” talk <a href="https://speakerdeck.com/olivergierke/a-deep-dive-into-spring-application-events?slide=12">here</a> (recording <a href="https://www.youtube.com/watch?v=4oBqCtdRIYo">here</a>).</p>
<p>To get started with the registry, all you need to do is adding the Moduliths Events Starter POM to you project:</p>
<div class="language-xml highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nt"><dependency></span>
<span class="nt"><groupId></span>org.moduliths<span class="nt"></groupId></span>
<span class="nt"><artifactId></span>moduliths-events-starter<span class="nt"></artifactId></span>
<span class="nt"><version></span>${moduliths.version}<span class="nt"></version></span>
<span class="nt"></dependency></span>
</code></pre></div></div>
<p>It currently pulls in JPA for persistence and Jackson for serialization.
Published events that are consumed by a transactional event listener will need to be serializable by Jackson to make this work out of the box.
Both, persistence mechanism and serialization strategy are pluggable.
If you fancy to contribute different implementations (JDBC, anyone?), please make yourself heard in the <a href="https://github.com/odrotbohm/moduliths/issues">bug tracker</a>.</p>
<h2 id="improvements-to-the-module-canvas">Improvements to the Module Canvas</h2>
<p>Moduliths’ Module Canvas tries to provide a canonical overview of entry points into a particular module.
In case a developer asks: “What are the most interesing technical parts of a module?”, the Canvas is supposed to provide the answer.
It’s obviously inspired by Chris Richardson’s <a href="https://github.com/cer/microservice-canvas">Microservice Canvas</a> and the <a href="https://github.com/ddd-crew/bounded-context-canvas">Bounded Context Canvas</a> primarily driven by Nick Tune.
Here’s one taken from Salespoint, a POS library I am involved with developed by the TU Dresden:</p>
<div style="text-align: center">
<img src="/assets/images/module-canvas.png" />
</div>
<p>On the very surface, the Canvas provides information about</p>
<ul>
<li>The Spring components exposed by the module (either public or implementing an interface exposed publicly).</li>
<li>The aggregate roots contained in the module.</li>
<li>Events listened to and events published by the module.</li>
</ul>
<h3 id="grouping-components">Grouping components</h3>
<p>Moduliths 1.1 has added more details and smarts to the Canvas.
The Spring components listed are now grouped and API was introduced to customize the groupings.
If your application works with a custom stereotype, that is expressed in the code base, you can now create a custom group for it.
Assume our web layer contained components named <code class="language-plaintext highlighter-rouge">…Representations</code> that were responsible for mapping inbound and outbound JSON representations on our domain model.
We could make those show up in a dedicated group by customizing the canvas creation like this:</p>
<div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="kn">import</span> <span class="nn">static</span> <span class="n">org</span><span class="o">.</span><span class="na">moduliths</span><span class="o">.</span><span class="na">docs</span><span class="o">.</span><span class="na">Documenter</span><span class="o">.</span><span class="na">CanvasOptions</span><span class="o">.*;</span>
<span class="kt">var</span> <span class="n">representations</span> <span class="o">=</span> <span class="nc">Grouping</span><span class="o">.</span><span class="na">of</span><span class="o">(</span><span class="s">"Representations"</span><span class="o">,</span>
<span class="s">"Components to map from domain types to DTOs and vice versa."</span><span class="o">,</span>
<span class="nc">Grouping</span><span class="o">.</span><span class="na">nameMatching</span><span class="o">(</span><span class="s">".*Representations"</span><span class="o">));</span>
<span class="kt">var</span> <span class="n">documenter</span> <span class="o">=</span> <span class="k">new</span> <span class="nc">Documenter</span><span class="o">(</span><span class="n">modules</span><span class="o">).</span><span class="na">writeModuleCanvases</span><span class="o">(</span>
<span class="nc">CanvasOptions</span><span class="o">.</span><span class="na">defaults</span><span class="o">().</span><span class="na">groupingBy</span><span class="o">(</span><span class="n">representations</span><span class="o">));</span>
</code></pre></div></div>
<h3 id="more-details-about-events-and-event-listeners">More details about events and event listeners</h3>
<p>The sections describing published and listened to events as been enriched to contain more detail about the listener and the publication.
For the listeners, we now pull in the Javadoc on the listening method as description of the listener (not shown in the image above).</p>
<p>For that to work, you need to use <code class="language-plaintext highlighter-rouge">capital.scalable:spring-auto-restdocs-json-doclet</code> in your Javadoc generation to extract the Javadoc into a JSON file that is then transparently picked up by the documentation generation.
A request to extract that functionality into a separate project has been filed <a href="https://github.com/ScaCap/spring-auto-restdocs/issues/435">here</a>.</p>
<div class="language-xml highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nt"><configuration></span>
<span class="nt"><doclet></span>c.s.r.jsondoclet.ExtractDocumentationAsJsonDoclet<span class="nt"></doclet></span>
<span class="nt"><docletArtifact></span>
<span class="nt"><groupId></span>capital.scalable<span class="nt"></groupId></span>
<span class="nt"><artifactId></span>spring-auto-restdocs-json-doclet<span class="nt"></artifactId></span>
<span class="nt"><version></span>2.0.8<span class="nt"></version></span>
<span class="nt"></docletArtifact></span>
<span class="nt"></doclet></span>
<span class="nt"></configuration></span>
</code></pre></div></div>
<p>The origin of an event publication is tracked by finding constructor and factory method invocations on the event type within the code base.
If the method that call is coming from is part of the Javadoc created for the project, it gets linked to, just as all other publicly visible types.</p>
<h2 id="support-for-jmolecules">Support for jMolecules</h2>
<p><a href="https://jmolecules.org">jMolecules</a> is a Java library within the <a href="https://xmolecules.org/">xMolecules</a> family of projects that aims to provide programming language specific means to express architectural concepts in code.
Moduliths 1.1 has added support for jMolecules’ <code class="language-plaintext highlighter-rouge">@DomainEventHandler</code> as well as the <code class="language-plaintext highlighter-rouge">Repository</code> interface.
If used in code, methods and classes annotated with them will be recognized as event listener or repository respectfully.</p>
<h2 id="module-detection-api">Module detection API</h2>
<p>To be as little invasive as possible, Moduliths assumes a certain package structure to detect logical modules in a particular codebase.
All packages, directly located under the one that contains the Spring Boot application class, are considered module packages.
While this is a decent default when structuring new code bases, ones that haven’t been started with that model in mind usually deviate from that.
To be able to accommodate customization needs, Moduliths 1.1 ships a <code class="language-plaintext highlighter-rouge">ModuleDetectionStrategy</code> SPI, that allows users to return all module base packages given the root package of the application:</p>
<div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="kd">public</span> <span class="kd">interface</span> <span class="nc">ModuleDetectionStrategy</span> <span class="o">{</span>
<span class="nc">Stream</span><span class="o"><</span><span class="nc">JavaPackage</span><span class="o">></span> <span class="nf">getModuleBasePackages</span><span class="o">(</span><span class="nc">JavaPackage</span> <span class="n">basePackage</span><span class="o">);</span>
<span class="o">}</span>
</code></pre></div></div>
<p>We ship two different strategies out of the box: the default one that returns the direct subpackages as described above, and one that considers packages explicitly annotated with <code class="language-plaintext highlighter-rouge">@Module</code> only.</p>
<p>To customize the strategy to be used, register your custom implementation inside <code class="language-plaintext highlighter-rouge">META-INF/spring.factories</code>:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>org.moduliths.model.ModuleDetectionStrategy=\
com.acme.CustomModuleDetectionStrategy
</code></pre></div></div>
<p>The strategy will now be picked up, as soon as you create a <code class="language-plaintext highlighter-rouge">Modules</code> instance in your code.</p>
Spring RESTBucks in 20212021-04-14T19:21:00+02:00http://www.odrotbohm.de/2021/04/Spring-RESTBucks-in-2021
<p>The <a href="https://github.com/odrotbohm/spring-restbucks">RESTBucks sample project</a> has served as showcase for various Spring related technologies in the context of building a hypermedia based API implementing a high-level business process for almost a decade.
It has evolved significantly since then and – in the last couple of months – accumulated quite a batch of changes.
I think that it’s worthwhile to have a look at them and how new libraries, specs, and their integration into Spring projects shape the sample.</p>
<p><a name="jmolecules"></a></p>
<h1 id="jmolecules">jMolecules</h1>
<p>I’ve written about the <a href="https://github.com/xmolecules/jmolecules">jMolecules project</a> in a <a href="../../02/Architecturally-evident-code-with-jMolecules">previous post</a>.
Its general idea is to allow user code to express architectural concepts in code, and a lot of the boilerplate code that’s needed, if – for example – the model shall be persisted with JPA.
I know that whether to persist a domain model using JPA directly is a topic for debate, but I’d like to leave that for another post for now.
<a href="https://github.com/odrotbohm/spring-restbucks/commit/0a42f07ebed87eb777b633ae861fcb494339afa6">This commit</a> moved Spring RESTBucks domain model to jMolecules and essentially consist of the following steps:</p>
<ul>
<li>Aggregates, entities, and value objects now implement jMolecules’ <code class="language-plaintext highlighter-rouge">AggregateRoot</code>, <code class="language-plaintext highlighter-rouge">Entity</code> and are annotated with <code class="language-plaintext highlighter-rouge">@Value</code>.</li>
<li>Entities and aggregates now all use identifier types that implement <code class="language-plaintext highlighter-rouge">Identifier</code> backed by <code class="language-plaintext highlighter-rouge">UUID</code> strings.</li>
<li>Associations are now explicitly modeled through jMolecules <code class="language-plaintext highlighter-rouge">Association</code> interface.</li>
</ul>
<p>All JPA annotations and customizations that were necessary could be removed in favor of the <a href="https://github.com/xmolecules/jmolecules-integrations/tree/main/jmolecules-bytebuddy">jMolecules ByteBuddy plugin</a> to generate the mappings and boilerplate derived from the jMolecules annotations.</p>
<ul>
<li>Identifier fields and types do not need any kind of technical mapping and customizations anymore.</li>
<li>Entity relationships like <code class="language-plaintext highlighter-rouge">Order.lineItems</code> get default mappings applied, considering the default composition nature of aggregates, i.e. the aggregate lifecycle governing the lifecycle of the contained entities.</li>
<li>Persisting <code class="language-plaintext highlighter-rouge">Association</code> instances works out of the box due to the ByteBuddy plugin generating the necessary boilerplate <code class="language-plaintext highlighter-rouge">AttributeConverter</code> and field mapping.</li>
</ul>
<p><a name="spring-data-rest"></a></p>
<h2 id="spring-data-rest">Spring Data REST</h2>
<p>The <a href="https://spring.io/blog/2021/04/14/spring-data-2021-0-goes-ga">Spring Data Pascal release</a> train ships fundamental integration with jMolecules, like the ability to convert <code class="language-plaintext highlighter-rouge">Identifier</code> instances into primitives and properly integrate <code class="language-plaintext highlighter-rouge">Association</code> into the object mapping.
Also, Spring Data REST now picks up <code class="language-plaintext highlighter-rouge">Converter</code> implementations shipped by the jMolecules Integrations project.
All of that causes RESTBucks just to work seamlessly with the DDD building blocks expressed via jMolecules abstractions.</p>
<p><a name="jackson"></a></p>
<h2 id="jackson">Jackson</h2>
<p>Another piece of the puzzle is the jMolecules Jackson support that automatically customizes the serialization, deserialization of both <code class="language-plaintext highlighter-rouge">Identifier</code> types and value objects declared through jMolecules <code class="language-plaintext highlighter-rouge">@ValueObject</code> annotation.
This can be seen in effect on <code class="language-plaintext highlighter-rouge">CreditCardNumber</code> that’s a value object in the domain model wrapping a <code class="language-plaintext highlighter-rouge">String</code> to apply rules of the domain concept to it.
Despite the nesting, it serializes as plain <code class="language-plaintext highlighter-rouge">String</code> and also seamlessly deserializes <code class="language-plaintext highlighter-rouge">String</code>s into a <code class="language-plaintext highlighter-rouge">CreditCardNumber</code>.
You can find more details about the jMolecules Jackson integration <a href="https://github.com/xmolecules/jmolecules-integrations/tree/main/jmolecules-jackson">here</a>.</p>
<p><a name="advanced-metadata"></a></p>
<h1 id="advanced-metadata-for-state-transitions">Advanced metadata for state transitions</h1>
<p>The very start of a significant improvement in the API was to realize that the way the sample handled order submission wasn’t really a representation of the real-life process.
The standard Spring Data REST export of the <code class="language-plaintext highlighter-rouge">Order</code> domain type assumed that an order was created by <code class="language-plaintext highlighter-rouge">POST</code>ing line items to the server, including prices.
That is not quite how it works in the real world at best.
To be blunt: it’s been wrong from day one, but I effectively didn’t care about this as the example project’s focus was on the general use of hypermedia in APIs, not taking every part of the process and implement it perfectly to the very end.</p>
<p>This step of the process has now changed to be rather implemented by a custom Spring MVC controller as Spring Data REST allows us to hook into the URI space it exposes and selectively override individual resources and mappings.
We start by introducing a dedicated data transfer object (DTO) to capture all information necessary for placing an order.
In our case it’s the location the drink is supposed to be consumed at, as well as a list of drinks.
Also, we add a method to create a new <code class="language-plaintext highlighter-rouge">Order</code> from that information to the DTO:</p>
<div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nd">@Data</span>
<span class="kd">class</span> <span class="nc">LocationAndDrinks</span> <span class="o">{</span>
<span class="nd">@NotNull</span> <span class="c1">//</span>
<span class="kd">private</span> <span class="nc">Location</span> <span class="n">location</span><span class="o">;</span>
<span class="kd">private</span> <span class="nc">List</span><span class="o"><</span><span class="nc">Drink</span><span class="o">></span> <span class="n">drinks</span><span class="o">;</span>
<span class="nc">Order</span> <span class="nf">toOrder</span><span class="o">()</span> <span class="o">{</span>
<span class="nc">Order</span> <span class="n">order</span> <span class="o">=</span> <span class="k">new</span> <span class="nc">Order</span><span class="o">(</span><span class="nc">Collections</span><span class="o">.</span><span class="na">emptyList</span><span class="o">(),</span> <span class="n">location</span><span class="o">);</span>
<span class="n">drinks</span><span class="o">.</span><span class="na">forEach</span><span class="o">(</span><span class="nl">order:</span><span class="o">:</span><span class="n">add</span><span class="o">);</span>
<span class="k">return</span> <span class="n">order</span><span class="o">;</span>
<span class="o">}</span>
<span class="o">}</span>
</code></pre></div></div>
<p>We now use that type in our controller method to map the <code class="language-plaintext highlighter-rouge">@RequestBody</code>.
That process makes use of a new feature just introduced in Spring Data REST, that allows to bind aggregate instances from URIs of resources exposed by it.
<code class="language-plaintext highlighter-rouge">Drink</code> is a Spring Data REST managed aggregate, and thus, we have to submit a list of URIs pointing to drinks:</p>
<div class="language-json highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="p">{</span><span class="w">
</span><span class="nl">"drinks"</span><span class="p">:</span><span class="w"> </span><span class="p">[</span><span class="w"> </span><span class="s2">"…/drinks/3322ac99-…"</span><span class="w"> </span><span class="p">],</span><span class="w">
</span><span class="nl">"location"</span><span class="p">:</span><span class="w"> </span><span class="s2">"Zum mitnehmen"</span><span class="w">
</span><span class="p">}</span><span class="w">
</span></code></pre></div></div>
<p>Spring Data REST will take care of resolving the URI to the <code class="language-plaintext highlighter-rouge">Drink</code> instance with identifier <code class="language-plaintext highlighter-rouge">3322ac99-…</code> automatically for us.
This leaves the question of how the client will know about that structure and how to populate the fields.
We will this discuss this in detail below.
Before we do that, let’s have a look at the controller method implementation as it’s quite interesting as well:</p>
<div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nd">@BasePathAwareController</span>
<span class="nd">@RequiredArgsConstructor</span>
<span class="kd">class</span> <span class="nc">OrderController</span> <span class="o">{</span>
<span class="kd">private</span> <span class="kd">final</span> <span class="nc">Orders</span> <span class="n">orders</span><span class="o">;</span>
<span class="nd">@PostMapping</span><span class="o">(</span><span class="n">path</span> <span class="o">=</span> <span class="s">"/orders"</span><span class="o">)</span>
<span class="nc">HttpEntity</span><span class="o"><?></span> <span class="n">placeOrder</span><span class="o">(</span><span class="nd">@RequestBody</span> <span class="nc">LocationAndDrinks</span> <span class="n">payload</span><span class="o">,</span>
<span class="nc">Errors</span> <span class="n">errors</span><span class="o">,</span> <span class="nc">PersistentEntityResourceAssembler</span> <span class="n">assembler</span><span class="o">)</span> <span class="o">{</span>
<span class="k">return</span> <span class="nc">MappedPayloads</span><span class="o">.</span><span class="na">of</span><span class="o">(</span><span class="n">payload</span><span class="o">,</span> <span class="n">errors</span><span class="o">)</span>
<span class="o">.</span><span class="na">mapIfValid</span><span class="o">(</span><span class="nl">LocationAndDrinks:</span><span class="o">:</span><span class="n">toOrder</span><span class="o">)</span>
<span class="o">.</span><span class="na">mapIfValid</span><span class="o">(</span><span class="nl">orders:</span><span class="o">:</span><span class="n">save</span><span class="o">)</span>
<span class="o">.</span><span class="na">mapIfValid</span><span class="o">(</span><span class="nl">assembler:</span><span class="o">:</span><span class="n">toFullResource</span><span class="o">)</span>
<span class="o">.</span><span class="na">concludeIfValid</span><span class="o">(</span><span class="n">it</span> <span class="o">-></span> <span class="o">{</span>
<span class="kt">var</span> <span class="n">uri</span> <span class="o">=</span> <span class="n">it</span><span class="o">.</span><span class="na">getRequiredLink</span><span class="o">(</span><span class="nc">IanaLinkRelations</span><span class="o">.</span><span class="na">SELF</span><span class="o">).</span><span class="na">toUri</span><span class="o">();</span>
<span class="k">return</span> <span class="nc">ResponseEntity</span><span class="o">.</span><span class="na">created</span><span class="o">(</span><span class="n">uri</span><span class="o">).</span><span class="na">body</span><span class="o">(</span><span class="n">it</span><span class="o">);</span>
<span class="o">});</span>
<span class="o">}</span>
<span class="o">}</span>
</code></pre></div></div>
<p>Note, how it makes use of the <a href="https://github.com/odrotbohm/spring-playground/tree/main/spring-web-tools#a-monadic-mappedpayload-type"><code class="language-plaintext highlighter-rouge">MappedPayloads</code></a> abstraction currently living in my <a href="https://github.com/odrotbohm/spring-playground"><code class="language-plaintext highlighter-rouge">spring-playground</code></a> repository.
It provides an API to express the typical processing steps of a web request fluently: apply some validation, transformation of the payload, invoke business code, assemble a response representation.
We simply accept the <code class="language-plaintext highlighter-rouge">LocationAndDrinks</code> instance deserialized by Jackson, create an <code class="language-plaintext highlighter-rouge">Order</code> instance from it, store that and then use Spring Data REST’s <code class="language-plaintext highlighter-rouge">PersistentEntityResourceAssembler</code> to produce a response following the usual rules of pointing to referenced aggregates etc.
The pipeline will transparently handle binding errors by returning a <code class="language-plaintext highlighter-rouge">400 Bad Request</code> rendering the <code class="language-plaintext highlighter-rouge">Errors</code> instance as response, including support to internationalized error messages etc.
Read more about this in <a href="https://github.com/odrotbohm/spring-playground/tree/main/spring-web-tools#a-monadic-mappedpayload-type">the documentation</a>.</p>
<h2 id="advertising-the-order-creation-using-hal-forms">Advertising the order creation using HAL FORMS</h2>
<p>Now that we’ve customized the step of creating an order in the first place, how does the client find out about it?
The <a href="https://rwcbook.github.io/hal-forms/">HAL FORMS media type</a> allows to describe resource state transitions, and the payload structure expected for those.
<a href="https://github.com/spring-projects/spring-hateoas/releases/tag/1.3.0">Spring HATEOAS 1.3</a> has shipped advanced support for that and allows us to easily create such forms by defining affordances.
Affordances capture the semantics expressed by e.g. a Spring MVC controller method and depending on the configuration exposes those in the way a particular media type is defined.
As of the Spring Data Pascal release train, Spring Data REST enabled projects generally enable the exposure of affordances as HAL FORMS, but they do not expose any forms automatically yet.</p>
<p>To expose the order creation form we enrich the <code class="language-plaintext highlighter-rouge">RepositoryRootResource</code>’s <code class="language-plaintext highlighter-rouge">order</code> link with an affordance.
All we need to do to achieve that is point at the method that is accepting the request in a <code class="language-plaintext highlighter-rouge">RepresentationModelProcessor</code>.</p>
<div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nd">@Component</span>
<span class="kd">class</span> <span class="nc">RootResourceModelProcessor</span>
<span class="kd">implements</span> <span class="nc">RepresentationModelProcessor</span><span class="o"><</span><span class="nc">RepositoryLinksResource</span><span class="o">></span> <span class="o">{</span>
<span class="nd">@Override</span>
<span class="kd">public</span> <span class="nc">RepositoryLinksResource</span> <span class="nf">process</span><span class="o">(</span><span class="nc">RepositoryLinksResource</span> <span class="n">model</span><span class="o">)</span> <span class="o">{</span>
<span class="c1">// We point to the method we want to advertise</span>
<span class="kt">var</span> <span class="n">affordance</span> <span class="o">=</span> <span class="n">afford</span><span class="o">(</span><span class="n">methodOn</span><span class="o">(</span><span class="nc">OrderController</span><span class="o">.</span><span class="na">class</span><span class="o">)</span>
<span class="o">.</span><span class="na">placeOrder</span><span class="o">(</span><span class="kc">null</span><span class="o">,</span> <span class="kc">null</span><span class="o">,</span> <span class="kc">null</span><span class="o">));</span>
<span class="c1">// Add the affordance to the orders link</span>
<span class="k">return</span> <span class="n">model</span><span class="o">.</span><span class="na">mapLink</span><span class="o">(</span><span class="nc">LinkRelation</span><span class="o">.</span><span class="na">of</span><span class="o">(</span><span class="s">"orders"</span><span class="o">),</span> <span class="n">link</span> <span class="o">-></span> <span class="o">{</span>
<span class="k">return</span> <span class="n">link</span><span class="o">.</span><span class="na">andAffordance</span><span class="o">(</span><span class="n">affordance</span><span class="o">);</span>
<span class="o">});</span>
<span class="o">}</span>
<span class="o">}</span>
</code></pre></div></div>
<p>Note, how we, in a media type independent way, describe what’s to be advertised from the root resource.
We deliberately guide the client to propose a state transition using the controller method pointed to.
Alternatively, we could have built the affordance manually using Spring HATEOAS’ <a href="https://docs.spring.io/spring-hateoas/docs/1.3.0/reference/html/#server.affordances.api"><code class="language-plaintext highlighter-rouge">AffordanceBuilder</code> API</a>.
Clients that continue to request HAL won’t see any of this, but ones that understand HAL FORMs can now request the resource using an <code class="language-plaintext highlighter-rouge">Accept</code> header set to <code class="language-plaintext highlighter-rouge">application/prs.hal-forms+json</code> and see the following:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>GET /
Accept: application/prs.hal-forms+json
</code></pre></div></div>
<div class="language-json highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="p">{</span><span class="w">
</span><span class="err">…</span><span class="p">,</span><span class="w">
</span><span class="nl">"_templates"</span><span class="w"> </span><span class="p">:</span><span class="w"> </span><span class="p">{</span><span class="w">
</span><span class="nl">"default"</span><span class="p">:</span><span class="w"> </span><span class="p">{</span><span class="w">
</span><span class="nl">"method"</span><span class="p">:</span><span class="w"> </span><span class="s2">"post"</span><span class="p">,</span><span class="w">
</span><span class="nl">"properties"</span><span class="p">:</span><span class="w"> </span><span class="p">[</span><span class="w">
</span><span class="p">{</span><span class="w">
</span><span class="nl">"name"</span><span class="p">:</span><span class="w"> </span><span class="s2">"location"</span><span class="p">,</span><span class="w">
</span><span class="nl">"options"</span><span class="p">:</span><span class="w"> </span><span class="p">{</span><span class="w">
</span><span class="nl">"inline"</span><span class="p">:</span><span class="w"> </span><span class="p">[</span><span class="w">
</span><span class="s2">"Zum mitnehmen"</span><span class="p">,</span><span class="w">
</span><span class="s2">"Vor Ort"</span><span class="w">
</span><span class="p">],</span><span class="w">
</span><span class="nl">"maxItems"</span><span class="p">:</span><span class="w"> </span><span class="mi">1</span><span class="w">
</span><span class="p">},</span><span class="w">
</span><span class="nl">"prompt"</span><span class="p">:</span><span class="w"> </span><span class="s2">"Ort"</span><span class="p">,</span><span class="w">
</span><span class="nl">"required"</span><span class="p">:</span><span class="w"> </span><span class="kc">true</span><span class="p">,</span><span class="w">
</span><span class="nl">"value"</span><span class="p">:</span><span class="w"> </span><span class="s2">"Zum mitnehmen"</span><span class="w">
</span><span class="p">},</span><span class="w">
</span><span class="p">{</span><span class="w">
</span><span class="nl">"name"</span><span class="p">:</span><span class="w"> </span><span class="s2">"drinks"</span><span class="p">,</span><span class="w">
</span><span class="nl">"options"</span><span class="p">:</span><span class="w"> </span><span class="p">{</span><span class="w">
</span><span class="nl">"link"</span><span class="p">:</span><span class="w"> </span><span class="p">{</span><span class="w">
</span><span class="nl">"href"</span><span class="p">:</span><span class="w"> </span><span class="s2">"http://localhost:8080/drinks/by-name{?q}"</span><span class="p">,</span><span class="w">
</span><span class="nl">"templated"</span><span class="p">:</span><span class="w"> </span><span class="kc">true</span><span class="w">
</span><span class="p">},</span><span class="w">
</span><span class="nl">"minItems"</span><span class="p">:</span><span class="w"> </span><span class="mi">1</span><span class="w">
</span><span class="p">},</span><span class="w">
</span><span class="nl">"prompt"</span><span class="p">:</span><span class="w"> </span><span class="s2">"Getränke"</span><span class="w">
</span><span class="p">}</span><span class="w">
</span><span class="p">],</span><span class="w">
</span><span class="nl">"target"</span><span class="p">:</span><span class="w"> </span><span class="s2">"http://localhost:8080/orders"</span><span class="p">,</span><span class="w">
</span><span class="nl">"title"</span><span class="p">:</span><span class="w"> </span><span class="s2">"Eine Bestellung erzeugen"</span><span class="w">
</span><span class="p">}</span><span class="w">
</span><span class="p">}</span><span class="w">
</span><span class="p">}</span><span class="w">
</span></code></pre></div></div>
<p>There’s quite a lot going on here.
The response contains a <code class="language-plaintext highlighter-rouge">_template</code> rendered for the affordance that we described in our <code class="language-plaintext highlighter-rouge">RepresentationModelProcessor</code>.
According to the HAL FORMS spec, if only one is contained in it, it’s named <code class="language-plaintext highlighter-rouge">default</code>.
The <code class="language-plaintext highlighter-rouge">target</code> and <code class="language-plaintext highlighter-rouge">method</code> attributes are derived from the controller method we pointed to and also, the <code class="language-plaintext highlighter-rouge">LocationAndDrinks</code>’ payload type has been unfolded and its properties are advertised.
We have both the <code class="language-plaintext highlighter-rouge">title</code> and <code class="language-plaintext highlighter-rouge">prompt</code> attributes internationalized to German using a simple resource bundle as described in <a href="https://docs.spring.io/spring-hateoas/docs/current/reference/html/#mediatypes.hal-forms.i18n">Spring HATEOAS’ reference documentation</a>.</p>
<p>Both properties use the <code class="language-plaintext highlighter-rouge">options</code> element, indicating that the value to be submitted for them has to be one or more items from a given list of options.
For <code class="language-plaintext highlighter-rouge">location</code>, that list is a simple inline list of text values.
They in turn an internationalized variants of the <code class="language-plaintext highlighter-rouge">Location</code> enum that’s part of the server side model handled by Spring Data REST’s automatic enum translation feature.</p>
<p>However, the slightly more interesting case is the option definition for <code class="language-plaintext highlighter-rouge">drink</code>.
We can express that the list of available options is dynamic, and the values to be provided for selection are available via a particular (templated) URI.
HAL FORMS defines that, unless otherwise specified, the target resource is supposed to return a collection of either scalar values, or a dictionary with fields <code class="language-plaintext highlighter-rouge">value</code> and <code class="language-plaintext highlighter-rouge">prompt</code>.
Thus, we now expose a dedicated resource blending into the <code class="language-plaintext highlighter-rouge">/drinks</code> URI space from <code class="language-plaintext highlighter-rouge">DrinksOptions</code>:</p>
<div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code>
<span class="nd">@BasePathAwareController</span>
<span class="kd">public</span> <span class="kd">class</span> <span class="nc">DrinksOptions</span> <span class="o">{</span>
<span class="kd">private</span> <span class="kd">final</span> <span class="nc">Drinks</span> <span class="n">drinks</span><span class="o">;</span>
<span class="kd">private</span> <span class="kd">final</span> <span class="nc">TypedEntityLinks</span><span class="o"><</span><span class="nc">Drink</span><span class="o">></span> <span class="n">links</span><span class="o">;</span>
<span class="cm">/* Constructor omitted */</span>
<span class="nd">@GetMapping</span><span class="o">(</span><span class="s">"/drinks/by-name"</span><span class="o">)</span>
<span class="kd">public</span> <span class="nc">HttpEntity</span><span class="o"><?></span> <span class="n">getOptions</span><span class="o">(</span><span class="nd">@RequestParam</span> <span class="nc">Optional</span><span class="o"><</span><span class="nc">String</span><span class="o">></span> <span class="n">q</span><span class="o">)</span> <span class="o">{</span>
<span class="kt">var</span> <span class="n">sort</span> <span class="o">=</span> <span class="n">sort</span><span class="o">(</span><span class="nc">Drink</span><span class="o">.</span><span class="na">class</span><span class="o">).</span><span class="na">by</span><span class="o">(</span><span class="nl">Drink:</span><span class="o">:</span><span class="n">getName</span><span class="o">).</span><span class="na">ascending</span><span class="o">();</span>
<span class="kt">var</span> <span class="n">options</span> <span class="o">=</span> <span class="n">q</span><span class="o">.</span><span class="na">map</span><span class="o">(</span><span class="n">it</span> <span class="o">-></span> <span class="n">drinks</span><span class="o">.</span><span class="na">findByNameContaining</span><span class="o">(</span><span class="n">it</span><span class="o">,</span> <span class="n">sort</span><span class="o">))</span>
<span class="o">.</span><span class="na">orElseGet</span><span class="o">(()</span> <span class="o">-></span> <span class="n">drinks</span><span class="o">.</span><span class="na">findAll</span><span class="o">(</span><span class="n">sort</span><span class="o">))</span>
<span class="o">.</span><span class="na">map</span><span class="o">(</span><span class="k">this</span><span class="o">::</span><span class="n">toPromptedValue</span><span class="o">)</span>
<span class="o">.</span><span class="na">toList</span><span class="o">();</span>
<span class="kt">var</span> <span class="n">model</span> <span class="o">=</span> <span class="nc">HalModelBuilder</span><span class="o">.</span><span class="na">halModel</span><span class="o">()</span>
<span class="o">.</span><span class="na">embed</span><span class="o">(</span><span class="n">options</span><span class="o">,</span> <span class="nc">LinkRelation</span><span class="o">.</span><span class="na">of</span><span class="o">(</span><span class="s">"drinks"</span><span class="o">))</span>
<span class="o">.</span><span class="na">build</span><span class="o">();</span>
<span class="k">return</span> <span class="nc">ResponseEntity</span><span class="o">.</span><span class="na">ok</span><span class="o">(</span><span class="n">model</span><span class="o">);</span>
<span class="o">}</span>
<span class="nc">HalFormsPromptedValue</span> <span class="nf">toPromptedValue</span><span class="o">(</span><span class="nc">Drink</span> <span class="n">drink</span><span class="o">)</span> <span class="o">{</span>
<span class="k">return</span> <span class="nc">HalFormsPromptedValue</span><span class="o">.</span><span class="na">of</span><span class="o">(</span><span class="n">drink</span><span class="o">.</span><span class="na">getName</span><span class="o">(),</span>
<span class="n">links</span><span class="o">.</span><span class="na">linkToItemResource</span><span class="o">(</span><span class="n">drink</span><span class="o">).</span><span class="na">getHref</span><span class="o">())</span>
<span class="o">}</span>
<span class="o">}</span>
</code></pre></div></div>
<p>The request is answered by either looking up all drinks or applying a name filter, mapping the <code class="language-plaintext highlighter-rouge">Drink</code> instances to expose their name as prompt, and the URI they’re exposed under as value.
Thus, the responses look as follows:</p>
<div class="language-json highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="p">{</span><span class="w">
</span><span class="nl">"_embedded"</span><span class="w"> </span><span class="p">:</span><span class="w"> </span><span class="p">{</span><span class="w">
</span><span class="nl">"drinks"</span><span class="w"> </span><span class="p">:</span><span class="w"> </span><span class="p">[</span><span class="w">
</span><span class="p">{</span><span class="w"> </span><span class="nl">"prompt"</span><span class="p">:</span><span class="w"> </span><span class="s2">"Cappuchino"</span><span class="p">,</span><span class="w"> </span><span class="nl">"value"</span><span class="p">:</span><span class="w"> </span><span class="s2">"…/drinks/462a692d-…"</span><span class="w"> </span><span class="p">},</span><span class="w">
</span><span class="p">{</span><span class="w"> </span><span class="nl">"prompt"</span><span class="p">:</span><span class="w"> </span><span class="s2">"Java Chip"</span><span class="p">,</span><span class="w"> </span><span class="nl">"value"</span><span class="p">:</span><span class="w"> </span><span class="s2">"…/drinks/07217680-…"</span><span class="w"> </span><span class="p">}</span><span class="w">
</span><span class="p">]</span><span class="w">
</span><span class="p">}</span><span class="w">
</span><span class="p">}</span><span class="w">
</span></code></pre></div></div>
<p>The client is now supposed to follow the <code class="language-plaintext highlighter-rouge">link</code> attribute of the <code class="language-plaintext highlighter-rouge">options</code> document found in the form, and – depending on the <code class="language-plaintext highlighter-rouge">minItems</code>/<code class="language-plaintext highlighter-rouge">maxItems</code> arrangement – offer a selection control for the values returned.
The server is even prepared to serve some kind of auto-completion by taking the partial user input as query parameter (through the exposed template variable).
It would then submit the form to the URI described in <code class="language-plaintext highlighter-rouge">target</code> and use the values backing the individual option items.
The options configuration is added via the <code class="language-plaintext highlighter-rouge">HalFormsConfiguration</code> bean located in <code class="language-plaintext highlighter-rouge">JacksonCustomizations</code>.</p>
<div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nd">@Configuration</span><span class="o">(</span><span class="n">proxyBeanMethods</span> <span class="o">=</span> <span class="kc">false</span><span class="o">)</span>
<span class="kd">class</span> <span class="nc">JacksonCustomizations</span> <span class="o">{</span>
<span class="nd">@Bean</span>
<span class="nc">HalFormsConfiguration</span> <span class="nf">halFormsConfiguration</span><span class="o">()</span> <span class="o">{</span>
<span class="nc">Supplier</span><span class="o"><</span><span class="nc">Link</span><span class="o">></span> <span class="n">drinksOptionsUri</span> <span class="o">=</span> <span class="n">linkTo</span><span class="o">(</span><span class="n">methodOn</span><span class="o">(</span><span class="nc">DrinksOptions</span><span class="o">.</span><span class="na">class</span><span class="o">)</span>
<span class="o">.</span><span class="na">getOptions</span><span class="o">(</span><span class="nc">Optional</span><span class="o">.</span><span class="na">empty</span><span class="o">()))</span>
<span class="o">.</span><span class="na">withSelfRel</span><span class="o">()</span>
<span class="o">.</span><span class="na">withType</span><span class="o">(</span><span class="nc">MediaTypes</span><span class="o">.</span><span class="na">HAL_JSON_VALUE</span><span class="o">);</span>
<span class="k">return</span> <span class="k">new</span> <span class="nf">HalFormsConfiguration</span><span class="o">()</span>
<span class="o">.</span><span class="na">withPattern</span><span class="o">(</span><span class="nc">CreditCardNumber</span><span class="o">.</span><span class="na">class</span><span class="o">,</span> <span class="nc">CreditCardNumber</span><span class="o">.</span><span class="na">REGEX</span><span class="o">)</span>
<span class="o">.</span><span class="na">withOptions</span><span class="o">(</span><span class="nc">LocationAndDrinks</span><span class="o">.</span><span class="na">class</span><span class="o">,</span> <span class="s">"location"</span><span class="o">,</span>
<span class="n">it</span> <span class="o">-></span> <span class="nc">HalFormsOptions</span><span class="o">.</span><span class="na">inline</span><span class="o">(</span><span class="nc">Location</span><span class="o">.</span><span class="na">values</span><span class="o">())</span>
<span class="o">.</span><span class="na">withSelectedValue</span><span class="o">(</span><span class="nc">Location</span><span class="o">.</span><span class="na">TAKE_AWAY</span><span class="o">)</span>
<span class="o">.</span><span class="na">withMaxItems</span><span class="o">(</span><span class="mi">1L</span><span class="o">))</span>
<span class="o">.</span><span class="na">withOptions</span><span class="o">(</span><span class="nc">LocationAndDrinks</span><span class="o">.</span><span class="na">class</span><span class="o">,</span> <span class="s">"drinks"</span><span class="o">,</span>
<span class="n">it</span> <span class="o">-></span> <span class="nc">HalFormsOptions</span><span class="o">.</span><span class="na">remote</span><span class="o">(</span><span class="n">drinksOptionsUri</span><span class="o">.</span><span class="na">get</span><span class="o">())</span>
<span class="o">.</span><span class="na">withMinItems</span><span class="o">(</span><span class="mi">1L</span><span class="o">));</span>
<span class="o">}</span>
<span class="o">}</span>
</code></pre></div></div>
<p>See how we define inline options for the <code class="language-plaintext highlighter-rouge">LocationAndDrinks.location</code> property by simply pointing to the enum values and set up the remote options for <code class="language-plaintext highlighter-rouge">drinks</code> by constructing a URI.</p>
<p>A similar form has been exposed for the process step of issuing a payment (see <code class="language-plaintext highlighter-rouge">PaymentOrderModelProcessor</code>).
Note, how it is only conditionally added to the representations using <code class="language-plaintext highlighter-rouge">RepresentationModel.mapLinkIf(…)</code> which means that the form will only be visible to clients if the order is to be paid in the first place implementing the hypermedia as the engine of application state idea.
The <code class="language-plaintext highlighter-rouge">HalFormsConfiguration</code> has set up an explicit pattern for the <code class="language-plaintext highlighter-rouge">CreditCardNumber</code> domain type (see above).
This causes the form derived from <code class="language-plaintext highlighter-rouge">PaymentForm</code> (the type mapping the payload) expose that pattern as <code class="language-plaintext highlighter-rouge">regex</code> for the <code class="language-plaintext highlighter-rouge">number</code> field.</p>
<h2 id="hal-explorer">HAL Explorer</h2>
<p>It’s not by accident that the just released 0.16.0 version of the <a href="https://github.com/toedter/hal-explorer">HAL Explorer library</a> maintained by Spring HATEOAS community veteran <a href="https://twitter.com/kaitoedter">Kai Tödter</a> has shipped extended support for HAL FORMS in general and the <code class="language-plaintext highlighter-rouge">options</code> field in particular.
Kai has helped to shape the addition of the <code class="language-plaintext highlighter-rouge">options</code> element to the HAL FORMS significantly, and I am glad that we could get Spring Data REST’s HAL Explorer module to be updated to consume the WebJAR of that version for the Pascal release.
That means, the advanced support for HAL FORMS in Spring HATEOAS and Spring Data REST can be visualized right away.
Let’s have a quick walk through the individual process steps using the HAL Explorer.</p>
<p>To start the application, simply clone the sample project repository, move into the <code class="language-plaintext highlighter-rouge">server</code> directory, run <code class="language-plaintext highlighter-rouge">./mvnw spring-boot:run</code> and point your browser to <code class="language-plaintext highlighter-rouge">http://localhost:8080</code>.
The HAL Explorer will show up and issue an HTTP request asking for HAL FORMS to the root of the API.
The above mentioned form returned will cause the UI show that it found a form.</p>
<div style="text-align: center">
<img src="/assets/images/restbucks/place-order-form-1.png" />
</div>
<p>Note, how the internationalized title returned in the form is used for display purposes.
Clicking on the plus icon will reveal the form and allow users to actually fill it out:</p>
<div style="text-align: center">
<img src="/assets/images/restbucks/place-order-form-2.png" />
</div>
<p>See how HAL Explorer advertises the properties required to be submitted, how it has rendered a single-value selection drop-down menu for the location as well as a multi-select element for the drinks, populated with the values obtained from the resource.
In the body section of the form you can also see the actual payload that HAL Explorer is going to submit to the server.
If you select a second element from the “Getränke” section, it will automatically add that to the array value of the <code class="language-plaintext highlighter-rouge">drinks</code> field.</p>
<p>Once we submitted the form, the client follows the <code class="language-plaintext highlighter-rouge">Location</code> header of the <code class="language-plaintext highlighter-rouge">201 Created</code> response.
As the order is now in “payment expected” state, it exposes both the <code class="language-plaintext highlighter-rouge">restbucks:payment</code> link as well as a form to submit the payment:</p>
<div style="text-align: center">
<img src="/assets/images/restbucks/payment-form-1.png" />
</div>
<p>We can again click the button to reveal the full form:</p>
<div style="text-align: center">
<img src="/assets/images/restbucks/payment-form-2.png" />
</div>
<p>See how the client has made use of the <code class="language-plaintext highlighter-rouge">regex</code> field of the form definition to automatically apply validation to the input field, and reports the error, as we’re still lacking to enter the 16th digit of the credit card number.</p>
<p>While HAL Explorer is of course not a UI that you’d like to expose to end users, it is a great tool to make a hypermedia API discoverable by client developers.
Especially, as – in contrast to other approaches – does not only inspect static API description, but also integrates with the dynamic nature of hypermedia APIs nicely.</p>
<h1 id="summary">Summary</h1>
<p>That’s been quite a ride!
I hope you could get an impression of how the features shipped in the latest Spring HATEOAS and Spring Data releases help you to build richer APIs and at the same time reduce the amount of persistence technology induced boilerplate in your domain model.
There’s more in the pipeline.
In particular, I am going to improve on the testing and documentation story, so that you get an impression of how to use Spring REST Docs to document hypermedia APIs and package that documentation right with the application so that it’s discoverable by HAL Explorer.
Also, I’d like to polish up my Android client implementation also contained in the repository to make more extensive use of the affordances exposed by the API.</p>
<p>Anything you liked in particular?
Suggestions to make what to improve on?
Please leave a comment below!</p>
Architecturally evident code with jMolecules2021-02-22T22:51:00+01:00http://www.odrotbohm.de/2021/02/Architecturally-evident-code-with-jMolecules
<p>Expressing architectural concepts in code often stops at naming conventions and technologies implicitly describing these concepts. <a href="http://jmolecules.org">jMolecules</a> provides annotations and types to describe architectural context and technology specific integration to derive concept specific default mappings and boilerplate code to minimize the gap between architectural idea and the code written to implement those.</p>
<p><em>Note: This is a follow up blog post to <a href="http://odrotbohm.de/2020/03/Implementing-DDD-Building-Blocks-in-Java/">“Implementing DDD Building Blocks in Java”</a> as the libraries discussed in that have evolved significantly.
While I thought about updating the original article I eventually decided to write a completely new one as the extend of the changes is too great.</em></p>
<h2 id="the-architecture-code-gap">The architecture code gap</h2>
<p>The general journey from architectural idea usually follows the following pattern:
the team has a rough idea of the fundamental logical structure of the code they want to write.
That structure can be driven by patterns solely established within the team but is usually influenced by widely adapted architectural approaches like Ports and Adapters or Domain-Driven Design building blocks like entities, aggregates, repositories and services.
The teams agree on a strategy to actually implement these concepts.
The means to achieve that commonly range from naming conventions for individual types or packages and package structures.
Then, the final step towards running code is mapping the logical and technical constraints implied by the concept to the implementation technologies.</p>
<p>Let us take a look at a very simple example.
Assume a simple <code class="language-plaintext highlighter-rouge">Customer</code> aggregate that is responsible to implement business constraints.
For example, we should be allowed to assign multiple addresses to the customer, but at least a single <code class="language-plaintext highlighter-rouge">Address</code> instance needs to be assigned to it.
This is admittedly simplistic but the complexity of the constraints does not actually matter to the point I am trying to make.
Let us further assume, we would want to map the model code to the database directly using JPA and Spring Data repositories.
I know this is a topic worth debating on its own, but let us stick with that for now.
Even in that very reduced example, the actual implementation has significant impact on the code to be written:</p>
<ul>
<li>The concept of an aggregate in the code base is established by the presence of an entity and a corresponding repository.</li>
<li>The implementation of the root entity of the aggregate has to adhere to some constraints implied by JPA: a default constructor is required, explicit, embedded identifier types have to implement <code class="language-plaintext highlighter-rouge">Serializable</code>, etc.</li>
<li>We need to apply some default mappings that are expressions of the constraints implied by the roles of the individual types and the overall arrangement: the dedicated identifier type has to be annotated with <code class="language-plaintext highlighter-rouge">@EmbeddedId</code>.
The list of addresses has to be mapped as cascading <code class="language-plaintext highlighter-rouge">@OneToMany</code> relationship to express the governing nature of the conceptual aggregate.</li>
</ul>
<p>There might be well justified exceptions to those mappings but fundamentally, there are rules that can and have to be applied to express the logical concept.
Zooming out a bit, there are a couple of things going on here at the same time.
First, the logical concept of an aggregate is not explicit.
It is scattered amongst different technologies that kind of help expressing the concept but suffer a fundamental problem themselves, which is – second – they are not designed with the architectural abstraction in mind in the first place.
Arguably, Spring Data is built around the concept of a DDD repository. Also, Spring provides stereotype annotations like <code class="language-plaintext highlighter-rouge">@Service</code> and <code class="language-plaintext highlighter-rouge">@Repository</code> to assign roles to container managed components.
However, they are driven by the needs of the particular technology’s requirements and functionality like applying transactions and persistence exception translation in the examples given.</p>
<p class="teaser">
What if we could approach this differently?
What if we could express the well established architectural and design concepts explicitly and the technology mappings or at least more reasonable defaults for them would be derived from those?
</p>
<p><a name="jmolecules"></a></p>
<h2 id="jmolecules">jMolecules</h2>
<p>Let us take it one step at a time.
<a href="http://jmolecules.org">jMolecules</a> is a project that attempts to tackle the first step: expressing architectural concepts in code directly, either through annotations or interfaces.
It has evolved from the jDDD library discussed in <a href="http://odrotbohm.de/2020/03/Implementing-DDD-Building-Blocks-in-Java/">this earlier blog post</a> but found a new home in the <a href="http://xmolecules.org/">xMolecules project</a> that in turn attempts to provide similar architectural abstractions for different programming ecosystems.</p>
<p>So we would start by using the Domain-Driven Design abstractions provided by jMolecules in our domain model:</p>
<div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="kn">import</span> <span class="nn">org.jmolecules.ddd.types.AggregateRoot</span><span class="o">;</span>
<span class="kn">import</span> <span class="nn">org.jmolecules.ddd.types.Entity</span><span class="o">;</span>
<span class="kn">import</span> <span class="nn">org.jmolecules.ddd.types.Identifier</span><span class="o">;</span>
<span class="kd">class</span> <span class="nc">Customer</span> <span class="kd">implements</span> <span class="nc">AggregateRoot</span><span class="o"><</span><span class="nc">Customer</span><span class="o">,</span> <span class="nc">CustomerId</span><span class="o">></span> <span class="o">{</span>
<span class="kd">private</span> <span class="kd">final</span> <span class="nc">CustomerId</span> <span class="n">id</span><span class="o">;</span>
<span class="kd">private</span> <span class="nc">List</span><span class="o"><</span><span class="nc">Address</span><span class="o">></span> <span class="n">addresses</span><span class="o">;</span>
<span class="cm">/* Other properties and business methods omitted. */</span>
<span class="nd">@Value</span><span class="o">(</span><span class="n">staticConstructor</span> <span class="o">=</span> <span class="s">"of"</span><span class="o">)</span>
<span class="kd">public</span> <span class="kd">static</span> <span class="kd">class</span> <span class="nc">CustomerId</span> <span class="kd">implements</span> <span class="nc">Identifier</span> <span class="o">{</span>
<span class="kd">private</span> <span class="kd">final</span> <span class="no">UUID</span> <span class="n">id</span><span class="o">;</span>
<span class="o">}</span>
<span class="o">}</span>
<span class="kd">class</span> <span class="nc">Address</span> <span class="kd">implements</span> <span class="nc">Entity</span><span class="o"><</span><span class="nc">Customer</span><span class="o">,</span> <span class="nc">AddressId</span><span class="o">></span> <span class="o">{</span>
<span class="cm">/* Other properties and business methods omitted. */</span>
<span class="nd">@Value</span><span class="o">(</span><span class="n">staticConstructor</span> <span class="o">=</span> <span class="s">"of"</span><span class="o">)</span>
<span class="kd">static</span> <span class="kd">class</span> <span class="nc">AddressId</span> <span class="kd">implements</span> <span class="nc">Identifier</span> <span class="o">{</span>
<span class="kd">private</span> <span class="kd">final</span> <span class="no">UUID</span> <span class="n">id</span><span class="o">;</span>
<span class="o">}</span>
<span class="o">}</span>
</code></pre></div></div>
<p>We’re able to express Domain-Driven Design concepts here:</p>
<ul>
<li><code class="language-plaintext highlighter-rouge">CustomerId</code> and <code class="language-plaintext highlighter-rouge">AddressId</code> are identifiers.</li>
<li><code class="language-plaintext highlighter-rouge">Customer</code> is an aggregate with <code class="language-plaintext highlighter-rouge">CustomerId</code> as its identifier type.</li>
<li><code class="language-plaintext highlighter-rouge">Address</code> is an entity belonging to the <code class="language-plaintext highlighter-rouge">Customer</code> aggregate using <code class="language-plaintext highlighter-rouge">AddressId</code> as identifier type.</li>
</ul>
<p>This looks very neat so far.
Except the slightly verbose identifier wrapper types, we are writing only the minimal amount of code necessary and the higher level concepts are both explicitly visible to the developers and also extractable for tools that might want to derive documentation.
However, if this code was supposed to be persisted using for example JPA, we would now have to go ahead and add quite a bit of boilerplate annotations and implementation code:</p>
<ul>
<li>Both <code class="language-plaintext highlighter-rouge">Address</code> and <code class="language-plaintext highlighter-rouge">Customer</code> would need to be annotated with JPA’s <code class="language-plaintext highlighter-rouge">@Entity</code> and get default constructors.
As we can only <code class="language-plaintext highlighter-rouge">null</code> the properties, this would effectively prevent us from imposing non-nullability constraints on any fields.</li>
<li>The implementations of <code class="language-plaintext highlighter-rouge">Identifier</code> would have to additionally implement <code class="language-plaintext highlighter-rouge">Serializable</code> and ideally also declare a serial version UUID.</li>
<li>We would have to annotate the identifier types as <code class="language-plaintext highlighter-rouge">@Embeddable</code>, the identifier fields within the entities as <code class="language-plaintext highlighter-rouge">@EmbeddedId</code> and map the <code class="language-plaintext highlighter-rouge">addresses</code> property using an <code class="language-plaintext highlighter-rouge">@OneToMany</code>.</li>
</ul>
<p><a name="jmolecules-integrations"></a></p>
<h2 id="jmolecules-technology-integrations">jMolecules technology integrations</h2>
<p>Besides the core artifacts containing abstractions to express architectural patterns, jMolecules provides a set of <a href="https://github.com/xmolecules/jmolecules-integrations">technology integration libraries</a>.
At its heart, there is a ByteBuddy plugin that will translate jMolecules annotations and interfaces into the technology specific annotations and declarations to make sure they work out of the box within in a particular technology context.
The complete example can be found <a href="https://github.com/xmolecules/jmolecules-integrations/tree/main/jmolecules-examples/jmolecules-spring-data-jpa">here</a>.</p>
<div class="language-xml highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nt"><build></span>
<span class="nt"><plugins></span>
<span class="nt"><plugin></span>
<span class="nt"><groupId></span>net.bytebuddy<span class="nt"></groupId></span>
<span class="nt"><artifactId></span>byte-buddy-maven-plugin<span class="nt"></artifactId></span>
<span class="nt"><version></span>1.10.21<span class="nt"></version></span>
<span class="nt"><executions></span>
<span class="nt"><execution></span>
<span class="nt"><goals></span>
<span class="nt"><goal></span>transform<span class="nt"></goal></span>
<span class="nt"></goals></span>
<span class="nt"></execution></span>
<span class="nt"></executions></span>
<span class="nt"><dependencies></span>
<span class="nt"><dependency></span>
<span class="nt"><groupId></span>org.jmolecules.integrations<span class="nt"></groupId></span>
<span class="nt"><artifactId></span>jmolecules-bytebuddy<span class="nt"></artifactId></span>
<span class="nt"><version></span>0.1.0<span class="nt"></version></span>
<span class="nt"></dependency></span>
<span class="nt"></dependencies></span>
<span class="nt"></plugin></span>
<span class="nt"></plugins></span>
<span class="nt"></build></span>
</code></pre></div></div>
<p>The <code class="language-plaintext highlighter-rouge">jmolecules-bytebuddy</code> plugin will – depending on the classpath arrangement of the project being built – inspect the code to be compiled for architectural concepts expressed via jMolecules annotations and types.
It will then add the technology specific annotations that are required to implement the concept and add it to the code compiled.</p>
<p>With that plugin integrated into the build, the code <code class="language-plaintext highlighter-rouge">Customer</code> aggregate code shown above is indeed a fully functional JPA entity.
All default constructors, additional interfaces and default mappings as described above will be generated.
Also, if the nullability annotations arrangement of the type describes fields as non-nullable, a generated <code class="language-plaintext highlighter-rouge">@PrePersist</code>/<code class="language-plaintext highlighter-rouge">@PostLoad</code> method will verify the instance to be persisted or just loaded to be in valid state, in other words, that no non-nullable fields are actually <code class="language-plaintext highlighter-rouge">null</code>.</p>
<h3 id="spring-integration">Spring integration</h3>
<p>Besides the integration for JPA, the ByteBuddy plugin also translates jMolecules <code class="language-plaintext highlighter-rouge">@Service</code>, <code class="language-plaintext highlighter-rouge">@Repository</code> etc. annotations into their Spring counterparts so that application components can stay free of Spring annotations for the sole purpose of component definition but still work out of the box with it.</p>
<p>Also, jMolecules’ <a href="https://github.com/xmolecules/jmolecules/blob/1.1.0/jmolecules-events/src/main/java/org/jmolecules/event/annotation/DomainEventHandler.java"><code class="language-plaintext highlighter-rouge">@DomainEventHandler</code></a> annotation is translate into Spring’s <code class="language-plaintext highlighter-rouge">@EventListener</code> to implement annotation driven event listeners.</p>
<h2 id="summary">Summary</h2>
<p>jMolecules allows to express architectural concepts like Domain-Driven Design building blocks as annotations or types within Java code.
Its integration library projects those concepts into particular technologies like JPA and Spring.</p>
Implementing DDD Building Blocks in Java2020-03-17T16:25:00+01:00http://www.odrotbohm.de/2020/03/Implementing-DDD-Building-Blocks-in-Java<p><em>NOTE: This post has been largely superseded by “Architecturally evident code with jMolecules”.
Make sure you rather read this one for the most up to date state of affairs.</em></p>
<p>When it comes to implementing building blocks of DDD, developers often struggle to find a good balance between conceptual purity and technical pragmatism.
In this article I’m going to discuss an experimental idea to express some of tactical design concepts of DDD in Java code and derive the metadata to e.g. implement persistence without polluting the domain model with annotations on the one hand and an additional mapping layer on the other.</p>
<h2 id="context">Context</h2>
<p>In Java applications the building blocks of Domain-Driven Design can be implemented in a variety of ways.
Those ways usually make different trade-offs in decoupling the actual domain model from technology specific aspects.
A lot of Java projects err on the side of still annotating their model classes with e.g. JPA annotations for easy persistence so that they don’t have to maintain a separate persistence model.
Whether that’s a good idea is out of scope for this article.
The primary focus of it is to see how we make the model more focused on DDD even in that case.</p>
<p>Another aspect we’re going to touch on is how to make DDD building blocks visible within the code.
Often a lot of them can be indirectly identified, e.g. by analyzing that the domain type managed by a Spring Data repository having to be an aggregate by definition.
However, in that particular case we’re relying on a particular persistence technology to be in use to derive exactly that information.
Also, it would be nice if we could reason about the role of a type by looking at it without any other context.</p>
<p><a name="sample"></a></p>
<h2 id="sample">Sample</h2>
<p>Let’s start with a quick example that allows us to highlight the challenges.
Note, that the model is not the only way you could design it.
I am just describing what could be the result of a design in a particular context.
It’s about how an aggregate, entity or value object can be represented in code and the effect of one particular way of doing that.
We model <code class="language-plaintext highlighter-rouge">Customer</code>s that consist of <code class="language-plaintext highlighter-rouge">Address</code>es, <code class="language-plaintext highlighter-rouge">Order</code>s that consist of <code class="language-plaintext highlighter-rouge">LineItem</code>s which in turn point to <code class="language-plaintext highlighter-rouge">Product</code>s and point to the <code class="language-plaintext highlighter-rouge">Customer</code> that placed the order.
Both <code class="language-plaintext highlighter-rouge">Customer</code> and <code class="language-plaintext highlighter-rouge">Order</code> are aggregates conceptually.</p>
<p><strong>A sample excerpt domain model</strong></p>
<p style="text-align: center;"><img src="/assets/images/sample.svg" alt="Sample UML" /></p>
<p>Let’s start with the <code class="language-plaintext highlighter-rouge">Order</code>’s relationship to the <code class="language-plaintext highlighter-rouge">Customer</code>
aggregate. A very naive representation in code that uses JPA annotations
directly would probably look something like this:</p>
<figure class="highlight"><pre><code class="language-java" data-lang="java"><span class="nd">@Entity</span>
<span class="kd">class</span> <span class="nc">Order</span> <span class="o">{</span>
<span class="nd">@EmbeddedId</span> <span class="nc">OrderId</span> <span class="n">id</span><span class="o">;</span>
<span class="nd">@ManyToOne</span> <span class="nc">Customer</span> <span class="n">customer</span><span class="o">;</span>
<span class="nd">@OneToMany</span> <span class="nc">List</span><span class="o"><</span><span class="nc">LineItem</span><span class="o">></span> <span class="n">items</span><span class="o">;</span>
<span class="o">}</span>
<span class="nd">@Entity</span>
<span class="kd">class</span> <span class="nc">LineItem</span> <span class="o">{</span>
<span class="nd">@ManyToOne</span> <span class="nc">Product</span> <span class="n">product</span><span class="o">.</span>
<span class="o">}</span>
<span class="nd">@Entity</span>
<span class="kd">class</span> <span class="nc">Customer</span> <span class="o">{</span>
<span class="nd">@EmbeddedId</span> <span class="nc">CustomerId</span> <span class="n">id</span><span class="o">;</span>
<span class="o">}</span></code></pre></figure>
<p>While this constitutes working code, a lot of the semantics of the model remain implicit.
In JPA, the most coarse grained concept is an entity.
It doesn’t know about aggregates.
It will also automatically use eager loading for to-one relationships.
For a cross aggregate relationship that is not what we want.</p>
<p>A technology focused reaction would be to switch to lazy loading.
That however creates a new problems, we’re on a start to dig down a rabbit hole and actually have moved away from domain modeling to modeling technology, something we wanted to avoid in the first place.
We also might want to resort to rather only map identifiers instead of aggregate types, e.g. replacing <code class="language-plaintext highlighter-rouge">Customer</code> with <code class="language-plaintext highlighter-rouge">CustomerId</code> in <code class="language-plaintext highlighter-rouge">Order</code>.
While that solves the cascading problem, it’s now even less clear that this property effectively establishes a cross aggregate relationship.</p>
<p>For the <code class="language-plaintext highlighter-rouge">LineItem</code>s referenced, a proper default mapping would rather be eager loading (instead of lazy) and cascading all operations as the aggregate usually governs the life cycle of its internals.</p>
<p><a name="idea"></a></p>
<h2 id="the-idea">The idea</h2>
<p>To improve the situation described above, we could start introducing types that allow us to explicitly assign roles to model artifacts and constrain the composition of them by using generics.
Let’s start with those (most of them originally described in John Sullivan’s <a href="http://scabl.blogspot.com/2015/04/aeddd-9.html">Advancing Enterprise DDD - Reinstating the Aggregate</a> but slightly renamed alongside the attempt to turn this into a library).</p>
<figure class="highlight"><pre><code class="language-java" data-lang="java"><span class="kd">interface</span> <span class="nc">Identifier</span> <span class="o">{}</span>
<span class="kd">interface</span> <span class="nc">Identifiable</span><span class="o"><</span><span class="no">ID</span> <span class="kd">extends</span> <span class="nc">Identifier</span><span class="o">></span> <span class="o">{</span>
<span class="no">ID</span> <span class="nf">getId</span><span class="o">();</span>
<span class="o">}</span>
<span class="kd">interface</span> <span class="nc">Entity</span><span class="o"><</span><span class="no">T</span> <span class="kd">extends</span> <span class="nc">AggregateRoot</span><span class="o"><</span><span class="no">T</span><span class="o">,</span> <span class="o">?>,</span> <span class="no">ID</span> <span class="kd">extends</span> <span class="nc">Identifier</span><span class="o">></span>
<span class="kd">extends</span> <span class="nc">Identifiable</span><span class="o"><</span><span class="no">ID</span><span class="o">></span> <span class="o">{}</span>
<span class="kd">interface</span> <span class="nc">AggregateRoot</span><span class="o"><</span><span class="no">T</span> <span class="kd">extends</span> <span class="nc">AggregateRoot</span><span class="o"><</span><span class="no">T</span><span class="o">,</span> <span class="no">ID</span><span class="o">>,</span> <span class="no">ID</span> <span class="kd">extends</span> <span class="nc">Identifier</span><span class="o">></span>
<span class="kd">extends</span> <span class="nc">Entity</span><span class="o"><</span><span class="no">T</span><span class="o">,</span> <span class="no">ID</span><span class="o">></span> <span class="o">{}</span>
<span class="kd">interface</span> <span class="nc">Association</span><span class="o"><</span><span class="no">T</span> <span class="kd">extends</span> <span class="nc">AggregateRoot</span><span class="o"><</span><span class="no">T</span><span class="o">,</span> <span class="no">ID</span><span class="o">>,</span> <span class="no">ID</span> <span class="kd">extends</span> <span class="nc">Identifier</span><span class="o">></span>
<span class="kd">extends</span> <span class="nc">Identifiable</span><span class="o"><</span><span class="no">ID</span><span class="o">></span> <span class="o">{}</span></code></pre></figure>
<p><code class="language-plaintext highlighter-rouge">Identifier</code> is just a marker interface to equip identifier types with. That encourages dedicated types to describe identifiers.
Primary intent of that is to avoid every entity to be identified by a common type (such as <code class="language-plaintext highlighter-rouge">Long</code> or <code class="language-plaintext highlighter-rouge">UUID</code>).
While that might seem like a good idea from a persistence point of view it’s easy to mix up a <code class="language-plaintext highlighter-rouge">Customer</code>’s identifier with an <code class="language-plaintext highlighter-rouge">Order</code>’s one.
Explicit identifier types avoid that problem.</p>
<p>A DDD <code class="language-plaintext highlighter-rouge">Entity</code> is an identifiable concept which means it needs to expose its identifier. It is also bound to an <code class="language-plaintext highlighter-rouge">AggregateRoot</code>.
That might seem counter intuitive at first but it allows to verify that an <code class="language-plaintext highlighter-rouge">Entity</code> such as <code class="language-plaintext highlighter-rouge">LineItem</code> is not accidentally referred to from a different aggregate.
Using those interfaces we can set up static code analysis tooling to verify our model structure.</p>
<p><code class="language-plaintext highlighter-rouge">Association</code> is basically an indirection towards a related aggregate’s identifier that purely serves expressiveness within the model.</p>
<p>These interfaces and all subsequently mentioned code are available through a library called <em>jDDD</em>, living in <a href="https://github.com/odrotbohm/jddd">this GitHub repository</a>.</p>
<p><a name="explicit-building-blocks"></a></p>
<h3 id="explicit-building-blocks-in-our-sample">Explicit building blocks in our sample</h3>
<p>What would our model look like with these concepts applied (JPA annotations not declared for clarity, code to be found <a href="https://github.com/odrotbohm/jddd/tree/master/jddd-examples/jddd-spring-data-jpa">here</a>)?</p>
<figure class="highlight"><pre><code class="language-java" data-lang="java"><span class="kd">class</span> <span class="nc">OrderId</span> <span class="kd">implements</span> <span class="nc">Identifier</span> <span class="o">{}</span> <span class="c1">// same for other ID types</span>
<span class="kd">class</span> <span class="nc">Order</span> <span class="kd">implements</span> <span class="nc">AggregateRoot</span><span class="o"><</span><span class="nc">Order</span><span class="o">,</span> <span class="nc">OrderId</span><span class="o">></span> <span class="o">{</span>
<span class="nc">OrderId</span> <span class="n">id</span><span class="o">;</span>
<span class="nc">CustomerAssociation</span> <span class="n">customer</span><span class="o">;</span>
<span class="nc">List</span><span class="o"><</span><span class="nc">LineItem</span><span class="o">></span> <span class="n">items</span><span class="o">;</span>
<span class="o">}</span>
<span class="kd">class</span> <span class="nc">LineItem</span> <span class="kd">implements</span> <span class="nc">Entity</span><span class="o"><</span><span class="nc">Order</span><span class="o">,</span> <span class="nc">LineItemId</span><span class="o">></span> <span class="o">{</span> <span class="err">…</span> <span class="o">}</span>
<span class="kd">class</span> <span class="nc">CustomerAssociation</span> <span class="kd">implements</span> <span class="nc">Association</span><span class="o"><</span><span class="nc">Customer</span><span class="o">,</span> <span class="nc">CustomerId</span><span class="o">></span> <span class="o">{</span> <span class="err">…</span> <span class="o">}</span>
<span class="kd">class</span> <span class="nc">Customer</span> <span class="kd">implements</span> <span class="nc">AggregateRoot</span><span class="o"><</span><span class="nc">Customer</span><span class="o">,</span> <span class="nc">CustomerId</span><span class="o">></span> <span class="o">{</span> <span class="err">…</span> <span class="o">}</span></code></pre></figure>
<p>With that we can extract a lot of additional information from looking at
the types and the fields alone:</p>
<ul>
<li>The identifier type for <code class="language-plaintext highlighter-rouge">Order</code> is <code class="language-plaintext highlighter-rouge">OrderId</code>, something we could’ve derived before but only involving JPA annotation interpretation.</li>
<li><code class="language-plaintext highlighter-rouge">LineItem</code> is an entity belonging to the <code class="language-plaintext highlighter-rouge">Order</code> aggregate.</li>
<li>The <code class="language-plaintext highlighter-rouge">customer</code> property clearly indicates it’s represents an association towards the <code class="language-plaintext highlighter-rouge">Customer</code> aggregate.</li>
</ul>
<p>It’s a pretty straight forward task to implement a verification of e.g. entities only being held in their owning aggregates using tools like <a href="https://jqassistant.org/">jQAssistant</a> or <a href="https://www.archunit.org/">ArchUnit</a>.
Also the information can be extracted, used for documentation etc.</p>
<p><a name="persistence-technology"></a></p>
<h3 id="adapting-fundamental-persistence-technology">Adapting fundamental persistence technology</h3>
<p>While all of this is nice, we still face the challenge of having to map this to a data store eventually, in this case assuming JPA.
As identified before there are some default mapping rules we’d need to apply that result in boilerplate annotating of the model.
Some examples of such steps:</p>
<ul>
<li>All entities will need to be annotated with <code class="language-plaintext highlighter-rouge">@javax.persistence.Entity</code>.</li>
<li>Identifier types will need to become <code class="language-plaintext highlighter-rouge">@Embeddable</code>, the identifier (read: an entity’s property with a type assignable to <code class="language-plaintext highlighter-rouge">Identifier</code>) mapped as <code class="language-plaintext highlighter-rouge">@EmbeddedId</code>.
In e.g. Hibernate embedded identifiers also need to implement <code class="language-plaintext highlighter-rouge">Serializable</code> (for potential usability in a second-level cache).</li>
<li><code class="language-plaintext highlighter-rouge">Entity</code> properties within an aggregate could get relationship mappings defaulted to <code class="language-plaintext highlighter-rouge">@OneToOne</code> or <code class="language-plaintext highlighter-rouge">@OneToMany</code> with eager fetching as it’s reasonable to assume the aggregate controls their lifecycle.</li>
<li>Implementations of <code class="language-plaintext highlighter-rouge">Association</code> will have to be embeddables as well.</li>
</ul>
<p>How do we actually massage these defaults into the types from the outside? I have a <a href="https://github.com/odrotbohm/jddd/tree/master/jddd-jpa">prototypical implementation based on ByteBuddy</a> available. It ships a <a href="https://github.com/odrotbohm/jddd/blob/1ca9d08a23b17454c4b2c5b3e09ab3cfcb1e907b/jddd-jpa/src/main/java/org/jddd/jpa/JDddJpaPlugin.java"><code class="language-plaintext highlighter-rouge">JpaPlugin</code></a> implementing ByteBuddy’s <code class="language-plaintext highlighter-rouge">Plugin</code> interface for usage from its build plugins like this:</p>
<p><em>Using the ByteBuddy JPA plugin to default JPA annotations based on DDD
concepts.</em></p>
<figure class="highlight"><pre><code class="language-xml" data-lang="xml"><span class="nt"><plugin></span>
<span class="nt"><groupId></span>net.bytebuddy<span class="nt"></groupId></span>
<span class="nt"><artifactId></span>byte-buddy-maven-plugin<span class="nt"></artifactId></span>
<span class="nt"><version></span>${bytebuddy.version}<span class="nt"></version></span>
<span class="nt"><executions></span>
<span class="nt"><execution></span>
<span class="nt"><goals></span>
<span class="nt"><goal></span>transform<span class="nt"></goal></span>
<span class="nt"></goals></span>
<span class="nt"></execution></span>
<span class="nt"></executions></span>
<span class="nt"><configuration></span>
<span class="nt"><transformations></span>
<span class="nt"><transformation></span>
<span class="nt"><plugin></span>….JDddJpaPlugin<span class="nt"></plugin></span>
<span class="nt"></transformation></span>
<span class="nt"></transformations></span>
<span class="nt"></configuration></span>
<span class="nt"></plugin></span></code></pre></figure>
<p>The plugin would essentially work as follows:</p>
<ol>
<li>Identify the DDD concept by checking whether the type handed to the <code class="language-plaintext highlighter-rouge">Plugin</code> implements any of the interfaces of interest.</li>
<li>For each concept inspect type and fields for existing annotations and — if not present — add the default appropriate for the relationship at hand.</li>
</ol>
<p><a name="spring-data"></a></p>
<h3 id="integration-with-spring-data">Integration with Spring Data</h3>
<p>A final step we can take in terms of letting persistence technology adapt to the information available in the type system is the question how to resolve <code class="language-plaintext highlighter-rouge">Associations</code> easily.
Our aforementioned sample contains these interfaces which at some point could actually make it int Spring Data:</p>
<figure class="highlight"><pre><code class="language-java" data-lang="java"><span class="kd">interface</span> <span class="nc">AggregateLookup</span><span class="o"><</span><span class="no">T</span> <span class="kd">extends</span> <span class="nc">AggregateRoot</span><span class="o"><</span><span class="no">T</span><span class="o">,</span> <span class="no">ID</span><span class="o">>,</span> <span class="no">ID</span> <span class="kd">extends</span> <span class="nc">Identifier</span><span class="o">></span> <span class="o">{</span>
<span class="nc">Optional</span><span class="o"><</span><span class="no">T</span><span class="o">></span> <span class="nf">findById</span><span class="o">(</span><span class="no">ID</span> <span class="n">id</span><span class="o">);</span>
<span class="o">}</span>
<span class="kd">interface</span> <span class="nc">AssociationResolver</span><span class="o"><</span><span class="no">T</span> <span class="kd">extends</span> <span class="nc">AggregateRoot</span><span class="o"><</span><span class="no">T</span><span class="o">,</span> <span class="no">ID</span><span class="o">>,</span> <span class="no">ID</span> <span class="kd">extends</span> <span class="nc">Identifier</span><span class="o">></span>
<span class="kd">extends</span> <span class="nc">AggregateLookup</span><span class="o"><</span><span class="no">T</span><span class="o">,</span> <span class="no">ID</span><span class="o">></span> <span class="o">{</span>
<span class="k">default</span> <span class="nc">Optional</span><span class="o"><</span><span class="no">T</span><span class="o">></span> <span class="nf">resolve</span><span class="o">(</span><span class="nc">Association</span><span class="o"><</span><span class="no">T</span><span class="o">,</span> <span class="no">ID</span><span class="o">></span> <span class="n">association</span><span class="o">)</span> <span class="o">{</span>
<span class="k">return</span> <span class="nf">findById</span><span class="o">(</span><span class="n">association</span><span class="o">.</span><span class="na">getId</span><span class="o">());</span>
<span class="o">}</span>
<span class="k">default</span> <span class="no">T</span> <span class="nf">resolveRequired</span><span class="o">(</span><span class="nc">Association</span><span class="o"><</span><span class="no">T</span><span class="o">,</span> <span class="no">ID</span><span class="o">></span> <span class="n">association</span><span class="o">)</span> <span class="o">{</span>
<span class="k">return</span> <span class="nf">resolve</span><span class="o">(</span><span class="n">association</span><span class="o">).</span><span class="na">orElseThrow</span><span class="o">(</span>
<span class="o">()</span> <span class="o">-></span> <span class="k">new</span> <span class="nc">IllegalArgumentException</span><span class="o">(</span>
<span class="nc">String</span><span class="o">.</span><span class="na">format</span><span class="o">(</span><span class="s">"Could not resolve association %s!"</span><span class="o">,</span> <span class="n">association</span><span class="o">)));</span>
<span class="o">}</span>
<span class="o">}</span></code></pre></figure>
<p><code class="language-plaintext highlighter-rouge">AggregateLookup.findById(…)</code> is essentially equivalent to <code class="language-plaintext highlighter-rouge">CrudRepository.findById(…)</code> which is not a coincidence.
<code class="language-plaintext highlighter-rouge">AssociationResolver</code> exposes methods that resolve the <code class="language-plaintext highlighter-rouge">Association</code> via the <code class="language-plaintext highlighter-rouge">findById(…)</code> method using the association’s exposed identifier.
This allows a <code class="language-plaintext highlighter-rouge">CustomerRepository</code> to look like this and work out of the box without any further changes.</p>
<figure class="highlight"><pre><code class="language-java" data-lang="java"><span class="kd">interface</span> <span class="nc">Customers</span> <span class="kd">extends</span>
<span class="n">o</span><span class="o">.</span><span class="na">s</span><span class="o">.</span><span class="na">d</span><span class="o">.</span><span class="na">r</span><span class="o">.</span><span class="na">Repository</span><span class="o"><</span><span class="nc">Customer</span><span class="o">,</span> <span class="nc">CustomerId</span><span class="o">>,</span>
<span class="nc">AssociationResolver</span><span class="o"><</span><span class="nc">Customer</span><span class="o">,</span> <span class="nc">CustomerId</span><span class="o">></span> <span class="o">{</span> <span class="err">…</span> <span class="o">}</span>
<span class="nc">Order</span> <span class="n">order</span> <span class="o">=</span> <span class="err">…</span> <span class="c1">// obtain order</span>
<span class="nc">Customers</span> <span class="n">customers</span> <span class="o">=</span> <span class="err">…</span> <span class="c1">// obtain repository</span>
<span class="nc">Optional</span><span class="o"><</span><span class="nc">Customer</span><span class="o">></span> <span class="n">customer</span> <span class="o">=</span> <span class="n">customers</span><span class="o">.</span><span class="na">resolve</span><span class="o">(</span><span class="n">order</span><span class="o">.</span><span class="na">getCustomer</span><span class="o">());</span></code></pre></figure>
<p>Note, how <code class="language-plaintext highlighter-rouge">Customers</code> is a standard Spring Data repository and we can easily, explicitly resolve associations to other aggregates via their repositories.</p>
<p><a name="open-questions"></a></p>
<h3 id="open-questions-and-outlook">Open questions and outlook</h3>
<p><strong>Would the interfaces something you’d be willing to let your domain code depend on?</strong> – I know this is an extremely controversial topic.
There’s a group of people that doesn’t bother at all and that would’ve happily depended on such interfaces if they were part of e.g. Spring Data.
Others are rightfully concerned about keeping their domain model as independent of technology aspects as possible.
However, there is a middle ground.
If you think about it: implementing your domain model in a programming language is technical coupling as well.
Using date abstractions in your model is, using e.g. the money APIs is.
I think that one can argue that it’s okay to depend on some technology if the library depended on is <em>focussed</em> and the effort to remove it is small.
What we have here is a set of interfaces that allows us to make DDD concepts explicit that previously had been implicit.
That’s just in line with the spirit of DDD in the first place.</p>
<p><strong>Is requiring <code class="language-plaintext highlighter-rouge">Identifier</code> to restrictive?</strong> — The generics bounds to <code class="language-plaintext highlighter-rouge">ID extends Identifier</code> eliminate the possibility to use simple types (<code class="language-plaintext highlighter-rouge">Long</code>, <code class="language-plaintext highlighter-rouge">UUID</code>) as identifiers.
While this is intentional to some degree it might also be considered too invasive.</p>
<p><strong>Is the persistence setup too confusing?</strong> — while the concept specific defaulting is nice, it also might create some confusion, especially to developers that are used to seeing JPA annotations.
“How is this working at all?” is a question likely to come up easily.
What do the new defaults look like?</p>
<p><strong>Further persistence technology integration</strong> — It might make sense for other persistence integrations to also provide mapping defaults based on rules applicable to DDD building blocks.
This could mean both other ByteBuddy plugins but also the optional inspection of the building block interfaces to reason about the model.</p>
<p><strong>Build integration</strong> — While integrating the defaulting via ByteBuddy works well, it feels bit awkward to see nothing happen if everything goes well, which might just be something to get used to.
Errors result in failing builds on the command line, which is fine.
The integration with Eclipse however has some issues: first, the ByteBuddy Maven plugin is currently not running by default because apparently it’s lacking the metadata necessary for m2e to know what to do.
You can get this to work by tweaking the m2e lifecycle mappings file adding the following configuration block:</p>
<p><em>Declaring the ByteBuddy Maven plugin</em></p>
<figure class="highlight"><pre><code class="language-xml" data-lang="xml"><span class="nt"><pluginExecution></span>
<span class="nt"><pluginExecutionFilter></span>
<span class="nt"><groupId></span>net.bytebuddy<span class="nt"></groupId></span>
<span class="nt"><artifactId></span>byte-buddy-maven-plugin<span class="nt"></artifactId></span>
<span class="nt"><versionRange></span>[0.0.1,)<span class="nt"></versionRange></span>
<span class="nt"><goals></span>
<span class="nt"><goal></span>transform<span class="nt"></goal></span>
<span class="nt"></goals></span>
<span class="nt"></pluginExecutionFilter></span>
<span class="nt"><action></span>
<span class="nt"><execute></span>
<span class="nt"><runOnIncremental></span>true<span class="nt"></runOnIncremental></span>
<span class="nt"></execute></span>
<span class="nt"></action></span>
<span class="nt"></pluginExecution></span></code></pre></figure>
<p>That said, errors in the plugin execution are signaled via a marker on the <code class="language-plaintext highlighter-rouge">pom.xml</code> and the <code class="language-plaintext highlighter-rouge"><execution /></code> element of the plugin declaration.
The hover then contains the stack trace of the exception produced by the plugin. While this is fine, it’s not very convenient.
I’ve filed <a href="https://github.com/raphw/byte-buddy/issues/820">a ticket</a> to ask for improvement.</p>
<p><a name="summary"></a></p>
<h2 id="summarytldr">Summary — tl;dr</h2>
<p>The article described common problems expressing DDD building blocks while designing domain models and directly mapping them onto persistence technology like JPA.
A set of interfaces describing the building blocks as well as their relationships was suggested potentially shipped as a library.
Improved JPA default mappings based on those building blocks were implemented using a ByteBuddy <code class="language-plaintext highlighter-rouge">Plugin</code>.
Additional Spring Data integration was suggested to make it easy to resolve associations between aggregates explicitly.</p>
<p>The library and sample code lives in this <a href="https://github.com/odrotbohm/jddd">GitHub repository</a>.
Binaries currently available from the <a href="https://repo.spring.io/libs-snapshot/org/jddd">Spring Artifactory repository</a>:</p>
<figure class="highlight"><pre><code class="language-xml" data-lang="xml"><span class="nt"><repositories></span>
<span class="nt"><repository></span>
<span class="nt"><id></span>spring-libs-snapshot<span class="nt"></id></span>
<span class="nt"><url></span>https://repo.spring.io/libs-snapshot<span class="nt"></url></span>
<span class="nt"></repository></span>
<span class="nt"></repositories></span>
<span class="nt"><dependencies></span>
<span class="nt"><dependency></span>
<span class="nt"><groupId></span>org.jddd<span class="nt"></groupId></span>
<span class="nt"><artifactId></span>jdd-core<span class="nt"></artifactId></span>
<span class="nt"><version></span>0.0.1-SNAPSHOT<span class="nt"></version></span> <span class="c"><!-- Replace with current version if needed --></span>
<span class="nt"></dependency></span>
<span class="nt"></dependencies></span></code></pre></figure>
<p>Looking forward to your feedback, questions and comments!</p>
Evolving Distributed Systems2016-10-09T13:25:00+02:00http://www.odrotbohm.de/2016/10/evolving-distributed-systems
<p>I’ve recently been pulled into <a href="https://twitter.com/olivergierke/status/782958179391004672">a discussion</a> about the effect of contracts in distributed systems both technically and regarding team communication.
As usual, 140 characters are quite a limitation for reasonable discussion I thought I’d summarize my ideas here.</p>
<p><a name="context"></a></p>
<h2 id="where-do-we-come-from">Where do we come from?</h2>
<p>Let’s get the elephant out of the room: everyone is talking about microservices these days.
Just like so many others, I’ve never been a fan of the term, as it implies a focus on <em>size</em> and <em>small</em>.
While there are definitely <a href="https://vimeo.com/148843366">advantages to smaller</a> — but that raises the question: “Smaller than what?”
We need to come up with a proper context.
Assuming we’re about to ship the same amount of functionality, the smaller the systems, the more of them we usually have to deal with.
That in turn creates new and most certainly <em>different</em> challenges — both organizationally and from a systems architecture point of view.</p>
<p>I usually prefer to speak of “a system of systems”.
I don’t care much about size for the sake of size if a system meets its functional and non-functional requirements.
It’s interesting to observe people assuming a system on the one side of the size spectrum (i.e. a single, monolithic application) is fundamentally flawed and problematic per se, but hardly anyone looks a the risks and negative side effects of potentially over-dividing a system.</p>
<p>So let’s stay with the assumption that we build a system of systems and let’s take a look of the effects on the architecture of such a division.</p>
<p><a name="inter-systems-communication"></a></p>
<h2 id="effect-on-inter-system-communication">Effect on inter-system communication</h2>
<p>If a system is comprised of systems in turn, a crucial aspect of the overall architecture is if and how the individual systems communicate with each other.
The approach I usually see here is that they expose APIs — usually HTTP & JSON (aka. street-REST) based — and a request they serve involves actively reaching out to other services in the system.</p>
<p>This approach has a couple of important effects: a user request to the overall system causes quite a few internal requests, systems calling other systems, which — without any mitigating means — causes latency to pile up.
Also, a lot of API surface has to be created and maintained which usually causes the teams to slow down as changes have to be synchronized, API “versions” are created (which <a href="https://www.infoq.com/news/2013/12/api-versioning">creates effort</a>).
More on that below.</p>
<p>To mitigate the former, a quick technical answer is found: communication needs to be done asynchronously and in a reactive way.
Even with that in places use of HTTP and REST in general is deemed inappropriate and especially non-performant, so that “more efficient”, usually more RPC-style communication protocols are recommended.
There’s a certain irony in the latter, as most usage of HTTP I usually see, follows RPC mechanisms more than it does follow REST constraints in the first place and it’s weird to see people hope to avoid getting the effects of RPC-style communication when they use HTTP RCP-style.</p>
<p><a name="solving-the-right-problem"></a></p>
<h2 id="are-we-solving-the-right-problem">Are we solving the right problem?</h2>
<p>Let’s take a step back and think about what our architecture was supposed to support in the first place: we wanted to achieve business agility.
We wanted to build software around business teams and features, so that can ship new functionality <em>without having to wait for other teams</em>.
This means, when defining our systems architecture, we need to enable the individual systems to evolve <em>independently</em> of the others, too, right?</p>
<p>The first question we can raise here is, whether it is a good idea to let the systems communicate a lot, as communication means we need to agree on an API in the first place, which in turn creates coupling.
The least coupling of systems is achieved amongst the ones that don’t speak to each other at all, which basically boils down to the first law of distributed computing: don’t do it.</p>
<p>Also note how the over-partitioning of the system described above results in the requirement of evolvability — the primary driver behind our architecture — getting intermingled with the aspect of efficiency.
To a large degree, low coupling and efficiency are contradicting requirements in the first place.
This seems to indicate that we should try to avoid the separation in places where efficiency is concern of great priority.</p>
<p><a name="scs"></a></p>
<h2 id="self-contained-systems-scs">Self-Contained Systems (SCS)</h2>
<p>An interesting approach to the separation of a system into systems are <a href="http://scs-architecture.org/">Self-Contained Systems (SCS)</a>.
The fundamental idea of SCS is simple: you comprise a systems of web-applications per a <a href="http://martinfowler.com/bliki/BoundedContext.html">Domain-Driven Design Bounded Context</a>, i.e. the primary separation aspect is business capabilities.
Technical separation is a downstream concern (potentially using even smaller microservices) and can be used <em>within</em> an SCS but it’s regarded an implementation detail.</p>
<p>Here is the most crucial aspects of SCS within the current context of discussion:
Self-Contained Systems strictly try to avoid inter-systems communication when serving user requests, which means they act on local (potentially replicated) data only and rather expose events potentially relevant to other parties instead of notifying them explicitly.
Inter-systems communication can be implemented separately using messaging or the scheduled pulling of events from other systems.</p>
<p>What seems like a quite strict and limiting restriction in the first place has an important upside: it alone removes — or at least mitigates — a lot of the downstream problems that had to be handled in the unrestricted approach described above.
Not having to deal with the accumulated latency and perceived poor performance of inter-process calls, we can now concentrate on the aspect of our architecture that we considered most important in the first place: independent evolvability.</p>
<p><a name="api-evolution"></a></p>
<h2 id="api-evolution">API evolution</h2>
<p>Let’s assume we have two systems (potentially SCS) that we decided need to talk to each other.
When designing the inter-systems communication and deciding for a particular technology we again need to think about the fundamental goal of the separation in the first place: independent evolvability.</p>
<p>What does independent evolvability actually mean? Fundamentally, it means that we’re able to deploy a new version of one of the participants — don’t mix up “version” with “API version” here, I’ll get to that in a second — without breaking the other.
That means, the ability to change either side of the communication without turning that into a breaking change is a key aspect in the design and choice of technology for such communication.</p>
<p><a name="rest"></a></p>
<h2 id="rest">REST</h2>
<p>If you read up on Roy’s thesis and the <a href="https://www.ics.uci.edu/~fielding/pubs/dissertation/web_arch_domain.htm#sec_4_1">requirements the World Wide Web imposed on its architecture</a>, you’ll find that it basically reads like a description for the requirements imposed on micro-service architectures.
That shouldn’t be a surprise as the web is basically the most distributed system ever built in the first place.
Turn that around and you’ll realize that it might not be bad to follow the ideas of the web when building a distributed system that’s supposed to scale and evolve.</p>
<p>Evolvability is a key aspect of the architectural style REST:</p>
<blockquote>
<p>…, extensibility allows us to avoid getting stuck forever with the limitations of what was deployed.
Even if it were possible to build a software system that perfectly matches the requirements of its users, those requirements will change over time just as society changes over time.
A system intending to be as long-lived as the Web must be prepared for change. — Roy T. Fielding, <a href="https://www.ics.uci.edu/~fielding/pubs/dissertation/web_arch_domain.htm#sec_4_1_2">Architectural Styles and Design of Network-based Software Architectures (Section 4.1.2)</a></p>
</blockquote>
<p>That might raise the question why people complain about it being non-performant and inappropriate for distributed systems?
A pretty obvious observations in most of the claims I see is that people use HTTP in a way that’s more RPC-like than it is REST.
That usually includes ignoring key constraints that are important to the architectural effects REST promises.</p>
<p>In software, an architectural style describes a set of constraints that — if followed — lead to certain traits of a system.
It might be a REST-special thing, but people seem to assume they could get the benefits of it entirely but pick and choose only the constraints that are easy to implement.
Unfortunately, that’s not how it works.
Hypermedia is a required constraint for a REST API, especially, if the pursued effect of applying the style is evolvability.</p>
<p>On the other hand, being the most performant communication has never been a primary driver of HTTP as it favors low coupling and scalability over efficiency.
That doesn’t mean the latter is totally out of scope: there’s caching, there’s compression, there are partial responses, there is support for (binary) media types etc.
Still, these means are shaped in a way they don’t undermine the other traits deemed more important.</p>
<p><a name="crud-apis"></a></p>
<h2 id="the-problem-of-crud-apis">The problem of CRUD APIs</h2>
<p>Let’s be honest, a lot of self-proclaimed REST APIs around these days are basically HTTP based CRUD APIs that expose database content as JSON.
The effect of that is that the documentation and specification of those APIs is very focussed on describing the individual resources and the data fields found in the JSON (Swagger being the most prominent instance of a tool creating incentives to do exactly that).</p>
<blockquote>
<p>The more generic your API, the more coupling you create.</p>
</blockquote>
<p>The motivation for that usually is that this generic approach allows easy client implementations “as they can all just behave the same way” or “it’s the easiest way to talk to a server”.
Also, a lot of the specifics of the data — e.g. the field <code class="language-plaintext highlighter-rouge">status</code> in a representation of an order only being able to contain three different values — are easy to create, generate by inspecting server side code, a service description language etc.
So what is the downside of that?</p>
<ol>
<li>
<p><em>The service looking like that is hardly containing any business value.</em>
It exposes <a href="https://speakerdeck.com/stilkov/wait-what-our-microservices-have-actual-human-users-1?slide=11">data, not business functionality</a>.
There <em>is</em> a client somewhere implementing features, but it’s not on the server.</p>
</li>
<li>
<p><em>If there is some kind of logic — usually at least data validation — it has to be replicated on both the server and the client creating the coupling</em> we so desperately wanted to avoid in the first place as it has to be kept in sync.
If there is some higher-level logic implemented that can be used via the API — a client being able to place an order, submit payment information etc. — it is completely implicit and the functionality to use that has to be implemented by <em>all</em> clients.
Also, it means the clients will have to inspect the payload more closely, which reduces the legroom the server has to actually make changes to it.</p>
</li>
<li>
<p><em>The more your API is considered to provide data only, the more clients want a lot of control over the retrieval.</em>
They want to be very specific about the fields a representation is supposed to return.
They might even be able to formulate detailed predicates to filter collection resources.
Giving in to these incentives is not even a problem per se, you just have to be aware of the consequences.
You create strong coupling between the client and the server.
Your clients might be able to gain a little efficiency but you pay for that with stronger coupling.
Don’t be surprised to run into RPC-like characteristics of your remote communication, if you use HTTP in an RPC style.</p>
</li>
</ol>
<p>To summarize the situation: the more generic you make your API the less value you create with that API, the more coupling you create, as business logic is moved into clients.
That’s something which is not the most intuitive thing to see and something that a lot of developers oversee.</p>
<p><a name="contracts"></a></p>
<h2 id="the-problem-of-contracts">The problem of contracts</h2>
<p>The RPC-style approach to systems interacting then also usually leads to a strong focus on defining contracts between the systems, a desire to generate clients and server stubs so that the interaction can be tested etc.</p>
<p>The idea of a contract between two communicating parties and the management of those contracts is quite a natural one to come to.
It promises reliability and control.
If both parties adhere to the contract, everything’s supposed to work, right?
That’s not even wrong.
However contracts imply a couple of downsides in the very special context we try to apply them in:</p>
<ol>
<li>
<p><em>A contract requires parties to communicate in the first place.</em> Remember that we wanted to evolve systems <strong>independently</strong>?
Once in a contractual agreement, every change has to be signed off by both sides.
We introduce new reasons to talk when we wanted to actually reduce the friction.
I totally acknowledge that the lack of communication might be a problem within an organization in the first place.
However, if that’s the case, introducing something that creates more need to communicate can actually be a counter productive thing.
Just because there’s more to talk about, it doesn’t fix the problem of non-communication in the first place.</p>
</li>
<li>
<p><em>Contracts are often set up in a way that they’re (or try to be) extremely specific, especially on the level of data formats exchanged.</em>
What — if looked at, superficially — sounds like a great idea, can actually be a problem regarding evolvability as it creates incentives for clients to make assumptions they shouldn’t have made in the first place.
If we start documenting all available values a field in the representation can have, the server will never ever be able to change it.
This gets even worse if business rules are formulated based on those detailed descriptions, as it usually leads to clients implementing them that way (inspecting the payload closely), which replicates the business rules already present on the server and thus creates coupling — something we wanted to avoid in the first place.</p>
</li>
<li>
<p>The focus on defining the contract leads to the acceptance that changes to a system can only be implemented in a breaking way.
This usually leads to teams completely ignoring other means to ship those changes because: “Hey, we have contracts!”.
Thus a change in contract leading to what’s called “a version of the API”, which then raises the question how to version it.
Hint: <a href="https://www.infoq.com/articles/roy-fielding-on-versioning">you don’t</a>.</p>
</li>
</ol>
<blockquote>
<p>A problem you can avoid is a problem you don’t have to fix.</p>
</blockquote>
<p>Generally speaking, my biggest problem with contracts is that they lead to the assumption that a change to an API needs to be a breaking one.
It also leads to involved parties completely skipping the question how to bring themselves into a situation (by making architectural and technical decisions) so that much less changes are likely to be breaking ones.
Again, a problem you can avoid is a problem you don’t have to fix.</p>
<p>“Well,” I hear you say, “but there <em>is</em> shared semantics.
We have to agree on something, right?”
Exactly!
I don’t dispute that fact, and I also don’t dispute that it’s a good thing to to come up with some sort of contract in the first place.
I criticize two things: people overseeing the negative implications (or at least the effects subverting the original idea of the architecture) and blindly turning it into a tools problem: “Oh, I can generate this from that and I’ll be done.”
Often times, tooling hides the negative effects it imposes its outcome by dazzling users with ease of applicability and fancy UIs.
If it looks good, it’s got to be good, right?</p>
<p>“Enough chitchat, what do you suggest instead?” — First of all, my core point is that in a system of systems context, you’re better of prioritizing the problem of <em>how to evolve your system in a non-breaking way</em> over the one of how to handle breaking changes: if a change is not a breaking one in the first place, there’s no need for communication when rolling out the feature, there’s no “new version”.
You just ship.
If required, the other party picks up the change asynchronously.
But we were able to decouple the deployments of the system in the first place.</p>
<p>“But <em>I</em> have to deal with breaking changes!” I hear you say.
Fine, I answer.
But I’d still argue a lot of them look like they’re breaking ones, because you’ve so finically painted yourself into a corner by ignoring the means technology exposes to turn your allegedly breaking changes into non-breaking ones.
Which brings me back to the very often overlooked constraint REST brings in that regard: hypermedia.</p>
<p><a name="hypermedia"></a></p>
<h2 id="hypermedia-to-the-rescue">Hypermedia to the rescue</h2>
<p>As mentioned before, the aspect of hypermedia (the presence of links in representations in the first place and its advanced partner Hypermedia As The Engine Of Application State (HATEOAS) is a key constraint within REST to enable evolvability in a system.
The latter is a tool to indicate to clients <em>what</em> they can do with the resource at hand and <em>when</em> — or <em>if</em> at all — they can actually invoke certain functionality.
As I’ve written up a concrete sample for the benefits of that approach in <a href="http://olivergierke.de/2016/04/benefits-of-hypermedia">this blog post</a>, I’d like to concentrate on the effect that this approach has on an architectural level.</p>
<p>First, when using hypermedia, we need to focus on different things when designing and documenting APIs.
Focus less on URLs, URL structures and the last nifty detail of fields in the representation (as that creates coupling).
Focus more on the media type(s) served and the semantics of link relations:</p>
<ul>
<li>What does it mean if a link with a certain name can be found?</li>
<li>Which HTTP method(s) can be used to follow that link?</li>
<li>What do I need to submit as payload?</li>
<li>What do I get as response?</li>
</ul>
<p>We effectively start to document resource <em>types</em>, not individual resources.
In my opinion the very first question is the most important one to answer, as that’s gonna be the answer a client will build its state detection around: instead of inspecting a payload field for a certain value (e.g. <code class="language-plaintext highlighter-rouge">status : "payment expected"</code>), it can inspect the links available to decide whether to offer functionality in the UI (e.g. is the <code class="language-plaintext highlighter-rouge">payment</code> link present?).
That approach shines especially in the area of security: instead of having to teach the client whether it is or is not allowed to do something to the system via a separate chain of requests to the server (did I hear you scream: <em>“INEFFICIENT!”</em>?), you can rather let the server decide whether to advertise that functionality in the first place.
The client just picks up the link if present.
You basically try to reduce as many decisions of the client to a plain “Yes or no?”.</p>
<p>If that’s in place and clients adheres to those rules of not implementing business logic based on business fields in the representation, the server gains a lot more legroom for changes in the first place.
In the best case that might allow us to teach the clients new tricks without having to change it in the first place, e.g. if a link shows up in a certain resource state the client didn’t explicitly expect it to appear but then just picks it up (again, please refer to the <a href="http://olivergierke.de/2016/04/benefits-of-hypermedia">other blog post</a> discussing the hypermedia example in detail).
However, remember that automatically learning new trick wasn’t our primary goal in the first place, but being able to redeploy changed systems without breaking others.
The most important bit here is that we avoid to document details of the API that create incentives to strongly couple the clients to those details.
More information, more details often times is worse.</p>
<p>That’s one of the reasons I am very critical with self-proclaimed REST (when they actually mean HTTP) design and description languages like RAML or Swagger.
Trying to be both at the same time — specification of what the server should be <em>and</em> documentation to the client — they intermingle concerns and create a lot of incentives to expose implementation details to clients.
Information that clients then make use of and by that tightly couple themselves to the server.
Even worse, they create a kind of coupling that the designer or user of the described API might not even be aware of and which might not even be necessary.
Some information might have ended up in the description to support the server implementation but eventually ends up in the client.</p>
<p><a name="tl-dr"></a></p>
<h2 id="tldr">tl;dr</h2>
<p>To build an evolvable distributed system you want to get away with <em>just enough</em> inter-systems specification, not with <em>as much as tools can easily generate</em>.
You want to focus on the ability to make non-breaking changes over handling breaking ones.
You want to avoid the need for communication, not create incentives to increase it.</p>
The Benefits of Hypermedia APIs2016-04-29T13:01:00+02:00http://www.odrotbohm.de/2016/04/benefits-of-hypermedia
<p>Recently, I stumbled over a <a href="http://blog.jonathanchannon.com/2016/04/28/what-is-a-hypermedia-client/">blog post by Jonathan Channon</a> explaining how he got to realize that hypermedia APIs are not some magical thing but rather a pragmatic approach to reduce coupling between services.
Also, I’ve been traveling conferences with a talk on <a href="https://speakerdeck.com/olivergierke/domain-driven-design-and-rest">Domain-Driven Design and REST</a> recently that covers the aspect of hypermedia as well and features an — as I think — rather nice example of how effective hypermedia can be when building distributed systems.
I’ll come back to the example in a bit but let’s start with some fundamentals.</p>
<p><a name="fundamentals"></a></p>
<h2 id="fundamentals">Fundamentals</h2>
<p>REST web services are an especially great fit if you develop a distributed system (client-server being the most simple instance of that) where the individual systems are managed by different parties and have to be deployed independently.
That could be a simple mobile app for your business, or it could be a microservice architecture (especially en vogue these days).
Independent deployability can even an important requirement if the same team manages individual services as it will allow you to roll out new features of an individual system without having to wait for others.</p>
<p>The crucial thing here is, that you want to avoid — or can’t even afford — to have to deploy the interacting systems together.
Thus, breaking APIs is basically a no-go for the server or at least has to be avoided as much as possible.
But when do we get into the state of a “broken API”? Whenever the assumptions the client made before are not met by the server anymore.
We need to make sure the client makes as little assumptions about the server as possible.
Hypermedia allows you to achieve exactly that as a lot of assumptions that you might naïvely code into your client can actually be simplified to the decision “Is a link with the given link relation present or not?”.</p>
<p><a name="an-example"></a></p>
<h2 id="an-example">An Example</h2>
<p>Let me give you a concrete example: the REST in Practice book ships with an example called RESTBucks.
It basically simulates the ordering experience at a coffee shop and takes an order through some kind of life cycle (payment expected, in preparation etc.).
See <a href="https://speakerdeck.com/olivergierke/domain-driven-design-and-rest?slide=49">this diagram</a> (also below) for an overview.
Notice how the order can only be canceled in the payment expected state in this version of the diagram (state transition 3).</p>
<script async="" class="speakerdeck-embed" data-slide="49" data-id="704520fbd3b94c5db6f1a31962ae0774" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
<p>If you now coded a mobile client naïvely, it would probably look for the status field of the JSON payload, check whether it’s “payment expected” and if so, display a button to trigger the request for canceling.</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>GET /orders/4711
{
…,
"status" : "payment expected"
}
</code></pre></div></div>
<p>The client would have to know about the resource to issue the request to, the HTTP method it’s supposed to use and the payload it has to send to the server.
You could even tip your toes into hypermedia and let the client look for the link to find the request target but hypermedia is not going to free the server from knowing about the request method and payload details.
So, what is the problem with that approach of inspecting the representation in such detail?</p>
<p><a name="adapting-to-change"></a></p>
<h2 id="adapting-to-change">Adapting to change</h2>
<p>Assume there are a couple of changed and new requirements coming up:</p>
<ol>
<li>As parts of the payload are intended to be displayed to the user, they’re supposed to be internationlized. So German users would get a “Zur Kasse gehen” instead.</li>
<li>Canceling an order is now also allowed <em>after the drinks have been prepared</em>.</li>
</ol>
<p>If the client is implemented like described above, both of these requirements require the client code to be changed.
This stems from the fact that the client used detailed server side knowledge (allow to cancel in a certain state expressed through a certain value in the payload) and duplicated it in its implementation.
It implicitly created coupling that we were thinking we avoided by using HTTP and JSON.
Bummer!
What could we have done instead?</p>
<p>As I also describe in the talk, using hypermedia is basically about reducing critical decisions in the client to the presence of a link with a certain name in a certain context.
We could’ve just implemented our mobile client that way: whenever the representation of an order contains a <code class="language-plaintext highlighter-rouge">cancel</code> link, we display the corresponding button and trigger the documented HTTP call to issue the cancellation if it’s pressed.</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>GET /orders/4711
{
"_links" : {
"cancel" : "…"
},
"status" : "…",
…
}
</code></pre></div></div>
<p>This fundamentally reduces the knowledge baked into the client to nothing but the presence of the link.
That slight change in the way the client is implemented would’ve made it capable to not break due to a change in the API (1, as it would just forward the value of the field to display to the user) and even pick up a new feature transparently (2, as it would transparently display the button in a completely different state of the order as well).</p>
<p><a name="conceptual-changes"></a></p>
<h2 id="what-have-we-done-effectively">What have we done effectively?</h2>
<script async="" class="speakerdeck-embed" data-slide="52" data-id="a96550a9853d48078257b7ae7f331dfa" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
<p>We basically traded two different kinds of complexity here. The naive approach described in the beginning of the post lets the system end up in the left part of the spectrum as adds semantics to certain parts of the payload and by that replicates business logic already implemented on the server.
That duplication across system boundaries is what effectively creates the coupling which we have to avoid to make sure we can roll out changes to the server easily.
That said, this reduction in coupling doesn’t come for free: we paid for it by slightly increasing the protocol knowledge (the client knowing about the media type, how to find links, knowing the semantics of the link relations).</p>
<p>So we actually make the client dumber and smarter at the same time: dumber about the business rules and smarter about the protocol.
That’s a great trade-off as the protocol semantics are much less likely to change in comparison to the business rules, which effectively makes the client less brittle against changes on the server and thus allows the latter to change more significantly without breaking the client.</p>
<p>That said, please check out <a href="http://blog.jonathanchannon.com/2016/04/28/what-is-a-hypermedia-client/">Jonathan’s article</a> in which he outlines how important it is that clients really embrace hypermedia to use it for their benefits and that it’s not enough for servers to just serve hypermedia enabled representations.</p>
<p><a name="changelog"></a></p>
<h3 id="changelog">Changelog</h3>
<p>2016-08-07: Added a paragraph to elaborate on the conceptual differences of the approaches and the architectural consequences on system coupling. Minor wording updates for the previously existing content.</p>
Why field injection is evil2013-11-22T14:17:00+01:00http://www.odrotbohm.de/2013/11/why-field-injection-is-evil
<p>I’m quite frequently getting pulled into discussions on Twitter about the different flavors of <a href="http://en.wikipedia.org/wiki/Dependency_injection">Dependency Injection</a>. Also, I’ve repeatedly expressed my <a href="https://twitter.com/olivergierke/status/314704198908403713">distaste for field injection</a> but as Twitter is not the right communication channel to give an in-depth rational about my opinion. So here we go.</p>
<p>Let’s discuss this stuff with a bit of (quite generic) context: we want to code a component that has a collaborator. As we know, Dependency Injection is the means to connect the two the apparently easiest way to achieve this is the following:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>class MyComponent {
@Inject MyCollaborator collaborator;
public void myBusinessMethod() {
collaborator.doSomething();
}
}
</code></pre></div></div>
<p>So what’s wrong with this code?</p>
<h2 id="its-nullpointerexceptions-begging-to-happen">It’s NullpointerExceptions begging to happen</h2>
<p>Well, first of all it’s broken by default. What’s the API you get to create instances of this class which you will need in your unit test?</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>MyComponent component = new MyComponent();
component.myBusinessMethod(); // -> NullPointerException
</code></pre></div></div>
<p>The core of the problem here is that code you’ve written allows clients to create instances of the class in an invalid state. The whole purpose of a type is clients being able to rely on the invariants it enforces. It’s one of the reasons you use an <code class="language-plaintext highlighter-rouge">EmailAddress</code> type over a plain <code class="language-plaintext highlighter-rouge">String</code> to represent email adresses in your code: clients can be sure the instance they get is a valid email address as the value object enforces this constraint during construction. A <code class="language-plaintext highlighter-rouge">String</code> can potentially be anything, validated or not - how do you know?</p>
<p>So you can probably guess what this is heading to: constructor injection. Let’s rewrite the code shown before in a way it actually enforces the traits I just outlined:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>class MyComponent {
private final MyCollaborator collaborator;
@Inject
public MyComponent(MyCollaborator collaborator) {
Assert.notNull(collaborator, "MyCollaborator must not be null!");
this.collaborator = collaborator;
}
public void myBusinessMethod() {
collaborator.doSomething();
}
}
</code></pre></div></div>
<p>“Ohh boy!”, I can hear you say, “So much boilerplate code!”. Let me get back to this argument in a bit and just recap, what we’ve achieved:</p>
<ol>
<li><em>You can only create instances of <code class="language-plaintext highlighter-rouge">MyComponent</code> by providing a <code class="language-plaintext highlighter-rouge">MyCollaborator</code></em>. You <em>force</em> clients to provide mandatory dependencies, making sure every object created is in a valid state after construction.</li>
<li><em>You communicate mandatory dependencies publicly.</em> Remember when we bashed service locators for hiding dependencies in the implementations? Field injections is just lipstick on the pig in that regard. You still don’t know about the dependencies just looking at the public interface of the type (e.g. while skimming the JavaDoc). Especially if you share code amongst projects field injection based types become a “run-and-wait-for-the-NPE-to-happen,-declare-missing-beans-and-repeat” kind of approach.</li>
<li><em>Final fields also add to the immutable nature application components get.</em> You can clearly distinguish between mandatory dependencies (<code class="language-plaintext highlighter-rouge">final</code>) and optional ones (non-<code class="language-plaintext highlighter-rouge">final</code>) usually injected through setter injection.</li>
</ol>
<p>An often faced argument I get is: “Constructors just get too verbose if I have 6 or 7 dependencies. With fields only, this is fine”. Awesome, you’ve effectively worked around a clear indicator that the code you write is doing way too much. An increase in the number of dependencies a type has <em>should</em> hurt, as it makes you think about whether you should split up the component into multiple ones. You want to really cure the pain, not blindly apply pain killers to it, don’t you?</p>
<h1 id="testability">Testability</h1>
<p>Coming back to the amount of code to be written for the constructor injection based variant. Assuming we sticked to the field injection variant, we would have much less code to write, right? Well, I guess you’re writing tests for your code, right? So how do you actually inject a dependency into your component while testing?</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>MyCollaborator collaborator = … // mock dependency
MyComponent component = new MyComponent();
// Inject dependency by some reflection magic
component.myBusinessMethod();
</code></pre></div></div>
<p>Reflection is the answer here, fine. No matter how comfortable you make this by using a helper method or the like, it’s still a messy workaround isn’t it? Especially if the alternative to that is a simple:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>MyCollaborator collaborator = … // mock dependency
MyComponent component = new MyComponent(collaborator);
component.myBusinessMethod();
</code></pre></div></div>
<p>You get code completion on the constructor call and when you add a dependency to the type under test, refactoring applies, no unset dependencies etc.</p>
<h1 id="boilerplate-buster-lombok">Boilerplate buster Lombok</h1>
<p>Admittedly I’ve been turned off by the amount of code to be written for constructor injection in the first place as well. This is clearly a shortcoming of Java as a languages. Unfortunately a lot of good OO practices like value objects, favoring delegation over inheritance and constructor DI are significantly easier to implement in languages like Scala.</p>
<p>However, <a href="http://projectlombok.org/">Project Lombok</a> is a really awesome helper to reduce the amount of boilerplate you have to write to do “the right things” (™). There’s a ton of helpful features in Lombok but I want to concentrate on the one related to the discussion here. With Lombok the constructor DI based variant of my component up there would look something like this:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>@RequiredArgsConstructor(onConstructor = @__(@Inject))
class MyComponent {
private final @NonNull MyCollaborator collaborator;
public void myBusinessMethod() {
collaborator.doSomething();
}
}
</code></pre></div></div>
<p>The <code class="language-plaintext highlighter-rouge">@RequiredArgsAnnotation</code> will cause a constructor being added during the compilation process taking all final fields as parameters. The additional <code class="language-plaintext highlighter-rouge">@NonNull</code> annotation will cause the parameter be checked for <code class="language-plaintext highlighter-rouge">null</code> as well. The weird looking <code class="language-plaintext highlighter-rouge">onConstructor</code> is Lombok’s way of letting you add annotations to the constructor generated. So with an additional annotation you effectively get the API we’re looking for.</p>
<p>To summarize, here are the results of the comparison that I get to:</p>
<h3 id="field-injection">Field injection:</h3>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>++ less code to write
-- unsafe code
- more complicated to test
</code></pre></div></div>
<h3 id="constructor-injection">Constructor injection:</h3>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>++ safe code
- more code to write (see the hint to Lombok)
+ easy to test
</code></pre></div></div>
666 - Hell not found2013-09-20T20:16:00+02:00http://www.odrotbohm.de/2013/09/666-hell-not-found
<p>Yesterday evening, a few tweets made it into my Tweetbot column listening to tweets related to Spring Data. The one raising my attention was pointing to a blog post creatively entitled “<a href="http://movingfulcrum.tumblr.com/post/61693014502/spring-data-and-mongodb-a-mismatch-made-in-hell">Spring Data MongoDB - A Mismatch Made In Hell</a>”. As the title already suggests, it contains a rather rigid critique of the features and design approaches we chose for the MongoDB module in the Spring Data project. The post has a very harsh tone and is equipped with a whole bunch of either deep misconceptions or deliberate refusal to see facts, which I found quite surprising. Let me go through it bit by bit and clear the dust it created.</p>
<p>But let’s start with the blog post:</p>
<blockquote>
<p>The Spring guys love to tout their support for MongoDb as an advantage over frameworks like JEE. However, using it in a real life project shows how severely lacking and fundamentally mis-designed the framework is. Spring Data MongoDB tries to shoehorn an ORM style strictness to a fundamentally non-relational database, resulting in it being rendered useless in real life.</p>
</blockquote>
<p>Quite an intro, right? Rest assured, the tone doesn’t get any less aggressive throughout the post. Having that said, what’s more important to me here is that it would’ve been tremendously helpful to what this ORM-style strictness is, that we impose onto users. Just to give you an impression, here’s what it looks like to persist a raw <code class="language-plaintext highlighter-rouge">String</code> or MongoDB <code class="language-plaintext highlighter-rouge">DBObject</code> using our <code class="language-plaintext highlighter-rouge">MongoTemplate</code>:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>String document = "{'firstname' : 'Dave', 'lastname' : 'Matthews'}";
template.save(document, "myCollection");
DBObject document = new BasicDBObject();
document.put("firstname", "Dave");
document.put("lastname", "Matthews");
template.save(document, "myCollection");
template.findAll(Map.class, "myCollection")
</code></pre></div></div>
<p>Not very ORMish, right? You don’t even need types to persist data and get it out of the store again. “What is <code class="language-plaintext highlighter-rouge">MongoTemplate</code> then even good for?”, you might ask. First, you <em>can</em> make use of the extensive object-to-store mapping we provide if you like to. However, even if you opt out of that, what you definitely get is appropriate resource mapping and exception translation from MongoDB specific exceptions into Spring’s <code class="language-plaintext highlighter-rouge">DataAccessException</code>s. Just the way Spring developers expect it when using a template provided by us. In general the automatic object-to-store mapping is one of the key reasons developers use Spring Data MongoDB over the raw driver, but let’s go on…</p>
<h2 id="cant-retrieve-fields---full-document-only">Can’t retrieve fields - Full document only</h2>
<blockquote>
<p>This is the biggest indicator of how flawed Spring Mongo’s design is. It tries to model documents like rows in a SQL database and wants you to make ‘entity’ classes like an ORM. Guess what, the two are not the same. A document can be far more complex and larger than a typical row in sql database.</p>
</blockquote>
<p>So first of all - no we don’t. As indicated above it’s perfectly fine to use Spring Data MongoDB with plain <code class="language-plaintext highlighter-rouge">Map</code>s or <code class="language-plaintext highlighter-rouge">DBObjects</code>. However, writing Java application, developers are used to interact with types to write type safe code. Hence it’s an extremely valuable feature to be able to get the documents retrieved from the store mapped onto domain classes automatically. A friendly reminder: an entity is not a concept tied to ORM. Feel free to read up on this in Eric Evans’ “Domain Driven Design” - a highly recommended book anyway.</p>
<blockquote>
<p>With a row in a sql db, it is assumed that you will pull out all of it on most queries, otherwise the data is usually split in multiple tables. But documents are a different beast. Documents are nested within each other, and most of the time you only want to pull out a small subset of it from your database.</p>
<p>But with Spring Mongo’s ‘entity’ modelling, you are forced to pull out your entire document on each query.</p>
</blockquote>
<p>I am terribly sorry, but this is wrong again. There are a few ways to skin the cat here: first of all, on the reading side, you’re not forced to use the same types as you might have used when writing the data. So it’s perfectly fine to persist a <code class="language-plaintext highlighter-rouge">Person</code>, but trigger a query for <code class="language-plaintext highlighter-rouge">PersonSummary</code> and which only consists of firstname, lastname and email address.</p>
<p>The second approach is just staying with <code class="language-plaintext highlighter-rouge">Person</code> but equip the <code class="language-plaintext highlighter-rouge">Query</code> instance you use with a field spec to in- or exclude the fields you’d like:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>Query query = new Query().fields().include("firstname").include("lastname");
template.find(query, Person.class);
</code></pre></div></div>
<p>This would essentially populate only the <code class="language-plaintext highlighter-rouge">firstname</code> and <code class="language-plaintext highlighter-rouge">lastname</code> field of the type handed into the template.</p>
<h2 id="no-dbref-lazy-loading">No DBRef lazy loading</h2>
<blockquote>
<p>This one is pure insane.</p>
</blockquote>
<p>At this point I got used to the cursing :).</p>
<blockquote>
<p>If you use a DBRefs to refer to another document, Spring Mongo will pull out the entire document, instead of just the reference. So if you have a bunch of documents connected to each other via dbrefs, a small query where you really only want to access a couple fields will end up pulling out the entire document graph!</p>
</blockquote>
<p>If you have a lot of documents related to each other, there are two things to consider here: first, I’d raise the question if MongoDB is the right store for this kind of data. The argument feels a bit like a “It’s frickin’ complicated to store a tree in a relational database. JDBC is awful!”. Maybe have a look into Neo4j for highly interconnected data.</p>
<blockquote>
<p>The fact that the bug report on this is almost 2 years old and has been assigned a ‘minor’ status with no resolution in sight is mindboggling, and shows how misaligned Spring Mongo’s visions are with its usage in the real world.</p>
</blockquote>
<p>Admittedly <a href="https://jira.springsource.org/browse/DATAMONGO-348">DATAMONGO-348</a> has been open for quite a while. Still, we’ve seen tons of customer projects working perfectly fine with eagerly loaded <code class="language-plaintext highlighter-rouge">DBRef</code>s or - if that was a problem - simply using manually maintained references. In fact, the MongoDB reference documentation actually recommends <a href="http://docs.mongodb.org/manual/reference/database-references/"><em>not to use DBRefs</em></a> but manual references. So what constitutes the “real world” is a matter of perspective.</p>
<h2 id="no-cursor-support">No cursor support</h2>
<blockquote>
<p>Want to use a cursor to stream and iterate through a collection. No dice. Either pull out the entire collection or fall back to the native Mongo Java driver.</p>
</blockquote>
<p>Exactly! However, what’s so utterly wrong with that? A few lines ago we’ve got complaints about abstracting too much, now we’re back to too little. Here’s how it goes:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>template.execute(new CollectionCallback<Void>() {
Void doInCollection(DBCollection collection) {
DBObject query = new BasicDBObject("lastname", "Matthews");
DBCurson cursor = collection.find(query);
while (cursor.hasNext()) {
// … do something
}
return null;
}
})
</code></pre></div></div>
<p>It’s not really “falling back” but rather using the template mechanisms of resource management and exception translation but still getting access to the driver API to perform operations closer to the store. For plain iterating we have <a href="https://jira.springsource.org/browse/DATAMONGO-203">DATAMONGO-203</a>. It hasn’t got many votes so far but we’re of course happy to implement it.</p>
<h2 id="incomplete-aggregation-framework-support">Incomplete aggregation framework support</h2>
<blockquote>
<p>Spring Mongo only very recently started supporting the Mongo Aggregation framework, and like the rest of Spring Mongo, it is a half hearted effort.</p>
</blockquote>
<p>I’d like to see a list of other Java-based MongoDB libraries that already support the aggregation framework.</p>
<blockquote>
<p>The framework documentation is sparse and confusing and most of your real world aggregation queries wont end up fitting with Spring Mongo’s implementation (not without nonsensical workarounds anyway); forcing you yet again to fall back to the native driver.</p>
</blockquote>
<p><a href="http://docs.spring.io/spring-data/mongodb/docs/current/reference/htmlsingle/#mongo.aggregation">This</a> is the “sparse” documentation about what’s currently implemented. The design of the API has been closely aligned with the examples in the MongoDB reference documentation, made a review round through the MongoDB Java driver development team and has been pre-release applied to a hand full of real world projects where it had worked just fine.</p>
<p>I am not saying the support is perfect, but trying to create the impression it’s the dumbest thing since JPA for NoSQL is a bit off, I think.</p>
<h2 id="incomplete-index-support">Incomplete index support</h2>
<p>I have to admit, I couldn’t make too much sense of that section. Maybe an example would have been helpful here as there seems to be some obvious confusion.</p>
<blockquote>
<p>Spring also has an <code class="language-plaintext highlighter-rouge">ensureIndex()</code> method to manually create indexes on fields, without using annotations, but there are no guidelines whatsoever as to when and how frequently it should be called and what the performance implications of calling it are.</p>
</blockquote>
<p>Spring doesn’t have methods. <code class="language-plaintext highlighter-rouge">MongoTemplate</code> has, the said one in particular. No guidelines? What are the performance implications? We assume basic knowledge of MongoDB indexing but generally speaking the usage of <code class="language-plaintext highlighter-rouge">ensureIndex()</code> is recommended over the use of annotations mostly as you’ll probably like to create the indexes in your app explicitly rather than the mapping sub-system create the them on the fly when you bootstrap the app.</p>
<h2 id="cant-switch-database">Can’t switch database</h2>
<blockquote>
<p>A lot of times you will want to store data in different databases on a single instance of Mongo for things like keeping data of individual customers separate.</p>
<p>With the native Mongo driver, switching between the databases is a simple matter of calling getDb(dbName). With Spring however, this is close to impossible unless you are willing to write a chunk of the framework yourself (which may change underneath you across releases).</p>
</blockquote>
<p>What is described as “close to impossible” here is essentially a <code class="language-plaintext highlighter-rouge">MongoTemplate</code> instance per database you want to interact with. I even described an approach to multi-tenancy with Spring Data MongoDB using our <code class="language-plaintext highlighter-rouge">MongoDbFactory</code> abstraction in a <a href="http://stackoverflow.com/questions/16325606/making-spring-data-mongodb-multi-tenant">post</a> on StackOverflow recently. Not sure you want to get more dynamic than that. By the way, the approach is close to what you get with <code class="language-plaintext highlighter-rouge">AbstractRoutingDataSource</code> in the Spring JDBC world. I’d also argue it’s good practice not to actively reach out for resources from within application code, so hiding this behind configuration and using dependency injection to access such components has been agreed on to be the right way to go for almost a decade.</p>
<p>Regarding the changing APIs: first, I fail to see something utterly hacky is necessary to achieve the flexibility and second we stick to semantic versioning and don’t deliberately break APIs.</p>
<h2 id="surprise-logging-framework">Surprise Logging Framework</h2>
<blockquote>
<p>I have already written about Spring’s documentation issues. The Spring documentation says it uses Jakarta Commons Logging, but Spring Data apparently uses SLF4J. However, the Spring Data documentation makes absolutely no mention of this fact.
This means if you are starting out with Spring Data, your very first experience will consist of a bunch of undocumented runtime errors, which you will figure out only after banging your head for a few hours on Stack Overflow.</p>
</blockquote>
<p>The reason Spring is still on Commons Logging is backwards compatibility and has been <a href="https://spring.io/blog/2009/12/04/logging-dependencies-in-spring">outlined in 2009</a> already. If we started the core framework from scratch we’d use Slf4j. If you write Java software today and still you’re still on Commons Logging, you have quite a different problem anyway. The usage of Slf4j is consistent amongst all the Spring Data modules in the release train.</p>
<p>We don’t explicitly include this in the reference documentation as we strongly recommend to use tools like Maven or Gradle for dependency management. Using those it’s a matter of e.g. <code class="language-plaintext highlighter-rouge">mvn dependency:tree</code> to see what get’s pulled in from where. Explicitly listing dependencies in the reference documentation creates redundancy and increases the risk of inconsistencies which we want to avoid.</p>
<p>I haven’t really heard of people being heavily plagued by runtime errors related to logging when starting with Spring Data modules. Especially if you follow the sample projects or even use Spring Boot to get started finding dependencies is either really simple or even being taken care of for you.</p>
<h2 id="no-support-for-dynamic-nature-of-documents">No support for dynamic nature of documents</h2>
<blockquote>
<p>The biggest reason to use a document-oriented database like MongoDb is for its dynamic nature. Things like the fact that one document can be different from the other, so I can have multiple versions in the same collection and progressively upgrade my users. Documents can be nested. Key names don’t have to be known in advance, so I can insert a map of properties directly into my document.</p>
</blockquote>
<p>I am not sure where this comes from, and would be highly interested what triggered the impression. You can have totally diverse documents in a collection with Spring Data, you can of course nest documents, you can also persist Maps or nested Maps easily. All of these original claims are so utterly and obviously wrong, they really make me wonder how you use Spring Data MongoDB, play with the smallest examples and still come with statements like these. It’s a bit like stating: “The bad thing about the Spring framework is that it doesn’t support transactions.”</p>
<h1 id="conclusion">Conclusion</h1>
<p>In general the entire Spring Data team is very open to feedback from the community - we do our best to regularly answer questions in our forums and on stack overflow, usually have a look at incoming JIRA issues quickly. I can’t remember the blog author to have reached out for support or help in any of those - if I’ve overseen something here, I am sorry. Beyond that, we’ve seen an increasing amount of pull requests being submitted against Spring Data MongoDB recently and we happily go ahead and integrate them. So if there’s really something incredibly missing but important to you, there’s always the option to roll up your sleeves and give the feature a spike.</p>
<p>On a final note: if you’re a software developer ever being so frustrated about a piece of technology, that it makes you want to write a blogpost like the just discussed one - you know you’ve done something wrong. You could have reached out for help, raised your voice way before you reached this level of frustration. I encourage everyone to go ahead and ask questions, file bugs and get in touch with us. We’re eager to get better in any way we can and do our best to continuously improve - the software we write and the processes we work in. Feedback helps, rage posts do not.</p>
Jürgenized2013-03-14T18:16:00+01:00http://www.odrotbohm.de/2013/03/juergenized<table>
<tbody>
<tr>
<td>*Jürgenization</td>
<td>noun</td>
<td>jərgenajzeʃən*</td>
</tr>
</tbody>
</table>
<p>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.</p>
<p>The term originates from <a href="https://twitter.com/springjuergen">Jürgen Höller</a>, 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.</p>
<p>Nowadays the term usually relates to the process of code quality assurance, in particular around Spring eco-system projects.</p>
Websites VS. APIs2013-02-21T00:00:00+01:00http://www.odrotbohm.de/2013/02/websites-vs-apis
<p>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 <a href="http://govdata.de">govdata.de</a>. I put launched in quotation marks as the launch has been a rather rocky one critized <a href="http://www.dw.de/net-activists-slam-germanys-open-data-portal/a-16611003">through out</a> <a href="http://opengovgermany.com/2013/02/04/german-government-screws-up-open-data/">the web</a>.</p>
<p>I in particular made fun of the very verbose <a href="http://www.govdata.de/ckan/api"><code class="language-plaintext highlighter-rouge">api</code></a> resource the portal exposes. If you do a <code class="language-plaintext highlighter-rouge">GET</code> on it all you get returned is a:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>{ "version" : 1 }
</code></pre></div></div>
<p>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 <a href="https://twitter.com/olivergierke/status/304562182350315520">initial tweet</a> caused a bit of response and started some interesting conversation.</p>
<p><a href="https://twitter.com/ischieferdecker">Ina Schiefendecker</a> (I assume to be related to the GovData project as she is working for <a href="http://www.fokus.fraunhofer.de/de/motion/index.html">Fraunhofer FOKUS</a>, responsible for implementing the portal) <a href="https://twitter.com/ischieferdecker/status/304567001819525121">pointed me</a> to the documentation:</p>
<blockquote>
<p>Just have a look: <a href="http://t.co/cA4Q0pXzKQ">http://t.co/cA4Q0pXzKQ</a> or <a href="http://t.co/Qd114XnfbG">http://t.co/Qd114XnfbG</a></p>
</blockquote>
<p>I <a href="https://twitter.com/olivergierke/status/304568799187832832">replied</a> that adding hypermedia elements to the responses would turn the chunks of data into a usable API, which she <a href="https://twitter.com/ischieferdecker/status/304570536229474304">responded</a> to with:</p>
<blockquote>
<p>If you want hypermedia take the portal, if you want to program take the API</p>
</blockquote>
<p>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:</p>
<h4 id="for-the-govdata-team-the-website-is-something-different-than-the-api">For the GovData team the website is something different than the API</h4>
<p>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 <em>and</em> APIs you expose to the web.</p>
<p>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 (<em>sigh</em>), the API with <a href="http://ckan.org/">CKAN</a>. Totally different technology stacks, but does that impose a real conceptual difference to a web site and a web API?</p>
<p>Playing devil’s advocate a bit one now could ask:</p>
<blockquote>
<p>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?</p>
</blockquote>
<p>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 <em>representation design for different client types</em>. Even for <a href="http://roca-style.org/">well designed websites</a> 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 <em>designing representations</em> for clients with different requirements. So here’s what it boils down to:</p>
<blockquote>
<p>Both your website and your API benefit from being considered ‘the same thing’ with different representations.</p>
</blockquote>
<p>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: <strong>if it’s on the web, embrace the web.</strong></p>
<hr />
<p>Edit - 2013-04-30: <a href="https://twitter.com/owolf">Oliver Wolf</a> has a great <a href="https://speakerdeck.com/owolf/turning-passive-apis-into-active-apis">presentation</a> 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.</p>
Whoops! Where did my architecture go2013-01-15T00:00:00+01:00http://www.odrotbohm.de/2013/01/whoops-where-did-my-architecture-go
<p>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 <a href="http://blog.schauderhaft.de/2013/01/13/the-importance-of-packages/">blog post</a> 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 <a href="https://github.com/olivergierke/Whoops-Architecture">GitHub</a>.</p>
<p>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.</p>
<h2 id="divide-and-conquer">Divide and conquer</h2>
<p>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.</p>
<p>As a consequence of that we create artifacts with different (in)stability metrics (see <a href="http://en.wikipedia.org/wiki/Software_package_metrics">Wikipedia</a> for details). This metric essentially expresses the <em>risk of a change</em> 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.</p>
<h2 id="layers">Layers</h2>
<p>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.</p>
<p>Layering is a reasonably understood by developers as it’s decomposes the software system by by a <em>technical aspect</em>. It’s tought in university, probably practitioned in most of the development shops out there. So here’s the interesting question:</p>
<blockquote>
<p>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?</p>
</blockquote>
<p>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.</p>
<h2 id="slices">Slices</h2>
<p>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 <a href="https://speakerdeck.com/olivergierke/whoops-where-did-my-architecture-go-2?slide=10">this slide</a>).</p>
<h2 id="architecture-vs-codebase">Architecture VS. Codebase</h2>
<p>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 <a href="http://www.hello2morrow.com/products/sonargraph">Sonargraph</a> and <a href="http://structure101.com/products/">Structure 101</a> 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?”.</p>
<p>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.</p>
<p>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 <a href="http://blog.schauderhaft.de/2012/01/01/the-one-correct-way-to-do-dependency-injection">post</a> 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.</p>
<p>At this point, I’d like to throw in another question:</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>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.</p>
<h2 id="packages">Packages</h2>
<p>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 <code class="language-plaintext highlighter-rouge">exceptions</code> package is not really reasonable either as it groups types by technical commonalities which usually doesn’t provide any architectural benefit.</p>
<p>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 <a href="https://github.com/olivergierke/Whoops-Architecture/tree/master/packages-before">packages-before project</a> of this GitHub repo:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>….account.domain
….account.presentation
….account.repository
….account.service
….core.domain
….customer.domain
….customer.presentation
….customer.service
….customer.repository
</code></pre></div></div>
<p>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 <code class="language-plaintext highlighter-rouge">account</code> 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.</p>
<p>Second, you see that the core slice does not have code in any of the actual layers, but a <code class="language-plaintext highlighter-rouge">domain</code> 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:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>….customer.domain
+ Customer
….customer.service
+ CustomerManagement
+ CustomerManagementImpl
+ CustomerNumberGenerator
….customer.repository
+ CustomerRepository
</code></pre></div></div>
<p>Assume the following: <code class="language-plaintext highlighter-rouge">CustomerRepository</code> is simply persisting <code class="language-plaintext highlighter-rouge">Customer</code> instances. The core part of the service implementation is generating customer numbers when a new <code class="language-plaintext highlighter-rouge">Customer</code> 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, <code class="language-plaintext highlighter-rouge">CustomerRepository</code> 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 <a href="https://github.com/olivergierke/Whoops-Architecture/tree/master/packages-after">here</a>.)</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>….customer
+ Customer
+ CustomerManagement
o CustomerManagementImpl
o CustomerNumberGenerator
o CustomerRepository
</code></pre></div></div>
<p>We end up with less then a half of public types to manage. <code class="language-plaintext highlighter-rouge">CustomerRepository</code> cannot be used from anywhere else as the Java compiler prevents us from doing so. <code class="language-plaintext highlighter-rouge">CustomerNumberGenerator</code> 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 <a href="https://speakerdeck.com/olivergierke/whoops-where-did-my-architecture-go-2?slide=35">this slide</a> (compare to the slide before to see the difference).</p>
<h2 id="summary">Summary</h2>
<p>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.</p>
Hello World2012-12-16T00:00:00+01:00http://www.odrotbohm.de/2012/12/hello-world
<p>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.</p>
<p>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 <a href="https://twitter.com/olivergierke/status/280345756282523648">research on Twitter</a> I tried <a href="http://jekyllrb.com/">Jekyll</a> and <a href="http://jekyllbootstrap.com">Jekyll Bootstrap</a> in particular. It’s a Ruby-based website or blog generator that’s entirely file-based and (in my case) Markdown-driven.</p>
<p>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.</p>
<p>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.</p>
Spring, logging and JMX2010-10-01T20:16:06+02:00http://www.odrotbohm.de/2010/10/spring-logging-and-jmx
<p>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.</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code><context:mbean-server />
<context:mbean-export />
</code></pre></div></div>
<p>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 <code class="language-plaintext highlighter-rouge">${classname}MBean</code>). Fortunately Log4J ships with a <code class="language-plaintext highlighter-rouge">LoggerDynamicMBean</code> that exports a <code class="language-plaintext highlighter-rouge">Logger</code> 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:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code><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>
</code></pre></div></div>
<p>Running this in combination with the XML snippet above now exposes the logger for org.springframework.jmx as JMX MBean.</p>
<h2 id="xml-hell-go-make-it-clear-and-nice">XML Hell? Go make it clear and nice!</h2>
<p>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 <code class="language-plaintext highlighter-rouge">org.springframework.jmx</code>. So what if we could expose the logger with something like this:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code><jmx:logger type="Log4J" name="org.springframework.jmx" />
</code></pre></div></div>
<p>We can! I’ve created a small <a href="http://github.com/olivergierke/spring-jmx-namespace">sample project</a> 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!</p>
Enabling Hibernate criteria query statistics with AspectJ2010-09-15T20:16:06+02:00http://www.odrotbohm.de/2010/09/enabling-hibernate-critera-query-statistics-with-aspectj
<p>In the <code class="language-plaintext highlighter-rouge">#java.de</code> IRC channel someone pointed me to this <a href="http://opensource.atlassian.com/projects/hibernate/browse/HHH-3452">request for enhancement</a> 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.</p>
<p>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 <code class="language-plaintext highlighter-rouge">CriteriaLoader</code> class, as Chuck May points out. So supposed you want to use this feature <em>now</em>. 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:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>public privileged aspect CriteriaStatisticsAspect {
public String CriteriaLoader.getQueryIdentifier() {
return "[CRITERIA] " + getSQLString();
}
}
</code></pre></div></div>
<p>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 <a href="http://mojo.codehaus.org/aspectj-maven-plugin/">Maven AspectJ plugin</a> to your <code class="language-plaintext highlighter-rouge">pom.xml</code> and tell it to consider the Hibernate JARs too by adding a <code class="language-plaintext highlighter-rouge">weaveDependencies</code> block to the configuration section of the plugin.</p>
<p>To ease the burden of getting started with this approach I have uploaded the <a href="http://github.com/olivergierke/hibernate-criteria-statistics">sample code</a> 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.</p>
Conference autumn 20102010-09-10T20:16:06+02:00http://www.odrotbohm.de/2010/09/conference-autumn-2010
<p>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.</p>
<p>I’ll kick off my conference autumn by speaking at <a href="http://www.webappdays.de/">WebAppDays</a> in Düsseldorf (Sept. 27th/28th) presenting <a href="http://www.springsource.org/roo">Roo</a> as rapid java application development framework as well as giving an overview about <a href="http://www.springsource.com/products/tcserver">tcServer</a>, the SpringSource commercial edition of <a href="http://tomcat.apache.org/">Tomcat</a>. To not make this a marketing talk entirely, I will concentrate on how developers can benefit from tcServer usage during development and in production.</p>
<p>Next stop for me the is <a href="http://gearconf.com/">GearConf</a>, 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 <a href="http://www.eclipse.org/mylyn/">Mylyn</a> and how it can help developers to be more productive and ease context switches.</p>
<p>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.</p>
<p>The main event this autum of course is <a href="http://www.devoxx.com/">Devoxx</a> 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 <a href="http://twitter.com/springjuergen">Jürgen Höller</a> on <a href="http://www.devoxx.com/display/Devoxx2K10/Spring+3.1+-+Themes+and+Trends">Spring 3.1</a>, <a href="http://twitter.com/benalexau">Ben Alex</a> on <a href="http://www.devoxx.com/display/Devoxx2K10/Extreme+Productivity+with+Spring+Roo">Roo</a>, <a href="http://twitter.com/cdupuis">Christian Dupuis</a> on tooling for <a href="http://www.devoxx.com/display/Devoxx2K10/Spring+Developer+Tools+to+push+your+Productivity">Spring</a> and <a href="http://www.devoxx.com/display/Devoxx2K10/Groovy+Grails+Development+in+Eclipse">Grails</a>.</p>
<p>Right in between those events I will promote upcoming Hades 2.0 release at <a href="http://87.230.78.21:8080/display/jugc/2010.11.08+Agile+in+a+Year+und+Hades">JUG Cologne Nov. 8th</a>. 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. :)</p>
<p>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 :)</p>
Hades 2.0.0.RC2 introduces transactional DAOs2010-06-22T20:16:06+02:00http://www.odrotbohm.de/2010/06/hades-2-0-0-rc2-introduces-transactional-daos
<p>Our latest Hades <a href="http://redmine.synyx.org/news/18">release</a> 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.</p>
<p>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. <code class="language-plaintext highlighter-rouge">@Transactional</code> at a Spring MVC controller e.g. which is rather a sub-optimal solution.</p>
<p>So actually we were quite reluctant to the idea of applying transactions to Hades DAO instances as there were some crucial points to consider:</p>
<ol>
<li><em>Actually a DAO layer might not be at the right level of abstraction.</em> Usually you define transactions on a more business related method than a plain <code class="language-plaintext highlighter-rouge">save(…)</code> or <code class="language-plaintext highlighter-rouge">findByUsername(…)</code>. 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.</li>
<li><em>If we apply transactions we don’t want to imply our transaction model to the user’s application.</em> 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.</li>
<li>Although the transactional behavior that we define for CRUD methods might be okay for 90% of the use cases <em>there has to be a way to override the defaults and replace them by some custom one.</em></li>
<li>As Spring 3.0 <em>supports multiple transaction managers</em> via <code class="language-plaintext highlighter-rouge">@Transactional</code> we have to make sure we participate in the right transaction depending on in which context the DAO is used.</li>
<li><em>It has to be easy to define transaction configuration for DAO interfaces</em> containing the finder methods.</li>
</ol>
<p>We decided to use <code class="language-plaintext highlighter-rouge">@Transactional</code> annotations at the <code class="language-plaintext highlighter-rouge">GenericJpaDao</code> implementation class and activate annotation based transactions for the proxies explicitly through the <code class="language-plaintext highlighter-rouge">GenericDaoFactoryBean</code>. 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 <code class="language-plaintext highlighter-rouge">@Transactional</code>, too, or use e.g. XML configuration or even <code class="language-plaintext highlighter-rouge">TransactionTemplate</code>. This gets us solutions for issues 1 and 2.</p>
<p>Issue 5 is quite easy to solve as you can simply annotate the finder methods of your DAO interface (or the interface itself) with <code class="language-plaintext highlighter-rouge">@Transactional</code> and transactions get applied as you are used to with Spring.</p>
<p>The actual tricky part is issue 3. The main idea here is to simply redeclare the CRUD method originally declared in <code class="language-plaintext highlighter-rouge">GenericDao</code> inside your concrete DAO interface and reconfigure transactions as you like. So supposed you want to get rid of the <code class="language-plaintext highlighter-rouge">readOnly</code> flag at <code class="language-plaintext highlighter-rouge">readByPrimaryKey(…)</code> 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:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>public interface UserDao extends GenericDao<User, Long> {
@Override
@Transactional
User readByPrimaryKey(Long key);
}
</code></pre></div></div>
<p>Getting this to work needs some reflection magic as we of course still have to delegate the call to that method to the <code class="language-plaintext highlighter-rouge">GenericJpaDao</code> instance but according to the Java Reflection API it of course does only implement <code class="language-plaintext highlighter-rouge">GenericDao.readByPrimaryKey(…)</code> and not <code class="language-plaintext highlighter-rouge">UserDao</code>. <code class="language-plaintext highlighter-rouge">readByPrimaryKey(…)</code>. 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.</p>
<p>Issue 4 is not that interesting as we simply have to configure our internal <code class="language-plaintext highlighter-rouge">TransactionInterceptor</code> to lookup the appropriate <code class="language-plaintext highlighter-rouge">PlatformTransactionManager</code> instance in a lazy-loading-like fashion but that all happens under the covers and you don’t need to take care of this.</p>
<p>So let me quickly summarize what 2.0.0.RC2 brings you in regard of transactions:</p>
<ul>
<li>Transactional CRUD methods (everything declared in `
GenericDao<code class="language-plaintext highlighter-rouge">) with appropriate defaults (</code>readOnly` flag set to true on read-only methods) that automatically take part in more coarse grained transactions if necessary</li>
<li>The ability to use <code class="language-plaintext highlighter-rouge">@Transactional</code> for your concrete DAO interfaces</li>
<li>The ability to reconfigure the transactional behavior of the CRUD methods by simply redeclaring a method inside the concrete DAO interface</li>
</ul>
Changing a project's artifactId in Sonar2010-06-10T20:16:06+02:00http://www.odrotbohm.de/2010/06/changing-a-projects-artifact-id-in-sonar
<p><a href="http://sonar.codehaus.org/">Sonar</a> is a great tool to take care of code quality in your software projects. I use it heavily to monitor the <a href="http://techqa.synyx.org/">open source projects I am involved with</a>. When working on getting <a href="http://hades.synyx.org/">Hades</a> 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 <code class="language-plaintext highlighter-rouge">hades-parent</code> to <code class="language-plaintext highlighter-rouge">org.synyx.hades.parent</code>. Everything fine until I pushed the metrics of the 1.5.1 release into Sonar.</p>
<p>Sonar created a new project, as it cannot know about my refactoring. So what to do? I spoke to <a href="http://twitter.com/SimonBrandhof">Simon Brandhof</a> and apparently there’s no feature in Sonar to change the artifact id via the user interface. So I opened a <a href="http://jira.codehaus.org/browse/SONAR-1608">JIRA issue</a> for it, feel free to vote for it if you like. Meanwhile we could achieve this by manually altering the <code class="language-plaintext highlighter-rouge">kee</code> column inside the <code class="language-plaintext highlighter-rouge">PROJECTS</code> table. It contains entries of the form <code class="language-plaintext highlighter-rouge">${groupId}:${artifactId}(:${branchName})</code> for entries of type <code class="language-plaintext highlighter-rouge">PRJ</code> (i guess that stands for project. Altering these entries solved the problem.</p>
<p>Thanks to Simon and Verschdl for help!</p>
Hades 1.5 released2010-04-11T20:16:06+02:00http://www.odrotbohm.de/2010/04/hades-1-5-released
<p>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.</p>
<h2 id="why-15">Why 1.5?</h2>
<p>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”?</p>
<p>Since it’s beginning Hades relied on two major interfaces: <code class="language-plaintext highlighter-rouge">GenericDao</code> and <code class="language-plaintext highlighter-rouge">Persistable</code> where as especially the latter raised some discussions <a href="http://redmine.synyx.org/boards/2/topics/8">here</a> 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. <code class="language-plaintext highlighter-rouge">GenericDao</code> had the aim to abstract between creation and updates of objects. Although there slight semantic differences this maps to the difference between using <code class="language-plaintext highlighter-rouge">EntityManager</code> methods <code class="language-plaintext highlighter-rouge">persist(…)</code> and <code class="language-plaintext highlighter-rouge">merge(…)</code>. To know what to call when <code class="language-plaintext highlighter-rouge">save(…)</code> is being called on <code class="language-plaintext highlighter-rouge">GenericDao</code> 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.</p>
<p>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 <code class="language-plaintext highlighter-rouge">null</code>, 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 <code class="language-plaintext highlighter-rouge">isNew()</code> on you instance then. So in effect, the interface comes into play if explicitly needed and not in any other case.</p>
<p>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 <code class="language-plaintext highlighter-rouge">EntityManagerFactory</code> 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 <code class="language-plaintext highlighter-rouge">exclude-filter</code> and <code class="language-plaintext highlighter-rouge">include-filter</code> (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 <code class="language-plaintext highlighter-rouge">Between</code>, <code class="language-plaintext highlighter-rouge">LessThan</code> and <code class="language-plaintext highlighter-rouge">GreaterThan</code> in method names. To round things up we’ve fixed a few minor bugs here and there. For more details read the <a href="http://redmine.synyx.org/versions/show/34">changelog</a> or the updated <a href="http://redmine.synyx.org/attachments/download/96">reference documentation</a>.</p>
<h2 id="hades-20">Hades 2.0</h2>
<p>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.</p>
<p>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 <code class="language-plaintext highlighter-rouge">GenericDao</code> and not blurred with additional interfaces.</p>
<p>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.</p>
Neglected classes in Spring - Part III2010-04-07T20:16:06+02:00http://www.odrotbohm.de/2010/04/neglected-classes-in-spring-part-iii
<p>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:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>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);
}
}
</code></pre></div></div>
<p>Let’s recap what we just have done. First we need to get access to the <code class="language-plaintext highlighter-rouge">ServletContext</code> of the web application. A Spring <code class="language-plaintext highlighter-rouge">WebApplicationContext</code> that was registered by a <code class="language-plaintext highlighter-rouge">ContextLoaderListener</code> will be registered in the <code class="language-plaintext highlighter-rouge">ServletContext</code> under a special name the framework knows, so that <code class="language-plaintext highlighter-rouge">WebApplicationContextUtils</code> can then look it up and hand it out to you to manually retrieve Spring beans from it.</p>
<p>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 <code class="language-plaintext highlighter-rouge">SpringBeanAutowiringSupport</code> which is residing in <code class="language-plaintext highlighter-rouge">org.springframework.web.context.support</code> spending a rather unregarded life. It offers a method <code class="language-plaintext highlighter-rouge">processInjectionBasedOnCurrentContext(Object target)</code> that automatically injects Spring beans to properties of the given target using the usual annotation driven suspects (<code class="language-plaintext highlighter-rouge">@Autowired</code>, <code class="language-plaintext highlighter-rouge">@Resource</code>, <code class="language-plaintext highlighter-rouge">@Inject</code>). So our sample code turns into something like this:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>public class MyServlet extends HttpServlet {
@Inject
private MyService service;
@Override
public void init() {
SpringBeanAutowiringSupport.
processInjectionBasedOnCurrentContext(this);
}
}
</code></pre></div></div>
<p>Done. Note, that we override the init method without the <code class="language-plaintext highlighter-rouge">ServletConfig</code> parameter as the called method looks up the actual <code class="language-plaintext highlighter-rouge">ApplicationContext</code> from a static map held in <code class="language-plaintext highlighter-rouge">ContextLoader</code> which inherits from. If you need to lookup beans from an <code class="language-plaintext highlighter-rouge">ApplicationContext</code> tied to a particular <code class="language-plaintext highlighter-rouge">ServletContext</code> you can use <code class="language-plaintext highlighter-rouge">processInjectionBasedOnServletContext(Object target, ServletContext servletContext)</code> and hand it the appropriate instances.</p>
<p>P.S.: Thanks to <a href="http://jandiandme.blogspot.com/">Eberhard Wolff</a> for pointing me at this.</p>
REST based web applications with Spring 32010-04-01T20:16:06+02:00http://www.odrotbohm.de/2010/04/rest-based-web-applications-with-spring-3<p>Yesterday I gave a talk on REST based web applications with Spring 3.</p>
<iframe src="http://de.slideshare.net/slideshow/embed_code/3610375" width="600" height="489" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" style="border:1px solid #CCC;border-width:1px 1px 0;margin-bottom:1em" allowfullscreen="true" webkitallowfullscreen="true" mozallowfullscreen="true">
</iframe>
<div style="margin-bottom:1em">
<strong>
<a href="http://de.slideshare.net/olivergierke/rest-based-web-applications-with-spring-3" title="REST based web applications with Spring 3">REST based web applications with Spring 3</a>
</strong> from
<strong>
<a href="http://de.slideshare.net/olivergierke">Oliver Gierke</a>
</strong>
</div>
<p>You can also grab the sample code at <a href="http://github.com/olivergierke/spring-rest">GitHub</a>.</p>
New challenges2010-02-10T19:16:06+01:00http://www.odrotbohm.de/2010/02/new-challenges
<p>It’s been official for a few days now, so I thought I could drop a public note about me joining <a href="http://www.springsource.de/">SpringSource Germany (division of VMware)</a> as Senior Consultant beginning March 1st this year. Time to look back on three exciting years at <a href="http://www.synyx.de/">Synyx</a> and an outlook of what’s about to come.</p>
<p>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 <a href="/tags.html#spring-ref">crucial part</a> 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 <a href="http://hades.synyx.org/">Hades</a> that I lead, which is based on Spring and carries Spring principles and values to the domain of easing data access with JPA.</p>
<p>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.</p>
<p>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.</p>
<p>It’s been a pleasure! And it will be…</p>
Neglected classes in Spring - Part II2010-01-24T19:16:06+01:00http://www.odrotbohm.de/2010/01/neglected-classes-in-spring-part-ii
<p>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:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>@RequestMapping(value = "users", method = GET)
public String showUsers(Model model) {
model.addAttribute("users",
userManagement.getUsers());
return "users";
}
</code></pre></div></div>
<p>As you can see we use a parameter of type <code class="language-plaintext highlighter-rouge">Model</code> that will we automatically get an instance handed by Spring. For a complete list of supported parameter and return types see <a href="http://web.archive.org/web/20100207151300/http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/mvc.html#mvc-ann-requestmapping-arguments">Spring reference documentation</a> on that topic.</p>
<p>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.</p>
<h2 id="pagination">Pagination</h2>
<p>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 <code class="language-plaintext highlighter-rouge">PageRequest</code> implementation class. But there is still the question on how to create instances of <code class="language-plaintext highlighter-rouge">PageRequest</code> from an incoming request. A naive might be the following:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>@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";
}
</code></pre></div></div>
<p>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 <code class="language-plaintext highlighter-rouge">WebRequest</code> injected into every controller method that wants to use pagination, which breaks the abstraction level gained.</p>
<p>So what about rather something like this:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>@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
}
}
</code></pre></div></div>
<p>Inside the implementation your first task is to determine, whether you can return the given <code class="language-plaintext highlighter-rouge">MethodParameter</code> or return a <code class="language-plaintext highlighter-rouge">WebArgumentResolver.UNRESOLVED</code>. Our resolver would have to check if the target type is a <code class="language-plaintext highlighter-rouge">Pageable</code> and extract the request parameters then.</p>
<h2 id="accessing-the-current-user">Accessing the current user</h2>
<p>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:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>@RequestMapping(value = "/myaccount", method = GET)
public String showUsers(Model model,
@CurrentUser UserDetails userDetails) {
model.addAttribute("user",
userManagement.getUser(userDetails.getId());
return "user";
}
</code></pre></div></div>
<p>Similar to the plain type based <code class="language-plaintext highlighter-rouge">WebArgumentResolver</code> implementation for <code class="language-plaintext highlighter-rouge">Pageable</code> the implementation here would check for the custom <code class="language-plaintext highlighter-rouge">CurrentUser</code> 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 <code class="language-plaintext highlighter-rouge">UserDetails</code> used as <code class="language-plaintext highlighter-rouge">ModelAttribute</code>, but that depends on the detailed requirements of your application.</p>
<h2 id="summary">Summary</h2>
<p><code class="language-plaintext highlighter-rouge">WebArgumentResolver</code> allows providing your own custom controller method parameters to centralize either lookup or extraction logic, that would otherwise be scattered through your controller code.</p>
Article on Hades in current issue of German JavaMagazin2009-06-04T07:03:20+02:00http://www.odrotbohm.de/2009/06/article-on-hades-in-current-issue-of-german-javamagazin<p>The June issue of the German <a href="http://it-republik.de/jaxenter/java-magazin-ausgaben/EJB-3.0-000304.html">JavaMagzin</a> features an article about <a href="http://www.synyx.org/de/projects/hades.html">Hades</a> written by myself. I sketch out issues implementing persistence layers briefly and introduce solutions to these issues using Hades. Furthermore fellow developer <a href="http://blog.alexander-hanschke.de/">Alexander Hanschke </a>introduced <a href="http://www.majug.de">Java User Group Mannheim</a> in yet another article, too. Check out the current issue and get your copy.</p>
<p>Beyond that, we at Synyx decided to give the part of our homepage that deals with our OpenSource projects a brush up. Check out <a href="http://www.synyx.org">http://www.synyx.org</a> to start diggin into the <a href="http://www.synyx.org/de/projects/">projects</a>, read up our <a href="http://www.synyx.org/de/blogs/">developer’s blogs</a> and keep in touch via the <a href="http://redmine.synyx.org">project tracker</a>. Kudos to <a href="http://bifrost.rei-network.info/blog/">Philip Reiman</a> who did most of the work.</p>
Diggin' into Spring 3 transactional test facilities2009-05-28T20:16:06+02:00http://www.odrotbohm.de/2009/05/diggin-into-spring-3-transactional-test-facilities
<p>Today I devoted my day to a general check in how far Hades can be run with the <a href="http://www.springsource.com/download/community?project="> latest Spring 3 milestone</a>. After managing the typical Maven foo I had a project profile up and running that builds <a href="http://hades.synyx.org">Hades</a> against Spring 3 M3 and executes the tests against it. In case you try to migrate some of your code, too, and wonder where <code class="language-plaintext highlighter-rouge">spring-agent</code> JAR has gone: its <code class="language-plaintext highlighter-rouge">org.springframework.instrument</code> now. But back to topic.</p>
<p>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:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>@Test(expected=DataAccessException.class)
public void checkDoesNotCascadeIfNotConfigured() {
// Setup some persistent object graph that is
// supposed to throw an exception
userDao.saveAndFlush(user);
}
</code></pre></div></div>
<p>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?</p>
<p>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 <a href="https://fisheye.springsource.org/browse/spring-framework/trunk/org.springframework.test/src/main/java/org/springframework/test/context/transaction/TransactionalTestExecutionListener.java?r1=134&r2=655">this commit</a> Jürgen Höller added a <code class="language-plaintext highlighter-rouge">transactionStatus.flush()</code> 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.</p>
<p>As I spoke to <a href="http://blog.springsource.com/author/juergenh/">Jürgen</a> we found out that the flush was implemented due to a <a href="http://jira.springframework.org/browse/SPR-5315">improvement</a> filed in JIRA. Fortunately there is already <a href="http://jira.springframework.org/browse/SPR-5699">another ticket</a> that adresses the issue. Waiting for RC1 to see this fixed…</p>
<p>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.</p>
Using Spring's @Configurable in three easy steps2009-05-25T20:57:53+02:00http://www.odrotbohm.de/2009/05/using-springs-configurable-in-three-easy-steps
<p>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 <a href="http://twitter.com/springrod/status/1905699064">buzz</a> 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.</p>
<h2 id="1-equip-your-domain-class-with-configurable">1. Equip your domain class with <code class="language-plaintext highlighter-rouge">@Configurable</code></h2>
<p>The <a href="http://svn.synyx.org/synyx/opensource/misc/org.synyx.samples.spring.atconfigurable/tags/org.synyx.samples.spring.atconfigurable-0.0.1/src/main/java/org/synyx/samples/spring/atconfigurable/domain/User.java">domain class</a> in the sample is <code class="language-plaintext highlighter-rouge">org.synyx.samples.spring.atconfigurable.domain.User</code>. Note that we can inject the referenced service by just stating an <code class="language-plaintext highlighter-rouge">@Autowired</code> property. No setter needed, no pollution of the domain class’ interface.</p>
<h2 id="2-enable-injecting-capabilities-in-your-configuration-file">2. Enable injecting capabilities in your configuration file</h2>
<p>The maven project I have created states a dependency to spring-context that allows two critical declarations: <code class="language-plaintext highlighter-rouge"><context:spring-configured /></code> activates injection into domain classes not managed by Spring. Note that I use <code class="language-plaintext highlighter-rouge"><context:component-scan /></code> in the <a href="http://svn.synyx.org/synyx/opensource/misc/org.synyx.samples.spring.atconfigurable/tags/org.synyx.samples.spring.atconfigurable-0.0.1/src/main/resources/application-context.xml"><code class="language-plaintext highlighter-rouge">application-context.xml</code></a> to pick up the <code class="language-plaintext highlighter-rouge">User</code> class as well as <code class="language-plaintext highlighter-rouge">GreetingServiceImpl</code> from the service package.</p>
<h2 id="3-enable-load-time-weaving">3. Enable load-time weaving</h2>
<p>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 <code class="language-plaintext highlighter-rouge"><context:load-time-weaver aspectj-weaving="autodetect"/></code> 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 <a href="http://svn.synyx.org/synyx/opensource/misc/org.synyx.samples.spring.atconfigurable/tags/org.synyx.samples.spring.atconfigurable-0.0.1/pom.xml">command line argument</a> for Maven’s Surefire plugin.</p>
<p>This way you can easily enrich domain objects maybe persisted by Hibernate with domain services managed by Spring</p>
<h2 id="resources">Resources</h2>
<ul>
<li><a href="http://svn.synyx.org/synyx/opensource/misc/org.synyx.samples.spring.atconfigurable/tags/org.synyx.samples.spring.atconfigurable-0.0.1">Source code @ Synyx’ OpenSource SVN</a></li>
<li><a href="http://repo.synyx.org/org/synyx/samples/spring/org.synyx.samples.spring.atconfigurable/0.0.1/org.synyx.samples.spring.atconfigurable-0.0.1.jar">Binaries @ Synyx’ OpenSource Maven Repository</a></li>
</ul>
Hades 0.5.0 released2009-05-22T16:40:40+02:00http://www.odrotbohm.de/2009/05/hades-050-released
<p>Let me prodly announce version 0.5.0 of Hades. As our <a href="http://hades.synyx.org">project home</a> 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.</p>
<h2 id="streamlining-of-the-spring-namespace">Streamlining of the Spring namespace</h2>
<p>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 <code class="language-plaintext highlighter-rouge">base-package</code> which aligns pretty much from the <code class="language-plaintext highlighter-rouge">base-package</code> 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. <code class="language-plaintext highlighter-rouge"><hades:dao-config base-package="com.acme.**.dao" /></code> would scan all packages starting with <code class="language-plaintext highlighter-rouge">com.acme</code> and ending on <code class="language-plaintext highlighter-rouge">dao</code> for Hades DAO interfaces and create the appropriate instances for them.</p>
<h2 id="osgi-ready">OSGi ready</h2>
<p>There was a bug in 0.4 <code class="language-plaintext highlighter-rouge">MANIFEST.MF</code> 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 <a href="http://repo.synyx.org/org/synyx/hades/org.synyx.hades.sample/0.5.0/">here</a>.</p>
<h2 id="programatic-api">Programatic API</h2>
<p>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 <code class="language-plaintext highlighter-rouge">GenericDaoFactoryBean</code> that implements Springs <code class="language-plaintext highlighter-rouge">FactoryBean</code> interface. With 0.5.0 Hades provides a <code class="language-plaintext highlighter-rouge">GenericDaoFactory</code> that provides an interface that suits needs for programatic access. Now you can create DAO instances by simply invoking <code class="language-plaintext highlighter-rouge">GenericDaoFactory.create(em).getDao(UserDao.class);</code></p>
<h2 id="miscellaneous">Miscellaneous</h2>
<p>We aligned our versioning and artifact naming OSGi conventions.</p>
<h2 id="roadmap">Roadmap</h2>
<p>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.</p>
<h2 id="links">Links</h2>
<ul>
<li><a href="http://hades.synyx.org">Hades project home</a></li>
</ul>
Achieving application modularity with Hera2009-05-17T16:04:27+02:00http://www.odrotbohm.de/2009/05/achieving-application-modularity-with-hera<p>The <a href="http://www.javaposse.com/index.php?post_id=479283">latest episode</a> of the <a href="http://www.javaposse.com/">JavaPosse podcast</a> 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.</p>
<p>As a note aside I want to mention, that I am of course aware of <a href="http://www.osgi.org">OSGi</a> 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.</p>
<p><a href="http://weblogs.java.net/blog/bv/">Bill Venners</a> 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.</p>
<h2 id="the-concept-of-binding">The concept of binding</h2>
<p>At some point <a href="http://joelneely.wordpress.com/">Joel Neely</a> 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.</p>
<p>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 <strong>plus</strong> 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.</p>
<h2 id="aligning-object-creation-to-the-classpath-configuration">Aligning object creation to the classpath configuration</h2>
<p>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 <code class="language-plaintext highlighter-rouge">ApplicationContext</code> creation to the before mentioned usage of the classpath to assemble modules.</p>
<p><a href="http://www.springframework.org">Springs</a> 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</p>
<p><code class="language-plaintext highlighter-rouge"><import resource="classpath*:com/acme/**/my-context.xml" /></code></p>
<p>in config files of a core application allows to transparently add beans from configuration files named <code class="language-plaintext highlighter-rouge">my-context.xml</code> under a package <code class="language-plaintext highlighter-rouge">com.acme</code> to an <code class="language-plaintext highlighter-rouge">ApplicationContext</code>. 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 <code class="language-plaintext highlighter-rouge">my-context.xml</code> and thus aligns availability of beans in the <code class="language-plaintext highlighter-rouge">ApplicationContext</code> to the classpath configuration.</p>
<h2 id="client-side-binding">Client side binding</h2>
<p>This leads us to the question how an extensible object gets access to the instance that is created from an module JAR’s <code class="language-plaintext highlighter-rouge">my-context.xml</code>. 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 <a href="http://hera.synyx.org">Hera</a> comes into play. It provides a Spring namespace to dynamically lookup beans from an <code class="language-plaintext highlighter-rouge">ApplicationContext</code> and let them be bound to a collecting bean. Thus by defining</p>
<p><code class="language-plaintext highlighter-rouge"><hera:list id="foo" class="my.plugin.Interface" /></code></p>
<p>all beans implementing <code class="language-plaintext highlighter-rouge">my.plugin.Interface</code> would be collected into a <code class="language-plaintext highlighter-rouge">ListFactoryBean</code> 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 <code class="language-plaintext highlighter-rouge">Interface</code> 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.</p>
<h2 id="binding-at-runtime">Binding at runtime</h2>
<p>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 <code class="language-plaintext highlighter-rouge">TaxCalculator</code> extend Hera’s <code class="language-plaintext highlighter-rouge">Plugin<T></code> interface, that adds a <code class="language-plaintext highlighter-rouge">supports(T delimiter)</code> method to allow determining if the plugin is suitable in a given context. The delimiter type in our example could be a <code class="language-plaintext highlighter-rouge">State</code> enum or the <code class="language-plaintext highlighter-rouge">User</code> type itself. Thus the plugin itself can decide which states it provides tax calculation for.</p>
<p>At the client side aquiring a simple list of all the <code class="language-plaintext highlighter-rouge">TaxCalculator</code> 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</p>
<p><code class="language-plaintext highlighter-rouge"><hera:registry id="foo" class="my.plugin.TaxCalcuator" /></code></p>
<p>to obtain an instance of <code class="language-plaintext highlighter-rouge">PluginRegistry<TaxCalculator, User></code> 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 <a href="http://trac.synyx.org/hera/chrome/site/mvn/hera-core/apidocs/index.html">JavaDoc</a> for details.</p>
<h2 id="bringin-the-parts-together">Bringin the parts together</h2>
<p>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.</p>
<h2 id="summary">Summary</h2>
<p>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.</p>
Unit testing annotation based Spring MVC controllers2009-05-17T08:18:54+02:00http://www.odrotbohm.de/2009/05/unit-testing-annotation-based-spring-mvc-controllers
<p>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.</p>
<p>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 <code class="language-plaintext highlighter-rouge">AnnotationHandlerMethodAdapter</code>, 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 <a href="http://jira.springframework.org/browse/SPR-5763">request for enhancement</a> to extract that class and thus offer an easy way to test URL mappings.</p>
<p>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.</p>
<p>Suppose you have a controller class like this:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>@Controller
public class MyController {
@RequestMapping("/users")
public void foo(HttpServletResponse response) {
// Controller code goes here...
}
}
</code></pre></div></div>
<p>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:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>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);
}
}
</code></pre></div></div>
<p>You probably want to factor out basic behaviour into a common superclass to easily write mapping tests for all of your controllers.</p>
Hera 0.4 released2009-03-30T15:50:48+02:00http://www.odrotbohm.de/2009/03/hera-04-released<p>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 <a href="http://www.olivergierke.de/2008/10/09/the-smallest-plugin-system-ever/">my introducing blog post</a> about it.</p>
<p>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 <code class="language-plaintext highlighter-rouge">Ordered</code> or by annotating your plugin classes with <code class="language-plaintext highlighter-rouge">@Order</code>) to fix the order of plugins in the registry. Furthermore we made <code class="language-plaintext highlighter-rouge">PluginRegistry</code> an interface with 0.4 and provide a <code class="language-plaintext highlighter-rouge">SimplePluginRegistry</code> (without ordering capabilities) that is completely independent of Spring and a <code class="language-plaintext highlighter-rouge">OrderAwarePluginRegistry</code> that will be used when you use the Hera Spring namespace.</p>
<p>Feel free to check out the new release at <a href="http://hera.synyx.org">http://hera.synyx.org</a> and give feedback!</p>
Java Posse Roundup 2009 - Part I2009-03-05T10:53:16+01:00http://www.odrotbohm.de/2009/03/java-posse-roundup-09-part-i<p>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.</p>
<p>My flight to the states was actually quite nice although it took me almost 24h to finally get to Crested Butte, Colorado. <a href="http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=Whiterock+716,+Crested+Butte,+CO,+USA&sll=38.8758,-106.981773&sspn=0.131502,0.30899&ie=UTF8&ll=40.680638,-106.962891&spn=16.381406,39.550781&t=h&z=5&iwloc=addr">Crested Butte</a> 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.</p>
<h2 id="monday">Monday</h2>
<p>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 <a href="http://www.youtube.com/javaposse">JavaPosse Youtube channel</a>.</p>
<p>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 <code class="language-plaintext highlighter-rouge">jfx:*</code>.</p>
<p>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 <a href="http://www.youtube.com/javaposse">JavaPosse Youtube channel</a>.</p>
<h2 id="tuesday">Tuesday</h2>
<p>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.</p>
<p>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…</p>
<p>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.</p>
<p>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…</p>
<h2 id="wednesday">Wednesday</h2>
<p>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.</p>
<p>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.</p>
<h2 id="summing-up-the-first-days">Summing up the first days</h2>
<p>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…</p>
Hades 0.4 released2009-02-26T16:34:58+01:00http://www.odrotbohm.de/2009/02/hades-04-released<p>Passionatedly practicing conference driven development I’d like to announce version 0.4 of the DAO implementation library Hades.</p>
<h2 id="eclipse-plugin">Eclipse plugin</h2>
<p>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.</p>
<h2 id="automatic-detection-of-jpa-persistence-provider">Automatic detection of JPA persistence provider</h2>
<p>As of version 0.4 Hades is able to detect the JPA persistence provider you use by inspecting the <code class="language-plaintext highlighter-rouge">EntityManager</code> instance. Thus no explicit configuration is necessary anymore.</p>
<p>So feel free to take a look at and provide feedback.</p>
<h2 id="links">Links</h2>
<ul>
<li><a href="http://hades.synyx.org">Hades project home</a></li>
<li><a href="http://redmine.synyx.org/wiki/hades/Eclipse">Documentation of the Eclipse plugin</a></li>
</ul>
Heading Java Posse Roundup 20092009-02-26T16:15:17+01:00http://www.odrotbohm.de/2009/02/heading-javaposse-roundup-2009<p>2 more days and I will make my way to Crested Butte, Colorado to join this year’s <a href="http://www.mindviewinc.com/Conferences/JavaPosseRoundup/">Java Posse Roundup</a>. Not having attended an “Uncoference” before I really look forward to this style of conference as the <a href="http://en.wikipedia.org/wiki/Unconference">concept</a> 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. <a href="http://www.flickr.com/photos/tags/javaposseroundup08/">Last year’s pictures</a> look awesome.</p>
<p>I’ll try to post here now and then to reflect what’s going on over there but i guess <a href="http://twitter.com/olivergierke">Twitter</a> frequency will be much higher.</p>
Integrating Hades into existing applications2009-02-06T19:11:58+01:00http://www.odrotbohm.de/2009/02/integrating-hades-into-existing-applications<p>Today I’ve got an email by <a href="https://www.xing.com/profile/Thomas_Braun14/N1.1.4.2.b6504d">Thomas Braun</a> who considered to play around with Hades. He is facing an application with an existing data access layer based on Spring’s <code class="language-plaintext highlighter-rouge">HibernateDaoSupport</code> class. This raised the question of how to integrate Hades into the app without changing existing code.</p>
<p>Thomas was using <code class="language-plaintext highlighter-rouge">AnnotationSessionFactoryBean</code> to create the <code class="language-plaintext highlighter-rouge">SessionFactory</code> from annotation metadata. As Hades relies on JPA <code class="language-plaintext highlighter-rouge">EntityManager</code> interface the basic question was how to use it next to the SessionFactory while avoiding duplicate metadata evaluation and thus two entity handling infrastructure.</p>
<p>The solutions is unexpectedly simple. Supposed you use <code class="language-plaintext highlighter-rouge">LocalContainerEntityManagerFactoryBean</code> as you normally would do in plain JPA setup and register it under <code class="language-plaintext highlighter-rouge">entityManagerFactory</code> in your Spring configuration file you can configure DAOs based on <code class="language-plaintext highlighter-rouge">HibernateDaoSupport</code> as follows:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code><bean class="your.dao.based.on.HibernateDaoSupport">
<property name="sessionFactory">
<bean factory-bean="entityManagerFactory"
factory-method="getSessionFactory" />
</property>
</bean>
</code></pre></div></div>
<p>The key here is, that <code class="language-plaintext highlighter-rouge">HibernateEntityManagerFactory</code> (which is the type that will be created by the LCEMFB if you use the <code class="language-plaintext highlighter-rouge">HibernateVendorAdaptor</code>) offers a method <code class="language-plaintext highlighter-rouge">getSessionFactory</code> to get access to the underlying SessionFactory instance.</p>
<p>Once again nice to see how easy Spring helps integrating applications, existing code with new approaches.</p>
Clean Code - Review Part I2009-01-23T20:37:03+01:00http://www.odrotbohm.de/2009/01/clean-code-review-part-i<p>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.</p>
<h2 id="1-separate-constructing-a-system-frum-using-it">1. Separate constructing a system frum using it</h2>
<p>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 <a href="http://www.springsource.org/javaconfig">Spring JavaConfig</a>). For Robert the startup process of an application actually a <strong>concern</strong>. 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.</p>
<h2 id="2-dependency-injection">2. Dependency Injection</h2>
<p>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.</p>
<h2 id="3-cross-cutting-concerns--aop">3. Cross cutting concerns / AOP</h2>
<p>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.</p>
<h2 id="4-incremental-design">4. Incremental design</h2>
<p>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…</p>
<h2 id="5-domain-specific-languages">5. Domain specific languages</h2>
<p>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.</p>
<h2 id="summary">Summary</h2>
<p>Robert boils down the chapter to the following paragraph:</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>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.</p>
<p>If you like, check out the <a href="http://www.amazon.de/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/ref=sr_1_1?ie=UTF8&s=books-intl-de&qid=1232735586&sr=8-1">book @ Amazon</a>.</p>
The DAO is dead! Long live the DAO!2009-01-14T21:30:09+01:00http://www.odrotbohm.de/2009/01/se-radio-episode-121-or-mappers<p><a href="http://www.se-radio.net/podcast/2008-12/episode-121-or-mappers-michael-ploed">Episode 121</a> of <a href="http://www.se-radio.net">Software Engineering Radio</a> deals with the topic of OR Mappers. Michael Plöd introduces the concept of <a href="http://en.wikipedia.org/wiki/Object-relational_mapping">object-relational mapping</a> 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.</p>
<p>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…</p>
<p>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:</p>
<blockquote>
<p>…a <strong>Data Access Object</strong> (DAO) is an <a href="http://en.wikipedia.org/wiki/Object_%28computer_science%29">object</a> that provides an abstract <a href="http://en.wikipedia.org/wiki/Interface_%28computer_science%29">interface</a> to some type of <a href="http://en.wikipedia.org/wiki/Database">database</a> or persistence mechanism, providing some specific operations without exposing details of the database.</p>
</blockquote>
<p>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.</p>
<h2 id="separation-of-persistence-logic-and-business-logic">Separation of persistence logic and business logic</h2>
<p>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.</p>
<h2 id="tangled-code--more-sophisticated-api">Tangled code / More sophisticated API</h2>
<p>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.</p>
<h2 id="exchange-implementation">Exchange implementation</h2>
<p>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.</p>
<h2 id="dont-repeat-the-dao">Don’t repeat the DAO!</h2>
<p>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.</p>
<h2 id="hades-to-help">Hades to help!</h2>
<p>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 <a href="http://hades.synyx.org">Hades</a> and play around with it if you like.</p>
<p>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 <a href="http://hades.synyx.org">Hades</a> (and the DAO question) on 2009’s first <a href="http://www.devdusk.de">DevDusk</a> - Technology for Techies, a bimonthly meeting of passionated geeks, nerds, techies, whatever you wnt to call them. Would be nice to see you there.</p>
<h2 id="links">Links</h2>
<ul>
<li><a href="http://www.ibm.com/developerworks/java/library/j-genericdao.html">Don’t repeat the DAO</a></li>
</ul>
Subtleties on java.lang.Enum2009-01-12T07:32:01+01:00http://www.odrotbohm.de/2009/01/subtleties-on-javalangenum<p>As i twittered a few days ago, I stumbled over a subtle issue in the core Java library. Not as extreme as <a href="http://www.olivergierke.de/wordpress/2008/12/javac-issues-implementing-generics/">here</a> but one to raise ones eyebrows, too.</p>
<p>I just wanted to write a small method to access an enum value by its <code class="language-plaintext highlighter-rouge">String</code> representation or use a default, if the conversion fails:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>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))
}
</code></pre></div></div>
<p>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) <code class="language-plaintext highlighter-rouge">Enum</code> type, claiming the type handed to the <code class="language-plaintext highlighter-rouge">valueOf(…)</code> method was not an Enum?</p>
<p>What? I’ve handed over an <code class="language-plaintext highlighter-rouge">Enum</code> as default value and you tell me, it is not of an <code class="language-plaintext highlighter-rouge">Enum</code> 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 <code class="language-plaintext highlighter-rouge">getDeclaringClass()</code> instead, as the JavaDoc reveals.</p>
<p>Although I understand that <code class="language-plaintext highlighter-rouge">Enum</code>s with methods are implemented with inner classes, I do not understand why these inner classes do not extend <code class="language-plaintext highlighter-rouge">Enum<T></code>. Futhermore I cannot believe that the behaviour of <code class="language-plaintext highlighter-rouge">getClass()</code> changes depending on whether you use methods in your <code class="language-plaintext highlighter-rouge">Enum</code> or not. Strange thing…</p>
<p>Below you find a small test case to reproduce the issue. Be sure you have JUnit in version 4 or above on the classpath.</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>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);
}
}
</code></pre></div></div>
Hades at Java User Group Karlsruhe2008-12-18T14:11:22+01:00http://www.odrotbohm.de/2008/12/hades-at-jug-karlsruhe<p>Yesterday I gave a presentation about <a href="http://trac.synyx.org/hades">Hades</a> at the Java User Group Karlsruhe. It was preceeded by an introduction to Aspect Oriented Programming by <a href="http://dlinsin.blogspot.com/">David Linsin</a> and Florian Waibel of Netpioneer that showed the usage of AOP to define system architecture constraints.</p>
<p>You can download the <a href="http://www.olivergierke.de/wordpress/wp-content/uploads/2008/12/generic-daos-with-hades1.pdf">slides</a> as well as the <a href="http://www.olivergierke.de/wordpress/wp-content/uploads/2008/12/hades-sample.zip">sample code</a> here or all stuff at the <a href="http://groups.google.com/group/jug-karlsruhe">JUG Karlsruhe Google group</a>.</p>
JavaC issues implementing generics2008-12-15T15:02:20+01:00http://www.odrotbohm.de/2008/12/javac-issues-implementing-generics<p>Attenting <a href="http://www.olivergierke.de/wordpress/2008/12/devoxx-2008">Devoxx last week</a>, 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:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>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();
</code></pre></div></div>
<p>Don’t try to get the details, there are only three important things:</p>
<ul>
<li>Two generic parametrizations, where one is a derived one from the other</li>
<li>The static factory method as suggested to ease using this generic class in Josh Blochs “Effective Java 2” (Item 1)</li>
<li>The last line takes advantage of this method to create an instance of the registry.</li>
</ul>
<p>The strange thing is, this compiles within Eclipse but does not on plain <code class="language-plaintext highlighter-rouge">javac</code>. I mailed Alex Buckley about the issue and after some back and forth he discovered a strange issue with javac.</p>
<p>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 (<a href="http://bugs.sun.com/view_bug.do?bug_id=6192945">6192945</a>, <a href="http://bugs.sun.com/view_bug.do?bug_id=6369605">6369605</a>, <a href="http://bugs.sun.com/view_bug.do?bug_id=6193815">6193815</a>). I’ll leave out the bloody details, here is, what it boils down to:</p>
<p><code class="language-plaintext highlighter-rouge">Javac</code> somehow only tries to lookup types forward in this case. It infers <code class="language-plaintext highlighter-rouge">T == Plugin<String></code>, but complains that for it <code class="language-plaintext highlighter-rouge">Plugin<String></code> is not a subtype of <code class="language-plaintext highlighter-rouge">Plugin<S></code> (as it has not inferred S yet). Guess what, if you simply switch the generic parameters, it compiles like a charm:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>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();
</code></pre></div></div>
<p>(Note the order of the generic types in the method signature)</p>
<p>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 <code class="language-plaintext highlighter-rouge">javac</code> 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.</p>
Spring 3.0 M1 is out now for Maven users, too2008-12-12T04:17:06+01:00http://www.odrotbohm.de/2008/12/spring-30-m1-is-out-now-for-maven-users-too<p>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 <a href="http://blog.springsource.com/2008/12/05/spring-framework-30-m1-released/#comment-131869">blog comment</a>. I’m leaching it from the servers right now…</p>
Devoxx 20082008-12-11T18:30:16+01:00http://www.odrotbohm.de/2008/12/devoxx-2008<p>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 <a href="http://www.devoxx.com/display/JV08/The+next+versions+of+Parleys.com">Stephan Janssen</a> on the new <a href="http://www.parleys.com">Parleys.com</a> as well as some other ones tomorrow but as The days were so fully packed, I’ll try to organize stuff a little.</p>
<h2 id="monday">Monday</h2>
<p>The first university day, I especially remember a <a href="http://www.devoxx.com/display/JV08/The+Scala+Experience">talk</a> of Ted Neward and Bill Vinner on <a href="http://www.scala-lang.org/">Scala</a>. 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:</p>
<blockquote>
<p>No, I will not make this an EJB! Get out!</p>
</blockquote>
<p>Of course he was not serious (well, actually I don’t know).</p>
<h2 id="tuesday">Tuesday</h2>
<p>Tuesday started out with a presentation of Holly Cummins and Kirk Pepperdine on <a href="http://www.devoxx.com/display/JV08/Java+Performance">Java performance tools</a>. The talk had quite a balanced weight between theoretical introduction and tools in action to discover and track performance bottlenecks.</p>
<p>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 <a href="http://www.olivergierke.de/wordpress/wp-content/uploads/2008/12/generic-daos-with-hades.pdf">here</a>.</p>
<p>The <a href="http://www.devoxx.com/display/JV08/Pro+Spring+2.5">Pro Spring 2.5</a> 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 <code class="language-plaintext highlighter-rouge">@Autowired</code> on a property of type <code class="language-plaintext highlighter-rouge">List</code> and it will get all Spring beans injected implementing the <code class="language-plaintext highlighter-rouge">Foo</code> interface. Of course this raises the question of how Spring can detect the generic type at runtime. Seems like <code class="language-plaintext highlighter-rouge">org.sfw.core.GenericCollectionTypeResolver</code> does the trick.</p>
<h2 id="wednesday">Wednesday</h2>
<p>The session day ended with a <a href="http://www.devoxx.com/display/JV08/RESTful+Design%2C+Patterns+and+Anti-Patterns">talk</a> of <a href="http://www.innoq.com/blog/st/">Stefan Tilkov</a> 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 <strong>endpoint</strong>? 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:</p>
<blockquote>
<p>It’s like overriding a <code class="language-plaintext highlighter-rouge">plus</code> method, with formatting your harddrive.”</p>
</blockquote>
<p>Note, that same as to the quote of Ted - exeggeration serves descriptiveness. ;)</p>
<p>Yesterday evening was a <a href="http://www.devoxx.com/display/JV08/European+JUG+Gathering">BOF session of JUG leaders</a>. 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.</p>
<h2 id="thursday">Thursday</h2>
<p>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</p>
<ul>
<li>no closures (jihaa! let’s simply talk another 3 years about it)</li></li>
<li>no Properties</li>
<li>no reimplemented Generics</li>
<li>small language changes:
** multiple exceptions in catchclause: <code class="language-plaintext highlighter-rouge">catch (Foo, Bar e)</code>
** null-safe object traversal: <code class="language-plaintext highlighter-rouge">a?.foo()?.bar()?</code> -> returns <code class="language-plaintext highlighter-rouge">null</code> if one of the values in between is <code class="language-plaintext highlighter-rouge">null</code>
** type inference: <code class="language-plaintext highlighter-rouge">Map<String, Object> map = new HashMap();</code> <- gets <code class="language-plaintext highlighter-rouge">new HashMap<String, Object>();</code> automatically</li>
<li>modularity on language level</li>
</ul>
<p>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.</p>
<p>More detailled information can be found in <a href="http://hamletdarcy.blogspot.com/2008/12/java-7-update-from-mark-reinhold-at.html">Hamlet D’Arcy’s blog</a>, who I occasionally met discussing the language changes with Josh Bloch at the whiteboards.</p>
<p>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 <a href="http://en.wikipedia.org/wiki/Joshua_Bloch">Josh Bloch</a> 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 <a href="http://blogs.sun.com/abuckley/">Alex Buckley</a> an try to keep track on it.</p>
<p>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.</p>
<p>The most funny part - as I could have predicted - was the <a href="http://www.javaposse.org">Java Posse</a> 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.</p>
<p>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</p>
Hades 0.3 is out2008-12-06T21:19:00+01:00http://www.odrotbohm.de/2008/12/hades-03-is-out<p>I am pleased to announce version 0.3 of <a href="http://trac.synyx.org/hades">Hades</a>, an open source project I lead. The release bundles a new <code class="language-plaintext highlighter-rouge">ExtendedGenericDao</code> implementation based on <a href="http://www.eclipse.org/eclipselink/">EclipseLink</a> as well as some major package refactorings. For more information and a detailed changelog see the <a href="http://trac.synyx.org/hades">project homepage</a>.</p>
On the way to Devoxx2008-12-06T17:55:04+01:00http://www.odrotbohm.de/2008/12/on-the-way-to-devoxx<p>Tomorrow some colleagues and me will be travelling to Antwerp, Belgium to attend this years <a href="http://www.devoxx.com">Devoxx</a> (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 <a href="http://dlinsin.blogspot.com/">fellow developers</a>. Furthermore I will give a short intro into <a href="http://trac.synyx.org/hades">Hades</a> on <a href="http://www.devoxx.com/display/JV08/Easing+JPA+DAO+development+with+Hades">Tuesday</a>.</p>
<p>I will try to sum up every day with a small blog post as I did on <a href="http://www.olivergierke.de/wordpress/tag/springone08/">SpringOne</a> Europe already.</p>
Is REST the next Spring?2008-12-04T18:25:11+01:00http://www.odrotbohm.de/2008/12/is-rest-the-next-spring<p>Browsing the latest JavaMagazin leader written by <a href="http://www.innoq.com/blog/st/">Stefan Tilkov</a>, 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.</p>
<p>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.</p>
<p>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.</p>
<p>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).</p>
<p>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?</p>
<p>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.</p>
Hades on tour2008-11-18T10:33:17+01:00http://www.odrotbohm.de/2008/11/hades-on-tour<p>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:</p>
<ul>
<li>Dec, 9th 2008 - <a href="http://www.devoxx.com/display/JV08/Easing+JPA+DAO+development+with+Hades">Devoxx Conference, Antwerpen</a></li>
<li>Dec, 17th 2008 - <a href="http://groups.google.com/groups/jug-karlsruhe">Java User Group, Karlsruhe</a></li>
<li>Jan, 15th, 2008 - <a href="http://www.devdusk.de">DevDusk, Frankfurt</a></li>
</ul>
<p>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.</p>
The metadata dilemma2008-11-18T10:24:59+01:00http://www.odrotbohm.de/2008/11/the-metadata-dilemma<p>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.</p>
<h2 id="what-is-metadata">What is metadata?</h2>
<p><a href="http://de.wikipedia.org/wiki/Metadata">Wikipedia</a> names “data about data” and further explains:</p>
<blockquote>
<p>In data processing, metadata is definitional data that provides information about or documentation of other data managed within an application or environment.</p>
</blockquote>
<p>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.</p>
<h2 id="to-tie-or-not-to-tie">To tie or not to tie?</h2>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<h2 id="problems">Problems</h2>
<p>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.</p>
<p>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?</p>
<h2 id="conclusion">Conclusion?</h2>
<p>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.</p>
<p>What do you think?</p>
Videos of the Four Sided Cube unplugged gig2008-11-02T19:18:02+01:00http://www.odrotbohm.de/2008/11/videos-of-the-unplugged-gig<p>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 <a href="http://www.youtube.com/foursidedcube">YouTube channel</a>.</p>
<iframe width="420" height="315" src="http://www.youtube.com/embed/GmJLyX2P1YI" frameborder="0" allowfullscreen="true"></iframe>
The smallest plugin system ever2008-10-09T10:13:58+02:00http://www.odrotbohm.de/2008/10/the-smallest-plugin-system-ever<p>I blogged about <a href="http://www.olivergierke.de/wordpress/2008/09/26/hades-02-is-out/">Hades</a>, an OpenSource project I lead a while ago. Today I want to launch another neat library. Much smaller than Hades but IMHO useful nevertheless.</p>
<p>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:</p>
<ul>
<li>The component should have the easiest possible access to collaborateurs.</li>
<li>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.</li>
<li>I would be nice if we could integrate this with Spring</li>
</ul>
<p>Here’s the solution I came up with…</p>
<p>I have an interface <code class="language-plaintext highlighter-rouge">Plugin<T></code>, where T defines the criteria or delimiter to select plugins that shall actually be invoked. The only method this interface contains is <code class="language-plaintext highlighter-rouge">boolean supports(T delimiter)</code>. 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.:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>public interface NotificationProvider implements Plugin<String> {
void notify(Notification notification);
}
</code></pre></div></div>
<p>Your <code class="language-plaintext highlighter-rouge">NotificationProvider</code> instances have to implement <code class="language-plaintext highlighter-rouge">supports</code> 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 <code class="language-plaintext highlighter-rouge">Notification</code> in this case, but it does not have to be.</p>
<p>The next core abstraction is the <code class="language-plaintext highlighter-rouge">PluginRegistry<S extends Plugin<T>, T></code>. Wow, whatta signature. Instantiating it, it allows you to register <code class="language-plaintext highlighter-rouge">Plugin</code>s of type <code class="language-plaintext highlighter-rouge">S</code> and in turn access the by providing delimiter in various ways. You can ask the registry for the first suitable <code class="language-plaintext highlighter-rouge">Plugin</code>, all suitable plugins or ask for mandatory plugins and let the registry throw an exception if none found. See the <a href="http://trac.synyx.org/hera/chrome/site/mvn/plugin-core/apidocs/index.html">JavaDoc</a> for details.</p>
<p>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 <code class="language-plaintext highlighter-rouge">PluginRegistry</code> into a Spring bean and access plugins as you like.</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code><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>
</code></pre></div></div>
<h2 id="how-to-create-a-registry">How to create a registry?</h2>
<p>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 <code class="language-plaintext highlighter-rouge">NotificationProvider</code> implementation after next application restart.</p>
<p>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.</p>
<p>This is where Spring comes into play again. I implemented a <code class="language-plaintext highlighter-rouge">PluginRegistryBeanFactoryPostProcessor</code> (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 <code class="language-plaintext highlighter-rouge">PluginRegistry</code> and expose it as a new bean in the application context itself.</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code><bean class="org.synyx.plugin.support.PluginRegistryBeanFactoryPostProcessor">
<property name="lists">
<map>
<entry key="notificationProviders"
value="com.acme.notification.NotificationProvider" />
</map>
</property>
</bean>
</code></pre></div></div>
<p>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 <code class="language-plaintext highlighter-rouge">PluginRegistry</code>. This is mainly due to the requirement to create multiple <code class="language-plaintext highlighter-rouge">PluginRegistry</code>s with one <code class="language-plaintext highlighter-rouge">BeanPostProcessor</code>. Maybe we’d drop this providing a more speaking interface but take into account to register one <code class="language-plaintext highlighter-rouge">BeanFactoryPostProcessor</code> for one <code class="language-plaintext highlighter-rouge">PluginRegistry</code>.</p>
<h2 id="so-how-do-you-set-up-your-plugin-jars">So how do you set up your plugin JARs?</h2>
<p>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.</p>
<p><code class="language-plaintext highlighter-rouge"><import resource="classpath*:com/acme/**/plugin-context.xml" /></code></p>
<p>Defining this along with the <code class="language-plaintext highlighter-rouge">BeanPostProcessor</code> 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 <code class="language-plaintext highlighter-rouge">pom.xml</code> files into some kind of program instance configuration.</p>
<h2 id="syntactic-sugar">Syntactic sugar</h2>
<p>As you might have noticed, registration of the <code class="language-plaintext highlighter-rouge">BeanFactoryPostProcessor</code> is somewhat ugly. Besides the enormous name it is a LOT of XML to just define registering all beans implementing <code class="language-plaintext highlighter-rouge">Foo</code> under <code class="language-plaintext highlighter-rouge">bar</code>. Furthermore the entry’s “key” is actually the bean id the <code class="language-plaintext highlighter-rouge">PluginRegistry</code> is registered under, the “value” is actually a type name.</p>
<p>To ease configuration a little I’ve added a Spring namespace implementation , that boils declaring a <code class="language-plaintext highlighter-rouge">PluginRegistry</code> down to something like this:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code><plugin:registry id="notificationProviders"
class="com.acme.notification.NotificationProvider" />
</code></pre></div></div>
<p>You can gain Eclipse classname code completion by adding <code class="language-plaintext highlighter-rouge">org/synyx/plugin/core/config/plugin-config.xsd</code> to your XML catalog. If you installed <a href="http://springide.org">Spring IDE</a>, it should come up with the code completion if you edit the class attribute of the registry element.</p>
<h2 id="simple-lists">Simple lists</h2>
<p>The project also includes Spring support for a little stripped down version of the requirements by providing a <code class="language-plaintext highlighter-rouge">BeanListBeanFactoryPostProcessor</code>, 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 <code class="language-plaintext highlighter-rouge">Plugin</code> and use <code class="language-plaintext highlighter-rouge">PluginRegistry</code>. Of course there is also a namespace element list, that provides a configuration shortcut to define this <code class="language-plaintext highlighter-rouge">BeanFactoryPostProcessor</code>, too.</p>
<h2 id="summary">Summary</h2>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>If you have any comments, ideas, critique dont’t hesitate to leave a comment or contact me directly.</p>
<h2 id="links">Links</h2>
<ul>
<li><a href="http://trac.synyx.org/hera">Project website</a></li>
</ul>
<p>Update: We decided to use Hera as the name for the project as all our projects are named around gods of the greek mythology. This affected the project URL.</p>
Hades 0.2 is out2008-09-26T20:35:09+02:00http://www.odrotbohm.de/2008/09/hades-02-is-out<p>Today we officially released version 0.2 of <a href="http://trac.synyx.org/hades">Hades</a>, a domain class and DAO development library based on JPA and <a href="http://www.springframework.org">Spring</a>. Hades is mainly based on an idea provided by <a href="http://jandiandme.blogspot.com/">Eberhard Wolff</a> in Java Magazin. Hades feature list reads as follows:</p>
<ul>
<li>Implementation of CRUD methods for JPA Entities</li>
<li>Transparent triggering of JPA NamedQueries by finder methods</li>
<li>Dynamic query generation from finder method names</li>
<li>Implementation domain base classes providing basic properties</li>
<li>Support for transparent auditioning (created, last changed)</li>
<li>Easy Spring integration with custom namespace</li>
</ul>
<p>Version 0.2 mainly brings minor enhancements and polishes. Since today we’re also listed at <a href="https://www.ohloh.net/projects/hades">ohloh.net</a>. So feel free to check out the documentation and play with it a little.</p>
<h2 id="links">Links</h2>
<ul>
<li><a href="http://trac.synyx.org/hades">Hades project site</a></li>
</ul>
How to feed link SCM paths into your Trac2008-09-26T13:11:35+02:00http://www.odrotbohm.de/2008/09/how-to-feed-long-scm-paths-to-your-trac<p>We’re using <a href="http://trac.edgewall.org">Trac</a> 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 <a href="http://trac.edgewall.org/ticket/3676">this ticket </a>explains 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.</p>
<p>As the ticket describes this is just an index and can easily be dropped with</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>ALTER TABLE `node_change` DROP PRIMARY KEY;
</code></pre></div></div>
Developers facing the real world2008-09-05T12:45:07+02:00http://www.odrotbohm.de/2008/09/developers-facing-the-real-world<p>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 <a href="http://en.wikipedia.org/wiki/Separation_of_concerns">Separation of Concerns</a> and is also known as the <a href="http://en.wikipedia.org/wiki/God_object">God object antipattern</a>.</p>
Validating domain objects2008-08-11T20:58:20+02:00http://www.odrotbohm.de/2008/08/validating-domain-objects<p>Fellow developer <a href="http://dlinsin.blogspot.com/">David Linsin</a> wrote a <a href="http://dlinsin.blogspot.com/2008/08/how-to-validate-your-domain-objects.html">blogpost</a> 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:</p>
<p>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.</p>
<p>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).</p>
<p>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.</p>
<p>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.</p>
<p>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 <code class="language-plaintext highlighter-rouge">IllegalArgumentException</code>. Doing so in a DTO would make clean error messaging almost impossible.</p>
<p>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 <code class="language-plaintext highlighter-rouge">UserDTO</code> in an Spring MVC validator implementation.</p>
Effective bug smashing with test cases2008-07-01T11:59:50+02:00http://www.odrotbohm.de/2008/07/effective-bug-smashing-with-test-cases<p>There are a lot of opinions buzzing around about how testing and test driven development helps you writing better software. Reading <a href="http://www.amazon.de/Secrets-Rockstar-Programmers-Riding-Crest/dp/0071490833/ref=sr_1_1?ie=UTF8&s=books-intl-de&qid=1214904407&sr=8-1">Secrets of the rockstar programmers</a> just now, I’ve stumbled over an intresting interview with <a href="http://www.bileblog.org/about/">Hani Suleiman</a>, co-author of <a href="http://www.amazon.de/Next-Generation-Java-Testing-Advanced/dp/0321503104/ref=sr_1_1?ie=UTF8&s=books-intl-de&qid=1214904551&sr=8-1">Next Generation Java Testing</a>. 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.</p>
<p>Nevertheless, the quote, that pinged my mind, was this one:</p>
<blockquote>
<p>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.</p>
</blockquote>
<p style="text-align: right;">(Hani Suleiman on testing and bugs)</p>
<p>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.</p>
<p>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:</p>
<p>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:</p>
<ul>
<li>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!)</li>
<li>You add a comment to the ticket that the current revision lets you reproduce the bug</li>
<li>Continue, like described above</li>
</ul>
<p>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.</p>
<p>What do you think about this?</p>
SpringOne 2008 - Application platform keynote2008-06-12T12:00:19+02:00http://www.odrotbohm.de/2008/06/application-platform-keynote<p>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 ;).</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
Spring 2008 - Summing up day one2008-06-12T11:58:48+02:00http://www.odrotbohm.de/2008/06/summing-up-day-one<p>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.</p>
<p>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.</p>
<p>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. ;)</p>
<p>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.</p>
<p>This issue is really some subtle problem with GPL in general as it uses terms that do not have been judicially debated seemingly.</p>
<p>As you can see, I came back with my brain packed with a lot of cool new ideas. And there is yet another day ;).</p>
5 (or 3) aspects you probably haven't thought about2008-06-11T20:09:35+02:00http://www.odrotbohm.de/2008/06/5-or-3-aspects-you-probably-havent-thought-about<p>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.<!--more--></p>
<p>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.</p>
<p>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.</p>
<p>This was a really awesome talk as it showed up the enormous power of AOP and the things you actually can achieve with it.</p>
EclipseLink - High performance persistence for Spring2008-06-11T17:57:14+02:00http://www.odrotbohm.de/2008/06/eclipselink-hig-performance-persistence-for-spring<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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</p>
Thomas Risberg - Persistence tuning for Spring environments2008-06-11T14:37:31+02:00http://www.odrotbohm.de/2008/06/thomas-risberg-persistence-tuning-for-the-spring-environments<p>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.</p>
<p>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.</p>
<p>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 <a href="http://www.springsource.com/products/suite/apfororacledb">SpringSource Advanced Pack for Oracle</a> he gave some more detailled insights in Oracle database performance tunings.</p>
<p>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.</p>
SpringOne 2008 - Jürgen Höller - Spring 2.5 on it's way to 3.02008-06-11T13:26:41+02:00http://www.odrotbohm.de/2008/06/jurgen-holler-spring-25-on-its-way-to-30<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
SpringOne 2008 - Kickoff2008-06-11T12:20:15+02:00http://www.odrotbohm.de/2008/06/springone-kickoff<p>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!</p>
<p>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.</p>
<p>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.</p>
My software engineering book Top 52008-06-08T14:03:33+02:00http://www.odrotbohm.de/2008/06/my-software-engineering-book-top-5<p>As I <a href="http://www.olivergierke.de/wordpress/2008/06/06/reading-domain-driven-design-again/">rummage in Eric Evans’ <strong>Domain Driven Design</strong> again</a>, 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.</p>
<!--more-->
<h2 id="eric-evans---domain-driven-design">Eric Evans - Domain Driven Design</h2>
<p>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.</p>
<p>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.</p>
<ul>
<li>[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)</li>
</ul>
<h2 id="martin-fowler---refactoring">Martin Fowler - Refactoring</h2>
<p>Recently I discovered a <a href="http://www.infoq.com/news/2008/06/soa-without-esb">presentation of Martin Fowler on SOA</a> 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.</p>
<p>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.</p>
<ul>
<li>[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)</li>
</ul>
<h2 id="johannes-link---softwaretests-mit-junit">Johannes Link - Softwaretests mit JUnit</h2>
<p>Agile software development builds on various heuristics and methodologies like continuos integration and first of all unit testing or even <strong>Test Driven Development</strong> (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.</p>
<ul>
<li>[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)</li>
</ul>
<h2 id="steve-mcconnell---code-complete">Steve McConnell - Code Complete</h2>
<p>That’s a really huge one. And all on coding? This <strong>has</strong> 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.</p>
<p>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 <strong>Code Complete 2</strong>, 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.</p>
<ul>
<li>[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)</li>
</ul>
<p><strong>Martin Fowler - Patterns of Enterprise Application Architecture
</strong></p>
<p>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.</p>
<p>In fact, this is not a beginner one but is rather an architects groundwork to build further knowledge and experience on.</p>
<ul>
<li>[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)</li>
</ul>
Reading "Domain Driven Design" again2008-06-06T14:56:51+02:00http://www.odrotbohm.de/2008/06/reading-domain-driven-design-again<p>Currently I read Eric Evans’ “<a href="http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215/ref=sr_1_1?ie=UTF8&s=books-intl-de&qid=1212756929&sr=8-1">Domain Driven Design</a>” once again. Having done so 3 times already, I discovered a paragraph that reminded me of a <a href="http://dlinsin.blogspot.com/2008/05/do-you-care-about-your-code.html">blog post</a> written by David Linsin a while ago. Eric writes as follows:</p>
<blockquote>"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"</blockquote>
<p>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.</p>
<p>“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.</p>
<p>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.</p>
Switching language / SpringOne ahead2008-06-04T21:16:24+02:00http://www.odrotbohm.de/2008/06/switching-language-springone-ahead<p>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.</p>
<p>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.</p>
Clueso - So sehr dabei2008-06-01T20:23:38+02:00http://www.odrotbohm.de/2008/06/clueso-so-sehr-dabei<p>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.<!--more--></p>
<p>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.</p>
<p>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.</p>
<p>“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.</p>
<p>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.</p>
<p>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.</p>
<p>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 mit so viel 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.</p>
<p>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.</p>
<p>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 ;).</p>
<p>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.</p>
Spass mit Maven Archetypes2008-04-22T17:37:13+02:00http://www.odrotbohm.de/2008/04/spass-mit-maven-archetypes<p>Wir führen in der <a href="http://www.synyx.de" title="Synyx GmbH & Co. KG" target="_blank">Firma</a> nach und nach <a href="http://www.docbook.org" title="Docbook" target="_blank">Docbook</a> als Dokumentationsstandard ein. Mit <a href="http://docs.codehaus.org/display/MAVENUSER/Docbkx+Maven+Plugin" title="Dokumentation zu docbkx" target="_blank">docbkx</a> steht auch ein Plugin für unser Buildsystem <a href="http://maven.apache.org/" title="Maven" target="_blank">Maven</a> 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.<!--more--></p>
<p>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.</p>
<p>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 <code class="language-plaintext highlighter-rouge">archetype.xml</code> im META-INF abgelegt werden muss. Soweit die Dokumentation die <a href="http://maven.apache.org/guides/mini/guide-creating-archetypes.html" title="Dokumentation zu Maven Archetypes" target="_blank">hier</a> zu finden ist.</p>
<p>Nun will das Archetype Plugin von Maven allerdings in den bereitgestellten Dateien typische Mavenplatzhalter wie <code class="language-plaintext highlighter-rouge">${version}</code> 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 (<code class="language-plaintext highlighter-rouge">\${version}</code>). Dies funktioniert aber nur ab Maven 2.0.8.</p>
<p>Nachdem diese Hürde genommen war musste ich <a href="http://velocity.apache.org/" title="Velocity" target="_blank">Velocity</a> (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 <a href="http://www.nabble.com/filtering-of-archetype-resources-td15579593s177.html" title="Nabble Forum zum Them Resourcen filtern in Maven Archetypes" target="_blank">Untiefen des Nabble Forums</a> stieß ich dann auf den Hinweis, das Attribut <code class="language-plaintext highlighter-rouge">filtered="true"</code> in den <code class="language-plaintext highlighter-rouge"><resource /></code> Elementen würde genau dies bewerkstelligen.</p>
<p>Was ihr jetzt hier in knapp 5 Minuten gelesen habt, hat mich locker 3 Stunden gekostet^^. Jaja, Dokumentation ist manchmal eben doch hilfreich ;).</p>
Trac 0.10.3 auf MySQL2008-04-21T15:59:47+02:00http://www.odrotbohm.de/2008/04/trac-0103-auf-mysql<p>Ich habe mir bei meinem <a href="http://www.synyx.de">Arbeitgeber</a> für ein paar kleinere Projekte ein <a href="http://trac.edgewall.org">Trac</a> eingerichtet, das gegen eine <a href="http://www.mysql.com/">MySQL</a> Datenbank läuft. Das ganze macht besonders im Zusammenspiel mit <a href="http://www.eclipse.org/mylyn/">Mylyn</a> großen Spaß. Gestern fiel mir jedoch auf, dass ein paar der vorbereiteten Ticketqueries nicht funktionierten. Angeblich sei der Query falsch.<!--more--></p>
<p>Nach kurzer Recherche stieß ich auf einige die <a href="http://groups.google.com/group/trac-users/browse_thread/thread/bf57366c435e57b5/5f7900106c34f5d5?lnk=gst&q=ticket+mysql#5f7900106c34f5d5">das gleiche Problem</a> hatten. Es handelt sich wohl um einen <a href="http://trac.edgewall.org/ticket/4387">known Bug</a>, 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 <code class="language-plaintext highlighter-rouge">$User</code> in den Queries zu entfernen. Dann tut alles wieder wie erwartet.</p>
Spring Webinar2008-03-10T20:46:03+01:00http://www.odrotbohm.de/2008/03/spring-webinar<p>Nächsten Dienstag (18.03.08) werde ich über den IRC des Forums <a href="http://www.tutorials.de" title="Tutorials.de" target="_blank">tutorials.de</a> ein Minitutorial zu Thema “Leichtgewichtige JavaEE Entwicklung mit Spring” halten. Der Code basiert zum Großteil auf dem <a href="http://www.synyx.de/de/galleries/download/schulungen/j2ee-entwicklung-mit-spring-beispielcode.zip" title="Beispielcode zum Webinar" target="_blank">Beispielcode</a> meines Vortrages bei der Java User Group Karlsruhe.</p>
<p>Nähere Informationen zum Vortrag gibts <a href="http://http://www.tutorials.de/forum/java-technology-webconferences/306938-18-03-2008-21-00-uhr-java-entwickler-chat-zum-thema-lightweight-javaee-mit-spring.html" title="Informationen zum Spring Webinar" target="_blank">hier</a>.</p>
Agim Emruli - Spring WebFlow2008-03-03T18:30:33+01:00http://www.odrotbohm.de/2008/03/agim-emruli-spring-webflow<p><a href="http://www.agimemruli.de/">Agim</a> schloss die Vortragsreihe mit einer Präsentation zu <a href="http://www.springframework.org/webflow">Spring WebFlow</a> und Spring Faces. Zu Beginn stellte er die zentralen Konuepte Flow und Conversation vor und ging im weiteren auf den Flow scoped <code class="language-plaintext highlighter-rouge">PersistenceContext</code> 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.<!--more--></p>
<p>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.</p>
Erich Eichinger - Spring.NET2008-03-03T17:30:16+01:00http://www.odrotbohm.de/2008/03/erich-eichinger-erich-eichinger-springnet<p>Spring ist nicht nur im Javaumfeld beliebt sonder erfreut sich auch in .NET Umgebungen steigendere Beliebtheit. <a href="https://www.xing.com/profile/Erich_Eichinger">Erich</a> 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 <a href="http://www.springframework.net/">Spring .NET</a> zurechtfinden.<!--more--></p>
<p>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:</p>
<p><code class="language-plaintext highlighter-rouge">on exception is ConcurrentModificationException retry 3x delay 1s</code></p>
<p>Insgesamt ein recht spannender Vortrag der wieder einmal deutlich macht, wie gut Spring unterschiedliche Technologien und Plattformen abstrahiert.</p>
Arjen Poutsma - Spring WebServices2008-03-03T16:15:54+01:00http://www.odrotbohm.de/2008/03/arjen-poutsma-spring-webservices<p><a href="http://blog.springframework.com/arjen/">Arjen</a> stellte mit <a href="http://www.springframework.org/spring-ws">Spring WebServices</a> 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.<!--more--></p>
<p>Arjen zeigte anhand eines kleines Hotelbuchungsbeispiels die grundätzliche Vorgehensweise und deutete die verschiedenen Integrationsmechanismen an (DOM API oder Object XML Mapping.</p>
<p>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.</p>
<p>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 ;)</p>
Mike Wiesner - Spring Security2008-03-03T14:45:55+01:00http://www.odrotbohm.de/2008/03/mike-wiesner-spring-security<p><a href="http://www.mwiesner.com/">Mike</a> stellte dann das aktuelle M2 Release von <a href="http://acegisecurity.sourceforge.net/">Spring Security</a> 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.<!--more--></p>
<p>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 <code class="language-plaintext highlighter-rouge"><authz:... /></code> Taglibrary vor und gab einen kurzen Einblick in den manuellen Zugriff auf Authentifikationsdaten.</p>
Jürgen Höller - Spring 2.52008-03-03T12:25:11+01:00http://www.odrotbohm.de/2008/03/jurgen-holler-spring-25
<p>Als nächstes gab <a href="http://blog.springsource.com/main/author/juergenh/">Jürgen Höller</a> Einsichten in neue Features von <a href="http://www.springframework.org">Spring 2.5</a>. 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.</p>
<p>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.</p>
<p>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 <code class="language-plaintext highlighter-rouge"><context:load-time-weaver /></code> wählt Spring automatisch den zur Plattform passenden Loadtime Weaver aus und man kann damit transparent vom einer SE Umgebung in den Tomcat wechseln.</p>
<p>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.</p>
<p>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.</p>
Eberhard Wolff - Spring Portfolio2008-03-03T10:30:33+01:00http://www.odrotbohm.de/2008/03/eberhard-wolff-spring-portfolio<p>Nach eine kurzen organisatorischen Einführung begann <a href="http://jandiandme.blogspot.com/">Eberhard</a> mit einem Ãœberblick über OSGi, das dynamische Komponentenmodell für Java. Danach stellte er <a href="http://www.springframework.org/osgi">Spring OSGi</a> 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.<!--more--></p>
<p>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.</p>
<p>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 <a href="http://www.springide.org/blog/">SpringIDE</a> 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.</p>
Spring Release Party2008-03-03T08:36:11+01:00http://www.odrotbohm.de/2008/03/spring-release-party<p>Gleich gehts auf nach Stuttgart zur Spring Release Party. Diesmal findet die Party <strong>nach</strong> dem Release von Spring 2.5 vor etwa 4 Monaten. Bei der <a href="http://www.jugs.de/protokolle2006.html#300306">letzten Party</a> war man ja etwa 6 Monate zu früh ;). Der Event scheint sich zu einem festen Termin bei Spring Releases zu etablieren.</p>
Neue Four Sided Cube Platte am 8.2.20082008-02-01T22:03:05+01:00http://www.odrotbohm.de/2008/02/neue-four-sided-cube-platte-am-822008<p><img src="http://www.olivergierke.de/wordpress/wp-content/uploads/2008/02/cdteaser_datum.jpg" alt="CD Teaser 4" /></p>
<p>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.</p>
<p>Ordern könnt ihr die Platte über die <a href="http://www.foursidedcube.de">Webseite</a>. Im Rhein-Neckar Raum werden wohl auch die Großhandelsketten versorgt.</p>
Googles Android2007-11-14T12:04:43+01:00http://www.odrotbohm.de/2007/11/googles-android<p>Vor ein paar Tagen hat <a href="http://www.google.de" title="Google" target="_blank">Google </a>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…<!--more--></p>
<p>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.</p>
<p>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.</p>
<p>Wer mag kann sich ja mal das <a href="http://code.google.com/android/intro/tutorial.html" title="Android tutorial" target="_blank">Tutorial</a> anschauen. Es liefert einen guten Ãœberblick über die Technologie und das Arbeiten mit dem SDK.</p>
13949712720901ForOSX2007-11-05T13:43:44+01:00http://www.odrotbohm.de/2007/11/13949712720901forosx<p>“Hö, wie bitte?”, dachte ich, als ich diese Zeichenkette im <a href="http://www.retokiefer.com/archives/13949712720901forosx/">Blog eines Bekannten</a> 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…</p>
Four Sided Cube mit neuer Hompage2007-10-13T18:00:54+02:00http://www.odrotbohm.de/2007/10/four-sided-cube-mit-neuer-hompage<p>Wie ihr <a href="http://www.foursidedcube.de">hier</a> 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…</p>
Domainumzug2007-09-27T15:56:22+02:00http://www.odrotbohm.de/2007/09/domainumzug<p>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…</p>
Neues von Four Sided Cube2007-08-12T13:31:05+02:00http://www.odrotbohm.de/2007/08/neues-von-four-sided-cube<p>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 <a href="http://www.flickr.com/photos/90861917@N00/">Flickr</a>.</p>
<p>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.</p>
Dixie Chicks - Shut up and sing2007-08-12T13:24:58+02:00http://www.odrotbohm.de/2007/08/dixie-chicks-shut-up-and-sing<p>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:</p>
<blockquote>**"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." <cite>- </cite>**<cite style="font-style: normal">Natalie Maines</cite></blockquote>
<p>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.</p>
<p>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.</p>
<p>Der Film läuft aktuell in deutschen Kinos, das Video sowie die Liveperformance bei den Grammyawards (äußerst sehenswert) habe ich unten verlinkt.</p>
<ul>
<li>[Webseite zum Film](http://www.shutupandsing.de/)</li>
<li>["Not ready to make nice" Musikvideo @ YouTube](http://www.youtube.com/watch?v=fwc5YSAc-7g)</li>
<li>["Not ready to make nice" Live performance bei den Grammy Awards @ YouTube](http://www.youtube.com/watch?v=o-lJu5ibAM8)</li>
</ul>
Drum CLinic mit Ralf Gustke, Wolfgang Haffner und Felix Lehrmann im Rock Shop Karlsruhe2007-04-28T20:17:57+02:00http://www.odrotbohm.de/2007/04/drum-clinic-mit-ralf-gustke-wolfgang-haffner-und-felix-lehmann-im-rock-shop-karlsruhe<p>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.<!--more-->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 ;).</p>
<p>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 ;).</p>
<p>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 ^^.</p>
<p>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.</p>
<p>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…</p>
AOP Logging ist kein Logging - oder wie IT Zeitschriften erheblich nachlassen...2007-04-03T13:27:51+02:00http://www.odrotbohm.de/2007/04/aop-logging-ist-kein-logging-oder-wie-it-fachzeitschriften-erheblich-nachlassen<p>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…<!--more--></p>
<p>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.</p>
<p>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.</p>
<p>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…</p>
Recordingworkshop an der Popakademie2007-01-21T21:59:35+01:00http://www.odrotbohm.de/2007/01/recordingworkshop-an-der-popakademie<p>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.<!--more-->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.</p>
<p>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.</p>
<p>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.</p>
<ul>
<li>[Popakademie](http://www.popakademie.de)</li>
</ul>
Joy Denalane zum Thema "Artist Development" @ Popakademie2007-01-17T12:32:56+01:00http://www.odrotbohm.de/2007/01/joy-denalane-zum-thema-artist-development-popakademie<p>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…<!--more-->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 ;).</p>
<p>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.</p>
<ul>
<li>[www.joydenalane.de](http://www.joydenalane.de)</li>
</ul>
Vortrag - Komponentenbasierte Softwareentwicklung in PHP2007-01-12T13:43:37+01:00http://www.odrotbohm.de/2007/01/vortrag-komponentenbasierte-softwareentwicklung-mit-php<p>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.</p>
<ul>
<li>[PHP User Group Frankfurt](http://www.phpugffm.de)</li>
<li>[Komponentenbasierte Softwareentwicklung mit PHP](http://www.olivergierke.de/wordpress/wp-content/uploads/2007/01/oliver-schlicht-komponentenbasierte-softwareentwicklung-mit-php.pdf)</li>
<li>[Blogeintrag zum Thema](http://phpugffm.de/index.php/archives/126)</li>
<li>[Garden](http://garden.tigris.org)</li>
</ul>
FESTival 2006 - Neues von Four Sided Cube2006-12-01T18:02:01+01:00http://www.odrotbohm.de/2006/12/festival-2006-neues-von-four-sided-cube<p>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.</p>
<p>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 ;)</p>
<ul>
<li>[Webseite zum FESTival](http://festival.foursidedcube.de)</li>
</ul>
Mein Weg zu Spring2006-10-21T23:09:08+02:00http://www.odrotbohm.de/2006/10/mein-weg-zu-spring<p>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…<!--more-->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.</p>
<p>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.</p>
<p>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.).</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<ul>
<li>[Springwebsite](http://www.springframework.org)</li>
<li>[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</li>
<li>[What's new in Spring 2.0](http://static.springframework.org/spring/docs/2.0.x/reference/new-in-2.html)</li>
</ul>
Wallis Bird2006-10-15T16:24:10+02:00http://www.odrotbohm.de/2006/10/wallis-bird<p>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.<!--more--></p>
<p>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.</p>
<p>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!</p>
<ul>
<li>[Wallis Bird Homepage](http://www.wallisbird.de)</li>
<li>[Wallis Bird @ Myspace](http://www.myspace.com/wallisbird)</li>
</ul>
Neues Template2006-10-15T16:08:22+02:00http://www.odrotbohm.de/2006/10/neues-template<p>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.</p>
<p>Viel Spass damit…</p>
Barfuss in Bildern2006-10-01T19:08:54+02:00http://www.odrotbohm.de/2006/10/barfuss-in-bildern<p>Gestern früh fand das Fotoshooting für die Barfuss Platte statt. Ich hatte <a href="http://www.fotocommunity.de/pc/account/myprofile/544103">Nico Becherer</a>, 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.<!--more--></p>
<p>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 <a href="http://www.fotocommunity.de/pc/pc/mypics/544103" target="_blank">Gallerie in der Fotocommunity</a> bekommen. Ich setz mich dann mal an die Coverentwürfe ;)</p>
Bilder vom Gig bei Rock @ Church2006-09-12T20:49:54+02:00http://www.odrotbohm.de/2006/09/bilder-vom-gig-bei-rock-church<p>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 <a href="http://www.myspace.com/oliverschlicht">Myspace Account</a> hochgeladen. Glücklicherweise kann man die Slideshow auch recht leicht in Webseiten einbinden ;) Et voila.</p>
<p>Die Bilder stammen von einer sehr nette Photografin namens Jutta Leiske (<a href="http://www.fokus-eventphotos.de">www.fokus-eventphotos.de</a>), 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.</p>
Hallo mal wieder2006-09-02T12:29:50+02:00http://www.odrotbohm.de/2006/09/hallo-mal-wieder<p>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:</p>
<ul>
<li>links findet ihr immer die aktuellsten Dates, wie sie auch auf der Soulism Seite zu finden sind</li>
<li>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 <a href="http://www.last.fm/">www.last.fm</a>. Vielleicht schaut ihr euch den ein oder anderen ja mal an<!--more--></li>
</ul>
<p>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.</p>
<p>Ãœ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. <a href="http://www.bandits-dresden.de/">www.bandits-dresden.de</a></p>
<p>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 <a href="http://www.fortyfour./">www.fortyfour.biz</a></p>
<p>Soweit erstmal…
REINHAUN!</p>
Es tut sich was2006-05-01T20:06:28+02:00http://www.odrotbohm.de/2006/05/es-tut-sich-was<p>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.</p>
<p>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.<!--more--> 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.</p>
<p>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.</p>
<p>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 <a href="http://www.oliverschlicht.de/wordpress/www.soulism.de">www.soulism.de</a></p>
<p>Es scheint ein spannender Sommer zu werden ;)</p>
Quo vadis 2006?2005-12-14T12:10:12+01:00http://www.odrotbohm.de/2005/12/quo-vadis-2006<p>Hallo zusammen,</p>
<p>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.<!--more--></p>
<p>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</p>
SPAX Projekt am Start / Bandtreffenupdate2005-08-13T16:02:12+02:00http://www.odrotbohm.de/2005/08/spax-projekt-am-start-bandtreffenupdate<p>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.<!--more--></p>
<p>Mehr Informationen findet ihr unter <a href="http://www.oliverschlicht.de/wordpress/www.allcityallstars.de">www.allcityallstars.de</a>, zu kaufen gibts die Scheibe im Shop von www.mzee.com</p>
<p>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… ;-)</p>
<p>So long…</p>
Clueso Remixcontestergebnisse / Neues Projekt2005-07-09T14:23:57+02:00http://www.odrotbohm.de/2005/07/clueso-remixcontestergebnisse-neues-projekt<p>Seit circa 1,5h sind die Ergebnisse des Contests online. Leider haben wir es nicht unter die Topplätze geschafft. Ein besuch von <a href="http://www.start-ab.com" target="_blank">www.start-ab.com</a> lohnt sich jedoch trotzdem - es gibt viele gute Remixe dort.</p>
<p>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.</p>
<p>Ich freu mich auf eine aufregende Woche und einen geilen Gig ;-)</p>
<p>Bis dann</p>
Remixcontestsong online2005-06-05T19:54:56+02:00http://www.odrotbohm.de/2005/06/remixcontestsong-online<p>Da nun alle Remixe zum Contest online sind, hier auch nun mein Beitrag.</p>
<p><a href="http://www.soulism.de/soulismv2/content/e306/furtherContent308/projects452/mediaList/files456/pizzaschachteln_113remix.mp3">Clueso - Pizzaschachteln (113 Remix)</a></p>
<p>Der Vollständigkeit halber noch die Credits:</p>
<p>Thomas Hübner: Vocals
Isabel Haist: Vocals
Friedemann Schreiter: Piano
Martin Schneider: Gitarre
Oliver Schlicht: Drums/Bass/Gitarre/Klavier</p>
<p>Aufnahme, Produktion, Mischung, Mastering: Oliver Schlicht</p>
<p>Mal schauen was draus wird ;-)</p>
Clueso Remix Context dieses Wochenende2005-06-04T19:51:14+02:00http://www.odrotbohm.de/2005/06/clueso-remix-contest-dieses-wochenende<p>Dieses wochenende findet über das Webportal <a href="http://www.start-ab.com">www.start-ab.com</a> 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…</p>
<p>stay Tuned…</p>
Updates... was geht momentan?2005-04-01T17:30:30+02:00http://www.odrotbohm.de/2005/04/4<p>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 ;-)<!--more--></p>
<p>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…</p>
<p>Morgen kommt meine (ehemalige) Bandkollegin Goeschi zu mir ins Studio - wir recorden ein paar Songs und sammeln Material für zukünftige Releases.</p>
<p>Weiterhin arbeite ich mit RKEE (dem Pianisten aus der Liveband vom Dita Rantel - <a href="http://www.rkee.net">www.rkee.net</a>) am Feinschliff eine EP für einen Rapper namens Deckah (<a href="http://www.deckah.de">www.deckah.de</a>). 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.</p>
<p>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 ;-)</p>
<p>So, soweit erstmal… Bis zum nächsten mal.</p>
So viel neues...2005-02-13T14:12:24+01:00http://www.odrotbohm.de/2005/02/so-viel-neues<p>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.</p>
<p>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 ;-)</p>
<p>So, hier noch der Flyer für den Gig am 26. Vorbeikommen lohnt sich!!</p>