mod_cluster Prototype Screens

Stefan Negrea snegrea at redhat.com
Thu Jul 7 14:11:34 UTC 2011


Minimizing the resource names for contexts is a good idea. I will drop the word "Context". However, the host is very important. In a normal production environment with a couple of app servers, one would have a couple of hosts available for configuration. My test environment is fairly small (the reason why you see only localhost). This plugin will control the entire mod_cluster configuration not just the configuration for the current JBoss server (where the mod_cluster module was detected).

I think of having the resource names follow this format: "[host=testhost, path=/testapp]" (dropped "Context", rearranged host and path). The host should be first because it should be fairly short; this will also help with sorting/grouping/seeing resources that belong to a single host. 

Thanks for your suggestions :)

Thank you,
Stefan Negrea

Software Engineer

----- Original Message -----
> From: "John Mazzitelli" <mazz at redhat.com>
> To: rhq-devel at lists.fedorahosted.org
> Sent: Wednesday, July 6, 2011 4:22:17 PM
> Subject: Re: mod_cluster Prototype Screens
> They look good to me. Nice job.
> 
> One suggestion - the resource names could probably be shortened. For
> one, you don't need the word "Context" in them. Also, you might be
> able
> to just use the path, no? The resource names can be short, because now
> we have disambiguation tooltips in most of our UI views, so people can
> hover over them and see the hierarchy (i.e. see what their parent is).
> So perhaps your names can just be in the form "/jbossws", I'm not sure
> you'd even need hostname. Several months ago, we actually went through
> and shrunk all our resource names down to the minimum (but still tried
> to make them relatively unique) and we rely on the disambigutation
> columns in the UI to help discern further the identity.
> 
> Note that, one neat thing here is, since each webapp context is a
> separate resource, but of the same resource type, you can create
> groups
> of them in order to perform group operations.
> 
> for example, suppose you have three contexts, "/", "/webapp1", and
> "/webappTWO". You can create a group with "/" and "/webapp1", perform
> a
> group operation "disable webapp" on that group, and you would be
> disabling just those contexts, leaving the third, /webappTWO, as-is.
> 
> On 07/06/2011 05:07 PM, Stefan Negrea wrote:
> > Hello Everybody,
> >
> > I uploaded a couple of screenshots for the mod_cluster plugin
> > prototype. During yesterday's design review meeting there were some
> > concerns regarding the user interface/presentation of webapp
> > contexts. mazz had a great suggestion to treat every webapp as
> > sub-service to the main mod_cluster service.
> >
> > http://www.rhq-project.org/display/RHQ/Design+-+mod_cluster#Design-mod_cluster-PrototypeScreens
> >
> > As you can see, each webapp context is a sub-service of main
> > mod_cluster service (on the left hand inventory tree). The name of
> > each sub-service is very descriptive (with path and host). Users can
> > enable/disable/stop webapp contexts from the Operations tab of each
> > sub-service. Global operations (eg. Reset the node) are available
> > only through mod_cluster Operations tab. In the current version of
> > mod_cluster, all the configuration settings are global (eg. Sticky
> > Sessions) so only the main service has a Configuration tab.
> >
> > How does this look? Is a "webapp context" still confusing after
> > seeing these screenshots? Any other suggestions on how to
> > organize/structure the UI?
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel


More information about the rhq-devel mailing list