Nitro on IOS 4.3
15 Mar 2011Why is Nitro disabled in UIWebView and full screen web apps on IOS 4.3?
Read more about it here
Why is Nitro disabled in UIWebView and full screen web apps on IOS 4.3?
Read more about it here
You want to contribute to the management web interface for JBoss ? Then this should get you going.
Codebase
Everything is hosted at github, The best way is to create a fork of either one of the codebases listed below and work on that one.
The console it self is developed using the Google Web Toolkit. You would need to make yourself familiar with the basics before we et going. The GWT SDK will be installed as part of the maven build. No need to fetch it on it’s own. If you plan to work with Eclipse, then you should consider the development tools for GWT that are provided by Google. But please don’t ask how things are setup correctly in Eclipse. We baseline on maven and that’s it.
Widgets
We build on GWT 2.2 without any dependencies on external widget libraries. However these is a growing number of widgets (org.jboss.as.console.client.widgets) that should be reused. We aim for keeping the overall number of widgets to a minimum.
But if you need anything that doesn’t exist, take a look at the SmartGWT showcase, tell us about it and we’ll then consider implementing it.
MVP Pattern
But one of the cornerstones is the GWT Platform library, which nicely abstracts the MVP pattern. It act’s as a blueprint for the console design. A good introduction can be found here. (This is a “must read”)
AutoBeans
Internal model representations are build as AutoBean’s. They align well with the default GWT API and have build-in serialization support. A general guideline: Any domain representation that’s used within the console needs to be provided as an AutoBean abstraction. This means that beyond the integration layer (backend calls to the AS 7 domain) entities need to be adopted.
This is necessary to provide a baseline for the data binding used across widgets. Take a look at the form abstractions, then you’ll know what I mean. The CellList and CellTable API’s are another example.
We are using the AS7 mailing lists and/or IRC for discussions of technical matters, improvements, proposed patches, etc:
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.
Deployments (associated with server group)
Server Configuration (on a host)
Server Instances (on a host)
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:
The outermost categorization looks as follows:
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