L.S.,
Ah yeah, I assumed they wanted to package everything up for easy deployment, so I was thinking about properties files in a bundle, but they can very wel be externalized too obviously. It shouldn't really matter that much, the main idea was to add a way to configure the container with an environment property and then provide some hooks or services to leverage this information for configuring stuff based on the environment. Regards, Gert Vanthienen ------------------------ FuseSource Web: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ On Wed, Jun 13, 2012 at 8:56 AM, Guillaume Nodet <[email protected]> wrote: > 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
