camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brad Johnson <>
Subject Re: Class substitution in bean?
Date Mon, 01 Feb 2016 00:09:45 GMT
The separate properties files is what I have now.  I thought about
interceptors but have limited experience with them so will have look into
that further.

The reason I'm looking for a way to do this is because of what I've found
to be the work method at most of my clients.  As soon as APIs get defined,
Jira issues created,  and some bundles get in place they want to hit the
endpoints and do some testing or development.  In the past I'd make
separate bundles for test stubs that returned dummy data and the actual
integration bundles.  Then I'd inject the OSGi service which would either
be test or implementation. That works but results in a proliferation of
bundles and multiple features.

When I deploy in karaf I'd like to be able to start with the bundles and
the test dummy data and run SOAP UI tests against it verifying that all the
libraries versions and plumbing are correct.  If those tests don't pass
then there isn't a need to "complexify" ot by using actual integration
routes.  Then by tweaking the cfg file to change to the actual
implementation class name have the bundle reload itself with the
integration routes from the route builder.

Using a simple factory works in Eclipse but I haven't tried it deployed to
karaf yet.  We'll see.  If I can get that to work properly, and it appears
I can, it's going to do a lot to simplify testing and development and
configuration management.

On Sun, Jan 31, 2016 at 2:21 PM, Quinn Stevenson <> wrote:

> One option would be to put the definition of your bean in one XML file and
> the route in another.  You can have the production version of the
> supporting beans in src/main/resources/OSGI-INF/blueprint, and the test
> versions in src/test/resources/OSGI-INF/blueprint.  That’s not a great
> solution because you have to update two files (the prod one and the test
> one) if something significant changes, but it’s simple.
> The other option that comes to mind would be to use maven filtering to
> process the XML file.  You could specify different class name in maven
> profiles.
> > On Jan 30, 2016, at 1:19 PM, Ranx <> wrote:
> >
> > I'm currently creating test stubs for use with my blueprint tests and
> for use
> > in deployment and testing.  I've tried various methods with varying
> degrees
> > of luck.
> >
> > Is there a way to substitute a class name at start up?  I could create a
> > factory class to do a class for name on it but would prefer to use
> standard
> > mechanisms.
> >
> > <bean id="supplierServiceImpl" class="${serviceImpl}" />
> >
> > In my camel context if I use this it works fine:
> >               <route id="GetSuppliers">
> >                       <from uri="{{}}" />
> >                       <to
> uri="class:{{serviceImpl}}?method=getSuppliers" />
> >               </route>
> >
> > And if I use this in the preamble section above the context it works
> fine:
> > <cxf:rsServer id=&quot;cxfRsServer&quot;
> > address=&quot;${CXFServer}:${proxy.port}/resources&quot;
> >
> > So the properties are getting passed in but it doesn't like using the
> class
> > substitution.  I even tried wild swings like &lt;bean
> > id=&quot;supplierServiceImpl&quot; class=&quot;class:${serviceImpl}&quot;
> > />.  But at that point I'm just guessing.
> >
> > Any help is appreciated.
> >
> >
> >
> >
> >
> > --
> > View this message in context:
> > Sent from the Camel - Users mailing list archive at

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message