I really like Eclipse but, something has been bothering me for a while.
- Eclipse is build upon an OSGi framework called Equinox
- OSGi is supposed to support install/remove/restart and version-ing of bundles
- Eclipse plugins are OSGi bundles
So why the heck does Eclipse need to restart after installing new plugins?
Why does it need to restart when updating plugins?
Isn't one of the major points of OSGi to make that unnecessary?
.
.
Labels: eclipse, Equinox, opinion, OSGi, review
Here are the few groups on OSGi I've found for keeping up
OSGi - Yahoo GroupOSGi - Google GroupsOSGi Samples - Google GroupsEclipse Equinox News GroupApache Felix Mailing ListsThe
Eclipse Equinox Mailing ListOSGi BlogAny I've missed, please add a comment
Now it's time for me to make an RSS agregator to collect all of this data
.
.
Labels: Apache Felix, Equinox, news, OSGi
I'm looking at getting Equinox ready for a server, as mentioned in a previous post.
The way I see it, there are some first steps that need to be addressed.
- Create startup/shutdown scripts (live in /etc/init.d for safe (clean) starting and stopping
- Create a means to connect an Equinox console to a running instance, to deploy (or un-deploy) bundles, without restarting.
- Ensure the above can be done securely
Maybe these have been addressed but, all my Googling has shown to be fruitless.
Thoughts?
.
.
Maybe these have been addressed but, I feel like I've already spent more time searching for a solution than if I had just written it myself. Sometimes, I wonder if this is why we find so many re-implementations of problems in the open source world.
Update: I just had a random thought, maybe using JMX instead of a remote console would be a better means to (un)deploy bundles in a running Equinox...
.
.
Labels: Equinox, OSGi
After seeing a few presentations on OSGi at the
Spring Experience conference. I've become inspired about how this can be useful for the small guy, not just for big enterprises.
Many of us use hosted web services to run small and personal sites. Generally, with a small site, there are a few major pieces of software that they all have in common (the parenthesis show what I currently use).
- Web Server (Tomcat)
- Mail Server (James)
- Database (PostgreSQL)
If you are on a shared host, memory tends to be at a premium. For example, I use
JVDS, for
willCode4Beer, and only have 128MB of ram. I'm a java dev so I like running Tomcat. Running all of the services can really limit how much I can do.
Looking at OSGi, I'm considering moving to a model where everything can run off of the same virtual machine. This will also allow me to strip down the Linux install to a bare minimum.
My idea it a model like the following:
My latest searching indicates that
Apache Derby can run as an OSGi module. I'm not sure if Tomcat can but, I know Jetty can (I could also write a bundle using the embedded version of Tomcat). I know that there is not an OSGi bundle for Apache James, but, I can always write it.
Anyway, there's my idea. I'm going to dedicate a little time to get it up and running. The best part is, where the various projects share libraries, I should be saving quite a bit of RAM, let alone the amount saved by running in the same VM.
Being able to deploy mailets to the James server without restarting will be nice too. Just imagine, deploying web apps and mail apps dynamically.
Scalability? Basically, its a feature of OSGi but, imagine running on top of Terracotta (the mind explodes).
Guess I have a little work ahead.
Update: I just realized, of course there is an OSGi bundle for Tomcat, it's used in
Eclipse. Doh!
:-)Resources:
Tomcat BundlesDerby BundlesJetty Bundles.
.
.
Labels: Apache Derby, Apache James, Apache Tomcat, OSGi
