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? > > --Srinath > > On Thu, Sep 22, 2016 at 11:23 AM, Nuwan Dias <nuw...@wso2.com> 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 : nuw...@wso2.com >> 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: **az...@wso2.com* <az...@wso2.com> * cell: +94 77 3320919blog: **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*
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
