Hi All, We can categorize all the files which need to be handled by profiles into three groups.
*1) OSGi repository * - *Location:* repository/components - *Description:* Contains all the OSGi bundles, dropins artifacts and other required files. This repository is already organized into multiple profiles(if any). *2) Config repository* - *Location:* repository/conf - *Description: Contains configuration files of the products. We need to figure out a way handle profile specific configuration files.* *3) Artifact repository* - *Location*: repository/deployment - *Description*: Contains deployment artifacts of the product. We need to figure out a way to handle profile specific deployment artifacts. Shariq from the platform team will work on this. Thanks, Sameera. On Fri, Sep 23, 2016 at 3:18 PM, Nuwan Dias <[email protected]> wrote: > > > On Fri, Sep 23, 2016 at 2:38 PM, Srinath Perera <[email protected]> wrote: > >> I think this happen with ESB NIO transport and Servelt transport for >> webapps. ( Nuwan, is there other examples?). >> > > In the regsitry.xml, we configure the indexers and handlers. These again > are only required in certain profiles. There are also some configs in the > api-manager.xml which only makes sense to enable in certain profiles. > >> >> On Fri, Sep 23, 2016 at 9:42 AM, Kishanthan Thangarajah < >> [email protected]> wrote: >> >>> Current issue is that all bundles and artifacts (conf files, webapps) >>> are common to the server which are shared among all the profiles. We don't >>> have a way to delete and modify them when starting up a profile. >>> >>> One other option is we could pack everything (profile specific >>> artifacts) in the base distribution and provide a build script (ant) which >>> create profile specific runtime a. >>> >>> We will check for the other alternatives along with this PoC and see. >>> >>> On Thu, Sep 22, 2016 at 12:27 PM, Afkham Azeez <[email protected]> wrote: >>> >>>> We proposed an idea to build a pack based on a profile. That will >>>> contain only the essential stuff. So rather than starting up a runtime and >>>> then loading a profile, you build a pack that contains the bare >>>> minimum stuff required. Perhaps we can have a descriptor which describes >>>> what non-OSGi stuff are required for a profile and we can combine that with >>>> the OSGi bundles.info to figure out exactly what is needed. Can >>>> someone in the kernel team do a quick PoC? >>>> >>>> On Thu, Sep 22, 2016 at 11:26 AM, Srinath Perera <[email protected]> >>>> wrote: >>>> >>>>> Smaeera, are these things we can fix? >>>>> >>>>> --Srinath >>>>> >>>>> On Thu, Sep 22, 2016 at 11:23 AM, Nuwan Dias <[email protected]> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> This is to raise some concerns over the current server profiles. >>>>>> Although we are able to control the bundles which are loaded to the >>>>>> runtime >>>>>> based on the -Dprofile parameter, we still lack the ability of removing >>>>>> files and modifying configuration files when the server starts on a >>>>>> profile. And this is forcing us to start unnecessary bundles at startup. >>>>>> Let me explain... >>>>>> >>>>>> API Manager has both webapps and a gateway in its distribution. The >>>>>> synapse bundles are only required in the Gateway profiles. However since >>>>>> the axis2.xml file of API Manager defines the http transport senders and >>>>>> receivers based on the Synapse passthrough senders and receivers, the >>>>>> axis2 >>>>>> engine will try to load the synapse classes on startup. Ideally if we >>>>>> were >>>>>> able to modify the axis2.xml on the Publisher, Store and Key Manager >>>>>> profiles and replace the passthrough senders and receivers with our >>>>>> standard http senders and receivers, we could avoid loading the synapse >>>>>> bundles on the Publisher, Store and Key Manager. >>>>>> >>>>>> The same problem occurs for registry indexers and handlers. Since the >>>>>> registry indexers and handlers are configured on the registry.xml, even >>>>>> though these are only required in the publisher and store profiles, these >>>>>> bundles will be activated and running even on the Gateway, Key Manager >>>>>> and >>>>>> Traffic Manager. So unless we modify the registry.xml on those nodes >>>>>> manually, we can't stop those bundles from running. >>>>>> >>>>>> Another problem we're facing is the inability to remove webapps. >>>>>> Since all webapps in the repository/deployment/server/webapps and >>>>>> repository/deployment/server/jaggeryapps are deployed into the >>>>>> runtime, unless we remove these webapps manually there is no other way to >>>>>> stop them from being deployed in unrelated profiles. >>>>>> >>>>>> I heard there is a discussion to bind a profile to a container. Which >>>>>> would solve these problems. However it still won't help the >>>>>> "non-container" >>>>>> deployments. Are there ways to overcome the above mentioned limitations >>>>>> and >>>>>> enhance the efficiency of our profiles? >>>>>> >>>>>> Thanks, >>>>>> NuwanD. >>>>>> >>>>>> -- >>>>>> Nuwan Dias >>>>>> >>>>>> Software Architect - WSO2, Inc. http://wso2.com >>>>>> email : [email protected] >>>>>> Phone : +94 777 775 729 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> ============================ >>>>> Srinath Perera, Ph.D. >>>>> http://people.apache.org/~hemapani/ >>>>> http://srinathsview.blogspot.com/ >>>>> >>>> >>>> >>>> >>>> -- >>>> *Afkham Azeez* >>>> Director of Architecture; WSO2, Inc.; http://wso2.com >>>> Member; Apache Software Foundation; http://www.apache.org/ >>>> * <http://www.apache.org/>* >>>> *email: **[email protected]* >>>> * cell: +94 77 3320919 <%2B94%2077%203320919>blog: * >>>> *http://blog.afkham.org* <http://blog.afkham.org> >>>> *twitter: **http://twitter.com/afkham_azeez* >>>> <http://twitter.com/afkham_azeez> >>>> *linked-in: **http://lk.linkedin.com/in/afkhamazeez >>>> <http://lk.linkedin.com/in/afkhamazeez>* >>>> >>>> *Lean . Enterprise . Middleware* >>>> >>> >>> >>> >>> -- >>> *Kishanthan Thangarajah* >>> Technical Lead, >>> Platform Technologies Team, >>> WSO2, Inc. >>> lean.enterprise.middleware >>> >>> Mobile - +94773426635 >>> Blog - *http://kishanthan.wordpress.com >>> <http://kishanthan.wordpress.com>* >>> Twitter - *http://twitter.com/kishanthan >>> <http://twitter.com/kishanthan>* >>> >>> >>> -- >>> *Kishanthan Thangarajah* >>> Technical Lead, >>> Platform Technologies Team, >>> WSO2, Inc. >>> lean.enterprise.middleware >>> >>> Mobile - +94773426635 >>> Blog - *http://kishanthan.wordpress.com >>> <http://kishanthan.wordpress.com>* >>> Twitter - *http://twitter.com/kishanthan >>> <http://twitter.com/kishanthan>* >>> >>> >> >> >> -- >> ============================ >> Srinath Perera, Ph.D. >> http://people.apache.org/~hemapani/ >> http://srinathsview.blogspot.com/ >> > > > > -- > Nuwan Dias > > Software Architect - WSO2, Inc. http://wso2.com > email : [email protected] > Phone : +94 777 775 729 > -- Sameera Jayasoma, Software Architect, WSO2, Inc. (http://wso2.com) email: [email protected] blog: https://medium.com/@sameera.jayasoma twitter: https://twitter.com/sameerajayasoma
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
