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 <srin...@wso2.com> wrote:
> Smaeera, are these things we can fix?
> On Thu, Sep 22, 2016 at 11:23 AM, Nuwan Dias <nuw...@wso2.com> wrote:
>> 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?
>> Nuwan Dias
>> Software Architect - WSO2, Inc. http://wso2.com
>> email : nuw...@wso2.com
>> Phone : +94 777 775 729
> Srinath Perera, Ph.D.
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
*email: **az...@wso2.com* <az...@wso2.com>
* cell: +94 77 3320919blog: **http://blog.afkham.org*
*Lean . Enterprise . Middleware*
Architecture mailing list