Don't see any template fields when adding a Queue
by Scott Stark
I'm trying to follow the recipe Ian describes in
https://jira.jboss.org/jira/browse/JBAS-6219, but when I get to the "Add
New" page I don't see any fields. Just hitting the save button fails
when a queue with a null name/jndi-name is created. The form section of
the page does not show any fields for input:
<form id="resourceConfigurationForm" name="resourceConfigurationForm"
method="post" action="/admin-console/secure/resourceInstanceConfig.seam"
enctype="application/x-www-form-urlencoded"
onsubmit="prepareInputsForSubmission(this)">
<input type="hidden" name="resourceConfigurationForm"
value="resourceConfigurationForm" />
<table class="buttons-table">
<tbody>
<tr>
<td class="button-cell"><input id="resourceConfigurationForm:saveButton"
type="submit" name="resourceConfigurationForm:saveButton" value="Save"
alt="Click to Save Changes" class="buttonmed" /></td>
<td><input
onclick="location.href='/admin-console/secure/summary.seam?path=-3%2FResources%2FJMS+Destinations%2FQueue&conversationId=12&conversationPropagation=end';
return false;" id="resourceConfigurationForm:cancelButton"
class="buttonmed" value="Cancel" type="button" /></td>
</tr>
</tbody>
</table>
<input type="hidden" name="javax.faces.ViewState"
id="javax.faces.ViewState" value="..."/>
</form>
The full page is attached. I'm on osx 10.5.6 running firefox version:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.6)
Gecko/2009011912 Firefox/3.0.6
17 years
Re: [jopr-dev] tomcat and agent security
by John Mazzitelli
I just checked in a third (but commented) Tomcat <Connector>. It can be uncommented by users if they need this capability.
The comments in server.xml tell you when you would might want to do this:
<!-- Provides a secure but un-authenticated https connector for browsers to use.
Uncomment this connector if all of the following are true:
1) the server-to-agent communications is secured via the sslservlet transport
2) the server-to-agent communications always require agents to authenticate themselves with certificates
3) you want to allow users' browsers to access the GUI via the https: protocol
4) you do not want to force users' browsers to authenticate themselves with certificates
-->
Just to be clear, by default, this connector doesn't exist and its port isn't open - out of box this connector will be commented out. You have to explictly turn it on by uncommenting it if you want it.
(BTW: I did test this scenario and it works - you can have two secure connectors where one requires cert auth and the other doesn't)
----- Original Message -----
From: "Heiko W.Rupp" <hwr(a)redhat.com>
To: "jopr-dev" <jopr-dev(a)lists.jboss.org>
Sent: Thursday, February 26, 2009 9:32:10 AM GMT -05:00 US/Canada Eastern
Subject: Re: [jopr-dev] tomcat and agent security
Am 25.02.2009 um 21:46 schrieb John Mazzitelli:
>
> I think this is a use-case where users are gonna want to use the
> sslsocket transport so agents can talk to a separate Jboss/Remoting
> port in the server that can perform SSL certificate checking but it
> leaves Tomcat alone so GUI users are not burdened with needing SSL
> certificate in their browsers.
Would an alternative to have 2 connectors with ssl enabled - one for
the agent and the other for the clients?
Or does tomcat have a restriction to 1 connector with ssl?
Heiko
--
Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei
Muenchen
Handelsregister: Amtsgericht Muenchen HRB 153243
Geschaeftsfuehrer: Brendan Lane, Charlie Peters, Michael Cunningham,
Werner Knoblich
_______________________________________________
jopr-dev mailing list
jopr-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jopr-dev
17 years
release dates / releases
by John Mazzitelli
In response to:
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=151247
can I ask someone (Greg? Joe?) to go through the Jopr JIRA (and RHQ Jira) and put in more realistic dates for the different versions. Right now, the dates are completely irrelevant and if you read that forum post, its confusing people.
Also - can I recommend that we consider releasing at least a beta soon? The community seems to be growing and I think it would be useful to get the new code in the hands of others to help test with - I suspect there are folks out there that would be willing to install a beta and check it out.
17 years
tomcat and agent security
by John Mazzitelli
Here's something that was brought to my attention when a customer was asking how to enable bi-directional SSL authentication between Jopr server and Jopr agent.
We are using the Tomcat connectors on ports 7080 and 7443 for browsers/GUI use and for incoming agent requests.
By default, the agent uses the "servlet" transport which means it sends HTTP requests to port 7080.
If you switch the agent to use the "sslservlet" transport, you tell it to send HTTPS requests to port 7443, which is configured in Tomcat to be the SSL connector.
What happens when you want the agents to authenticate themselves with the server via SSL certificates? Its easy - you configure Tomcat's SSL connector with the appropriate keystore/truststore settings so when Tomcat receives agent requests over 7443, it verifies the agent's certificate using the normal SSL handshaking (there are settings in rhq-server.properties to do this).
BUT! Because we are piggybacking on the Tomcat connector that browsers use to get to the UI, this means that now all users are required to install a certificate in their browser AND that certificate needs to be placed in the Tomcat truststore. Very few people (any?) would be willing to do this just so their Jopr users can access the GUI. They will just want browsers to access the UI via https: like 99% of all the other web apps out there.
I think this is a use-case where users are gonna want to use the sslsocket transport so agents can talk to a separate Jboss/Remoting port in the server that can perform SSL certificate checking but it leaves Tomcat alone so GUI users are not burdened with needing SSL certificate in their browsers.
I bring this up because I have to write up some documentation on this, and I thought I'd solicit comments on this.
17 years
new UI look
by John Mazzitelli
First, I love the new fonts - much cleaner, very easily readable.
Second, I didn't think I would, but I'm OK with the grey MICA icons.
Third, I do not like the "Configure" MICA icon - it looks too similar to the "Service" resource icon (the sprocket). I suggest the "C" MICA icon should be a wrench.
Forth, the "inventory" icon is blah - I'd much prefer the tag. That dog-ear'ed piece of paper icon can mean 100 different things (in fact, its what I had for content before :)
Fifth, the package MICA icon is blah too - though, I'm not sure how easy it is to build a 3-D box in 13x13 pixels. I'm more OK with this than I am the inventory icon.
Sixth, I really wish we had some way of explaining the difference between the "group" icon and the "folder" icon in the left-nav (e.g. group vs. subcategory). I can easily see this be a point of confusion for people.
17 years
mica icons
by John Mazzitelli
Here's some ideas on a new set of MICA icon (so they are true icons, not letters). We can resize these, make them bigger for the tabs themselves (there might already be larger sizes of these).
Inventory/Monitor/Events/Config/Alerts/Operations/Packages:
17 years
order of tabs
by John Mazzitelli
I'm looking at the tabs in the resource view, and I'm thinking, why are they ordered they way they are?
summary | monitor | events | inventory | configure | operations | alert
I think we need to push those permanent, required tabs to the left, and the optional ones on the right.
I also think inventory should be to the far left (well, next to summary now that we have that):
summary | inventory | monitor | alerts | configure | operations | events | packages
We should also order the MICA icons to match the order of the tabs.
17 years
Re: [Jopr] - JBoss Messaging custom queue's not being discovered
by Heiko W.Rupp
Hello,
> I would like to monitor my JBoss Messaging message queue's. These
> queue's have custome JMX domain names. For example:
> com.docmorris.log.destination:name=log.esb.dlq,service=Queue
Indeed - They are discovered if they follow this naming scheme:
jboss.messaging.destination:service=Queue,name=%name%|
jboss.esb.*:service=Queue,name=%name%
(same for topic)
You can edit the plugin-descriptor for the JbossAS plugin and add your
pattern there - something like
jboss.messaging.destination:service=Queue,name=%name%|
jboss.esb.*:service=Queue,name=%name%|
com.docmorris.*:service=Queue,name=%name%
We can't just discoveri .*:service=Queue,name=%name% --as this will
clash with e.g.
resources from JBossMQ
--
Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei
Muenchen
Handelsregister: Amtsgericht Muenchen HRB 153243
Geschaeftsfuehrer: Brendan Lane, Charlie Peters, Michael Cunningham,
Werner Knoblich
17 years
Logging ...
by Heiko W.Rupp
Hi,
this email is just for the records and summarizes a discussion we had
lately:
our server and agent are logging at INFO level by default.
So all log.debug() is not hitting the logfile, but still the arguments
of log.debug() are
evaluated(*) even if the logger decides later on to throw them away
and new objects
might be created, which hits performance and stresses the garbage
collector.
Can we please (in the future) guard those log.debug() calls by if
(log.isDebugEnabled()) (or equivalent)
to save on evaluation of the argument, calling the logger and object
creation?
One needs still to be careful to do the log.isDebugEnabled() not
within tight loops, but outside
Example:
boolean shouldLog = log.isDebugEnabled();
for (int i = 0; i< 1000; i++) {
....
if (shouldLog)
log.debug( i + ... );
}
*) This might be no big deal for log.debug("hello world"), but
sometimes stuff that
calls into the database - and actually, that can be triggered by
a simple toString() call, if the implementation of toString() also
shows other
Entities hanging on the the one to print out.
Or in the past (different employer) that was doing some complex
calculation
over a network of connected entities - here everything was in Memory,
but all
the objects where BigDecimal and just logging created dozens of Objects.
Running with and without log.debug() made a factor of 2-3 in the
runtime of
the routine.
Heiko
--
Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei
Muenchen
Handelsregister: Amtsgericht Muenchen HRB 153243
Geschaeftsfuehrer: Brendan Lane, Charlie Peters, Michael Cunningham,
Werner Knoblich
17 years
request for comments - timeline view
by Joseph Marques
as of last night, the events tab will now only show up when the resource
(or compatible group) you're viewing supports the events. the result of
this, in short, is that we need to find a new home for the timeline view.
if you go to the events tab for some JBAS instance in inventory, you'll
see the timeline subtab. the problem lies in the fact that the timeline
view displays data from several different subsystems: availability
history, logged event, executed operations, triggered alerts. as a
result, if we kept timeline under the event tab, you could only get to
it if your resource supported events...but then you lose the ability to
view the other types of data this composite view can display.
so, the question is...where should this view go? some options so far:
1) as it's own tab for a resource (alongside monitor, events,
configuration, operation, alerts, content)
2) as a subsystem view (alongside config updates, problem resources, etc
at /rhq/subsystem/layout/main.xhtml path)
for option #1, the fit is rather natural, but there is some concern that
"timeline" doesn't correctly implement what a resource tab is attempting
to model (a resource-wise view of each subsystem). while i agree with
that assessment (because timeline is a composite view) i nonetheless
think this is a good target.
for option #2, the fit is less than ideal, but it still might have
value. the problems i see here is that we would still need a way of
selecting a resource before the timeline view could be displayed.
subsystem views are supposed to be cross-cutting views (and, in that
respect, it's similar to timeline) but subsystem views are single
subsystems across all resources in the system (whereas timeline is
multiple subsystems across a single resource).
clearly, the timeline view lies somewhere in the middle. so, what do
other people think? should it be a new tab on a resource, or should it
be a subsystem view that allows you to select different resources?
-joseph
17 years