As I believe adding configuration files into a product is the responsibility of the product team. Not yours. In fact what we do is to add an entry into the bin.xml to copy qpid configuration files into the product distribution from the carbon core distribution that is built in the middle (which is wrong as I believe). I could have blindly modified all bin.xml files to copy configuration. But if a product did not need qpid/event then having the config files alone in the dist is pointless.
As I mentioned earlier as well, the issue in this particular case is not using the correct qpid libs. That is why the issue went away when you built event which eventually installed the latest qpid libs. It used to look for configuration files in conf/qpid/ and that is what I saw in your error message. So if you had built event feature, you would not have got this error. Thanks, Danushka On Fri, Apr 1, 2011 at 12:21 PM, Dimuthu Leelarathne <[email protected]>wrote: > Hi, > > On Fri, Apr 1, 2011 at 11:12 AM, Pradeep Fernando <[email protected]>wrote: > >> +1 agreed with danushka. Adding default configuration is not the >> solution for what dimuthu has encountered. In this case dimuthu is >> responsible for making the stratos distribution. Anybody working on >> wso2 product distribution should know what should be done in order to >> get the product running. No excuses. > > > > There is something very wrong here. Either technology or the process. Let > me ask the simple question. How did Qpid config files get copied to all > products and not services? How come services got second hand treatment? > AFAIK Qpid config files were added products by someone from Qpid team. > > So lets speculate, > > 1) Should someone from Stratos team do it? > 2) Should the feature be developed as self contained? > 3) Should technology be developed to handle this situation? Automatic > copying of config files? > 3) Should the RM of each product check the service? At minimum check > whether it starts? > > Copying something to 13 products is not an easy task if you want to build > them all check whether anything breaks (speaking by experience because I > have done it). If someone told me adding Qpid config files was my > responsibility I would create time to do it. I fixed it for manager. I > wasn't even aware of it until each server started hanging - one after other. > > > >> If we rely on default configs, then wso2 products will go in to >> production with default configs in the future. (by mistake) >> >> > -1. What about the config files we already ship? Don't they have default > configs? > > thanks, > dimuthu > > > But having a default config will serve a different scenario. If a user >> deletes the qpid config files after installing the features, and we >> still want the server to be started then we should have default >> configs. >> >> --Pradeep >> _______________________________________________ >> Carbon-dev mailing list >> [email protected] >> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >> > > > _______________________________________________ > Carbon-dev mailing list > [email protected] > http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev > >
_______________________________________________ Carbon-dev mailing list [email protected] http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
