2017-03-22 1 views
1

J'ai créé une distribution maven en utilisant karaf-maven-plugin.org.apache.aries.transaction.blueprint/1.1.1 impossible d'obtenir javax.transaction.TransactionManager

J'ai créé projet Maven en utilisant

mvn archetype:generate -DarchetypeGroupId=org.apache.karaf.archetypes -DarchetypeArtifactId=karaf-assembly-archetype -DarchetypeVersion=4.1.0

j'ai ajouté des fonctionnalités suivantes:

   <bootFeatures> 
        <feature>standard</feature> 
        <feature>jpa/2.5.0</feature> 
        <feature>transaction-api/1.2.0</feature> 
        <feature>transaction</feature> 
        <feature>eclipselink</feature> 
        <feature>pax-jdbc-config</feature> 
        <feature>pax-jdbc-postgresql</feature> 
       </bootFeatures> 

Lorsque je télécharge karaf 4.1.0 la distribution à partir du site Apache, et installer des fonctionnalités en utilisant la fonction : installer, tout fonctionne bien, cependant, dans la distribution construite par le plugin, je reçois l'erreur:

Unable to start blueprint container for bundle org.apache.aries.transaction.blueprint/1.1.1 due to unresolved dependencies [(objectClass=javax.transaction.TransactionManager)] java.util.concurrent.TimeoutException at org.apache.aries.blueprint.container.BlueprintContainerImpl$1.run(BlueprintContainerImpl.java:371) [15:org.apache.aries.blueprint.core:1.7.1] at org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48) [15:org.apache.aries.blueprint.core:1.7.1] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?] at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:?] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:?] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [?:?] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:?] at java.lang.Thread.run(Thread.java:745) [?:?]

2017-03-22T11:03:51,401 | ERROR | Blueprint Extender: 1 | BlueprintContainerImpl | 15 - org.apache.aries.blueprint.core - 1.7.1 | Unable to start blueprint container for bundle org.apache.aries.transaction.blueprint/2.1.0 due to unresolved dependencies [(objectClass=javax.transaction.TransactionManager)] java.util.concurrent.TimeoutException at org.apache.aries.blueprint.container.BlueprintContainerImpl$1.run(BlueprintContainerImpl.java:371) [15:org.apache.aries.blueprint.core:1.7.1] at org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48) [15:org.apache.aries.blueprint.core:1.7.1] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?] at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:?] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:?] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [?:?] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:?] at java.lang.Thread.run(Thread.java:745) [?:?]

que j'ai trouvé le service dans le registre OSGi dans la console Web:

Service 266 - [org.apache.aries.transaction.AriesTransactionManager, javax.transaction.TransactionManager, javax.transaction.TransactionSynchronizationRegistry, javax.transaction.UserTransaction, org.apache.geronimo.transaction.manager.RecoverableTransactionManager] (pid: n/a) 
    from Bundle 143 - Apache Aries Transaction Manager (org.apache.aries.transaction.manager), version 1.3.2 
    service.bundleid: 143 
    service.scope: singleton 

Qu'est-ce qui ne va pas ici? Est-ce que le plugin maven fait quelque chose de mal, ou le problème est que ce plugin utilise une version instable des artefacts?

Répondre

1

Sans regarder le câblage de vos bundles OSGi, il n'est pas possible d'en être certain, mais l'explication la plus probable est due au paquet javax.transaction toxique. Lors de la spécification de JTA, il est devenu clair que certains types de "core Java" nécessaires pour implémenter certaines interfaces JTA, par exemple, les objets Connection SQL ont besoin d'un XAResource associé. Cela a forcé une partie de l'API JTA dans Java de base, mais plutôt que de placer l'API complète dans l'environnement de base, seuls quelques types ont été ajoutés. Cela conduit à un paquetage partagé entre Java Runtime et JTA, et provoque de gros problèmes dans les systèmes modulaires (qui ne permettent normalement pas de voir le même paquet de plusieurs sources simultanément)

Dans ce cas, le service Gestionnaire de transactions doit utiliser l'API JTA à partir d'un ensemble déployé à l'intérieur de l'infrastructure OSGi (l'environnement d'exécution de base n'inclut pas l'interface TransactionManager) L'ensemble consommant, d'autre part, importe probablement javax.transaction de l'ensemble système (ie l'environnement d'exécution Java). Comme ces deux bundles ne partagent pas une vue de l'API de service, ils ne peuvent pas partager le service OSGi

La seule façon de résoudre ce problème consiste à placer l'API JTA sur le chemin d'accès aux classes Java et à l'exposer via le bundle système. une t la version correcte en utilisant une propriété de lancement telle que:

org.osgi.framework.system.packages.extra=javax.transaction;version=1.2