AS 5.1.0.CR1 with Embedded Jopr is out!

Ever since I have been involved with JBoss I remember people asking for a better management console for the JBoss Application Server. And it is it true that this request has been mostly ignored; well, until now.

For production deployments JBoss offered JBoss Operations Network, a full systems management solution able to monitor/provision/diagnose clusters of JBoss Application servers and more (web servers, databases, etc.).

For development, experienced developers had no problem fiddling with deployment descriptors and command line tools, and for the most part they've loved to have full control of every single aspects of the application server or picking into server internals through the generic jmx/web consoles.

It was the middle ground coverage that was missing: developers and admins with little knowledge of the server who wanted a simplified GUI with a wizard-based approach to the most common administrative tasks: deployment, configuration and monitoring of datasources, message queues, user applications, etc.

And as weird as it may sound, although JBoss 2/3/4.x was built on top of a management technology (JMX), this did not make the writing of management tools any easier. It's one thing to connect a subsystem to a management bus and use that as a kernel, and another thing to have detailed knowledge (i.e. metadata) about the management information and operations the subsystem exposes.

It's like you can access almost everything, but not everything is meant to be managed. E.g. a JMX attribute could be used for injecting one service into another and a JMX operation be part of an internal component-to-component API. And this could change from one release to another.

So writing and maintaining a decent console on top of this moving target would have been really difficult. Not to mention that the majority of JBoss core-developers would prefer to code a new transaction manager rather than touch anything GUI related. :-)

But this is about to change.

JBoss AS 5 built on top of the JBoss Microcontainer introduced the Profile service to solve exactly the problem described above. The Profile service is essentially a configuration and management API that we plan to keep stable and JBoss AS 5.1.0.CR1 is the first release to bundle Embedded Jopr, the new Seam-based management console that exercises the new API.

Seeing is believing so for the truly impatient, download JBoss AS, unzip, run and point to http://localhost:8080/admin-console (hint: use admin/admin to log in). Try it out and tell us what you think.

Read Jason's announcment of the 5.1.0.CR1 release and enjoy the new JBoss AS.

Cheers
/Dimitris

JBoss OSGi 1.0 Beta1

So just a little while after my blog entry about the OSGi hype, Thomas Diesler released the first Beta of the JBoss OSGi project, proving our commitment for supporting OSGi, despite my belief that OSGi may be of little relevance to the average EE application.

The latest JBoss OSGi release integrates the most popular OSGi runtimes (Felix, Equinox, Knoplerfish) and let's you install bundles by dropping them to the server deploy directory.

An installer is provided to let you overlay the selected OSGi runtime on top of an existing JBoss AS 5.x installation (or go with the bundled AS image), and a number of interesting examples are included to get you started.

If OSGi suits your fancy, go get it!

The hype around OSGi

Reading Robert's very interesting blog entry OSGi: YAGNI , I can only agree with the author's view of OSGi.

OSGi makes a nice kernel if you want to build really modular applications, but how many real world systems really need this? I'd dare to say maybe 10% of them and certainly less than 20%. The remaining 80-90% will have little to benefit from a super modular design, although they will have to bear the overhead and cost of creating and maintaining an application according to OSGi rules.

Witness the success of dynamic languages and development environments where development speed is the ultimate goal. Those guys care less about packaging, isolation and hot-swapping of subsystems and more about getting their work done. As long as the containers are fast, recycling the whole application is simpler and safer in most cases.

People have been writing enterprise web applications for years, do you think packaging is really their primary concern or the offered standardized functionality, richness and relevance of APIs?

Don't get me wrong, a kernel based design is essential for runtime environments, or other truly dynamic designs. JBoss had a kernel since 2001 and I presume that for the other players an OSGi kernel makes sense, if you didn't have one in the first place and if you feel comfortable with tying up your server internals with this particular technology. We are also in the process of adding support for OSGi deployments, although this is not our #1 priority simply because our customers and users don't really ask for it.

But proposing that every other application needs to fit this particular design is just an effort to tie you up in elaborate development environments and runtimes that promise to alleviate the pain of complying to the new "standard". Even if that means you need 20 steps to run and deploy a simple hello world application.

Or else, how can you can possibly monetize tomcat? :-)

JBoss AS Wish List - Input Needed!

So you have been a JBoss AS User for a long time, you have participated in the user/developer forums, opened JIRAs, asked for bug fixes and new features.

Would you like help us define and prioritize the hit list of things to work for the next 18 months? What new feature you'd like to see in JBoss AS 6 or what you'd like to see fixed or improved in JBoss AS 5? Even better, is there something you'd like to contribute?

The JBoss Wiki awaits your input!!!