David, Thanks for your help ... see comments below.
David Jencks wrote:
On Aug 5, 2005, at 6:32 AM, Joe Bohn wrote:
Well I'm still feeling my way around the web console code, but it
looks to me like they are expecting users to add more queues to the
org/apache/geronimo/SystemJMS config.
I don't think this is possible yet, although I think aaron is working
on a way to make it possible shortly. I believe that each new queue
is currently added to a new configuration.
You're right. I was mistakenly looking at the creation of new JMS
Connection Factories which does in fact create new factories (and
therefore configs) with a parent-id of org/apache/geronmio/SystemJMS.
Of course this might not work now either without Aaron's changes ... but
it looks like that is what the code is assuming. The creation of new
queues (and therefore configs) is in fact based off a different parent
(something like org/apache/geronimo/Console) ... but this does seem to
be working.
What should be be encouraging them to do ... that's the harder
question. I'll look for somebody else to answer that one. :-)
Allowing, yes, at least for "mutable" configurations. Encouraging,
maybe.
However, I'm looking at a problem that may end up being related to
(or affected by) the configuration.
The Web Console includes capabilities to manage JMS connection
factories and destinations (adding/removing queues and topics).
However, the portlet to manage the factories is currently failing
with an exception because it assumes that there is a "state"
attribute on the each factory GBean and this attribute doesn't exist
on the DefaultActiveMQConnectionFactory.
I believe this is due to the recent removal of the jsr-77 state
manageable and similar attributes from the base gbean wrapper object.
I think the intent was to move them to all gbeans that were exposed in
jsr-77. Apparently not all of this proposal was implemented, which
may possibly affect our compliance with the jsr-77 portion of the tck.
I finally figured out that the state of a GBean is now maintained for
each GBean by the kernel. Therefore, rather than getting the "state"
attribute from the GBean I must call kernel.getGBeanState() for the
particular GBean. I guess that means that it was implemented but just
not reflected in the Console sandbox yet.
thanks
david jencks
So I wonder if the portlet is in error looking for the wrong
attribute or the factory GBean is in error for not defining the
attribute. Of course, if we remove the queues and factory defined
in SystemJMS then this eliminates the problem (at least on the
DefaultActionMQConnectionFactory).
- Joe
[EMAIL PROTECTED] wrote:
The org/apache/geronimo/SystemJMS config defines an ActiveMQ
resource adapter ( and the DefaultActiveMQConnectionFactory ) ,
MDBTransferBeanOutQueue and SendReceiveQueue admin objects.
Should the two queues be removed ( I assume they were there for
testing in the past)?
Are we expecting users of the web console ( I haven't played with
yet) adding more queues to the org/apache/geronimo/SystemJMS config,
or should we be encouraging them to use their own config?
If we aren't expecting users to be able to add more queues to the
org/apache/geronimo/SystemJMS config, then should the
org/apache/geronimo/SystemJMS config be removed from the config.list
and replaced with org/apache/geronimo/ActiveMQServer?
John
This e-mail message and any attachments may contain confidential,
proprietary or non-public information. This information is intended
solely for the designated recipient(s). If an addressing or
transmission error has misdirected this e-mail, please notify the
sender immediately and destroy this e-mail. Any review,
dissemination, use or reliance upon this information by unintended
recipients is prohibited. Any opinions expressed in this e-mail are
those of the author personally.
--
Joe Bohn
[EMAIL PROTECTED]
"He is no fool who gives what he cannot keep, to gain what he cannot
lose." -- Jim Elliot
--
Joe Bohn
[EMAIL PROTECTED]
"He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
