Re: [Architecture] unpackWARs=true for WARs outside appBase are supported from Tomcat 7.0.48 onwards
On Mon, Feb 17, 2014 at 7:42 PM, Kasun Gajasinghe kas...@wso2.com wrote: Hi, It seems that Tomcat now supports the unpackWARs=true attribute for unpacking wars outside the Host's appBase. So, in the context of AS, the webapps deployed to tenants too will be unpacked by default. In the Tomcat 7.0.34 version we used before did not unpack the wars outside the Host's appBase. I think there were some users who requested this. In Carbon 4.3.0, we are planning to update Tomcat to 7.0.50, so we can support this now. Great ! This was one of the main limitation of AS tenant mode, make sure include this into test plan. Thanks ! This is documented under the Tomcat migration guide. [1] Related ticket at [2]. [1] http://tomcat.apache.org/migration-7.html#Deployment [2] https://issues.apache.org/bugzilla/show_bug.cgi?id=51294 Regards, KasunG -- *Kasun Gajasinghe* Software Engineer; WSO2 Inc.; http://wso2.com , *email: * *kasung AT spamfree wso2.com http://wso2.com ** cell: **+94 (77) 678-0813 %2B94%20%2877%29%20678-0813* *linked-in: *http://lk.linkedin.com/in/gajasinghe *blog: **http://kasunbg.org* http://kasunbg.org *twitter: **http://twitter.com/kasunbg* http://twitter.com/kasunbg -- Sagara Gunathunga Senior Technical Lead; WSO2, Inc.; http://wso2.com V.P Apache Web Services;http://ws.apache.org/ Linkedin; http://www.linkedin.com/in/ssagara Blog ; http://ssagara.blogspot.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Refactoring Carbon-Commons in Github
On Mon, Feb 17, 2014 at 8:06 PM, Geeth Munasinghe ge...@wso2.com wrote: Hi Following components in carbon-commons get dependencies from other projects as follows. - application-deployers/org.wso2.carbon.application.deployer.synapse - org.wso2.carbon.mediation.initializer - carbon-mediation - org.wso2.carbon.mediation.registry - carbon-mediation - org.wso2.carbon.datasource - carbon-data - org.wso2.carbon.task.services - carbon-mediation - application-mgt/org.wso2.carbon.application.mgt.bpel - org.wso2.carbon.bpel - carbon-business-process - org.wso2.carbon.bpel.skeleton - org.wso2.carbon.datasource - carbon-data - org.wso2.carbon.mediation.dependency.mgt - carbon-mediation - application-mgt/org.wso2.carbon.application.mgt.synapse - org.wso2.carbon.mediation.initializer - carbon-mediation - org.wso2.carbon.mediation.registry - carbon-mediation - org.wso2.carbon.datasource - carbon-data - org.wso2.carbon.task.services - carbon-mediation How can we proceed ? I don't think anyone has an proper answer just looking at above mentioned list of Maven dependencies, please analyse and find out why above components need those dependencies etc. ? Thanks ! Thanks Geeth *G. K. S. Munasinghe* *Software Engineer,* *WSO2, Inc. http://wso2.com http://wso2.com/ * *lean.enterprise.middleware.* email: ge...@wso2.com phone:(+94) 777911226 -- Sagara Gunathunga Senior Technical Lead; WSO2, Inc.; http://wso2.com V.P Apache Web Services;http://ws.apache.org/ Linkedin; http://www.linkedin.com/in/ssagara Blog ; http://ssagara.blogspot.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] Refactoring Carbon-Commons in Github
Hi Following components in carbon-commons get dependencies from other projects as follows. - application-deployers/org.wso2.carbon.application.deployer.synapse - org.wso2.carbon.mediation.initializer - carbon-mediation - org.wso2.carbon.mediation.registry - carbon-mediation - org.wso2.carbon.datasource - carbon-data - org.wso2.carbon.task.services - carbon-mediation - application-mgt/org.wso2.carbon.application.mgt.bpel - org.wso2.carbon.bpel - carbon-business-process - org.wso2.carbon.bpel.skeleton - org.wso2.carbon.datasource - carbon-data - org.wso2.carbon.mediation.dependency.mgt - carbon-mediation - application-mgt/org.wso2.carbon.application.mgt.synapse - org.wso2.carbon.mediation.initializer - carbon-mediation - org.wso2.carbon.mediation.registry - carbon-mediation - org.wso2.carbon.datasource - carbon-data - org.wso2.carbon.task.services - carbon-mediation How can we proceed ? Thanks Geeth *G. K. S. Munasinghe* *Software Engineer,* *WSO2, Inc. http://wso2.com http://wso2.com/ * *lean.enterprise.middleware.* email: ge...@wso2.com phone:(+94) 777911226 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] unpackWARs=true for WARs outside appBase are supported from Tomcat 7.0.48 onwards
+1 useful for jaggery as well. Regards, /Nuwan On Mon, Feb 17, 2014 at 9:19 AM, Sagara Gunathunga sag...@wso2.com wrote: On Mon, Feb 17, 2014 at 7:42 PM, Kasun Gajasinghe kas...@wso2.com wrote: Hi, It seems that Tomcat now supports the unpackWARs=true attribute for unpacking wars outside the Host's appBase. So, in the context of AS, the webapps deployed to tenants too will be unpacked by default. In the Tomcat 7.0.34 version we used before did not unpack the wars outside the Host's appBase. I think there were some users who requested this. In Carbon 4.3.0, we are planning to update Tomcat to 7.0.50, so we can support this now. Great ! This was one of the main limitation of AS tenant mode, make sure include this into test plan. Thanks ! This is documented under the Tomcat migration guide. [1] Related ticket at [2]. [1] http://tomcat.apache.org/migration-7.html#Deployment [2] https://issues.apache.org/bugzilla/show_bug.cgi?id=51294 Regards, KasunG -- *Kasun Gajasinghe* Software Engineer; WSO2 Inc.; http://wso2.com , *email: * *kasung AT spamfree wso2.com http://wso2.com ** cell: **+94 (77) 678-0813 %2B94%20%2877%29%20678-0813* *linked-in: *http://lk.linkedin.com/in/gajasinghe *blog: **http://kasunbg.org* http://kasunbg.org *twitter: **http://twitter.com/kasunbg* http://twitter.com/kasunbg -- Sagara Gunathunga Senior Technical Lead; WSO2, Inc.; http://wso2.com V.P Apache Web Services;http://ws.apache.org/ Linkedin; http://www.linkedin.com/in/ssagara Blog ; http://ssagara.blogspot.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Thanks Regards,Nuwan BandaraTechnical Lead; **WSO2 Inc. * *lean . enterprise . middleware | http://wso2.com http://wso2.com * *blog : http://nuwanbando.com http://nuwanbando.com; email: nu...@wso2.com nu...@wso2.com; phone: +1 812 606 7390 %2B1%20812%20606%207390 * http://www.nuwanbando.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Meeting minutes for the review of the Jaggery-Pipe and simpleRouter implementation
+1 for the proposal guys. and as chan said if we can use goose for base
stuff lets get that and built on top of that.
Regards,
/Nuwan
On Sun, Feb 16, 2014 at 7:09 AM, Chan duli...@wso2.com wrote:
I would further suggest to merge the simple router to goose.js[1] and
promote a single router as the base. The router module should be improved
for the above mentioned features. We can also remove the authentication and
authorization bits off from goose.js to a middleware component that can be
plugged in. (feel free to name it as jaggery-router since we are following
a convention on naming).
[1] - https://github.com/dulichan/goose.js
On Sun, Feb 16, 2014 at 12:37 PM, Sameera Medagammaddegedara
samee...@wso2.com wrote:
Hello Everyone,
*Description:*
The review looked at the use of the Jaggery-Pipe [3] ( a middleware
implementation like connect.js [1] ) and the simpleRouter plug-in [4] that
will be integrated into the Store and Publisher. These new components will
be used to handle routing and support for additional extension points in
the Store and Publisher.
*Participants*:
*Enterprise Store Team*: Ruchira, Praveena,Tanya, Nadeesha and Sameera
*Mobile Team:* Dulitha (Chan)
*Observations:*
- There is no need to allow users to define multiple routes to a
single handler in one line. This can be handled by defining each route in
a single line, in order to promote readability
- There is no need to allow users to override a plug-in used in the
pipe
*Actions:*
- The underlying implementation of the simpleRouter needs to be
changed so that it creates a tree structure from each route. This will
allow the definition of multiple route levels;
- /store/asset/:type/:id
- /store/asset/api/:id
- The simpleRouter should operate in two modes: development and
production
- In the development mode the route tree should be constructed for
each request
- In the production mode the route tree should only be built once
- The variables in a route should be defined using : (colons) as
opposed to { (curly braces):
- Current: /store/asset/{type}
- New: /store/asset/:type
- This is the implementation used in other JavaScript routing
frameworks (e.g. Express [2] )
*References*
[1] Connect.js ,URL: http://www.senchalabs.org/connect/
[2] Express.js ,URL: http://expressjs.com/guide.html
[3] Jaggery-Pipe ,URL:https://github.com/splinter/jaggery-pipe
[4] simpleRouter ,URL:
https://github.com/splinter/jaggery-pipe/blob/master/plugins/simpleRouter.js
Thank You,
Sameera
--
Sameera Medagammaddegedara
Software Engineer
Contact:
Email: samee...@wso2.com
Mobile: + 94 077 255 3005
--
Chan (Dulitha Wijewantha)
Software Engineer - Mobile Development
WSO2Mobile
Lean.Enterprise.Mobileware
* ~Email duli...@wso2.com duli...@wso2mobile.com*
* ~Mobile +94712112165 %2B94712112165*
* ~Website dulithawijewantha.com http://dulithawijewantha.com/ *
* ~Blog blog.dulithawijewantha.com
http://dulichan.github.io/chan/*
* ~Twitter @dulitharw https://twitter.com/dulitharw*
--
*Thanks Regards,Nuwan BandaraTechnical Lead; **WSO2 Inc. *
*lean . enterprise . middleware | http://wso2.com http://wso2.com *
*blog : http://nuwanbando.com http://nuwanbando.com; email:
nu...@wso2.com nu...@wso2.com; phone: +1 812 606 7390 *
http://www.nuwanbando.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Fwd: How can we patch Jaggery Apps?
Guys whats the verdict on this discussion ? Having a patch directory within the app seems to be a fine idea, which does not effect the platform patching or raise depsyc complications. Shall we come to a conclusion and implement this. IMO this is vital to all the products that has jaggery applications. Regards, /Nuwan On Thu, Jan 30, 2014 at 12:19 AM, Chan duli...@wso2.com wrote: On Thursday, January 30, 2014, Tanya Madurapperuma ta...@wso2.com wrote: On Wed, Jan 29, 2014 at 10:49 AM, Chan duli...@wso2.com wrote: On Wed, Jan 29, 2014 at 10:43 AM, Chan duli...@wso2.com wrote: On Wed, Jan 29, 2014 at 10:25 AM, Madhuka Udantha madh...@wso2.comwrote: On Wed, Jan 29, 2014 at 3:27 AM, Nuwan Bandara nu...@wso2.com wrote: On Tue, Jan 28, 2014 at 1:19 PM, Afkham Azeez az...@wso2.com wrote: On Tue, Jan 28, 2014 at 11:06 PM, Nuwan Bandara nu...@wso2.com wrote: Hi All On Tue, Jan 28, 2014 at 11:33 AM, Manuranga Perera m...@wso2.com wrote: The problem ultimately boils down to this common scenario: a) A customer has a Jaggery app in their environment. b) Some UI (images, css, headers, ect.) is customized c) Now they find a bug and ask for a patch +1, the issue here is all others replied here against patching a jaggery app is because you think of a jaggery app as a hello world web app. But you should look at the jaggery code in products like APIM / AppFac / UES / ES / MDM. In all these products Jaggery app is the place that has the major business logic. In these products Carbon is just the hosting environment. These are full fledge applications that does all kinds of things, generate meta data, has its own configurations etc, and when we find a minor issue we cannot ask people to replace the entire app and reconfigure every thing from the beginning. Just try the application developers shoes for a moment here and get out of the midleware developer mindset; Imagine we have developed an application and thats our main product. Now how do you fix problems in this product ? will you be shipping new versions of the product always when you find an issue ? If that is the case we will be shipping new versions of AS every day ;) Also when there is a requirement we should not think about how it can be squeezed into the existing model with minimum headache. We should find a comfortable solution for the users not something comfortable to implement. The requirement is to fix bugs in apps. The requirement is not, support patching of webapps. The solution is to update the app through patch fileif the app is uses a textual scripting language, or redeploy changed or a new version, if the app is in a compiled/binary/bytecode form. +1, that should work, but we nee AFAIU this solution is not feasible as we have to maintain a separate git repo for each customer. As far as I know - we do maintain code bases for customers. Plus maintaining git repos for customers is realistically not a hard thing to do cause everything is scriptable in git. It will become an issue when the number of customers grow. And also customers with lesser developer knowledge will face issues in resolving conflicts in merging etc. If customers customize our jaggery apps which they will definitely do - they will version control it anyway and most probably they will use git. Patches approach is nice but thinking from an Application Developer stand point version controlling is the best way to handle this type of patches. Food for thought I guess. [1] - https://devcenter.heroku.com/articles/git On Tue, Jan 28, 2014 at 1:37 PM, Afkham Azeez az...@wso2.com wrote: Cluster-wide patch distribution will be handle by the Operations Center. Azeez On Tue, Jan 28, 2014 at 12:40 PM, Ruchira Wageesha ruch...@wso2.comwrote: -- Tanya Madurapperuma -- Chan (Dulitha Wijewantha) Software Engineer - Mobile Development WSO2Mobile Lean.Enterprise.Mobileware * ~Email duli...@wso2.com duli...@wso2mobile.com* * ~Mobile +94712112165 %2B94712112165* * ~Website dulithawijewantha.com http://dulithawijewantha.com/ * * ~Blog blog.dulithawijewantha.com http://dulichan.github.io/chan/* * ~Twitter @dulitharw https://twitter.com/dulitharw* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Thanks Regards,Nuwan BandaraTechnical Lead; **WSO2 Inc. * *lean . enterprise . middleware | http://wso2.com http://wso2.com * *blog : http://nuwanbando.com http://nuwanbando.com; email: nu...@wso2.com nu...@wso2.com; phone: +1 812 606 7390 * http://www.nuwanbando.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] unpackWARs=true for WARs outside appBase are supported from Tomcat 7.0.48 onwards
Hi, It seems that Tomcat now supports the unpackWARs=true attribute for unpacking wars outside the Host's appBase. So, in the context of AS, the webapps deployed to tenants too will be unpacked by default. In the Tomcat 7.0.34 version we used before did not unpack the wars outside the Host's appBase. I think there were some users who requested this. In Carbon 4.3.0, we are planning to update Tomcat to 7.0.50, so we can support this now. This is documented under the Tomcat migration guide. [1] Related ticket at [2]. [1] http://tomcat.apache.org/migration-7.html#Deployment [2] https://issues.apache.org/bugzilla/show_bug.cgi?id=51294 Regards, KasunG -- *Kasun Gajasinghe* Software Engineer; WSO2 Inc.; http://wso2.com , *email: * *kasung AT spamfree wso2.com http://wso2.com ** cell: **+94 (77) 678-0813* *linked-in: *http://lk.linkedin.com/in/gajasinghe *blog: **http://kasunbg.org* http://kasunbg.org *twitter: **http://twitter.com/kasunbg* http://twitter.com/kasunbg ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Improved UI for capturing service information
Hi Chandana, This looks good. Firstly, when we create the service asset in the store, we need to think whether it is necessary for everything that you store in the G-Reg's service asset to be listed here. I know it is useful to have an asset in the repository that can capture everything, but in terms of the UI, we should think twice as to what's needed. For example, when I'm adding a new service as a provider, or when I'm updating information about it, what do I like to be seeing/updating? If you think along these lines this UI is far too complicated to use. Can we identify what fields make sense to be on this? Thanks, Senaka. On Mon, Feb 17, 2014 at 8:50 AM, Chandana Napagoda chand...@wso2.comwrote: Hi All, We are creating a WSO2 Enterprise Store based UI to capture Service Information and this new UI is also based on the Configurable Governance Artifacts(RXT). Here with I have attached the initial design of ES based Add Service UI. In this design, overview section (first section of RXT) is visible and other sections are collapsed. Either user can enter other information or proceed with save action. In Edit view, all the sections are expanded. Please refer the attached screenshots. Changes which will be made to saved RXT will be reflected to new UI as well. Suggestions are welcome. Regards, Chandna -- *Chandana Napagoda* Senior Software Engineer WSO2 Inc. - http://wso2.org *Email : chand...@wso2.com chand...@wso2.com**Mobile : +94718169299 %2B94718169299* *Blog :http://cnapagoda.blogspot.com http://cnapagoda.blogspot.com* -- *[image: http://wso2.com] http://wso2.com Senaka Fernando* Senior Technical Lead; WSO2 Inc.; http://wso2.com * Member; Apache Software Foundation; http://apache.org http://apache.orgE-mail: senaka AT wso2.com http://wso2.com**P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818 Linked-In: http://linkedin.com/in/senakafernando http://linkedin.com/in/senakafernando*Lean . Enterprise . Middleware ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Improved UI for capturing service information
Hi All, How about adding a link like for example Show Advance Settings to list all the information and only show the most required fields in the default view. Regards, Pulasthi On Mon, Feb 17, 2014 at 12:20 PM, Senaka Fernando sen...@wso2.com wrote: Hi Chandana, This looks good. Firstly, when we create the service asset in the store, we need to think whether it is necessary for everything that you store in the G-Reg's service asset to be listed here. I know it is useful to have an asset in the repository that can capture everything, but in terms of the UI, we should think twice as to what's needed. For example, when I'm adding a new service as a provider, or when I'm updating information about it, what do I like to be seeing/updating? If you think along these lines this UI is far too complicated to use. Can we identify what fields make sense to be on this? Thanks, Senaka. On Mon, Feb 17, 2014 at 8:50 AM, Chandana Napagoda chand...@wso2.comwrote: Hi All, We are creating a WSO2 Enterprise Store based UI to capture Service Information and this new UI is also based on the Configurable Governance Artifacts(RXT). Here with I have attached the initial design of ES based Add Service UI. In this design, overview section (first section of RXT) is visible and other sections are collapsed. Either user can enter other information or proceed with save action. In Edit view, all the sections are expanded. Please refer the attached screenshots. Changes which will be made to saved RXT will be reflected to new UI as well. Suggestions are welcome. Regards, Chandna -- *Chandana Napagoda* Senior Software Engineer WSO2 Inc. - http://wso2.org *Email : chand...@wso2.com chand...@wso2.com**Mobile : +94718169299 %2B94718169299* *Blog :http://cnapagoda.blogspot.com http://cnapagoda.blogspot.com* -- *[image: http://wso2.com] http://wso2.com Senaka Fernando* Senior Technical Lead; WSO2 Inc.; http://wso2.com * Member; Apache Software Foundation; http://apache.org http://apache.orgE-mail: senaka AT wso2.com http://wso2.com**P: +1 408 754 7388 %2B1%20408%20754%207388; ext: 51736*; *M: +94 77 322 1818 %2B94%2077%20322%201818 Linked-In: http://linkedin.com/in/senakafernando http://linkedin.com/in/senakafernando*Lean . Enterprise . Middleware -- -- Pulasthi Supun Software Engineer; WSO2 Inc.; http://wso2.com, Email: pulas...@wso2.com Mobile: +94 (71) 9258281 Blog : http://pulasthisupun.blogspot.com/ Git hub profile: https://github.com/pulasthi ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] Automatically deleting old BPEL processes that do not have any associated process instances in BPS
Hi All, In BPS when we directly copy a new zip ( which is identified by the md5sum of the zip file ) file of an existing BPEL process to /repository/deployment/server/bpel folder this will be picked up as an new version of the process and the existing process will be kept as a retired process ( correct me if i am wrong ). To my understanding this is required since there may be process instances that my be running on the older version of the process which is ok. But when we do not have any instances associated with an particular process that we are going to retire because there is a new version, shouldn't we be able to automatically remove the older version?. is there a reason to why this is not handled?. The accumulation of such process can lead to out of memory errors in production setups . The new cleanup tool that was introduced with the BPS 3.2.0 release does give a manual solution to this but wouldn't it be better handle this within the code itself. WDYT? Regards, Pulasthi -- -- Pulasthi Supun Software Engineer; WSO2 Inc.; http://wso2.com, Email: pulas...@wso2.com Mobile: +94 (71) 9258281 Blog : http://pulasthisupun.blogspot.com/ Git hub profile: https://github.com/pulasthi ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Fwd: How can we patch Jaggery Apps?
Guys it would be awesome if you can describe how the patch directory in the app works (I mean in detail). Then everyone will be clear about it. Cheers~ On Tue, Feb 18, 2014 at 10:12 AM, Madhuka Udantha madh...@wso2.com wrote: On Mon, Feb 17, 2014 at 8:56 PM, Nuwan Bandara nu...@wso2.com wrote: Guys whats the verdict on this discussion ? Having a patch directory within the app seems to be a fine idea, which does not effect the platform patching or raise depsyc complications. patch directory was most fine solution that we came across on this thread and also same discussion had in few email threads[1] did not have any conclusion for $subject. I too think $subject is essential for all products that depend on jaggery apps I am +1 for patch directory Shall we come to a conclusion and implement this. IMO this is vital to all the products that has jaggery applications. [1] Webapp Patching Strategy @ strategy-gr...@wso2.com on 4/5/13 Regards, /Nuwan On Thu, Jan 30, 2014 at 12:19 AM, Chan duli...@wso2.com wrote: On Thursday, January 30, 2014, Tanya Madurapperuma ta...@wso2.com wrote: On Wed, Jan 29, 2014 at 10:49 AM, Chan duli...@wso2.com wrote: On Wed, Jan 29, 2014 at 10:43 AM, Chan duli...@wso2.com wrote: On Wed, Jan 29, 2014 at 10:25 AM, Madhuka Udantha madh...@wso2.comwrote: On Wed, Jan 29, 2014 at 3:27 AM, Nuwan Bandara nu...@wso2.com wrote: On Tue, Jan 28, 2014 at 1:19 PM, Afkham Azeez az...@wso2.com wrote: On Tue, Jan 28, 2014 at 11:06 PM, Nuwan Bandara nu...@wso2.com wrote: Hi All On Tue, Jan 28, 2014 at 11:33 AM, Manuranga Perera m...@wso2.comwrote: The problem ultimately boils down to this common scenario: a) A customer has a Jaggery app in their environment. b) Some UI (images, css, headers, ect.) is customized c) Now they find a bug and ask for a patch +1, the issue here is all others replied here against patching a jaggery app is because you think of a jaggery app as a hello world web app. But you should look at the jaggery code in products like APIM / AppFac / UES / ES / MDM. In all these products Jaggery app is the place that has the major business logic. In these products Carbon is just the hosting environment. These are full fledge applications that does all kinds of things, generate meta data, has its own configurations etc, and when we find a minor issue we cannot ask people to replace the entire app and reconfigure every thing from the beginning. Just try the application developers shoes for a moment here and get out of the midleware developer mindset; Imagine we have developed an application and thats our main product. Now how do you fix problems in this product ? will you be shipping new versions of the product always when you find an issue ? If that is the case we will be shipping new versions of AS every day ;) Also when there is a requirement we should not think about how it can be squeezed into the existing model with minimum headache. We should find a comfortable solution for the users not something comfortable to implement. The requirement is to fix bugs in apps. The requirement is not, support patching of webapps. The solution is to update the app through patch file if the app is uses a textual scripting language, or redeploy changed or a new version, if the app is in a compiled/binary/bytecodeform. +1, that should work, but we nee AFAIU this solution is not feasible as we have to maintain a separate git repo for each customer. As far as I know - we do maintain code bases for customers. Plus maintaining git repos for customers is realistically not a hard thing to do cause everything is scriptable in git. It will become an issue when the number of customers grow. And also customers with lesser developer knowledge will face issues in resolving conflicts in merging etc. If customers customize our jaggery apps which they will definitely do - they will version control it anyway and most probably they will use git. Patches approach is nice but thinking from an Application Developer stand point version controlling is the best way to handle this type of patches. Food for thought I guess. [1] - https://devcenter.heroku.com/articles/git On Tue, Jan 28, 2014 at 1:37 PM, Afkham Azeez az...@wso2.com wrote: Cluster-wide patch distribution will be handle by the Operations Center. Azeez On Tue, Jan 28, 2014 at 12:40 PM, Ruchira Wageesha ruch...@wso2.comwrote: -- Tanya Madurapperuma -- Chan (Dulitha Wijewantha) Software Engineer - Mobile Development WSO2Mobile Lean.Enterprise.Mobileware * ~Email duli...@wso2.com duli...@wso2mobile.com* * ~Mobile +94712112165 %2B94712112165* * ~Website dulithawijewantha.com http://dulithawijewantha.com/ * * ~Blog blog.dulithawijewantha.com http://dulichan.github.io/chan/* * ~Twitter @dulitharw https://twitter.com/dulitharw* ___
Re: [Architecture] Fwd: How can we patch Jaggery Apps?
Hi Nuwan and all, If there is a patch which has a dependency to jar file(say a hostobject or any other carbon bundle changed) which will be used in jaggery application, In that case, we have a dependency between jaggery patch and usual patch(patch). How does the dependency resolution works if we maintain jaggery patches separately? Or Did I miss anything here? thank you. On Tue, Feb 18, 2014 at 11:17 AM, Chan duli...@wso2.com wrote: Guys it would be awesome if you can describe how the patch directory in the app works (I mean in detail). Then everyone will be clear about it. Cheers~ On Tue, Feb 18, 2014 at 10:12 AM, Madhuka Udantha madh...@wso2.comwrote: On Mon, Feb 17, 2014 at 8:56 PM, Nuwan Bandara nu...@wso2.com wrote: Guys whats the verdict on this discussion ? Having a patch directory within the app seems to be a fine idea, which does not effect the platform patching or raise depsyc complications. patch directory was most fine solution that we came across on this thread and also same discussion had in few email threads[1] did not have any conclusion for $subject. I too think $subject is essential for all products that depend on jaggery apps I am +1 for patch directory Shall we come to a conclusion and implement this. IMO this is vital to all the products that has jaggery applications. [1] Webapp Patching Strategy @ strategy-gr...@wso2.com on 4/5/13 Regards, /Nuwan On Thu, Jan 30, 2014 at 12:19 AM, Chan duli...@wso2.com wrote: On Thursday, January 30, 2014, Tanya Madurapperuma ta...@wso2.com wrote: On Wed, Jan 29, 2014 at 10:49 AM, Chan duli...@wso2.com wrote: On Wed, Jan 29, 2014 at 10:43 AM, Chan duli...@wso2.com wrote: On Wed, Jan 29, 2014 at 10:25 AM, Madhuka Udantha madh...@wso2.comwrote: On Wed, Jan 29, 2014 at 3:27 AM, Nuwan Bandara nu...@wso2.com wrote: On Tue, Jan 28, 2014 at 1:19 PM, Afkham Azeez az...@wso2.com wrote: On Tue, Jan 28, 2014 at 11:06 PM, Nuwan Bandara nu...@wso2.comwrote: Hi All On Tue, Jan 28, 2014 at 11:33 AM, Manuranga Perera m...@wso2.comwrote: The problem ultimately boils down to this common scenario: a) A customer has a Jaggery app in their environment. b) Some UI (images, css, headers, ect.) is customized c) Now they find a bug and ask for a patch +1, the issue here is all others replied here against patching a jaggery app is because you think of a jaggery app as a hello world web app. But you should look at the jaggery code in products like APIM / AppFac / UES / ES / MDM. In all these products Jaggery app is the place that has the major business logic. In these products Carbon is just the hosting environment. These are full fledge applications that does all kinds of things, generate meta data, has its own configurations etc, and when we find a minor issue we cannot ask people to replace the entire app and reconfigure every thing from the beginning. Just try the application developers shoes for a moment here and get out of the midleware developer mindset; Imagine we have developed an application and thats our main product. Now how do you fix problems in this product ? will you be shipping new versions of the product always when you find an issue ? If that is the case we will be shipping new versions of AS every day ;) Also when there is a requirement we should not think about how it can be squeezed into the existing model with minimum headache. We should find a comfortable solution for the users not something comfortable to implement. The requirement is to fix bugs in apps. The requirement is not, support patching of webapps. The solution is to update the app through patch file if the app is uses a textual scripting language, or redeploy changed or a new version, if the app is in a compiled/binary/ bytecode form. +1, that should work, but we nee AFAIU this solution is not feasible as we have to maintain a separate git repo for each customer. As far as I know - we do maintain code bases for customers. Plus maintaining git repos for customers is realistically not a hard thing to do cause everything is scriptable in git. It will become an issue when the number of customers grow. And also customers with lesser developer knowledge will face issues in resolving conflicts in merging etc. If customers customize our jaggery apps which they will definitely do - they will version control it anyway and most probably they will use git. Patches approach is nice but thinking from an Application Developer stand point version controlling is the best way to handle this type of patches. Food for thought I guess. [1] - https://devcenter.heroku.com/articles/git On Tue, Jan 28, 2014 at 1:37 PM, Afkham Azeez az...@wso2.com wrote: Cluster-wide patch distribution will be handle by the Operations Center. Azeez On Tue, Jan 28, 2014 at 12:40 PM, Ruchira Wageesha ruch...@wso2.comwrote: -- Tanya Madurapperuma -- Chan (Dulitha
Re: [Architecture] Automatically deleting old BPEL processes that do not have any associated process instances in BPS
Hi Pulasthi, Are you using the maven-bpel-plugin to build the zip file. It seems like the plugin is generating a zip file which produces a different md5sum each time even though the content of the bpel package has not changed at all. This must be the reason for you issue. Regards Nandika On Tue, Feb 18, 2014 at 10:11 AM, Pulasthi Supun pulas...@wso2.com wrote: Hi Eranda On Mon, Feb 17, 2014 at 7:23 PM, Eranda Sooriyabandara era...@wso2.comwrote: Hi Pulasthi, On Tuesday, February 18, 2014, Pulasthi Supun pulas...@wso2.com wrote: Hi All, In BPS when we directly copy a new zip ( which is identified by the md5sum of the zip file ) file of an existing BPEL process to /repository/deployment/server/bpel folder this will be picked up as an new version of the process and the existing process will be kept as a retired process ( correct me if i am wrong ). To my understanding this is required since there may be process instances that my be running on the older version of the process which is ok. But when we do not have any instances associated with an particular process that we are going to retire because there is a new version, shouldn't we be able to automatically remove the older version?. is there a reason to why this is not handled?. The accumulation of such process can lead to out of memory errors in production setups . The new cleanup tool that was introduced with the BPS 3.2.0 release does give a manual solution to this but wouldn't it be better handle this within the code itself. We give a manual solution because retirement of a process cannot identified automatically. AFAIU, though the process doesn't have a instance associated with it, we may not tell that it is retired. Your requirement can be there for some use cases but it's not always been the case. But when a new version of the same process is deployed we will only keep the newer version and remove the older version right?. From the UI the older version cannon't even be Re-activated. Thanks Eranda WDYT? Regards, Pulasthi -- -- Pulasthi Supun Software Engineer; WSO2 Inc.; http://wso2.com, Email: pulas...@wso2.com Mobile: +94 (71) 9258281 Blog : http://pulasthisupun.blogspot.com/ Git hub profile: https://github.com/pulasthi -- *Eranda Sooriyabandara*Senior Software Engineer; Integration Technologies Team; WSO2 Inc.; http://wso2.com Lean . Enterprise . Middleware E-mail: eranda AT wso2.com Mobile: +94 716 472 816 Linked-In: http://www.linkedin.com/in/erandasooriyabandara Blog: http://emsooriyabandara.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- -- Pulasthi Supun Software Engineer; WSO2 Inc.; http://wso2.com, Email: pulas...@wso2.com Mobile: +94 (71) 9258281 Blog : http://pulasthisupun.blogspot.com/ Git hub profile: https://github.com/pulasthi ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Nandika Jayawardana Senior Technical Lead WSO2 Inc ; http://wso2.com lean.enterprise.middleware ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Fwd: How can we patch Jaggery Apps?
Hi, If we are going with patching directory model, then following are my initial thoughts. - We will have a directory named .patches(or a better name) in the app root - Patches will have to be copied into that with directories named 0, 1, 2 ... n - We can either ask them to restart the server or we can simply hot deploy/undeploy the patches by listening to the .patch directory of the app Another doubt that I have is, whether we need to offer it as a part of Jaggery core itself or to offer it as a Jaggery module. If it is included in the core, then Jaggery server itself will be looking at the directories and deploy the patches. But, if we go with a Jaggery module, then they will have to explicitly engage/initialize the apps for patching via an init script. WDYT? /Ruchira On Tue, Feb 18, 2014 at 11:17 AM, Chan duli...@wso2.com wrote: Guys it would be awesome if you can describe how the patch directory in the app works (I mean in detail). Then everyone will be clear about it. Cheers~ On Tue, Feb 18, 2014 at 10:12 AM, Madhuka Udantha madh...@wso2.comwrote: On Mon, Feb 17, 2014 at 8:56 PM, Nuwan Bandara nu...@wso2.com wrote: Guys whats the verdict on this discussion ? Having a patch directory within the app seems to be a fine idea, which does not effect the platform patching or raise depsyc complications. patch directory was most fine solution that we came across on this thread and also same discussion had in few email threads[1] did not have any conclusion for $subject. I too think $subject is essential for all products that depend on jaggery apps I am +1 for patch directory Shall we come to a conclusion and implement this. IMO this is vital to all the products that has jaggery applications. [1] Webapp Patching Strategy @ strategy-gr...@wso2.com on 4/5/13 Regards, /Nuwan On Thu, Jan 30, 2014 at 12:19 AM, Chan duli...@wso2.com wrote: On Thursday, January 30, 2014, Tanya Madurapperuma ta...@wso2.com wrote: On Wed, Jan 29, 2014 at 10:49 AM, Chan duli...@wso2.com wrote: On Wed, Jan 29, 2014 at 10:43 AM, Chan duli...@wso2.com wrote: On Wed, Jan 29, 2014 at 10:25 AM, Madhuka Udantha madh...@wso2.comwrote: On Wed, Jan 29, 2014 at 3:27 AM, Nuwan Bandara nu...@wso2.com wrote: On Tue, Jan 28, 2014 at 1:19 PM, Afkham Azeez az...@wso2.com wrote: On Tue, Jan 28, 2014 at 11:06 PM, Nuwan Bandara nu...@wso2.comwrote: Hi All On Tue, Jan 28, 2014 at 11:33 AM, Manuranga Perera m...@wso2.comwrote: The problem ultimately boils down to this common scenario: a) A customer has a Jaggery app in their environment. b) Some UI (images, css, headers, ect.) is customized c) Now they find a bug and ask for a patch +1, the issue here is all others replied here against patching a jaggery app is because you think of a jaggery app as a hello world web app. But you should look at the jaggery code in products like APIM / AppFac / UES / ES / MDM. In all these products Jaggery app is the place that has the major business logic. In these products Carbon is just the hosting environment. These are full fledge applications that does all kinds of things, generate meta data, has its own configurations etc, and when we find a minor issue we cannot ask people to replace the entire app and reconfigure every thing from the beginning. Just try the application developers shoes for a moment here and get out of the midleware developer mindset; Imagine we have developed an application and thats our main product. Now how do you fix problems in this product ? will you be shipping new versions of the product always when you find an issue ? If that is the case we will be shipping new versions of AS every day ;) Also when there is a requirement we should not think about how it can be squeezed into the existing model with minimum headache. We should find a comfortable solution for the users not something comfortable to implement. The requirement is to fix bugs in apps. The requirement is not, support patching of webapps. The solution is to update the app through patch file if the app is uses a textual scripting language, or redeploy changed or a new version, if the app is in a compiled/binary/ bytecode form. +1, that should work, but we nee AFAIU this solution is not feasible as we have to maintain a separate git repo for each customer. As far as I know - we do maintain code bases for customers. Plus maintaining git repos for customers is realistically not a hard thing to do cause everything is scriptable in git. It will become an issue when the number of customers grow. And also customers with lesser developer knowledge will face issues in resolving conflicts in merging etc. If customers customize our jaggery apps which they will definitely do - they will version control it anyway and most probably they will use git. Patches approach is nice but thinking from an Application Developer stand point version
