Hi Marnie, > > I'm a little out of my comfort zone in this area, but ... > > Not too keen to see the wrapping around AMQException subclassing being > changed at the moment. I think we are just starting to see some limitations > in the way that exception management back to clients from the broker works > and would prefer to hold off until we have a little more clarity.
I just wanted to clarify that I was talking purely here about the .NET client implementation, and not about changing anything at the broker level. I was kind of saying that from a user of the .NET client I think it would be more explicit if you could look directly at the actual exception type (i.e. catch an AMQAuthorizationException directly) instead of having to catch a generic AMQException and then look at what it contains in the InnerException. Notice that AMQAuthorizationException already inherits from AMQException so you could still catch a super AMQException if you wanted so that would not change. The issue here I'm bringing up is that we're basically returning at this point an AMQException with the message "unable to connect to broker" that wraps the underlying AMQAuthorizationException. That's what I meant when I said that a "generic" AMQException was being thrown instead of a more explicit subclass of it. > I know we have a JIRA relating to SSL but not aware of anything which > explains the authentication problem that you're seeing. Cool. Any pointers about where to explore a bit more the SSL support in the java broker/client? I'd love to check it out since I'm guessing that's another of those features as of yet missing from the .NET client :) Tomas Restrepo [EMAIL PROTECTED] http://www.winterdom.com/weblog/
