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/
ServerExtensionDiscussion.docx
Description: application/vnd.openxmlformats-officedocument.wordprocessingml.document
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
