On Sun, May 5, 2013 at 11:41 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. > An option we talk about here is to rename CApp archive to Carbon archive. So that it can contain either application data or extension data. thanks, Amila. > > 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 > > -- *Amila Suriarachchi* Software Architect WSO2 Inc. ; http://wso2.com lean . enterprise . middleware phone : +94 71 3082805
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
