The Spring Blog
You may remember the AMC Gremlin–a strong claimant for ugliest car ever. The Gremlin was produced back in the 70s, but there are still a few around, like this one, which I photographed last year in San Francisco.
The enterprise Java experience today reminds me of this piece of American motoring heritage. The Gremlin was a desperate response to the oil shock. AMC needed a “compact” car, so they took the smallest car they had and chopped it in half. The end result sold surprisingly well, but showed unmistakable signs of the fact that its front and rear were produced by different teams and hastily cobbled together. Needless to say, it was Japanese and European manufacturers who triumphed in the shift toward smaller cars.
Over the past couple of months, we’ve had a number of customers report issues to us regarding
ClassNotFoundExceptions and proxies in dm Server. The issue actually has to do with type visibility in OSGi and is explained very well by Peter Kriens over at the OSGi Alliance Blog. Please take a look at his post if you are seeing classloading issues when using proxies in dm Server or any other OSGi runtime.
[caption id=“attachment_1577” align=“alignright” width=“250” caption=“Google App Engine Groovy”][/caption]
Google just announced that their Google App Engine cloud hosting platform now supports other languages than Python: namely Java and Groovy!
You can now effectively write your Google App Engine applications in Groovy!
A couple of weeks ago, the SpringSource Groovy team and the Google App Engine Java team worked together, hand in hand, to iron out the details, to ensure that the popular and award-winning Groovy dynamic language for the JVM would run well on this exciting platform. After having created together some patches for Groovy, in the area of constrained and strict security manager policies, the Groovy development team integrated these patches and released the updated Groovy 1.6.1 version in line for the D-Day. With this new release, you can directly use the “groovy-all” JAR in your WEB-INF/lib directory and get started writing your applications in Groovy, right away, and host them on Google’s infrastructure.
Development work on dm Server 2.0 has been fully underway for some time now and I’m pleased to announce that the first milestone is available for download. Downloads are available from our home page. You can find more information about the features in this release and the coming release in my previous entry.
In this blog entry I’ll outline:
- what is new in 2.0 M1
- building dm Server directly from SVN
We're using Scrum
For the development of the 2.0 release, the dm Server team have adopted Scrum. You can see our current sprint and release backlogs in our JIRA. As ever, the development of dm Server is driven by the requirements of our users. If you see an item on the backlog that you’d like us to implement, please take the time to vote for it. Equally, if you’d like dm Server to be able to do something that isn’t currently covered by an item on the backlog, please open a new user story describing what you’d like to be able to do.
We get a lot of questions from dm Server users about what to expect in the next few releases. In this blog entry, I will outline the main features that we have on our roadmap. We are following Scrum practices so you can expect to see reasonably frequent milestones as output from our sprints, and we are flexible in handling new requirements and changes in priorities.
Shared repositories allow you to have a centralized location for managing the artifacts that are available to be installed in your dm Server instances. These shared repositories can then be added to a dm Server configuration at any point in its repository chain.
Over the past few months, the community has shown a great deal of interest in dm Server. The forums are very active and we always have stimulating discussions when presenting at conferences. We’ve noticed that a lot of the same questions come up as users start developing their first applications for dm Server, and so we’ve put together a Getting Started Guide to help get you up to speed much more quickly.
By reading the Getting Started Guide and studying the accompanying sample you’ll learn best practices for :
Forrester recently described a trend that they refer to as “lean software” in their paper entitled Lean Software Is Agile, Fit-To-Purpose, And Efficient. They state that “lean software is emerging as the antidote to bloatware” and that “the trend toward lean software has been building for years, but the worldwide recession is accelerating it”.
Forrester mentions SpringSource as one of four companies at the forefront of the lean software movement. This is due to our leadership within the Spring, Apache, Groovy and Grails communities, as well as our active encouragement, via SpringSource dm Server, of enterprise OSGi as the basis for next-generation application infrastructure.
In an earlier post, I blogged about the REST capabilities we added to Spring @MVC version 3.0. Later, Alef wrote about using the introduced functionality to add an Atom view to the Pet Clinic application. In this post, I would like to introduce the client-side capabilities we added in Milestone 2.
The RestTemplate is the central Spring class for client-side HTTP access. Conceptually, it is very similar to the JdbcTemplate, JmsTemplate, and the various other templates found in the Spring Framework and other portfolio projects. This means, for instance, that the RestTemplate is thread-safe once constructed, and that you can use callbacks to customize its operations.
In an earlier blog, Ben introduced Bundlor, the concepts behind it and how to use it from the command line as well as from within ANT and Maven. In this post I’ll show how Bundlor can be used in an Eclipse environment.
When developing OSGi-based applications, some users don’t want to spend time constantly updating their MANIFEST.MF, but instead want to focus on actual business logic in their application components: in such a scenario the Bundlor Eclipse integration will ensure that the MANIFEST.MF file reflects actual dependencies expressed by code artifacts in the project and removes the need to manually manage classpath settings in Eclipse. Additionally BundlorEclipse can help to cleanly separate runtime dependencies from test dependencies by introducing test-only source folders in Eclipse and a second manifest file called TEST.MF to specify dependencies of your unit test classes.