Hi
You have mixed Spring versions in your pom.xml. I just spotted Spring 2.5.6
org.springframework
spring
2.5.6
You need Spring 3.0+ only.
You can run from command line
mvn dependency:tree
or
mvn dependency:list
To see all your JAR deps. Then you can spot mixed versio
Well, look at it this way. At least the camel riders now know of a
potential change to AMQ! :)
On Tue, Sep 18, 2012 at 11:08 AM, Claus Ibsen wrote:
> Ah sorry I did it again, sent to the wrong @dev.
> This talk should happen only on AMQ @dev.
>
> On Tue, Sep 18, 2012 at 5:04 PM, James Carman
>
Hi guys! Thanks for the responses. I believe that is a problem of the jars in
the pom but I still can't figure out why.
Here is my pom:
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://mave
Hi Babak,
that sounds good.
Thanks
Christian
Am 18.09.2012 16:32, schrieb Babak Vahdat:
Hi
IMHO instead of the "stop" workaround better let the IoC container do the
job for you. That's instead of declaring it like:
@EndpointInject
ProducerTemplate producer;
Simply do:
@Autowired
ProducerT
Ah sorry I did it again, sent to the wrong @dev.
This talk should happen only on AMQ @dev.
On Tue, Sep 18, 2012 at 5:04 PM, James Carman
wrote:
> Is this conversation spanning two lists? I would think the ActiveMQ
> community (those that aren't camel riders) would want to be involved,
> too. Th
Is this conversation spanning two lists? I would think the ActiveMQ
community (those that aren't camel riders) would want to be involved,
too. This should probably move to the ActiveMQ dev list.
On Tue, Sep 18, 2012 at 8:18 AM, Claus Ibsen wrote:
> Hi
>
> 1)
> I have experimented a bit and so f
Hi
IMHO instead of the "stop" workaround better let the IoC container do the
job for you. That's instead of declaring it like:
@EndpointInject
ProducerTemplate producer;
Simply do:
@Autowired
ProducerTemplate producer;
And declare the ProducerTemplate the way from the Wiki (see the XML-snippet
I think that is not necessary. I only wanted to check if it is normal
behaviour or if we have a bug.
Strangely it seemed to not hang in earlier versions. Not sure why though.
Christian
Am 18.09.2012 15:39, schrieb Claus Ibsen:
As the templates (their default impls) is associated with a
CamelCo
As the templates (their default impls) is associated with a
CamelContext, we could eventually also add logic, to enlist the
template in a list of active template stored on the camel context. So
when camel context shutdown, it could shutdown the templates as well -
as a fail safe.
And if a client i
Hi Claus,
thanks for the clarification. It is also great to have this in Javadoc.
Christian
Am 18.09.2012 15:26, schrieb Claus Ibsen:
On Tue, Sep 18, 2012 at 3:12 PM, Christian Schneider
wrote:
Hi all,
we had a problem with the camel shutdown at a Talend ESB Camel example after
updating to
On Tue, Sep 18, 2012 at 3:12 PM, Christian Schneider
wrote:
> Hi all,
>
> we had a problem with the camel shutdown at a Talend ESB Camel example after
> updating to camel 2.10-SNAPSHOT.
>
> The example uses a ProducerTemplate with a camel jms producer that is
> injected using an annotation:
> @End
Hi all,
we had a problem with the camel shutdown at a Talend ESB Camel example
after updating to camel 2.10-SNAPSHOT.
The example uses a ProducerTemplate with a camel jms producer that is
injected using an annotation:
@EndpointInject
ProducerTemplate producer;
At the end of the example main
Hi
1)
I have experimented a bit and so far the best tradeoff I have is
lib
lib/camel
lib/optional
lib/web
lib/extra
I moved the camel JARs into a separate lib, as Camel can be made
optional (only web requires it).
In lib/optional I have all the optional stuff, except for mqtt and leveldb.
mqtt a
13 matches
Mail list logo
