Oracle GlassFish 3.1 Testing - The OSGi telnet interface

Introduction

For my current job, I'm designing the architecture for a new system. Given the set of requirements - which of course I cannot go into due to secrecy reasons - an OSGi capable environment may be one of the solutions we're looking into. Also, being able to use a standard JavaEE programming model is also requested.

Given these requirements, we narrowed our choice of JavaEE servers down to:
In the next couple of postings, I'd like to keep you informed on the progressions and testing results we see for GlassFish, as this is currently being investigated. Most posts will be short and focused, covering just a single issue we encountered.

GlassFish 3.1 - a first test

In this post we'll discuss some issues with getting the OSGi capabilities up and running. The long story is below, or you can just skip to the solution at the end.

One of the main reasons we like GlassFish, especially the new 3.1 version, is it's support for a mixed usage of both OSGi components and ordinary JavaEE components like EJBs, Servlets, etc. Especially as GF 3.1 supports Java EE 6, developers can use the nice annotation based configuration to inject dependencies between components.

However, one of the first tests before we start coding a little application of our own is of course just to get the damn thing running. For this, I downloaded a small sample application and tried to deploy this on GF.

Where is the OSGi???

One of the first things we've encountered when starting the application server was the lack of the OSGi stuff. Given the focus of GF on the new OSGi stuff, this is quite strange off course. There is no way using the admin console to deploy your OSGi bundles...

After some googling, the solution seems quite apparent: just use the update manager (worthy of a post of it's own...) to install the additional admin modules to enable OSGi capabilities. Problem solved you think? Not really, after installation the admin console just stays the same, no OSGi admin console anywhere.

Hey, where is the telnet interface?

One of my first guesses to get things running was to check the Apache Felix telnet interface whether the admin-bundles were correctly installed. This should be as simple as:

>telnet localhost 6666

But unfortunately, as you can see, no results. The question is: why is the telnet interface not running? If you try a fresh install of GlassFish 3.0, you immediately get a nice telnet interface at your disposal.

The first hint why the telnet interface isn't up and running immediately is because the bundle for the telnet shell is stored in the "modules" directory - where all available bundles reside - but not in the "modules/autostart" directory - I guess the name says it all. The reason is apparently that having a telnet console at your disposal by default is a security issue.

Moving this file to the "autostart" directory should solve the telnet issue, shouldn't it? Again no, at least not completely. During the final stages of development and testing of GF 3.1, a bug was found on the Windows platform. This bug caused thousands of threads to be started in some circumstances when the auto-file-deploy bundle was enabled.

As a last minute fix, the auto deploy ("fileinstall") bundle was removed from the list of bundles which GlassFish automatically installs at startup of the server. You see, automatic bundle starting is a two-phase process in GlassFish, where first a number of bundles are started which are configured in your domain configuration (domain.xml). Then, it is the job of the auto-file-deploy bundle to autostart all bundles present in the "module/autostart" directory.

Conclusion

After performing the following changes:

  • Moving the telnet bundle to the autostart directory
  • Re-enabling the fileinstall bundle in domain.xml
  • Installing the OSGi admin UI components
everything was working again as expected. So next: on to using the OSGi features.

Comments

Post a Comment

Popular posts from this blog

Validations across micro-services

Image
On my day-job as a consultant for GROUP9  we had an interesting discussion on how to handle validations across micro-services. Let's look at this in the context of a fictionalized example. Example: amazon selling for other companies The case we were discussing was the typical case of referential integrity between two objects. Imagine this: we're Amazon, and being a large e-commerce platform, we want to enable other sellers to use our platform to sell their products, while we handle all the logistics (and of course get a percentage on every sale 😁). To achieve this, we come to an agreement with a seller after some negotiations, e.g. agreeing on the commission percentage we receive on every sale. During these negations, we can add some of the products of that seller to our platform, show them the pricing, additional information etc, so the seller can have an idea what his products would look like when promoted on our platform. Being Amazon, we of course have a micro-services lan...
Read more

Bridging the world of Event Storming and BPMN

Image
In a recent post , Bernd Ruecker made a nice post on a pattern to transform events to commands in MicroServices and DDD. The post discusses the differences between Choreography and Orchestration as two major styles in which various micro-services can be connected and the pros and cons of these styles. Creating business process based systems using DDD is something I've been working on quite a bit. In this post, I would like to take this one step further and also show how the worlds of BPMN and DDD have a very nice fit, even b eyond than just this pattern. To do this, I'm going to make a connec tion between BP MN and a prominent style of analysis in the DDD world - Event Storming by Alberto Brandolini . Also, I'd like to dive into how the strategic design parts of DDD can help us in guiding us where we would like to apply these patterns. The latter will be subject of a later post. Event Storming First things first, lets look at Event Storming and how it is used in DD...
Read more

From Multi-Threaded applications to Multi-Time applications

Image
At the DDD Europe conference.. Recently, I visited the DDD Europe  conference, where Vaughn Vernon held a talk on using Akka an the Actor model to implement applications, based on the principles of Domain Driven Design. This talk, combined with some recent issues I've been facing at my customers site, inspired me to think about the design issues you face when developing multi-time applications. But let's start with what Vernon was talking about at his talk. Vernons talk His main premise: the Actor model is a more simplified model for application development, while at the same time providing a thread-safe environment to fully make use of the ever increasing number of cores processors have. While CPUs don't get any faster, in terms of pure clock speed, they do get more cores, and the we need to adapt our software to make use of these multiple cores. Traditional programming models don't scale nicely because of IO waits causing the software to block and the CPU being ...
Read more