date:20061025

And it looks like the upgrade from wadi 2.0m1 to 2.0m2-SNAPSHOT is  
non-trivial.  I see a ton of "org.codehaus.wadi.gridstate" related  
symbols missing and a bunch of things like missing "ProxiedLocation"  
and "InvocationContext".


I think someone who knows all this wadi muck is going to need to look  
at this.


We need to get this resolved so we don't ship different versions of  
activemq/activeio/activecluster junk with G.


--jason


On Oct 25, 2006, at 6:11 PM, Jason Dillon wrote:


Blah... wadi needs to be upgraded as well :-(

--jason


On Oct 25, 2006, at 5:27 PM, Dain Sundstrom wrote:


Submit a patch.

-dain

On Oct 25, 2006, at 5:21 PM, Jason Dillon wrote:


Looks like openejb2 is still using old ActiveMQ jars.

Can we get those deps upgraded plz?

--jason


On Oct 25, 2006, at 5:11 PM, Jason Dillon wrote:

Anyone know why we are still seeing old activemq and  
activecluster bits?



[WARNING] POM for 'activecluster:activecluster:pom:1.1- 
SNAPSHOT:compile' is invalid. It will be ignored for artifact  
resolution. Reason: Not a v4.0.0 POM.
[WARNING] POM for 'activemq:activemq:pom:3.2.4-SNAPSHOT:compile'  
is invalid. It will be ignored for artifact resolution. Reason:  
Not a v4.0.0 POM.



--jason

Re: Old activemq and activecluster


Blah... wadi needs to be upgraded as well :-(

--jason


On Oct 25, 2006, at 5:27 PM, Dain Sundstrom wrote:


Submit a patch.

-dain

On Oct 25, 2006, at 5:21 PM, Jason Dillon wrote:


Looks like openejb2 is still using old ActiveMQ jars.

Can we get those deps upgraded plz?

--jason


On Oct 25, 2006, at 5:11 PM, Jason Dillon wrote:

Anyone know why we are still seeing old activemq and  
activecluster bits?



[WARNING] POM for 'activecluster:activecluster:pom:1.1- 
SNAPSHOT:compile' is invalid. It will be ignored for artifact  
resolution. Reason: Not a v4.0.0 POM.
[WARNING] POM for 'activemq:activemq:pom:3.2.4-SNAPSHOT:compile'  
is invalid. It will be ignored for artifact resolution. Reason:  
Not a v4.0.0 POM.



--jason

Re: Old activemq and activecluster


Submit a patch.

-dain

On Oct 25, 2006, at 5:21 PM, Jason Dillon wrote:


Looks like openejb2 is still using old ActiveMQ jars.

Can we get those deps upgraded plz?

--jason


On Oct 25, 2006, at 5:11 PM, Jason Dillon wrote:

Anyone know why we are still seeing old activemq and activecluster  
bits?



[WARNING] POM for 'activecluster:activecluster:pom:1.1- 
SNAPSHOT:compile' is invalid. It will be ignored for artifact  
resolution. Reason: Not a v4.0.0 POM.
[WARNING] POM for 'activemq:activemq:pom:3.2.4-SNAPSHOT:compile'  
is invalid. It will be ignored for artifact resolution. Reason:  
Not a v4.0.0 POM.



--jason

Re: J2EE Management for JEE 5

2006-10-25 Thread Christopher M. Cardona


Dain Sundstrom wrote:

On Oct 24, 2006, at 10:45 PM, Christopher M. Cardona wrote:

2. JSR77.3.5.0.1 the deploymentDescriptor attribute must provide a 
full deployment descriptor based on any partial deployment descriptor 
plus deployment annotations.


That doesn't sound like it will be easy. Do they mean that you must 
build a full deployment descriptor backwards out of the annotations?




I’m not exactly sure how to interpret it either. Looks like the 
objective is to make sure the value for 'deploymentDescriptor' attribute 
of J2EEDeployedObject is always set to the combined or full DD (partial 
DD plus deployment annotations). Our current implementation passes the 
DD values to the constructors of the concrete classes that implement 
J2EEDeployedObject. So my guess is checking and manipulation of DD 
should be done inside the classes that call those constructors. Thoughts?


My first question is do we even have to update our current JSR 77 
implementation to become JEE 5 compliant.


JSR 77 is a weird spec in that is had very few Java APIs specified. 
The bulk of the spec described the names of fields and operations to 
be exposed via JMX. You should check if the Java APIs were updated for 
Java5 generics.


Looking at the latest specs there are no API changes. I’ll update this 
thread if I find anything…


Thanks,
chris



-dain

Re: Old activemq and activecluster


Looks like openejb2 is still using old ActiveMQ jars.

Can we get those deps upgraded plz?

--jason


On Oct 25, 2006, at 5:11 PM, Jason Dillon wrote:

Anyone know why we are still seeing old activemq and activecluster  
bits?



[WARNING] POM for 'activecluster:activecluster:pom:1.1- 
SNAPSHOT:compile' is invalid. It will be ignored for artifact  
resolution. Reason: Not a v4.0.0 POM.
[WARNING] POM for 'activemq:activemq:pom:3.2.4-SNAPSHOT:compile' is  
invalid. It will be ignored for artifact resolution. Reason: Not a  
v4.0.0 POM.



--jason

Old activemq and activecluster


Anyone know why we are still seeing old activemq and activecluster bits?


[WARNING] POM for 'activecluster:activecluster:pom:1.1- 
SNAPSHOT:compile' is invalid. It will be ignored for artifact  
resolution. Reason: Not a v4.0.0 POM.
[WARNING] POM for 'activemq:activemq:pom:3.2.4-SNAPSHOT:compile' is  
invalid. It will be ignored for artifact resolution. Reason: Not a  
v4.0.0 POM.



--jason

javamail problems

I have been hacking on JavaMail lately and have run into difficulty  
overriding the JavaMail SMTP implementation.  In the great wisdom of  
Sun Microsystems, the only way to add a new protocol provider to the  
JavaMail implementation is have the implementation discover it via a  
META-INF/javamail.providers or META-INF/javamail.default.providers in  
the class loader.  Once your provider has been discovered, you can  
get it instantiated by either making it the default provider defined  
by the first META-INF/javamail.default.providers found in the class  
loader, programatically selecting the provider with  
session.getProviders() and session.setProvider(provider), or by  
passing in the mail.smtp.class=your.SMTPClass to the  
Session.getInstance(properties) method.  The third option seems  
really cool but the class you specify must be mentioned in a META-INF  
providers file otherwise the property is silently ignored.


I'd like to propose a couple of changes for the next release after  
1.2 which should make JavaMail (and some other lame specs) easier to  
use.


1) Add the ability to declare additional dependencies to the  
configuration via the config.xml file.  We probably want a way to  
exclude a dependency and maybe add to the front of the dependency  
list (unless remove re-add works).  This is required to add a new  
provider to the existing javamail configuration.  Without this, you  
must update every application to point to a new configuration that  
contains your provider jar.


2) Add a "className" attribute to  
org.apache.geronimo.mail.ProtocolGBean and all subclasses.  If this  
is set then, in addOverrides, we add a mail.${protocol}.class=$ 
{className} to the properties object.  There is no reason to add this  
until item 1 is complete, since you can't extend the class path, and  
would be very confusing to users.


What do you think?

-dain

Re: Assembly is caching old junk


Thanks Jason!

-dain

On Oct 25, 2006, at 4:19 PM, Jason Dillon wrote:

I think I may have fixed this.  Now, when installing car modules  
into an assemblies repository, if the module already exists in the  
target repo, the config.ser.sha1 in the source and target repos is  
compared.  If they are the same, then the module is skipped (as was  
the behavior before), else the module is uninstalled from the  
target repo and then reinstalled.


Logging output has been trimmed, so it only shows what is being  
installed.  mvn -X shows full details about uninstalls and skipping.


Lemme know if you still see old artifacts getting cached in  
builds... there might still be a few more holes to patch, but this  
was the big one.


--jason


On Oct 25, 2006, at 2:04 PM, Jason Dillon wrote:

Hrm... this ends up reinstalling way to many modules.  I think we  
may need to encode a guid in the car which can be inspected to  
find out if an installed car is the same as a car to be  
installed... so that we can intelligently skip reinstalling a  
car... instead of blindly skipping or reinstalling.


--jason


On Oct 25, 2006, at 1:49 PM, Jason Dillon wrote:

Since people is still down I can't do much on gbuild, as there  
are too may deps missing, and it would take too long to build the  
deps or upload from my network...


I looked into this problem... may have a fix, though I'm not 100%  
sure this is all that needs to be done.  Looks like when we  
install configs into the assembly's target store, we skip modules  
that exist already.  I'm going to add a flag (default to true)  
which will trigger existing modules to be uninstalled first  
instead of just skipping them.


--jason


On Oct 19, 2006, at 4:34 PM, Dain Sundstrom wrote:

I don't understand how any of this stuff works.  All I know is  
when I run mvn install I don't get my source changes.  It would  
be nice to have a single command that does something reasonable.


-dain

On Oct 19, 2006, at 4:17 PM, David Jencks wrote:

It might help anyone trying to fix this if you can determine  
what is out of date in the assembly.  For instance,


-- assembly might pick up timestamped jars instead of locally  
build -SNAPSHOT jars

-- assembly might include old copies of jars

As workarounds for the first you can build offline after  
removing all g. timestamped jars from your m2 repo
for the second perhaps running mvn -o clean install in assembly  
would help.


Pesonally I try to only rebuild stuff that I've changed or  
depends on stuff I've changed



thanks
david jencks

On Oct 19, 2006, at 3:40 PM, Dain Sundstrom wrote:

The tck is moving very slow because when I make a simple  
change to a jar the final assembly is getting the old code.   
For example, I do the following:


* changing some code (In my case naming)
* run "mvn install" from the geronimo/server/trunk

At this point if I unpack an assembly and debug, it I get the  
old code. The only way I have found around this is to run a  
clean build (and a clean build again in the tck), which means  
the turn around time to test a single fix to a tck bug is  
about 30 minutes.  Can someone please fix this?


-dain

Re: Having some trouble making a simple network...


Any progress on this?

--jason


On Oct 16, 2006, at 3:45 AM, Rob Davies wrote:

It'll take a week - or so  - simply because I've a lot of other  
stuff to do. It's not a major piece of work - but there's some  
fiddly things to change in the broker to support it - so we've just  
got to be careful not to break anything else.

On 16 Oct 2006, at 08:11, Jason Dillon wrote:

Any idea how easy this is going to be to implement?  Should it be  
fairly simple, or a major design change?


--jason


On Oct 15, 2006, at 11:38 PM, Rob Davies wrote:


Hi Jason,

I just created a jira for this: http://issues.apache.org/activemq/ 
browse/AMQ-979


On 16 Oct 2006, at 05:40, Jason Dillon wrote:

How then do I setup a hub/spoke network where the hub does not  
know about all of the spokes, and where the spokes may be behind  
firewalls, only allowing outgoing connections?  I had thought  
that having the remote broker define a network connection to the  
central broker would have been enough to connect them or bi- 
directional message flow.  But it sounds like that is not the  
case based on what you've said.


How should I configure the brokers assuming that the remote  
brokers maybe behind a firewall then?


--jason


On Oct 15, 2006, at 9:30 PM, Hiram Chirino wrote:


Hey Jason,

Not sure what those errors are about, but first off... if network
connections are only defined from the remote brokers to the  
central broker,
then only messages can sent to the central broker.  The central  
broker will

not be able to send message back to the remote broker.

Regards,
Hiram

On 10/15/06, Jason Dillon <[EMAIL PROTECTED]> wrote:


Hiya... I'm having some trouble making a simple broker network  
for
GBuild.  The idea was to embed a broker in each node, and then  
have
the slave nodes connect to the master node, so that all client  
code
will always be connected, and let activemq handle broker to  
broker

connectivity.

But, I can not seems to get it to work.

NOTE: This is not master/slave in terms of broker fail-over...  
its
just hub/spoke where the hub is the master and slave a  
spoke... just

for clarity on the bits below.

My central manager (which is what slave nodes connect to) has:

http://activemq.org/config/1.0";>
 class="org.springframework.beans.factory.config.PropertyPlacehold 
erConfi

gurer"/>
 
 
 
 
 
 
 
 
 
 
 
 


And my slave nodes have:

http://activemq.org/config/1.0";>
 class="org.springframework.beans.factory.config.PropertyPlacehold 
erConfi

gurer"/>
 
 
 
 
 
 
 
 
 
 
 
 
failover="true"/>
 
 


But... for some reason this is not working... and I don't know  
why.
Connectivity is good, as when I change the slave client's to  
connect
with "tcp://gbuild.org:16161" instead of "vm://localhost"  
everything

works fine.

But when the slaves use "vm://localhost" then they never see any
messages, and the master node complains with "No subscriptions
registered, will not dispatch message at this time" when new  
messages
are queued... though when the slave starts I do see it  
connecting to
gbuild.org:16161 and I see the master node create a consumer  
for the

client (and remove it when I stop the slave).

Not sure if this matters, but I also see these logs on the  
master node:



19:54:45,283 DEBUG [Service] Async error occurred:
java.lang.NullPointerException
java.lang.NullPointerException
 at
edu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap. 
hash

(ConcurrentHashMap.java:154)
 at
edu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap. 
get

(ConcurrentHashMap.java:759)
 at
org.apache.activemq.broker.AbstractConnection.processAddConnectio 
n

(AbstractConnection.java:616)
 at
org.apache.activemq.broker.jmx.ManagedTransportConnection.process 
AddConn

ection(ManagedTransportConnection.java:87)
 at org.apache.activemq.command.ConnectionInfo.visit
(ConnectionInfo.java:121)
 at org.apache.activemq.broker.AbstractConnection.service
(AbstractConnection.java:238)
 at org.apache.activemq.broker.TransportConnection 
$1.onCommand

(TransportConnection.java:63)
 at  
org.apache.activemq.transport.ResponseCorrelator.onCommand

(ResponseCorrelator.java:95)
 at  
org.apache.activemq.transport.TransportFilter.onCommand

(TransportFilter.java:65)
 at
org.apache.activemq.transport.WireFormatNegotiator.onCommand
(WireFormatNegotiator.java:133)
 at  
org.apache.activemq.transport.InactivityMonitor.onCommand

(InactivityMonitor.java:122)
 at  
org.apache.activemq.transport.TransportSupport.doConsume

(TransportSupport.java:84)
 at org.apache.activemq.transport.tcp.TcpTransport.run
(TcpTransport.java:136)
 at java.lang.Thread.run(Thread.java:595)
19:54:45,

Re: Assembly is caching old junk

I think I may have fixed this.  Now, when installing car modules into  
an assemblies repository, if the module already exists in the target  
repo, the config.ser.sha1 in the source and target repos is  
compared.  If they are the same, then the module is skipped (as was  
the behavior before), else the module is uninstalled from the target  
repo and then reinstalled.


Logging output has been trimmed, so it only shows what is being  
installed.  mvn -X shows full details about uninstalls and skipping.


Lemme know if you still see old artifacts getting cached in builds...  
there might still be a few more holes to patch, but this was the big  
one.


--jason


On Oct 25, 2006, at 2:04 PM, Jason Dillon wrote:

Hrm... this ends up reinstalling way to many modules.  I think we  
may need to encode a guid in the car which can be inspected to find  
out if an installed car is the same as a car to be installed... so  
that we can intelligently skip reinstalling a car... instead of  
blindly skipping or reinstalling.


--jason


On Oct 25, 2006, at 1:49 PM, Jason Dillon wrote:

Since people is still down I can't do much on gbuild, as there are  
too may deps missing, and it would take too long to build the deps  
or upload from my network...


I looked into this problem... may have a fix, though I'm not 100%  
sure this is all that needs to be done.  Looks like when we  
install configs into the assembly's target store, we skip modules  
that exist already.  I'm going to add a flag (default to true)  
which will trigger existing modules to be uninstalled first  
instead of just skipping them.


--jason


On Oct 19, 2006, at 4:34 PM, Dain Sundstrom wrote:

I don't understand how any of this stuff works.  All I know is  
when I run mvn install I don't get my source changes.  It would  
be nice to have a single command that does something reasonable.


-dain

On Oct 19, 2006, at 4:17 PM, David Jencks wrote:

It might help anyone trying to fix this if you can determine  
what is out of date in the assembly.  For instance,


-- assembly might pick up timestamped jars instead of locally  
build -SNAPSHOT jars

-- assembly might include old copies of jars

As workarounds for the first you can build offline after  
removing all g. timestamped jars from your m2 repo
for the second perhaps running mvn -o clean install in assembly  
would help.


Pesonally I try to only rebuild stuff that I've changed or  
depends on stuff I've changed



thanks
david jencks

On Oct 19, 2006, at 3:40 PM, Dain Sundstrom wrote:

The tck is moving very slow because when I make a simple change  
to a jar the final assembly is getting the old code.  For  
example, I do the following:


* changing some code (In my case naming)
* run "mvn install" from the geronimo/server/trunk

At this point if I unpack an assembly and debug, it I get the  
old code. The only way I have found around this is to run a  
clean build (and a clean build again in the tck), which means  
the turn around time to test a single fix to a tck bug is about  
30 minutes.  Can someone please fix this?


-dain

[jira] Created: (AMQ-1004) Upgrade to spring 2.0 and xbean 2.7

Upgrade to spring 2.0 and xbean 2.7
---

 Key: AMQ-1004
 URL: https://issues.apache.org/activemq/browse/AMQ-1004
 Project: ActiveMQ
  Issue Type: Improvement
Reporter: Hiram Chirino
 Assigned To: Hiram Chirino
 Fix For: 4.1




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Resolved: (AMQ-1004) Upgrade to spring 2.0 and xbean 2.7

 [ https://issues.apache.org/activemq/browse/AMQ-1004?page=all ]

Hiram Chirino resolved AMQ-1004.


Resolution: Fixed

fix in 467783

> Upgrade to spring 2.0 and xbean 2.7
> ---
>
> Key: AMQ-1004
> URL: https://issues.apache.org/activemq/browse/AMQ-1004
> Project: ActiveMQ
>  Issue Type: Improvement
>Reporter: Hiram Chirino
> Assigned To: Hiram Chirino
> Fix For: 4.1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (AMQ-826) LDAP based authorization support

2006-10-25 Thread Nikola Goran Cutura (JIRA)

[ 
https://issues.apache.org/activemq/browse/AMQ-826?page=comments#action_37283 ] 

Nikola Goran Cutura commented on AMQ-826:
-

Thanks for wildcard link. I did not implement '*', I'll finish it as well. Is 
it possible to have kind of regular expression like STOCKS.PRICE.NYSE.*BM ?

Regarding composite destinations, I would like your attention:

Union of ACLs means that if a user has privilege on at least one destination, 
all destinations will allow operation.
Intersection of ACLs means that if a user lacks privilege on at least one 
destination, no destination will allow operation.

I'll produce a test to verify this but my point is that current implementation 
of union is a security leak (if my understanding is correct). Suppose that a 
guest user wants to read from a destination not authorized for guests, say 
destination USERS.SECRET. A guest may create a destination in GUEST space with 
all necessary privileges, say GUEST.ALLOW. Now, the user creates a composite 
destination (GUEST.ALLOW, USERS.SECRET) and attempts an operation:

Case UNION: as operation is permitted on GUEST.ALLOW it is sufficient for 
composite destination; operation is performed on both destinations in spite of 
the fact that user is not authorized for the other.

Case INTERSECTION: as operation is NOT permitted on USERS.SECRET no operation 
is attempted on composite destination.

Now, maybe I got it wrong but the method 'getXACLs()' in 
DefaultAuthorizationMap is pretty clear - it adds all ACLs from all entries...

> LDAP based authorization support
> 
>
> Key: AMQ-826
> URL: https://issues.apache.org/activemq/browse/AMQ-826
> Project: ActiveMQ
>  Issue Type: Improvement
>Reporter: james strachan
> Assigned To: Nikola Goran Cutura
> Attachments: LdapAuth.zip
>
>
> Patch kindly added by ngcutura - discussion thread...
> http://www.nabble.com/LDAP-Authorization-tf1851705.html#a5344494

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Assembly is caching old junk

Hrm... this ends up reinstalling way to many modules.  I think we may  
need to encode a guid in the car which can be inspected to find out  
if an installed car is the same as a car to be installed... so that  
we can intelligently skip reinstalling a car... instead of blindly  
skipping or reinstalling.


--jason


On Oct 25, 2006, at 1:49 PM, Jason Dillon wrote:

Since people is still down I can't do much on gbuild, as there are  
too may deps missing, and it would take too long to build the deps  
or upload from my network...


I looked into this problem... may have a fix, though I'm not 100%  
sure this is all that needs to be done.  Looks like when we install  
configs into the assembly's target store, we skip modules that  
exist already.  I'm going to add a flag (default to true) which  
will trigger existing modules to be uninstalled first instead of  
just skipping them.


--jason


On Oct 19, 2006, at 4:34 PM, Dain Sundstrom wrote:

I don't understand how any of this stuff works.  All I know is  
when I run mvn install I don't get my source changes.  It would be  
nice to have a single command that does something reasonable.


-dain

On Oct 19, 2006, at 4:17 PM, David Jencks wrote:

It might help anyone trying to fix this if you can determine what  
is out of date in the assembly.  For instance,


-- assembly might pick up timestamped jars instead of locally  
build -SNAPSHOT jars

-- assembly might include old copies of jars

As workarounds for the first you can build offline after removing  
all g. timestamped jars from your m2 repo
for the second perhaps running mvn -o clean install in assembly  
would help.


Pesonally I try to only rebuild stuff that I've changed or  
depends on stuff I've changed



thanks
david jencks

On Oct 19, 2006, at 3:40 PM, Dain Sundstrom wrote:

The tck is moving very slow because when I make a simple change  
to a jar the final assembly is getting the old code.  For  
example, I do the following:


* changing some code (In my case naming)
* run "mvn install" from the geronimo/server/trunk

At this point if I unpack an assembly and debug, it I get the  
old code. The only way I have found around this is to run a  
clean build (and a clean build again in the tck), which means  
the turn around time to test a single fix to a tck bug is about  
30 minutes.  Can someone please fix this?


-dain

Re: Assembly is caching old junk

Since people is still down I can't do much on gbuild, as there are  
too may deps missing, and it would take too long to build the deps or  
upload from my network...


I looked into this problem... may have a fix, though I'm not 100%  
sure this is all that needs to be done.  Looks like when we install  
configs into the assembly's target store, we skip modules that exist  
already.  I'm going to add a flag (default to true) which will  
trigger existing modules to be uninstalled first instead of just  
skipping them.


--jason


On Oct 19, 2006, at 4:34 PM, Dain Sundstrom wrote:

I don't understand how any of this stuff works.  All I know is when  
I run mvn install I don't get my source changes.  It would be nice  
to have a single command that does something reasonable.


-dain

On Oct 19, 2006, at 4:17 PM, David Jencks wrote:

It might help anyone trying to fix this if you can determine what  
is out of date in the assembly.  For instance,


-- assembly might pick up timestamped jars instead of locally  
build -SNAPSHOT jars

-- assembly might include old copies of jars

As workarounds for the first you can build offline after removing  
all g. timestamped jars from your m2 repo
for the second perhaps running mvn -o clean install in assembly  
would help.


Pesonally I try to only rebuild stuff that I've changed or depends  
on stuff I've changed



thanks
david jencks

On Oct 19, 2006, at 3:40 PM, Dain Sundstrom wrote:

The tck is moving very slow because when I make a simple change  
to a jar the final assembly is getting the old code.  For  
example, I do the following:


* changing some code (In my case naming)
* run "mvn install" from the geronimo/server/trunk

At this point if I unpack an assembly and debug, it I get the old  
code. The only way I have found around this is to run a clean  
build (and a clean build again in the tck), which means the turn  
around time to test a single fix to a tck bug is about 30  
minutes.  Can someone please fix this?


-dain

[jira] Resolved: (AMQ-978) No Messaged delivery when mixing Perl stomp client Producer/Consumer and Java JMS Producer/Consumer

 [ https://issues.apache.org/activemq/browse/AMQ-978?page=all ]

Hiram Chirino resolved AMQ-978.
---

Fix Version/s: 4.1
   4.0.2
   Resolution: Fixed

> No Messaged delivery when mixing Perl stomp client Producer/Consumer and Java 
> JMS Producer/Consumer
> ---
>
> Key: AMQ-978
> URL: https://issues.apache.org/activemq/browse/AMQ-978
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Connector
> Environment: This problem seems platform independent: It happens in 
> Linux, Mac OSX, and Windows.
> Software Used: ActiveMQ 4.0, Java 5.0, JMS, Perl 5.8.7, Perl CPAN module 
> Net-Stomp-0.31
>Reporter: Sileshi Kassa
> Assigned To: Hiram Chirino
> Fix For: 4.1, 4.0.2
>
> Attachments: Net-Stomp-0.31-bytemessage-support.patch, 
> Net-Stomp-0.31-bytemessage-support.sileshi-patch, Publisher.pl, Subscriber.pl
>
>
> Facts: Perl Stomp client Producer and Consumer works fine
>Java JMS client Producer and Consumer works fine
> I have also used other Perl Stomp protocol implementation with no problem.
> The problem happens when I mix Java and Perl clients
> Scenario Test 1:
> A. Perl Stomp client Consumer
> B. Java JMS client Producer
> Scenario Test 2:
> A. Java JMS client Consumer
> B. Perl Stomp client Producer
> I have looked into it via Java JMX management jconsole, and it seems to me 
> there is a wall between
> the stomp server and default server. It the stomp server only passes messages 
> coming from stomp lients
> and default server also does the same.
> If this is truly the case, and this is by design, I will be very 
> disappointed. There should not be any wall.
> A message is message irrespective of its source and should be delivered to 
> any one that is listening
> on the same destination.
> I will attach the Perl clients testcases.
> For Java client,  a simple JMS client Producer and Consumer with the same 
> topic used as
> the perl side will do the job. The topic I used on the perl side: 
> "/topic/Test.CrossDelivery"
> and the Java side topic is  "Test.CrossDelivery"
> This problem is a show stopper for us.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (AMQ-1003) ConnectionDotFilePlugin cannot support broker with a non-localhost broker name

2006-10-25 Thread Adrian Co (JIRA)

 [ https://issues.apache.org/activemq/browse/AMQ-1003?page=all ]

Adrian Co updated AMQ-1003:
---

  Summary: ConnectionDotFilePlugin cannot support broker with a 
non-localhost broker name  (was: ConnectionDotFile)
Affects Version/s: 4.1
  Description: The ConnectionDotFilePlugin creates a BrokerViewMBean, 
but uses the localhost as its broker name. This prevents a broker with a 
different name from using it. (throws instancenotfound exception)
 Priority: Minor  (was: Major)

> ConnectionDotFilePlugin cannot support broker with a non-localhost broker name
> --
>
> Key: AMQ-1003
> URL: https://issues.apache.org/activemq/browse/AMQ-1003
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 4.1
>Reporter: Adrian Co
>Priority: Minor
>
> The ConnectionDotFilePlugin creates a BrokerViewMBean, but uses the localhost 
> as its broker name. This prevents a broker with a different name from using 
> it. (throws instancenotfound exception)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (AMQ-1003) ConnectionDotFile

2006-10-25 Thread Adrian Co (JIRA)

ConnectionDotFile
-

 Key: AMQ-1003
 URL: https://issues.apache.org/activemq/browse/AMQ-1003
 Project: ActiveMQ
  Issue Type: Bug
Reporter: Adrian Co




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: How to settup a plugin site?

2006-10-25 Thread Jacek Laskowski


On 10/25/06, Hernan Cunico <[EMAIL PROTECTED]> wrote:

Hi Jacek,
I'm planning to set up a plugin site for testing (and learning ;-) ) and 
remembered you mentioned working on some docs.
So I thought asking you first ;-) Did you have the chance to put some ideas 
together? At this point I have no much idea where to start so any help will be 
really useful.


Hi,

I have had no time working on it, so if you want to jump in and take
care of it, I'd be very grateful (and more likely to be finished soon
;-)). Thanks Hernan!

Jacek

--
Jacek Laskowski
http://www.jaceklaskowski.pl

Re: J2EE Management for JEE 5

2006-10-25 Thread Joe Bohn




Dain Sundstrom wrote:

JSR 77 is a weird spec in that is had very few Java APIs specified.   
The bulk of the spec described the names of fields and operations to  be 
exposed via JMX.  You should check if the Java APIs were updated  for 
Java5 generics.


JSR 77 is a weird spec!  As I was just looking at Chris' note and the 
spec I was surprised to see that most of the fundamental "interfaces" 
(like J2EEManagedObject and J2EEServer) are only defined within our 
implementation (modules/geronimo-management) and not included in our 
version of the management spec.  It seems that only the JSR 77 
statistics types are included as interfaces in our version of the spec.


This makes me wonder about the specs that I signed up for which are 
newly included in Java EE 5 (JSTL and Annotations).   Is it correct to 
assume that we should only include interface definitions from the specs 
if they were explicitly called out (such as with package names) or 
called out in an API section of the specification?   The JSTL spec 
includes an API section that includes not only interfaces but also 
abstract and other classes.  I was planning to just use Glassfish for 
JSTL and pick up their spec jar as part of the package rather than 
creating a Geronimo named spec jar.  Does that make sense?


The Annotations spec has package qualified annotation interfaces 
declared in the spec.  It appears that somebody (DBlevins?) has already 
created most of these in our specs tree.


Thanks,
Joe

Re: J2EE Management for JEE 5

2006-10-25 Thread Christopher M. Cardona


Anita,


I agree it would be nice to have these statistic interfaces implemented 
so we can provide performance data. IIRC somebody created a patch that 
uses ServletStats and I created an EJBModuleStats for the EJB Server 
portlet patch I submitted a few months ago. I’m not sure if this is even 
required for JEE 5. I assume it’s not because we didn’t implement it for 
J2EE 1.4. We can definitely put cycles to this but I personally wanted 
to work on the JEE 5 compliance issues first so we can make tiny steps 
to our JEE 5 goals. If you want to start working on JSR 77 performance 
monitoring you can go ahead.


Best wishes,
chris

anita kulshreshtha wrote:

Chris,
As you said, there is not much to do in upgrading JSR77 from 1.0 to 
1.1. However it would be nice to have some of the missing things 
implemented in 1.0. We could provide implementation of the following 
interfaces:

EJBStats.java
EntityBeanStats.java
JCAConnectionPoolStats.java
JCAConnectionStats.java
JCAStats.java
JDBCConnectionPoolStats.java
JDBCConnectionStats.java
JDBCStats.java
JMSConnectionStats.java
JMSConsumerStats.java
JMSEndpointStats.java
JMSProducerStats.java
JMSSessionStats.java
JMSStats.java
JTAStats.java
JVMStats.java
JavaMailStats.java
MessageDrivenBeanStats.java
ServletStats.java
SessionBeanStats.java
StatefulSessionBeanStats.java
StatelessSessionBeanStats.java
URLStats.java
Some of these interfaces might be already implemented. I am aware of 
JVMStatsImpl. In that case we should enable the 'stastisticsProvider' 
attribute of the ManagedObject.


Thanks,
Anita

*/"Christopher M. Cardona" <[EMAIL PROTECTED]>/* wrote:

I’m currently investigating what it would take to update our J2EE
Management (JSR 77) implementation for compliance with JEE 5 in
Geronimo. Looking at the changes between spec releases 1.0 (June 18,
2002) and 1.1 (June 22, 2006) there are 4 items that changed:

1. JSR77.4.2.1.3 will be/ changed from "sequence" to/
"sequenceNumber" -
This is just a typo error change.

2. JSR77.3.5.0.1 the deploymentDescriptor attribute must provide a
full
deployment descriptor based on any partial deployment descriptor plus
deployment annotations.

3. JSR77.9.1 J2EE Management CIM. The Managed Object Format (MOF) and
UML representation of the model are available from the Distributed
Management Task Force (DMTF) web site:
http://www.dmtf.org/standards/cim

4. JSR77.9.6 Appendix (CIM - Common Information Model) pages
190-214 removed

Here’s the link to the spec change log:
http://jcp.org/aboutJava/communityprocess/maintenance/jsr077/JSR77_MR.html

My first question is do we even have to update our current JSR 77
implementation to become JEE 5 compliant. If the spec changes are
all we
need to consider then it looks like only item 2 needs some attention
since item 1 is just a typo error correction and items 3 and 4 are
related to CIM which we didn’t implement. I’m not even sure if we
need
to do anything with item 2 like checking for deployment descriptor
value. Are there any other changes that I need to consider? Please
let
me know if I am missing anything. Any suggestions, ideas, and
concerns
are welcome.

Thanks,
chris



How low will we go? Check out Yahoo! Messenger’s low PC-to-Phone call 
rates.

[jira] Created: (AMQ-1002) org.apache.activemq.spring.SpringTest.testSenderWithSpringXmlUsingSpring2NamespacesWithEmbeddedBrokerConfiguredViaXml

org.apache.activemq.spring.SpringTest.testSenderWithSpringXmlUsingSpring2NamespacesWithEmbeddedBrokerConfiguredViaXml
-

 Key: AMQ-1002
 URL: https://issues.apache.org/activemq/browse/AMQ-1002
 Project: ActiveMQ
  Issue Type: Test
Reporter: Hiram Chirino
 Fix For: 4.1


Upgrading to spring 2.0 broker this test.  Commenting out till we can fix it.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [discussion] openejb-itests in testsuite

2006-10-25 Thread David Blevins

Great, I'll be looking forward to it.

-David

On Oct 23, 2006, at 9:36 PM, Prasad Kashyap wrote:

Thanx David. I shall try to put it in a sandbox if I can, or else send
you a a patch.

Cheers
Prasad

On 10/23/06, David Blevins <[EMAIL PROTECTED]> wrote:

On Oct 23, 2006, at 2:34 PM, Prasad Kashyap wrote:

> I have migrated the openejb-itests module to m2 with the  
intention of
> using it for G's testsuite.  The junit test code will have to go  
under

> the ejbcontainer-testsuite under the testsuite framework
> (geronimo/testsuite).

I don't know which approach would make sense or if there is some
middle ground.  You have a copy of this migrated code somewhere I
could look at/try out?

If we did #2 it'd obviously be a copy as OpenEJB 3 runs those tests
about 7 times during an average build and another 5 more times on a
build with assemblies.

-David

> The beans and the ejub jars can go just about anywhere.  So I'd  
like

> to solicit the suggestion of openejb and geronimo folks on where we
> should place them
>
> 1) Leave them where they are under openejb2/modules/openejb-itests.
> Get help from openejb commiters to get this commited. Unlike in
> previous G releases, this module would now only build the ejb  
jars. No

> tests would actually run here.
>
> 2) Move/copy the ejbs to some place under testsuite and create the
> jars there. This will keep the ejbs and the tests together.  
Since the
> moduleId (configId) in the plans should match the m2  
artifactItem id

> (g:a:v:t), the moduleId in the ejb plans would then become
> o.a.g.testsuite.*
>
>
> Apart from this decision, other things that need to resolved  
before we

> put this code in are
>
> http://issues.apache.org/jira/browse/OPENEJB-288
> http://www.mail-archive.com/dev@geronimo.apache.org/msg34995.html
>
>
> Cheers
> Prasad
>

Re: J2EE Management for JEE 5


On Oct 24, 2006, at 10:45 PM, Christopher M. Cardona wrote:

2. JSR77.3.5.0.1 the deploymentDescriptor attribute must provide a  
full deployment descriptor based on any partial deployment  
descriptor plus deployment annotations.


That doesn't sound like it will be easy.  Do they mean that you must  
build a full deployment descriptor backwards out of the annotations?


My first question is do we even have to update our current JSR 77  
implementation to become JEE 5 compliant.


JSR 77 is a weird spec in that is had very few Java APIs specified.   
The bulk of the spec described the names of fields and operations to  
be exposed via JMX.  You should check if the Java APIs were updated  
for Java5 generics.


-dain

Re: More tomcat questions?

2006-10-25 Thread anita kulshreshtha

Not yet. I was hoping to avoid that.. ;-)ThanksAnitaJeff Genender <[EMAIL PROTECTED]> wrote: How/Who is setting the protocol to 1.0?  Did you step through the codeto see where its getting set?Jeffanita kulshreshtha wrote:> Jeff,>   I am attaching a file. Please take a look at the 'protocol' > shown  by RequestProcessor. The protocol is set to HTTP/1.0, even though> the connectors are using 1.1! Could this explain all the 0' s in the> statistics fields? This used to work correctly in TC 5.5.12. I am trying> to figure out why all the statistics are zeros.> > thanks> Anita> > > Yahoo! Messenger with Voice. Make PC-to-Phone Calls> > to the US (and 30+ countries) for 2¢/min or less. 
		Stay in the know. Pulse on the new Yahoo.com.  Check it out.

Chris, As you said, there is not much to do in upgrading JSR77 from 1.0 to 1.1. However it would be nice to have some of the missing things implemented in 1.0. We could provide implementation of the following interfaces:EJBStats.javaEntityBeanStats.java JCAConnectionPoolStats.javaJCAConnectionStats.java JCAStats.javaJDBCConnectionPoolStats.java JDBCConnectionStats.javaJDBCStats.java JMSConnectionStats.javaJMSConsumerStats.java JMSEndpointStats.javaJMSProducerStats.java JMSSessionStats.javaJMSStats.java
JTAStats.javaJVMStats.java JavaMailStats.javaMessageDrivenBeanStats.java ServletStats.java SessionBeanStats.javaStatefulSessionBeanStats.java StatelessSessionBeanStats.java URLStats.java Some of these interfaces might be already implemented. I am aware of JVMStatsImpl. In that case we should enable the 'stastisticsProvider' attribute of the ManagedObject. Thanks,Anita"Christopher M. Cardona" <[EMAIL PROTECTED]> wrote: Im currently investigating what it would take to update our J2EE Management (JSR
77) implementation for compliance with JEE 5 in Geronimo. Looking at the changes between spec releases 1.0 (June 18, 2002) and 1.1 (June 22, 2006) there are 4 items that changed:1. JSR77.4.2.1.3 will be/ changed from "sequence" to/ "sequenceNumber" - This is just a typo error change.2. JSR77.3.5.0.1 the deploymentDescriptor attribute must provide a full deployment descriptor based on any partial deployment descriptor plus deployment annotations.3. JSR77.9.1 J2EE Management CIM. The Managed Object Format (MOF) and UML representation of the model are available from the Distributed Management Task Force (DMTF) web site: http://www.dmtf.org/standards/cim4. JSR77.9.6 Appendix (CIM - Common Information Model) pages 190-214 removedHeres the link to the spec change log: http://jcp.org/aboutJava/communityprocess/maintenance/jsr077/JSR77_MR.htmlMy first question is do we even have to update our current
JSR 77 implementation to become JEE 5 compliant. If the spec changes are all we need to consider then it looks like only item 2 needs some attention since item 1 is just a typo error correction and items 3 and 4 are related to CIM which we didnt implement. Im not even sure if we need to do anything with item 2 like checking for deployment descriptor value. Are there any other changes that I need to consider? Please let me know if I am missing anything. Any suggestions, ideas, and concerns are welcome.Thanks,chris
How low will we go? Check out Yahoo! Messengers low PC-to-Phone call rates.

[jira] Resolved: (AMQ-1001) Allow the openwire value cache size to be configurable.

 [ https://issues.apache.org/activemq/browse/AMQ-1001?page=all ]

Hiram Chirino resolved AMQ-1001.


Resolution: Fixed

Added in revision 467676 in trunk

> Allow the openwire value cache size to be configurable.
> ---
>
> Key: AMQ-1001
> URL: https://issues.apache.org/activemq/browse/AMQ-1001
> Project: ActiveMQ
>  Issue Type: New Feature
>Reporter: Hiram Chirino
> Assigned To: Hiram Chirino
> Fix For: 4.1
>
>
> This means that the cache size needs to be a negociated option between the 
> client and broker.  We should also default the cache size to be much smaller 
> like 1024 since every connection was using too much memory for cached objects.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (AMQ-1001) Allow the openwire value cache size to be configurable.

Allow the openwire value cache size to be configurable.
---

 Key: AMQ-1001
 URL: https://issues.apache.org/activemq/browse/AMQ-1001
 Project: ActiveMQ
  Issue Type: New Feature
Reporter: Hiram Chirino
 Assigned To: Hiram Chirino
 Fix For: 4.1


This means that the cache size needs to be a negociated option between the 
client and broker.  We should also default the cache size to be much smaller 
like 1024 since every connection was using too much memory for cached objects.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: How to settup a plugin site?

2006-10-25 Thread Hernan Cunico


Hi Jacek,
I'm planning to set up a plugin site for testing (and learning ;-) ) and remembered you mentioned working on some docs. 
So I thought asking you first ;-) Did you have the chance to put some ideas together? At this point I have no much idea where to start so any help will be really useful.


PS: not sure how stable the @apache.org dist lists are with the data moved so, 
just in case, I'm CCing you directly.

Cheers!
Hernan

Jacek Laskowski wrote:

On 10/9/06, Aaron Mulder <[EMAIL PROTECTED]> wrote:


Just like a Maven 2 repo, except with a geronimo-plugins.xml in the
root directory.  The only files that are actually used by the current
plugin installer are the actual archives in question, the
maven-metadata.xml files that list the available versions for each
artifact, and the geronimo-plugins.xml in the root.  Note that many
plugins require separate JARs, which can either be on the same site or
loaded from a secondary repo like ibiblio, but for versionless
dependencies it's going to take the most recent version of the
artifact in question from the first site that has any matching version
at all.


Is there a documentation page for it? If not, I'd like to create one,
but I wonder where it should go.

Jacek

[jira] Commented: (AMQ-826) LDAP based authorization support

[ 
https://issues.apache.org/activemq/browse/AMQ-826?page=comments#action_37281 ] 

james strachan commented on AMQ-826:


1. union is probably more appropriate. If the user tries to send to 5 
destinations and one of them is not available, it should generate an error and 
fail rather than silently just sending to the ones it can etc

2. Yes. > acts as a recursive match to any depth.

http://incubator.apache.org/activemq/wildcards.html

> LDAP based authorization support
> 
>
> Key: AMQ-826
> URL: https://issues.apache.org/activemq/browse/AMQ-826
> Project: ActiveMQ
>  Issue Type: Improvement
>Reporter: james strachan
> Assigned To: Nikola Goran Cutura
> Attachments: LdapAuth.zip
>
>
> Patch kindly added by ngcutura - discussion thread...
> http://www.nabble.com/LDAP-Authorization-tf1851705.html#a5344494

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (AMQ-992) MySQL doesn't honor lock in JDBC Master Slave configuration?

[ 
https://issues.apache.org/activemq/browse/AMQ-992?page=comments#action_37280 ] 

james strachan commented on AMQ-992:


I wonder if some SQL statement like the following works for MysQL...

LOCK TABLE foo IN ACCESS EXCLUSIVE MODE;

> MySQL doesn't honor lock in JDBC Master Slave configuration?
> 
>
> Key: AMQ-992
> URL: https://issues.apache.org/activemq/browse/AMQ-992
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 4.1
> Environment: RHEL 4
> MySQL 4.x, 5.x
> mysql-ab_jdbc_driver
>Reporter: Steven Lotito
> Attachments: mysql_obtain_lock.txt
>
>
> I have been attempting to get the new 4.1 JDBC Master Slave configuration 
> working with MySQL.
> The log from the first broker to start up states:
> 2006-10-18 09:35:08,558 [main   ] INFO  DefaultDatabaseLocker 
>  - Attempting to acquire the exclusive lock to become the Master broker
> 2006-10-18 09:35:08,559 [main   ] INFO  DefaultDatabaseLocker 
>  - Becoming the master on dataSource: [EMAIL PROTECTED]
> The 2nd broker to start up has an identical message and both brokers listen 
> for connections.
> The 2nd broker should be waiting for the lock and NOT accepting connections, 
> if I understand http://www.activemq.org/site/jdbc-master-slave.html 
> correctly...
> Oracle exhibits the expected behavior:
> When running the exact same configuration (except using an Oracle 
> datasource), the first broker has the same log message as above,  while the 
> 2nd broker halts at the "Attempting to acquire the exclusive lock to become 
> the Master broker" message until I fail the master.  Then it becomes the 
> master.
> Is this a known issue?  I was able to replicate it using both MySql 4 and 5 
> (trying both the MySQL Connector/J 3.1 and MySQL Connector/J 5.0 drivers)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Resolved: (AMQ-931) NMS test fails against trunk version of server

 [ https://issues.apache.org/activemq/browse/AMQ-931?page=all ]

james strachan resolved AMQ-931.


Fix Version/s: 4.1
   Resolution: Fixed

Things are working fine for me with the current trunk. I wonder if the bug has 
been fixed (we've been applying quite a few patches to NMS recently).

Let us know if you still have problems and we can reopen this issue

> NMS test fails against trunk version of server
> --
>
> Key: AMQ-931
> URL: https://issues.apache.org/activemq/browse/AMQ-931
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: NMS (C# client)
> Environment: Gentoo Linux EM64T, Mono 1.1.17, AMQ SVN
>Reporter: Adam Wendt
> Fix For: 4.1
>
>
> When running the test case against svn version of broker server the server 
> generates this error:
> Exception in thread "ActiveMQ Transport: tcp:///127.0.0.1:36117" 
> java.lang.IllegalArgumentException: Invalid version: 0, could not load 
> org.apache.activemq.openwire.v0.MarshallerFactory
> at 
> org.apache.activemq.openwire.OpenWireFormat.setVersion(OpenWireFormat.java:328)
> at 
> org.apache.activemq.openwire.OpenWireFormat.renegotiateWireFormat(OpenWireFormat.java:568)
> at 
> org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:110)
> at 
> org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:123)
> at 
> org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:88)
> at 
> org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:129)
> at java.lang.Thread.run(Thread.java:595)
> The C# test runs fine against 4.0.1 or 4.0.2RC3 server

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (AMQ-992) MySQL doesn't honor lock in JDBC Master Slave configuration?