On Fri, Sep 15, 2017 at 8:49 PM, SajithAR Ariyarathna <sajit...@wso2.com>
wrote:
> 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.
>
Will there be exactly one microservice per webapp? If yes, why can't we
figure out the number of services (webpps in this case) to be registered
during server startup (or component activation) and inform it to startup
resolver?
I'm anyway +1 for the suggestion solution below, but I'm trying to figure
out what can/can't be done here before that.
> 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>
>
--
*Kishanthan Thangarajah*
Technical Lead,
Platform Technologies Team,
WSO2, Inc.
lean.enterprise.middleware
Mobile - +94773426635
Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>*
Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>*
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
