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:
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
Comments
Post a Comment