There is not a lot to say about the post as he is mostly correct that the inclusion of OSGi mostly a plumbing thing in the JEE App Servers of the day. But at least it seems to be a much better technology that basing everything on JMX, since it was never really meant to be used to handling loading of all kinds of things in a complex server.

The reason I am responding to the post at all is that I find it somewhat strange that anyone would even consider the idea that Sun would invent a competing development- and deployment-model to JEE, even if perhaps not surprising from a person is very focused on OSGi. The whole idea about Glassfish (and Jboss and WebSphere) is that they implement the JEE spec as set by a JSR.

And as far as I know there is no standard even defined for deploying enterprisy applications in OSGi. So if we are going to make a new way to deploy stuff in OSGi, perhaps someone should come up with a model that can actually replace JEE instead of just saying it is “broken” and then have everyone rolling their own way of doing things. If we are all doing things in different ways we don’t need an App Server to begin with, we will just load the modules in OSGi we need and figure out how to put them together ourselves, without putting it all in Glassfish…. or Jboss or WebSphere.

What I find odd about the usage of OSGi in Glassfish is that Sun is still working on a component model of their own, to be included in a future Java release while OSGi isn’t. But it seems that the developers inside of Sun isn’t going to eat that dog food and are just going with what everyone else are using in the first place.

It started out with making a tool to make mining in the game easier. Keeping track of what ore is in your ore cart either takes paper (I usually don’t have a lot of that at my computer) or a good deal of focus (I can’t really muster that when doing something with this little action) especially when doing alloies. So I set down to make an app that would not only make this easier. But at the same time enable me to do some statistics over the mines I use and what kind of output I was getting.

I quickly desided I wanted to make an app much like the stuff I do at work. I wanted a database to store the data, a persistence layer so I didn’t have to mess with SQL and it all abstracted from my GUI via facades. It was all rather quickly put together with HSQLDB, Hibernate and HibernateSynchornizer for Eclipse and the project was off the ground…

It quickly ground to a halt tho. Mining wasn’t really something I did a lot anyway. Instead I had begun to toy with making food in the game so a new module in the app was started. I wanted to investigate effects of ingredients and store what worked for me… It didn’t last long before I lost interest in that either =). Along the way I also started a resource management module that should make it easy to calculate how much base resources it would take to make more complex stuff… It kinda got off the ground and then died too.

But then I discovered a feature of the game that was either new or I had simply not noticed it before. Basically you can copy the contents of a chest (or other containers) into the clipboard in a format that is pretty easy to parse. Generally a problem with the game is figureing out where you have your stuff and how much you have of it distributed thourgout the gameworld. So a new project started: The Inventory Manager.

Getting it together was pretty quick. Most of the application was already in place. And it only required a little work to get the database worked out to store it in. And behold the first module of my app was functional and packed for deplyment on Mac OS X (and a little later on Windows too). So here is my first Code Divsion branded app in a long time: The ATitD Manager

Mac version:

http://www.codedivision.com/uploads/software/ATitDManager-osx-a1.sitx

Windows version:

http://www.codedivision.com/uploads/software/ATitDManager-win-a1.zip