SpringSource Produktivitätsoffensive
May 9th, 2009 by P.G.Taboada

Diese Woche haben wir zwei großartige Nachrichten aus der SpringSource Ecke bekommen:



Bei STS handelt es sich um eine Eclipse-basierte IDE, die bisher nur den “Enterprise- Kunden” vorbehalten war. Es ist die Zusammenstellung von Spring IDE und andere Plugins aus der SpringSource Softwareschmiede:

Key Highlights von der Produktseite:

  • Greater Productivity
  • OSGi Made Easy
  • Developer Onramp to Virtualization
  • Task Focused Development
  • Guided Learning

Bei Spring Roo handelt es sich letztendlich um die Umsetzung von Rod Johnsons Aussage:

We (the Java EE Community) are not picking the low hanging fruits

Und damit hat er recht: wir haben mit Java EE sehr mächtige Frameworks, scheitern aber kläglich daran, daraus ordentliche “full stack application frameworks” zu bauen. Die Quittung haben wir mit “Ruby on Rails” und Konsorten bekommen: erst haben wir sie belächelt, dann diese für Prototypen eingesetzt. Jetzt lautet es “success stories” aus allen Ecken. Mit Spring Roo bekommen wir ein “full stack application framework“, das diesmal aber in Java mit Java Tools und Technologien umgesetzt wurde (Maven2, JPA, JUnit, Spring MVC, Spring Security, u.s.w.).

“Roo delivers productivity without compromise. Spring Roo melds the development advantages that have emerged in dynamic frameworks with the robustness, reliability, performance and familiarity of enterprise Java. Roo is designed for developers that want to build Java applications faster than ever without having to learn a new language or syntax. Roo is designed to be incorporated into the majority of development environments including visual development tools and utilizes the widely understood implementations of relevant standards.” (Quelle:

Die Spring Roo Seite verrät zur Zeit sehr wenig – nicht einmal, wie man Spring Roo aktuell runterladen kann. Hier muss man die Blogosphäre aus dem Umfeld im Radar haben:

Ich habe das Gefühl, dass die Java-Gemeinde endlich aufatmen kann, denn jetzt hat man eine Alternative zu Ruby on Rails, Grails und Co. Es wird sich zeigen, wie tief Spring Roo in den Kinderschuhen steckt, und ob SpringSource “den Kampf” an einer weitere Front aufnehmen kann. SpringSource scheint wieder die OSS Community entdeckt zu haben (die Community darf sogar  bei der Namensfindung mithelfen), und spielt zu meiner Freude die Karte gross aus.

How to use the SimpleHttpInvokerServiceExporter
Feb 26th, 2009 by P.G.Taboada

The JRE 1.6 ships with small HTTP-Server implementation. The Javadocs can be found here.

Spring has provides many different ways of configuring remote access to beans (aka spring remoting), but the remoting documentation fails when it comes to the usage of the HTTP Service exporter that works with the new JRE 1.6 HttpServer.

So here is a small example on how wire up the embedded JDK HttpServer and spring remoting.

Read the rest of this entry »

Stop this “my support is better than yours” discussion!
Aug 30th, 2008 by P.G.Taboada

Ok, someone is making money with support.
Ok, someone is not contributing to OSS.
But wait – is offering support not exactly that? Contributing to OSS by doing the dirty work no one wants to do?

That’s why I do not agree entirely with the label “parasites”. It is not easy to offer support, IMHO it is a Job that no one likes to do. I don’t know if it is true for everyone – but I am very happy to be a developer and not to be a support guy.

Read the rest of this entry »

SpringSource announces an application plattform
May 5th, 2008 by P.G.Taboada

SpringSource recently announced the Spring Aplication Platform, and this announcement is generating a lot of fuss. Google has recently launched the Google App Engine. From an Java enterprise developers point of view it is shamelessly easy to use, deploy, etc. Well, unfortunately it only takes Python apps for now, but it is stated that there will be more languages supported in the future. But it’s Google again putting its finger into the Java EE wound (first GWT with webapps, then Android shaking the Java ME world, and now App Engine showing how runtimes should look like).

Looking at Googles App Engine I thought how nice it would be to have the deployment, packaging and runtime of Java EE applications redesigned.  Those deployment descriptors really suck. As it seems (heard it at the Jax from speakers “off the record”) Java Dynamic Modules and Java Superpackages aren’t going to make it into the next Java relase – Java 7.

From this point of view, the Spring Application Platform is bringing fresh air into the Java EE development. The Java EE dream of a runtime didn’t come through. Modularization got lost somewhere in the way. Packaging and deployment is a nightmare, and tools didn’t solve the problem. Since Java EE 5 is being adopted very slowly and Java EE 6 is really far away, this is surely the best time to drop in an alternative. Well done. Though beeing an alternative, there seems to be some level of commitment regarding Java EE deployment support.

IMHO the real shock came with the change in licensing terms. We are used to SpringSource licensing their products under the Apache 2 license. The license is clear and accepted by most companies. The Spring Application Platform is licensed under the GPL. GPL is, IMHO, the most misunderstood license we have in the OSS. I do not have nothing against the GPL, I only have a problem with the different interpretations. And if a license can be misunderstood, how can we rely on it? I won’t start another blog about how GPL works – please go read the GPL and the GPL FAQ, it’s worth it. A nice reply from Will Hartung about GPL on the TSS thread can be found here.

Does nobody actually, you know, READ these licenses?
Users who change GPL code have absolutely no, zero, zippo, big bagel, goose egg obligation to give back to “the community”.
I can take this code, make all the changes I want, sell it to my customers, and you can come knock on my door saying “I want the code, it’s GPL! Give me the code!” and I can nod and smile knowingly and tell you to pound sand. “Give me $100K and I’ll give you the software.

Thanks Will. It’s beautiful.

Rod argues that if someone takes the code, makes changes and starts selling it, this someone will, sooner or later, have to provide the source code to a major number of customers and hence the changes will be available for the community, especially for SpringSource. Rod, I hope I did quote you right, sorry if I didn’t.

Another great statement from Will comes a few postings later:

But you certainly aren’t going to take back contributions that don’t have at least shared copyright, because as soon as that happens you can’t relicense the whole under something other than GPL. So, there’s not a whole lot of value to the community there.

Later Rod makes a nice statement about what’s ok:

1. Using the platform to run closed source applications is OK. This immediately covers the vast majority of companies and developers who are end users. This would cover for example, software use by companies like Google, banks, media companies etc.
2. Modifying and extending the platform and “hiding” (closing) it is OK, unless you redistribute. So if you modify it in your own company, or you modify it and distribute your modifications in GPL open source, that’s OK. If you modify it and distribute a closed source product including those modifications, that is not OK. This would exclude Oracle, for example, from modifying the server and redistributing it as a closed source product. We believe this is a Good Thing.
3. It is fine to run closed source applications on the platform. Whether you can redistribute them as one closed product (bundling the platform) would depend if they constituted a derivative work.

I liked this one too:

Wow, 174 replies and counting, mostly about GPL, hmm, i knew I should have done law!!! ha ha
Lets stay technical please, even though it clearly doesn’t pay !!!

This is perfectly showing how GPL, although commonly used in OSS projects, is really badly misunderstood by people.

IMHO GPL licensing was a bad idea. SpringSource targets the enterprise, the enterprise dislikes GPL, that’s a fact. Linux seems to be the exception to the rule. It’ nice to see how SpringSource understands GPL – but this understanding is not binding. What if someone wakes up next week and says – “oh sorry, I think we have to rethink our GPL understanding….”

Security Anforderungen 2.0: Gruppen, Rollen, Flexibilität
Apr 28th, 2008 by P.G.Taboada

Was habe ich mich gefreut, als Jira das Sicherheitskonzept um Rollen (Projekt-Rollen) erweitert hat. Statt Rechtekonfigurationen an Benutzergruppen zu binden, hat man jetzt die Möglichkeit Rechte an bestimmte Rollen zu binden. Für jedes Projekt folgt dann die Benutzer/ Rolle Zuweisung: dadurch ergibt sich letztlich, welche Rechte ein Benutzer für ein bestimmtes Projekt haben wird.

Gerade in kleine, agil arbeitende Teams ist das wesentlich effizienter: in einem Projekt ist man der Projektleiter, bei einem anderem lediglich ein Entwickler. So flexibel wie Entwickler heute die Rollen wechseln müssen, so flexibel konfigurierbar muss heute auch unternehmenskritische Software sein. In der Vergangenheit musste man in Jira für jede mögliche Kombination der Rollen in einem Projekt entsprechende Benutzergruppen einführen. Benutzergruppen sind aber statisch/ global und nehmen keine Rücksicht auf besondere Projektgegebenheiten. Am Ende bekommt jedes Projekt eigene Benutzergruppen.

Die Einführung von Projektrollen und Sicherheitskonfigurationen für Projektrollen im Allgemeinen reduziert die Konfiguration drastisch. Danke Atlassian!

Ein Rollenmodell ist nicht mit den heute üblichen deklarativen Mitteln konfigurierbar. Wir scheitern an der instanzbasierten Sicherheit. Je nach Projekt hat der Benutzer andere Rollen. Um so wichtiger ist es, ein Security Framework zu wählen, mit dem man die nötige Flexibilität und die Möglichkeit bekommt, eigene Anforderungen umzusetzen.

Auch wenn JAAS ein beeindruckendes Werk ist, mangelt es meiner Meinung nach an Flexibilität. Anpassungen sind sehr schnell nicht mehr portabel, eine Bindung zu der Laufzeitumgebung und oder Infrastruktur ist das Ergebenis. Spring Security (formerly known as Acegi) ist hingegen sehr flexibel. Security wird dadurch nicht trivial, aber besondere Anforderungen und entsprechende Lösungsansätze scheitern nicht mehr an dem Framework.

Schade dass in der Spring Security Dokumentation zu diesem Thema nichts zu finden ist. Eine Interessante Ausarbeitung zum Thema Gruppen und Rollen auf Konzeptebene ist hier zu finden.

»  Substance:WordPress   »  Style:Ahren Ahimsa