You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Ranx <br...@mediadriver.com> on 2016/01/30 21:19:53 UTC
Class substitution in bean?
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="{{suppliers.info.endpoint}}" />
<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="cxfRsServer"
address="${CXFServer}:${proxy.port}/resources"
So the properties are getting passed in but it doesn't like using the class
substitution. I even tried wild swings like <bean
id="supplierServiceImpl" class="class:${serviceImpl}"
/>. But at that point I'm just guessing.
Any help is appreciated.
--
View this message in context: http://camel.465427.n5.nabble.com/Class-substitution-in-bean-tp5777061.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Class substitution in bean?
Posted by Matt Sicker <bo...@gmail.com>.
Have you tried using interceptors?
https://camel.apache.org/intercept.html
https://camel.apache.org/advicewith.html
On 30 January 2016 at 14:19, Ranx <br...@mediadriver.com> 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="{{suppliers.info.endpoint}}" />
> <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="cxfRsServer"
> address="${CXFServer}:${proxy.port}/resources"
>
> So the properties are getting passed in but it doesn't like using the class
> substitution. I even tried wild swings like <bean
> id="supplierServiceImpl" class="class:${serviceImpl}"
> />. But at that point I'm just guessing.
>
> Any help is appreciated.
>
>
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/Class-substitution-in-bean-tp5777061.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
--
Matt Sicker <bo...@gmail.com>
Re: Class substitution in bean?
Posted by Brad Johnson <br...@mediadriver.com>.
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 <
quinn@pronoia-solutions.com> 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 <br...@mediadriver.com> 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="{{suppliers.info.endpoint}}" />
> > <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="cxfRsServer"
> > address="${CXFServer}:${proxy.port}/resources"
> >
> > So the properties are getting passed in but it doesn't like using the
> class
> > substitution. I even tried wild swings like <bean
> > id="supplierServiceImpl" class="class:${serviceImpl}"
> > />. But at that point I'm just guessing.
> >
> > Any help is appreciated.
> >
> >
> >
> >
> >
> > --
> > View this message in context:
> http://camel.465427.n5.nabble.com/Class-substitution-in-bean-tp5777061.html
> > Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
Re: Class substitution in bean?
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
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 <br...@mediadriver.com> 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="{{suppliers.info.endpoint}}" />
> <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="cxfRsServer"
> address="${CXFServer}:${proxy.port}/resources"
>
> So the properties are getting passed in but it doesn't like using the class
> substitution. I even tried wild swings like <bean
> id="supplierServiceImpl" class="class:${serviceImpl}"
> />. But at that point I'm just guessing.
>
> Any help is appreciated.
>
>
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Class-substitution-in-bean-tp5777061.html
> Sent from the Camel - Users mailing list archive at Nabble.com.