Re: Issue With namespace handlers Blueprint

[Grzegorz Grzybek]

Hello

With camel blueprint you don't use spring-dm and its namespaces. Your
XML describing Camel route should use
http://camel.apache.org/schema/blueprint and
http://www.osgi.org/xmlns/blueprint/v1.0.0 namespaces.

regards
Grzegorz

2016-02-09 8:49 GMT+01:00 gurmehar.kalra :
> Hi,
>
> Facing Issue as :
>Bundle  is waiting for namespace handlers
> [http://www.springframework.org/schema/osgi-compendium,
> http://www.springframework.org/schema/context]
> and due to this Buleprint bundle is going Grace Pierod
>
>
>
> --
> Regards,
> Gurmehar Singh
> #9891999169
>
> 
> Disclaimer: Information contained in this e-mail is proprietary to
> JetSynthesys Pvt Ltd, its associated companies and/ or its customers and is
> intended for use only by the individual or entity to which it is addressed.
> This e-mail may contain information that is privileged, confidential or
> exempt from disclosure under applicable law. If you are not the intended
> recipient or it appears that this mail has been forwarded to you without
> proper authority, you are notified that any use or dissemination of this
> information in any manner is strictly prohibited. In such cases, please
> notify us immediately at mailmas...@jetsynthesys.com and delete this mail
> from your records.

Re: Transaction problem with Camel, ActiveMQ and Spring JMS

[Stephan Burkard]

Hmmm... not really sure about #2... or do I also need a JTA Tx manager for
working with multiple brokers?



On Tue, Feb 9, 2016 at 8:48 AM, Stephan Burkard  wrote:

> Hi Quinn
>
> I found this blog post that explains some things we found out:
>
> http://tmielke.blogspot.ch/2012/03/camel-jms-with-transactions-lessons.html
>
> => See sections 2) and 3) for simple configuration without Tx manager
>
> => See section 7) for Tx manager with transacted = false
>
> In that blog post the author also references a discussion with the Spring
> folks. In this discussion the result is: "For the modern DMLC (
> DefaultMessageListenerContainer), it's only necessary to specify an
> external transaction manager if a JTA-aware manager is needed"
>
> Complete discussion:
> http://forum.spring.io/forum/spring-projects/integration/jms/114247-jms-dmlc-not-caching-connection-when-using-tx-despite-cachelevel-cache-consumer
>
> However: what is missing, is the fact that a defined Tx manager AND
> transacted = true creates a transaction flaw.
>
> The Javadoc of Spring DMLC says: It is strongly recommended to EITHER set
> "sessionTransacted" to "true" OR specify an external "transactionManager".
>
> So the Camel transacted flag sets sessionTransacted and that means for
> Spring to use local session transactions. A defined Tx manager means for
> Spring that you use a JTA Tx manager instead. But there seems to be no code
> to avoid setting both of them. Perhaps sessionTransacted is ignored if you
> really use a JTA Tx manager?
>
> To sum things up as I understand them:
> 1. When we just work with one broker, we only set transacted = true. No
> need for any Tx manager.
> 2. When we work with multiple brokers, we need to define a Spring JMS
> Transaction Manager and we set transacted = false to tell Spring NOT to use
> local session transactions.
> 3. When we want to span JMS and other systems in a transaction we need a
> JTA Tx manager and we set transacted = false to tell Spring NOT to use
> local session transactions.
>
>
> And on top of all that, I learned from section 8) of the blog post that I
> always configure too much connections on the connection factory.
>
> Thank you very much!
> Stephan
>
>
>
>
> On Mon, Feb 8, 2016 at 5:41 PM, Quinn Stevenson <
> qu...@pronoia-solutions.com> wrote:
>
>> Good to hear ;-)
>>
>> Yeah - I meant camel-sjms - I think autocorrect got me on that one -
>> sorry.  I like the way camel-sjms does it’s internal pooling - I don’t need
>> to create pooled connection factories anymore.  You can also just add
>> “transacted=true” in the URI and you’re using JMS Session transactions - no
>> other config needed.
>>
>> I have a guess as to what’s going on with the tests - the “transacted”
>> attribute enables/disables JMS Session transactions, which is why the
>> example named “noTxManager” worked.  It’s true it wasn’t using a
>> transaction manager, it didn’t need one - JMS Session transactions don’t
>> require an external transaction manager.
>>
>> In the second example, we were trying to use two types of transactions at
>> the same time - transactions managed by the Spring JMS transaction manager
>> and JMS Session transactions.  Somewhere in the Spring wiring, something
>> got crossed with this and we would up without good transactional behavior.
>> The details of why are beyond me here - somebody more knowledgeable with
>> Spring JMS will have to answer that.
>>
>> Anyway - I’m glad it’s working now.
>>
>> Also, theres a ActiveMQ JUnit rule in 5.13.1 that would make this testing
>> easier (shameless plug - I contributed the rule ;-) ).  It should pickup
>> the ActiveMQ broker jars from the test class path, so it should work with
>> versions of the broker other than 5.13.1.
>>
>> > On Feb 8, 2016, at 9:30 AM, Stephan Burkard  wrote:
>> >
>> > Oh, our messages overlapped...
>> >
>> > Your questions:
>> >
>> > "... doing this queue to queue work using one or two ActiveMQ brokers?"
>> > => One broker
>> >
>> > "... you may want to try camel-sims"
>> > => I guess you mean Camel sJms, that's the closest match I found in the
>> > list of Camel components on GitHub :-) Never heard (ok, it is only since
>> > 2.11), but I will have a look at it.
>> >
>> > "If you’d be using XA in the real world..."
>> > => No, we don't use XA
>> >
>> >
>> > But your hint with "transacted = false" works! I was able to run the
>> > "standard" version 5 times in a row and it was always successful.
>> >
>> > Currently it looks like either one has to define the whole Tx stuff and
>> set
>> > transacted = false OR to use the simple config with transacted = true.
>> >
>> > At least I learned that I have not real understanding what this flag
>> does.
>> > And I claim that most examples use transacted = true even when they
>> define
>> > Tx manager etc.
>> >
>> > Regards
>> > Stephan
>> >
>> >
>> >
>> >
>> >
>> > On Mon, Feb 8, 2016 at 4:59 PM, Stephan Burkard 
>> wrote:
>> >
>> >> Hi Quinn
>> >>
>> >> Here is the new version of my test pr

Re: Redelivery per Endpoint

[Claus Ibsen]

Camel ought to only retry the "step" in the route that failed, eg only
the SQL when you configure its error handler.

On Tue, Feb 9, 2016 at 8:53 AM, NES  wrote:
> Thank you for your response.
>
> I use Camel 2.16.1.
>
>
>
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/Redelivery-per-Endpoint-tp5777413p5777424.html
> Sent from the Camel - Users mailing list archive at Nabble.com.



-- 
Claus Ibsen
-
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

Re: Issue With namespace handlers Blueprint

[Claus Ibsen]

A typical problem with this is that you use some Camel components /
data formats etc in the blueprint xml file, which you have not yet
installed in the karaf container.

Install them using features:install camel-



On Tue, Feb 9, 2016 at 8:49 AM, gurmehar.kalra
 wrote:
> Hi,
>
> Facing Issue as :
>Bundle  is waiting for namespace handlers
> [http://www.springframework.org/schema/osgi-compendium,
> http://www.springframework.org/schema/context]
> and due to this Buleprint bundle is going Grace Pierod
>
>
>
> --
> Regards,
> Gurmehar Singh
> #9891999169
>
> 
> Disclaimer: Information contained in this e-mail is proprietary to
> JetSynthesys Pvt Ltd, its associated companies and/ or its customers and is
> intended for use only by the individual or entity to which it is addressed.
> This e-mail may contain information that is privileged, confidential or
> exempt from disclosure under applicable law. If you are not the intended
> recipient or it appears that this mail has been forwarded to you without
> proper authority, you are notified that any use or dissemination of this
> information in any manner is strictly prohibited. In such cases, please
> notify us immediately at mailmas...@jetsynthesys.com and delete this mail
> from your records.



-- 
Claus Ibsen
-
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

Re: Redelivery per Endpoint

[NES]

Thank you for your response.

I use Camel 2.16.1.



--
View this message in context: 
http://camel.465427.n5.nabble.com/Redelivery-per-Endpoint-tp5777413p5777424.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Issue With namespace handlers Blueprint

[gurmehar . kalra]

Hi,

Facing Issue as :
   Bundle  is waiting for namespace handlers 
[http://www.springframework.org/schema/osgi-compendium, 
http://www.springframework.org/schema/context]
and due to this Buleprint bundle is going Grace Pierod



--
Regards,
Gurmehar Singh
#9891999169


Disclaimer: Information contained in this e-mail is proprietary to JetSynthesys 
Pvt Ltd, its associated companies and/ or its customers and is intended for use 
only by the individual or entity to which it is addressed. This e-mail may 
contain information that is privileged, confidential or exempt from disclosure 
under applicable law. If you are not the intended recipient or it appears that 
this mail has been forwarded to you without proper authority, you are notified 
that any use or dissemination of this information in any manner is strictly 
prohibited. In such cases, please notify us immediately at 
mailmas...@jetsynthesys.com and delete this mail from your records.

Re: Transaction problem with Camel, ActiveMQ and Spring JMS

[Stephan Burkard]

Hi Quinn

I found this blog post that explains some things we found out:

http://tmielke.blogspot.ch/2012/03/camel-jms-with-transactions-lessons.html

=> See sections 2) and 3) for simple configuration without Tx manager

=> See section 7) for Tx manager with transacted = false

In that blog post the author also references a discussion with the Spring
folks. In this discussion the result is: "For the modern DMLC (
DefaultMessageListenerContainer), it's only necessary to specify an
external transaction manager if a JTA-aware manager is needed"

Complete discussion:
http://forum.spring.io/forum/spring-projects/integration/jms/114247-jms-dmlc-not-caching-connection-when-using-tx-despite-cachelevel-cache-consumer

However: what is missing, is the fact that a defined Tx manager AND
transacted = true creates a transaction flaw.

The Javadoc of Spring DMLC says: It is strongly recommended to EITHER set
"sessionTransacted" to "true" OR specify an external "transactionManager".

So the Camel transacted flag sets sessionTransacted and that means for
Spring to use local session transactions. A defined Tx manager means for
Spring that you use a JTA Tx manager instead. But there seems to be no code
to avoid setting both of them. Perhaps sessionTransacted is ignored if you
really use a JTA Tx manager?

To sum things up as I understand them:
1. When we just work with one broker, we only set transacted = true. No
need for any Tx manager.
2. When we work with multiple brokers, we need to define a Spring JMS
Transaction Manager and we set transacted = false to tell Spring NOT to use
local session transactions.
3. When we want to span JMS and other systems in a transaction we need a
JTA Tx manager and we set transacted = false to tell Spring NOT to use
local session transactions.


And on top of all that, I learned from section 8) of the blog post that I
always configure too much connections on the connection factory.

Thank you very much!
Stephan




On Mon, Feb 8, 2016 at 5:41 PM, Quinn Stevenson  wrote:

> Good to hear ;-)
>
> Yeah - I meant camel-sjms - I think autocorrect got me on that one -
> sorry.  I like the way camel-sjms does it’s internal pooling - I don’t need
> to create pooled connection factories anymore.  You can also just add
> “transacted=true” in the URI and you’re using JMS Session transactions - no
> other config needed.
>
> I have a guess as to what’s going on with the tests - the “transacted”
> attribute enables/disables JMS Session transactions, which is why the
> example named “noTxManager” worked.  It’s true it wasn’t using a
> transaction manager, it didn’t need one - JMS Session transactions don’t
> require an external transaction manager.
>
> In the second example, we were trying to use two types of transactions at
> the same time - transactions managed by the Spring JMS transaction manager
> and JMS Session transactions.  Somewhere in the Spring wiring, something
> got crossed with this and we would up without good transactional behavior.
> The details of why are beyond me here - somebody more knowledgeable with
> Spring JMS will have to answer that.
>
> Anyway - I’m glad it’s working now.
>
> Also, theres a ActiveMQ JUnit rule in 5.13.1 that would make this testing
> easier (shameless plug - I contributed the rule ;-) ).  It should pickup
> the ActiveMQ broker jars from the test class path, so it should work with
> versions of the broker other than 5.13.1.
>
> > On Feb 8, 2016, at 9:30 AM, Stephan Burkard  wrote:
> >
> > Oh, our messages overlapped...
> >
> > Your questions:
> >
> > "... doing this queue to queue work using one or two ActiveMQ brokers?"
> > => One broker
> >
> > "... you may want to try camel-sims"
> > => I guess you mean Camel sJms, that's the closest match I found in the
> > list of Camel components on GitHub :-) Never heard (ok, it is only since
> > 2.11), but I will have a look at it.
> >
> > "If you’d be using XA in the real world..."
> > => No, we don't use XA
> >
> >
> > But your hint with "transacted = false" works! I was able to run the
> > "standard" version 5 times in a row and it was always successful.
> >
> > Currently it looks like either one has to define the whole Tx stuff and
> set
> > transacted = false OR to use the simple config with transacted = true.
> >
> > At least I learned that I have not real understanding what this flag
> does.
> > And I claim that most examples use transacted = true even when they
> define
> > Tx manager etc.
> >
> > Regards
> > Stephan
> >
> >
> >
> >
> >
> > On Mon, Feb 8, 2016 at 4:59 PM, Stephan Burkard 
> wrote:
> >
> >> Hi Quinn
> >>
> >> Here is the new version of my test project that uses an embedded
> ActiveMQ
> >> broker. Since the AMQ libs are of version 5.9.0 (standard edition)
> there is
> >> no more special Redhat version.
> >>
> >> There is a new BrokerManagementExecutor that is configured to stop the
> >> broker 5 seconds after the test starts. On my machine the broker
> shutdown
> >> happens after about 400 messag

Re: Camel-xmlsecurity :No XML schema found

[Claus Ibsen]

You need to put the test.xsd file together with your Camel application
so they are in the same OSGi bundle, so the classloder can find the
file.

Look at some of the other osgi examples that are in the examples of Camel.
https://github.com/apache/camel/tree/master/examples

On Tue, Feb 9, 2016 at 6:16 AM, Jack Ding  wrote:
> Hello,
>
> I am testing the  XML Security component according to the example from the 
> camel-xmlsecurity website. For example the following producer refers to the 
> Test.xsd:
>
>  uri="xmlsecurity:sign://detached?keyAccessor=#keyAccessorBean&xpathsToIdAttributes=#xpathsToIdAttributesBean&schemaResourceUri=Test.xsd"
>  />
>
> I am testing this in the karaf and I have put the Test.xsd in the following 
> folder:
>
> apache-karaf-2.3.11/instances/mytestinstance/
> However I am getting this error:
> org.apache.camel.component.xmlsecurity.api.XmlSignatureException: XML 
> Signature component is wrongly configured: No XML schema found for specified 
> schema resource URI Test.xsd
>
> My camel version is 2.14.3.
>
> According to the document it is the classpath:
> schemaResourceUri: Since 2.14.0. Classpath to the XML Schema file
>
> Could anybody advise what the classpath exactly is and where I should I put 
> the Test.xsd in Karaf container for xmlsecurity endpoint to access it?
>
> Thanks in advance
>



-- 
Claus Ibsen
-
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

Re: Redelivery per Endpoint

[Claus Ibsen]

What version of Camel do you use?

On Tue, Feb 9, 2016 at 6:53 AM, NES  wrote:
> Hi, I'm implentnting the function that receive a message from servlet
> endpoint and send it to some endpoints.
>
> like this.
>
> 
> 
> 
> 
>  />
> 
> 
> 
>
> Now, I want to add the retry option to every endpoint.
> e.g. if sending message by http4 and activemq is success, and by sql is
> failed, I want to only execute query again.
> I also want to define retry count and interval separately.
>
> I tried to use Redelivery Policy of Camel, but onException and Error Handler
> don't have endpoint scope.
>
> How can I implement retry options?
> I’d appreciate it.
>
>
>
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/Redelivery-per-Endpoint-tp5777413.html
> Sent from the Camel - Users mailing list archive at Nabble.com.



-- 
Claus Ibsen
-
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

Redelivery per Endpoint

[NES]

Hi, I'm implentnting the function that receive a message from servlet
endpoint and send it to some endpoints.

like this.










Now, I want to add the retry option to every endpoint.
e.g. if sending message by http4 and activemq is success, and by sql is
failed, I want to only execute query again.
I also want to define retry count and interval separately.

I tried to use Redelivery Policy of Camel, but onException and Error Handler
don't have endpoint scope.

How can I implement retry options?
I’d appreciate it.



--
View this message in context: 
http://camel.465427.n5.nabble.com/Redelivery-per-Endpoint-tp5777413.html
Sent from the Camel - Users mailing list archive at Nabble.com.

OsgiServiceRegistry caching service references, why?

[Tim Jones]

I have looked at the code in org.apache.camel.core.osgi.OsgiServiceRegistry
(camel-core-osgi-2.15.4) and it appears to cache the service references.
This means that if I uninstall/install the bundle supplying the service it
wont automagically 'pick up' the new service. 

For what reason(s) are the service references cached?

Note - after modifying OsgiServiceRegistry and removing the cache a new
service is picked up and behaves more like I would expect in a dynamic OSGi
environment.




--
View this message in context: 
http://camel.465427.n5.nabble.com/OsgiServiceRegistry-caching-service-references-why-tp5777410.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Camel-xmlsecurity :No XML schema found

[Jack Ding]

Hello,

I am testing the  XML Security component according to the example from the 
camel-xmlsecurity website. For example the following producer refers to the 
Test.xsd:



I am testing this in the karaf and I have put the Test.xsd in the following 
folder:
 
apache-karaf-2.3.11/instances/mytestinstance/
However I am getting this error:
org.apache.camel.component.xmlsecurity.api.XmlSignatureException: XML Signature 
component is wrongly configured: No XML schema found for specified schema 
resource URI Test.xsd

My camel version is 2.14.3.

According to the document it is the classpath:
schemaResourceUri: Since 2.14.0. Classpath to the XML Schema file

Could anybody advise what the classpath exactly is and where I should I put the 
Test.xsd in Karaf container for xmlsecurity endpoint to access it?  

Thanks in advance 

Re: CamelBlueprintTestSupport No bean could be found in the registry

[Brad Johnson]

What I meant was if he is using the actual implementation or the test stub
is the second bundle then he can simply refer to in the test scope.
There's one huge caveat there though.  It has to be a pure OSGi service
that does not rely on another CamelContext.  PojoSR is not capable of
testing across multiple contexts.  My guess is that he has something
associated with a second camel context in the service bundle.  So if the
bundle declares a service like:

 
  
 

or


 
  
 

Then that can be used during testing from one bundle to the other and
switched to and from the actual implementation to a test
implementation by changing what the bean class is..  It can use its
own blueprint xml, obviously, it just can't rely on a second camel
context.

Those can be switched.  In some cases one can then use this:


 
  
 

And change it with configuration.  As long as one doesn't get multiple
contexts involved.  Hopefully in Camel 3 they will move to a karaf
environment for tests (whether through Pax Exam or something else.)

When my clients ask what I find weakest in Camel/blueprint I
automatically reply "testing".



On Mon, Feb 8, 2016 at 1:37 PM, enigma  wrote:

> @Ranx - With reference to your statement - " If the first bundle is in his
> POM with a scope of
> test then it should be available during testing. ".
>
> Are you saying that it is possible to invoke the asService method *without
> *the the Stub Implementation and the OSGI can invoke the actual
> implementation?
>
> If that is the case, then I have tried it that approach and was NOT
> successful. Not sure, if I am missing something here.
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/CamelBlueprintTestSupport-No-bean-could-be-found-in-the-registry-tp5777228p5777405.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>

Re: CamelBlueprintTestSupport No bean could be found in the registry

[enigma]

@Ranx - With reference to your statement - " If the first bundle is in his
POM with a scope of 
test then it should be available during testing. ". 

Are you saying that it is possible to invoke the asService method *without
*the the Stub Implementation and the OSGI can invoke the actual
implementation?  

If that is the case, then I have tried it that approach and was NOT
successful. Not sure, if I am missing something here. 



--
View this message in context: 
http://camel.465427.n5.nabble.com/CamelBlueprintTestSupport-No-bean-could-be-found-in-the-registry-tp5777228p5777405.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: CamelBlueprintTestSupport No bean could be found in the registry

[Brad Johnson]

Perhaps I confused matters.  The interface canonical name is the key to the
registry and the stub is the implementation.  I'm not sure if PojoSR
proxies that as it would be in an actual OSGi environment but I'm guessing
that it does.
As you know the proxy class in OSGi dynamically implements the interface
and acts as the intermediary to calls to the actual implementation.

The OSGi/PojoSR are using the interface name as the key for look up. But he
was having a problem when he ran his two bundles of the second bundle not
finding the interface in the registry for a service that was being exported
by his first bundle.  If the first bundle is in his POM with a scope of
test then it should be available during testing.

Sorry if I sewed confusion there.

Brad

On Mon, Feb 8, 2016 at 9:19 AM, Quinn Stevenson  wrote:

> I’m a little confused here - asService take the object implementing the
> interface and the service property key/values - I’m not sure how that could
> even work as an interface instead of the implementation object.  The
> service interface is provided earlier in the call ( the key in services.put
> ), and I like having the string there as well so I don’t have to add
> dependencies to my project all the time (when I’m using OSGi classes that
> are provided by the framework).
>
> That said, I’m always looking for ways to simplify tests - do you have an
> idea on how this could work?  Maybe you could do a prototype that we could
> see?
>
>
> > On Feb 7, 2016, at 6:43 PM, Brad Johnson 
> wrote:
> >
> > According
> > to my humble opinion, the asService() method should ideally have
> Interface
> > instead of Implementation argument.
> >
> > The asService is there to create a proxy to the actual implementation
> class
> > I believe.  What you are actually putting in the registry is a key of the
> > value of the full package and class name of the interface.  That's what
> > blueprint is going to look up the service based upon.  The value is what
> > you put in as the implementation.
> >
> > In a true blueprint environment that implementation will be hidden
> behind a
> > proxy object that exposes the interface.  Any bundle wanting to use that
> > proxied implementation then just tells it what the package anc class name
> > of the interface are.  In other words, when that interface is fetched
> from
> > the OSGi registry and handed to the requester, the requester doesn't know
> > what concrete implementation it is talking to. It may be a test stub, it
> > may be the actual implementation.  In fact, if you try to then cast that
> to
> > the concrete implementation of the class it will fail because what it
> finds
> > is a proxy of the interface.  This also makes it possible to hot swap
> > bundles at run time because the proxy stays the same but the
> implementation
> > changes.
> >
> > I'm still mystified why your test class wasn't picking up the service
> from
> > your first bundle though.  If you have have it exported and referenced
> and
> > listed as a test dependency in your client bundle then it should be
> > automatically loaded up.  One of those pieces sounds as if it is missing.
> >
> >  @Override
> >protected void
> > addServicesOnStartup(Map>
> > services) {
> >services.put( MyServiceInterface.class.getName(), asService(new
> > StubServiceImplementation(), "implementation", "stub"));
> >}
> >
> >
> > On Fri, Feb 5, 2016 at 4:53 PM, enigma  wrote:
> >
> >> Thank you and Have a good weekend! :)
> >>
> >>
> >>
> >> --
> >> View this message in context:
> >>
> http://camel.465427.n5.nabble.com/CamelBlueprintTestSupport-No-bean-could-be-found-in-the-registry-tp5777228p5777317.html
> >> Sent from the Camel - Users mailing list archive at Nabble.com.
> >>
>
>

Re: mock not working if id too long

[Claus Ibsen]

That is just the output of that message history table that limits to a
20 chars in those columns.

There is no id limit in Camel.

On Mon, Feb 8, 2016 at 5:45 PM, trbvm  wrote:
> Hi guys,
>
> I'm observing strange behaviour in tests, where I've used to use verbose ids
> for routes and processing steps to be able to mock them in tests with
> weaveById method. But it seems to me, if id is longer then 18 chars, then
> the step in route will not be mocked or, at least not properly mocked.
>
> Can anyone confirm this? Does camel trim ids? At least, in log they are
> trimmed. In example below the id should be abcdefgeleader-selection. I
> thought, it's just readability issue, but after shortening ids, my test
> became green.
>
>
> Message History
> ---
> RouteId  ProcessorId  Processor
> Elapsed (ms)
> [abcdefgeleader-sel] [abcdefgeleader-sel] [file://in?moveFailed=error] [
> 50]
>
>
>
>
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/mock-not-working-if-id-too-long-tp5777381.html
> Sent from the Camel - Users mailing list archive at Nabble.com.



-- 
Claus Ibsen
-
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

mock not working if id too long

[trbvm]

Hi guys,

I'm observing strange behaviour in tests, where I've used to use verbose ids
for routes and processing steps to be able to mock them in tests with
weaveById method. But it seems to me, if id is longer then 18 chars, then
the step in route will not be mocked or, at least not properly mocked.

Can anyone confirm this? Does camel trim ids? At least, in log they are
trimmed. In example below the id should be abcdefgeleader-selection. I
thought, it's just readability issue, but after shortening ids, my test
became green.


Message History
---
RouteId  ProcessorId  Processor 
  
Elapsed (ms)
[abcdefgeleader-sel] [abcdefgeleader-sel] [file://in?moveFailed=error] [   
50]




--
View this message in context: 
http://camel.465427.n5.nabble.com/mock-not-working-if-id-too-long-tp5777381.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Transaction problem with Camel, ActiveMQ and Spring JMS

[Quinn Stevenson]

Good to hear ;-)

Yeah - I meant camel-sjms - I think autocorrect got me on that one - sorry.  I 
like the way camel-sjms does it’s internal pooling - I don’t need to create 
pooled connection factories anymore.  You can also just add “transacted=true” 
in the URI and you’re using JMS Session transactions - no other config needed.

I have a guess as to what’s going on with the tests - the “transacted” 
attribute enables/disables JMS Session transactions, which is why the example 
named “noTxManager” worked.  It’s true it wasn’t using a transaction manager, 
it didn’t need one - JMS Session transactions don’t require an external 
transaction manager.

In the second example, we were trying to use two types of transactions at the 
same time - transactions managed by the Spring JMS transaction manager and JMS 
Session transactions.  Somewhere in the Spring wiring, something got crossed 
with this and we would up without good transactional behavior.  The details of 
why are beyond me here - somebody more knowledgeable with Spring JMS will have 
to answer that.

Anyway - I’m glad it’s working now.  

Also, theres a ActiveMQ JUnit rule in 5.13.1 that would make this testing 
easier (shameless plug - I contributed the rule ;-) ).  It should pickup the 
ActiveMQ broker jars from the test class path, so it should work with versions 
of the broker other than 5.13.1.

> On Feb 8, 2016, at 9:30 AM, Stephan Burkard  wrote:
> 
> Oh, our messages overlapped...
> 
> Your questions:
> 
> "... doing this queue to queue work using one or two ActiveMQ brokers?"
> => One broker
> 
> "... you may want to try camel-sims"
> => I guess you mean Camel sJms, that's the closest match I found in the
> list of Camel components on GitHub :-) Never heard (ok, it is only since
> 2.11), but I will have a look at it.
> 
> "If you’d be using XA in the real world..."
> => No, we don't use XA
> 
> 
> But your hint with "transacted = false" works! I was able to run the
> "standard" version 5 times in a row and it was always successful.
> 
> Currently it looks like either one has to define the whole Tx stuff and set
> transacted = false OR to use the simple config with transacted = true.
> 
> At least I learned that I have not real understanding what this flag does.
> And I claim that most examples use transacted = true even when they define
> Tx manager etc.
> 
> Regards
> Stephan
> 
> 
> 
> 
> 
> On Mon, Feb 8, 2016 at 4:59 PM, Stephan Burkard  wrote:
> 
>> Hi Quinn
>> 
>> Here is the new version of my test project that uses an embedded ActiveMQ
>> broker. Since the AMQ libs are of version 5.9.0 (standard edition) there is
>> no more special Redhat version.
>> 
>> There is a new BrokerManagementExecutor that is configured to stop the
>> broker 5 seconds after the test starts. On my machine the broker shutdown
>> happens after about 400 messages are sent. Some seconds after the broker is
>> stopped, it starts again and the test finishes. I guess the automagical
>> broker restart is due to the vm-transport used.
>> 
>> Results on my machine:
>> 
>> 1. The "noTxManager" version still never fails, so it never loses a
>> message between the queues. It often misses one or two messages, but always
>> on both queues. So these messages could not be sent from the client, but
>> all messages that arrived at the first queue also arrive at the second
>> queue.
>> 
>> 2. The "standard" version fails on almost every attempt, it mostly loses
>> one or two messages between the queues. So these messags arrived at the
>> first queue but not on the second one.
>> 
>> Since the embedded broker is stopped at the end of the test, I added an
>> additional Camel route that consumes the default DLQ. I added the messages
>> arrived at the DLQ in the test summary output. But on my machine I never
>> had messages in it.
>> 
>> I hope you can reproduce the problem now more easily.
>> 
>> Regards
>> Stephan
>> 
>> 
>> 
>> 
>> 
>> 
>> On Sat, Feb 6, 2016 at 10:32 PM, Stephan Burkard 
>> wrote:
>> 
>>> Hi Quinn
>>> 
>>> I don't think that you need to match exactly my broker version. I had
>>> first discovered this issue on ActiveMQ 5.9.0 standard edition. I guess
>>> that simply every broker version suffers from this. I really don't think it
>>> is an ActiveMQ problem. It is according to Redhat a Spring JMS problem.
>>> 
>>> No, I never tried to use an embedded broker. Probably because I used
>>> remote brokers when I discovered the problem during Master-Slave failover
>>> tests. I will try to rewrite the test project to use an embedded broker
>>> that can be stopped and started as part of the test.
>>> 
>>> Yes, that's what I meant. That the remote broker increases the
>>> probability to show the issue. Because when the analysis of Redhat was
>>> correct, it is really a timing issue. You can also increase the chance for
>>> the issue if you produce even more messages per second. That increases the
>>> probability that a message falls just into the problematic time slice where

CSV file from SQL no headers?

[jtoepfer]

Env. ActiveMQ v5.9.1, Camel 2.13.1

I am currently generating CSV files from a custom SQL.  This works fine, but
they want the headers to be added to the CSV file.  I've included my route
below, is there currently any way of doing this?


  
  
  
  
building.csv
  
  
  


Thanks in advance for any help.



-
Josh Toepfer
--
View this message in context: 
http://camel.465427.n5.nabble.com/CSV-file-from-SQL-no-headers-tp5777379.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Transaction problem with Camel, ActiveMQ and Spring JMS

[Stephan Burkard]

Oh, our messages overlapped...

Your questions:

"... doing this queue to queue work using one or two ActiveMQ brokers?"
=> One broker

"... you may want to try camel-sims"
=> I guess you mean Camel sJms, that's the closest match I found in the
list of Camel components on GitHub :-) Never heard (ok, it is only since
2.11), but I will have a look at it.

"If you’d be using XA in the real world..."
=> No, we don't use XA


But your hint with "transacted = false" works! I was able to run the
"standard" version 5 times in a row and it was always successful.

Currently it looks like either one has to define the whole Tx stuff and set
transacted = false OR to use the simple config with transacted = true.

At least I learned that I have not real understanding what this flag does.
And I claim that most examples use transacted = true even when they define
Tx manager etc.

Regards
Stephan





On Mon, Feb 8, 2016 at 4:59 PM, Stephan Burkard  wrote:

> Hi Quinn
>
> Here is the new version of my test project that uses an embedded ActiveMQ
> broker. Since the AMQ libs are of version 5.9.0 (standard edition) there is
> no more special Redhat version.
>
> There is a new BrokerManagementExecutor that is configured to stop the
> broker 5 seconds after the test starts. On my machine the broker shutdown
> happens after about 400 messages are sent. Some seconds after the broker is
> stopped, it starts again and the test finishes. I guess the automagical
> broker restart is due to the vm-transport used.
>
> Results on my machine:
>
> 1. The "noTxManager" version still never fails, so it never loses a
> message between the queues. It often misses one or two messages, but always
> on both queues. So these messages could not be sent from the client, but
> all messages that arrived at the first queue also arrive at the second
> queue.
>
> 2. The "standard" version fails on almost every attempt, it mostly loses
> one or two messages between the queues. So these messags arrived at the
> first queue but not on the second one.
>
> Since the embedded broker is stopped at the end of the test, I added an
> additional Camel route that consumes the default DLQ. I added the messages
> arrived at the DLQ in the test summary output. But on my machine I never
> had messages in it.
>
> I hope you can reproduce the problem now more easily.
>
> Regards
> Stephan
>
>
>
>
>
>
> On Sat, Feb 6, 2016 at 10:32 PM, Stephan Burkard 
> wrote:
>
>> Hi Quinn
>>
>> I don't think that you need to match exactly my broker version. I had
>> first discovered this issue on ActiveMQ 5.9.0 standard edition. I guess
>> that simply every broker version suffers from this. I really don't think it
>> is an ActiveMQ problem. It is according to Redhat a Spring JMS problem.
>>
>> No, I never tried to use an embedded broker. Probably because I used
>> remote brokers when I discovered the problem during Master-Slave failover
>> tests. I will try to rewrite the test project to use an embedded broker
>> that can be stopped and started as part of the test.
>>
>> Yes, that's what I meant. That the remote broker increases the
>> probability to show the issue. Because when the analysis of Redhat was
>> correct, it is really a timing issue. You can also increase the chance for
>> the issue if you produce even more messages per second. That increases the
>> probability that a message falls just into the problematic time slice where
>> the consumer has committed but not the producer.
>>
>> Yes, that's right. I start the test and when I see lots of console output
>> I hit enter on the console where the stop command of the broker has waited.
>> Then I wait about 5 to 10 seconds and then I start the broker again. The
>> test reconnects and continues.
>>
>> Regards
>> Stephan
>>
>>
>>
>>
>>
>> On Fri, Feb 5, 2016 at 7:40 PM, Quinn Stevenson <
>> qu...@pronoia-solutions.com> wrote:
>>
>>> Stephan -
>>>
>>> I’ll get a broker running and try to match your version - I think I can
>>> get it from one of my customers whose running Fuse 6.2.
>>>
>>> While I do that - have you considered trying to reproduce this using an
>>> embedded broker that the test could control?  It would make it much easier
>>> to reproduce.
>>>
>>> I don’t think running the broker locally vs remotely should increase any
>>> probably of losing messages - we shouldn’t lose any as long as the
>>> configuration is correct.  It may increase the probably of an issue, but we
>>> shouldn’t lose messages.
>>>
>>> Also, just to confirm - when you’re testing this you are
>>> stopping/starting the broker in the middle of the test, not killing and
>>> restarting the broker - correct?
>>>
>>>
>>> > On Feb 5, 2016, at 12:37 AM, Stephan Burkard 
>>> wrote:
>>> >
>>> > Hi Quinn
>>> >
>>> > I just tested the POM changes you posted and the second run failed
>>> (without
>>> > failover-URL). I then tested with the failover-URL and the third
>>> attempt
>>> > failed.
>>> >
>>> > The latter is no big surprise since I discovered the problem du

Re: Transaction problem with Camel, ActiveMQ and Spring JMS

[Quinn Stevenson]

Thank You Stephan - that really helps.

I ran the project as-is and saw the failure in the “standard” setup on the 
first run - much easier for me ;-)

Then I change transacted to false, and I’ve run it 5-times and it’s succeeded 
(i.e. not lost messages ).

Have you been able to make it drop messages with transacted set to false?

Re: Transaction problem with Camel, ActiveMQ and Spring JMS

[Quinn Stevenson]

Hi Stephan - 

I have a keen interest in this one because my customers rely very heavily on NO 
MESSAGE LOSS - period (they are mostly Healthcare Providers).

I was comparing configurations again, and I came up with one more difference - 
can you try setting transacted=false in the “standard” test?  I ran it that was 
about 6-7 times and didn’t ever lose a message between the queues.  I’m using 
ActiveMQ 5.11.4 and Camel 2.16.2 for this test.

Also, in the real world, would you be doing this queue to queue work using one 
or two ActiveMQ brokers?  If you’d only be using one, you may want to try 
camel-sims - I’ve had pretty good luck with it, but it doesn’t support XA.  

If you’d be using XA in the real world, we should test that scenario as well.  
It feels like the “standard” configuration we’re using is almost and XA config, 
but not quite.  What you’ve call the noTxManager config is using internal JMS 
transactions and it’s working - that’s closer to the camel-jms configuration 
I’d use for a single broker.


> On Feb 6, 2016, at 2:32 PM, Stephan Burkard  wrote:
> 
> Hi Quinn
> 
> I don't think that you need to match exactly my broker version. I had first
> discovered this issue on ActiveMQ 5.9.0 standard edition. I guess that
> simply every broker version suffers from this. I really don't think it is
> an ActiveMQ problem. It is according to Redhat a Spring JMS problem.
> 
> No, I never tried to use an embedded broker. Probably because I used remote
> brokers when I discovered the problem during Master-Slave failover tests. I
> will try to rewrite the test project to use an embedded broker that can be
> stopped and started as part of the test.
> 
> Yes, that's what I meant. That the remote broker increases the probability
> to show the issue. Because when the analysis of Redhat was correct, it is
> really a timing issue. You can also increase the chance for the issue if
> you produce even more messages per second. That increases the probability
> that a message falls just into the problematic time slice where the
> consumer has committed but not the producer.
> 
> Yes, that's right. I start the test and when I see lots of console output I
> hit enter on the console where the stop command of the broker has waited.
> Then I wait about 5 to 10 seconds and then I start the broker again. The
> test reconnects and continues.
> 
> Regards
> Stephan
> 
> 
> 
> 
> 
> On Fri, Feb 5, 2016 at 7:40 PM, Quinn Stevenson  
>> wrote:
> 
>> Stephan -
>> 
>> I’ll get a broker running and try to match your version - I think I can
>> get it from one of my customers whose running Fuse 6.2.
>> 
>> While I do that - have you considered trying to reproduce this using an
>> embedded broker that the test could control?  It would make it much easier
>> to reproduce.
>> 
>> I don’t think running the broker locally vs remotely should increase any
>> probably of losing messages - we shouldn’t lose any as long as the
>> configuration is correct.  It may increase the probably of an issue, but we
>> shouldn’t lose messages.
>> 
>> Also, just to confirm - when you’re testing this you are stopping/starting
>> the broker in the middle of the test, not killing and restarting the broker
>> - correct?
>> 
>> 
>>> On Feb 5, 2016, at 12:37 AM, Stephan Burkard  wrote:
>>> 
>>> Hi Quinn
>>> 
>>> I just tested the POM changes you posted and the second run failed
>> (without
>>> failover-URL). I then tested with the failover-URL and the third attempt
>>> failed.
>>> 
>>> The latter is no big surprise since I discovered the problem during
>>> failover tests in a master-slave-config. I then reduced the setup to a
>>> single broker environment and it was still there.
>>> 
>>> My test broker is apache-activemq-5.11.0.redhat-620133, a patched Redhat
>>> version of AMQ 5.11. As you, I also don't change the AMQ version number
>> in
>>> the POM, I just use a newer broker than the library version. My broker
>> runs
>>> on another machine than the test. Perhaps this increases the probability
>> of
>>> losing a message?
>>> 
>>> Regards
>>> Stephan
>>> 
>>> 
>>> 
>>> 
>>> On Thu, Feb 4, 2016 at 7:06 PM, Quinn Stevenson <
>> qu...@pronoia-solutions.com  
>> >
 wrote:
>>> 
 I tested this with a 5.9.0 broker and I am seeing messages dropped with
 the TxText, but I still have to use the failover URL or the test just
>> stops
 after the broker is restarted.
 
 I don’t have a 5.9.1 broker to test with, so I don’t know if that would
 help, but the next oldest broker I have is 5.10.1, and it seems to be
 working with that broker.
 
 NOTE:  I’m not changing the activemq-version in the POM when I change
>> the
 broker version - I’m just starting a different broker (locally) on the
>> same
 port.
 
 
> On Feb 4, 2016, at 10:41 AM, Quinn Stevenson <
 qu...@pronoia

Re: CamelBlueprintTestSupport No bean could be found in the registry

[Quinn Stevenson]

I’m a little confused here - asService take the object implementing the 
interface and the service property key/values - I’m not sure how that could 
even work as an interface instead of the implementation object.  The service 
interface is provided earlier in the call ( the key in services.put ), and I 
like having the string there as well so I don’t have to add dependencies to my 
project all the time (when I’m using OSGi classes that are provided by the 
framework).

That said, I’m always looking for ways to simplify tests - do you have an idea 
on how this could work?  Maybe you could do a prototype that we could see?


> On Feb 7, 2016, at 6:43 PM, Brad Johnson  wrote:
> 
> According
> to my humble opinion, the asService() method should ideally have Interface
> instead of Implementation argument.
> 
> The asService is there to create a proxy to the actual implementation class
> I believe.  What you are actually putting in the registry is a key of the
> value of the full package and class name of the interface.  That's what
> blueprint is going to look up the service based upon.  The value is what
> you put in as the implementation.
> 
> In a true blueprint environment that implementation will be hidden behind a
> proxy object that exposes the interface.  Any bundle wanting to use that
> proxied implementation then just tells it what the package anc class name
> of the interface are.  In other words, when that interface is fetched from
> the OSGi registry and handed to the requester, the requester doesn't know
> what concrete implementation it is talking to. It may be a test stub, it
> may be the actual implementation.  In fact, if you try to then cast that to
> the concrete implementation of the class it will fail because what it finds
> is a proxy of the interface.  This also makes it possible to hot swap
> bundles at run time because the proxy stays the same but the implementation
> changes.
> 
> I'm still mystified why your test class wasn't picking up the service from
> your first bundle though.  If you have have it exported and referenced and
> listed as a test dependency in your client bundle then it should be
> automatically loaded up.  One of those pieces sounds as if it is missing.
> 
>  @Override
>protected void
> addServicesOnStartup(Map>
> services) {
>services.put( MyServiceInterface.class.getName(), asService(new
> StubServiceImplementation(), "implementation", "stub"));
>}
> 
> 
> On Fri, Feb 5, 2016 at 4:53 PM, enigma  wrote:
> 
>> Thank you and Have a good weekend! :)
>> 
>> 
>> 
>> --
>> View this message in context:
>> http://camel.465427.n5.nabble.com/CamelBlueprintTestSupport-No-bean-could-be-found-in-the-registry-tp5777228p5777317.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>> 

Re: Invalid "Content-Type" Header is configured

[Claus Ibsen]

It depends on what Camel components are used for the http/rest
transport, and what bindings you are using, and if using pojors if
they have annotations and whatnot.

The given example is sparse, so we cannot see how its being used.

I suggest to study the existing rest examples and the rest-dsl documentation.

On Fri, Feb 5, 2016 at 4:42 PM, Matt Sicker  wrote:
> You can specify what content-types are consumed and produced via the rest
> dsl. Perhaps application/json is the default?
>
> On 4 February 2016 at 22:47, sogabe  wrote:
>
>> Hi,
>> I'm testing REST DSL like this.
>>
>> {code}
>> 
>> >type="com.buildria.camel.rest.Book"
>>outType="com.buildria.camel.rest.Book">
>> 
>> 
>> 
>> {/code}
>>
>> and I've invoked the following command.
>>
>> {code}
>> $ curl  'http://localhost:/books/' --include --request POST \
>>  --header 'Accept: application/xml' \
>>  --header 'Content-Type: application/json' \
>>  - -data-binary '{ "id": 100, "title": "Camel", "price": 300 }'
>>
>> HTTP/1.1 200 OK
>> Content-Type: application/json ...
>> (1)
>> Accept: application/xml
>> breadcrumbId: ID-lily-50699-1454646457713-0-8
>> User-Agent: curl/7.41.0
>> Transfer-Encoding: chunked
>> Server: Jetty(9.3.5.v20151012)
>>
>> 
>> 
>> 300
>> Camel
>> 
>> {code}
>>
>> I can get a response as XML, but Content-Type of response (1) is
>> "application/json".
>> It should be "application/xml"?
>>
>> Thanks,
>> --
>> Seiji Sogabe
>>
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://camel.465427.n5.nabble.com/Invalid-Content-Type-Header-is-configured-tp5777250.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>
>
>
> --
> Matt Sicker 



-- 
Claus Ibsen
-
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

Re: issue in coding of blueprint in camel

[Grzegorz Grzybek]

Hello

With camel blueprint you don't use spring-dm and its namespaces. Your
XML describing Camel route should use
http://camel.apache.org/schema/blueprint and
http://www.osgi.org/xmlns/blueprint/v1.0.0 namespaces.

regards
Grzegorz Grzybek

2016-02-08 14:37 GMT+01:00 prateek khanna :
> Hi,
>
> when implementing the bundle in blueprint and deploying in fuse container
> then it is showing "grace period" instead of creating .
> In fuse logs it is showing as
> "Bundle camel-blueprint is waiting for namespace handlers [
> http://www.springframework.org/schema/osgi-compendium,
> http://www.springframework.org/schema/context]";
>
> Request you to please suggest.
>
> Regard,
> Prateek

issue in coding of blueprint in camel

[prateek khanna]

Hi,

when implementing the bundle in blueprint and deploying in fuse container
then it is showing "grace period" instead of creating .
In fuse logs it is showing as
"Bundle camel-blueprint is waiting for namespace handlers [
http://www.springframework.org/schema/osgi-compendium,
http://www.springframework.org/schema/context]";

Request you to please suggest.

Regard,
Prateek

Re: Exposing rest service from camel application using existing http transport

[Claus Ibsen]

You can use the servlet component with the rest-dsl.

There is already a tomcat example.
https://github.com/apache/camel/tree/master/examples/camel-example-swagger-java



On Mon, Feb 8, 2016 at 10:37 AM, gilboy  wrote:
> Hi
>
> I am looking at using the Rest component to define a Rest endpoint. My camel
> application gets packaged as a WAR file which I deploy in to my standalone
> tomcat instance.
>
> I am not sure if I can bind this Rest endpoint to HTTP requests that arrive
> at the HTTP endpoint on my tomcat instance.
>
> In the documentation it looks like I need to use another camel component
> like camel-jetty or camel-servlet to manage the REST transport. However, I
> don't want to do this as I already have a http endpoint available in my
> tomcat instance
>
> Thanks
> Joe
>
>
>
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/Exposing-rest-service-from-camel-application-using-existing-http-transport-tp5777361.html
> Sent from the Camel - Users mailing list archive at Nabble.com.



-- 
Claus Ibsen
-
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

Exposing rest service from camel application using existing http transport

[gilboy]

Hi

I am looking at using the Rest component to define a Rest endpoint. My camel
application gets packaged as a WAR file which I deploy in to my standalone
tomcat instance. 

I am not sure if I can bind this Rest endpoint to HTTP requests that arrive
at the HTTP endpoint on my tomcat instance. 

In the documentation it looks like I need to use another camel component
like camel-jetty or camel-servlet to manage the REST transport. However, I
don't want to do this as I already have a http endpoint available in my
tomcat instance

Thanks
Joe



--
View this message in context: 
http://camel.465427.n5.nabble.com/Exposing-rest-service-from-camel-application-using-existing-http-transport-tp5777361.html
Sent from the Camel - Users mailing list archive at Nabble.com.