And the import
+import com.sun.xml.bind.marshaller.NamespacePrefixMapper;
is in camel-jaxb, not camel-core...
Best,
Christian
On Fri, May 11, 2012 at 5:57 AM, Claus Ibsen wrote:
> Morning guys
>
> Christian I noticed that you import a com.sun package.
> +import com.sun.xml.bind.marshaller.Names
Good morning Claus!
I had the same thoughts, but because this class comes from
jaxb-impl-2.1.13, I assume it will not be a problem with an IBM JDK. I use
the Apple JDK (Java version: 1.6.0_31, vendor: Apple Inc.) and it works
well.
NamespacePrefixMapper is an abstract class which doesn't implemen
Morning guys
Christian I noticed that you import a com.sun package.
+import com.sun.xml.bind.marshaller.NamespacePrefixMapper;
Will this not be problems for people using IBM JVMs etc?
I would normally discourage against using com.sun packages, especially
in camel-core.
Maybe there is an interfac
On 5/10/12 11:40 PM, Daniel Kulp wrote:
We discussed a while ago how the Camel CXF component's modes don't really
"match" what CXF can provide. It currently has two modes:
1) Message mode - it provides the full message kind of as a stream.
However, it specifically DISABLES much of the CXF pro
2012/5/10 Daniel Kulp :
>
> We discussed a while ago how the Camel CXF component's modes don't really
> "match" what CXF can provide. It currently has two modes:
>
> 1) Message mode - it provides the full message kind of as a stream.
> However, it specifically DISABLES much of the CXF processing
On Thursday, May 10, 2012 10:33:50 PM Christian Müller wrote:
> The first Java 7 build which passed!!!
>
> Many thanks to Dan, Claus and all other who worked on this.
I wouldn't say it passed. Half the modules are skipped. :-(
There seems to be an issue with Camels build and the Maven paralle
The first Java 7 build which passed!!!
Many thanks to Dan, Claus and all other who worked on this.
Best,
Christian
On Thu, May 10, 2012 at 9:33 PM, Apache Jenkins Server <
jenk...@builds.apache.org> wrote:
> The Apache Jenkins build system has built Camel.trunk.fulltest.java7
> (build #86)
>
>
On Thursday, May 10, 2012 07:42:28 PM Babak Vahdat wrote:
> Am 10.05.12 16:41 schrieb "Claus Ibsen" unter :
> >On Thu, May 10, 2012 at 4:27 PM, Daniel Kulp wrote:
> >> Not sure about this commit
> >>
> >> This commit would make this area of the code NOT work at all with CXF
> >>2.5.x
> >> and
We don't make claims from a Camel side.
CXF makes the claims on that, if we can adhere to a range, we certainly
I think should do so in an integration framework.
Deciding what others could / should do when there is opportunity for choice
tends
to be the wrong way in my humble opinion.
/je
On M
Am 10.05.12 16:41 schrieb "Claus Ibsen" unter :
>On Thu, May 10, 2012 at 4:27 PM, Daniel Kulp wrote:
>>
>> Not sure about this commit
>>
>> This commit would make this area of the code NOT work at all with CXF
>>2.5.x
>> and older. I'm personally OK with that since 2.10 is primarily tested
We discussed a while ago how the Camel CXF component's modes don't really
"match" what CXF can provide. It currently has two modes:
1) Message mode - it provides the full message kind of as a stream.
However, it specifically DISABLES much of the CXF processing of the message.
2) Payload -
Hi
Welcome to the Camel community.
Next time use the @user mailing list for questions on using Camel.
Thats where the most people hang out.
See this FAQ about dynamic endpoint
http://camel.apache.org/how-do-i-use-dynamic-uri-in-to.html
On Thu, May 10, 2012 at 4:05 PM, karpaczio wrote:
> Hi
>
Hi
I have a route, that regularly fetches data from an uri.
from("quartz://camelLogTimer?trigger.repeatInterval=10s&stateful=true").
to(endpointUri).
unmarshal().
... // here I can find out what is new endpointUri
It appeared that original endpointUri may change and I'll rece
On Thu, May 10, 2012 at 4:27 PM, Daniel Kulp wrote:
>
> Not sure about this commit
>
> This commit would make this area of the code NOT work at all with CXF 2.5.x
> and older. I'm personally OK with that since 2.10 is primarily tested with
> 2.6, but I'm not sure if that's the ideal situation
Not sure about this commit
This commit would make this area of the code NOT work at all with CXF 2.5.x
and older. I'm personally OK with that since 2.10 is primarily tested with
2.6, but I'm not sure if that's the ideal situation. If it is, then the
OSGi import ranges for CXF need updat
15 matches
Mail list logo
