Re: [Architecture] is it correct to deploy class mediators via a CAR file
On Sun, May 5, 2013 at 11:41 AM, Kishanthan Thangarajah kishant...@wso2.com 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 srin...@wso2.com 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 harsh...@wso2.comwrote: Hi Srinath, On Wed, Apr 24, 2013 at 3:24 PM, Srinath Perera srin...@wso2.comwrote: 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 ka...@wso2.comwrote: @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 kishant...@wso2.com wrote: Hi Kasun, On Sat, Apr 13, 2013 at 1:54 PM, Kasun Indrasiri ka...@wso2.comwrote: 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
Re: [Architecture] AS J2EE support - JSF
Hi, I further went through both of these implementations specially considering the performance and community. *Performance with AS:* Both of them showed almost similar results. But with the increasing number of threads myFaces performed slightly better than mojarra. *Community:* Currently both have active communities and there are number of recent releases from both. And again it seems myfaces has bit more active community since the start of the project. Mojarra(known as RI) was not much active in early days but now. IMO it's better to start with Apache myfaces and keep it as our default implementation. Later we can provide the support to mojarra(or any other implementation) according to the user requirements. Thanks! On Fri, Apr 26, 2013 at 3:18 PM, Pradeep Fernando prad...@wso2.com wrote: On Fri, Apr 26, 2013 at 12:41 PM, Piyum Fernando pi...@wso2.com wrote: Hi folks, There are two major JSF implementations; Apache myFaces[1] and Oracle Mojarra[2] I tested both of these implementations with a simple JSF wep app running on AS by creating new class loading environments and worked well. I went through few J2EE servers and default implementations they use are as follows; Apache Myfaces - TomEE, Geronimo Oracle Mojarra - Glassfish, Web Logic JBoss comes with both by default. AFAIK most of the times JSF web apps work fine with any of them. But some features may work well only with a particular impl and some may depend on the versions too. IMO we should provide the support to use any of these implementations and versions. In this case we can use different class loading environments for each of them and allow the user to configure the web app to use the one needed. integrating one of these implementations/test/release/resolve user issues is the best way to get start with this kind of task. Smooth integration is more important than the, number of JSF implementations we support, to begin with. just a thought. --Pradeep WDYT? [1] http://myfaces.apache.org/ [2] https://javaserverfaces.java.net/ -- Piyum Fernando Software Engineer Mobile: +94 77 22 93 880 Home: +94 31 22 75 715 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Pradeep Fernando* Member, Management Committee - Platform Cloud Technologies Senior Software Engineer;WSO2 Inc.; http://wso2.com blog: http://pradeepfernando.blogspot.com m: +94776603662 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Piyum Fernando Software Engineer Mobile: +94 77 22 93 880 Home: +94 31 22 75 715 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] [AppFactory] Enabling event notifications in AppFactory jaggery application.
Hi all, In AppFactory, there are load of events generated that are interested for different users(App Owners, Developers, QA and DevOps). Currently these events are not visible to end users. POC is implemented to try out a scenario as in diagram and provide a better run time view to end users.[image: Inline image 1] Here, users access the jaggery application in browser, then web socket is opened from jaggery server to browser. When any activity is going on AF, BPS, Jenkins,etc, events are published to different topics. We have a JMS listener subscribed to these events and notifications are received by JMS subscribers. JMS subscribers push incoming messages into web socket so that browser get updated with these messages. Above scenario is tested and working without ELB. We need to figure out a way how we can handle this use case in a clustered mode with ELB. Based on incoming message formats, we need to render the message in browser. And we need to identify/define hierarchical topics and message formats based on interested events. Thoughts are welcome before we integrate this with AF. thank you. -- Manjula Rathnayaka Software Engineer WSO2, Inc. Mobile:+94 77 743 1987 AF_event_wall.jpg___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [AppFactory] Enabling event notifications in AppFactory jaggery application.
since IE9 and below and many android browsers doesn't support websocket [1] we may have to implement a fall back mechanism. we can use a already existing client-side library such as 'socket.io' [2] but may have to write a server-side Jaggery module to support that. [1] http://caniuse.com/websockets [2] http://socket.io/ On Mon, May 6, 2013 at 4:26 PM, Manjula Rathnayake manju...@wso2.comwrote: Hi, On Mon, May 6, 2013 at 4:04 PM, Manjula Rathnayake manju...@wso2.comwrote: Hi all, In AppFactory, there are load of events generated that are interested for different users(App Owners, Developers, QA and DevOps). Currently these events are not visible to end users. POC is implemented to try out a scenario as in diagram and provide a better run time view to end users.[image: Inline image 1] Here, users access the jaggery application in browser, then web socket is opened from jaggery server to browser. When any activity is going on AF, BPS, Jenkins,etc, events are published to different topics. We have a JMS listener subscribed to these events and notifications are received by JMS subscribers. JMS subscribers push incoming messages into web socket so that browser get updated with these messages. Above scenario is tested and working without ELB. We need to figure out a way how we can handle this use case in a clustered mode with ELB. The reason to not work with ELB is, web socket transport is WS,WSS and that is not supported in ELB. Based on incoming message formats, we need to render the message in browser. And we need to identify/define hierarchical topics and message formats based on interested events. Thoughts are welcome before we integrate this with AF. thank you. -- Manjula Rathnayaka Software Engineer WSO2, Inc. Mobile:+94 77 743 1987 thank you. -- Manjula Rathnayaka Software Engineer WSO2, Inc. Mobile:+94 77 743 1987 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture AF_event_wall.jpg___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
