Oh, one other thing, since it crossed my mind. I know we exposed more "management
attributes" for Putnam, and we need to make sure the model incorporates all those
additions, plus make it intuitive to manage.
Andy
----- Original Message -----
From: "Brian Stansberry"
<brian.stansberry(a)redhat.com>
To: "Andrig Miller" <anmiller(a)redhat.com>
Cc: "Clebert Suconic" <csuconic(a)redhat.com>,
"jboss-as7-dev(a)lists.jboss.org Development"
<jboss-as7-dev(a)lists.jboss.org>
Sent: Wednesday, April 6, 2011 2:44:51 PM
Subject: Re: [jboss-as7-dev] HornetQ subsystems in AS 7
I don't see any technical reason they can't be combined; i.e. there's
nothing about the AS 7 architecture that says these need to be
separate
subsystems.
The basic issue is configuration. The xsds for the current 2
subsystems
were almostly 100% lifted from the hornetq-jms.xsd and
hornetq-configuration.xsd. Those two xsds both have a "queueType" but
the meaning is different. If we combine the two subsystems into one,
that means we combine the schemas and the management resource trees
and
we need to make sure it is very intuitive for users to understand what
it is they are configuring and how to configure commonly used things.
We need to do that whether or not we combine into a single subsystem,
since it's clearly not intuitive now.
On 4/6/11 3:20 PM, Andrig Miller wrote:
>
>
> ----- Original Message -----
>> From: "Clebert Suconic"<csuconic(a)redhat.com>
>> To: "Andrig Miller"<anmiller(a)redhat.com>
>> Cc: "Brian Stansberry"<brian.stansberry(a)redhat.com>,
>> "jboss-as7-dev(a)lists.jboss.org Development"
>> <jboss-as7-dev(a)lists.jboss.org>
>> Sent: Wednesday, April 6, 2011 2:17:15 PM
>> Subject: Re: [jboss-as7-dev] HornetQ subsystems in AS 7
>> Well... Topic subscriptions are just Queues.
>>
>> There are advantages of using the HornetQ API directly...
>> Especially
>> on Asynchronous ACKs.
>>
>> Although I don't understand exactly why you need a separate module
>> on
>> AS7 for this. This is just a simple POJO being accessed through the
>> classloader. (hornetq-core.jar, and hornetq-core-client.jar)
>>
>
> Yeah, I don't see why that would be necessary either. Using the core
> API directly is fine, and can be exposed in the module along with
> JMS.
>
> Andy
>
>>
>> On Apr 6, 2011, at 3:14 PM, Andrig Miller wrote:
>>
>>> Personal take on this, is that there shouldn't be two. The
>>> astonishment below about only have queue's and not topics is a
>>> direct result of this separation, because the implementation
>>> details
>>> underneath JMS, in terms of HornetQ, is that there are only
>>> queues,
>>> even though topics are fully support, but its still just a queue
>>> underneath.
>>>
>>> This is a problem in my mind.
>>>
>>> Andy
>>>
>>> ----- Original Message -----
>>>> From: "Brian Stansberry"<brian.stansberry(a)redhat.com>
>>>> To: "jboss-as7-dev(a)lists.jboss.org Development"
>>>> <jboss-as7-dev(a)lists.jboss.org>, "Clebert Suconic"
>>>> <csuconic(a)redhat.com>
>>>> Sent: Wednesday, April 6, 2011 1:15:04 PM
>>>> Subject: [jboss-as7-dev] HornetQ subsystems in AS 7
>>>> Copied below is a discussion we had today on #jboss-as7 in IRC
>>>> that
>>>> I'm
>>>> copying here to get input from the HQ folks.
>>>>
>>>> AS 7 currently has 2 HQ-related subsystems, "messaging" which
>>>> provides
>>>> core HQ, and "jms" which brings in JMS spec compliance. The
gist
>>>> of
>>>> the
>>>> discussion is 1) whether this separation is overly unintuitive
>>>> and
>>>> 2)
>>>> if
>>>> it's necessary, is the name "messaging" for the core HQ
subsystem
>>>> too
>>>> likely to lead users to assume it's where JMS topic/queue
>>>> creation
>>>> is
>>>> done.
>>>>
>>>> The conversation is below. It carried on after the following;
>>>> please
>>>> see
>>>>
http://echelog.matzon.dk/logs/browse/jboss-as7/1302040800 if you
>>>> are
>>>> interested.
>>>>
>>>> pilhuhn: Also I am astonished that Q s are present , but not
>>>> Topics
>>>> [1:52pm] bstansberry: pilhuhn: there are topics in the jms
>>>> subsystem
>>>> [1:53pm] bstansberry: the "messaging" subsystem is very
oriented
>>>> toward
>>>> core HornetQ
>>>> [1:54pm] bstansberry: Nihility: ^^^ reminds me of our discussion
>>>> w/
>>>> paul
>>>> re: the JGroups subsystem, where we decided it was silly to give
>>>> a
>>>> "generic" name to a subsystem that was not exposing a
standard
>>>> API
>>>> [1:55pm] bstansberry: same applies to subsystem=messaging
>>>> [1:55pm] pilhuhn: so Qs are in both? messaging and jms? feels
>>>> strange
>>>> [1:55pm] Nihility: bstansberry: makes sense
>>>> [1:55pm] Nihility: bstansberry: sort of
>>>> [1:55pm] Nihility: bstansberry: another example is subsystem=web
>>>> [1:56pm] Nihility: bstansberry: which is jboss web
>>>> [1:56pm] bstansberry: well, that at least is exposing the Servlet
>>>> spec
>>>> [1:56pm] dmlloyd: shared global bindings are a nasty little
>>>> problem
>>>> [1:56pm] Nihility: i think our goal should just be to have
>>>> subsystem
>>>> names
>>>> [1:56pm] Nihility: that are intuitive easy to understand
>>>> [1:57pm] Nihility: jgroups vs group-communication is basically
>>>> the
>>>> same
>>>> to me
>>>> [1:57pm] dmlloyd: jgroups is unambiguous and concise imo
>>>> [1:57pm] bstansberry: yes, that's decided
>>>> [1:57pm] Nihility: yes
>>>> [1:57pm] dmlloyd: hornetq should be hornetq
>>>> [1:57pm] Nihility: the reason for messaging and jms is different
>>>> [1:57pm] pilhuhn: I think it needs to be clear that for an
>>>> enduse,
>>>> that
>>>> he wants to have a jms/queue and not a messaging/queue when doing
>>>> jms
>>>> [1:58pm] dmlloyd: jms should be jms
>>>> [1:58pm] Nihility: they realy do have two subsystems
>>>> [1:58pm] dmlloyd: if there is such a generic notion
>>>> [1:58pm] bstansberry: right, so calling hornetq "messaging"
is
>>>> not
>>>> intuitive
>>>> [1:58pm] Nihility: they have this notion of a lightweight topic
>>>> [1:58pm] bstansberry: people will gravitate toward it
>>>> [1:59pm] pilhuhn: Yeah leightweight.. it will float in the clouds
>>>> [1:59pm] Nihility: and thats what they think is a real messaging
>>>> api
>>>> [1:59pm] pilhuhn: .oO( DId I win as BS-Bingo? )
>>>> [1:59pm] Nihility: jms is just something extra they do for the
>>>> spec
>>>> [1:59pm] Nihility: with extra requirements etc
>>>> [1:59pm] Nihility: so its like a higher level layer
>>>> [1:59pm] Nihility: so they have core messaging
>>>> [1:59pm] Nihility: and they have jms
>>>> [1:59pm] Nihility: and togheter thats hornetq
>>>> [1:59pm] bstansberry: good point
>>>> [2:00pm] bstansberry: ok, no JIRA, at least not from me
>>>> [2:01pm] bstansberry: instead, a dev list thread and the HQ
>>>> people
>>>> can
>>>> deal with it
>>>> [2:01pm] pilhuhn: The admin that wants to use a MessageDrivenBean
>>>> does
>>>> not really care about that separation
>>>> [2:02pm] Nihility: the separation is more because you can run hq
>>>> without
>>>> starting the jms services
>>>> [2:02pm] Nihility: and they have separate configuration
>>>> [2:02pm] pilhuhn: yep
>>>> [2:02pm] Nihility: although you could collapse the two
>>>> [2:02pm] Nihility: emuckenhuber and i debated that for awhile
>>>> [2:02pm] Nihility: we had a hard time deciding
>>>> [2:03pm] pilhuhn: What I want to express (and that targets rather
>>>> us
>>>> with JON and the console) is that for this said admin it needs to
>>>> be
>>>> totally clear that he wants to go to subsys/jms/queue
>>>>
>>>> --
>>>> Brian Stansberry
>>>> Principal Software Engineer
>>>> JBoss by Red Hat
>>>> _______________________________________________
>>>> jboss-as7-dev mailing list
>>>> jboss-as7-dev(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat