In a press release made available by the OSGi Alliance yesterday, several leading vendors including SpringSource, IBM, Oracle, RedHat, Sun, SAP, ProSyst, and Paremus joined forces in their support of OSGi as the foundation for next generation server platforms.

To highlight some of the key points:

Craig Hayman, VP IBM WebSphere said

[IBM] has been shipping WebSphere Application Server built on OSGi since 2006. As a result, IBM clients benefit from a modular platform built with proven components and the ability to automatically use only the components required by their application.

Oracle WebLogic Server is a great example of the customer benefits of modularization, with its reduced footprint, improved startup time, and flexible configuration options. OSGi technology provides the standards based foundation...

Running OSGi technology in JBoss Enterprise Middleware Solutions enables our customers to deliver safer services and applications in a more dynamic runtime environment.

Sun has seen strong demand for OSGi technology within the GlassFish community. The GlassFish community will be able to take advantage of the modularity and dynamic extensibility implemented via an OSGi-technology based microkernel in the upcoming GlassFish v3 Prelude Release.

You need to look a bit harder at the various vendor offerings to determine to what extent they have been able to realize those benefits for you as a user. At SpringSource you could say we were "lucky" in this respect. We had the good fortune to be able to design…

I'm happy to announce the availability of RC2 of the SpringSource dm Server, previously known as the SpringSource Application Platform. This release is feature complete and barring any serious issues will become 1.0 GA in two weeks time.

This release fixes a few critical bugs, upgrades to Tomcat 6.0.18 and updates all code, documentation and supporting materials to reflect the new name.

Due to the renaming of the product, PlatformOsgiBundleXmlWebApplicationContext has been renamed to ServerOsgiBundleXmlWebApplicationContext and moved from the com.springsource.platform.web.dm package to the com.springsource.server.web.dm package. Thus, if you are setting the contextClass for Spring MVC's ContextLoaderListener or DispatcherServlet in web.xml in a Shared Services WAR, be sure to change the fully qualified path to com.springsource.server.web.dm.ServerOsgiBundleXmlWebApplicationContext…

The OSGi Alliance have posted an early draft of release 4.2 of the Service Platform specification.  SpringSource employees are active members of both the Core Platform Expert Group (CPEG) and the Enterprise Expert Group (EEG) within the Alliance. My personal involvement has been largely with the EEG, and particularly with RFC 124 "A Component Model for OSGi".

RFC 124 is a standardization of the core ideas behind Spring Dynamic Modules. If you look at the configuration schema, you'll see that it very closely resembles the "osgi" namespace provided by Spring Dynamic Modules (DM).  RFC 124 takes…

The answer is the Apache Software Foundation (ASF), a non-profit, meritocracy-based organization made up of individuals (not companies) who contribute code, bug fixes, answers to user questions, their time, and sometimes even their money to ensure that the software they are delivering addresses real-world requirements, along with being robust, secure, and widely adopted.

ZDNet’s Dana Blankenhorn’s response to Dave Rosenberg’s blog regarding companies selling support for technologies they don’t own or contribute to inspired me to set some things straight about Apache projects and companies that “support�? them. SpringSource which, through its acquisition of Covalent, is a significant contributor to a number of Apache projects. I agree with Dave that vendors who are attempting to monetize open source projects by merely selling “support�? around those technologies, while not contributing to the software, are little more than parasites. Not only do these companies not contribute to the projects, but their lack of involvement results in inferior support, which harms users and, ultimately, the reputation and acceptance of the projects.

In Dana’s post he noted that SpringSource was a “Third Party Support�? provider for Apache projects. SpringSource (and formerly Covalent) is a major ongoing contributor to a number of Apache projects both directly and indirectly. There have been other open source vendors that claimed they “owned�? or “ran�? an Apache project. I am not going to make that same mistake here, since such a claim clearly indicates that the speaker does not truly understand Apache and the way the organization works. The contributions and leadership of Apache projects by SpringSource employees clearly do not fit Dana’s third-party support provider definition, as is evidenced here:

• SpringSource/Covalent has employed committers on the Apache HTTP server and Tomcat projects nearly from inception – 1998 and 2001, respectively.
• Many of the Apache HTTP server modules were originally proprietary code developed by Covalent that was contributed to the ASF.
• SpringSource employees have made more than 75% of the commits on the Apache Tomcat project in the past two years and had the most active committers on the Apache HTTP server project for four years running.
• ASF Members who are SpringSource employees, are actively involved in leading and mentoring Incubator Projects.

SpringSource’s customers count on us because of our significant, long-standing involvement in the Apache projects and in the actual Foundation itself. We have also been a long-standing and charter sponsor of the ASF as well as its conference – ApacheCon – and even host its annual Members Reception at that conference to honor and thank the individuals who contribute so much to those projects.

SpringSource will never claim to own or run an Apache project, but we will proudly continue to contribute what the Apache Software Foundation values so highly – technical leadership, solid code, bug fixes and support.

Now that the holiday season (at in the Netherlands that is) has almost ended, I thought it would be time for another Amsterdam Java Meetup. So, we reserved the good-old Jaren in the Nieuwe Doelenstraat again, for having a few (paid-for) drinks with fellow Java developers and everybody else that wants to join in.

We're doing this in the same week as the Core AOP course, held in Amsterdam, which is quite convenient for me, since now I'm sure I will be in town as opposed to some of the other meetups where I couldn't be present myself.

Again, the location is the same as last time. As usual…

On Wednesday I gave a webinar on Optimising and Tuning Apache Tomcat. A recording of the webinar and a copy of the slides can be obtained from the webinars section of the SpringSource website. The same page has links for all the previous SpringSource webinars, as well as the Covalent webinar archive.

I wasn't able to get to all of the questions during the Q&A session so, as promised, here are the remaining questions and my answers.

• What are the best practices for tuning XYZ application running on Apache Tomcat?

  There isn't an ideal configuration setting for any application as the best settings will depend on many factors. As a starting point, use the recommendations provided with the application. After that, follow the process set out in the webinar and don't be afraid to go against the recommendations provided with the application if that gives you better performance.

<li><strong>Do you have any recommendations for open source tools for troubleshooting, performance benchmarking or testing web applications?</strong>

My starting point when troubleshooting is to build a simple test case using Eclipse. I then use the built-in debugger to step through the code to really understand what is happening. If you need a profiler then NetBeans includes one although I have never used it. I use a commercial profiler (YourKit) as they provide free licences to open source developers. For performance benchmarking I use Apache JMeter and for testing I use a combination of JUnit and Apache JMeter.

<li…

Yesterday, SpringSource announced the GA release of SpringSource Enterprise. As our first commercial product release, this is an important milestone for us. The engineering team did an amazing job putting this release together. The package includes enterprise versions of Spring, the SpringSource Tool Suite, SpringSource Application Management Suite and SpringSource Advanced Pack for Oracle Database, all designed to make it easier to develop, deploy, and manage enterprise-class applications.

You can test drive SpringSource Enterprise yourself: http://www.springsource.com/products/enterprise.

We…

This week the EclipseLink team announced the release of EclipseLink 1.0. I've been using EclipseLink on S2AP for a while now; in fact, I used EclipseLink when developing our JPA load-time-weaving support.

We've yet to upgrade our internal usage to 1.0 - our beta9 was tagged just before the announcement - but I wanted to demonstrate how effectively the pairing works in an OSGi environment.

EclipseLink in Petclinic

In the 1.2.0 version of the S2AP Petclinic sample, we released the EclipseLink implementation of the Clinic back-end. The back-end is a drop-in replacement for the JDBC back-end that was previously the only option.

Building Petclinic EclipseLink

To build the EclipseLink version of Petclinic, simply open a terminal window in the Petclinic root directory and run:

cd org.springframework.petclinic.eclipselink
ant collect-provided jar

	<p>
		This will create the Petclinic EclipseLink PAR file in  <span style="font-family:courier">org.springframework.petclinic.eclipselink/target/artifacts/org.springframework.petclinic.eclipselink.par</span> and will put all the required bundles in  <span style="font-family:courier">org.springframework.petclinic.eclipselink/target/par-provided/bundles/</span>.
	</p>
	<h2 id="running-petclinic-eclipselink">
		Running Petclinic EclipseLink
	</h2>
	<p>
		To run the Petclinic EclipseLink application, copy all the provided…

I am pleased to announce that Developing Rich Web Applications with Spring, a three-day bootcamp lead by SpringSource engineers on web application development, is now available.  This intense, hands-on workshop teaches how to apply the latest versions of Spring Web MVC, Spring Web Flow, Spring JavaScript, and Spring Faces to create rich web applications.  It compliments our flagship "Core Spring" course by focusing squarely on using Spring to solve problems facing Java web application developers.

• How to design and implement REST architectures with Spring Web MVC 2.5
• How to progressively enhance HTML pages and forms with Ajax behaviors using Spring JavaScript with the Dojo Toolkit
• How to design and implement linear progressions that carry out application transactions with Spring Web Flow 2
• How to implement web authentication and authorization models with Spring Security 2
• How to optimize object persistence and concurrency in a high-volume web application environment
• How to integrate JavaServerFaces component libraries into your application with Spring Faces
• User interface best practices in the areas of style, layout, and accessibility
• Testing strategies for all layers of a web application
• Techniques for optimizing web application performance

For more information and to register for an upcoming workshop, visit SpringSource.com.  I am very excited to be leading the first public bootcamp in Washington D.C on August 5th through 7th--I hope to see you there!