Github user clebertsuconic commented on the pull request:
https://github.com/apache/activemq-artemis/pull/260#issuecomment-102053241
The same thing could apply to any other test.. I don't think it's a valid
change...
I could accept making it something else but fixed... change the
GitHub user thiagokronig opened a pull request:
https://github.com/apache/activemq-artemis/pull/260
Fix AeroGearBasicServerTest by binding random port
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/thiagokronig/activemq-artemis
Github user thiagokronig commented on the pull request:
https://github.com/apache/activemq-artemis/pull/260#issuecomment-102047182
Occasionally I have something running on 8080.
I thought that it would be better than binding to a fixed port so common as
8080.
Also, doing so
Github user asfgit closed the pull request at:
https://github.com/apache/activemq-artemis/pull/259
---
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
GitHub user clebertsuconic opened a pull request:
https://github.com/apache/activemq-artemis/pull/261
Changing host to 0.0.0.0
We are changing the default host to 0.0.0.0 per feedback from the community
(activemq dev-list)
You can merge this pull request into a Git repository by
I think it's fine to release with auto create set to false. Remember 1.0.0
is just a starting point. We can discuss what needs changing after the
release in a separate discussion. I'm sure there will be lots of
differences like this but we shouldn't let them block this first release.
Great job on
On 14/05/15 17:11, Justin Bertram wrote:
However, it is doubtful this is the way any broker will ever be run for real.
Yes, of course.
As I see it, the default configuration is for users (mostly developers) who
want to start up a broker quickly, run a few examples, look at the console,
etc.
Another reason for not releasing this build: the destinations are not
automatically created. Server throws *ActiveMQNonExistentQueueException *when
trying to create a destination. Is this a configurable feature? If so, it
should be set to the standard ActiveMQ behavior by default (i.e.,
The resource clean up code for dead clients doesn't seem to work reliably.
Probably not a show-stopper for a beta release, but definitely needs to be
cleaned up for production. Basically, when Artemis detected a dead client
(it stopped responding because I hit a breakpoint in my debugger), it
why don't we just add a flag --secure or something similar and document it.
I'm fine with a flag, but I'd advocate using --unsecure and having a secure
configuration by default. Then it's up to the user to decide which they want.
Justin
- Original Message -
From: Andy Taylor
BTW now that we generate the instance configuration, we could create
fully secure configurations by default. For example we could generate
a broker with SSL enabled using a generated self signed cert. We
could also create a default admin users with a generated password etc.
On Thu, May 14, 2015
The security issue is a valid argument, but like you say if its not common
for users to unzip and deploy into production then its actually a moot point.
Production systems are not the only systems on which security is important.
Consider a casual user who starts the broker just to play
If its not 100% air tight then there are still vulnerabilities. I think
something useful out of the box is better.
Since the user now has to create an instance befote tunning tbw broker,
why don't we just add a flag --secure or something similar and document it.
Then it's up to the user to decide
IMO the broker correctly binds to localhost only and does not, by default,
allow connections from remote machines. This is a simple security/sanity
measure to prevent access to default (i.e. unsecured) instances.
The merit of this configuration is obviously up for debate, but it's worth
If it was done on purpose for security reasons, that's cool. However, it is
doubtful this is the way any broker will ever be run for real. The whole
purpose of a broker is to integrate disparate systems. It's like having a
web server start up without the ability to server web pages by default.
I'm not sure that's a good default. ActiveMQ has traditionally
allowed remote access to it's ports. I think a localhost binding is
fine for things like management ports, but for the main service the
product gives it should be on the public ports.
That would be like tomcat or jetty defaulting to
Thanks, Clebert!
And thanks for the quick update on the default bindings.
On Thu, May 14, 2015 at 8:59 AM, Clebert Suconic clebert.suco...@gmail.com
wrote:
here is the JIRA with the current progress on the renames:
https://issues.apache.org/jira/browse/INFRA-9543
On Thu, May 14, 2015 at
+1 We debated this some time ago for ActiveMQ and opted for the current
functionality of allowing remote connections by default.
Bruce
On Thu, May 14, 2015 at 9:32 AM, Hiram Chirino hi...@hiramchirino.com
wrote:
I'm not sure that's a good default. ActiveMQ has traditionally
allowed remote
+1
On 05/14/2015 12:14 PM, Bruce Snyder wrote:
+1 We debated this some time ago for ActiveMQ and opted for the current
functionality of allowing remote connections by default.
Bruce
On Thu, May 14, 2015 at 9:32 AM, Hiram Chirino hi...@hiramchirino.com
wrote:
I'm not sure that's a good
-1
Two reasons:
1. The default configuration of localhost for the broker does not allow
connections from off-machine. For some reason, socket connections are
refused from non-local clients. I had to change the broker.xml config to
use the machine's actual IP address, and then non-local clients
However, it is doubtful this is the way any broker will ever be run for real.
Yes, of course.
As I see it, the default configuration is for users (mostly developers) who
want to start up a broker quickly, run a few examples, look at the console,
etc. All that would typically be done locally
Logged bug ACTIVEMQ6-106.
And at the risk of opening a big can of worms, do we need to have
Infrastructure rename the JIRA database from ACTIVEMQ6 to AMQARTEMIS or
something? I was very hesitant to enter a bug there, and had to
double-check that it was indeed the Artemis bug tracker.
On Thu, May
We have requested a rename. Infra is waiting on a window to reboot JIRA.
Sent from my iPad
On May 14, 2015, at 11:41, Jim Gomes e.se...@gmail.com wrote:
Logged bug ACTIVEMQ6-106.
And at the risk of opening a big can of worms, do we need to have
Infrastructure rename the JIRA database
Thinking about it I agree with Hiram too
Sent from Samsung Mobile
div Original message /divdivFrom: Jim Gomes
e.se...@gmail.com /divdivDate:14/05/2015 16:42 (GMT+00:00)
/divdivTo: ActiveMQ Dev dev@activemq.apache.org /divdivSubject: Re:
[VOTE] Apache Artemis 1.0.0 (RC2)
here is the JIRA with the current progress on the renames:
https://issues.apache.org/jira/browse/INFRA-9543
On Thu, May 14, 2015 at 11:41 AM, Jim Gomes e.se...@gmail.com wrote:
Logged bug ACTIVEMQ6-106.
And at the risk of opening a big can of worms, do we need to have
Infrastructure rename
https://github.com/apache/activemq-artemis/pull/261
but if you guys could please keep the feedback coming.. no need to
wait the next RC to try it out.
On Thu, May 14, 2015 at 11:50 AM, andy.tayls67 andy.tayl...@gmail.com wrote:
Thinking about it I agree with Hiram too
Sent from Samsung
Sent from my iPad
On May 14, 2015, at 11:05, Jim Gomes e.se...@gmail.com wrote:
-1
Two reasons:
1. The default configuration of localhost for the broker does not allow
connections from off-machine. For some reason, socket connections are
refused from non-local clients. I had to
It's impossible to run any of the NMS unit tests with destination
autocreate set to false. If Artemis is meant to be a drop-in replacement
(as much as possible) for ActiveMQ, then we should match feature defaults,
unless there is an definite problem that is being solved by changing the
defaults.
Agreed. But there are lots of them. Let's get 1.0.0 out and then come up
with a migration path for all of them.
On 14 May 2015 20:04, Jim Gomes e.se...@gmail.com wrote:
It's impossible to run any of the NMS unit tests with destination
autocreate set to false. If Artemis is meant to be a drop-in
I'd be happy either way.
On 14 May 2015 20:00, Justin Bertram jbert...@apache.com wrote:
why don't we just add a flag --secure or something similar and document
it.
I'm fine with a flag, but I'd advocate using --unsecure and having a
secure configuration by default. Then it's up to the
This is going to be the first release... and even the first with
OpenWire... there certainly going to be other issues.
I Think of this like a Beta... people will then have time to kick it
out and raise issues...
then this should be released very frequently...
On Thu, May 14, 2015 at 3:29
Is that what it is? just setting auto-create to true will fix it?
if that's the case... it's an easy fix?
On Thu, May 14, 2015 at 3:06 PM, Andy Taylor andy.tayl...@gmail.com wrote:
Agreed. But there are lots of them. Let's get 1.0.0 out and then come up
with a migration path for all of them.
Github user clebertsuconic commented on the pull request:
https://github.com/apache/activemq-artemis/pull/262#issuecomment-102180201
looks nice... but it seems to be a regression on the extra-tests:
GitHub user thiagokronig opened a pull request:
https://github.com/apache/activemq-artemis/pull/262
Make Topology non-serializable and also improve constructor
Topology serialization is already broken at this point, as its
`topologyListeners` are not Serializable themselves.
Yeah, we don't have to have everything fixed, however, ACTIVEMQ6-106 is a
showstopper, because consumers are getting kicked off even when the are
sending KeepAlive and even when they are active. I attached a sample
application to the JIRA that can reproduce the item.
As far as I can tell, the
Github user clebertsuconic commented on the pull request:
https://github.com/apache/activemq-artemis/pull/262#issuecomment-102180239
I'm running a full testsuite as well just in case
---
If your project is set up for it, you can reply to this email and have your
reply appear on
Of course. Will do it on Linux tomorrow.
On Thu, May 14, 2015, 19:31 clebertsuconic g...@git.apache.org wrote:
Github user clebertsuconic commented on the pull request:
https://github.com/apache/activemq-artemis/pull/262#issuecomment-102180201
looks nice... but it seems to be a
37 matches
Mail list logo
