----- Original Message -----
From: "Clebert Suconic" <csuconic(a)redhat.com>
To: "Andrig Miller" <anmiller(a)redhat.com>
Cc: "jboss-as7-dev(a)lists.jboss.org Development"
<jboss-as7-dev(a)lists.jboss.org>, "Brian Stansberry"
<brian.stansberry(a)redhat.com>
Sent: Wednesday, April 6, 2011 10:24:41 PM
Subject: Re: [jboss-as7-dev] HornetQ subsystems in AS 7
When you say management, you're talking about the management module
through JMX, or in more general terms?
In AS 7, there is a management API that everything will use, including the console, and
that will sit on top of your API (whether JMX or other), at least that's the way I
understand it.
On Apr 6, 2011, at 5:09 PM, Andrig Miller wrote:
> Whether they are separate or together, the management has to be
> understandable by the average person. Most people aren't going to
> care about the underlying core API.
>
> Even in your analogy, the Hibernate guys recommend using the JPA
> API, not the underlying Hibernate stuff (which of course is starting
> to be one and the same).
>
> So, the real question is how do you make sure this thing can be
> managed without confusion, between the two.
>
> Andy
>
> ----- Original Message -----
>> From: "Clebert Suconic" <csuconic(a)redhat.com>
>> To: "Brian Stansberry" <brian.stansberry(a)redhat.com>
>> Cc: "Andrig Miller" <anmiller(a)redhat.com>,
>> "jboss-as7-dev(a)lists.jboss.org Development"
>> <jboss-as7-dev(a)lists.jboss.org>
>> Sent: Wednesday, April 6, 2011 3:45:51 PM
>> Subject: Re: [jboss-as7-dev] HornetQ subsystems in AS 7
>> Just making an analogy:
>>
>> JMS Wrapper <-> Core Api
>>
>> is analog as
>> JPA <-> Hibernate
>>
>> I don't see the JMS as another subsystem. That's a wrapper in top
>> of
>> HornetQ core. The add-ons are basically JNDI bindings and other
>> things
>> like that.
>>
>>
>> For the future of the project, and how message systems are
>> evolving, I
>> think it's better to separate JMS and Core. For instance we may
>> have
>> stomp clients, maybe AMQP some day... and etc.
>>
>> Who knows... JMS 2 is coming.. maybe we will need extra configs for
>> JMS2 based on the outcome of what's out of the JSR. (That's off
>> course
>> just a speculation since JMS2 JSR is still assembling the Expert
>> Group).