Re: Released BOM should have hardcoded camel version

Hi Claus, Thanks, good info. I’ll follow the same for ActiveMQ. -Matt Pavlovich > On Mar 13, 2024, at 1:29 AM, Claus Ibsen wrote: > > Hi > > The BOM should use hardcoded versions as the BOM is for a given version, eg > 4.5.0 should be 4.5.0 versions. > That is al

Re: Released BOM should have hardcoded camel version

any unintended side-effects? Thanks, Matt Pavlovich > On Mar 10, 2024, at 7:34 AM, Claus Ibsen wrote: > > Hi > > https://issues.apache.org/jira/browse/CAMEL-20413 > > The BOM we release for both core and SB have > > > org.apache.camel > camel-api > ${proj

Re: [VOTE] Accept karaf-camel as new Apache Karaf subproject

kaged as bundles? Hi Andrea- This is really the gist of my inquiry — What is the level of effort involved in maintaining OSGi metadata for Camel? From the high level it appears to be handled automatically at this point. Thanks, Matt Pavlovich

Re: [VOTE] Accept karaf-camel as new Apache Karaf subproject

aintaining OGSI metadata in Camel a concern? Thanks, Matt Pavlovich

Re: Camel 4 roadmap and affect on Camel 3

. Seems odd that Camel would prefer to opt out of that by default. Add’l thoughts on Camel v4— How about the Camel JMS component using Spring JMS be swapped out with the Java-native one as the default for ‘jms’? This would obviously be a major breaking change. Thanks, Matt Pavlovich > On

Re: [PROPOSAL] Refactoring and new maintenance of camel-karaf

Hey JB- These sound really good! Especially whiteboard support and simplified deployment of dependencies. Thanks! Matt Pavlovich > On May 2, 2022, at 8:07 AM, Jean-Baptiste Onofré wrote: > > Hi guys, > > I worked on several changes on camel-karaf that I would like to >

Re: [PROPOSAL] Remove activemq-camel component

Hey JB- I already removed it from 5.17.0 (main) -Matt > On Jan 12, 2022, at 4:16 AM, Jean-Baptiste Onofré wrote: > > Hi all, > > ActiveMQ provides activemq-camel component. > > This component is "old" (using Camel 2.25.x) and has been replaced by > camel-activemq and/or camel-jms. > > I

Re: Dropping Java 8

+1 good time to start doing that > On Sep 3, 2021, at 5:18 AM, Andrea Cosentino wrote: > > Hello all, > > More and more third party libraries are starting to drop JDK 8 in favor of > JDK 11 (last one I've found is Optaplanner). > > I think we need to define a release where we totally drop

Re: [PROPOSAL] Remove activemq-camel from Apache ActiveMQ

7/5.16). > > (2) can be targeted to 5.17.x for sure. > > Regards > JB > >> Le 21 mai 2021 à 15:49, Matt Pavlovich a écrit : >> >> JB- >> >> Agreed that we can start to wind down activemq-camel. >> >> How about: >> >> 1. Rem

Re: [PROPOSAL] Remove activemq-camel from Apache ActiveMQ

Hit send too soon.. I’m happy to build the Guide for the website. Thanks, Matt Pavlovich > On May 21, 2021, at 8:49 AM, Matt Pavlovich wrote: > > JB- > > Agreed that we can start to wind down activemq-camel. > > How about: > > 1. Remove activemq-camel from activ

Re: [PROPOSAL] Remove activemq-camel from Apache ActiveMQ

JB- Agreed that we can start to wind down activemq-camel. How about: 1. Remove activemq-camel from activemq-osgi 2. Keep activemq-camel as a module in the build 3. Create a ticket for ‘Guide to ActiveMQ 5.1+ Camel 3.x' There are a *ton* of Camel examples online that reference the

Re: R: Artemis 2.0 target features

Yep.. email client auto-address nuked me. Please disregard. On 12/7/16 4:27 PM, Andrea Cosentino wrote: I guess this is the wrong mailing lista.. Il mer, 7 dic, 2016 alle 22:20, Matt Pavlovich<mattr...@gmail.com> ha scritto: Kicking off a discussion on what folks would like

Artemis 2.0 target features

Kicking off a discussion on what folks would like to see in 2.0.0 release for Artemis. My thought is that we should target ActiveMQ 5.x feature parity in an effort to solidify Artemis in the product sense. I will detail out specifics from my previous note on 5.x-Artemis feature gaps.

Re: Proposed change to BlueprintCamelContext startup behaviour

I've had to work through these same issues by registering a service listener to a "service manager" thingie and having the CamelRoute passed into the "service manager" thingie. However, shouldn't the CamelContext be initialized when the BlueprintEvent.CREATED is sent? I could see it being

Re: Clustered routes in master/slave mode

+1 Claus- I could see a lot of value in having this feature for file://, ftp:// and several other components as well. Are you thinking Context or Route level or both? -Matt On 5/28/16 2:52 AM, Claus Ibsen wrote: Hi We have a few components that offer capability to run a Camel routes in

Re: camel route not posting the message to mq

Hi- This question is best suited for the camel-users list. camel-dev is geared for the development of the Camel itself. Would you please post this questions over on that list? Also, it'd be helpful if you posted this code to a website like pastebin or other where the code can be formatted

Re: [DISCUSS] - Moving from maven-bundle-plugin to bnd-maven-plugin and SNAPSHOT versions

On 4/6/16 1:53 AM, Claus Ibsen wrote: Yeah all the sister Apache projects like Karaf / ServiceMix / CXF / ActiveMQ etc are also using it. Though it begs the question - why 2 plugins? Why cant they work together and make 1 good plugin. There adoption of OSGi do not need more confusion and

Re: [DISCUSS] - Moving from maven-bundle-plugin to bnd-maven-plugin and SNAPSHOT versions

I was ruminating about this as well-- I agree its not exact; however, is there any real impact? The bundle version is indicated by the SNAPSHOT. How would the package export having the .SNAPSHOT qualifier (which would not impact any wiring) have any undesirable impact? On 4/5/16 4:48 PM,

Re: [DISCUSS] - Moving from maven-bundle-plugin to bnd-maven-plugin and SNAPSHOT versions

I think its important to consider that Camel moving to bnd-maven-plugin will mean most users will do the same, or inherit their projects from a camel-parent pom or camel-bom. I suggest that end-user Camel projects be included as a use case, along with the Camel source tree itself. On 4/5/16

Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0

wrote: I think the core should focus on speed, consistency, reliability and last extensibility; Camel has a nice traction but we don’t want to see “strange” bugs from new features if that makes sense as a long windy sentence….. On Apr 4, 2016, at 9:36 AM, Matt Pavlovich <mattr...@gmail.com>

Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0

On 4/4/16 11:12 AM, Raul Kripalani wrote: On Mon, Apr 4, 2016 at 4:44 PM, Matt Pavlovich <mattr...@gmail.com> wrote: The current website looks the same as it did when it was created: https://web.archive.org/web/20070701184530/http://activemq.apache.org/camel/ I thought the Karaf gu

Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0

On 3/23/16 5:07 AM, Claus Ibsen wrote: j) Split camel-cxf into modules so we can separate WS and RS and also spring vs blueprint. Today its big ball of dependencies that is a bit hard to slice and dice. Specially for MSA style with REST and you dont want to add in a bunch of extra not needed

Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0

On 3/24/16 3:27 PM, Raul Kripalani wrote: On Thu, Mar 24, 2016 at 5:24 PM, Krzysztof Sobkowiak < krzys.sobkow...@gmail.com> wrote: I think, the way to Camel 3 should also include the renovation of the Core (if really necessary) or even rewriting and making it more asynchronous, e.g. using

Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0

On 3/24/16 3:55 PM, Claus Ibsen wrote: On Thu, Mar 24, 2016 at 6:24 PM, Krzysztof Sobkowiak wrote: Hi I'm not sure how the Camel Core actually looks like (especially the quality and the ability to refactor or make more complicated changes) but I had occasion to

Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0

Jakub- Sign me up to help with this. -Matt On 3/23/16 9:22 AM, jkorab wrote: Claus Ibsen-2 wrote PS: We surely also need a better "what is Camel" story on the front page. Its still that very first one with all the tech jumble that was initially created. I would be happy to write something

Re: Camel always sending MQRFH2 headers to target WebsphereMQ queue.

Hi Sashi- Are you reading the message out of a Transmit queue (XMIT)? Does the message have an XQH header? If so, we have a solution for that. Thanks, Matt Pavlovich Founding Partner Media Driver P: (512) 284-4330 E: m...@mediadriver.com Skype: mattrpav On Jun 3, 2013, at 11:20 AM

Re: 3.0 Ideas

=jms.. / (I want these [x,y,z,a,b,c] headers propagated, but drop the rest.. ) Thanks, Matt Pavlovich

Re: 3.0 Ideas

to component out-of-the-box. Thanks Matt Pavlovich On Mar 19, 2013, at 5:11 PM, Daniel Kulp dk...@apache.org wrote: HttpURLConnection

Re: 3.0 Ideas

re-test, and new projects on 3.0 are clean. My $0.02. Thanks, Matt Pavlovich On Mar 18, 2013, at 9:51 PM, Willem jiang willem.ji...@gmail.com wrote: I'm afraid it is not easy to do that, as there a lots of people using the jms component. It could be same with http component (http client 3.x

Re: 3.0 Ideas

track. Take a look at https://issues.apache.org/jira/browse/CAMEL-6108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13592471#comment-13592471for a proposal. Raúl. Sent while on the move On 19 Mar 2013 00:38, Matt Pavlovich mattr...@gmail.com wrote

Re: 3.0 Ideas

If all goes well with the sjms component conversion, could we drop the old component completely and rename sjms - jms? Another request for 3.0: - Convert the http4 component to - http (original http component dropped) Thanks, Matt Pavlovich On Mar 4, 2013, at 2:35 PM, Scott England-Sullivan

Re: [DISCSS] - Remove error handler mbeans from JMX

a path to solve some of the issues? Okay you are pushing my boundaries, and I am working on a solution. Thanks, Matt Pavlovich On 2/28/12 6:57 AM, Claus Ibsen wrote: Hi I am considering to remove error handlers mbeans from JMX as they are painful to track properly for context and route scoped

Re: [DISCSS] - Remove error handler mbeans from JMX

? Thanks, Matt Pavlovich On 2/28/12 6:57 AM, Claus Ibsen wrote: Hi I am considering to remove error handlers mbeans from JMX as they are painful to track properly for context and route scoped routes, in the various DSLs (Java vs XML etc.). And the fact an error handler can be used for multiple

Re: [discuss] implementing Locks in Camel

this today with transactions. My $0.02 Matt Pavlovich On Sep 7, 2011, at 11:20 AM, Hadrian Zbarcea wrote: Ben, no issue with the term lock(), I get the semantics. What I don't get is this: what happens in your scenario if one of the boxes crashes (say physically, burnt memory chip, power

Re: [discuss] implementing Locks in Camel

Disclaimer-- I haven't used either of these locking technologies described, but understand how and why Ben is looking to use them. I think it would be helpful to understand how other use cases would apply to support this in the DSL. I can see a lot of ways where users would misinterpret what

Re: [DISCUSS] Global interceptors

+1 Totally agree. This is a functionality that I've implemented a number of times and is great for creating audit trails, and replay. On Jul 21, 2011, at 4:22 AM, Guillaume Nodet wrote: For ServiceMix, we are in need for having *global* interceptors, i.e. some kind of static list of