Posts Tagged ‘OSGi’

Guess what?

Thursday, June 17th, 2010

With the fantastic weather outside, I needed to take a break in my training. My legs felt very tired this morning and my heart rate just would not go above 155 bpm: all the signs to take a rest day. Now, rest day for the legs does not mean rest day for the brain! And so, I put some more pages to the Beginning MVC chapter. Download here.

Oh, and one more thing. I spoke to Gregory from Mulesoft today and we had an interesting chat about OSGi. I will add my thoughts about this soon, in the meantime read Ross’s post at http://rossmason.blogspot.com/2008/04/osgi-is-irrelevant.html.

HqlToken exception in dm Server

Sunday, February 21st, 2010

If you’re using Hibernate in WebLogic, some of you may have come across a class loading problem, because WebLogic includes Antlr 2.7 on its main classpath, and when you start application that requires antlr as well, you will end up with strange class loading and casting exceptions.
OSGi should really solve all this, shouldn’t it? We no longer have monolithic classpaths, we have bundles with isolated classpaths and the OSGi runtime provides the lifecycle management and dependency resolution services. Well, in case of Hibernate, it is not that simple. Let’s say you have a typical web application with the repository tier implemented in Hibernate. The bundlified Hibernate distribution (courtesy of the SpringSource Enterprise Bundle Repository) correctly depends on Antlr 2.7; and so–to satisfy the dependency–you make your repository bundle depend on the appropriate Antlr bundle, and all seems to be working. Until you use more complex HQL query; that is one that does not begin with select, but with delete or update.
You see, Hibernate uses Antlr to translate the HQL into an abstract syntax tree. The root of the problem is that it [Hibernate] passes a name of its internal class to Antlr. Antlr then tries to load the class using the provided name and use this class in the vertices of the AST. Naturally, in OSGi, this is a problem, because the Antlr bundle does not depend on Hibernate. The error message is then quite obvious ClassNotFoundException: HqlToken, but this exception is thrown from Antlr rather than from Hibernate or the rest your application.
The dm Server’s extensions to the OSGi standard allow us to specify PAR-wide resolution context, which solves this problem.
In practice, you have to place both your repository and webapp bundles in a PAR; in your repository’s MANIFEST.MF, you need to specify

...
Import-Bundle: ...,
 com.springsource.org.hibernate;version="[3.3.1.GA,3.3.1.GA]";
 import-scope:=application,
...

and finally, in your webapp, you need to include dependency on Hibernate in its MANIFEST.MF.
In summary, you need to:

  • Mark the Hibernate Import-Bundle entry with import-scope:=application in repository,
  • Include Hibernate in Import-Bundle in webapp

These two simple steps solve the
ClassNotFoundException: org.hibernate.hql.ast.HqlToken web applications that use Hibernate in dm Server 2.0.

Jeabu is coming

Monday, August 24th, 2009

Our new open-source project, Jeabu, is on its way. If you are very adventurous and interested in the earliest code, pull it from http://github.com/janm399/jeabu/tree/master.

Spring User Group speaker icebreaker

Wednesday, August 12th, 2009

The ice has been broken. The first step on the path to future speeches has been taken.

First of all I would like to thank each and every one in the audience for the great support. You can now download the demo source code and the OSGi presentation material.

You can also download Dr David Syer’s Spring Batch presentation.

Videos and photos from the event will be uploaded to our website and to the upcoming Cake blogs, so keep an eye on us.

dm Server 2.0 in Action

Saturday, June 27th, 2009

We strongly believe that OSGi is the future of Java EE development. Let me be more clear (mea maxima culpa!) clearer: if Java EE applications do not clean up their act and become more manageable, they will face the slow death of COBOL (notice that I spell COBOL with upper-case letters — I have some COBOL programming experience under my belt — scary!). It means that there will be a lot of development and a lot of work for us Java programmers to do, but all the cool stuff will be happening elsewhere. Let’s name drop: Ruby on Rails, Grails, dare I say JavaScript?

Take your Java EE skills to the next level

Because of this, you really should get to MEAP and get your hands on the early releases of our new book, dm Server 2.0 in Action.

The next Spring User Group

Thursday, April 9th, 2009

I have several ideas for the next SUG talk, I think they are all really exciting, but I will welcome your comments. The choices are:

  1. Securing Spring web and WS applications.
  2. Introduction to OSGi with Spring Dynamic Modules and dm Server
  3. Spring on the server side, Ruby on the client

Securing Spring web and WS applications

In this talk, we will take an existing, well-written Spring web application and crack it. We will use Mallory’s services and show script and XHTML injection, cookie stealing, the “other four” HTTP methods and — Mallory’s favourite — SQL injection.
Next, we will take another Eastern European, Eve, and we’ll show how we can snoop on WS messages, we will demonstrate how Mallory can modify the message. We will also show how we can cut Eve out and how we will detect that Mallory is making changes to our messages.
You’ll experience our Eastern European team at its dark, foreign and generally menacing best :)

OSGi, Spring DM and dm Server

We have done quite a bit of development using the dm Server and OSGi. We can show how to make most of OSGi in your new applications. We will show the usual tricks of updating dependencies at runtime, we will also show OSGi fragments and dynamically extensible web applications.
You will see web applications deploy and update in seconds!

Spring on the server side, Ruby on the client

This should please all of you out there who think that Java web applications with servlet, JSPs, taglibs, and all that are just too complicated for the task. In this talk, we’ll show how to have a complex (and easily load-balanced) services tier in Java and Spring and how to make the most of the agility of Ruby on the client. You’ll see loads of JSON and REST.
If time permits, we may sprinkle it with memcached magic dust.

Please comment

So, please help me decide which talk would go down the best. I look forward to your comments either in this blog or on my e-mail.

SpringSource dm Server in Action

Thursday, October 23rd, 2008

We’re excited to tell you that our new book, SpringSource dm Server in Action, is now available under the Manning Early Access Program. As you can guess, the book focuses on the dm Server and its impact on the world of Java EE programming.

What’s inside?

We start with the basics: installation of the dm Server and the Tool Suite, followed quickly by your first helloworld bundle. Then we dive into the deep waters of the dm Server’s architecture. Understanding the architecture and capabilities of the dm Server allows us to explore the different approaches we can take to architecting our applications. Our code is no longer bound by the monolithic structure of WARs, RARs, EJB JARs and similar foul beasts. However, we cannot ignore existing applications and we dedicate two chapters to moving existing Java enterprise applications to the dm Server. Finally, we show how to monitor and manage dm Server instances in production environment and — using the information we gathered — we explain how to improve your applications’ performance and reliability.

Wait no longer!

If you are interested in writing new OSGi-based applications or migrating existing Java enterprise applications to the dm Server, wait no longer and get your hands on our book at http://www.manning.com/machacek/.

dm Server

Wednesday, October 1st, 2008

SpringSource have released the GA version of the dm Server. The dm Server is an OSGi-based Java EE application server.

OSGi what?

OSGi will allow you to keep the structure of your application even at runtime. You will be able to kiss good-bye to the monolithic deployment archives that obliterate your application’s structure. However, straight OSGi comes with a terrible price.

Remember this?

; set PE bit
mov eax, cr0
or eax, 1
mov cr0, eax
jmp cs:@pm
@pm:


This switched the 80286 CPU to protected mode; the 80386 also brought paging and virtual address space. In protected mode, we can run the same code as in real mode, but the memory addresses are completely different. This means that old trusty code in BIOS is unusable; we can keep our applications, but the applications cannot use int 0x13 to read from the disk. We had to start using real operating systems, whose kernels process the applications’ requests and access the hardware directly, without the real-mode code in BIOS.

What does that have anything to do with OSGi? Well, OSGi can run any ol’ Java code, but you cannot “just add this jar to the classpath”. This means that virtually all applications need to be re-packaged and updated to make them run in OSGi execution environment. In fact, there is no application in OSGi, there are only bundles. This is in principle excellent, but we still think about applications as umbrellas for bundles.

SpringSource OSGi repository

The work involved in turning 100 odd jars in a typical Java EE application into OSGi bundles is terrible. Luckily, SpringSource have a repository of trusty old Java EE libraries turned into OSGi bundles. You can download and use these bundles in place of the jars you had in your JEE applications.

dm Server

As you can guess, the dm Server bridges the pure OSGi world and standard Java EE application server world. You can deploy existing WAR as well as new PAR (Platform Archive, a collection of bundles). Additionally, each bundle can specify its personality. The personality specifies the type of code the bundle contains. A web personality tells the dm Server that the bundle will be processing HTTP requests and that it will need to be deployed in Tomcat, which is bundled with the dm Server.

Baby steps

We won’t go into detailed description of the dm Server’s architecture — we can’t give out all details of our book, SpringSource Application Platform in Action. We will, however, invite you to Spring in Finance Exchange, where Aleksa and I are going to show how to move a complex Java EE web application from WebLogic to the dm Server live!

OSGi, assemblies and other such animals

Sunday, September 14th, 2008

With the RC2 of SpringSource’s dm Server the OSGi development in Java will gain even more momentum. There are two camps of developers: one hates OSGi and the other loves it.
The reasons for hate include steep learning curve, difficulty in migrating existing applications and complexity of deployment. The first two reasons are understandable. Our SpringSource Application Platform in Action book will help with the first one and the dm Server will do an excellent job in making the migration as painless as possible. The third complaint — complexity of deployment — is not so clearly cut. If you currently need to deploy multiple versions of the same service at the same time, chances are that the complexity of your application is far greater than the complexity if equivalent OSGi-based application. In most cases, programmers actually refer to deploying a new version of a particular class or jar. But they do not want the new version to be available at the same time as the old one. Essentially, once the new version is out, the old version is lost. It is the typical update & pray scenario. You can obviously do the same with OSGi bundles. There’s nothing stopping you from updating a bundle whilst keeping its version number. OSGi is not obtrusive at all in this respect!

Assemblies

Similar thing happened to .NET assemblies: the assemblies can include a version number and .NET type identification includes the class name, the assembly and optionally a version number. Most systems use only the simple type identification, without the version number. The users of the .NET Framework have thrown away the versioning control in favour of trivial deployment and risk of problems.

Change of thinking

What we need is a shift in thinking: you can still continue with the big bang deployment, even in the OSGi world. You should, however, try to make full use of the features of the OSGi’s execution environment. This will pave the way towards easily maintainable applications in the future.