WebServiceContext (manchmal) nicht mit OSGi injiziert - Apache Karaf

Question

Mein Team geerbt eine alte Codebasis auf Apache Karaf gebaut, und es hat einige JAX-WS-Dienste. Wir haben derzeit ein Problem damit, dass dieses Objekt nicht immer in die Bean injiziert wird.

Unser Service ist definiert als:

@WebService(serviceName = "XXXSoapService", portName = "XXXSoapPort", endpointInterface = "com.XXX.service.XXXSoapInterface", targetNamespace = "http://xxx.xx/") 
@BindingType(value=SOAPBinding.SOAP12HTTP_BINDING) 
public class XXXSoapService implements XXXSoapInterface { 
    @Resource 
    WebServiceContext context; 

    public void doXXX() { 
    context.getMessageContext(); // throws nullpointerexception 
    } 
} 

Wir haben bereits mehrere Möglichkeiten haben wir versucht, online zu finden. Wir haben die Setter-Injektion versucht, wir haben versucht, einen Namen für die Ressource anzugeben, und wir haben sichergestellt, dass die endpointInterface festgelegt wurde.

Unabhängig davon, was wir tun, wird der Dienst in den meisten Fällen instanziiert, ohne den WebServiceContext einzufügen. Manchmal funktioniert es, was uns glauben lässt, dass es mit der Funktionsweise von KARAF zu tun hat, und versucht, den WebServiceContext einzufügen, bevor er verfügbar ist.

Wir haben CXF in der org.apache.karaf.features.xml in einem featuresBoot-Abschnitt.

Mein Verständnis von OSGI und Karaf ist sehr einfach, daher weiß ich nicht wirklich, wonach ich suchen soll.

Hat jemand eine Vorstellung davon, warum der WebServiceContext die meiste Zeit nicht injiziert wird, aber es wird manchmal injiziert?

EDIT: Ich habe darüber gelesen, und es scheint eine Ausnahme, die ich mit Apache Blueprint habe etwas damit zu tun haben könnte:

[Blueprint Extender: 3] ERROR org.apache.aries.blueprint.container.BlueprintContainerImpl - Unable 

Bauplan Behälter für Bündel zu starten io.hawt.hawtio-karaf-terminal/2.0.0 wegen nicht aufgelöster Abhängigkeiten [(objectClass = org.apache.felix.service.threadio.ThreadIO), (objectClass = org.apache.felix.service.command.CommandProcessor)] java.util.concurrent.TimeoutException bei org.apache.aries.blueprint.container.Blue printContainerImpl $ 1.run (BlueprintContainerImpl.java:371) bei org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run (DiscardableRunnable.java:48) bei java.util.concurrent.Executors $ RunnableAdapter.call (Executors.java:511) bei java.util.concurrent.FutureTask.run (FutureTask.java:266) bei java.util.concurrent.ScheduledThreadPoolExecutor $ ScheduledFutureTask.access $ 201 (ScheduledThreadPoolExecutor.java:180) auf Java. util.concurrent.ScheduledThreadPoolExecutor $ ScheduledFutureTask.run (ScheduledThreadPoolExecutor.java:293) bei java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1149) bei java.util.concurrent.ThreadPoolExecutor $ Worker.run (ThreadPoolExecutor. Java: 624) bei java.lang.Thread.run (Thread .java: 748)

Ich werde in die Abhängigkeiten für dieses Modul schauen, aber kann das der Grund sein? Irgendwelche anderen Ideen?

Answer 1

Gefunden eine Lösung, aber ich bezweifle, dass es die Lösung ist. Es ist eher eine Arbeit.

Ich habe javaee-api-7.0.jar zu einem Ordner mit Abhängigkeiten hinzugefügt, die wir immer laden, wenn Karaf startet, und es hat plötzlich jedes Mal angefangen zu arbeiten. Es injiziert nun den WebServiceContext wie erwartet.

Was es nicht erklärt ist, warum es einige Male zuvor funktioniert hat. Wenn es eine fehlende Abhängigkeit wäre, würde es nie funktionieren.Meine Vermutung ist, dass einige Abhängigkeiten zu spät geladen wurden, und es würde die meiste Zeit fehlschlagen, und jetzt, da ich es in diesem Ordner von Abhängigkeiten einschließe, wird es beim Start oder früh genug in dem Prozess geladen. Ich verstehe ehrlich nicht, was passiert.

Ich schreibe diese Antwort, weil es jemand anderen helfen könnte, aber ich werde es nicht als gelöst markieren, weil ich nicht glaube, dass es die eigentliche Lösung ist. Wenn jemand eine richtige Lösung hat, bitte wegschiessen.