I'm converting an application to an OSGi environment.
This application uses asynchronous servlets (so Servlet 3.0.0+) to detach the incoming requests from their thread, and queue the requests.
As far as I can see, all servlet bridged Felix packages use servlet 2.x, so I can not use servlet 3.0 specific stuff.
Is that true? Is there any way to use asynchronous servlets in Felix? If not, is it
planned?
I've tried both Felix and Equinox.
Felix turned out to be pretty easy, it's mostly a matter of injecting the Servlet 3.0 package to the framework, from then on there aren't any servlet 2.0 dependencies.
Note that the examples on the felix site aren't completely up to date.
Anyway: I've shared an example on github, maybe it's useful for somebody:
https://github.com/flyaruu/felix-bridge
As an alternative to a servlet bridge it might be worth looking at Eclipse Virgo. The latest release of that currently includes Tomcat 7 and I believe the 3.5 release will use Jetty 8, so that would give you your servlet 3.0 support in an OSGi environment.
Related
Could someone help me understand or rather provide a comparison between using winstone vs tomcat from both functionality perspective as well as performance perspective.
Winstone is an old servlet-container. It is not maintained anymore (last release was in January 2008) and only supports servlet api 2.5.
As a feature comparison, Tomcat supports servlet api 3.1 (and support of servlet api 4.0 is on the way). Tomcat is the most used servlet container in the world and well maintained.
For performance comparison between Tomcat and Winstone, I do not know of a benchmark but I would put trust in the most used and tested (ie Tomcat).
Between Tomcat and Winstone, the choice is fast.
Note: Winstone was known to be a lightweight servlet container embedded in Jenkins. But Jenkins has replaced it by embedded Jetty a long time ago.
I see tcServer is built on Apache Tomcat. So the support of EJB,JAX_WS support is not available on tcServer/ApacheTomcat. But Apacahe Tomcat has other versions like TomEE+ or integrating OpenEJB, provides support for EJB,JAX-WS.
So, is there similar support by tcServer to support EJB,JAX-WS?
No, Like you said tc Server is based on Apache Tomcat, not TomEE. So, there is no support for EJB or JAX-WS, nor is there an effort to support EJB or JAX-WS.
Imagine you want to have a highly modular web application in Java. Components are already using Spring framework also. Some components cover only pure Logic and some others also come with some presentation GUIs in HTML. The application is not Portlet compatible but we need to have dynamic menu which promotes the list of installed modules and links to the pages or REST APIs. Since it’s Java, using OSGI is recommended but I got too much confused with the recent features in OSGI (introduced past few years) and I have few questions:
Now OSGI is not only Module Management System but also IoC Container! It almost contains equivalent annotations for many of Spring IoC features. So How we can use Spring enabled modules inside OSGI? Can we eliminate Spring for our new designs and completely rely on OSGI? Or for dependency Injection within the modules we can use Spring and for Dependency injection over the Modules we can use OSGI?
For real-life large scale applications we have two options: Using Embedded Felix within application Container (e.g. Tomcat) or Using OSGI Bundle of Application Container (Jetty or Tomcat) within KARAF. Which approach is better? Which one is more scalable?
Researching OSGi can get confusing because there are 15 years of articles and examples out there - a lot of which are valid but may be out of date.
You could consider removing Spring if it was just used as an IoC container. OSGi DS provides #Component and #Reference annotations (like spring Autowire) if DS is enabled in your OSGi container. The new OSGi enroute project has some modern examples of performing IoC and providing REST services.
Replacing more of the features might be more work. Running the latest Spring in OSGi may not work due to the classloader differences in OSGi and the spring projects move away from OSGi.
OSGi is no IoC container at all. There are some technologies for injection support that run on OSGi though. The most important are declarative services and blueprint. Spring is not really supported. There is some Spring DM support but this code is not maintained for ages.
So you should use one of the two supported IoC containers above. For aries blueprint I have written support for CDI annotations using the maven-blueprint-plugin. This may be your best bet to convert the application. I recommend to first convert your spring application to use only CDI annotations and only then start the OSGi migration. Such a migration is not easy. Make sure you get some good coaching and consulting.
Embedded Felix on a servlet container is good if most of you application is non OSGi and you just want to use bundles for a very small part. Karaf is better if you want to write your whole application for OSGi.
What is the status of the current developments around Spring and OSGi?
It looks like things have gotten a bit quiet lately.
The latest version of the doc at (http://docs.spring.io/osgi/) is from 2009.
I see some announcements that Spring DM has become Eclipse Gemini Blueprint (http://www.eclipse.org/gemini/blueprint/documentation/migration/). But also there, the latest release is from August 2012.
Is Spring and OSGi a dead path? If so, what other options are there to make a spring application modular (e.g. allow deployment, starting, stopping & updating of a module within a running JVM)?
Thanks
I agre that spring on OSGi is a dead end. There does not seem to be any real drive in it since springsource abandoned OSGi.
There are some alternatives though. The most stable and complete one is Apache Aries at the moment. It provides blueprint support which is similar to spring xml and some extensions like jpa container managed transactions. Be aware though that aries still contains much less functionality then spring. So for example annotation support is very limited.
Alternatives to Aries blueprint are Declarative Services and pax CDI. Declarative services is very small footprint and quite stable and has great supports for the dynamics of OSGi. On the other hand it is even more limited than blueprint. So for example there is no special jpa support at all.
PAX CDI aims to provide Java EE on OSGi using Open Webbeans or Weld + some extensions like Deltaspike. Together it would provide similar comfort like Java EE 6. Unfortunately it is not completely finished so at the moment I would not yet consider it ready for production use.
Gemini Blueprint is still active, right now gemini blueprint upgraded to support R5 and M2 is available in the eclipse nexus.
This text is from the book called Core Java Server Faces:
It is a historical accident that there are two separate mechanisms,
CDI beans and JSF managed beans, for beans that can be used in JSF
pages. We suggest that you use CDI beans unless your application must
work on a plain servlet runner such as Tomcat. The source code for the
book comes in two versions, one with CDI beans (for Java EE 6
application servers) and one with JSF managed beans (for servlet
runners without CDI support).
My question is:
If I use the Spring Framework, and a Tomcat Server, will I need to use one of the beans mentioned above, or does Spring Framework come with its own bean implementations?
As far as I know, Spring Framework supports Dependency Injection. Does it support it if I run the application on Tomcat? Does it mean that I will be using neither the CDI beans nor the JSF Managed means mentioned in this book?
Thank you.
talking about container is more correct than bean implementation. Yes Spring comes with its own container. In fact you can see spring frameworks as a kind of alternative to the full Java EE stack.
Using Spring DI and CDI together has about no interest but you still can use JSF with spring on tomcat although if i would advise you to switch to a Java EE 6 web profile server instead of spring in this case.
Spring comes with is own view framework implementation named spring mvc.
All of this can run perfectly on any servlet container (jetty tomcat etc...) on condition that you provide associated dependencies ofc.