Invalid property ‘cacheTarget’ of bean class [org.springframework.osgi.service.exporter.support.OsgiServiceFactoryBean]

Okay, so I’ve lost so much time on this incredibly stupid issue, and Google wasn’t of much help that I thought I’d blog about it as a memo for myself and for others.

here’s the setup : I’ve created an osgi bundle (using PDE new plugin wizard), created a class (implementing an interface) and tried to export it as an OSGi service using Spring DM.

I used Spring IDE tooling to generate my bundle’s context xml files (I tend to follow the Spring DM best practices in separating the bundle’s context in 2 xml files, one for the regular Spring setup, the other for OSGi interactions).

Anyway, the first xml file simply declares a Spring bean :

Read more of this post

Inclusion dynamique de ressources Spring

Une super astuce que je viens de tomber dessus sur le blog de Zenika : merci à eux de partager celà :)

Il s’agit de controler l’inclusion de fichiers de configuration Spring via une property passé à la JVM :

<import resource="${env}-infrastructure.xml"/>

puis passer l’argument :

-Denv=prod

ou encore

-Denv=dev

Par exemple, selon que l’on est en mode développement ou en mode production.

J’adore ! surtout pour l’inclusion des fichiers .properties 🙂

Le billet qui présente cette technique.

Sortie de Spring DM Server 2.0 M1

SpringSource frappe fort : ils viennent d’annoncer la sortie du premier milestone de DM Server 2.0.
J’ai pas vu le coup venir : rien qu’Hier, Rob Harrop a publié un billet où il parle de leurs plans pour Spring DM Server 2, et e lendemain, ils publient un premier milestone …

Voici rapidement les quelques nouveautés apportées par cette version :

[Suite:]

=> Utilisation de Scrum comme processus de développement (c’est bien comme ça qu’on l’appèlle hein ?)
=> Premier support de la notion de plans : pensez les features d’Eclipse. Je tiens à préciser que j’avais abandonné DM Server 1 à cause de la notion de PAR, une sorte de regroupement de bundles dans un archive, ce qui va tout simplement à l’encontre de l’essence de l’OSGi. Avec les plans, un simple descripteur xml d’un ensemble de bundles, je crois qu’une ré-évaluation des choses s’impose :D
=> Premier support de la notion de cloning : j’ai pas encore approfondi ma lecture la dessus, je peux donc pas présenter ce que c’est.

Voici maintenant quelques liens clés :
=> Annonce
=> Téléchargement
=> Release notes
=> Doc : Getting Started, User Guide, Dev Guide

—-

Sortie du second Milestone de Spring Dynamic

Spring Dynamic Modules permet de réconcilier le modèle de développement de Spring Framework avec celui d’OSGi, et ce via l’ajout d’un namespace osgi utilisable dans les fichiers de configuration de Spring qui permettent entre autre d’importer un service OSGi en tant que Bean Spring ainsi que d’exporter un Bean Spring en tant que service OSGi.

Aujourdhui, le second milestone de Spring dynamic Modules (spring DM) est sorti, apportant comme nouveautés :

[Suite:]

  • Passage à Spring 2.5.6
  • Mise à jour des dépendances ves les modules Spring pour refléter les nouveaux noms de ceux-ci
  • Support des services compendium via le namespace compendium
  • etc.

Les liens qu’il vous faut :

=> Télécharger
=> Documentation
=> FAQ
=> Changelog

—-

Sortie de Spring Framework 2.5.6

La première version de maintenance de Spring Framework après la décision de ne plus les fournir librement après les premiers 3 mois puis le revirement de la situation est maintenant disponible avec la publication de la 2.5.6 qui apporte principalement :

  • Près de 100 bugs résolus
  • Passage à des versions plus récentes pour des libs externes (EclipseLink, AspectJ, etc.)
  • Entêtes OSGi révisées

Les liens importants :

[Suite:]

=> Annonce
=> Documentation
=> Changelog
=> Télécharger (ça c’est pour la version community (ou gratuite), et le lien que je donne vous fait sauter un formulaire à remplir (ou a ignorer) proposé par le lien original que voici)

—-

Changement de politique de maintenance de Spring

C’est officiel : Rod Jonhson vient de poster un billet sur le blog officiel de SpringSource pour dire qu’il ont effectué une sorte de refactoring sur leur nouvelle politique de maintenance annoncée il y’a peu et qui a causé, pour rester en un doux euhémisme, de violentes réactions de la communauté (genre 250 commentaires jusque là sur The Server Side).

Je suis encore en train de lire (et relire) l’annonce, mais une chose est sûre : SpringSource est revenu sur sa décision de changer la politique de maintenance de Spring Framework, en quotant Rod Jonhson :

Read more of this post

Bug bizarroïde, ou OSGi quand tu nous tiens …

Aujourd’hui, j’ai failli m’arracher les cheveux à cause d’un bug bizarre dans l’application sur laquelle on travaille (une application client/serveur à base d’Eclipse RCP côté client et Tomcat tournant comme service dans Equinox côté serveur avec Spring DM).

Pour expliquer la chose, on utilise un super petit plug-in développé par Martin Lippert appelé Spring Extension Factory. Ce plugin permet de faire en sorte que les vues et éditeurs Eclipse peuvent être déclarés dans l’applicationContext du plug-in (en tant que Spring beans quoi) ce qui permet de profiter de la DI par exemple. Plus précisément, dans notre cas ceci revient à injecter les proxies des services distants (sur le serveur) qui seront invoqués par remoting (via Hessian pour le moment, mais c’est interchangeable grâce à l’abstraction Spring du Remoting).

ça marchait impec jusqu’à aujourd’hui, où on avait besoin d’utiliser une vue définie dans un plug-in A dans une perspective définie par un plug-in B. Et hop, l’injection de dépendances ne marchait plus (un NPE à l’accès à une des dépendances)

[Suite:]

bon, heureusement que je me suis vite aperçu (enfin, plus d’une heure) que si j’utilisais les versions plus récentes de Spring Extension Factory (1.0.3 au lieu de 1.0.1) et de Spring DM (1.1.2 au lieu de 1.1.0), le problème n’est plus … Ouf !

Peut être que c’était Spring DM qui n’utilisait pas le classloader correct :

* fixed usage of incorrect class loader for imported services with client thread context class loader management

(tiré du changelog de la 1.1.2)

Mais bon, comme ça marche là, je vais pas bloquer la dessus :D

—-

Sortie de Spring Dynamic Modules 1.1.2

Une nouvelle version de maintenance de la branche 1.1 de Spring Dynamic Modules (DM) 1.1.2 vient de sortir.

Pour rappel, Spring DM permet d’intégrer les modèles de composition d’OSGi (externe) et de Spring Framework (interne), et ce en:
– Importer déclarativement des services OSGi en tant que beans Spring, qu ipourront ensuite participer au cycle habituel de Spring (AOP, DI, etc.)
– Exporter déclarativement des beans Spring comme services OSGi.

Read more of this post

Changement de la stratégie de maintenance de Spring Framework

SpringSource, anciennement Interface21, la boite derrière le très populaire Spring Framework vient d’annoncer (en fait, ça date de 2 jours, mais bon …) une nouvelle stratégie de maintenance de leur produit phare (Spring Framework) : En gros, et à partir de Septembre 2008 (nous y somme déjà), les versions de maintenance ne seront disponibles publiquement que pendant les 3 premier mois suivant la sortie du produit. Après cela, les mises à jour qui suivent ne seront disponibles que pour les client payants de SpringSource et ce pendant 3 ans …

Read more of this post

Sortie de SpringSource DM Server RC 2

Le second et dernier release candidate de SpringSource DM Server, anciennement appelé SpringSource Application Platform vient tout juste de sortir.

Pour rappel, SpringSource DM Server est une nouvelle génération de serveurs Java offrant OSGi comme modèle de programmation (qui utilise Spring Dynamic Modules en interne).

Quelques nouveautés:

[Suite:]

  • Renommage de SpringSource Application Platform à SpringSource DM Server
  • Utilisation de Tomcat 6.0.18
  • Quelques renommage de classes
  • Bug fixes

La version finale est prévue dans 2 semaines.

A noter qu’il faut s’enregistrer dans leur programme Beta pour pouvoir télécharger SpringSource DM Server.

—-