Did my previous email make any sense? Is the recommendation to install separate servers because of JVM isolation, or is there another reason?
On Wed, Jan 8, 2014 at 11:25 AM, chris snow <[email protected]> wrote: > What is the driver for recommending to install separate servers for each > product? In production environments, having separate JVMs is more robust, > but this is too heavy weight for development environments. > > Therefore, I'm thinking we should allow an administrator to deploy > multiple features to a single carbon instance if required. If JVM > isolation is required by the administrator, then a LXC container could be > created for each server instance that requires its own JVM. > > I think this approach is similar to that taken by the Ubuntu tomcat > package. An administrator would install one tomcat instance (apt-get > install tomcat). Multiple wars can be deployed to the single tomcat > instance, for example in a development environment. Prod environments > could use lxc to install multiple tomcats to give each war its own jvm if > required. > > Does this make sense? > On 8 Jan 2014 06:36, "Geeth Munasinghe" <[email protected]> wrote: > >> +1 Interesting idea. I think installing features on carbon kernel will >> not be flexible thing here. Instead we should package a single server to >> install. Because if some one wants to install both ESB and App Server as >> separate servers on the same machine, then person has to install carbon >> kernal twice and install set of features on them. >> >> Thanks >> Geeth >> >> >> *G. K. S. Munasinghe* >> *Software Engineer,* >> *WSO2, Inc. http://wso2.com <http://wso2.com/> * >> *lean.enterprise.middleware.* >> >> email: [email protected] >> phone:(+94) 777911226 >> >> >> On Wed, Jan 8, 2014 at 11:47 AM, Nirmal Fernando <[email protected]> wrote: >> >>> Hi Chris, >>> >>> The idea is very interesting indeed. Thanks for bringing it up. If you >>> have a look at p2-profile's pom of a product, you would get an idea about >>> the set of features that are required by that product. >>> >>> >>> On Wed, Jan 8, 2014 at 1:49 AM, chris snow <[email protected]> wrote: >>> >>>> Hi Lasantha, >>>> >>>> I'm hoping that it would be possible to automate installing carbon core >>>> and also automate installing features. >>>> >>>> My hope is that features would be able to coexist on the same carbon >>>> core platform without interfering with each other. >>>> >>>> It should be up to the administrator to decide which features to >>>> install together, for example to install AS and BPS should be as simple as: >>>> >>>> $ apt-get install wso2-as wso2-bps >>>> >>>> The distribution's standard locations should be used, e.g. >>>> /etc/wso2/as/... for configuration files, and /var/log for log files. >>>> >>>> Many thanks, >>>> Chris >>>> On 7 Jan 2014 09:08, "Lasantha Fernando" <[email protected]> wrote: >>>> >>>>> Hi Chris, >>>>> >>>>> Looks interesting. In your approach, are you planning to automate >>>>> installing features on top of a carbon-kernel to get the relevant features >>>>> for a product? >>>>> >>>>> Also, how would it work if installing multiple WSO2 products, or >>>>> different product features on top of a single carbon kernel? >>>>> >>>>> Thanks, >>>>> Lasantha >>>>> >>>>> On 7 January 2014 02:12, chris snow <[email protected]> wrote: >>>>> >>>>>> Today I was thinking of more examples to help explain my previous >>>>>> email. Here is one example from the eclipse world: >>>>>> >>>>>> Package: eclipse-jdt (3.8.0~rc4-1) - >>>>>> http://packages.debian.org/wheezy/eclipse-jdt >>>>>> >>>>>> dep: default-jre Standard Java or Java compatible Runtime >>>>>> or java5-runtime virtual package provided by default-jre, >>>>>> gcj-4.6-jre, gcj-4.7-jre, gcj-jre, openjdk-6-jre, openjdk-7-jre >>>>>> or java6-runtime virtual package provided by default-jre, >>>>>> openjdk-6-jre, openjdk-7-jre >>>>>> >>>>>> dep: eclipse-platform (>= 3.8.0~rc4-1) Eclipse platform without >>>>>> development plug-ins >>>>>> .. >>>>>> >>>>>> Therefore: >>>>>> >>>>>> $ apt-get install eclipse-jdt # eclipse-jdt 3.8.0~rc4-1 also >>>>>> installs eclipse-platform >= 3.8.0~rc4-1 >>>>>> >>>>>> With chunk releases for Carbon 4.2+ being backward compatible, could >>>>>> the same principle be applied: >>>>>> >>>>>> $ apt-get install wso2-as # wso2-as 5.0 also installs >>>>>> wso2-core-platform >= 4.20 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Sun, Jan 5, 2014 at 3:46 PM, chris snow <[email protected]>wrote: >>>>>> >>>>>>> Has anyone ever looked at creating native linux platform installers >>>>>>> for WSO2 products? For example: >>>>>>> >>>>>>> - DEB for debian based distros >>>>>>> - RPM for redhat based distros >>>>>>> >>>>>>> I've been thinking of how the tomcat package works on ubuntu where >>>>>>> the latest major version (e.g. 7) completely replaces the previous >>>>>>> version. >>>>>>> >>>>>>> However, from what I understand, wso2 features require a certain >>>>>>> "major + minor version + minimum chunk" version of Carbon so there would >>>>>>> need to be a packaged version of Carbon for each supported Carbon >>>>>>> release, >>>>>>> for example: >>>>>>> >>>>>>> - wso2-carbon-core-42.deb >>>>>>> - wso2-carbon-core-50.deb >>>>>>> - wso2-carbon-core-51.deb >>>>>>> - etc >>>>>>> >>>>>>> However, products with a different "major + minor" version >>>>>>> wso2-carbon-core-42, wso2-carbon-core-50, and wso2-carbon-core-51 could >>>>>>> co-exist as they would be considered different packages (though ports >>>>>>> would >>>>>>> need to be selected as to avoid clashing). With the approach, you could >>>>>>> perform the following to install 4.2.x and 5.0.x side by side: >>>>>>> >>>>>>> apt-get install wso2-carbon-core-42.deb >>>>>>> apt-get install wso2-carbon-core-50.deb >>>>>>> >>>>>>> An increase in the chunk version would cause the package to be >>>>>>> upgraded (much the same as apt-get upgrade). For example, version of >>>>>>> wso2-carbon-core-42.deb (version chunk 2) would upgrade a previous >>>>>>> installation of wso2-carbon-core-42.deb (version chunk 1). >>>>>>> >>>>>>> WSO2 products could be installed on top of the carbon core base as >>>>>>> features, where there the feature has a dependency on the appropriate >>>>>>> version of Carbon, for example: >>>>>>> >>>>>>> - wso2-as-52.deb would have a dependency on wso2-carbon-core-42.deb >>>>>>> (version chunk 1+) >>>>>>> >>>>>>> Does this approach make sense? Would it work? >>>>>>> >>>>>>> Many thanks, >>>>>>> >>>>>>> Chris >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Check out my professional profile and connect with me on LinkedIn. >>>>>> http://lnkd.in/cw5k69 >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> *Lasantha Fernando* >>>>> Software Engineer - Data Technologies Team >>>>> WSO2 Inc. http://wso2.com >>>>> >>>>> email: [email protected] >>>>> mobile: (+94) 71 5247551 >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> >>> Thanks & regards, >>> Nirmal >>> >>> Senior Software Engineer- Platform Technologies Team, WSO2 Inc. >>> Mobile: +94715779733 >>> Blog: http://nirmalfdo.blogspot.com/ >>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> -- Check out my professional profile and connect with me on LinkedIn. http://lnkd.in/cw5k69
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
