In the dm Server 2.0.0.M1 release we added support for shared repositories. As a followup to this new functionality, we've added support for browsing those repositories via JMX.

Connecting to a running dm Server instance with a JMX client now shows you a Repository group. Under this group, each configured repository (with the exception of chained repositories) has a bean that returns synopses of all of the artifacts contained inside. The bean also exposes a method for returning the entire, detailed ArtifactDescriptor for a given bean based on it's type, name, and version.

Last month we discovered how easy it is to build a fully-fledged enterprise application in just a few minutes using Spring Roo - our new productivity tool for Java developers. While many Java developers have already started evaluating Roo to help save time on their projects, I've received a lot of questions from people curious about how Roo actually works. In this blog entry I will explore Roo's architecture in depth, including its goals, alternatives prototyped, design rationale and implementation details. By the end you'll have a good understanding of what makes Roo tick and why its approach…

As Rob mentioned in his introduction to the OSGi Web Container, dm Server automatically imports system packages into Web bundles. This has proved very useful, especially when deploying existing WAR files into an OSGi environment. I've recently spent some time moving this functionality from dm Server's Web subsystem into the OSGi Web Container RI. This blog describes the new functionality, and how to make use of it.

Enabling import of the system packages

There are two ways in which you can instruct the RI to import all of the exported system packages.

When you install a Web bundle, you can now use the SpringSource-SystemPackages…

Today we announced the public availability of the 1.0 GA release of the newest member of the open source Spring project portfolio, Spring BlazeDS Integration. Corresponding with this event, I thought it time to bring my previous getting started post up to date. To recap:

This project's purpose is to make it easier to build Spring-powered Rich Internet Applications using Adobe Flex as the front-end client. It aims to achieve this purpose by providing first-class support for using the open source Adobe BlazeDS project and its powerful remoting and messaging facilities in combination with the familiar Spring programming model.

Taking Spring BlazeDS Integration for a Test Drive

• full Spring Security integration
• asynchronous messaging support (with 3 different message destination types)
• a complete XML configuration namespace
• annotation-based configuration options for remoting
• numerous advanced customization hooks

Now included with the project distribution is a thorough collection of samples built in collaboration with Adobe that demonstrate use of the various features, known as the Spring BlazeDS Integration Test Drive. These samples are a great way to get up and running with the project, and here I'm going to give you a quick…

Cloning is the feature in dm Server 2.0 which copies certain bundles and libraries into a scoped application (that is, a PAR or a scoped plan) as described in the roadmap.

The support for cloning in dm Server has progressed steadily over the last few sprints. The fundamental mechanisms were in place in M1: cloning may be triggered:

• manually by specifying the directive sharing:=clone on import-library or import-bundle
• automatically when a scoped application fails to resolve because of a uses constraint violation.

Since then the code was tidied up somewhat, a major performance optimisation was added for the common case of Spring framework being cloned, log messages were added to indicate which bundles have been cloned, tracing was improved, and a few bugs were fixed.

We have noticed that manual cloning is a relatively safe operation as it is completely under the user's control. However, automatic cloning is always speculative. It is driven by OSGi resolver failures, in particular violations of uses constraints (as explained in an earlier blog). Some uses constraint violations cannot be avoided by cloning, but we can't tell until automatic cloning has been attempted and the uses…

As the Register and several bloggers have noted, Red Hat recently announced a defensive move motivated by trying to play catch-up with SpringSource. Clearly the momentum of SpringSource tc Server and dm Server has Red Hat worried, along with the continued advance of the Spring Framework as the de facto standard component model for enterprise Java.

The “JBoss Open Choice strategy” appears to be a repackaging, rather than new technology, which attempts to position JBoss as still relevant in a brave new world of changing requirements. Not only is the repackaging obviously reactive, but much of…

We're pleased to announce that the first milestone of Spring Security 3.0 is now available for download. The release is also available through the Maven milestone repository at http://maven.springframework.org/milestone. As with Spring 3.0, this is the first release which requires a minimum JDK 1.5 to run and also require Spring 3.0, so you should get hold of the Spring 3.0.0.M3 release if you aren't already using it. So what's new and what has changed in this release?

Expression–Based Access Control

  <http use-expressions="true">
     <intercept-url pattern="/secure/**" access="hasRole('ROLE_SUPERVISOR') and hasIpAddress…

Following my previous entry many people have been asking about the impact that the move to the OSGi Web Container will have on dm Server. The most common questions being asked are:

• What is being added?
• What is staying the same?
• What is changing?
• How do I keep up to date?

I'll address each of these questions independently. If you have any more questions, please feel free to comment.

What is being added?

Integrating with the Web Container RI will give dm Server access to all the features of the OSGi Web Container standard. This includes a standard model for how WARs are handled, support for the webbundle URL scheme and support for the Web Container extender.

I'm exploring some nice value-added features for the RI including dynamic configuration using ConfigAdmin, a comprehensive MBean interface to introspect deployed web bundles and EventAdmin integration to monitor lifecycle events. All of these features will be added to dm Server as well as to the RI.

What is staying the same?

You'll be pleased to know that much of what you have learnt about web applications in dm Server remains the same.

Using the dm Server deployer

In addition to support for webbundle URLs, WAR files can still be deployed using the dm Server deployer. All paths into the deployer are supported including the pickup directory, deployer MBean and Admin Console.

When deploying using the dm Server deployer, WAR file dependencies will be automatically installed from the bundles available in the configured repository chain.

WAR deployment patterns

All the WAR types mentioned in the Programmer's Guide remain - in fact they are part of the Web Container standard.

System package imports

WARs deployed using dm Server will auto-import all the configured system packages even if this feature doesn't make it into the standard. If deploying using a webbundle URL you can trigger system package import using a URL parameter. I'm hopeful that the spec will include some standard behaviour in this area

What is changing?

We are aiming to keep the most features the same in dm Server, but the move to the Web Container does necessitate some changes. At the same time, we're taking advantage of the code rework to integrate some of the more popular feature requests we see from our users.

Web modules are being removed

The biggest change is the removal of web modules. Our preference is to support standards-based approaches, and now that we've been able to work with the OSGi Alliance to create a standards-based approach to web applications on OSGi, we are moving to it in preference to a dm Server-specific solution.

For those of you who are using web modules today, I'm really interested to hear what features you like the most and would be sad to lose. There is no reason why important web modules features cannot be reworked on top of Web Container web bundles.

Switch to Tomcat config format

In the 1.0.x line, the Tomcat instance embedded in dm Server is configured using the JSON configuration file format. Many of our users have requested that we switch back to using Tomcat's XML format. The Web Container RI uses the standard Tomcat format and when dm Server switches to the Web Container it will switch configuration file formats as well.

I'm still finalizing the exact details of where the configuration files will be stored. I'm hoping to be able to parameterize the Tomcat configuration file with placeholders that can be populated from ConfigAdmin

How do I keep up to date?

The easiest way to stay abreast of the progress is to track the SVN repos for the Web Container and for dm Server Web. You can access these repos at the URLs below:

• OSGi Web Container - https://anonsvn.springsource.org/svn/dm-server-osgi-web-container/trunk
• dm Server Web - https://anonsvn.springsource.org/svn/dm-server-web/main-branches/jersey

I'll be blogging here regularly and you can follow progress on Twitter with #osgi and #dmserver.

Updated: added version control instructions for Git.

For the last few months I've been working with Subbarao Meduri, Graham Charters, Hal Hildebrand and others from the OSGi Enterprise Expert Group on the RFC66 Web Container specification. The Web Container specification defines how WAR files can be deployed on an OSGi service platform in a standard way.

This is extremely interesting for us, because dm Server has supported WAR files for nearly 18 months now and we are excited to be able to work towards a standard model. As an end user, you'll be able to deploy WAR files on OSGi without…