Yes, we will be continuing with this approach, since, one of the main aims of this release is increasing stability of the product, and with the profile separation, we have faced with several functional and usability issues. So until we find clean solutions to the issues, we will follow the more stable way for now.
Cheers, Anjana. On Tue, Apr 8, 2014 at 11:32 AM, Gihan Anuruddha <[email protected]> wrote: > Hi, > > We are trying to build some BAM server profiles in order to make BAM > deployment much easier. Basically, our target was created 4 new server > profiles to represent the Cassandra, data-receiver, analyzer and dashboard > components. But at the moment we are facing few issues regarding this. > > First one is Carbon doesn't allow us to maintain the profile specific > config files. As an example, if I take the Cassandra profile, this > profile only needs carbon core, runtime features and the Cassandra specific > features. But in our default profile we are using the web app management > feature. > Due to this web app management feature it alters the conf/tomcat/context.xml > at build time by adding a loader class as org.wso2.carbon.webapp.mgt. > loader.CarbonWebappLoader. But then when we try to run Cassandra profile > carbon server doesn't start properly. To overcome this issue we have to > add some common set of features even we don't use in this particular > profile (This issue was found out by Kishanthan when he debug the issue.) > > Second one is from Cassandra features. At the moment we don't have any > clear separation of cassandra server and client modules. So we can't add > only the cassandra client modules to our server profiles. As an example, > in data-receiver profile, cassandra client is the only requirement. So > for this we are using a component called cassandra.dataaccess. Ideally > this suppose to work since we only need cassandra client for this > profile. But we are getting this [1] due to tight couple between cassandra > client > and server. To overcome this issue we have to bundle cassandra server > features as well to all profiles and then need to edit wso2server.sh file > by adding -Ddisable.cassandra.server.startup=true manually to prevent > start cassandra server in respective server profile nodes. > > Due to above reasons we thought of moving from p2 based server profiles to > component based restrictions like as we do with disabling cassandra server. > So at the moment we are trying to add few flags like > -Ddisblbe.analytics=true, -Ddisble.receiver=true to prevent the start of > relevant features at runtime. > > [1] - https://wso2.org/jira/browse/BAM-1501 > > Any thoughts are welcome. > > Regards, > Gihan > > -- > W.G. Gihan Anuruddha > Senior Software Engineer | WSO2, Inc. > M: +94772272595 > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Anjana Fernando* Technical Lead WSO2 Inc. | http://wso2.com lean . enterprise . middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
