Hi Kishanthan, We had two: short term and long term goals.
1) We should be OK with hot deployment only for ESB and for others that where it is possible. (At least that was the consensus of the meeting). For other servers, we will manage the extensions, and when we want to update Stratos, we will do round robin restart. 2) We need to solve this problem. May be in C5. Note this dynamic import has come up several time (talk to Sameera). --Srinath On Mon, May 6, 2013 at 12:11 AM, Kishanthan Thangarajah <[email protected] > wrote: > During an offline discussion we (AmilaS, Azeez, Harshana) had on the > second approach, (using p2 to support server extensions), the following > points were brought up. > > 1. How are we going to handle this in a MT environment as all tenants will > see those extentions classes at run-time? > 2. bundles.info in what connects p2 and equinox, and it is read only > once, during start-up by equinox AFAIK. So this is why after installing new > features, we had > to restart the server to take effect. This will again be a limitation. > 3. Right now we use Dynamic-Imports to resolve required import packages > when integrating other 3rd party components with Carbon. So to support this > properly, > we need to use proper import packages in all the 3rd party integration. > 4. Updating bundles at run-time requires to refresh the Carbon environment > and refreshing the environment while server running means refresh happens > iteratively > up to the root level and it is similar to Graceful server restart which is > not a good practice. > > On the first approach (using our own deployer to deploy the server > extension libs), we could use a CApp deployer like approach. As mentioned > by Kasun, for synapse artifacts, we can use the synapse library deployer + > template approach to hot-deploy/update custom/class mediators. > > How should we proceed from here? > > Thanks, > Kishanthan. > > > > On Tue, Apr 30, 2013 at 3:45 PM, Srinath Perera <[email protected]> wrote: > >> Please find the notes in the attached doc >> >> Mainly we discuss using "our own server extension" vs. using P2 to do >> that. Kishanthan will explore the both options and get back. >> >> --Srinath >> >> >> On Wed, Apr 24, 2013 at 4:52 PM, Harshana Martin <[email protected]>wrote: >> >>> Hi Srinath, >>> >>> >>> On Wed, Apr 24, 2013 at 3:24 PM, Srinath Perera <[email protected]>wrote: >>> >>>> Kasun, where do we stand now? >>>> >>>> 1) Are we creating a new extension type? for class mediators, axis2 >>>> modules etc >>>> 2) what do we plan to do far hot deployment? >>>> >>>> lets have a redmine issue unless we are working on this now? >>>> >>> >>> We already have redmine issues for this [1290] [1291]. >>> >>> Shall we organize a review meeting Friday 26th or Monday 29th to discuss >>> this further? >>> >>> If we are to get this fixed for Carbon 4.2.0, we need to decide ASAP. >>> >>> Thanks and Regards, >>> Harshana >>> >>>> >>>> >>>> >>>> >>>> >>>> On Sat, Apr 13, 2013 at 7:07 PM, Kasun Indrasiri <[email protected]>wrote: >>>> >>>>> @Amila: With Synapse library approach, any custom mediator will get >>>>> hot update as long as they reside in the template which will be deployed >>>>> with the Synapse library. Any other sequence will be basically calling the >>>>> template (call template). However, once a given custom mediator get hot >>>>> deployed, any other sequence can use that custom mediator(without using >>>>> templates), but not subjected to hot update till that particular sequence >>>>> get redeployed. So, the bottom line is that, to support 'hot update' the >>>>> custom mediator should reside in a template. >>>>> >>>>> On Sat, Apr 13, 2013 at 4:04 PM, Kishanthan Thangarajah < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi Kasun, >>>>>> >>>>>> >>>>>> On Sat, Apr 13, 2013 at 1:54 PM, Kasun Indrasiri <[email protected]>wrote: >>>>>> >>>>>>> This is the progress we made on deploying Synapse extensions - Class >>>>>>> Mediators and Custom Mediators. >>>>>>> >>>>>>> I've mainly tried following existing method on deploying extensions >>>>>>> on Synapse trunk. >>>>>>> >>>>>>> - *Synapse Extension Approach - XAR* : We can hot deploy any >>>>>>> synapse custom mediator as an extension. However, although the xar got >>>>>>> hot >>>>>>> updated, we have to redeploy all the referring sequence and proxy >>>>>>> services >>>>>>> to get the updated changes in to effect. >>>>>>> >>>>>>> - *Synapse Library Deployer* : Synapse library carters hot update >>>>>>> requirement by keeping the changing artifacts as a template. So, that >>>>>>> sequences can share and refer a given template and during hot update, >>>>>>> its >>>>>>> only the template get hot updated. So this support both hot >>>>>>> deployment/update for class mediator. But, this doesn't support adding >>>>>>> custom mediators (factories and serializers) >>>>>>> >>>>>>> So, then I extend the synapse library functionality such that it >>>>>>> loads factories and serializers prior to deploying the library >>>>>>> artifacts. >>>>>>> >>>>>>> With that we can hot deploy/update both class mediators and custom >>>>>>> mediators with out deploying any sequences that are referring those >>>>>>> mediators. [All artifacts (custom/class mediators along with templates) >>>>>>> are >>>>>>> packed in a synapse-lib zip file.] >>>>>>> >>>>>> >>>>>> +1, I'm trying compare this approach with the new CApp artifacts >>>>>> deployment approach we are working on (thread : "Synchronous deployment >>>>>> of >>>>>> CApp artifacts"). >>>>>> >>>>>> Say that we want to hot update both custom/class mediators using the >>>>>> above synapse lib functionality and other artifacts (sequences, proxies, >>>>>> etc) using the CApp approach. >>>>>> >>>>>> So the hot update to take effect, does the order of >>>>>> deployment matters here? i.e synapse library deployer should be called >>>>>> first before CApp deployer calls the relevant synapse artifacts >>>>>> deployers? >>>>>> May be I'm missing some info here. >>>>>> >>>>>> @Kishanthan: >>>>> >>>>> - With the template+synapse-lib approach, the order doesn't affect the >>>>> functionality. (cApp artifacts merely referring some templates while the >>>>> actual custom/class mediator resides in the synapse-lib itself. >>>>> - If we don't use templates, then the order matters. Synapse-lib >>>>> should get deployed first and then the cApp. >>>>> >>>>> Thanks, >>>>>> Kishanthan. >>>>>> >>>>>>> >>>>>>> (For more info, please refer synapse-dev on "Adding hot >>>>>>> deployment/update support to synapse custom mediators".) >>>>>>> >>>>>>> Any thoughts? >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Apr 5, 2013 at 8:02 AM, Sanjiva Weerawarana < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> On Thu, Apr 4, 2013 at 2:01 PM, Amila Suriarachchi >>>>>>>> <[email protected]>wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> A solution is to have a different artifact type in Dev Studio for >>>>>>>>>> these - say ESB Extensions. >>>>>>>>>> >>>>>>>>> >>>>>>>>> +1. all these extension types should be supported by the >>>>>>>>> respective product it self. For an example esb should support custom >>>>>>>>> mediator extensions etc .. >>>>>>>>> >>>>>>>>> I think car file is a bundle of another set of artefacts. So >>>>>>>>> always users can use one car file to bundle application and other to >>>>>>>>> bundle >>>>>>>>> extensions. For an example currently we use car file to bundle >>>>>>>>> environment >>>>>>>>> specific registry resources. >>>>>>>>> >>>>>>>> >>>>>>>> Amila I'm proposing that we remove server extensions from the >>>>>>>> "Composite APPLICATION Archive" packaging model. >>>>>>>> >>>>>>>> Server extensions are not app level code. >>>>>>>> >>>>>>>> Sanjiva. >>>>>>>> -- >>>>>>>> Sanjiva Weerawarana, Ph.D. >>>>>>>> Founder, Chairman & CEO; WSO2, Inc.; http://wso2.com/ >>>>>>>> email: [email protected]; phone: +94 11 763 9614; cell: +94 77 787 >>>>>>>> 6880 | +1 650 265 8311 >>>>>>>> blog: http://sanjiva.weerawarana.org/ >>>>>>>> >>>>>>>> Lean . Enterprise . Middleware >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Architecture mailing list >>>>>>>> [email protected] >>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Kasun Indrasiri >>>>>>> Associate Technical Lead >>>>>>> WSO2, Inc.; http://wso2.com >>>>>>> >>>>>>> lean.enterprise.middleware >>>>>>> >>>>>>> cell: +94 71 536 4128 >>>>>>> Blog : http://kasunpanorama.blogspot.com/ >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Architecture mailing list >>>>>>> [email protected] >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Kishanthan Thangarajah* >>>>>> Software Engineer, >>>>>> Development Technologies Team, >>>>>> WSO2, Inc. >>>>>> lean.enterprise.middleware >>>>>> >>>>>> Mobile - +94773426635 >>>>>> Blog - *http://kishanthan.wordpress.com* >>>>>> Twitter - *http://twitter.com/kishanthan* >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Kasun Indrasiri >>>>> Associate Technical Lead >>>>> WSO2, Inc.; http://wso2.com >>>>> lean.enterprise.middleware >>>>> >>>>> cell: +94 71 536 4128 >>>>> Blog : http://kasunpanorama.blogspot.com/ >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> ============================ >>>> Srinath Perera, Ph.D. >>>> http://www.cs.indiana.edu/~hperera/ >>>> http://srinathsview.blogspot.com/ >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> >>> Harshana Martin >>> Senior Software Engineer >>> Member, Management Committee - Development Technologies >>> WSO2 Inc. : http://wso2.com >>> >>> Mobile: +94 775 998 115 >>> Profile: https://www.google.com/profiles/harshana05 >>> Blog: http://harshana05.blogspot.com >>> Twitter: http://twitter.com/harshana05 >>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> ============================ >> Srinath Perera, Ph.D. >> http://www.cs.indiana.edu/~hperera/ >> http://srinathsview.blogspot.com/ >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > *Kishanthan Thangarajah* > Software Engineer, > Development Technologies Team, > WSO2, Inc. > lean.enterprise.middleware > > Mobile - +94773426635 > Blog - *http://kishanthan.wordpress.com* > Twitter - *http://twitter.com/kishanthan* > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- ============================ Srinath Perera, Ph.D. Senior Software Architect, WSO2 Inc. Visiting Faculty, University of Moratuwa Member, Apache Software Foundation Research Scientist, Lanka Software Foundation Blog: http://srinathsview.blogspot.com/ Photos: http://www.flickr.com/photos/hemapani/ Phone: 0772360902
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
