I'm new in developing XML over http based services using Apache Camel.
is there any example from where i can kick start ?
Regards,
Nitesh
--
View this message in context:
http://camel.465427.n5.nabble.com/How-to-write-a-cxf-service-that-uses-plain-xml-over-http-tp5776963.html
Sent from the Cam
Yep. What Claus proposes sounds sensible.
– Raúl.
On Thu, Jan 28, 2016 at 6:13 PM, Claus Ibsen wrote:
> On Thu, Jan 28, 2016 at 3:48 PM, James Carman
> wrote:
> > I would rather us bump the major version number if we're going to start
> > requiring users to use Java8.
> >
>
> Yeah that was als
2.16 -> 2.17 is not a patch release, it’s a minor release with new features and
dependency updates and such.
2.16.1 -> 2.16.2 is a patch release.
I would agree no changes in JDK requirements on a patch release. A minor
release is different.
Dan
> On Jan 28, 2016, at 5:52 PM, Christian
I'm with James (even we did it otherwise in the past). A patch release
shouldn't require you to upgrade your JRE.
Camel 2.17 = Java 1.7
Camel 3.0 = Java 1.8
May it forces us to work on Camel 3.0 ;-)
Best,
Christian
-
Software Integration Specialist
Apache Member
V.P. Apache Cam
Send a mail to users-subscr...@camel.apache.org or
dev-subscr...@camel.apache.org as described here:
http://camel.apache.org/mailing-lists.html
Best,
Christian
-
Software Integration Specialist
Apache Member
V.P. Apache Camel | Apache Camel PMC Member | Apache Camel committer
Apa
Either way, make it obvious. I don't care if we stick with semver or not,
but a patch release shouldn't require you to upgrade your JRE. That's not
cool
On Thu, Jan 28, 2016 at 1:14 PM Claus Ibsen wrote:
> On Thu, Jan 28, 2016 at 3:48 PM, James Carman
> wrote:
> > I would rather us bump the maj
That makes a lot of sense. I like the version number alliteration.
On 28 January 2016 at 12:17, Johan Edstrom wrote:
> That sounds rather reasonable.
>
>
> > On Jan 28, 2016, at 11:13 AM, Claus Ibsen wrote:
> >
> > On Thu, Jan 28, 2016 at 3:48 PM, James Carman
> > wrote:
> >> I would rather us
That sounds rather reasonable.
> On Jan 28, 2016, at 11:13 AM, Claus Ibsen wrote:
>
> On Thu, Jan 28, 2016 at 3:48 PM, James Carman
> wrote:
>> I would rather us bump the major version number if we're going to start
>> requiring users to use Java8.
>>
>
> Yeah that was also my first thought.
On Thu, Jan 28, 2016 at 3:48 PM, James Carman
wrote:
> I would rather us bump the major version number if we're going to start
> requiring users to use Java8.
>
Yeah that was also my first thought.
I would like to keep Camel 2.17 as-is on Java 1.7. Then if 2.18 is
Java 1.8+ then its much easier
Github user astefanutti closed the pull request at:
https://github.com/apache/camel/pull/816
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is
GitHub user astefanutti opened a pull request:
https://github.com/apache/camel/pull/816
ZooKeeper and Yammer components Asciidoc migration
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/astefanutti/camel asciidoc
Alternatively
Github user astefanutti closed the pull request at:
https://github.com/apache/camel/pull/815
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is
Wasn't there a camel update from 1.6 to 1.7 in the 2.x series?
On 28 January 2016 at 10:12, Daniel Kulp wrote:
>
> > On Jan 28, 2016, at 11:02 AM, Raul Kripalani wrote:
> >
> >
> >> Major version X (X.y.z | X > 0) MUST be incremented if any backwards
> > incompatible changes are introduced to t
Github user brreitme closed the pull request at:
https://github.com/apache/camel/pull/812
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is ena
GitHub user astefanutti opened a pull request:
https://github.com/apache/camel/pull/815
Camel CDI DeltaSpike properties example
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/astefanutti/camel cdi-examples
Alternatively you can
> On Jan 28, 2016, at 11:02 AM, Raul Kripalani wrote:
>
>
>> Major version X (X.y.z | X > 0) MUST be incremented if any backwards
> incompatible changes are introduced to the public API.
>
> http://semver.org/#spec-item-8
>
> If it did, there is no question that we must bump up to 3.0.0. But
On Thu, Jan 28, 2016 at 3:55 PM, Johan Edstrom wrote:
> If we start using say Lambdas, then you are SOL on Java 7.
>
> Right?
>
What I'm saying is that us moving to JDK8 doesn't/shouldn't break any
aspect of the public API we (Camel) expose to our consumers:
> Major version X (X.y.z | X > 0) MU
If we compile to Java8, it won't be usable in a Java7 JVM.
On Thu, Jan 28, 2016 at 10:39 AM Raul Kripalani wrote:
> Good point, James. But after spending over 6 years in 2.x, I think users
> might expect a little more from 3.x than just a standard 2.x release + JDK
> upgrade. So from the public
If we start using say Lambdas, then you are SOL on Java 7.
Right?
> On Jan 28, 2016, at 8:54 AM, Raul Kripalani wrote:
>
> On Thu, Jan 28, 2016 at 3:49 PM, Johan Edstrom wrote:
>
>> Well - that doesn’t hold true for Java8 language features, does it?
>>
>
> Which part, Johan?
>
> *Raúl Kri
On Thu, Jan 28, 2016 at 3:49 PM, Johan Edstrom wrote:
> Well - that doesn’t hold true for Java8 language features, does it?
>
Which part, Johan?
*Raúl Kripalani*
PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
Messaging Engineer
http://about.me/raulkripalani | http://w
Well - that doesn’t hold true for Java8 language features, does it?
> On Jan 28, 2016, at 8:39 AM, Raul Kripalani wrote:
>
> Good point, James. But after spending over 6 years in 2.x, I think users
> might expect a little more from 3.x than just a standard 2.x release + JDK
> upgrade. So from t
Good point, James. But after spending over 6 years in 2.x, I think users
might expect a little more from 3.x than just a standard 2.x release + JDK
upgrade. So from the public view standpoint, I'm not so sure.
Also, JDK8 is backwards compatible with JDK7, so according to Semver a
major version inc
Hi
Thanks Dan. I added a style to the css so all the profile logos is set
to be 64x64.
The website looks okay now. You may need to delete browser cache or
whatever - If you open the page in private browser mode it looks okay
now.
So we are all equal size now - that is how we ride at ASF.
On Th
Probably should just update the CSS to stick a sytle/size on the img to make
it consistent for everyone.
You should just need to checkout:
https://svn-master.apache.org/repos/infra/websites/production/camel/content/styles
and update the site.css. Once you commit, it should be “live” in
I think it's time to start the switch, because many of our clients, libs etc.
are already on Java8.
I don't think it will be easy to have a stable codebase immediately.
--
Andrea Cosentino
--
Apache Camel PMC Member
Apache Karaf Committer
Email: ancosen1...@yaho
I would rather us bump the major version number if we're going to start
requiring users to use Java8.
On Thu, Jan 28, 2016 at 9:35 AM Daniel Kulp wrote:
>
> For master (targeting 2.17), I see we’re still setup for Java7.Would
> it make sense to move to requiring Java8? We can certainly star
We would need to upgrade Camel 2.17 to work with, at least, Karaf 3.x. The
first version supporting JDK8. Ideally, we should upgrade to Karaf 4.0.0.
In fact, I think it already works with Karaf 4.0.0, but we need to state it
officially.
https://camel.apache.org/karaf.html
As long as there are JD
+1
So much goodness of lambdas and methodrefs which will make things a lot
smoother and you have a very good point about thirdparties. And even with 9
being a bit set back it's still in reach so moving to 8 seems sensible
28. jan. 2016 15:35 skrev "Daniel Kulp" :
>
> For master (targeting 2.17),
For master (targeting 2.17), I see we’re still setup for Java7.Would it
make sense to move to requiring Java8? We can certainly start taking advantage
of the new things in Java8, but there are also dependencies (like Jetty) that
now require Java8 and more and more of them will be requiring
On Thu, Jan 28, 2016 at 2:20 PM, David Karlsen
wrote:
> Just a fyi. I think archaius is gone in Hystrix 1.5 (configuration is an
> interface with default imp with archaius). There is a RC out of Hystrix 1.5
>
Cool, thanks for the heads-up, David!
*Raúl Kripalani*
PMC & Committer @ Apache Ignite
Just a fyi. I think archaius is gone in Hystrix 1.5 (configuration is an
interface with default imp with archaius). There is a RC out of Hystrix 1.5
28. jan. 2016 15:12 skrev "Raul Kripalani" :
> Hey Bilgin,
>
> I agree with you. My implementation started as a experiment, to be honest.
>
> My visi
LOL. No worries, Claus! And thanks for informing.
When I saw your massive pic yesterday on the frontpage I thought: "well,
that's an embarrassing CSS styling #fail". It didn't even cross my mind it
might have been intentional. So, easy, I think you have a pretty good
standing in the community!
Th
Hey Bilgin,
I agree with you. My implementation started as a experiment, to be honest.
My vision was deep and fluent integration between Camel and Hystrix, that's
why I started experimenting with a fluent DSL. To me, Hystrix is not just
an external thing to integrate in Camel, but it should play
Hi Raul,
More or less the same time you published the first email about
camel-hystrix component, I also created camel-hystrix component [1]
(it is not finished yet!). But I took the typical (boring ;-))
approach where the hystix support can be used as a regular component
through URI configuration.
Hi
You may have noticed that my bio photo on the Camel website is too big
http://camel.apache.org/
A while back I updated my wiki profile details, as there is a "add
photo" button and it has a wizard that allows you to upload a photo. I
selected a mugshot I have been used elsewhere without any is
Github user asfgit closed the pull request at:
https://github.com/apache/camel/pull/814
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabl
GitHub user tdiesler opened a pull request:
https://github.com/apache/camel/pull/814
[CAMEL-9545] Dozer classloading may fail with spring based context
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/tdiesler/camel CAMEL-9545
Al
Github user asfgit closed the pull request at:
https://github.com/apache/camel/pull/813
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabl
Github user asfgit closed the pull request at:
https://github.com/apache/camel/pull/787
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabl
39 matches
Mail list logo
