Maybe I misunderstood, but I don't see where the bundle know about the environment. It's just that the configuration knows where to find the correct configuration bits, depending on the environment (dev, test, prod for example). That could be a system wide property and the bundles should not have any knowledge of that (which of course would not be the smartest idea to add if/then/else blocks hardcoded in the bundle).
On Tue, Jun 12, 2012 at 10:53 PM, Christian Schneider <[email protected]> wrote: > I have also seen this and think it is a very bad practice. You either end up > having sensitive information like > username/passwords in the bundle or have to add another mechanism for these. > In any case I think the bundle should not know about the environments. The > config should be kept in each environment. > > Of course my prefered strategy has the problem that you have to edit the > config at least at first deployment. I think this is not ideal but better > than having all in the bundle. > > Christian > > > Am 12.06.2012 21:57, schrieb Gert Vanthienen: > >> L.S., >> >> >> I recently came across an environment where they had a very nice >> solution for your configuration problem. They only had a single >> configuration file in their config directory, which basically >> contained the environment's name (development, test, staging, >> production). They also implemented their own property placeholder >> that, depending on the environment set, was loading another set of >> properties from the bundle. Every bundle would just come with the >> configuration for all environments and depending on where you dropped >> the bundle, it would just behave differently, connect to another >> broker or database or send/receive to other servers. Perhaps we >> should look into adding support for a setup like this in ServiceMix >> directly? >> >> Next to everything that has been said already and all the technologies >> suggested for managing your containers, you may also want to take a >> look at http://fuse.fusesource.org/fabric/ as a tool for handling >> this. >> >> >> Regards, >> >> Gert Vanthienen >> ------------------------ >> FuseSource >> Web: http://fusesource.com >> Blog: http://gertvanthienen.blogspot.com/ >> >> >> On Tue, Jun 12, 2012 at 2:56 PM, James Carman >> <[email protected]> wrote: >>> >>> I'm using: >>> >>> OSGi (blueprint-configured) >>> Camel >>> CXF >>> OpenJPA >>> >>> I am using the features-maven-plugin provided by karaf to generate my >>> features.xml file. I guess I can do this at any level of granularity >>> by specifying dependencies in the pom.xml file. >>> >>> Do you typically set these things up as "boot features" or do you just >>> use the karaf console to install the features needed at runtime. If >>> you use the console, how do you script your deployments? Do you just >>> put a bunch of karaf commands in a file and say "run this"? If you >>> use boot features, you can shutdown SMX, change the version of your >>> feature repository, blast the data directory, and restart (which is >>> what we're doing right now). >>> >>> What do folks typically do with bundle-specific configuration files >>> that they need in the etc directory? There are certain properties >>> that we just don't know until we get to the environment (JDBC urls, >>> usernames, passwords, etc), so we obviously can't default them. Do >>> the "middleware guys" just manage those? >>> >>> >>> On Tue, Jun 12, 2012 at 8:49 AM, Jean-Baptiste Onofré<[email protected]> >>> wrote: >>>> >>>> Hi James, >>>> >>>> it depends about what you use: >>>> - JBI ? >>>> - Camel ? >>>> - OSGi ? >>>> >>>> If you use Karaf/OSGi (with features/bundles/kar), you can update pieces >>>> with others running. >>>> >>>> It requires a high level of granularity in the features. So it mainly >>>> depends about your features structure. >>>> >>>> Regards >>>> JB >>>> >>>> >>>> On 06/12/2012 02:35 PM, James Carman wrote: >>>>> >>>>> Fellow ServiceMixers, >>>>> >>>>> How do people typically go about doing deployments to a running, >>>>> production environment? We would like to be able to deploy only the >>>>> pieces that need updating, leaving everything else running (web >>>>> services, camel routes, etc.). Do people do this in practice? If so, >>>>> how do you go about it? How do you set up your deployments? We are >>>>> currently using one big feature file that serves as a "manifest" for >>>>> what's supposed to be there, but this monolithic approach doesn't seem >>>>> to be very conducive to targeted deployments. >>>>> >>>>> Thanks, >>>>> >>>>> James >>>> >>>> >>>> -- >>>> Jean-Baptiste Onofré >>>> [email protected] >>>> http://blog.nanthrax.net >>>> Talend - http://www.talend.com > > > > -- > > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > Talend Application Integration Division http://www.talend.com > -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ FuseSource, Integration everywhere http://fusesource.com
