Hi All, This issue has been watered-down in v5.2.0 release, now the server starts successfully. Nonetheless, 'skipping the Startup Order Resolver' has been identified as a requirement. Created issue [1] to track this feature request2
[2] https://github.com/wso2/carbon-kernel/issues/1584 Thanks. On Tue, Oct 10, 2017 at 2:31 PM, SajithAR Ariyarathna <[email protected]> wrote: > Hi Kishanthan, > > On Fri, Sep 22, 2017 at 10:50 AM, Kishanthan Thangarajah < > [email protected]> wrote: > >> >> >> On Fri, Sep 15, 2017 at 8:49 PM, SajithAR Ariyarathna <[email protected]> >> 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> > -- 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
