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
