You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by gnani swami <pr...@gmail.com> on 2013/09/05 18:02:16 UTC
Are there any Camel hack to make all the JMS component to use one and
only thread?
Hi,
Camel was wonderful piece of software and using it in production for more
than a year. Our version of Camel was 2.10.1
I recently added few additional route (and bug in buz logic too) to
interface with additional systems, all the routes are doing the similar
job. They read JMS message from an unique-end-point (MQ JMS Queue) and
invoke buzComponent (Camel component).
But recently discovered that some subtle concurrency issues inside the
buzComponent causing trouble to us. And I am looking for some sort of Camel
hack to prevent it from further damage by making all the end-point consumer
to use one and only thread.
1) As a short term solution, we like to convert all the JMS component to
use single threaded threadPool (or taskExecutor), and that new thread pool
shouldn't allow more than a thread across all the JMS end-point. Is it
possible? We are not worried about latency and performance for some time.
2) if there is a possibility, our camel error handlers were already
in-place, Can we assume that single thread would continue working despite
any exception configured to errorHandler. ErrorHandlers will have its own
thread.
3) I am also happy to introduce one or more route and end-point inside
camelcontex.xml, so all the buzComponent can be redirected into that new
route to make it SingleThreaded execution somehow.. are there any
suggestion to use some camel component (We could use any hack as long as
configurable inside xml).
I am pretty sure all the above approach may be short sighted, but looking
for temporary solution which could work for few days. We are happy to
modify Camel xml, than changing code and making it complex.
I appreciate feedback.
Regards
Mohan
<camelContext>
<route id="route-one">
<from uri="ibmmq1:queue:fromSourceOne" />
<inOnly uri="direct://buzComponent" />
</route>
<route id="route-two">
<from uri="ibmmq2:queue:fromSourceTwo" />
<inOnly uri="direct://buzComponent" />
</route>
<!-- problematic root due to buzComponent locking-->
<route id="high-speed-source-source-3">
<from uri="ibmmq3:queue:fromHighSpeedSourceOne" />
<inOnly uri="direct://buzComponent" />
</route>
<route id="high-speed-source-source-4">
<from uri="ibmmq4:queue:fromHighSpeedSourceTwo" />
<inOnly uri="direct://buzComponent" />
</route>
</camelContext>
<bean id="ibmmq" class="org.apache.camel.component.jms.JmsComponent">
<property name="connectionFactory">
<bean class="com.ibm.mq.jms.MQConnectionFactory">
...
</bean>
</property>
</bean>
Re: Are there any Camel hack to make all the JMS component to use one
and only thread?
Posted by gnani swami <pr...@gmail.com>.
Thanks a lot!
It just worked.
On Fri, Sep 6, 2013 at 10:34 PM, Christian Posta
<ch...@gmail.com>wrote:
> +1 Andreas' comment.
>
> So what i was thinking was something like this...
>
> from("ibmmq1").to("seda:stage")
> from("ibmmq2").to("seda:stage")
> from("ibmmq3").to("seda:stage")
>
> from("seda:stage?concurrentConsumesr=1").to("direct://buzComponent")
>
>
>
>
> On Fri, Sep 6, 2013 at 3:57 AM, Andreas Gies <andreas@wayofquality.de
> >wrote:
>
> > One thing to keep in mind when you are experiencing odering issues is
> > that you can use ActiveMQ's message groups to make all messages for
> > one group to the same consumer. Very often that little trick helps
> > and still allows some form of concurrency for different groups.
> >
> > Andreas
> >
> >
> > On 09/05/2013 11:54 PM, gnani swami wrote:
> >
> >> Some of the messages where handled by wrong service and they are all
> >> queued
> >> in FailedErrorMessages directory. Application failed to process them. So
> >> it
> >> will end up in ordering, and lost message. Looking at our various
> >> exception it is quite easy for us to understand that they are caused by
> >> concurrency bug inside the buz logic.
> >>
> >> We like to move the <inOnly uri="direct://buzComponent" /> to new route
> >> under some endpoint (in-mem-queue). Quick google doesn't return anything
> >> related to multiplex, could you point me sample route? Can I create
> that
> >> multiplex in the new route under new endpoint.
> >>
> >> Thanks
> >>
> >>
> >>
> >> On Fri, Sep 6, 2013 at 12:35 AM, Christian Posta
> >> <ch...@gmail.com>**wrote:
> >>
> >> So what's the underlying concurrency issue? Ordering? Can you just
> have a
> >>> route that multiplexes all of those incoming queues into a single queue
> >>> (or
> >>> in-mem queue) and then have a route w/ only one thread that does CBR
> and
> >>> invoke the correct bean?
> >>>
> >>>
> >>> On Thu, Sep 5, 2013 at 9:02 AM, gnani swami <projectnash1994@gmail.com
> >>>
> >>>> wrote:
> >>>> Hi,
> >>>>
> >>>> Camel was wonderful piece of software and using it in production for
> >>>> more
> >>>> than a year. Our version of Camel was 2.10.1
> >>>>
> >>>> I recently added few additional route (and bug in buz logic too) to
> >>>> interface with additional systems, all the routes are doing the
> similar
> >>>> job. They read JMS message from an unique-end-point (MQ JMS Queue) and
> >>>> invoke buzComponent (Camel component).
> >>>>
> >>>> But recently discovered that some subtle concurrency issues inside the
> >>>> buzComponent causing trouble to us. And I am looking for some sort of
> >>>>
> >>> Camel
> >>>
> >>>> hack to prevent it from further damage by making all the end-point
> >>>>
> >>> consumer
> >>>
> >>>> to use one and only thread.
> >>>>
> >>>> 1) As a short term solution, we like to convert all the JMS component
> to
> >>>> use single threaded threadPool (or taskExecutor), and that new thread
> >>>>
> >>> pool
> >>>
> >>>> shouldn't allow more than a thread across all the JMS end-point. Is
> it
> >>>> possible? We are not worried about latency and performance for some
> >>>>
> >>> time.
> >>>
> >>>> 2) if there is a possibility, our camel error handlers were already
> >>>> in-place, Can we assume that single thread would continue working
> >>>> despite
> >>>> any exception configured to errorHandler. ErrorHandlers will have its
> >>>> own
> >>>> thread.
> >>>>
> >>>> 3) I am also happy to introduce one or more route and end-point inside
> >>>> camelcontex.xml, so all the buzComponent can be redirected into that
> new
> >>>> route to make it SingleThreaded execution somehow.. are there any
> >>>> suggestion to use some camel component (We could use any hack as long
> >>>> as
> >>>> configurable inside xml).
> >>>>
> >>>> I am pretty sure all the above approach may be short sighted, but
> >>>> looking
> >>>> for temporary solution which could work for few days. We are happy to
> >>>> modify Camel xml, than changing code and making it complex.
> >>>>
> >>>> I appreciate feedback.
> >>>>
> >>>> Regards
> >>>> Mohan
> >>>>
> >>>> <camelContext>
> >>>> <route id="route-one">
> >>>> <from uri="ibmmq1:queue:**fromSourceOne" />
> >>>> <inOnly uri="direct://buzComponent" />
> >>>> </route>
> >>>> <route id="route-two">
> >>>> <from uri="ibmmq2:queue:**fromSourceTwo" />
> >>>> <inOnly uri="direct://buzComponent" />
> >>>> </route>
> >>>> <!-- problematic root due to buzComponent locking-->
> >>>> <route id="high-speed-source-source-**3">
> >>>> <from uri="ibmmq3:queue:**fromHighSpeedSourceOne" />
> >>>> <inOnly uri="direct://buzComponent" />
> >>>> </route>
> >>>> <route id="high-speed-source-source-**4">
> >>>> <from uri="ibmmq4:queue:**fromHighSpeedSourceTwo" />
> >>>> <inOnly uri="direct://buzComponent" />
> >>>> </route>
> >>>> </camelContext>
> >>>>
> >>>> <bean id="ibmmq"
> class="org.apache.camel.**component.jms.JmsComponent">
> >>>> <property name="connectionFactory">
> >>>> <bean class="com.ibm.mq.jms.**MQConnectionFactory">
> >>>> ...
> >>>> </bean>
> >>>> </property>
> >>>> </bean>
> >>>>
> >>>>
> >>>
> >>> --
> >>> *Christian Posta*
> >>> http://www.christianposta.com/**blog<
> http://www.christianposta.com/blog>
> >>> twitter: @christianposta
> >>>
> >>>
> >
>
>
> --
> *Christian Posta*
> http://www.christianposta.com/blog
> twitter: @christianposta
>
Re: Are there any Camel hack to make all the JMS component to use one
and only thread?
Posted by Christian Posta <ch...@gmail.com>.
+1 Andreas' comment.
So what i was thinking was something like this...
from("ibmmq1").to("seda:stage")
from("ibmmq2").to("seda:stage")
from("ibmmq3").to("seda:stage")
from("seda:stage?concurrentConsumesr=1").to("direct://buzComponent")
On Fri, Sep 6, 2013 at 3:57 AM, Andreas Gies <an...@wayofquality.de>wrote:
> One thing to keep in mind when you are experiencing odering issues is
> that you can use ActiveMQ's message groups to make all messages for
> one group to the same consumer. Very often that little trick helps
> and still allows some form of concurrency for different groups.
>
> Andreas
>
>
> On 09/05/2013 11:54 PM, gnani swami wrote:
>
>> Some of the messages where handled by wrong service and they are all
>> queued
>> in FailedErrorMessages directory. Application failed to process them. So
>> it
>> will end up in ordering, and lost message. Looking at our various
>> exception it is quite easy for us to understand that they are caused by
>> concurrency bug inside the buz logic.
>>
>> We like to move the <inOnly uri="direct://buzComponent" /> to new route
>> under some endpoint (in-mem-queue). Quick google doesn't return anything
>> related to multiplex, could you point me sample route? Can I create that
>> multiplex in the new route under new endpoint.
>>
>> Thanks
>>
>>
>>
>> On Fri, Sep 6, 2013 at 12:35 AM, Christian Posta
>> <ch...@gmail.com>**wrote:
>>
>> So what's the underlying concurrency issue? Ordering? Can you just have a
>>> route that multiplexes all of those incoming queues into a single queue
>>> (or
>>> in-mem queue) and then have a route w/ only one thread that does CBR and
>>> invoke the correct bean?
>>>
>>>
>>> On Thu, Sep 5, 2013 at 9:02 AM, gnani swami <projectnash1994@gmail.com
>>>
>>>> wrote:
>>>> Hi,
>>>>
>>>> Camel was wonderful piece of software and using it in production for
>>>> more
>>>> than a year. Our version of Camel was 2.10.1
>>>>
>>>> I recently added few additional route (and bug in buz logic too) to
>>>> interface with additional systems, all the routes are doing the similar
>>>> job. They read JMS message from an unique-end-point (MQ JMS Queue) and
>>>> invoke buzComponent (Camel component).
>>>>
>>>> But recently discovered that some subtle concurrency issues inside the
>>>> buzComponent causing trouble to us. And I am looking for some sort of
>>>>
>>> Camel
>>>
>>>> hack to prevent it from further damage by making all the end-point
>>>>
>>> consumer
>>>
>>>> to use one and only thread.
>>>>
>>>> 1) As a short term solution, we like to convert all the JMS component to
>>>> use single threaded threadPool (or taskExecutor), and that new thread
>>>>
>>> pool
>>>
>>>> shouldn't allow more than a thread across all the JMS end-point. Is it
>>>> possible? We are not worried about latency and performance for some
>>>>
>>> time.
>>>
>>>> 2) if there is a possibility, our camel error handlers were already
>>>> in-place, Can we assume that single thread would continue working
>>>> despite
>>>> any exception configured to errorHandler. ErrorHandlers will have its
>>>> own
>>>> thread.
>>>>
>>>> 3) I am also happy to introduce one or more route and end-point inside
>>>> camelcontex.xml, so all the buzComponent can be redirected into that new
>>>> route to make it SingleThreaded execution somehow.. are there any
>>>> suggestion to use some camel component (We could use any hack as long
>>>> as
>>>> configurable inside xml).
>>>>
>>>> I am pretty sure all the above approach may be short sighted, but
>>>> looking
>>>> for temporary solution which could work for few days. We are happy to
>>>> modify Camel xml, than changing code and making it complex.
>>>>
>>>> I appreciate feedback.
>>>>
>>>> Regards
>>>> Mohan
>>>>
>>>> <camelContext>
>>>> <route id="route-one">
>>>> <from uri="ibmmq1:queue:**fromSourceOne" />
>>>> <inOnly uri="direct://buzComponent" />
>>>> </route>
>>>> <route id="route-two">
>>>> <from uri="ibmmq2:queue:**fromSourceTwo" />
>>>> <inOnly uri="direct://buzComponent" />
>>>> </route>
>>>> <!-- problematic root due to buzComponent locking-->
>>>> <route id="high-speed-source-source-**3">
>>>> <from uri="ibmmq3:queue:**fromHighSpeedSourceOne" />
>>>> <inOnly uri="direct://buzComponent" />
>>>> </route>
>>>> <route id="high-speed-source-source-**4">
>>>> <from uri="ibmmq4:queue:**fromHighSpeedSourceTwo" />
>>>> <inOnly uri="direct://buzComponent" />
>>>> </route>
>>>> </camelContext>
>>>>
>>>> <bean id="ibmmq" class="org.apache.camel.**component.jms.JmsComponent">
>>>> <property name="connectionFactory">
>>>> <bean class="com.ibm.mq.jms.**MQConnectionFactory">
>>>> ...
>>>> </bean>
>>>> </property>
>>>> </bean>
>>>>
>>>>
>>>
>>> --
>>> *Christian Posta*
>>> http://www.christianposta.com/**blog<http://www.christianposta.com/blog>
>>> twitter: @christianposta
>>>
>>>
>
--
*Christian Posta*
http://www.christianposta.com/blog
twitter: @christianposta
Re: Are there any Camel hack to make all the JMS component to use
one and only thread?
Posted by Andreas Gies <an...@wayofquality.de>.
One thing to keep in mind when you are experiencing odering issues is
that you can use ActiveMQ's message groups to make all messages for
one group to the same consumer. Very often that little trick helps
and still allows some form of concurrency for different groups.
Andreas
On 09/05/2013 11:54 PM, gnani swami wrote:
> Some of the messages where handled by wrong service and they are all queued
> in FailedErrorMessages directory. Application failed to process them. So it
> will end up in ordering, and lost message. Looking at our various
> exception it is quite easy for us to understand that they are caused by
> concurrency bug inside the buz logic.
>
> We like to move the <inOnly uri="direct://buzComponent" /> to new route
> under some endpoint (in-mem-queue). Quick google doesn't return anything
> related to multiplex, could you point me sample route? Can I create that
> multiplex in the new route under new endpoint.
>
> Thanks
>
>
>
> On Fri, Sep 6, 2013 at 12:35 AM, Christian Posta
> <ch...@gmail.com>wrote:
>
>> So what's the underlying concurrency issue? Ordering? Can you just have a
>> route that multiplexes all of those incoming queues into a single queue (or
>> in-mem queue) and then have a route w/ only one thread that does CBR and
>> invoke the correct bean?
>>
>>
>> On Thu, Sep 5, 2013 at 9:02 AM, gnani swami <projectnash1994@gmail.com
>>> wrote:
>>> Hi,
>>>
>>> Camel was wonderful piece of software and using it in production for more
>>> than a year. Our version of Camel was 2.10.1
>>>
>>> I recently added few additional route (and bug in buz logic too) to
>>> interface with additional systems, all the routes are doing the similar
>>> job. They read JMS message from an unique-end-point (MQ JMS Queue) and
>>> invoke buzComponent (Camel component).
>>>
>>> But recently discovered that some subtle concurrency issues inside the
>>> buzComponent causing trouble to us. And I am looking for some sort of
>> Camel
>>> hack to prevent it from further damage by making all the end-point
>> consumer
>>> to use one and only thread.
>>>
>>> 1) As a short term solution, we like to convert all the JMS component to
>>> use single threaded threadPool (or taskExecutor), and that new thread
>> pool
>>> shouldn't allow more than a thread across all the JMS end-point. Is it
>>> possible? We are not worried about latency and performance for some
>> time.
>>> 2) if there is a possibility, our camel error handlers were already
>>> in-place, Can we assume that single thread would continue working despite
>>> any exception configured to errorHandler. ErrorHandlers will have its own
>>> thread.
>>>
>>> 3) I am also happy to introduce one or more route and end-point inside
>>> camelcontex.xml, so all the buzComponent can be redirected into that new
>>> route to make it SingleThreaded execution somehow.. are there any
>>> suggestion to use some camel component (We could use any hack as long as
>>> configurable inside xml).
>>>
>>> I am pretty sure all the above approach may be short sighted, but looking
>>> for temporary solution which could work for few days. We are happy to
>>> modify Camel xml, than changing code and making it complex.
>>>
>>> I appreciate feedback.
>>>
>>> Regards
>>> Mohan
>>>
>>> <camelContext>
>>> <route id="route-one">
>>> <from uri="ibmmq1:queue:fromSourceOne" />
>>> <inOnly uri="direct://buzComponent" />
>>> </route>
>>> <route id="route-two">
>>> <from uri="ibmmq2:queue:fromSourceTwo" />
>>> <inOnly uri="direct://buzComponent" />
>>> </route>
>>> <!-- problematic root due to buzComponent locking-->
>>> <route id="high-speed-source-source-3">
>>> <from uri="ibmmq3:queue:fromHighSpeedSourceOne" />
>>> <inOnly uri="direct://buzComponent" />
>>> </route>
>>> <route id="high-speed-source-source-4">
>>> <from uri="ibmmq4:queue:fromHighSpeedSourceTwo" />
>>> <inOnly uri="direct://buzComponent" />
>>> </route>
>>> </camelContext>
>>>
>>> <bean id="ibmmq" class="org.apache.camel.component.jms.JmsComponent">
>>> <property name="connectionFactory">
>>> <bean class="com.ibm.mq.jms.MQConnectionFactory">
>>> ...
>>> </bean>
>>> </property>
>>> </bean>
>>>
>>
>>
>> --
>> *Christian Posta*
>> http://www.christianposta.com/blog
>> twitter: @christianposta
>>
Re: Are there any Camel hack to make all the JMS component to use one
and only thread?
Posted by gnani swami <pr...@gmail.com>.
Some of the messages where handled by wrong service and they are all queued
in FailedErrorMessages directory. Application failed to process them. So it
will end up in ordering, and lost message. Looking at our various
exception it is quite easy for us to understand that they are caused by
concurrency bug inside the buz logic.
We like to move the <inOnly uri="direct://buzComponent" /> to new route
under some endpoint (in-mem-queue). Quick google doesn't return anything
related to multiplex, could you point me sample route? Can I create that
multiplex in the new route under new endpoint.
Thanks
On Fri, Sep 6, 2013 at 12:35 AM, Christian Posta
<ch...@gmail.com>wrote:
> So what's the underlying concurrency issue? Ordering? Can you just have a
> route that multiplexes all of those incoming queues into a single queue (or
> in-mem queue) and then have a route w/ only one thread that does CBR and
> invoke the correct bean?
>
>
> On Thu, Sep 5, 2013 at 9:02 AM, gnani swami <projectnash1994@gmail.com
> >wrote:
>
> > Hi,
> >
> > Camel was wonderful piece of software and using it in production for more
> > than a year. Our version of Camel was 2.10.1
> >
> > I recently added few additional route (and bug in buz logic too) to
> > interface with additional systems, all the routes are doing the similar
> > job. They read JMS message from an unique-end-point (MQ JMS Queue) and
> > invoke buzComponent (Camel component).
> >
> > But recently discovered that some subtle concurrency issues inside the
> > buzComponent causing trouble to us. And I am looking for some sort of
> Camel
> > hack to prevent it from further damage by making all the end-point
> consumer
> > to use one and only thread.
> >
> > 1) As a short term solution, we like to convert all the JMS component to
> > use single threaded threadPool (or taskExecutor), and that new thread
> pool
> > shouldn't allow more than a thread across all the JMS end-point. Is it
> > possible? We are not worried about latency and performance for some
> time.
> >
> > 2) if there is a possibility, our camel error handlers were already
> > in-place, Can we assume that single thread would continue working despite
> > any exception configured to errorHandler. ErrorHandlers will have its own
> > thread.
> >
> > 3) I am also happy to introduce one or more route and end-point inside
> > camelcontex.xml, so all the buzComponent can be redirected into that new
> > route to make it SingleThreaded execution somehow.. are there any
> > suggestion to use some camel component (We could use any hack as long as
> > configurable inside xml).
> >
> > I am pretty sure all the above approach may be short sighted, but looking
> > for temporary solution which could work for few days. We are happy to
> > modify Camel xml, than changing code and making it complex.
> >
> > I appreciate feedback.
> >
> > Regards
> > Mohan
> >
> > <camelContext>
> > <route id="route-one">
> > <from uri="ibmmq1:queue:fromSourceOne" />
> > <inOnly uri="direct://buzComponent" />
> > </route>
> > <route id="route-two">
> > <from uri="ibmmq2:queue:fromSourceTwo" />
> > <inOnly uri="direct://buzComponent" />
> > </route>
> > <!-- problematic root due to buzComponent locking-->
> > <route id="high-speed-source-source-3">
> > <from uri="ibmmq3:queue:fromHighSpeedSourceOne" />
> > <inOnly uri="direct://buzComponent" />
> > </route>
> > <route id="high-speed-source-source-4">
> > <from uri="ibmmq4:queue:fromHighSpeedSourceTwo" />
> > <inOnly uri="direct://buzComponent" />
> > </route>
> > </camelContext>
> >
> > <bean id="ibmmq" class="org.apache.camel.component.jms.JmsComponent">
> > <property name="connectionFactory">
> > <bean class="com.ibm.mq.jms.MQConnectionFactory">
> > ...
> > </bean>
> > </property>
> > </bean>
> >
>
>
>
> --
> *Christian Posta*
> http://www.christianposta.com/blog
> twitter: @christianposta
>
Re: Are there any Camel hack to make all the JMS component to use one
and only thread?
Posted by Christian Posta <ch...@gmail.com>.
So what's the underlying concurrency issue? Ordering? Can you just have a
route that multiplexes all of those incoming queues into a single queue (or
in-mem queue) and then have a route w/ only one thread that does CBR and
invoke the correct bean?
On Thu, Sep 5, 2013 at 9:02 AM, gnani swami <pr...@gmail.com>wrote:
> Hi,
>
> Camel was wonderful piece of software and using it in production for more
> than a year. Our version of Camel was 2.10.1
>
> I recently added few additional route (and bug in buz logic too) to
> interface with additional systems, all the routes are doing the similar
> job. They read JMS message from an unique-end-point (MQ JMS Queue) and
> invoke buzComponent (Camel component).
>
> But recently discovered that some subtle concurrency issues inside the
> buzComponent causing trouble to us. And I am looking for some sort of Camel
> hack to prevent it from further damage by making all the end-point consumer
> to use one and only thread.
>
> 1) As a short term solution, we like to convert all the JMS component to
> use single threaded threadPool (or taskExecutor), and that new thread pool
> shouldn't allow more than a thread across all the JMS end-point. Is it
> possible? We are not worried about latency and performance for some time.
>
> 2) if there is a possibility, our camel error handlers were already
> in-place, Can we assume that single thread would continue working despite
> any exception configured to errorHandler. ErrorHandlers will have its own
> thread.
>
> 3) I am also happy to introduce one or more route and end-point inside
> camelcontex.xml, so all the buzComponent can be redirected into that new
> route to make it SingleThreaded execution somehow.. are there any
> suggestion to use some camel component (We could use any hack as long as
> configurable inside xml).
>
> I am pretty sure all the above approach may be short sighted, but looking
> for temporary solution which could work for few days. We are happy to
> modify Camel xml, than changing code and making it complex.
>
> I appreciate feedback.
>
> Regards
> Mohan
>
> <camelContext>
> <route id="route-one">
> <from uri="ibmmq1:queue:fromSourceOne" />
> <inOnly uri="direct://buzComponent" />
> </route>
> <route id="route-two">
> <from uri="ibmmq2:queue:fromSourceTwo" />
> <inOnly uri="direct://buzComponent" />
> </route>
> <!-- problematic root due to buzComponent locking-->
> <route id="high-speed-source-source-3">
> <from uri="ibmmq3:queue:fromHighSpeedSourceOne" />
> <inOnly uri="direct://buzComponent" />
> </route>
> <route id="high-speed-source-source-4">
> <from uri="ibmmq4:queue:fromHighSpeedSourceTwo" />
> <inOnly uri="direct://buzComponent" />
> </route>
> </camelContext>
>
> <bean id="ibmmq" class="org.apache.camel.component.jms.JmsComponent">
> <property name="connectionFactory">
> <bean class="com.ibm.mq.jms.MQConnectionFactory">
> ...
> </bean>
> </property>
> </bean>
>
--
*Christian Posta*
http://www.christianposta.com/blog
twitter: @christianposta