Hi all,

We need to do slight modification for the above directory structure. Since
we are not allowing the end user to change any file inside wso2
folder(ServerHome/wso2), we cannot keep the conf directory of each runtime
inside wso2 directory. So we are planning to move out conf directory of
each runtime from wso2 directory. Modified directory structure will look
like below (changes from the above structure is highlighted in red colour),

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
       |
       |_________ conf
       |        |________ runtime1
       |        |             |________ deployment.yaml
       |        |             |________ master-keys.yaml
       |        |             |________ secrets.properties
       |        |             |________ log4j2.xml
       |        |             |________ etc
       |        |             |             |______ pax-logging.properties
       |        |             |________ osgi
       |        |                           |______ launch.properties
       |        |                           |______ osgi-debug.options
       |        |________ runtime2
       |                      |________ deployment.yaml
       |                      |________ master-keys.yaml
       |                      |________ secrets.properties
       |                      |________ log4j2.xml
       |                      |________ etc
       |                      |             |______ pax-logging.properties
       |                      |________ osgi
       |                                    |______ launch.properties
       |                                    |______ osgi-debug.options
       |
       |_________ resources
       |        |________ security
       |                      |________ wso2secvault.jks
       |                      |________ wso2carbon.jks
       |
       |_________ wso2
                |_______ Default (this can be used to combine several
runtimes e.g in IoT)
                |           |_______ bin
                |           |           |_____ carbon.sh
                |           |_______ deployment
                |
                |_______ Runtime1
                |           |_______ bin
                |           |           |______ carbon.sh
                |           |_______ deployment
                |
                |_______ Runtime2
                |           |_______ bin
                |           |           |_____ carbon.sh
                |           |_______ deployment
                |
                |_______ lib (this will contains common jars)


We are currently working on this. Please share your thoughts / suggestions.

Thanks
Danesh

On Thu, Mar 30, 2017 at 8:37 PM, Thusitha Thilina Dayaratne <
thusit...@wso2.com> wrote:

> 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 <+94%2071%20275%206809>
> 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
>
>


-- 

*Danesh Kuruppu*
Senior Software Engineer | WSO2

Email: dan...@wso2.com
Mobile: +94 (77) 1690552
Web: WSO2 Inc <https://wso2.com/signature>
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to