Running OSGi Container Inside Embedded Jetty Web Container. Possible? - java

Working on a project that runs an embedded Jetty web server withing its infrastructure. We are looking at addings a new web application that would benefit greatly from allowing views to be plugged in using OSGi. Vaadin is our web framework of choice.
There is a great tutorial on creating an OSGi pluggable Vaadin application in GlassFish where the web container and OSGi container are bridged. That is, the web container is not running in the OSGi container. Here is the tutorial: https://vaadin.com/wiki/-/wiki/Main/Creating%20a%20Modular%20Vaadin%20Application%20with%20OSGi
My question is. Would it be possible to bridge an embedded Jetty web container and OSGi container in the same way as described in this tutorial.
Running jetty in an OSGi container is simply not an option for us as we have to work with existing deployment.

You should be able to embed any 4.2 compliant framework via the org.osgi.framework.launch.FrameworkFactory class. There's a few good examples if you google, two good ones are on the Felix site, and Neil Barlett's blog.
Configuring it will be far more work - you'll need to export all the Jetty and servlet packages via a system property org.osgi.framework.system.packages.extra and use something like Felix fileinstall or a console and pax-url to un/deploy bundles.
While your Vaadin app will be dynamic - nothing from Jetty or the embedding application will be (i.e. domain entities, services etc).

Could you embed a different container? Eclipse Virgo and JBoss AS are both OSGi and J2EE containers.
http://www.eclipse.org/virgo/
http://www.jboss.org/as7

Related

Spring application deployment on Java-ee servers

Can I deploy a Spring java application on all (or at least most) of JavaEE servers ? like Weblogic, JBoss, Webshpere, Tomcat, Jettty etc.
And is there is preferred Java EE server for Spring ?
Yes you can. And no - there isnĀ“t. Errata: you can take a look at the SpringSource dm Server. Be aware that spring is not a java EE implementation. Read this post here.
Yes, you can deploy it on any server, and you can use it on standalone applications and even on mobile applications. It is in no way restricted to web deployment. It is not even restricted to java, there is Spring.NET and even a Python version. However, java and web servers are a common if not the most common use for it.
Currently recommended web server by VMWare/Pivotal (current owner of Spring) is VFabric tcServer, which is a Tomcat fork containing some extra tools and functionality. But server in itself does not matter, Spring is container agnostic.
There is no preferred EE server. VFabric tcServer is a servlet container, not an EE server. It contains "enterprise capabilities" instead, but that's not the same thing. As said however, you can use whichever EE server you want.

How to know what glassfish is - full plaform or web profile?

I have installed glassfish. I can run
asadmin version
It shows what version it is, but how to know it is "Full Platform" or "Web profile"?
You could use the
glassfish4\bin>asadmin list-containers
command. Which lists all known application containers. A full profile server reports this:
jpa
jpa
web
weld
weld
security
grizzly
ear
ejb
osgi
resources_ear
resources
appclient
webservices
connector
A web profile server reports this:
jpa
jpa
web
weld
weld
security
grizzly
ejb
osgi
resources_ear
resources
connector
Not much difference but it should be enough ;)
You can look at the license file name to determine if it is Full profile or Web profile
<glassfish install dir>/glassfish/legal/3RD-PARTY-LICENSE.txt
<glassfish install dir>/glassfish/legal/3RD-PARTY-LICENSE-WEB-PROFILE.txt
GlassFish Web Profile: It is a lighter version of GlassFish that is designed for web applications and only includes a subset of the Java EE technologies.
GlassFish Full Platform: It is the complete version of GlassFish that includes all Java EE technologies.
Which one to download depends on the requirements of your project. If you are developing a web application and do not need the full Java EE stack, then the GlassFish Web Profile would be a good choice. If you are developing a more complex application that requires the full Java EE stack, then the GlassFish Full Platform would be a better choice.

Deploy ear in embedded Jetty

Is it possible to deploy ear (Jersey and Metro) archive in embedded Jetty? Google shows articles and manuals only about Jetty + JBoss.
As far as I understand, Jetty shouldn't have such a functionality.
That's because jetty was designed to be a web container only for Servlets and JSPs.
You can see the jetty as an alternative to the Tomcat web server.
So Jetty is able to process only web based stuff (read WARs).
JBoss on the other hand is a full fledged Java EE container, so it can handle ears as well.
What you've seen is probably embedding the jetty inside the jboss.
I know that Jboss has used tomcat for dealing with servlets and jsps internally, so it might be possible to switch the underlying implementation from tomcat to jetty.
Hope this helps
I'll add that many people deploying into things like JBoss or other full Java EE stacks really don't need the full stack and can often get away with a servlet engine plus a handful of components. I know folks that have gone with aggregated solutions of things like jetty + open ejb to achieve a lightweight stack that does what they need without all the added Java EE bells and whistles. For example, if you intend to have an embedded scenario then you don't need to deploy an ear you can deploy the application bit by bit, handling servlets with jetty and ejb's with openejb or whatever *bean solution you like.
If you need the full Java EE container then by all means use one...but if you are using a minor subset of those Java EE features there are other ways to assemble your application.

How is GlassFish an OSGi container?

In researching OSGi and OSGi containers, I stumbled across this SO question mentioning GlassFish as an OSGi container, and I have to say I'm quite baffled.
How is this possible?!?!
My understanding was that OGS - a Java-compliant app server - has 2 containers:
Web Container: where you deploy WAR files for web apps and services
App Container: where you deploy EJBs for business logic
Where do OSGi bundles fit into this paradigm?!? Does OGS allow you to deploy an OSGi bundle to the app container and treat it like an EJB or something? And if I'm mistaken about how OGS works please correct me! Thanks in advance!
Hmm, a rather total misunderstanding of what OSGi is ...
OSGi is a framework that allows you to organize your code so that you can built it from reusable components that can then collaborate through the service layer (no more Class.forName or XML!).
OSGi frameworks can run standalone, they run inside an application, the can run in a WAR file, and they can run inside an application server. And you can even run OSGi inside OSGi inside OSGi since it does not rely on statics anywhere.
The OSGi Alliance specifies a format for the modules (bundles) so that modules can specify their dependencies. The Alliance also specifies an API to install and manage modules. And last, it specifies a large number of interfaces that are useful when you develop applications.
Websphere, Glassfish, JBoss, Jonas, all support deploying OSGi bundles.
OSGi is a module system that allows to add/remove/upgrade different bundles, handles dependencies, provides runtime information on the status, etc.
When it comes to GlassFish (which has an Apache Felix OSGi container in it), the different features of the application server (eg HTTP server, JMS server, etc.) are implemented as bundles. There is console and web based interface for the OSGi container where you can start, install, remove services (see the PDF below)
As far as Java EE applications go, they can interact with the OSGI container too. For example, an EJB can be exported as an OSGi service and also the EJB can consume an OSGi service itself.
For more info, see http://glassfish.java.net/public/GF-OSGi-Features.pdf
Glassfish internally uses OSGi to provide the features you mentioned. Besides that you can deploy your own OSGi bundles on it. See https://wikis.oracle.com/display/GlassFish/OSGi
There is no real connection between OSGi and Java EE though. You can not yet use JavaEE in OSGi bundles on Glassfish. For this case there are first initiatives like Weld on OSGi: http://www.slideshare.net/TrevorReznik/weldosgi-injecting-easiness-in-osgi
They are not really production ready though.

OSGI creating modular web application

I have been looking for a solution to create a modular web application, which is modular in the sense that user can provide its own plugin in form of a simple jar which will then provide its own data to my web application and my webapp will be responsible for displaying it.
Now the catch is i want my web app to be as generic as possible without relying on the j2ee web container to support anything . i.e. i cant rely on my web container to provide osgi support and deploy web application as an osgi bundle itself ( which truly makes things very simple for eg. glassfish and WAS).
I am planning to use equinox and only solution i see currently is the servlet bridge they provide on their official site, but to me it is really a pain to delegate everything to a servlet which will in turn interpret the request and find an apropriate bundle Class and then again communicate back somehow only the data to the web application.
To me it would be wonderful if my web app was also a bundle.
Is there anything close to this ideal solution which i can try for? Or any other communication method between the two relams of osgi and web appliction (container)?
The OSGi spec details the WAB (Web Archive Bundle) format.
And Pax Web offers great support for WAB/WAR webapps (PAX Web runs fine on Equinox, Felix, etc)
Using pax web you get the BundleContext via the ServletContext, eg:
BundleContext bundleContext = (BundleContext) getServletContext().getAttribute("osgi-bundlecontext");
For the user driven pluggability you mention, I'd suggested you provide some service interfaces for the plugin bundles to implement and in your webapp use a ServiceTracker to listen for their registration (unless you're using Declarative Services). You also easily be able to install bundles from an upload servlet.
I'm guessing users uploading plugins would have to be logged in and authorized, so security issues will have been met at this point.
EDIT: replying to comment here as not enough space in comment field
Apologies, think I misinterpreted you question - you have an existing webapp container(s) and you want to deploy a WAR with OSGi functionality? If that's the case then either use the ServletBridge as others have mentioned or embed an OSGi framework into your WAR (this is relatively easy, see this for example).
You could even make this optional by attempting to get the BundleContext from the ServletContext and if this returns null then launch your own embedded framework. That way it'll run in a native OSGi container (e.g. Glassfish) or in a Java EE app server.
Otherwise, PaxWeb is an implementation of the HttpService and WebApp OSGi specs, but with lots of extensions to make life easier - but you deploy this to an OSGi container.
You might want to look into Apache Sling. It is a web framework that has an embedded OSGi container. The OSGi container is called Apache Felix and is pretty good.
ServletBridge is for embedding an OSGI contianer within a web container. The other option is to embed a web container (as a bundle) in an OSGI container. The following article has some details on how to achieve this.
http://java.dzone.com/articles/osgi-and-embedded-jetty
You may want to try ChonCMS - http://www.choncms.com
Its architecture is based exactly on what you are asking, it comes with few plugins to enable base CMS functionality, it is modular platform with minor web app container using felix and plugins can be added/removed at run time as well.
Disadvantage might be that it has lack of documentation, but you may ask, it is open source, I'm sure they will be happy to answer questions, and even better you can contribute - it is still in incubation phase.

Categories