#Virtual_Hosts
important especially for Cloud deployments, as a lightweight option (the
level of isolation, e.g. persistence, can be debated, though)
--
View this message in context:
http://activemq.2283324.n4.nabble.com/DISCUSS-ActiveMQ-CodeName-Must-Have-Features-tp4694989p4695373.html
Sent from
well.. we have Hierarchical queues. Im not sure if it's the same thing.
On Wed, Apr 15, 2015 at 11:40 AM, Clebert Suconic
clebert.suco...@gmail.com wrote:
We already have Message Groups.. .maybe someone could review it to
check if it's compatible.. (It should be BTW.. we used to compete)
for
The equivalent of BrokerFilters for extension points - including using embedded
Camel inside the Broker for flexible message routing
On 15 Apr 2015, at 16:56, James Carman ja...@carmanconsulting.com wrote:
In order for ActiveMQ {CodeName} to take over as the next generation
of ActiveMQ,
We already have Message Groups.. .maybe someone could review it to
check if it's compatible.. (It should be BTW.. we used to compete)
for OSGI: https://issues.apache.org/jira/browse/ACTIVEMQ6-93
Virtual Topics: again: we already have it... needs to check if it's
totally compatible (which
My big +1 Daniel. OSGi support is very important for us. Whether ActiveMQ
{CodeName} will be a future ActiveMQ
mainstream or not user should have possibility to chose ActiveMQ {CodeName} as
the broker in ServiceMix. But it requires
OSGi support.
Regards
Krzysztof
On 15.04.2015 18:23, Daniel
MUST HAVE
- JMS 2.0 support would be great (and I know is already included in the
code donation)
-- Virtual topics seem like they can be deprecated/discarded in favor of
shared durable subscriptions
NICE TO HAVE
- Support for existing legacy message stores. A means to convert an
existing legacy
Support for storing broker data in a relational database.
On Wed, Apr 15, 2015 at 11:56 AM, James Carman
ja...@carmanconsulting.com wrote:
In order for ActiveMQ {CodeName} to take over as the next generation
of ActiveMQ, it obviously must have some level of feature parity with
the existing
I don't think we will need virtual topics if we support JMS2
On 15 Apr 2015, at 17:29, Daniel Guggi daniel.gu...@gmail.com wrote:
correction Message Destinations - Message Groups
On Wed, Apr 15, 2015 at 6:27 PM, Daniel Guggi daniel.gu...@gmail.com
wrote:
@Configuration format file
I
On Wed, Apr 15, 2015 at 11:41 AM, Brian D. Johnson
br...@thejohnsonfamily.name wrote:
MUST HAVE
- JMS 2.0 support would be great (and I know is already included in the
code donation)
Yep.. done..
-- Virtual topics seem like they can be deprecated/discarded in favor of
shared durable
It wasn't clear to me if the format of the Configuration file is
really important or not. If I was the user i wouldn't mind.
Users will have to change the configs anyways... things like the
journal will have new settings... paging address... address-settings..
other things.. but if the XML taste
correction Message Destinations - Message Groups
On Wed, Apr 15, 2015 at 6:27 PM, Daniel Guggi daniel.gu...@gmail.com
wrote:
@Configuration format file
I as a user wouldn't mind either
Features I'd also like to have in v6
- Message Destinations (afaik already...)
- Virtual
https://issues.apache.org/jira/browse/ACTIVEMQ6-27
On Wed, Apr 15, 2015 at 11:43 AM, Hiram Chirino hi...@hiramchirino.com wrote:
Support for storing broker data in a relational database.
On Wed, Apr 15, 2015 at 11:56 AM, James Carman
ja...@carmanconsulting.com wrote:
In order for ActiveMQ
NICE TO HAVE
- Support for existing legacy message stores. A means to convert an
existing legacy store to the new store format would suffice.
This would need to be done as an exporter on ActiveMQ-5. is it
feasible? I'm still learning the codebase and I could look at it.. but
if anyone knows
In order for ActiveMQ {CodeName} to take over as the next generation
of ActiveMQ, it obviously must have some level of feature parity with
the existing ActiveMQ 5.x (or 6.x if it's released before that
transition) offering. We should come up with some level of a roadmap
together about which
Couple things I think are important:
1) OSGi support - in particular the Karaf features and various commands and
such for starting and configuring the brokers within Karaf.
2) Related to (1) - using the “normal” libraries that we would use within
Karaf. The particular one I’m thinking of
@Configuration format file
I as a user wouldn't mind either
Features I'd also like to have in v6
- Message Destinations (afaik already...)
- Virtual Destination/Topics support
- and big +1 for Auto-creation of destinations
On Wed, Apr 15, 2015 at 6:03 PM, Clebert Suconic
On Wed, Apr 15, 2015 at 11:40 AM, Krzysztof Sobkowiak
krzys.sobkow...@gmail.com wrote:
My big +1 Daniel. OSGi support is very important for us.
+1: https://issues.apache.org/jira/browse/ACTIVEMQ6-93
I had identified before.. it needs to be done
Must have:
Support for the Timestamp plugin, or (better) built-in equivalent. My usage
requires the ability to override timestamps on submitted messages to
correct for out of synch clocks between clients and server.
On Wed, Apr 15, 2015, 8:58 AM James Carman ja...@carmanconsulting.com
wrote:
Hi,
my whishlist:
(with descending importance level)
- stability and resilience!!!
- simplified configuration, (it should be difficult to create unstable
configurations)
- easy and very stable out-of-the-box clustering without centralized
components
(i.e. like leveldb but without running a
, April 15, 2015 2:01:48 PM
Subject: Re: [DISCUSS] ActiveMQ {CodeName} Must-Have Features...
Hi,
my whishlist:
(with descending importance level)
- stability and resilience!!!
- simplified configuration, (it should be difficult to create unstable
configurations)
- easy and very stable out
(i.e. in ActiveMQ {CodeName})
C) both 'A' and 'B'
?
Justin
- Original Message -
From: Marc Schöchlin m...@256bit.org
To: dev@activemq.apache.org
Sent: Wednesday, April 15, 2015 2:01:48 PM
Subject: Re: [DISCUSS] ActiveMQ {CodeName} Must-Have Features...
Hi,
my whishlist
21 matches
Mail list logo