Sorry, hit send too soon...
Here are the steps:
1. mkdir spruitt
2. cd spruit
3. wget
http://mirrors.sonic.net/apache/activemq/activemq-artemis/1.2.0/apache-artemis-1.2.0-bin.zip
4. unzip apache-artemis-1.2.0-bin.zip
5. cd apache-artemis-1.2.0/examples/features/standard/security
6. mvn verify
C
Could you outline the exact steps you are following to execute the example?
Also, when you say, "I just posted the results..." Where exactly did you post
the results?
Here are the steps I just performed and everything worked as expected (i.e. the
example ran without error)
1.
1.
1.
- O
FYI, I'm hoping to do a 5.13.1 release in a week or 2 (if everything goes
well and no blockers pop up), at which point you can upgrade to hopefully
solve this issue. 5.14.0 probably won't be out for a while yet.
On Fri, Jan 15, 2016 at 9:13 AM, Tim Bain wrote:
> Another way you could eliminate
Justin,
I should have been more specific. The html readme files have instructions and
examples that appear to be only ActiveMQ. My fault.
Also, I just posted the results from running the example
examples/features/standard/security and I still get basically the same user
authentication except
I guess I'm confused about your previous statements:
> Clebert suggested I look under examples/features/standard/security. I did,
> but the example is for ActiveMQ, so I didn't pursue it. Another suggestion,
> is update the example folders with pure Artemis examples.
The example in examples/
I tried the security example at \examples\features\standard\security as
suggested by Clebert. I copied the the broker.xml and the user / role
property files to my broker install. I ran the example code and I still get
the same problem.
Exception in thread "main" javax.jms.JMSSecurityException: AM
To my knowledge Artemis only ships pure Artemis examples. Where exactly where
you looking where you found an ActiveMQ example in the Artemis distribution (or
repo)?
Also, most of the examples should be using a file-based JAAS configuration.
The example at examples/features/standard/security d
First, let thank the great community help.
All of my client rabbit holes I chased down led me to the real problem...
eventually.
Updating the documentation as Justin indicated resolve my basic issue. I
might suggest detailing the bootstrap.xml documentation along the lines of
the broker.xml desc
That's in ActiveMQ, which now uses Git at
https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=summary. See
https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=tree;f=activemq-web-console;h=04a8a829a6107322ba3eedf2ae5028a2120fdf93;hb=refs/heads/master
for the master branch of the web cons
That's correct.
On Fri, Jan 15, 2016 at 7:45 AM, itelleria wrote:
> Thank you for your quick reply.
>
> So, to sum up, transport thread is required to send and receive messages
> and
> because of that it's always launched when a connection is created.
>
>
>
>
> --
> View this message in context:
First, I think you're right that it's problematic that KahaDB checkpoint
operations and "real" usage of the memory store are able to block one
another, though my reasons for saying that may not be quite the same as
yours. Fundamentally, the memory store and the persistence store are
intended to be
In fact in case I was not clear enough, the activemqweb application now
behave correctly (meaning does not say "slave" whichever node I am querying
but forwards to the active one) with the new servicemix (5.1.4) which use
ActiveMQ 5.10.
Now I don't even know where are the real source code of this
Thank you for your quick reply.
So, to sum up, transport thread is required to send and receive messages and
because of that it's always launched when a connection is created.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/ActimeMQ-Client-s-thread-management-tp4705885
Another way you could eliminate this problem (without turning off JMX) is
to change your log4j configuration to set the logging level to ERROR for
org.apache.activemq.network.MBeanBridgeDestination. You run the risk of
not seeing errors in MBean creation due to other reasons, but in practice
the o
Yes, I believe the documentation needs to be updated. It still references the
old non-JAAS basic security manager. I'll take care of that. In any event,
the JAAS security manager works fine for AMQP as far as I can tell so I don't
think this should be impacting this use-case.
Justin
-
Both of the exeception messages below are from the Artemis JMS client,
showing it failing to authenticate in similar manner to what you were
presumably seeing from the Qpid JMS client beforehand. I'd again
assume this is a result of the bootstrap issues mentioned in your
other thread, and I'd expec
I had similar tried things out with authentication (default user from
a newly created instance) yesterday when Steve posted on the Qpid
users list, and had no issue. I assume the problem stems from the
bootstrap config issues mentioned in the other thread.
Robbie
On 15 January 2016 at 01:46, Just
Steve mentioned in a separate thread over on the Qpid users list that
he was following some documentation for Artemis when running into
these issues. Steve, can you link to the exact bits you were
following, perhaps it needs updated?
Robbie
On 15 January 2016 at 00:36, Justin Bertram wrote:
> Th
18 matches
Mail list logo
