Hi All,
We encountered an issue in the Startup Order Resolver when incorporating
the Carbon Deployment framework into the Carbon UI Server.
Problem:
Carbon UI Server binds each web app to the transport layer via a
microservice (MSF4J). For each web app that will be deployed in the Carbon
UI Server, a corresponding Microservice will be registered (via OSGi bundle
context). Web app artifacts are discovered through the Carbon Deployment
framework. Therefore, the Carbon UI Server doesn't know how many app
artifacts are there pending to be deployed. It only knows that a particular
app artifact is being deployed and *n* number of artifacts deployed
previously (by incrementing a counter variable). Hence, the Carbon UI
Server cannot figure-out the number of Microservice instances that will be
registered in the server startup time. The msf4j-core bundle has declared
in its pom [1] to wait its activation until all Microservices are available
in the startup. So, the Startup Order Resolver monitors Microservice
registrations. As mentioned earlier, the Carbon UI Server bundle registers
Microservices into the OSGi environment without telling the Startup Order
Resolver that it provides the capability Microservice or the services count
(even we declared that the Carbon UI Server provides the Microservice
capability in its pom or via the CapabilityProvider interface, we don't
know the services count). Startup Order Resolver assumes that this "extra"
Microservice registrations have happened due to a developer mistakes and
prints the following error log.
[2017-09-13 18:06:49,526] WARN
{org.wso2.carbon.kernel.internal.startupresolver.StartupOrderResolver} -
Startup component carbon-deployment-service from
bundle(org.wso2.carbon.deployment.engine:5.1.0) is in the pending state
until Capability org.wso2.carbon.deployment.engine.Deployer from
bundle(msf4j-core:2.3.0.m2) is available as an OSGi service. Refer the
Startup Order Resolver documentation for information.
[2017-09-13 18:06:49,527] WARN
{org.wso2.carbon.kernel.internal.startupresolver.StartupOrderResolver} -
Startup component wso2-server-connector-sc from
bundle(org.wso2.carbon.connector.framework:4.4.26) is in the pending state
until Capability org.wso2.msf4j.internal.MicroservicesServerSC from
bundle(msf4j-core:2.3.0.m2) is available as an OSGi service. Refer the
Startup Order Resolver documentation for information.
[2017-09-13 18:06:49,528] WARN
{org.wso2.carbon.kernel.internal.startupresolver.StartupOrderResolver} -
Startup component wso2-microservices-server from
bundle(msf4j-core:2.3.0.m2) is in the pending state, because of the
Capability org.wso2.msf4j.Microservice from
bundle(org.wso2.carbon.uis.core:0.8.3.SNAPSHOT). If you've registered this
capability as an OSGi service, you need to declare it using the
Carbon-Component manifest header. Refer the Startup Order Resolver
documentation for information.
[2017-09-13 18:06:49,528] WARN
{org.wso2.carbon.kernel.internal.startupresolver.StartupOrderResolver}
- *Startup
component wso2-microservices-server from bundle(msf4j-core:2.3.0.m2) is in
the pending state, because of the Capability org.wso2.msf4j.Microservice
from bundle(org.wso2.carbon.uis.core:0.8.3.SNAPSHOT). If you've registered
this capability as an OSGi service, you need to declare it using the
Carbon-Component manifest header. Refer the Startup Order Resolver
documentation for information.*
[2017-09-13 18:06:49,529] WARN
{org.wso2.carbon.kernel.internal.startupresolver.StartupOrderResolver} -
Startup component carbon-transport-mgt from
bundle(org.wso2.carbon.core:5.2.0.m3) is in the pending state until
Capability org.wso2.carbon.deployment.engine.DeploymentService from
bundle(org.wso2.carbon.deployment.engine:5.1.0) is available as an OSGi
service. Refer the Startup Order Resolver documentation for information.
[2017-09-13 18:06:49,530] WARN
{org.wso2.carbon.kernel.internal.startupresolver.StartupOrderResolver} -
Waiting for a CapabilityProvider OSGi service to be registered from
bundle(org.wso2.carbon.uis.core:0.8.3.SNAPSHOT) with
providedCapabilityName: org.wso2.msf4j.Microservice. Refer the Startup
Order Resolver documentation for more information.
Suggesting Solution:
In the offline discussed had with Jayanga & ThusithaD, following was
suggested.
There should be a way to explicitly tell the Startup Order Resolver to
ignore an OSGI service registrations. This can be achieved with properties.
When registering a capability via the BundleContext, a property (e.g.
"SKIP_STARTUP_RESOLVER") can be set to true. When tracking services in the
Startup Order Resolver, it can skip the services that has the said property.
Dictionary<String, String> dictionary = new Hashtable<>();
dictionary.put("CHANNEL_ID", httpTransport.getId());
dictionary.put("contextPath", appContextPath);
*dictionary.put("SKIP_STARTUP_RESOLVER", "true");*
bundleContext.registerService(Microservice.class, new WebappMicroservice(),
dictionary);
WDYT?
[1] https://github.com/wso2/msf4j/blob/v2.4.0-m1/core/pom.xml#L366
Thanks.
--
Sajith Janaprasad Ariyarathna
Senior Software Engineer; WSO2, Inc.; http://wso2.com/
<https://wso2.com/signature>
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
