I'm quite happy to announce Dynamic-JMS to our readers. Dynamic-JMS is the first published effort that allows developers to use JMS dynamically in the OSGi environment. The task was quite complicated, but relatively small, which in turn made a solution possible after all. Now you can update Connection Settings, Upgrade Broker client or simply switch Messaging Brokers while the application is running, the listeners still listening and sessions stay valid - Well, every thing you deserve to have in a dynamic environment like OSGi.

Make sure to check the project, and try to use it if it doesn't make sense to you restarting the whole application for the sake of changing a connection string. And please, let us know what you think, or simply contribute some code that makes it even a better experience to use JMS dynamically in the OSGi environment.

P.S. Having implemented the first concept for running Java Web Services dynamically in the OSGi environment (Dynamic-WS), the first project that simplifies the dynamic use of JPA components in the OSGi environment (Dynamic-JPA), and now the first concept for running JMS components in the OSGi environment (Dynamic-JMS), you can bet that soon enough the first concept for running REST services dynamically in the OSGi environment will become available, so stay tuned!

Observing different approaches for logging OSGi-based applications for few months, I came across different articles on the topic. Although they explain how to use the OSGi Log Service pretty well, all in all, I consider the general approach for logging OSGi-based applications using OSGi Log Service is too complex. The complexity is driven by the fact that OSGi is a dynamic environment, and OSGi Log Service, like any other service, could become available or unavailable at runtime. Sure, these concerns need to be addressed, but my point here is that this should not be the responsibility of the developer.

The rest of this article explains what do you need to know about logging in OSGi and how you can use the OSGi Log service properly without adding any complexity to your code at all. Working on tens of OSGi-based applications I kept evolving my approach, so it's important to mention that the approach presented here is not only simple, but also has proved to work in different situations (even in cases where Log Service API packages are installed later than the bundles which consume them).

If you use OSGi in order to make your application dynamic, then your tests should test the dynamicity aspect of your application, otherwise how would you know whether your application behaves dynamically or not? how would you be sure that clients use the service with highest rank when such is registered? that bundle updates wouldn't break the application? or that any other risks you have when working on dynamic OSGi-based applications are tested and verified properly? Surely, you wouldn't want to verify this behavior in production systems or manually. Agreeing on the importance of dynamicity tests, we will move to the next issue that developers of dynamic OSGi-based applications have, how to test dynamicity?

I'm glad to announce that DynamicJava.org finally has a maven repository where the artifacts of our projects are hosted. So far, I was able to place there only the latest releases of DynamicJava.org projects, but with time other popular OSGi-related projects and core OSGi artifacts will be placed to make it easier for developers (I'm one of them, by the way) who spend much time looking for un-hosted important OSGi-related Maven artifacts. Also, if you have an OSGi-related Maven artifact, you are welcomed to host it here. The URL of the repository is http://maven.dynamicjava.org/ - Can't have enough of looking at this URL :) looks beautiful and simple to remind, wish the URLs of all maven repositories look the same.

It's worth to mention that I used Nexus, which is an open source Maven Repository Manager. The user interface is simple yet powerful and the application had scripts which could install and run it on 9 operating systems (excellent feature for a Linux dummy like myself). Kudos for the guys who developed it, it would have been great even if only 10% of the projects in Java space were as simple and accurate as this one.