Sujit has published a blog entry showing a nice example of how to easily leverage Spring DM within OpenESB v3 / Project Fuji; both to either expose a service, or to call existing services on the "bus". The "bus" (a.k.a. normalized message router) adds the option of a message based, loosely coupled and asynchronous contract to an OSGi environment such as Felix or GlassFish v3. The simple API mechanism allows the (interface centric) OSGi services to implement and invoke message based services. Fuji then includes a host of advanced constructs, including the ability to route, transform and augment these messages. The sample application bundle as well as instructions on installing the Spring DM bundles is available on the Fuji wiki.

The Java VisualVM blogging contest results are in and the "VisualVM OSGi plugin" entry clearly caught my eye. Not simply because it's in the top three, but because this management of OSGi platforms via JMX in a tool shipping with the JDK (visualvm) works well with GlassFish v3. You'll find the documentation and downloads on the creator's page. Kiev Gama also documents how he built the plugin (a NetBeans plugin really) for visualvm in this blog entry.

This is a nice addition to the ability to use the Felix shell (telnet localhost 6666) and to the Felix web console. All tools let you observe the content and status of the 200+ OSGi bundles currently in GlassFish v3 as well as operate on their life-cycle. This visualvm plugin matches well the troubleshooting positioning of visualvm (you most likely don't need it for day-to-day development). Of course, this is not specific to GlassFish and Kiev mentions having tested this with Fuji.

Kiev Gama was born in Recife, Brazil and is a PhD Student in Computer Science at UJF-Grenoble, France. Not really a surprise when you know that Richard Hall (of Felix fame and now with the GlassFish Team) used to be part of that group.

This is a short overview of how GlassFish v3 provides support for OSGi through pointers to the work / posts of Richard, Sahoo, Jerome and many others. The story starts with an OSGi-core that is used in a system that is organized around the notions of a kernel, services and components. A good overview is Jerome's presentation at JavaOne, TS-4923.

For the basic deployment check Jerome's GFv3 Extensions: Managed OSGi bundles which explains how asadmin deploy --type=osgi myosgibundle.jar will deploy an OSGi bundle: GFv3 installs the bundle in the OSGi framework, starts it and also records the information in domain.xml, so asadmin list-components will show that an OSGi bundle has been deployed. Note you can then Use the Felix Web Console to browse through the OSGi bundles.

There are other ways to activate the same deployment machinery and, in Using filesystem operations to manage OSGi bundles in GlassFish, Sahoo shows how GFv3 leverages Apache Felix's FileInstall to allow autodeploy via the autodeploy-bundles/ directory.

Jerome's next two posts describe an extension in GF v3 that allows applications to use @Resource to refer to OSGi services. In the first one, GF v3 Extensions: Spring, Java EE 6 and OSGi, the service is a Spring Bean that is exposed to the OSGi service registry using Spring DM, while in GF v3 Extensions: OSGi Declarative Services he just uses the standard OSGi Declarative Services, which were made part of the standard GF v3 bundle starting with b55

More posts in a future installment...

Jersey 1.1.1-ea (see Announcement) is now available at the GlassFish.org DEV Update Center repository. This means you can update your GlassFish to this development module with a couple of clicks. Follow the same instructions as for the latest Mojarra/JSF to discover and install the module; see our previous post for details.

The Update Center technology and repositories leverage IPS and GFv3's modularity (built on OSGi) to make updates, upgrades and additions very easy. The technology supports multiple repositories, local, intra-net, or remote and can be used not just to deliver updates to GlassFish but also all sorts of functionality on it, from Sun, its partners, your partners, your group, your IT shop, etc...

This is a significant change to the way we currently address these tasks and we are still improving all the pieces of this chain. I'm considering organizing a couple of online webinars on the topic later in the summer to get more details out but also to get your feedback and do some additional brainstorming.

You probably know that the new, modular, GlassFish v3 is built from (OSGi) components that can be updated using IPS. We assemble these pieces into ready-to-go JavaEE 6 Web Profile and full JavaEE 6 bundles but they can also be used to create à la carte distributions, as Alexis shows in his latest posts.

I recommend you to at least try the first example to get a better understanding of how all these technologies work together. The beauty of GFv3 is that everything is very small and fast - I'm writing this entry from a public WiFi site with pretty moderate connectivity and I'm spending more time waiting on BSC than running the example.

Part I starts with a IPS toolkit image from IPS Best Practices. The toolkit image is 5MB (most of it is the python 2.4 runtime) and has no GlassFish in it. From there, the next step is to download the GF v3 nucleus (2.41MB), which automatically brings in Felix (564KB), Grizzly (943KB) and HK2 (565KB); the IPS packages include the relevant OSGi modules. The rest of that entry shows how to install the updatecenter IPS pkg (that is the biggest package because of python graphical toolkit) and how to use it to add the management pkg, and then creates and starts a domain.

Part II in the series shows first how to install the GFv3 Web Container; then it mirrors Jerome's recent entry on GF v3, OSGi and Spring (that portion gets a bit complex and I see that Jerome already published a simpler version). Part III will continue the main theme of creating an a la carte GF v3 that has the components you want and is yet extensible.

Applications using the Spring framework have always been able to run happily in GlassFish, be it v2 or v3. Now with GlassFish v3 approaching a final release, new opportunities are coming along. In a follow-up to last week's entry on managed OSGi bundles, GlassFish architect Jerome Dochez takes it a little further by implementing the GlassFish service using Spring beans and invoking it using a Java EE 6 webapp. All with no OSGi or Spring dependency whatsoever. This detailed example uses Spring's extender bundle whose role is to target the Spring container for the Spring-based service implementation, and (this is what seems to me like the most interesting part), a simple web application that can simply inject this service with a standard @Resource annotation. Of course, this is no customized version of GlassFish and the service lookup uses OSGi services and a standard Java EE annotations. No GlassFish/Spring/OSGi API required. Powerful, yet very simple.

In his recent interview on OSGi interview JavaPosse.com, Peter Kriens (OSGi Director of Technology) mentions GlassFish v3 as an example of extending a runtime without using any API specific to that runtime. It's great to hear Peter likes the work done by the GlassFish v3 team!

Fuji continues to make progress. Fuji M3 was Released last November but I missed M4 (but see Annies' note on Logging). M5 was released last week (Downloads) and Andi has just published a Release Summary that complements the M5 Wiki page. Andi and Kirill also gave a nice webinar on Fuji last Thursday; see the webinar page for links to the screencasts and the presentation - I'm afraid I'm a bit behind and have not yet uploaded the recording.

And, on related news, the recent Release of OpenESB v2.1 M2 has been well received, notably the ability to install OpenESB directly on a pre-existing GlassFish installation; see the notes by Manfred and Giovani.

Added Also see Mark's Post on M4 and M5; as he points out the instructions on M4 are here.

Modularity is important but without extensibility and manageability, GlassFish v3 would not be as exciting. Jerome Dochez, the architect for GlassFish recently posted an entry on Managed OSGi bundles. He discusses the pros and cons of deploying extensions to GlassFish as plain OSGi modules dropped into the modules/ directory or by using the familiar asadmin deploy approach. Jerome then goes on to write, deploy and test a simple OSGi bundle starting from a Java class using respectively Maven and telnet (to access the Felix Console). This entry is a follow-up to a previous one on the use of Grizzly adapters to extend the application server runtime. Jerome promises a third part to this series focusing on combining Spring, OSGi and Java EE 6, all inside GlassFish v3.

While GlassFish v3 Prelude was released in 2008, you will need to get a promoted build in order to test the features discusses by Jerome. As previously reported, the full Java EE 6 implementation of GlassFish v3 is targeting a final release in September 2009.

It's been a little while since we mentioned grizzly here, but that doesn't mean the community has been standing still, quite the opposite in fact. One of the recent significant contributions to the project is Hubert's OSGi HTTP Service. This allows other OSGi bundles to dynamically register resources and servlets into the URI namespace of the HTTP Service.

In other Grizzly-related news, the Compojure web framework (Clojure-based) now supports Grizzly which the team has found to be easy to migrate to and Restlets Engine now integrates Grizzly 1.9.10 in its 1.1.4 release.

Finally, as you can see, Grizzly now has a logo! The community voted and chose Richard's logo (used in this post). Thanks Richard!

Lots of exciting developments in the GlassFish ESB world; hot on the heels of the GlassFish ESB v2 release candidate with its enterprise features and commercial support we're also showing that we have more big plans for the evolution of this platform. With Milestone 3 of Project Fuji we give you the keys to test drive some of the platform enhancements we're working on for GlassFish ESB.next and allow you to be an active participant in driving the direction.

If you haven't been following Project Fuji closely you might be interested to know that there is both an "evolutionary" and "revolutionary" side; Adapters and Containers from v2 also are used in Fuji, and applications built in v2 deploy and run on Fuji. Where we're innovating is in looking at the productivity in every layer; ensuring we are tops in flexibility, agility and ease of use.

Milestone 3 of Project Fuji introduces a (dare I say very cool) web based tooling option for composing services.

Check out the Fuji Milestone 3 Screencast which shows how to use simple drag and drop in a browser to easily build the same scenario that was built in Milestone 2 via the domain specific language "IFL" for composing services.

It's worth noting that the web tooling builds on top of the domain specific language and hence round tripping is easy; you can for example check out the project built in the browser from subversion and edit it in your IDE of choice, just as shown in milestone 2.

This gets us one step closer to the mantra of Fuji: Productivity through flexibility, agility, and ease of use.

• In terms of flexibility this expands your tooling choices
• For agility you might notice the "automatically save and deploy" option which is one step towards our goal of making it very light weight to develop, test and correct your application as you go along
• For ease of use the simple way of visually modeling enterprise integration patterns and simple properties dialogs go a long way

Many of you may have seen the cool things Fuji Milestone 1 did, with its web based tooling option and the simple but powerful way of defining services and linking them together. For Milestone 1 we deliberately chose some contemporary technologies such as RSS and XMPP, which left some folks wondering: how does this apply to the more classic integration scenarios?

Fear not, for Milestone 2 we have chosen a classic scenario and show you how quick and easy it is to solve it with the powerful, but simple to use capabilities in Fuji.

Don't just take our word for it, watch the Fuji Milestone 2 Screencast with Keith driving it. Then Download Milestone 2 and take it for a spin by getting a simple jar file and give us feedback! There actually are more features that we couldn't fit in a single screencast, so watch this space.

For a highlight of the features such as added enterprise integration patterns and interceptors leveraging OSGi capabilities see the Milestone 2 page. Also have a look at Andi's entry on Fuji Milestone 2, which includes further background info.

We also re-vamped the landing page for Fuji, have a look at our fancy schmancy portal page for Fuji https://fuji.dev.java.net, it should have all the links to explore further information, screencasts etc.

Note that tomorrow (October 22, 2008, 9am PT) we'll have a live meeting and webcast to demo and discuss Fuji in the OpenESB Innovation Series meeting, come and participate.

InformIT recently released a two-part interview of Andi Egloff and Keith Babo on Project Fuji and OpenESB. Each part, conducted by Ted Neward, is under 10 minutes and topics covered ranged from value of an ESB and the JBI standard as they are implemented today in OpenESB.

It then gets into how Project Fuji offers to integrate into existing development paradigms and reasons for using OSGi (and how it integrates with JBI). Finally, the discussion focuses on the DSL introduced with project Fuji, a standalone (javacc-based) language to express many powerful integration patterns.

While project Fuji is still a research project, I think it's fair to say that we're hoping that most of the working going on there will become OpenESB 3.0. If you find this interesting, make sure you listen to the monthly OpenESB Innovation Series.

The OSGi Alliance has issued a Press Release highlighting the OSGi support among a number of AppServers. Peter (the Alliance's Technical Director) has written a Companion Note and GlassFish Server deserved a special mention:

And last, but definitely not least, Sun decided to use OSGi in the J(ava)EE reference implementation Glassfish. They clearly take OSGi extremely serious nowadays since they also hired Richard S. Hall. It is so good to see Sun back at the OSGi Alliance.

Thanks for the welcome, Peter. It's nice to be back.

James Falkner and Prashant Dighe will give an Overview of WebSynergy TODAY (Thursday) - 11am PT, Sept 11th, 2008. You can join us via a concall (free if in the US, caller-paid overseas) or online via TheAquarium @ uStream.TV. For more details check out the OverviewOfWebSynergy page at the TheAquarium wiki. The plan (with the usual comment about mice and men) is to record the presentation. Updated Slides are available now at the wiki page.

James Falkner and Prashant Dighe will give an Overview of WebSynergy Thursday morning - 11am PT, Sept 11th, 2008. You can join us via a concall (free if in the US, caller-paid overseas) or online via TheAquarium @ uStream.TV. For more details check out the OverviewOfWebSynergy page at the TheAquarium wiki. The plan (with the usual comment about mice and men) is to record the presentation.