[
https://issues.apache.org/jira/browse/AXIS2-4847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13902705#comment-13902705
]
Andreas Veithen commented on AXIS2-4847:
----------------------------------------
First of all, I agree with Ancoron Luciferis that the current code uses managed
services in a very strange way. In addition to the points already mentioned,
one can also note that the code actually doesn't use the configuration provided
by the configuration manager at all...
But let's for the moment concentrate on the issue that causes the error. If I
understand this correctly, there are two issues:
1. The code shouldn't call the "updated" method synchronously and instead let
the config admin call it asynchronously.
2. To register the servlet, one needs a reference to the HttpService as well as
the ConfigurationContext. In the current code there is a service tracker (see
the Activator.HttpServiceTracker) that looks for HttpService and once that
service becomes available, it uses getServiceReference/getService to get a
reference to the ConfigurationContext. That pattern is of course incorrect
because it assumes that the ConfigurationContext is already registered when the
HttpService becomes available, but that is not necessarily the case.
The thing is that if one addresses problem 1 by removing the call to the
"updated" method in the bundle activator (as Andy did in his patch), then one
runs inevitably into the second issue. Andy's patch addresses problem 2 by
using SCR because that makes it easy to express a dependency on multiple
services that must be available at the same time.
I was wondering if it would not more elegant to use a different approach based
on the [whiteboard
pattern|http://felix.apache.org/documentation/subprojects/apache-felix-http-service.html#using-the-whiteboard].
In that case, one would simply have a ServiceTracker that looks for the
ConfigurationContext and then registers the HttpServlet as an OSGi service. The
HTTP whiteboard support would then register that servlet automatically with the
HttpService, i.e. the Axis2 code no longer depends directly on HttpService.
> IllegalStateException: Can only register services while bundle is active or
> activating.
> ---------------------------------------------------------------------------------------
>
> Key: AXIS2-4847
> URL: https://issues.apache.org/jira/browse/AXIS2-4847
> Project: Axis2
> Issue Type: Bug
> Affects Versions: 1.5.1
> Environment: Apache Felix Framework 3.0.2
> Reporter: Ancoron Luciferis
> Attachments: AXIS2-4847.patch
>
>
> I'm trying to run the axis2 OSGi version 1.5.1 inside a GlassFish 3.1
> (promoted build 23 currently) and facing the following problem:
> *ERROR* [org.osgi.service.cm.ManagedService, id=68, bundle=280]: Unexpected
> problem updating null
> java.lang.IllegalStateException: Can only register services while bundle is
> active or activating.
> at org.apache.felix.framework.Felix.registerService(Felix.java:2817)
> at
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:251)
> at
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:229)
> at
> org.apache.axis2.osgi.deployment.OSGiConfigurationContextFactory.updated(OSGiConfigurationContextFactory.java:107)
> at
> org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.run(ConfigurationManager.java:1112)
> at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:88)
> And because of that I then get:
> org.osgi.framework.BundleException: Activator start error in bundle
> org.apache.axis2.osgi [280].
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:1864)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:1734)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:905)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:892)
> at com.profitbricks.osgi.test.FelixTest.testModules(FelixTest.java:241)
> Caused by: java.lang.NullPointerException: Specified service reference cannot
> be null.
> at
> org.apache.felix.framework.BundleContextImpl.getService(BundleContextImpl.java:319)
> at
> org.apache.axis2.osgi.internal.Activator$HttpServiceTracker.addingService(Activator.java:79)
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:896)
> at
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:261)
> at
> org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:184)
> at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:339)
> at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:273)
> at org.apache.axis2.osgi.internal.Activator.start(Activator.java:50)
> at
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:633)
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:1817)
> ... 33 more
> When I read the code I don't really understand why the implementor chose
> "ManagedService" for the "OSGiConfigurationContextFactory" as it really
> should be a "ManagedServiceFactory". Additionally manually invoking the
> "updated" method within the activator code is counter-productive, as it is
> called automatically (and must be called asynchronously) by the OSGi
> Config-Admin.
> See sections 104.15.9 and 104.15.10 of the OSGi Compendium spec v4.2.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org
For additional commands, e-mail: java-dev-h...@axis.apache.org
