zzoli wrote:
>
> > My only motivation was to keep the dependencies up to date
> >
> > ---
> > Luca Burgazzoli
> >
> >
> > On Tue, Aug 2, 2016 at 5:50 PM, James Carman >
> > wrote:
> > > If it's only for test, what's the motivation?
If it's only for test, what's the motivation? Is anything broken? Does
anything code directly to the API?
On Tue, Aug 2, 2016 at 11:21 AM Matt Sicker wrote:
> You can use YAML instead of XML or properties files for a nice config
> format. Plus, there's a few log4j 1->2 tools out there already:
I see no reason to change the logging implementation for tests. If it
ain't broke, don't fix it.
On Tue, Aug 2, 2016 at 9:00 AM James Carman
wrote:
> +1, I'd rather use some form of a facade (homegrown, slf4j, etc.)
>
> On Tue, Aug 2, 2016 at 8:55 AM Vitalii Tymchyshyn
+1, I'd rather use some form of a facade (homegrown, slf4j, etc.)
On Tue, Aug 2, 2016 at 8:55 AM Vitalii Tymchyshyn wrote:
> Well, best practice is to use a logging facade like slf4j and not some
> logging implementation, like logback or log4j.
>
> P.S. I will be grateful if someone tell me if t
want to dispatch your reply messages to different
> endpoints without selectory?
>
> -Original Message-
> From: James Carman [mailto:ja...@carmanconsulting.com]
> Sent: Mittwoch, 13. Juli 2016 13:11
> To: dev@camel.apache.org
> Subject: Re: [DISCUSS] Reusing Exclusive ReplyTo
gt; wrong here?
>
> -Original Message-
> From: James Carman [mailto:ja...@carmanconsulting.com]
> Sent: Dienstag, 12. Juli 2016 15:47
> To: dev@camel.apache.org
> Subject: Re: [DISCUSS] Reusing Exclusive ReplyTo Queue..
>
> I am not talking about using a Shared reply queue. I'm
't tried that out myself, though.
>
> Best regards
> Stephan
>
> -Original Message-
> From: James Carman [mailto:ja...@carmanconsulting.com]
> Sent: Montag, 11. Juli 2016 16:29
> To: dev@camel.apache.org
> Subject: [DISCUSS] Reusing Exclusive ReplyTo Queue..
>
Right now, you must have a unique reply to queue for each destination.
Would there be any impact of allowing folks to use a single reply to queue
for all destinations? For example, suppose I want to use an "Exclusive"
reply to queue per node within my cluster, but I want all replies (for all
route
t; >>>
> >>>
> >>>
> >>>> On Jan 28, 2016, at 5:52 PM, Christian Müller <
> >>> christian.muel...@gmail.com> wrote:
> >>>>
> >>>> I'm with James (even we did it otherwise in the past). A patch release
> >
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:
> >
rom the public view standpoint, I'm not so sure.
>
> Also, JDK8 is backwards compatible with JDK7, so according to Semver a
> major version increment is not necessary.
> On 28 Jan 2016 14:48, "James Carman" wrote:
>
> > I would rather us bump the major version
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 should fix the last section on this page:
http://camel.apache.org/contributing.html
It mentions activemq-developers. Where do we make such updates?
quot;fixed", since it did exactly as it was asked to do, though.
On Mon, Feb 17, 2014 at 8:17 AM, Babak Vahdat
wrote:
> You're right and sorry for the confusion. I don't know why, but somehow my
> brain treated 2.7.10 as 2.9.10!
>
> So I change my vote here to +1.
>
>
I forgot to add, there haven't been any 2.9.x (nor 2.8.x) releases for
CXF yet, so we're not disallowing anything, except 3.0.x (only a
milestone release thus far), which we wanted to keep out anyway.
On Mon, Feb 17, 2014 at 7:52 AM, James Carman
wrote:
> When I open up the META-IN
How does the range from 2.6 (inclusive) to 2.9 (not inclusive) not
include 2.7.10?
On Mon, Feb 17, 2014 at 5:06 AM, Babak Vahdat
wrote:
> Hi Willem,
>
> can you please elaborate your explanation a bit? Currently what we've on the
> 2.12.x. as well as 2.11.x branches is this:
>
> 2.7.10
>
repo would be still there, that's:
> For the non-OSGi folks who make use of camel-cxf Camel component, we would
> put CXF 2.7.10 for them into the classpath but for the OSGi folks who use
> the camel-cxf Karaf feature, we would NOT allow them to make use of CXF
> 2.7.10!
>
> B
Why not just mark the issue as not fixed and release? Is the issue a
show-stopper?
On Sunday, February 16, 2014, Babak Vahdat
wrote:
> -1
>
> See
>
> http://camel.465427.n5.nabble.com/VOTE-Release-Apache-Camel-2-12-3-tp5747361p5747375.html
>
> Babak
>
>
> hadrian wrote
> > This is a vote to rel
I'm +1
On Mon, Feb 10, 2014 at 12:08 PM, Daniel Kulp wrote:
>
> I'm +1 to this.
>
> The OTHER big problem with the current JMX stats is that they are poorly
> implemented as a gigantic synchronized block which then has a bunch of
> internal synchronized blocks. In some of the load testing I'v
Agreed.
On Fri, Dec 27, 2013 at 8:40 AM, Daniel Kulp wrote:
>
>
> I’m really against committing this.
>
> It involves flipping from Random to SecureRandom for a bunch of places that
> do not require or need the security aspects of SecrureRandom. Randomly
> selecting the next server for load b
Agreed. I'm also -1 on this commit.
On Thu, Nov 28, 2013 at 8:32 AM, Daniel Kulp wrote:
>
> I’m -1 to this commit. I don’t think we should be adding a bunch of targets
> for all the various container/platform integrations. This starts going down
> the road of adding targets for karaf, glass
Furthermore, let me add that I agree with Dan Kulp's assessment and
his reasons are not political. They are technical.
On Mon, Dec 2, 2013 at 11:23 AM, James Carman
wrote:
> Agreed. I'm also -1 on this commit.
>
> On Thu, Nov 28, 2013 at 8:32 AM, Daniel Kulp wrote:
>>
+1
On Thu, Nov 28, 2013 at 9:08 PM, Hadrian Zbarcea wrote:
> The camel:dot goal provided by the camel-maven-plugin has not been
> maintained in 5+ years, produces poor quality output and, most importantly,
> doesn't seem to be used. I propose to remove it.
>
> Hadrian
>
>
There are quite a few broken tests. Jetty seems to be hosed. JPA has a
failed test. CDI has issues. It looks like JMS and FTP even decided to
join the party. This has been going on for a while now. This particular
job hasn't been "green" since 9/29. Should we stop working other issues
and ge
While mocking the HazelcastInstance objects in the test cases, I ran
into an interesting problem. The HazelcastInstanceConsumerTest was
@Ignored, stating that it messed up subsequent tests. Now that I'm
not using "live" HazelcastInstances, there is no reason to @Ignore
them anymore. However, whe
ttp://git-wip-us.apache.org/repos/asf/camel/diff/743eb4ad
> >
> > Branch: refs/heads/master
> > Commit: 743eb4ad0c5a5d4f84e75caa1852ee2fb51f4b3a
> > Parents: 3e2dedf
> > Author: James Carman (mailto:
>
gt; Apache Camel committer: https://camel.apache.org/team
> > V.P. Apache Camel: https://www.apache.org/foundation/
> > Apache Member: https://www.apache.org/foundation/members.html
> >
> > https://www.linkedin.com/pub/christian-mueller/11/551/642
> >
> >
> &g
Team,
I was looking at Sonar and one particular rule violation stands out
(at least to me):
https://analysis.apache.org/drilldown/issues/37401?&rule=findbugs%3AIS2_INCONSISTENT_SYNC&rule_sev=CRITICAL&severity=CRITICAL
There are quite a few places within Camel where we inconsistently
access varia
din.com/pub/christian-mueller/11/551/642
>
>
> On Fri, Oct 4, 2013 at 9:07 PM, James Carman
> wrote:
>
>> Agreed, Christian. There are more references to Mockito in the
>> codebase than there are EasyMock. Given that trend, I'm thinking I'll
>> write up
ste Onofré wrote:
>
>> Thanks to you !
>>
>> I will take a look to "replace" Easymock by Mockito in other tests.
>>
>> Regards
>> JB
>>
>>
>> On 10/04/2013 03:52 PM, James Carman wrote:
>>
>>> JIRA created:
>>>
>
JIRA created:
https://issues.apache.org/jira/browse/CAMEL-6826
I'll work on a patch this evening and attach it. Thanks for the input, JB!
On Fri, Oct 4, 2013 at 9:47 AM, Jean-Baptiste Onofré wrote:
> Fair enough, yes.
>
> Regards
> JB
>
>
> On 10/04/2013 03
By the way, I just did a quick search and mockito is found all over
the place in the codebase, so I would guess it's okay.
On Fri, Oct 4, 2013 at 9:41 AM, James Carman wrote:
> I agree that we should try to standardize, but it is only a
> test-scoped dependency, so it's not l
I agree that we should try to standardize, but it is only a
test-scoped dependency, so it's not like you'll put a burden on user
code. Do we really think that in order for one component to use
Mockito that we have to change everyone else? If it's not that
pervasive, it's not a big deal, but could
James
On Fri, Oct 4, 2013 at 9:22 AM, Jean-Baptiste Onofré wrote:
> Hi James,
>
> it sounds good to me. I would advice Easymock.
>
> Regards
> JB
>
>
> On 10/04/2013 03:06 PM, James Carman wrote:
>>
>> As opposed to using a real HazelcastInstance, I would like t
As opposed to using a real HazelcastInstance, I would like to change
the tests to use mock objects (using Mockito or something). There is
no real reason to use a live, running Hazelcast instance in a unit
test and it makes the unit tests very slow. Perhaps having a couple
of tests that test the i
I've submitted a patch for:
https://issues.apache.org/jira/browse/CAMEL-6771
which should solve the problem.
Thanks,
James
I have submitted a patch for:
https://issues.apache.org/jira/browse/CAMEL-6792
Please let me know if that will work.
Thanks,
James
All,
I have attached a patch to:
https://issues.apache.org/jira/browse/CAMEL-4015
Let me know if that'll do.
Thanks,
James
+1 (non-binding)
On Thursday, September 19, 2013, Christian Müller wrote:
> After 9 days of development, we have a new bug fix release candidate
> apache-camel-2.12.1 ready.
> It comes with 47 issues resolved: new features, improvements and bug fixes
> [1]. You can find the release notes here [2]
+1 (non-binding)
On Sun, Sep 15, 2013 at 5:25 PM, Christian Müller
wrote:
> After 2 month of development, we have a new bug fix release candidate
> apache-camel-2.10.7 ready.
> It comes with 63 issues resolved: new features, improvements and bug fixes
> [1].
> You can find the release notes here
With the "bom" approach, you don't use properties to define the
versions (you can but it seems unnecessary IMHO). All of the
dependency versions are defined in the parent pom in the
section, as normal dependencies.
On Wed, Aug 21, 2013 at 9:55 AM, Jon Anstey wrote:
> When using import scope tho
Is all of this really solving some big problem? I really don't see a
huge benefit here.
On Wed, Aug 21, 2013 at 9:27 AM, Jon Anstey wrote:
> I like the idea of having a pom just for versions. We could use Babak's
> proposal but instead of introducing another level of inheritance, just make
> one
So, the goal here is to be able to provide a list of version numbers
that change much easier for any release?
On Sat, Aug 17, 2013 at 3:09 AM, Claus Ibsen wrote:
> On Sat, Aug 17, 2013 at 12:01 AM, Christian Müller
> wrote:
>> What do you propose the "list of all the camel components and some ot
Isn't this whole situation similar to the Apache Web Server project and their
plugins? How do they do it?
On Feb 20, 2013, at 9:16 AM, Christian Schneider
wrote:
> Am 20.02.2013 14:26, schrieb Raul Kripalani:
>> I'm thinking about the organisation strategy here. Below is a list of a few
>>
I'm interested in this too! I'm here to help.
On Feb 19, 2013, at 3:44 PM, Christian Müller
wrote:
> Hadrian,
>
> did you found time to work on the new Camel components test kit?
> Should we plan a coding session in Portland?
>
> Best,
> Christian
>
> On Tue, Feb 19, 2013 at 8:34 PM, Hadria
A veto must be accompanied by a justification in order for it to stand:
http://www.apache.org/foundation/voting.html
On Feb 19, 2013, at 1:13 PM, Claus Ibsen wrote:
> I am -1 on this.
>
> On Tue, Feb 19, 2013 at 8:16 AM, Henryk Konsek wrote:
>> Hi,
>>
>> Unfortunately I won't be able to join
nce WIKI.
>
> Best,
> Christian
>
> On Sat, Feb 2, 2013 at 4:27 PM, James Carman
> wrote:
>
>> You guys don't maintain the original files somewhere in SVN? I've been on
>> projects where they stored the Gimp files in SVN. Thus we could
>> re-generate/t
e (
>> http://camel.apache.org/images/apache-camel-100h.png) is too small. Google
>> Plus needs a picture of 250x250 pixels.
>>
>> Remark : You can have a look in the images directory of camel and you will
>> find great old logo (LogicBlaze, ...) ;-)
>>
>>
2013, at 9:09 AM, James Carman wrote:
> A picture of a camel with a red hat on with the words "Apache Camel."
> Really?
>
> On Feb 1, 2013, at 8:59 AM, Charles Moulliard wrote:
>
>> Hi,
>>
>> For our supporters/fans and people who belong in Apache
Please don't use this Google Plus community for project-related discussions
(design discussions, etc.), though. That needs to be on the mailing lists in
order to keep the community in-the-loop.
On Feb 1, 2013, at 8:59 AM, Charles Moulliard wrote:
> Hi,
>
> For our supporters/fans and peopl
You'll need to include camel-ftp in your classpath.
On Thu, Nov 22, 2012 at 9:03 AM, tamil13 wrote:
> Hi. I need to make one project which include transfer file from ftp to local
> directory . I tried following code
>
> public static void main(String[] args) throws Exception{
>
I'm +1 for this feature and wouldn't mind helping out. We've done
something very similar to this at work and would very much like for it
to be "baked in" already for us.
On Wed, Oct 24, 2012 at 9:50 AM, Claus Ibsen wrote:
> On Wed, Oct 24, 2012 at 8:46 AM, Bengt Rodehav wrote:
>> I think this
Has there been a release of the software before? If so, and you are
changing the maven coordinates, then you could run into class path
collisions
Sent from my iPhone
On Oct 4, 2012, at 3:39 PM, Henryk Konsek wrote:
>>> +1 to use the groupId org.apache-extras.camel-extra
>>> +1 to use the packag
There is some discussion about this, though. We aren't sure if it's
the "hosting" or the "management" of the code that is the sticking
point. The hosting is definitely out, but merely using an external
source control system and all the other infrastructure/management
services here at the ASF migh
Agreed (as I pointed out on the JIRA).
On Tue, Sep 25, 2012 at 11:43 AM, Daniel Kulp wrote:
>
> I would personally just suggest Camel extras and be done with it. If there
> is any question or concerns about the license issue, it's not worth all the
> hastle and arguments and such. Stick it i
If an Apache module *requires* a non-ASL-friendly library in order to
be used, then I think that's the sticking point. Although, I don't
know how far we take that. All of our Java modules require a JVM,
which isn't compatible either.
On Tue, Sep 25, 2012 at 10:38 AM, Sam (Stephen Samuel)
wrote:
Thanks! That is a cool feature.
Sent from my iPad
On Sep 23, 2012, at 5:20 AM, Babak Vahdat wrote:
> Hi
>
> I just fixed it, so do an update on camel-jaxb which should now make the
> test pass again.
>
> BTW this unit-test verifies a new cool feature in Camel 2.11 provided by
> Claus Ibsen.
Running org.apache.camel.jaxb.JaxbMarshalNamespacePrefixMapperTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.627
sec <<< FAILURE!
Running org.apache.camel.jaxb.SplitterAndExceptionRouteTwistIssueTest
[Fatal Error] :4:22: An invalid XML character (Unicode: 0x10) was
found in
Well, look at it this way. At least the camel riders now know of a
potential change to AMQ! :)
On Tue, Sep 18, 2012 at 11:08 AM, Claus Ibsen wrote:
> Ah sorry I did it again, sent to the wrong @dev.
> This talk should happen only on AMQ @dev.
>
> On Tue, Sep 18, 2012 at 5:04 PM,
Is this conversation spanning two lists? I would think the ActiveMQ
community (those that aren't camel riders) would want to be involved,
too. This should probably move to the ActiveMQ dev list.
On Tue, Sep 18, 2012 at 8:18 AM, Claus Ibsen wrote:
> Hi
>
> 1)
> I have experimented a bit and so f
s.
On Thu, Sep 6, 2012 at 10:12 PM, James Carman
wrote:
> Have you tried using bouncycastle as your JCE provider? It supports PGP.
>
> On Thu, Sep 6, 2012 at 4:33 PM, ckalirasa wrote:
>> The error I was getting :
>>
>> java.lang.IllegalArgumentException: Public key
Have you tried using bouncycastle as your JCE provider? It supports PGP.
On Thu, Sep 6, 2012 at 4:33 PM, ckalirasa wrote:
> The error I was getting :
>
> java.lang.IllegalArgumentException: Public key is null, cannot proceed
> at
> org.apache.camel.converter.crypto.PGPDataFormat.marshal(
Did anyone have a chance to review this patch?
On Mon, Aug 27, 2012 at 10:53 PM, James Carman
wrote:
> I just submitted a patch to the following issue:
>
> https://issues.apache.org/jira/browse/CAMEL-5464
>
> I currently don't see an option for granting a license to the ASF w
I gave it 2048M.
On Aug 28, 2012 7:40 AM, "Claus Ibsen" wrote:
> On Tue, Aug 28, 2012 at 1:28 PM, James Carman
> wrote:
> > They were out of memory errors. I am running on:
> >
> > Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500)
> > Maven
avaeye.com/) (Chinese)
> Twitter: willemjiang
> Weibo: willemjiang
>
>
>
>
>
> On Tuesday, August 28, 2012 at 11:49 AM, James Carman wrote:
>
>> Okay, so my patch is "granted" by default. Good to go. Still waiting
>> on a full build to work locally. I&#x
seSource
> Web: http://www.fusesource.com (http://www.fusesource.com/)
> Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/)
> (English)
> http://jnn.javaeye.com (http://jnn.javaeye.com/) (Chinese)
> Twitter: willemjiang
> Weibo: willemjiang
>
>
>
&g
I just submitted a patch to the following issue:
https://issues.apache.org/jira/browse/CAMEL-5464
I currently don't see an option for granting a license to the ASF when
I attach files in JIRA. When it's restored, I'll reattach and grant
the license. I'm currently having trouble getting a "full"
[
https://issues.apache.org/jira/browse/CAMEL-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13085422#comment-13085422
]
James Carman commented on CAMEL-4251:
-
Nevermind. I believe someone has alr
[
https://issues.apache.org/jira/browse/CAMEL-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13085409#comment-13085409
]
James Carman commented on CAMEL-4251:
-
Does anyone have any ideas on this one? I
69 matches
Mail list logo
