Hi Kishanthan,
On Fri, Sep 22, 2017 at 10:50 AM, Kishanthan Thangarajah <
kishant...@wso2.com> wrote:
>
>
> 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?
>
> Web app artifacts are discovered via the Carbon Deployment framework.
Carbon Deployment framework will invoke the Deployer.deploy() method of the
Carbon UI Server app deployer for each web app artifact. Inside the
Deployer.deploy() method, there is no way figuring out how many app
artifacts are there pending to be deployed. They deployer only knows that
particular artifact is available for deployment and by maintaining a
counter variable how many artifacts were deployed previously. Through the
Deployer interface, Carbon UI Server cannot compute how many app artifacts
are there to deploy. Hence cannot derive the services count.
Thanks.
> 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.intern
>> al.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.intern
>> al.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.intern
>> al.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.intern
>> al.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.intern
>> al.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.intern
>> al.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 <+94%2077%20342%206635>
> Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>*
> Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>*
>
--
Sajith Janaprasad Ariyarathna
Senior Software Engineer; WSO2, Inc.; http://wso2.com/
<https://wso2.com/signature>
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
