L.S.,
Yeah, the credentials being in the bundles would be the biggest drawback of this approach. One thing you could do is use encrypted passwords, at least that would avoid having them in there in a human-readable format. If that's still an issue, there probably is no other way than having your administrators set this up directly on the machine (I agree a Blueprint XML file in the deploy folder is probably the easiest way for them), but even there that only works if your developers don't have access to the production machines, because otherwise they can still cat the file from within the Karaf console. Even if you still have to set up the database and probaby broker/content repository/... connections in this way, your test environments probably also has a lot of other web services to connect to or other Camel URLs that differ between environments so you would still gain that. Perhaps we can come up with a solution that only requires you to add the dev information to your bundle - if you expose the configuration as an OSGi service too, you could use the service ranking to override it in a production/test system. In a development environment, only the low-ranked development setup would be available so your developers can just "start their engines" and get to work. In the production environment, your administrators could set up the Blueprint file upfront with the production information and your bundles would pick that configuration instead. Not sure it would work for your environment though. Regards, Gert Vanthienen ------------------------ FuseSource Web: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 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 >
