Proper way to use velocity formatters like NumberTool
Hi, What's the proper way to use formatters in a camel-velocity template if you are NOT using injection (e.g. spring or guice)? I have seem a few examples including one where an instance of NumberTool is passed through the headers. Seemed very hacky to me, it seems like there must be a cleaner mechanism. --Chris
XMPP 2.15.0 vs. 2.15.1 failing
Hi, Earlier this evening I upgraded my camel project from 2.15.0 to 2.15.1 with no other code changes, and suddenly I was unable to connect to my XMPP server. The error I got was roughly this: "SASLauthentication failed using mechanism DIGEST-MD5:" I did some brief troubleshooting but was not able to solve the problem, so I just dropped back to 2.15.0. Searching various mailing lists I found a number of people complaining of the same problem; a ton of bad/unhelpful advice; and a good amount of skepticism that it's even really a problem. It certainly appears to be one to me. Permissions, keys, etc. dealing with this kind of stuff (including self-signed certificates on openfire servers) has always been pretty ugly in Java anyway. Most of the time I can fix things by adding various trust providers, or screwing around with keytool - but it's pretty hideous. I am following advice from the camel xmpp page and posting this to the mailing list rather than filing a bug. If someone believes this really is a bug let me know and I'll be happy to fill out the ticket. Or, of course, if you have some workaround that will allow this to continue working, that's great too. Despite the fact that it's trying to use digest, it's still inside of an SSL so I'm not overly concerned about it. (I just don't want to spend my life screwing around working around openfire).
Re: XMPP 2.15.0 vs. 2.15.1 failing
No, I haven't, and you're right - I should have. I'm an easily distracted type though and I'm trying to get some ZCL stuff pushed to maven central asap. I use camel for a ton of testing of that kind of thing, and shortly I'll be pushing out an xbee camel component I wrote (and am now testing). Sorry for the lame answer. If nobody knows what's going on here off the top of their heads I'll dig into it in a little bit and report back. On Fri, Apr 3, 2015 at 6:40 AM, Claus Ibsen wrote: > Hi > > Have you looked at the source code changes in camel-xmpp 2.15.0 and > 2.15.1 and also about any JAR upgrades. > The best clue would be in any of those changes. > > On Fri, Apr 3, 2015 at 12:18 PM, Christopher Piggott > wrote: > > Hi, > > > > Earlier this evening I upgraded my camel project from 2.15.0 to 2.15.1 > with > > no other code changes, and suddenly I was unable to connect to my XMPP > > server. The error I got was roughly this: > > > > "SASLauthentication failed using mechanism DIGEST-MD5:" > > > > I did some brief troubleshooting but was not able to solve the problem, > so > > I just dropped back to 2.15.0. > > > > Searching various mailing lists I found a number of people complaining of > > the same problem; a ton of bad/unhelpful advice; and a good amount of > > skepticism that it's even really a problem. It certainly appears to be > one > > to me. Permissions, keys, etc. dealing with this kind of stuff > (including > > self-signed certificates on openfire servers) has always been pretty ugly > > in Java anyway. Most of the time I can fix things by adding various > trust > > providers, or screwing around with keytool - but it's pretty hideous. > > > > I am following advice from the camel xmpp page and posting this to the > > mailing list rather than filing a bug. If someone believes this really > is > > a bug let me know and I'll be happy to fill out the ticket. Or, of > course, > > if you have some workaround that will allow this to continue working, > > that's great too. Despite the fact that it's trying to use digest, it's > > still inside of an SSL so I'm not overly concerned about it. (I just > don't > > want to spend my life screwing around working around openfire). > > > > -- > Claus Ibsen > - > Red Hat, Inc. > Email: cib...@redhat.com > Twitter: davsclaus > Blog: http://davsclaus.com > Author of Camel in Action: http://www.manning.com/ibsen > hawtio: http://hawt.io/ > fabric8: http://fabric8.io/ >
Multiple outputs from a custom component
I have been reading mailing lists and forums trying to figure this out but
haven't really come up with a clean solution.
I have a zigbee ZCL component I wrote for Camel that parses out a few
ZCL/ZDO messages. One of them is an attributes report, which contains a
list of attributes, each with:
- A numeric ID indicating which parameter
- A one-byte type ID which tells you if the value is a float, int, string,
whatever
- A value, which could be of various types
To use these components I do something like this:
from("seda:xbeeInput")
.to("xbee://localhost")
.to("zcl://localhost")
.to("zclSplitter://localhost")
.to(xmppUri);
The first four steps work great - the xbeeInput comes from the serial
port, sends the message to xbee decoding, and if that is successful it
parses it into a ZCL message containing some number of attributes.
The splitter is where I'm really having the problems. I'd really like
it to be just another Endpoint/Component/something in the library so
that the user doesn't have to screw around configuring custom
splitters or beans.
I have tried a number of things to solve this, but I'm getting so far
deep in the weeds that I feel like I'm on the wrong track.
Does anybody have an example they can show me of a custom Producer (or
something more appropriate?) that can act like a cusom splitter,
replacing whatever Exchange comes in with a series of smaller
Exchanges? I'm looking for something like:
public class ZclSplitter exends DefaultProducer {
public List process( Exchange originalExchange ) {
}
}
How is one supposed to accomplish this with a component?
--Chris
@UriPath and @UriSyntax
Hi, According to https://cwiki.apache.org/confluence/display/CAMEL/Camel+2.15.0+Release - Custom components using @UriEndpoint must now include a syntax attribute to document the uri syntax of the endpoint, when using the apt compiler plugin to generate documentation. I'm looking for documentation on this and not really finding how to use it or simple examples: - http://camel.apache.org/endpoint-annotations.html says what it is, but not how to use it - https://github.com/sigrist/camel-rxtx/blob/master/src/main/java/org/apache/camel/rxtx/RxTxEndpoint.java is an example soembody wrote that uses @UriParam ... that works fine, but when I try to add a @UriPath parameter it silently ends up null - Tons of examples in git but most of them don't have a 'syntax=' so I must be looking at old source Trying to piece all this together from scarce examples and documentation: - It doesn't seem like I really need to extend UriComponentConfiguration at all, do I? If I declare my component a @ManagedResource it seems to bind all the @UriParam just fine. It doesn't bind the @UriPath parameters, though, and fails to do so silently, despite the fact that they are marked @Meadata(required = "true"). - Are there any simple examples out there using @UriComponentConfiguration ? --Chris
Re: @UriPath and @UriSyntax
I will try that, thanks.
For a test, I just tried getting back to basics, and getting rid of all the
Uri configuration entirely - just to see what happens. I still have
META-INF/services/org/apache/camel/component/jssc (a text file) which
allows me to do:
from("jssc:com10?baud=19200") ...
and it locates the component just fine. The next thing I did was change
the Component to extend UriEndpointComponent rather than DefaultComponent.
That broke it as follows:
2015-04-07 10:15:41,550 [main] ERROR app.tasks.CamelTask - Failed to start
camel
org.apache.camel.FailedToCreateRouteException: Failed to create route
route1: Route(route1)[[From[jssc:com10?baud=19200]] -> [To[xmpp://cl...
because of Failed to resolve endpoint: jssc://com10?baud=19200 due to:
Cannot auto create component: jssc
So something, by doing that, just broke its ability to locate the endpoint
by name using the entry in META-INF. The stack trace it gives me is not
exceptionally helpful; what it's really telling me is that it can't locate
my component. What's especially confusing is that a UriEndpointComponent
extends DefaultComponent so it seems like, as far as camel is concerned,
they should be the same thing.
I checked in what I have so far ...
https://github.com/wz2b/camel-jssc/tree/master/src/main/java/com/autofrog/camel
On Tue, Apr 7, 2015 at 9:36 AM, Claus Ibsen wrote:
> Hi
>
> Oh if you have this as a component outside Camel, then you need to add
> the apt plugin
> https://github.com/apache/activemq/blob/master/activemq-camel/pom.xml#L63
>
> And this plugin if you want to include a .properties file in the JAR
> with a list of components it contains
> https://github.com/apache/activemq/blob/master/activemq-camel/pom.xml#L217
>
> Then you do the same as all the components in Apache Camel.
>
> On Tue, Apr 7, 2015 at 3:34 PM, Claus Ibsen wrote:
> > Hi
> >
> > All the 150+ components is an example of this. Just pick a similar /
> > simple component and see its source code.
> >
> > On Tue, Apr 7, 2015 at 3:12 PM, Christopher Piggott
> wrote:
> >> Hi,
> >>
> >> According to
> >> https://cwiki.apache.org/confluence/display/CAMEL/Camel+2.15.0+Release
> >>
> >>
> >>- Custom components using @UriEndpoint must now include a syntax
> >>attribute to document the uri syntax of the endpoint, when using the
> apt
> >>compiler plugin to generate documentation.
> >>
> >>
> >> I'm looking for documentation on this and not really finding how to use
> it
> >> or simple examples:
> >>
> >>
> >>- http://camel.apache.org/endpoint-annotations.html says what it
> is,
> >>but not how to use it
> >>-
> >>
> https://github.com/sigrist/camel-rxtx/blob/master/src/main/java/org/apache/camel/rxtx/RxTxEndpoint.java
> >>is an example soembody wrote that uses @UriParam ... that works
> fine, but
> >>when I try to add a @UriPath parameter it silently ends up null
> >>- Tons of examples in git but most of them don't have a 'syntax=' so
> I
> >>must be looking at old source
> >>
> >>
> >> Trying to piece all this together from scarce examples and
> documentation:
> >>
> >>
> >>- It doesn't seem like I really need to extend
> UriComponentConfiguration
> >>at all, do I? If I declare my component a @ManagedResource it seems
> to
> >>bind all the @UriParam just fine. It doesn't bind the @UriPath
> parameters,
> >>though, and fails to do so silently, despite the fact that they are
> marked
> >>@Meadata(required = "true").
> >>- Are there any simple examples out there using
> >>@UriComponentConfiguration ?
> >>
> >>
> >> --Chris
> >
> >
> >
> > --
> > Claus Ibsen
> > -
> > Red Hat, Inc.
> > Email: cib...@redhat.com
> > Twitter: davsclaus
> > Blog: http://davsclaus.com
> > Author of Camel in Action: http://www.manning.com/ibsen
> > hawtio: http://hawt.io/
> > fabric8: http://fabric8.io/
>
>
>
> --
> Claus Ibsen
> -
> Red Hat, Inc.
> Email: cib...@redhat.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
> hawtio: http://hawt.io/
> fabric8: http://fabric8.io/
>
Re: @UriPath and @UriSyntax
OK that hellped. What I ended up doing was:
* Component extends UriEndpointComponent
* Endpoint extends DefaultEndpoint and is marked @ManagedResource and
@UriEndpoint. It also has a @UriParam for 'baud' and another one for
'path' -- that last one is a problem (will explain in a second)
* Consumer extends DefaultConsumer and uses a processor to launch events
The endpoint is marked like this:
@UriEndpoint(scheme = "jssc",
syntax = "jssc:path",
consumerClass = JsscConsumer.class,
title = "JSSC Component")
I would like to be able to do this:
from("jssc:com10?baud=19200")
but THIS still does not work:
@UriPath
@Metadata(required="true")
private String path
so I end up having to do this:
from("jssc:com10?path=com10&baud=19200")
What is wrong with specifying it as a path parameter whose name
matches the 'syntax' in the @UriEndpoint annotation - shouldn't that
work?
*https://github.com/wz2b/camel-jssc/blob/master/src/main/java/com/autofrog/camel/JsscEndpoint.java
<https://github.com/wz2b/camel-jssc/blob/master/src/main/java/com/autofrog/camel/JsscEndpoint.java>*
--Chris
On Tue, Apr 7, 2015 at 10:59 AM, Claus Ibsen wrote:
> A component must have a default no-arg constructor.
>
> So add that, and call super(JsscEndpoint.class) and remove the other
> constructors as they are not really needed.
>
> On Tue, Apr 7, 2015 at 4:55 PM, Christopher Piggott
> wrote:
> > I will try that, thanks.
> >
> > For a test, I just tried getting back to basics, and getting rid of all
> the
> > Uri configuration entirely - just to see what happens. I still have
> > META-INF/services/org/apache/camel/component/jssc (a text file) which
> > allows me to do:
> >
> > from("jssc:com10?baud=19200") ...
> >
> > and it locates the component just fine. The next thing I did was change
> > the Component to extend UriEndpointComponent rather than
> DefaultComponent.
> > That broke it as follows:
> >
> > 2015-04-07 10:15:41,550 [main] ERROR app.tasks.CamelTask - Failed to
> start
> > camel
> > org.apache.camel.FailedToCreateRouteException: Failed to create route
> > route1: Route(route1)[[From[jssc:com10?baud=19200]] -> [To[xmpp://cl...
> > because of Failed to resolve endpoint: jssc://com10?baud=19200 due to:
> > Cannot auto create component: jssc
> >
> > So something, by doing that, just broke its ability to locate the
> endpoint
> > by name using the entry in META-INF. The stack trace it gives me is not
> > exceptionally helpful; what it's really telling me is that it can't
> locate
> > my component. What's especially confusing is that a UriEndpointComponent
> > extends DefaultComponent so it seems like, as far as camel is concerned,
> > they should be the same thing.
> >
> >
> > I checked in what I have so far ...
> >
> >
> https://github.com/wz2b/camel-jssc/tree/master/src/main/java/com/autofrog/camel
> >
> >
> >
> >
> > On Tue, Apr 7, 2015 at 9:36 AM, Claus Ibsen
> wrote:
> >
> >> Hi
> >>
> >> Oh if you have this as a component outside Camel, then you need to add
> >> the apt plugin
> >>
> https://github.com/apache/activemq/blob/master/activemq-camel/pom.xml#L63
> >>
> >> And this plugin if you want to include a .properties file in the JAR
> >> with a list of components it contains
> >>
> https://github.com/apache/activemq/blob/master/activemq-camel/pom.xml#L217
> >>
> >> Then you do the same as all the components in Apache Camel.
> >>
> >> On Tue, Apr 7, 2015 at 3:34 PM, Claus Ibsen
> wrote:
> >> > Hi
> >> >
> >> > All the 150+ components is an example of this. Just pick a similar /
> >> > simple component and see its source code.
> >> >
> >> > On Tue, Apr 7, 2015 at 3:12 PM, Christopher Piggott <
> cpigg...@gmail.com>
> >> wrote:
> >> >> Hi,
> >> >>
> >> >> According to
> >> >>
> https://cwiki.apache.org/confluence/display/CAMEL/Camel+2.15.0+Release
> >> >>
> >> >>
> >> >>- Custom components using @UriEndpoint must now include a syntax
> >> >>attribute to document the uri syntax of the endpoint, when using
> the
> >> apt
> >> >>compiler plugin to generate documentation.
> >> >>
> >> >>
> >> >> I'm looking for documentation on thi
Event driven producer?
Does the idea of an 'event driven producer' make sense? One that receives messages/exchange but doesn't necessarily produce one for every input? My input comes in as bytes that need to be assembled. A DefaultProducer seems t have a process() which produces messages 1;1 which is not what I need. I need to programmatically determine whether or not to emit an exchange, or do nothing (i.e. buffer it for a while until I have something to output).
