I'm with you, Jim. I think that is part of why others at my company consider
spring to be "evil" -- for a "light-weight" framework, there sure are a lot
of pieces you have to include and they seem to be growing and becoming more
intertwined with each new release. Like you, I'm not griping, it just seems
like everything in the java open-source world is starting to depend on
everything else in the java open-source world.

On Mon, Jul 19, 2010 at 3:57 PM, Jim Newsham <jnews...@referentia.com>wrote:

>  On 7/19/2010 8:13 AM, Claus Ibsen wrote:
>
>> Hi
>>
>>
>> On Mon, Jul 19, 2010 at 8:06 PM, Ron Smith<ronsmit...@gmail.com>  wrote:
>>
>>> Where I work, Spring has been declared "evil" so I am attempting to use
>>> camel without any of the Spring JARs but I can't find any examples of how
>>> to
>>> setup a JMS component without a Spring dependency. I am using Tibco as
>>> the
>>> JMS provider and it is providing JNDI.
>>>
>>>  It must be a touch workplace when a general considered standard
>> framework is considered evil?
>>
>> The camel-jms component leverages spring-jms for sending and receiving
>> JMS messages and therefore
>> you cannot use it without spring-jms.
>>
>> You can use plain JMS API if you want to avoid Spring and build a JMS
>> consumer.
>> For examples see the ActiveMQ in Action which shows that. And I am
>> sure you may find other examples by googling as well.
>>
>> To send the message to Camel is very easy from Java code. For example
>> just use the ProducerTemplate API.
>>
>
> We're also looking into using Camel + JMS (ActiveMQ in particular).  We
> don't use spring and have no intention to do so currently (no discussion
> about whether it's evil or not; it just doesn't suit our purposes at the
> moment).
>
> I was disappointed to discover that I needed to add the following jars in
> addition to camel-core, camel-jms, and activemq-all before it would run:
>  activemq-pool, commons-logging, commons-management, commons-pool,
> spring-aop, spring-beans, spring-context, spring-core, spring-jms,
> spring-tx.  Particularly for a project which claims to have minimal
> dependencies, this seems a little excessive.  I'm not griping -- if we
> choose to use Camel (which seems likely) then we'll happily (yet
> reluctantly) add these extra jars.  It just would be nice if such an
> internal dependency did not exist, for developers who do not use spring.
>
> Regards,
> Jim
>
>
>
>
>
>
>

Reply via email to