Hi All,

With the multiple runtime support, the directory structure of the products
would be change as follows.

ServerHome
       |_________ bin
       |         |_______ runtime1.sh
       |         |_______ runtime2.sh
       |         |_______ start-all.sh (start all the runtimes except
default in separate JVMs)
       |         |_______ default.sh (start required runtimes in a single
JVM)
       |         |_______ jartobundle.sh
       |
       |
       |_________ deployment (This will contains custom deployable
artifacts)
       |         |_______ runtime1
       |         |           |_______ uuf
       |         |           |_______ microservice
       |         |
       |         |_______ runtime2
       |                     |_______ uuf
       |                     |_______ microservice
       |
       |
       |_________ lib
       |
       |
       |
       |_________ wso2
                |_______ Default (this can be used to combine sevral
runtimes e.g in IoT)
                |           |_______ bin
                |           |           |_____ carbon.sh
                |           |_______ conf (runtime specific conf)
                |           |           |_____ deployment.yaml
                |           |_______ deployment
                |
                |_______ Runtime1
                |           |_______ bin
                |           |           |______ carbon.sh
                |           |_______ conf (runtime specific conf)
                |           |           |_______ deployment.yaml
                |           |_______ deployment
                |
                |_______ Runtime2
                |           |_______ bin
                |           |           |_____ carbon.sh
                |           |_______ conf
                |           |           |_____ deployment.yaml
                |           |_______ deployment
                |
                |_______ lib (this will contains common jars)



   - Kernel runtime feature will provide the default carbon.sh startup
   script.
   At the moment kernel provides org.wso2.carbon.kernel.feature(kernel
   related stuffs), org.wso2.carbon.runtime.feature(OSGi runtime related jars)
   and org.wso2.carbon.touchpoint.feature. With the new restructure there will
   be 4 features instead of 3. We will splitting
   the org.wso2.carbon.kernel.feature to 2 features based on runtime and
   standalone. There we will also rename org.wso2.carbon.runtime.feature would
   be renamed to something like org.wso2.carbon.osgi.feature which will
   contain all the equinox OSGi stuffs.

   - It will set the runtime.home based on the directory structure
   Default carbon.sh will determine the runtime based on the place the
   script resides and it will set the system property to that. Product teams
   don't have to modify this script. Product team can create their own script
   and put in ServerHome/bin which can be used as a linker to specific
   runtime/bin/carbon.sh. So product-specific properties can be set from that
   script and default carbon.sh file will make sure those properties will be
   set when the runtime starts.

   - Product team have to create start-all.sh or other scripts which will
   be in *ServerHome/bin*
   If a product contains multiple runtimes, then product team have to
   create a script which is responsible for starting all the available
   runtimes in separate JVMs

   - Customers will not modify anything on the wso2 folder. (Unless configs
   in particular runtime)
   The intention of naming this directory as wso2 is that this will contain
   the wso2 specific stuff and users shouldn't modify this.

   - If they want to customize something, still they don't change default
   apps inside wso2 directory
   e.g. if someone wanna customize the theme or some ui components, still
   they will not touch default artifacts in wso2 directory but
   ServerHome/deployment

   - This same structure would be maintained in products which will release
   on 4.4.x e.g. IoT


Thanks
Thusitha

On Thu, Mar 30, 2017 at 6:15 PM, Jayanga Dissanayake <jaya...@wso2.com>
wrote:

> Hi Abimaran,
>
> On Thu, Mar 30, 2017 at 4:08 PM, Abimaran Kugathasan <abima...@wso2.com>
> wrote:
>
>> Hi Jayanga,
>>
>> On Thu, Mar 30, 2017 at 3:42 PM, Jayanga Dissanayake <jaya...@wso2.com>
>> wrote:
>>
>>> Hi Abimaran,
>>>
>>> The basic idea is, if you had (store, publisher, key-manager, gateway)
>>> profiles on the previous model. In new Runtime model, you will have
>>> separate runtimes for each of those.
>>>
>>> It is somewhat similar to what was there as profiles, but different in
>>> packaging(folder) structure, deployment (each runtime will have specific
>>> deployment artifacts), etc.
>>>
>>
>> API Manager won't require multiple profiles/runtimes, reason is, earlier,
>> we has a profile called Key Manager, for C5 APIM, it will be vannila IS
>> pack, Gateway will be vannila EI, and there will be Analytics whch inclues
>> TM feaure as a seperate product and a Broker.
>>
>> I guess, API Manager won't need this multiple runtime concept for C5.
>>
>
> ​Packing an entire products inside another product is not recommended in
> C5 way.
> You have to use the runtimes. EI6.0 has already done that and IOT is now
> following the same approach.
> Please check how EI has used the runtimes.
>
>>
>>> Thanks,
>>> Jayanga.
>>>
>>>
>>> *Jayanga Dissanayake*
>>> Associate Technical Lead
>>> WSO2 Inc. - http://wso2.com/
>>> lean . enterprise . middleware
>>> email: jaya...@wso2.com
>>> mobile: +94772207259 <+94%2077%20220%207259>
>>> <http://wso2.com/signature>
>>>
>>> On Thu, Mar 30, 2017 at 2:48 PM, Abimaran Kugathasan <abima...@wso2.com>
>>> wrote:
>>>
>>>> Hi Danesh,
>>>>
>>>> By runtime, do you mean profile of the same product? In C4 based APIM,
>>>> we had multiple profiles (Store, Publisher, Key Manager, Gateway, Traffic
>>>> manager) but with C5, there will be multiple products shipped into one
>>>> package like API Manager, IS, EI, etc.
>>>>
>>>> Is this applicable only for profiles of the same product?
>>>>
>>>> On Thu, Mar 30, 2017 at 2:30 PM, Niranjan Karunanandham <
>>>> niran...@wso2.com> wrote:
>>>>
>>>>> Hi Thusitha,
>>>>>
>>>>> On Thu, Mar 30, 2017 at 2:10 PM, Thusitha Thilina Dayaratne <
>>>>> thusit...@wso2.com> wrote:
>>>>>
>>>>>> Since there will be multiple runtimes in a single product we need to
>>>>>> get the information such as current runtime name/path etc..
>>>>>>
>>>>>> According to the EI structure, the startup script for each runtime
>>>>>> resides in the <*ServerHome>/wso2/{runtime}/bin *directory. And
>>>>>> there is a corresponding script at <*ServerHome>/bin* which will
>>>>>> call the particular runtime's startup script.  Do we follow the same
>>>>>> structure or we put all the startup scripts in the <*ServerHome>/bin*
>>>>>> directory?
>>>>>>
>>>>>> IMHO We have following options
>>>>>>
>>>>>> *Option 1* - All startup scripts are in <*ServerHome>/wso2/{runtime}/bin
>>>>>> *and linker script in <*ServerHome>/bin *(Similar to EI structure)
>>>>>>
>>>>>>    - Kernel feature can set the runtime.home based om the script
>>>>>>    location (which will be required for config resolver and etc..) from 
>>>>>> the
>>>>>>    carbon.sh so product teams don't have to change the default carbon.sh
>>>>>>
>>>>>> +1 for this option. In this way other products need not maintain
>>>>> runtime specific carbon.sh file. This should come along with the Kernel
>>>>> runtime specific feature. In-addition to this, it would be nice if the
>>>>> startall script in the <SERVER_HOME>/bin finds the runtimes dynamically
>>>>> without having specify it in the script. IMO we can get all the runtime
>>>>> which has a carbon.sh file inside its bin directory  or getting all the
>>>>> folder names in <SERVER_HOME>/wso2 excluding lib folder.
>>>>>
>>>>>
>>>>>>
>>>>>>    -
>>>>>>
>>>>>> *Option 2* - All startup scripts are in <*ServerHome>/bin*
>>>>>>
>>>>>>    - We can assume the startup script name is equivalent to runtime
>>>>>>    name. apim.sh and set that as runtime.home.
>>>>>>    - Product teams have to rename the default carbon.sh file to
>>>>>>    relevant runtime name
>>>>>>
>>>>>> *Option 3 *- Can be any of above 2 options
>>>>>>
>>>>>>    - Default carbon.sh will set the runtime.home to "default" and
>>>>>>    product team have to edit default script and change the runtime.home 
>>>>>> value
>>>>>>    in product level.
>>>>>>
>>>>>> WDYT?
>>>>>>
>>>>>> Thanks
>>>>>> Thusitha
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Mar 8, 2017 at 8:33 PM, KasunG Gajasinghe <kas...@wso2.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Danesh,
>>>>>>>
>>>>>>> Please find some comments in-line.
>>>>>>>
>>>>>>> On Wed, Mar 8, 2017 at 8:16 PM, Danesh Kuruppu <dan...@wso2.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> In C5 based products, we can have multiple runtimes in the product
>>>>>>>> package. For each runtime, there will be 
>>>>>>>> configuration(deployment.yaml),
>>>>>>>> securevault, execution scripts(carbon.sh etc), logs, deployment 
>>>>>>>> specific
>>>>>>>> only for that runtime. resources(wso2carbon.jks) and lib directory 
>>>>>>>> will be
>>>>>>>> common to every runtime and those are placed at top level.
>>>>>>>> So the directory structure of the basic distribution will be
>>>>>>>> something like,
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> What's the difference between top-level conf/ folder and the conf/
>>>>>>> folders under runtimes?
>>>>>>>
>>>>>>> And, how will this new directory structure affect the p2.inf
>>>>>>> instructions? In the p2.inf, we define from/where to the config files.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> wso2-carbon
>>>>>>>>> |-- bin
>>>>>>>>> |-- resources
>>>>>>>>> |-- lib
>>>>>>>>> |-- conf
>>>>>>>>> |-- wso2
>>>>>>>>> |-- <runtime1>
>>>>>>>>> |-- bin
>>>>>>>>> |-- logs
>>>>>>>>> |-- conf
>>>>>>>>> |-- deployment.yaml
>>>>>>>>> |-- log4j2.xml
>>>>>>>>> |-- security
>>>>>>>>> |-- secure-vault.yaml
>>>>>>>>> |-- secrets.properties
>>>>>>>>> |-- deployment
>>>>>>>>> |-- <runtime2>
>>>>>>>>> ----
>>>>>>>>> |-- <runtime3>
>>>>>>>>> |-- lib
>>>>>>>>> |-- features
>>>>>>>>> |-- p2
>>>>>>>>> |-- plugins
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Each runtime will be started as different processes/JVM and for the
>>>>>>>> distributed setup, we are going to provide a tool to run each runtime 
>>>>>>>> in
>>>>>>>> different nodes/containers.
>>>>>>>>
>>>>>>>
>>>>>>> Does this mean we can run multiple runtimes at the same time from a
>>>>>>> given product instance?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> KasunG
>>>>>>>
>>>>>>>
>>>>>>>> We are currently working on this. Please share your thoughts /
>>>>>>>> suggestions.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> --
>>>>>>>>
>>>>>>>> *Danesh Kuruppu*
>>>>>>>> Senior Software Engineer | WSO2
>>>>>>>>
>>>>>>>> Email: dan...@wso2.com
>>>>>>>> Mobile: +94 (77) 1690552 <077%20169%200552>
>>>>>>>> Web: WSO2 Inc <https://wso2.com/signature>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Architecture mailing list
>>>>>>>> Architecture@wso2.org
>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> *Kasun Gajasinghe*Associate Technical Lead, WSO2 Inc.
>>>>>>> email: kasung AT spamfree wso2.com
>>>>>>> linked-in: http://lk.linkedin.com/in/gajasinghe
>>>>>>> blog: http://kasunbg.org
>>>>>>> phone: +1 650-745-4499 <(650)%20745-4499>, 77 678 0813
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Architecture mailing list
>>>>>>> Architecture@wso2.org
>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Thusitha Dayaratne
>>>>>> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>>>>>>
>>>>>> Mobile  +94712756809 <+94%2071%20275%206809>
>>>>>> Blog      alokayasoya.blogspot.com
>>>>>> About    http://about.me/thusithathilina
>>>>>> <http://wso2.com/signature>
>>>>>>
>>>>>>
>>>>> Regards,
>>>>> Nira
>>>>>
>>>>> --
>>>>>
>>>>>
>>>>> *Niranjan Karunanandham*
>>>>> Associate Technical Lead - WSO2 Inc.
>>>>> WSO2 Inc.: http://www.wso2.com
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Architecture mailing list
>>>>> Architecture@wso2.org
>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Thanks
>>>> Abimaran Kugathasan
>>>> Senior Software Engineer - API Technologies
>>>>
>>>> Email : abima...@wso2.com
>>>> Mobile : +94 773922820 <+94%2077%20392%202820>
>>>>
>>>> <http://stackoverflow.com/users/515034>
>>>> <http://lk.linkedin.com/in/abimaran>
>>>> <http://www.lkabimaran.blogspot.com/>  <https://github.com/abimarank>
>>>> <https://twitter.com/abimaran>
>>>>
>>>>
>>>> _______________________________________________
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>
>>
>> --
>> Thanks
>> Abimaran Kugathasan
>> Senior Software Engineer - API Technologies
>>
>> Email : abima...@wso2.com
>> Mobile : +94 773922820 <+94%2077%20392%202820>
>>
>> <http://stackoverflow.com/users/515034>
>> <http://lk.linkedin.com/in/abimaran>
>> <http://www.lkabimaran.blogspot.com/>  <https://github.com/abimarank>
>> <https://twitter.com/abimaran>
>>
>>
>
> ​
> *​Jayanga Dissanayake*
> Associate Technical Lead
> WSO2 Inc. - http://wso2.com/
> lean . enterprise . middleware
> email: jaya...@wso2.com
> mobile: +94772207259 <+94%2077%20220%207259>
> <http://wso2.com/signature>​
>
>
> _______________________________________________
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Thusitha Dayaratne
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

Mobile  +94712756809
Blog      alokayasoya.blogspot.com
About    http://about.me/thusithathilina
<http://wso2.com/signature>
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to