Richard S. Hall

Augusto Sellhorn wrote:
Now, what about version ranges? More specifically, let's say I want to restrict this to say ONLY support version 1.8 of that package? I can do this manually like this;

org.some.random.package;version=[1.8,1.8]

Now, is there a way to tell the plugin to do this and maybe other variations, without me needing to type in all possible packages for my project?

maven-bundle-plugin uses bnd and bnd allows you to specify various version range policies. Check the bnd documentation on Peter Kriens' web page.

Augusto Sellhorn wrote:

Richard S. Hall wrote:
The simplest approach is to create one big self-contained bundle, but it depends on your situation.

You mean embedded jars in the bundle? We ended up having to do that after bnd wrapping all dependencies wouldn't work in all cases.

Yes or just expanding them into the bundle, you don't necessarily need to embed the classes in their original JAR files.

Migue Carvajal wrote:
We have had some trouble using third party libraries in OSGi. Sometimes, our approach has been "bundlelize" the library, and this has revealed new troubles related to dependencies with other libraries, this end in a very big bundle containing a lot of dependent components.
Do you recommend any strategies to cope with this situations?

We cover this topic in the book. The simplest approach is to create one big self-contained bundle, but it depends on your situation. If you can already find bundle-ized versions of most of the dependencies, then keeping them separate is probably the best choice. This is definitely a hurdle when moving toward OSGi, but it is improving.

Migue Carvajal wrote:
Regarding to mobile phones and tablets, do you think Android is adequate to deploy OSGi over it? Is it possible to run OSGi in J2ME platform?
Thanks in advance,

Yes, see: http://www.ezdroid.com/

OSGi will also run on Foundation Profile.

Augusto Sellhorn wrote:As I mentioned on another thread, I do consider OSGi a type of SOA system, if you don't go with the misconception that SOA is all about Web Services.

I think a lot of OSGi folks see it that way too;
http://www.osgi.org/blog/2007/09/soa-osgi.html

I agree, but it seems to be a losing battle trying to explain it that way. Too many people (media included) equate SOA with web services. That is why I typically never use the term SOA, but use service-oriented programming or computing instead.

Gurmeet Jabbal wrote:How is OSGi different from SOA?

It really has nothing to do with SOA at all. OSGi is a module system for Java. It promotes a loosely coupled collaboration mechanism between modules, which it calls services. These services are just Java interfaces. Module publish their services in a local service registry where other modules can look them up to use them. In this way, providers and consumers are not coupled to each other, since they don't have to know about each other directly. This is the service-oriented interaction pattern of publish-find-bind, but that's it. There is nothing related to SOA.

Chaminda Amarasinghe wrote:
What is the best definition for OSGI?

Is that a Framework or Model?

It is a framework that supports a modularity model.

I'm not sure I fully understand the question. Is the issue you are trying to highlight one of dependency management?

It sounds like you are merely describing an optional service, meaning it may or may not be there. For optional services, you only need the service API to be present to resolve code dependencies, but you do not actually need an implementation of the service API. Technically, you can also specify optional code dependencies. In either case, your component with optional dependencies needs to be programmed to deal with the fact that the dependency might not be satisfied (which is slightly different for optional code dependencies vs optional service dependencies).

An alternative is to use something like iPOJO which can automatically inject null object proxies into your component for missing optional service dependencies, then in this case you don't even need to check for null. This would be basically the same as your suggested approach in your example description.

Don Scott wrote:Many of our apps use a javaagent to do some loadtime weaving with ASM. Since OSGI has a sort of start/stop available status for a module, how much does this affect the bytecode weavin? Is compile time weaving even possible in a generic way yet ie. not just an Equinox solution?

The new R4.3 spec defines an approach for load-time weaving.

Pradeep bhatt wrote:What happens when bundle1 dependent on bundle2 is shutdown. Will runtime exception be thrown ? One more question, if changes are made to argument passed to bundle 2 from bundle 1 I guess it wont get reflected in the caller's object, I mean is it similar to RMI calls ?

Regarding your first question, code dependencies are not impacted by whether a bundle is active or not. Once a code dependency is satisfied it will remain satisfied until the framework is shutdown or refreshed. You cannot just go pull the rug out from under a bundle by taking away its required classes. Service dependencies, on the other hand, can go away dynamically and a bundle must be prepared to deal with it. This is similar to distributed programming where remote services can fail for any reason.

Regarding your second question, even though I compare services to distributed computing above, I am only talking about how failure can occur at any time, nothing else. There is nothing special or magical about OSGi services, they are just direct objects shared among bundles and behave just like any normal object would.

Pradeep bhatt wrote:Thanks authors. what about .NET langauges like C# ? Is modularity taken care of there ?

.NET has more support for modularity by default than Java, but it is not as fine-grained and dynamic as OSGi. .NET packages its types into assemblies, which are its module concept. Assemblies contain a list of their dependencies on other assemblies. This way the .NET runtime can make sure all requirements are satisfied and it can support side-by-side versions. Additionally, .NET has another access modifier (besides public, private, and protected), called internal. This provides visibility within the entire assembly, but not outside of it (i.e., module global).

Pradeep bhatt wrote:I think it make sense to use ogsi when we need to maintain multiple versions of applications. Each version deployed as a bundle. Do you agree with this author ?

It is not necessarily multiple versions of an application per se, it is just when you need higher levels of modularity and encapsulation than what Java provides by itself. This could include running multiple versions of the same application at the same time, but you may just have a really big application where you want to enforce logical boundaries and enable better separation of concerns allowing different parts of the application to evolve independently. Or it could just be a small highly dynamic application where you want parts of it to be able to easily come and go in response to environmental changes.

Modularity is like object orientation, it doesn't just enable a single thing, it is about design.

Pradeep bhatt wrote:
Wouldn't it burden the deployer to specify the external depedency. There is a chance it may be missed because the code uses say class.forname(..)

It relieves the deployer, since there is no more guess work. However, it does burden the module developer. Luckily, though, since OSGi dependencies are based on Java packages, a lot of this information can be automatically generated with tools like bnd.

Regarding Class.forName(), it is a good idea to avoid using that when using OSGi. In general, modules shouldn't have to be directly loading classes and if they must they must take care in doing so to avoid making assumptions about type visibility.

Anyway, worst case, missing a dependency is no worse than not knowing you should have put something on the class path. You'll just end up with a runtime exception that you'll have to fix, but hopefully you'll catch this in your testing.

Raghavan Muthu wrote:
I have not heard of OSGi so far. Had been browsing the threads here and somehow could get that OSGI is a platform for addressing the modularity issues in Java based applications.

1. Is that modularity in terms of packaging alone? or anything else?

There is physical modularity in the sense that OSGi defines a packaging format (just a JAR file with some extra info inside) that is used for deployment. Logical modularity is created through another level of encapsulation where the visibility/exposure of code is completely controlled by the module itself. Dynamic module lifecycle management is supported (i.e., install, update, uninstall, etc). Lastly, an interface-based programming model (i.e., services) is promoted for loosely coupled collaboration among modules.

Raghavan Muthu wrote:
2. Conceptually, how does the OSGi work?

It uses a class loader per module to create and enforce modularity.

Raghavan Muthu wrote:
3. Would there be any issues with scalability of my Java application? If so how do I address them?

Depends on what sort of scalability. There isn't too much overhead associated with OSGi at execution time, so it should be an issue there. The biggest issue probably relates to the number of modules in a system, but I think most OSGi frameworks could easily handle 100s if not 1000s of modules without too much difficulty.

Augusto Sellhorn wrote:Ok, ok, XML was a bad example :-) I'm not a fan either, although you all know Declarative Services, Blueprint and Spring DM all use XML right? :-)

That's why I promote iPOJO, it supports annotations, XML, and API...

Augusto Sellhorn wrote:What I meant is the MANIFEST.MF file is kind of like Makefiles, it's sentitive to space indentation in some cases. For example, if you new line a long package you have to add a space (" ") to continue the line. I just tried it again to double check.

Although I admit it has gotten better, I could swear at one point if you didn't have an extra line or some other nonsense at the end of the MANIFEST file it wouldn't parse it correctly (just tried that and it didn't cause problems).

BTW Jigsaw doesn't use XML, their format looks like compilable source.

Yeah, manifest syntax is odd, but for the most part you don't really need to generate the actual file by hand with either Eclipse or tools like bnd or maven-bundle-plugin.