All about Java
JBossOSGi ist in Version 1.0.0 Beta 6 erschienen. Das JBossOSGi-Projekt soll zum einen eine Integrationsplattform für Drittpartei-OSGi-Frameworks bereitstellen. Zum anderen soll eine OSGi-Implementierung auf Basis des JBoss Microcontainers …
In a previous assignment we had a project more like an intranet application where you manage document, make applications (which flow through a complex 400+ step BPM), integration with a SOA engine, task, inbox, etc… It was a large government project with 500 daily users.
We chose the RAP [RCP], Databinding, EMF, Teneo, hibernate, JTrecache, Equinox[OSGI] project stack. We also have written a simple editor to manipulate EMF model.
I must admit I enjoyed defining my models in ecore. With the help of teneo my DAO consisted only ~100 lines. Since the application security (this is including down to input element levels with hidden/read/write granularity) was so tight we also kept the security definitions in the ecore model.
We kept the database schema definitions along with the ecore classes, which helped BI developers and DB admins to get updates momentarily (In the early phase of the project there were weekly deployments).
I think one of the problems with java world is it has the J2EE definition. 90% times you make a project, you choose the Application server, JPA, Web model etc for the project. But people believe “If it is a commercial / corporate product it’s gotta be J2EE compliant”, which is a big bold and IMHO unnecessary binding. Most of the time, you do not WORE! Not to mention there is the saying “Write Once Debug Everywhere”.
Lately application server vendors started adopting OSGI and we’ll see where this will go. But to be honest (this might require a correction) without using equinox, you cannot use much of the eclipse technologies where the base plugins require definitions via extension points. e4 with the new dependency injection stuff may make this comment deprecated. But with the more and on-the-target adoption of OSGI, we’ll see more eclipse technologies used outside RCP and IDE domain.
On the project I mentioned, people were like ‘Are you crazy you are taking way more risks, how are you gonna get support’, well, we used the SOA engine and DB of one of the largest provider provider, we have a support ticket still open for 6 months, where I had over 20 interactions with RAP, Teneo, EMF team all resolved within hours to days. Imagine if we were using the application server from that vendor.
In the end, the project was a big success and a breakthrough not in the country but at the global level. So I think developing enterprise application doesn’t mean you gotta go JavaEE. Putting together your own OSGI stack is much better. Plus while developing, you will get the joy of restarting the application in a matter of seconds rather then in minutes in comparison to application servers.
The Eclipse Foundation and the OSGi Alliance are holding a Cloud workshop during the OSGi DevCon/EclipseCon developer conference in Santa Clara, Thursday March 25.
They key question we want to answer in this workshop: what role can OSGi play in the cloud? Offerings like the ones from Amazon (aws.amazon.com) are agnostic of any application model and OSGi can play in their EC2 offering like anybody else because it is based on generic x86 machines. However, a model like the Google App Engine so severely knee-capped Java that it is doubt full that OSGi can run on it. Many cloud computing providers have free plans to get you started, or at least make the cost trivial. However, the costly part is your own investment in the software you develop for the cloud. On the desktop and on the server we’ve had a lot of advantage of standards that abstracted us from the vendors. This portability allows us to move our code to different app servers (well mostly). Though most of the lessons we learned in the past still apply to the cloud, the current vendors of cloud computing have very specific offerings that easily create portability problems. How to access the storage? How to discover and handle multiple instances of the application in the cloud? How to handle storage? How to share domain specific services? Standardizing interfaces for these aspects of cloud computing could provide a lot of portability. And portability is not only in the interest of the clients, also vendors gain by having a much larger market.
Perusing the different offerings for cloud computing I can clearly see that the OSGi bundle model would work very well in this area. Applications can easily be managed remotely because remote management is inside OSGi’s genes. This always has made OSGi easy to use in clusters and much of those benefits apply equally to cloud computing. However, the advantages of the OSGi service model seems to be even more clear. A cloud computing environment is by definition a dynamic environment. Adding instances, removing instances, and instances that fail will likely influence the other instances. This means that the application will need to handle the dynamicity of the services that these computing instances provide. There will be also be dependencies that must be managed. OSGi services shine in these areas, making it relatively simple to correctly model these dynamic dependencies.
So overall the combination of cloud computing and OSGi is clearly an interesting one. With the workshop we want to bring together cloud people and OSGi people and see where there are areas where OSGi standards could help. This first workshop is by invitation only because for this first time we want to learn; we need people with experience in the area of cloud computing and that see OSGi as a potential standards player in this area; creating a discussion between cloud experts and OSGi experts. So if you’re heavily into cloud computing and you want to attend, send me or Ian Skerret from the Eclipse Foundation a mail. Amazon? Google? Microsoft? You?
I’ve got my Monday all mapped out (don’t forget, the full conference starts early Monday morning!) – and it’s all about OSGi and eclipseRT.
First, I’m checking out Paul VanderLei and gang’s “Working with OSGi” tutorial, maybe popping in and out as I do some new-member jumpstarts.
After lunch, I’m heading to a interesting looking series of talks — Apache Aries, Eclipse Gemini and finally an overview of the Eclipse Virgo Project. Hopefully all the speakers stick around to the break for some Q&A.
After the break, I’m going to jump in on some lightning talks – first a couple on SWT, then SOA. Depending on what Microsoft has planned, I might pop in there for a bit and finish off with one of the panels (Panels will be posted on the schedule Monday!)
After that, it’s off to the Member and Committer reception, sponsored by our friends at Oracle! Oh, and the community awards ceremony will be there as well!
Rest up, it’s going to be a busy week.
– Don
Image credit: So gesehen@flicker, CC BY-SA 2.0.
I have been playing around with e4 (M3+Integration) today and so far I’m not impressed. I’m keeping an open mind, and may change my opinion at a later time.
At the moment however, I would dare to say that e4 might be the “Windows Vista” moment for Eclipse. High hopes, but at the end of the day not groundbreaking enough to be interesting for a wide audience of developers (=regular java devs, web devs)
There are some things I like a lot and would like to see in 3.x, such as:
The biggest drawbacks in my opinion:
From my POV app development is still too complex for the avarage developer. Here is why:
“Simplify the programming model” is stated as e4’s first objective (e4-summary.odp), but I don’t think this is true at present.
I often hear the Eclipse is big, bulky and intimidating. The Eclipse e4 download packs 230 MB and all the UI clutter we are used to – but many newbies find confusing.
If a customer asked me about migrating to e4 for a product that launches in Q4 2010, I couldn’t really recommend it. At this point I don’t see any “must have“ features yet — especially for the folks that have 3.x apps up and running.
This is bad and a bit of a catch-22 situation:
Looking forward to your opinions – especially if you disagree.
Kind regards,
Elias.
ECF recently announced full support for OSGi 4.2’s remote services standard with our upcoming 3.2 release.
Today, I learned that a community member has successfully used Spring dm, along with ECF’s remote services implementation to do declaratively-specified remote services. They have agreed to contribute the example to ECF, and so expect to see it as part of ECF soon.
People have also used ECF remote services with OSGi declarative services.
And, of course, one can use remote services programmatically as well.
Among other things, this allows a wide variety of existing tooling to be used to construct, use, and debug remote services…all made possible by having an open standard for distributing an OSGi service.
I just browsed the draft version of the new OSGi specs for the enterprise. I was especially interested in how they want to address the JPA related problems. They have not chosen a fundamentally different path than I’ve been doing JPA development in OSGi for 2 years now. Difference is, they propose a new interface (PersistenceUnitProvider) to be registered for each persistence unit while I was just registering an EntiyManagerFactory with the “pu-name” service property. So every interested service could directly bind to a specific EntityManagerFactory and create its EntityManager from it. So far so good.
I was surprised however, that the OSGi specs do not address the main issue with JPA. It’s static. You can not add/remove entities dynamically. It was never designed that way and the OSGi enterprise will not solve that issue. You still have to specify all entities up front in the dreaded persistence.xml. Yet, the more OSGi way would be to skip that file altogether, have the name of the persistence unit name as service property (unit.name) of the PersistenceUnitProvider and let the PUP consume entity beans (exported as java.lang.Object services) with their “unit.name” specifying their target unit. The PersistenceUnitProvider would then have to parse the beans annotations and incorporate it into its EntityManagers.
I am aware of the big problems that can bring with it. What if there are currently transactions running? Does removing an entity from the system also mean to clean up the database? The JPA implementation would have to rebuild its internal state and caches on entity changes. I had hopes the OSGi enterprise spec would address those issues of non-dynamically of current JPA implementations.
So even with this new spec, not much is going to change how I program JPA. It will still not be possible to add new business logic to a running OSGi system without touching the persistence.xml.
Time flies, it is more than 3 years ago that Bjorn Freeman-Benson, BJ Hargrave, and me sat down after the 2006 conference to discuss the possibilities to organize an OSGi DevCon in conjunction with EclipseCon. Today I am proud to announce the 4th OSGi DevCon in Santa Clara, March 22-25. The program is, as usual, staggering. It always impresses me how many people are willing to contribute to EclipseCon/OSGi DevCon. Overall there were more than 350 submissions and about 60 of those were for OSGi DevCon. Picking the most interesting program was even harder than previous years because there is less space; we therefore have less time for OSGi DevCon. However, the resulting program is probably of even higher quality.
First I would like to draw your attention to the fact that we will officially publish the OSGi Enterprise Specification during EclipseCon. The OSGi Alliance will host a BOF on Monday night. One of the co-chairs of the OSGi Enterprise Expert Group, Tim Diekmann, will give a presentation during this BOF of what is in this specification and why it is ground breaking.
We have three tutorials. The first tutorial is from the people that wrote the OSGi and Equinox: Creating Highly Modular Java Systems book. You will get a feel for Toast telematics! See Working with OSGi: The stuff you need to know.
The next tutorial is from Kirk Knoernschild and Neil Bartlett, both very experienced developers and excellent writers and presenters. This tutorial was actually chosen in the EclipseCon Program Commitee top 5. The subject is a very hot topic at the moment: modularity. We all learned the lessons about coupling and cohesion. However, applying those lessons in large developments is still hard. This tutorial will give you theoretical as well as practical insight in modularity and using OSGi to achieve it. See Modular Architecture from Top to Bottom.
The last tutorial is from Karl Pauls and Marcel Offermans. They are the lead developers of the Apache ACE project and have been developing with OSGi forever. Their subject is absolutely core for OSGi although not always that visible. OSGi is not a “Hello World” technology, such examples only work well when the scope is small. The scope of OSGi is, however, large scale technology. Size does matter for OSGi. A consequence of the scale is that systems have a large number of bundles. This number becomes so large that handling these bundles requires automation because it is just too much to do by hand. Karl and Marcel will teach how to manage installations that reach these problems. See Become a Certified Bundle Manager today.
The first long talk is a must for anyone using OSGi. One of the most exciting pieces of work inside the OSGi is the nested framework RFC. Nested frameworks bring back the initial philosophy of OSGi: the bundles are your application. Enterprise servers based on OSGi starting to deploy many applications inside a single framework. In such a constellation, your peer bundles and peer services might no longer be yours. Nested frameworks returns to this model, an application will be installed in a child framework, also called composite bundles. The lead developers of Eclipse Equinox as well as Apache Felix will present the proposed architecture and discuss merits, pitfalls, and problems that still need to be solved. So do not miss Composite Bundles – Isolating Applications in a Collaborative OSGi World.
OSGi is like a sharp knife. When used well, it is extremely useful, when used wrongly it hurts. Chris Aniszczyk, Jeff McAffer, Martin Lippert, and Paul Vanderlei have been working with OSGi for the better part of the noughties and therefore have lots of experiences and the bruises and cuts to prove it. Between them they cover almost any computing aspect that can be used in conjunction with OSGi. Jeff was the driver behind Eclipse’s adoption of OSGi, Chris is the lead developer of PDE, Martin has worked on Aspect Oriented Programming in Eclipse including the weaving issues and is an aficionado of OSGi as well, and Paul brings the experience from the embedded world. A must for anybody that wants to adopt OSGi. See OSGi Best and Worst Practices.
OSGi is at the foundation of RCP, obviously. However, you can use RCP and not see much of OSGi. David Orme has been contracting for J.P. Morgan where they created an internal platform based on RCP. In the last few years they re-architected this platform to take more advantage of OSGi. This is a very good experience report for anybody that has to develop software to be used inside large organizations. See OneBench Reloaded – Pushing the (OSGI) Modularity Story in an Enterprise-wide Rich Client Stack.
Looking at the size of this blog, I do not think I should loose more readers going through each of the 25 mins talks, even though I think they’re more than worth it. I therefore list them here as bullets:
On Valentine’s day the early registration price will end and you’ll have to pay the full amount. So be sure to register as soon as possible to take advantage of this discount. If you’re an OSGi member, you can get an additional discount if you register here with the email address you use on the OSGi members web site.
I am looking forward to see you again in this 4th OSGi DevCon, lets hope it will be the best ever!
The Eclipse RCP became a prominent platform for building client software. One of the delivery mechanisms supported by Eclipse RCP is Sun’s Java Web Start (JWS). Since Galileo Edition some changes has been introduced in the platform. This article provides some hints for creation of the RCP delivered by Java Web Start.
In order to package the RCP I suggest to use feature-based products as described in
a previous article. Following it, you should have a top-level plug-in (also refered as product-defining plug-in) and top-level feature, which is called “wrap”-feature in the context of the Java Web Start.
Before you start with Java Web Start (JWS), export the product and make sure it starts as a standalone application. In doing so, you have to ensure that your references to the plug-ins are correct. One of the way of doing it is to hit the Validate button in the top left of the product editor. 
If the validation is successful, try to export the product. The PDE builder will run and create a distribution. The errors of the compiler/builder/assembler, if any, are reported to files zipped to the logs.zip file in the distribution directory. A prominent error is
Compliance level '1.3' is incompatible with source level '1.6'. A compliance level '1.6' or better is required.
Which actually means that the plug-in classes has not been compiled at all. In order to avoid this error make sure to set the following properties in the build.properties file of the corresponding plug-in:
javacSource=1.3 javacTarget=1.3
After a successful export of the product, just export the top-level feature (the wrap-feature). Make sure to provide the signing information, since JWS requires all resources to be signed. If you are aiming to deliver for different platforms, make sure to define a target platform (Window > Preferences > Plug-in Development > Target Platform) which contains a Delta Pack. A Delta Pack is a set of plug-ins which can be downloaded separately on the
Eclipse Homepage. Also, don’t forget to switch over to the Java Web Start tab of the Feature Export Wizard, activate the checkbox “Create JNLP manifest for the JAR archives” and specify the site URL where the resulting JNLP will be located. Make sure all your features has the provider attribute set, since it is used as the “vendor” inside of the JNLP file, which is a mandatory attribute.
The PDE build will run and create a distribution in the specified directory. Along with the exported JARs in features and plug-ins, the packaging script will generate the JNLP descriptors for every feature. Still, the main JNLP file required for launching the application is missing and has to be provided separately. Here is, how it looks like:
<?xml version="1.0" encoding="UTF-8"?>
<jnlp spec="1.0+" codebase="http://localhost/app/" href="app.jnlp">
<information>
<title>application titel</title>
<vendor>provider</vendor>
<offline-allowed/>
</information>
<security>
<all-permissions/>
</security>
<application-desc main-class="org.eclipse.equinox.launcher.WebStartMain">
<argument>-product</argument>
<argument>de.techjava.app.webstart.productid</argument>
<argument>-application</argument>
<argument>de.techjava.app.webstart.appid</argument>
</application-desc>
<resources>
<j2se version="1.4+" ax-heap-size="128m" />
<jar href="plugins/org.eclipse.equinox.launcher_1.0.201.R35x_v20090715.jar"/>
<extension name="wrap feature" href="features/wrap_feature_1.0.0.jnlp" />
<!-- OSGI setup -->
<property name="osgi.instance.area" value="@user.home/app"/>
<property name="osgi.configuration.area" value="@user.home/app"/>
</resources>
</jnlp>
Important is to specify both, the product id and the applciation id, otherwise you will see the “Application id not found” exception. Of course you can specify
additional options as command-line arguments of the launcher itself. I found it useful to be able to let the OSGi running and then connect to it and query for loaded bundles. You can do it by adding the following arguments:
<argument>-console</argument> <argument>1234</argument> <argument>-noExit</argument>
This will allow to connect via telnet with running OSGi, even after the application finishes.
This is basically it.
This weekend, the Eclipse Foundation released their 3.6M5 of their namesake platform, including the Java IDE for which it has become synonymous. The 3.6 stream, also known as “Helios”, is due to be released in Summer this year; however, the M5 release is likely to be the last feature complete release with the remainder being bug fixes and optimisations.
A welcome feature is the ability for SWT to handle ‘open’ operations. This allows an Eclipse runtime to act as a file association type, such that double-clicking on a file in a user’s desktop will open that file inside Eclipse, without opening a new Eclipse instance. This should allow standalone Eclipse RCP tools to work with standalone files without having to resort to the user manually opening the file in the tool. In addition, Eclipse now has support for “virtual folders” which allow resources to be mapped and organised in a way unrelated to the file system.
The Eclipse platform now also ships with JUnit 3.8 and JUnit 4.7; either can be used with the automated run of tests. For those plugins which don’t explicitly request a version of JUnit, there is a wiki available that discusses the changes needed to allow the tests to resolve. Lastly, the JUnit view allows test runs (recorded with the test runner) to be viewed by dragging the XML test results file onto the view. In the case where builds are executed headlessly or on a different machine, this can allow faster navigation of test failures.
PDE has been updated to allow the root of an OSGi bundle to reside at any level of the filesystem hierarchy, rather than solely at the top level. This should allow easier interoperation with tools which put resources (such as META-INF/MANIFEST.MF) in other locations. In addition, the PDE builder (which uses information stored in build.properties) now has more in-sync checks with the corresponding .classpath of the project, which will hopefully lead to earlier and easier detection of errors between in-IDE projects and the exported builds.
The OSGi runtime underneath Eclipse, Equinox, has been extended to support both declarative and programmatic registration of ServletFilters. Combined with the upcoming release of the OSGi EEG, this should allow Eclipse to trivially host web-applications inside a running instance. Furthermore, the bytecode weaving (used by AspectJ) is now supported and distributed with Equinox. Lastly, it is now possible to startup multiple Equinox consoles rather than just relying on a single console as before.
The launching framework (used for starting external programs, ant builds, PDE launches etc.) has been decoupled from the UI, which makes it easier for headless tools to be able to reuse launches from headless tools.
OSGi users will also appreciate that the EventAdmin is now bundled as part of Eclipse RCP, rather than requiring a different download in order to make use of it. Furthermore, ECF now fully supports remote services and so this should be a bigger part of distributed Eclipse Equinox systems in future.
For more information about Event Admin and Remote Services, follow InfoQ’s Java Modularity series.
by Alex Blewitt
Writing code for multiple platforms is a challenge. It not only increases the complexity of your code and tests, but it also increases the complexity of your build process. The build process is what I have had trouble with as of late. So, I’m logging my struggles so that I, and you, might have some place to go the next time multi-platform deployment causes headaches.
So, here is my problem. I have a plug-in that has a little bit of platform-specific code in it. The code works on both windows and linux, and I have precompiled binaries for them. In other words, the build of the (C++) native code doesn’t need to be part of my build process. I do that separately just because it is easier. Setting up cross-compilers is a nightmare, and takes more time than I have.
So, here is what I do: I separate my native code into plug-in fragments for windows and for linux. After that, I have to go through all of my different manifests to make sure that P2 knows what to do with the the fragments. First, a p2.inf file has to be made for each fragment and the host plug-in, so that P2 knows the fragments are installable units that should be downloaded. OK, that’s fine. Then, I have to the feature.xml for the feature that contains my plugins and fragments to make sure that I specify the supporting environments:
OK, then I have to set up my fragments to make sure that the platform filters match their target environment:
Platform filters are basically read as a functional notation, where sets of attributes are bound to operators. For example, (|(osgi.arch=x86)(osgi.arch=x86_64)) binds the selection of the attributes (osgi.arch=x86 and osgi.arch=x86_64) to the logical OR operator (|), so that it reads, “the osgi architecture can be either x86 or x86_64.” So, I’ve got that down. I also had to set up the Bundle-NativeCode attribute in the manifest for the fragment so that my application knows where to find the binaries, but I’ll get back to that later.
OK, now one might expect that everything is ready to export. After all, the binaries don’t depend on any native Eclipse fragments (they don’t reference SWT or anything). So, it seems that my fragments should be able to be packaged up just like anything else.
That’s not the case however. When you run a build in PDE, and you put a platform filter on a fragment, Eclipse checks your current target platform and builds only for what you currently have. I, for example, have a machine with Windows XP on it, and that is the version of Eclipse that I downloaded. So, Eclipse will build only the windows fragment for me. There is no option to build for other platforms. If I use the Export Deployable Features wizard, this is what I get:
Even though my fragments don’t have any dependencies on any other platform-specific code and all I really need is a jar with my binaries in it, the PDE says, “No! I can’t build that for you.” OK, that’s fine. I know that it is possible to build for multiple platforms (the SWT guys do it), so I did some searching.
It turns out that what I need is something called the Eclipse Delta Pack. The Delta Pack is basically a bunch of fragments for different platforms which include native code for user interfaces and other i/o such as file manipulation. Getting the Delta Pack can transform your Eclipse workbench into a catch-all platform which targets everything that Eclipse can manage.
The unfortunate thing is that the Delta Pack isn’t that easy to find. If you go to the Eclipse Download page, you won’t find any reference to it. You have to go down to the bottom of the page, and find the Classic Eclipse distribution. And select Other Downloads:
Once there, you will want to get the release that you are targeting (probably somewhere in the 3.5.1 stream or later), and look to the left-hand menu. You will find the Delta Pack there:
Or, you can follow this link for the 3.5.1 drop.
When you download the Delta Pack, you have to unpack it. Make sure that you don’t unpack it over your current Eclipse install. That could make things go bad. Instead, unpack it somewhere else and you can tell Eclipse to add it to your target platform.
To do that, go to your Eclipse Preferences, and find the page for Target Platform, select the running platform, and Add the Delta Pack to it as an Eclipse Install:
After that’s done, you will have a new magic option in your Export Deployable Features wizard called Export for multiple platforms. That’s exactly what I was looking for!
So, one would think at this point that one could simply export all of the features, upload them to a P2 repository, and release the new version. Not so fast. If you are me and you do that, you get this bug report.
It was silly of me. I shouldn’t have assumed that the build would work flawlessly without testing. So, I checked my P2 repository, and low-and-behold, the Linux fragment was missing. That seemed strange. After all I did export for Linux. There’s no rocket science here. It’s just a pre-compiled binary after all.
So, after hours of fighting with trying different combinations of platform filters, and different ways of building, there were no warnings and no errors in the build. Unfortunately, there was also no Linux fragment. It just would not get created on my windows box. I was about to go and file a bug on P2, when I decided that maybe I should just try to get the build on Linux. So, I went through all the above steps again on a fresh install of Eclipse on a Linux machine. What I expected to happen was that it would build fine on the Linux machine, but instead of not having a Linux fragment, I would be left without a windows fragment.
That isn’t what happened. I did get a windows fragment. What was missing? You guessed it: the Linux fragment! My Linux machine failed to build the Linux fragment. But, at least I got an error this time:
It looks like there was something about my Bundle-NativeCode property in the Linux fragment which the PDE build system didn’t like. So, I went to investigate it.
I had used native code previously in an RCP toy application in which I was experimenting with OpenGL. When I looked up how to do it at that time, I learnt that I was supposed to use various keys such as processor= and os= to tell the plug-in when to use different compiled libraries. In fact, that is what I used in previous versions of Diver. When both the Windows and Linux binaries were in one fragment, it worked fine. But apparently, now that I had them in two fragments, that was very, very wrong:
I didn’t really know what to do, though since this is what I had read was correct, and it was previously working. In fact it still works for the different Windows versions. Not for Linux, though. I don’t know why. So, after another hour or so on Google, I learned about the key selection-filter which works in the same way that the Eclipse-PlatformFilter does. So, I copied my platform filter into the Bundle-NativeCode like this:
And it works! So, I learned a few things from this whole process:
Bundle-NativeCode Format. Eclipse won’t necessarily tell you what is wrong. It might just fail to build a fragment or two without you even noticing. The safest way to get it to work just seems to be to copy your Eclipse-PlatformFilter directly into the Bundle-NativeCode property. At least you don’t have to manage multiple different syntaxes that way.Anyway, that is all for now. I hope this can be helpful to anyone who is doing builds for multiple platforms. It isn’t an easy problem to solve, so there are bound to be pain points. This post will hopefully get you (and me) through them quickly next time.
Das OSGi Users’-Forum Germany veranstaltet am 15.4.2010 in Darmstadt einen Workshop zum Thema “Building OSGi based applications”. Der Workshop soll einen Überblick über die momentan verfügbaren Tools und Methoden geben, mit denen OSGi basierende …
in der Java Entwicklung, v. a. in Embedded Linux Umgebungen, gerne auch in. Frameworks wie OSGi. C und/oder Python Kenntnisse erwünscht, dazu. Erfahrung in den Bereichen Software Testing und Software Quality Assurance …
(If you’re eager, just jump down to the bolded part about victory.)
First, some background. I think the Eclipse Test Framework is one of the gems that is part of Eclipse. Effectively it’s a way to run JUnit tests against your bundles while Equinox OSGi is running. You can also have the whole workbench UI running if you like, which I think is a common case. In fact, for quite some time, that was the *only* case that I considered it for. If I had a JUnit test that didn’t need the workbench, I could “Run As -> Junit Test”. If I had a Junit test that needed the workbench, I could “Run As -> Junit Plug-in Test”. But I never really mentally equated the “workbench” with “OSGi framework.”
Then I went to write a test for one of my bundles that has a dependency on Jetty. And its a version of Jetty that is different from the one that ships with Eclipse. When I ran it as a vanilla “Junit Test” from within Eclipse, everything worked fine. I think I just “got lucky” and it picked up the right version of Jetty when I launched the test. But when I ran my test via the Ant “junit” task (no Eclipse Test Framework), it failed because the wrong version of Jetty got loaded. All of a sudden I realized that without my delicately constructed dependencies being managed by OSGi, I was lost back in the world of “which JAR file is getting used?”
So, this brings me to the real guts of this blog post. After discovering I needed OSGi during test execution, I took a second look at the Eclipse Test Framework. Wow, this looks promising! Headless OSGi-based bundle testing! Just what I need. So I converted my build script to go that route, only to run smack dab into bug 153429, which captures that the Eclipse Test Framework only supports JUnit3.
That was at least a year ago, maybe two. I commented out my Jetty test and continued running my other JUnit4 tests using Ant. I even wrote some JUnit3 tests that I could run against the Eclipse Test Framework. Meanwhile, the CC list on bug 153429 continued to build and milestones kept passing without any progress. I stubbornly left alone my Jetty test, refusing to rewrite it for Junit3 since I figured Junit4 on ETF was right around the corner.
Finally with Eclipse 3.6M5 we have complete and utter victory. I have successfully executed my Junit4 tests with the Eclipse Test Framework. I’m not building my product against 3.6 yet (still 3.5.0 actually), but I still was able to grab the zip for ETF and make it part of my base Eclipse for PDE build to consume.
Now that I have my tests working, I do have some observations to share.
Rather than launching the SDK to run my tests, I’m launching my own product, spit out by PDE build. Part of the reason is that I have some additional plug-in tests written using WindowTester, and they care that it’s my product which is launched, not the SDK.
There was a gotcha with this. ETF was created before p2. So you just dropped your test bundles into the “plugins” folder of the SDK, launched the SDK specifying the ETF application and test bundle / test class, and off you go. Today, if you do the same, and you’re launching the SDK to run your tests, it will still work because the SDK ships with the dropins reconciler enabled. My product does not (which is the default, I believe). So I couldn’t simply drop in my test bundles and make them available for ETF to find.
The solution to this is actually quite clean and works nicely.
I’ve also included in my test feature the EMMA OSGi bundle for measuring the coverage provided by my bundle tests.
Thanks to everyone who voted, provided patches, and general community support to get the ETF supporting JUnit4. It really completes the testing package that is available to developers working with Eclipse and more generally OSGi.
Here’s a gentle reminder that OSGi DevCon London 2010 is happening in a few weeks.
I highly recommend registering if you’re interested in OSGi. There will be people from all over the OSGi community including some great tutorials. I’ll be giving a talk regarding OSGi and API evolution… with some stories of how we handle the problem at Eclipse, how it’s handled elsewhere and what are the gaps. I’m also excited about the OSGi Development Tooling Panel that Christian Dupuis, Peter Kriens, David Savage, Toni Menzel and I will be hosting. If you were looking at a time to connect (or praiseand lambast us) with some of the OSGi Tooling folks, this would be a good time. We’re hoping for a lively and friendly discussion.
Feel free to check out the schedule online for the full listing of talks and tutorials.
I hope to see you there.
EclipseCon is proud to co-locate each year with OSGi DevCon. The OSGi Alliance works hard to pick a great track out from the dozens and dozens of submissions to EclipseCon related to OSGi. After doing their work, the EclipseCon program committee often comes over-the-top with some more picks.
If you can’t make it over to EclipseCon this year and are craving OSGi content, you should know that there’s also an OSGi DevCon event in the UK on February 23 (with JAX).
- Don
as Lucene-Subprojekt Apache Tika ist in Version 0.6 erschienen. Das Toolkit zur Textextraktion verfügt nun über ein zusätzliches OSGi-Bundle, außerdem wurde die MIME-Type-Detection überarbeitet und die POI-Dependency auf Version 3.6 aktualisiert. …
In our day to day work we often use the term backward compatible. We use this term as if it is a binary: something is backward compatible or it is not backward compatible. And yes, this is true if a client directly works with a provider. If the provider can work with clients that were compiled against a previous version then the provider can be said to be backward compatible with that previous version.
So is this always binary? Nope. The reason is the design by contract rule that we all follow, or should follow. In Java, we have this rule embodied in the interface, in C++ we used abstract classes. The primary advantage of design by contract is that now the client depends on the contract and the implementation depends on the contract but the client no longer depends on the implementation. Not only allows this model to have multiple implementations for the same contract, it also makes the dependencies smaller, more concise, and most important of all explicit. This model is depicted in the next figure.
In the OSGi service specifications clients and implementers are bundles. The contract is defined in a package that is imported by both the client and the implementer. The implementation is (normally) registered as a service under the interface defined in the contract package.
Instead of having two parties, where the backward compatibility was binary, we now have three parties making the situation a tad more convoluted. The compatibility is now expressed against the contract package because client and implementer have no longer any dependency on each other. What kind of changes can we make that do not affect the client? Well, these are the same changes we could make to the implementer in the simple case. Adding members to classes and adding fields to interfaces is harmless for clients of these classes and interfaces, they never know the difference. Even semantic changes are ok as long as we specify the evolution rules in the new contract.
However, the situation is different for an implementer of a contract; an implementer is semantically much closer bound to the contract than the client. A client compiled against version 1 of the contract can be bound to a backward compatible implementer that is bound to version 2 of the contract. However, a client compiled against version 2 of a contract must never be bound to a version 1 implementation because such an implementer has no knowledge of the changes in the contract and can therefore not faithfully implement it.
Interestingly, some of these incompatibility semantics show up in the way Java works. Implementers usually implement a number of Java interfaces; not implementing all the methods in such an interface will throw a No Such Method Error when called, clearly a violation of the new contract. In this article I talk about implementing the contract, however. There are many OSGi specifications where the client is also required to implement interfaces for callbacks but they are still considered clients. For example, in the Event Admin specification the client must implement the Event Listener service. These interfaces are called client interfaces and any change in them is incompatible for a client.
Using the contract model, we must take this asymmetric situation between clients and implementers into account when discussing backward compatibility. Almost any change in the contract will require the implementer to be aware of this change. However, there are a few cases where you can change the contract without requiring the implementer’s awareness. We had such an instance in the upcoming enterprise release. In the previous release, the Blueprint API had no generics, in this release the generic signatures are added. Generics are erased in runtime, therefore existing Blueprint implementations cannot detect the difference in API and there are no additional responsibilities. Such a change is backward compatible for implementers.
I hope it is clear that backward compatibility has 2 dimensions: clients and implementers. When we make a change to the contract we must ask ourselves if this change is compatible with clients and implementers. Theoretically there are four cases, however, in practice any client backward incompatible change is very likely to be implementation incompatible as well, so there are only three cases left. The remaining question is now how to handle these three cases in OSGi. Obviously, the version attribute is the most applicable place to start.
The only party that knows about the change is the person changing contract. This person must somehow must convey its backward compatibility rules to the client and to the implementer. Surprisingly (well not really), these three cases map very well to the three parts of the OSGi version scheme:
Using OSGi version ranges, implementers can import all versions where the major and minor part is fixed and ignore micro changes. For example, when the package that is compiled against has version 2.3.6, then the implementer should import [2.3,2.4). Clients can import all versions where the major part is fixed. For example: [2.3,3). I call this model of importing different ranges based on the version that is compiled against the version policy. There is an implementation policy and a client policy.
This model works very well but it has one huge disadvantage: it requires that exporters follow the OSGi version semantics and not just the syntax. Unfortunately, we punted on the semantics when we had to specify the version attribute. We did recommend a good strategy but we did not mandate it nor was it complete. In practice, this means that people are not carefully versioning their packages (if at all!). It is always tempting to put the specification version on the package because this makes it clear which version of the specification you’re getting when you have to select a package. However, this is the so called marketing version. Netscape Navigator came out as version 4.0 because it had to compete with Internet Explorer 3.0, there never was a version 3.0. In OSGi, we are currently at release 4.2 but if you look at the framework package version you’ll find we’re at 1.5.1, telling you it had 5 client backward compatible changes and since then one implementation backward compatible change. In contrast Wireadmin is still at 1.0. There are valid reasons for marketing versions but they unfortunately do not encode the evolution path the package has taken. It means that clients and implementers can no longer use a version policy to specify their compatibility requirements and must treat the version as an opaque identifier. The dire consequence of this model is that you basically have to rebuild all dependencies for any tiny change because clients and implementers can no longer reason about backward compatibility.
One solution that I proposed many years ago is to export a package under multiple versions. The exporter knows much more about its compatibility with prior versions, being able to specify the compatibility saves the importer from having to make assumptions. However, exporting a package under multiple versions only supports 2 cases for backward compatibility. If it is listed, it is backward compatible, if not, it is not compatible. As I hope this blog has demonstrated, treating backward compatibility as black and white is not sufficient.
I therefore hope it is clear that the exporter must provide different bits of information for the implementers and the clients. This could be a new version like attribute or it could use something like exporting three independent numbers:
The author of the contract package would maintain these numbers and incrementing them when the corresponding compatibility broke. This model seems to combine the best of both worlds. It exposes the different compatibilities without any required knowledge on the importer’s side. However, my personal position is that the current version policy works today if people are willing to follow the rules. Anything else will require spec changes. The OSGi has been accurately versioning their packages correctly since 1998. The thousand dollar question is, will others follow these semantics?
P.S. In the past year I’ve done some experimenting with automatically generating import ranges based on the exported version in bnd and an implementation and client version policy. You can read about these experiments here.
For my talk today at JFokus today I’ve taken the liberty of starting some notes for folks interested in attending. There’s a lot to cover and so I thought I would try the approach of providing some material up front so the session can be more of a dialog. I’m going to attempt to cover everything in the picture below and save the demos folks might want to see for the Sonatype booth. Happy to chat with folks and do any demos before and after the presentation. Just stop by!
I’m going to talk about some of the under pinnings of the technologies we’re using as part of our Maven work. Why we selected the technologes and some of the current work that’s happening.
There are several develops going on in the various Maven projects. Maven 3.x is on the way, but we have some very interesting work happing with OSGi within our Tycho project. The Flexmojos project and NAR (the C/++ framework for Maven) are also popular.
The primary IDE integration we work on at Sonatype. The most important thing to talk about in M2Eclipse is the configuration framework.
Most of the work we’ve been doing on Hudson is still not really good enough for public consumption but we’re testing the changes we’re making on the Sonatype grid.
Proviso is not publicly released yet, but Alin and I have been working together to get our provisioning framework ready for a public release.
We are starting to use Git heavily and soon likely exclusively. We are helping out on the EGit, and JGit projects at Eclipse and we’re trying to put a little Git server together based on JGit, MINA, and Apache Shiro.
I’ll chat about these in the talk.
I’ll likely keep adding to the entry leading up the talk, but I thought I would get the ball rolling!
In short, not much. At least, externally visible. There’s the possibility that it’s a duck, with limited visibility on what’s happening above the surface but furious paddling underneath; or it could be an iceberg with a similar differentiation between what’s externally visible and what’s under the covers. (Let’s just hope there’s no Titanic passing close by…)
In my previous post on JSR294, where to misquote Mark Twain “The news of JSR294’s death has been greatly exagerated”, it seemed that JSR294 is alive and well. In the jsr294-modularity-observer list, I triggered a discussion on the inactive status (which turned out to be an automated red herring). I got cited for spreading misinformation on the web:
It has come to my attention that someone is spreading false information
with respect to JSR 294 [1,2].Frankly, there are too many cleverly-worded points in this
misinformation to address individually here. The observer list remains
available for any observer to send questions and comments to.The “inactive” flag set on JSR 294 by the JCP Program Management Office
is unfortunate. I explained its origins to Peter Kriens earlier today.
It will be removed as soon as I publish an Early Draft Review, as per
PMO rules.I expect to publish an EDR within days [AlBlue: of 11th Dec 2009], and am confident it will meet
the Expert Group’s approval.
It should be noted that upon receiving updated information I edited in place both of the articles; and in the InfoQ piece, I specifically referred to JSR294 as ‘inactive’ although the blog post took its title from the well-known phrase The King is Dead! Long live the King!, also the title of an Enigma album. So both posts now correspond to reality, cleverly worded or otherwise.
But what of the promised EDR? Days turned to Weeks; Weeks turned into Month(s), and Sun turned into Oracle (or is about to be). Yet there’s still no sign externally that an EDR has been published, nor has there been any info to update on the public JSR 294 page. The easy conclusion to jump to is that the EDR is delayed (whether through choice, accident or unexpected event is speculative). Either way, there has been no EDR to speak of.
Meanwhile, Alex Buckley has published version 0.1 of the Project Lambda JLS draft, along with follow up comments there. Arguably the additions of lambdas is a more important end goal to Java than an incomplete module specification; so perhaps that is a better focus. Or it could be that the Oracle/Sun merger, now that it’s finally about to happen there may be a culling of useless JSRs. Jigsaw will still continue, but other than the addition of the module package-like protected interface to fields – which arguably OSGi already does by virtue of its exported packages – there wasn’t much overlap or use with JSR294.
Incidentally, speaking of Jigsaw, there’s a new proposal for a Jigsaw module-file format. Rather than using a standard JAR for containing data, the module-file format is a brief header (with some generally useless information), the (uncompressed) module-info.class file (which turns up from time-to-time in JSR294), followed by a Pack200 representation of the rest. The idea is to be able to parse some information from the module before it’s all finished downloading (JARs are based on the ZIP file format). ZIP’s standard reliance on the Central Directory at the end means that in order to parse a ZIP ifle, you need to jump to the end to be able to parse it (and in addition, be able to figure out all the intervening chunks). Arguably, there’s nothing that would prevent the central directory being written out first, but this tends not to be the case for automatically generated headers. Tools that introspect a single entry (like the MANIFEST.MF or INDEX.LIST) might be able to guess at the first two entries (which, after all, have the data and filename) and most JARs are built with the MANIFEST.MF up front. In other words, we don’t technically need to download a whole OSGi bundle to find out what it’s dependencies are too.
What’s more interesting, is that one of the goals for moving the module dependency to executable code (rather than having a declarative specification of the OSGi bundle, for example) was to allow code to extend the dependency list. Yet in the module-info class case, if that refers to any non-local classes (such as those that are coming down in the following Pack200 JAR file) it will either (a) not be able to create its dependency list, or (b) have to wait until the entire file is downloaded before having that information. Flexibility can be such a double-edged sword at times.
(It’s probably worth noting here that Pack200 completely reorganises the layout of the JAR file – it’s a non-streamable format. You have to load the entire file in before you can even extract one component, so if you have Pack200 JARs – either as part of a P2 update site, or as part of a Jigsaw module – you have to load the lot before you can do anything. (And that’s aside from problems with how you compile module-info.java in the first place.)
So, we all still wait to see what the outcome of the JSR294 EDR proposed proposal is. Alex was confident in its adoption, so perhaps it’s been trimmed down to just a single keyword; though the thorny issue of irrational version numbers, even as Semantic Versioning is already the de-facto standard, still holds. As Stephen J. McConnell noted, a version numbering system that permits “point-free @ braindead” and “point-free @ pathetic” as valid (but yet incomparable) version numbers is one that really means nothing at all. And yet, even though the spec offers a free-for-all naming convention (for both the module name and the version number), it mandates the @ be used – an operator overloaded with annotations in a Java class. It seems that whilst JSR294 is supposed to be independent of Jigsaw, it’s firmly driven by Jigsaw’s requirements.
Interestingly, a recent update by Alex Buckley on the difference between JSR294 and module systems, tries to focus what JSR294 is supposed to deliver – language and VM features for the benefit of module systems such as OSGi and Jigsaw. Although it would be tempting to read too much into the PDF at the moment, the key is the module-level visibility (without actually defining what a module boundary is) is encoded in the .class files. A generic way of specifying modules, whilst ignoring the module-info.java and the versioned dependencies that introduces, seems like a necessary step towards source-level module awareness.
One could argue, though, that this is entirely pointless. The goal of a module system is to express (versioned) dependencies of the things you depend on. Whether a field is accessible or not, or whether it’s enforced by the VM at runtime, is a bit of a moot point. Indeed, OSGi already provides this out of the box (at package-level granularity) by preventing you from accessing classes that are not visible. And if you have the Java source file for your code (to put the restricted module keyword in) then you can just as easily move the code into an internal (non-exported) package. Module-crossing boundaries (think Eclipse’s ‘internal’ or ‘friendly’ classes) are a use case which is not used well at the moment; they’re exported, but not really supposed to be used by other bundles. Having a module keyword, such that classes in the JDT packages are all in the same module, might provide a way of sharing internal details without having to expose their innards to the rest of the world.
But in reality, internal classes (or modules spanning bundles) are themselves a sign of a problem, rather than a symptom which should be treated. Having internally shared code between (say) JDT and JDT UI is the problem; get rid of that, and you don’t need to have bundle-spanning-modules.
Ultimately, JSR294 is a tricky thing to solve. Sun want to have a module system without OSGi’s so-called-but-not-qualified ‘problems’ (more realistically; one developed in-house to avoid intellectual property rights), whilst OSGi is the de-facto standard module system for Java at the moment. Given OSGi’s more restrictive nature (particularly in the form of version numbering) makes a combined proposal – like the earlier Simple Module System – less likely to be acceptable to both parties.
Of course, the people who ultimately get hurt by this are the Java developers of tomorrow. There won’t be a format that is accessible to both OSGi and Jigsaw module systems, which means developers will have to pick which one to support. Quite aside from the fact that OSGi bundles are already backwardly-compatible JAR files (and thus can be used inside or outside of a module runtime), the choice of using Jigsaw is to lock yourself into one manufacturer’s VM and from an as-yet-unreleased point forwards. It’s not difficult to do the math of where the biggest customer base is.
Finally, because someone always mentions it, OSGi is not too complex. Actually, arguably it makes development easier – particularly when considering things like the Blueprint service or Declarative Services, which provide a dependency-injection way of configuring modules without needing any code references to org.osgi packages in source. This, of course, makes them trivial to mock, both at testing time and then later at run-time as well. And, as noted in December’s Bundle.update, the Enterprise Expert Group Draft 4 was previously made available and is nearing completion. This will give an OSGi way of binding JNDI references and JDBC drivers to running OSGi applications, making an OSGi runtime into a JavaEE type container with late binding of databases. Whilst the spec isn’t yet finished, the direction of the group (including the WAB web bundle format) will make it trivial to deploy web-based applications that lean on the OSGi runtime.
What is complex, however, is the concept behind modularity. How you split apart a system into smaller modules, how to reference the components’ dependencies, how they hook together in the face of a non-flat classpath are all problems that Jigsaw will face just as much as OSGi will. Problems reported between “Hibernate and OSGi” will be just as applicable as “Hibernate and Jigsaw”. At least OSGi was defined with services in mind (allowing cross-module communication to occur); it’s just not clear whether Jigsaw will discover that down the line or not. Factories (like the URL parsers) in the JDK are currently in the same module as the net stuff anyway; so that’s an internal reference. But you can bet that a Jigsaw module ringfenced around the Java net classes will face exactly the same problems of how to depend on third-party supplied factories (c.f. JDBC, XML parsers…) in a non-flat classpath. Of course, the way it’s likely to happen is by using a non-non-flat classpath, or exactly the same classpath as we get outside of module systems at the moment. However, a compile-time checked classpath but with a flat runtime classpath (albeit one with ‘module’ keyword checking done on the fly) is going to prevent any kind of duplicate version being loaded into memory, or dynamic reloading of classes for that matter.
Modular Java is complex. Solutions to complex problems can be simple, or they can be complex; but if you don’t understand the problem, then everything looks complex. Kirk Knoernschild recently declared that 2010 is the year of Java Modularity and followed up with Java Modularity: Time to Set Sail. Modularity is something that we all need to pick up, regardless of which module system is needed. Ultimately, it may all boil down to today’s Oracle/Sun conference:
So it may come down to this. The future of OSGi, Jigsaw, and modularity on the Java platform comes down to the direction that Oracle intends to take Java technology going forward. Of course, their decision will have a tremendous impact on the entire Java ecosystem. We should have direction sometime soon. Time to set sail!
These are heady times in Eclipse project-land. I feel busier than a… well, I’m really, really busy.
We have creation reviews pending for the Modeling Team Framework and Object Teams proposals. Object Teams is an already-established, mature project that’s moving to Eclipse. The logistics of the move are interesting enough (the project itself is darned interesting to boot). This project will enter eclipse.org under incubation, but intends to graduate with their first release; this makes a lot of sense for a project with established code base as it allows their developers time to get used to the Eclipse Development Process, but then quickly establish themselves as mature technology. There is some overlap with this project and some existing Eclipse project, but discussions are underway to see how these technologies can work together, or carve out their own unique corners.
New project proposals are flowing it at an incredible pace.
The Enterprise Modules Project, code-named Gemini, was proposed in late 2009 and is due for creation soon. This project will “provide a home for subprojects that integrate existing Java enterprise technologies into module-based platforms, and/or that implement enterprise specifications on module-based platforms.” As a start, the reference implementations for eight OSGi Enterprise Expert Group specifications will be created as subprojects. Gemini is complemented by Dynamic Enterprise Application Platform Project, Virgo, which intends “to provide a runtime platform for the development of server-side enterprise applications built on top of Equinox, and optionally using modules from the Gemini project.”
Also queued up are the Graphiti, JavaScript Development Tools, Mangrove – SOA Modeling Framework, Mylyn Reviews, and ScalaModules proposals. There are about a dozen other proposals pending that I’d love to tell you about, but will have to wait.
There seems to be no end of interest in bringing projects to Eclipse. This is very gratifying to me and I do love working with the hard-working folks involved. Parts of our process can be frustrating though, and I’m working hard to address them while balancing the important principles that define what it means to be an Eclipse project. I’ll be presenting the Eclipse Board with an overview of the changes to the Eclipse Development Process that I’m working on in mid-February. I intend to have a draft ready for presentation to the Board in time for EclipseCon. In the meantime, I’ll be discussing the changes here and in Eclipse Bugzilla. If there are specific issues that you’d like addressed as part of this revision, either open a bug or email me directly (I’m the only “wayne” at the Eclipse Foundation).
We all have to make a living, and over the years I did a handful of jobs and I saw software from good to bad. I did lots of traveling for onsite jobs I did not like. For now I make my living with a simple developer job, no titles, average salary. But in the meantime I dream of having my own office. I started off two years ago developing a product for the german book producers market, today I have (proudly) some customers with a truly small revenue and together with a former colleague I’m working on a project in industrial automation. I still think that one day I can make a living with software products that I work on in my free time. Eclipse technology today is still my favourite, so nearly everything I do is based on OSGi, RCP or RAP Technology. I have some Spring DM, some hibernate stuff. I find it very hard to find partners for my little business, for many people I talked to are surprised how small my revenue is compared to the effort and time I put into this. What about you ? Do you too dream of making your own business ? What are your troubles about it and your experiences ? Let me know, and let me know if you want to join.
This article assumes you know what Declarative Services (DS) are and have a basic understanding of OSGi.
There is one big problem with the Eclipse console commands. You can have only one command with a specific name. That’s of course the case in all consoles known to me. However in most consoles the commands express by their name what they actually do. Now in Eclipse we have good commands like “ss” for a quick overview of the currently known bundles in the system. Then there are the framework commands like “launch“, “shutdown” and “exit” which fairly behave like you would expect them by their name. But do you know what the “list“, “ls” or “enable“, “en” commands do? Well, they come from the “Service Component Runtime” (SCR) bundle.
list/ls [-c] [bundle id] - Lists all components; add -c to display the complete info for each component; enable/en - Enables the specified component;
So when you load the SCR bundle the command “list” will be taken. And it will list components. A better name would have been “listcomponents“. An even better approach would have been, if the Eclipse command framework was initially planned to have commands that can be extended by actions. Because then we would have a “list” command that could be extended by actions. We would have “list components“, “list bundles” and “list services“. There would be much less namespace clutter and a tighter set of commands. But since we cannot create a new “list” command, as SCR occupies it already, we have to go a slightly different way.
Command actions are a way to group commands and redirect the concrete execution to an action. So for the SCR I would like to suggest the following command:
component
This command would have several actions:
list,enable,disable,info
and for the sake of completeness the short versions of the original SCR commands as actions:
ls,en,dis,i
A command action is an OSGi services, that can dynamically extend an existing command. Its service interface is really simple:
public interface CommandAction {
void execute(CommandActionContext context) throws Exception;
}
The action gets in a context that allows it to query execution parameters that the user typed in the command line. It also allows the action to print text on the console.
public interface CommandActionContext {
String getArgument(int index);
boolean hasOption(String name);
boolean isVerbose();
void print(String text);
void println(String text);
}
A sample action would look like this:
public class FileCopyAction implements CommandAction {
void execute(CommandActionContext context) throws Exception {
String from = context.getArgument(0);
String to = context.getArgument(1);
if (from == null || to == null) {
throw new IllegalArgumentException("You must specify from and to arguments");
}
// Copy code here...
}
}
Its OSGi DS definition would look like this:
<?xml version="1.0" encoding="UTF-8"?>
<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" name="org.example.commands.file.CopyAction">
<implementation class="org.example.commands.file.CopyAction"/>
<service>
<provide interface="org.eclipse.osgi.framework.console.action.CommandAction"/>
</service>
<property name="command" type="String" value="file"/>
<property name="action" type="String" value="copy"/>
</scr:component>
Now we need a way to bring a command and its actions together. This is implemented in an abstract class that implements the standard Equinox CommandProvider. It also parses the command line and prints help. It takes the first argument from the command line and searches an action that matches the argument. It then calls the found actions execute method with the rest of the command line neatly seperated into arguments and options (that start with “-” or “–”). It also catches any exception that the action may throw during its execution.
If the action throws an IllegalArgumentException, our command implementation will print help for the command.
If we want to introduce a new command “file” all we have to do is to create a small subclass from the abstract base class “ActionCommand“.
public class FileCommand extends ActionCommand {
public void _file(CommandInterpreter ci) {
execute("file", ci);
}
}
Per definition, to create a command in Eclipse Equinox we have to have a public method beginning with an underscore. So there is a small duplication of names here, since our ActionCommand baseclass does not know the name of the method its called from, we have to hand it in as first parameter to the execute method.
Somewhere we would also have to define the file command itself. Its published as a CommandProvider.
<?xml version="1.0" encoding="UTF-8"?>
<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" name="org.example.commands.file">
<implementation class="org.example.commands.file.FileCommand"/>
<service>
<provide interface="org.eclipse.osgi.framework.console.CommandProvider"/>
</service>
<reference cardinality="1..n" interface="org.eclipse.osgi.framework.console.action.CommandAction" name="CommandAction" policy="static" target="(command=file)"/>
</scr:component>
Please note, that this command component will only be instantiated if there is at least one CommandAction service registered that has its “command” property set to “file” and is therefor providing an action for our command.
See the example file copy action in “action” (It does not really copy a file):
That’s all. Happy extending your own commands. And maybe this will find its way back into the Equinox code and we can finally have one global “list” command with lots of actions.
The code is available at git.
<?xml version="1.0" encoding="UTF-8"?> <?eclipse version="3.4"?> <plugin> <extension point="org.eclipse.equinox.http.registry.servlets"> <servlet alias="/echo" class="servlets.EchoServlet" /> </extension> </plugin>
package servlets; package servlets; import java.io.IOException; import java.io.PrintWriter; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; public class EchoServlet extends HttpServlet { private static final long serialVersionUID = 137926368689939745L; @Override protected void doGet(HttpServletRequest request, HttpServletResponse response) { String value = request.getParameter("value"); PrintWriter writer; try { writer = response.getWriter(); String outputText = "Echo Servlet inside Equinox/Eclipse says: " + value; System.out.println(outputText); writer.write(outputText); writer.close(); } catch (IOException e) { // TODO Auto-generated catch block e.printStackTrace(); } } }
