Hi
I kinda recall there is a destination name resolver you can use. A
person had this question eg 6 months ago (eg a long time ago).
With this resolver you could do the lookup in jndi and return the real
destination object found there.
On Wed, Jul 15, 2009 at 3:15 AM, Willem Jiang wrote:
> Hi,
>
Hi,
Apache camel support the binding the JNDI configure file[1] with the
camel context, but current jms component doesn't support it.
From current JMS URI, there is no flag to tell camel-jms componement
the queue name is JNDI logical name.
Please feel free to fill a JIRA[2] as a feature req
May be this will help?
http://fusesource.com/docs/router/1.6/component_ref/JMSComp.html
Marat
On Tue, Jul 14, 2009 at 2:18 PM, fjaouen wrote:
>
> Hi,
>
> I try to use Apache camel JMS (http://camel.apache.org/jms.html). And it
> works fine if I use physical name. But I would like to use a logic
Hi,
I try to use Apache camel JMS (http://camel.apache.org/jms.html). And it
works fine if I use physical name. But I would like to use a logical name
based on JNDI.
For example instead of having:
I would like to have:
Where MY_LOGICAL_QUEUE_NAME is boun
On Tue, Jul 14, 2009 at 12:51 PM, xueqiang.mi wrote:
>
> Although I force the edited route to reserve the original route id, but
> some
> inner processor id can't be set as original, such as the "to" id in XML.
> {code:xml}
>
> {code}
Is it only for certain processors that this is happening?
Although I force the edited route to reserve the original route id, but some
inner processor id can't be set as original, such as the "to" id in XML.
{code:xml}
{code}
Another question, if the user didn't change the route but click the save
button, the route will also be rebuild, is there some s
Added mine. Should we add all Camel committers by default? I don't
think there is any drawback in having a license and not using it,
besides giving out an email address to yourkit that is already public.
Hadrian
OS license list for YourKit
===
Claus Ibsen
Jonathan Anstey
T
Awesome. This is very similar to what we agreed upon yesterday with
Claus.
I personally much prefer the in/out terminology as it has pretty
clearly defined meaning in a few specs.
The 'original' term is a bit confusing and I would avoid it. It could
mean either that the original coming in
me too. :-)
On Tue, Jul 14, 2009 at 9:29 AM, Willem Jiang wrote:
> Added mine :)
>
> OS license list for YourKit
> ===
> Claus Ibsen
> Jonathan Anstey
> Willem Jiang
> Jon Anstey wrote:
>>
>> Cool. Would like to tinker a bit with this. Updated license list:
>>
>> OS license lis
Added mine :)
OS license list for YourKit
===
Claus Ibsen
Jonathan Anstey
Willem Jiang
Jon Anstey wrote:
Cool. Would like to tinker a bit with this. Updated license list:
OS license list for YourKit
===
Claus Ibsen
Jonathan Anstey
On Tue, Jul 14, 2009 at 9:12
I wouldn't mind having it around to tinker with. Add myself onto the
list.
OS license list for YourKit
===
Claus Ibsen
Jonathan Anstey
Timothy Bish
On Tue, 2009-07-14 at 10:29 -0230, Jon Anstey wrote:
> Cool. Would like to tinker a bit with this. Updated license list:
>
> OS lic
Cool. Would like to tinker a bit with this. Updated license list:
OS license list for YourKit
===
Claus Ibsen
Jonathan Anstey
On Tue, Jul 14, 2009 at 9:12 AM, Claus Ibsen wrote:
> Hi
>
> I am in talks with YourKit - http://www.yourkit.com/
> About getting licenses for their prof
[
https://issues.apache.org/activemq/browse/CAMEL-1829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Anstey resolved CAMEL-1829.
Resolution: Duplicate
Fix Version/s: 2.0.0
Assignee: Jonathan Anstey
Fi
Hi
I am in talks with YourKit - http://www.yourkit.com/
About getting licenses for their profiler for the Apache Camel project.
They require that the license is on a per developer basis.
So I am gathering a list of developer names for them.
If you are interested in a license please provide your
Roman Kalukiewicz wrote:
2009/7/14 James Strachan :
2009/7/13 Claus Ibsen :
Reading between the lines; are you really just trying to make folks
use (what is currently called) "getOut()" and never try mutate what is
currently called getIn()?
i.e. so by default the "OUT" property is defaulted to
2009/7/14 Willem Jiang :
> James Strachan wrote:
>>
>> 2009/7/13 Claus Ibsen :
Reading between the lines; are you really just trying to make folks
use (what is currently called) "getOut()" and never try mutate what is
currently called getIn()?
i.e. so by default the "O
James Strachan wrote:
2009/7/13 Claus Ibsen :
Reading between the lines; are you really just trying to make folks
use (what is currently called) "getOut()" and never try mutate what is
currently called getIn()?
i.e. so by default the "OUT" property is defaulted to a copy of IN
that folks can ch
2009/7/14 Roman Kalukiewicz :
> 2009/7/14 James Strachan :
>> 2009/7/13 Claus Ibsen :
Reading between the lines; are you really just trying to make folks
use (what is currently called) "getOut()" and never try mutate what is
currently called getIn()?
i.e. so by default
2009/7/14 James Strachan :
> 2009/7/13 Claus Ibsen :
>>>
>>> Reading between the lines; are you really just trying to make folks
>>> use (what is currently called) "getOut()" and never try mutate what is
>>> currently called getIn()?
>>>
>>> i.e. so by default the "OUT" property is defaulted to a c
> Yeah.
>
> BTW we could leave getIn() and getOut() & try implement the
> ImmutableWrapper and CopyOnWriteFacade for In/Out respectively and try
> them out inside the current API - before we go ahead with any kind of
> renaming of getIn() and getOut().
>
> Maybe we could even keep getIn() / getOut
2009/7/14 Claus Ibsen :
>> I think we're kinda mostly on the same page (though saying it in
>> different ways). BTW I'm taking off my devils advocate hat now :)...
>>
>> What we're agreeing on I think is that;
>>
>> * getIn() should be immutable (when folks try to change it we can
>> throw the exce
> I think we're kinda mostly on the same page (though saying it in
> different ways). BTW I'm taking off my devils advocate hat now :)...
>
> What we're agreeing on I think is that;
>
> * getIn() should be immutable (when folks try to change it we can
> throw the exception and describe how getOut()
seda component - use pool size from concurrent consumers parameter
--
Key: CAMEL-1830
URL: https://issues.apache.org/activemq/browse/CAMEL-1830
Project: Apache Camel
Issue Type:
[
https://issues.apache.org/activemq/browse/CAMEL-1830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-1830.
Resolution: Working as Designed
It already did :)
> seda component - use pool size from concur
2009/7/13 Claus Ibsen :
>>
>> Reading between the lines; are you really just trying to make folks
>> use (what is currently called) "getOut()" and never try mutate what is
>> currently called getIn()?
>>
>> i.e. so by default the "OUT" property is defaulted to a copy of IN
>> that folks can change/
25 matches
Mail list logo
