Managing JBoss 7: Screenshots

To add some meat to the discussion, here are some recent screenshots of the current web interface. It does use a very reduced look&feel at this stage, that allows us to focus on the tasks at hand, without getting distracted too much. In the next iteration we'll look into adding some proper styles, with the help of our design friends from jboss.org.

Server Groups

Deployments (associated with server group)

Server Configuration (on a host)



Server Instances (on a host)

Managing JBoss 7: A task oriented approach

It's been several weeks now, since we started working on the management web interface for JBoss 7. Time to outline some of the general ideas and concepts the console is build on. If you are not familiar with domain management approach that has been introduced in 7.0, you should make yourself familiar with it before reading any further.

Conceptually the domain model consists of three different levels, that we tried to reflect within the user interface: Configuration profiles, server groups and host specific settings.



If you think of these levels as being layered atop of each other, then Profiles would be the bottom most configuration level that acts as a blueprint for the layers atop of it. Profiles consist of subsystem specific settings (i.e. JCA, TX, etc) and are referenced by Server Groups.

Server Groups on the other hand specify configuration properties for a set of Servers that run on different Hosts.

A Host is the top most and most detailed level. It runs Server Instances that belong to a particular Server Group.
While there are numerous ways to organize the information accessible through the web interface, we used a few simple questions to guide our decisions:

- "What are the primary tasks?"

- "At what frequency to these task occur?"

- "What's the impact on related configuration elements?"

The primary tasks already seem to be represented by the different levels described above: Changes to and requests of host specific information is something we expect to occur quiet regularly. This does cover use cases like starting server instances and requesting runtime state information (i.e. metrics).

Creation and modification of Server Groups will probably happen less often, except one specific use case, which is application deployment. Deployments are associated with server groups.

The least likely changes are going to happen on the profile level. I.e the modification of a thread pool size is something you probably wont do very often.

The outermost categorization looks as follows:

Now while this coarse grained organization nicely groups the primary tasks and allows you to focus on the goal you want to achieve, it doesn't give you any clues which configuration properties are inherited from lower levels. Some elements can be specified on a lower and be replaced on higher level (i.e. System Properties in profiles and server groups).

This problem has two sides: On the one hand you need to know where an inherited property comes from in order to change it, on the other hand need to know what impact a modification might have on higher levels (Think of a JVM property on the profile level that impacts all server groups).

This problem isn't solved yet. We are still working on visual distinction that allows you to clearly identify the source level of a configuration property and cross reference it accordingly. It might look like this:

Call for participation

There are plenty of other related topics that we can talk about, but that's it for today. If you want to participate, I would suggest you take a look at the following resources and let us know to what degree the suggested categorization makes sense.

- DomainManagementModelDesign

- jboss_7_0 schema

Stay tuned, we keep you posted.

"The future is bright and the present compelling ..."

Dimitiris about the release of JBoss AS 6 and the work on AS 7:
http://jaxenter.com/jboss-as-6-0-0-final.1-34623.html

Export Mac OS Mail RSS URL's

Neat and simple:

pubsub --client com.apple.mail list | cut -f3 | sed -ne '3,$p'

JBoss Developer Conference Berlin

JUDCon Berlin - October 7-8, 2010
Boston was a smashing success. Now on to Berlin!

JUDCon, the JBoss User and Developer Conference, gives developers the unique opportunity to participate in deep dive sessions with JBoss Core Developers and other leaders the JBoss community. Code sessions, hackfests, beer and food... now that's a developer conference.

More here

GWT Compiler Options

Joseph from the RHQ team has written a good article on how the different compiler options (num workers, Xmx, Xms) affect the overall compilation time: http://josephmarques.wordpress.com/2010/07/30/gwt-compilation-performance/

JBoss One Day Talk

One Day, 14 sessions on two tracks. Get together with the experts and join us in Munich, 1. October 2010.
JBoss One Day Talk - From the community for the community.


From the web page:

"Die Konferenz für Java Frameworks & Enterprise Edition Technologien

Der JBoss OneDayTalk 2010 (organisiert vom JBUGM e.V.) ist eine ganztägige Konferenz, bei der sich alles um das Thema JBoss Technologien und Java Frameworks dreht. Experten aus den USA und Europa treffen am 01.10.2010 in München zusammen, um ihr Wissen, ihre Erfahrungen und ihre Ideen miteinander zu teilen und darüber zu diskutieren. JBoss Project Leads und Core Developers werden ebenso vertreten sein wie Mitglieder der JBoss Community, Softwarearchitekten und IT-Entscheider.

Erstklassige Sprecher und aktuelle Themen wie JAVA6, JAVA EE 6, Caching, Clustering, Cloud Computing,Wicket, BPM, BPMN, BPMS, BPEL, Rules, Web Services, Ruby-On-Rails, Auditing, Performance und Versioning persistenter Klassen garantieren eine erstklassige und spannende Veranstaltung. Dabei liegt der Fokus nicht nur auf der Theorie der vorgestellten Themen. Vielmehr wird es auch Erfolgsberichte aus "echten" Projekten geben, in denen sich die Technologien unter Alltagsbedingungen im Projektumfeld bewährt haben."