OSGi - How mature is this technology?_问答_开发者

I have a requirement where I need to share some web resources (jsp, html, js, images, css etc.) across different Spring based Struts 2 applications. And seems like OSGi can be used to achieve this?

Can some one give some pointers on how to achieve this with OSGi?
And secondly I want to know is OSGi mature enough to be used in production applications?

Thanks in advance!

EDIT: I went through this post and seems like people are able to share a web bundle across web applications. The only difference is that they did it with Spring MVC. I want to know whether this can be achieved with Struts2 applications also?

EDIT 2: I am basically little unclear about the following:

Will the 'shareable-bundle' (containing the web resources to be shared) be a .war packaged. If yes, then from where will the final web context be formed since this bundle is again to be shared with the main 'web' application? I am expecting the final web context to be formed o开发者_运维知识库ut of the merging of the 'shareable-bundle' and the 'main' web application. Will it happen automatically? Any ideas?

While OSGI might be a solution, it might be a bit overkill (and, as Bozho pointed out, you'll need an OSGI capable container). Maybe have a look at How to share resources across projects in Maven for other options:

Cut and paste them.

Use Assembly and Dependency plugins

Use the maven-remote-resources-plugin

In this blog I’ll show how to do the second option since in my opinion, it is currently the most stable and flexible. In the future, I’ll try out the maven-remote-resources-plugin and write up a tutorial.

EDIT: To answer a comment from the OP. Yes, the idea it to create an assembly of the shareable web resources and to use the maven-dependency-plugin to pull and unpack the assembly in the "resource-consumer" projects. All this is explained and detailed in the blog post mentioned above. Let me know if anything is unclear in it.

OSGi is used in Eclipse, GlassFish, ServiceMix (and others, too), which are mature software products. However, they are very specific in nature, and my personal opinion is, that OSGi is not quite suitable for the common type projects. As far as I know (someone correct me, if there is news in this area), if you want to use OSGi with web applications, you will need an OSGi bundled servlet container. Also, putting resources (html, js, images) in OSGi bundles can be troublesome.

OSGi is a fairly mature technology - this is how all Eclipse plugins are structured. However, the technology has yet to gain traction in the web app space because there are very few servlet containers that support it.

If you want to read up on it, you should check out Modular Java by Craig Wells, as it gives a fairly good background on OSGi in relation to the Spring Framework.

With regard to sharing resources, you may want to look into an EAR package. I have successfully used this to deploy multiple WAR files with a common set of resources (for example, a compressed version of Dojo).

For example, an EAR can look like:

 ear-file/proj1
 ear-file/proj2
 ear-file/config
 ear-file/lib
 ear-file/resources
 ear-file/META-INF
 ear-file/APP-INF

You may also want to read up on the thread .war vs .ear file from a previous stackoverflow post.

I'm not overly familiar with Struts (or Spring MVC, for that matter), but you might look at the SpringSource dm Server. It is based on Equinox, the OSGi container used by Eclipse, and a bundlized Apache Tomcat (as well as the Spring framework stuff).

With the SpringSource server, each war file is deployed more or less traditionally, but can access resources (classes, services, etc.) via the normal OSGi mechanisms. Those mechanisms are based around the OSGi bundle's classloaders, which might be problematic for sharing file resources like jsps, html, css, and so on. It might work if you had something similar to the DefaultServlet that rendered things from the classloader rather than the file system. (Or, heck, I might be making this more complicated than I need to.)

On the other hand, you could deploy everything as independent web applications and stitch it all together at the client end.

The first answer to the modular web apps question looks really interesting, although not directly applicable to the SpringSource server, since it does not provide the OSGi HttpService. I believe the recent OSGi 4.2 enterprise spec work is heading towards the SpringSource server's deploy-war-files-as-OSGi-bundles approach, as well.

In answer to your EDIT 2 question, if I understand it correctly, the "web context" in that answer would be built dynamically using the HttpService, which is an interface that supplies methods to

Since those operations are handled dynamically, there wouldn't need to be anything explicitly merging web context bits.