Ouch, that was bad news for us. It seems our project has to take a step
back, review our options and maybe go back to running a bare OSGi container.
Reusing the existing feature definitions was one of the main drivers for
Karaf.
In short, the reason why we can't use Karaf standalone is IT policy. I'm
working for a large company with lots of rules around server setups and
deployments. Another department chooses preferred app server products and
the only way to deploy something is to provide a WAR file. So our workaround
to be able to use OSGi at all is to embed it in a WAR. And we can't use any
bundled web server (like pax jetty) as we are forced to use the app server
for that (f ex session replication is configured there). I'm sorry, but
these rules are a discussion for another day, and for other parts of my
company.
The people who chose to go with Karaf at my department had the impression
that embedding in another web container was supported. It seems they didn't
go to the bottom of this but say it was mentioned in the manual (I only find
it mentioned as a "describe todo" in the 2.1 manual) and in demos:
demos/web/README.txt
EMBEDDING KARAF IN A WEB APPLICATION
...
A. Using Jetty: Quick and Easy
...
B. Using Your Favorite Web Container
When inspecting this demo it seems it's only an embedded way to start Karaf,
and does not integrate any web functionality in Karaf with the outside
container.
I think it would be appropriate to clarify this in the example.
So this doesn't look so good for our usage of Karaf.
Are there any other suggestions on how we could solve this?
Best regards
Mike
Achim Nierbeck wrote:
Hi Mike,
well the spring-jms feature depends on the spring-web feature which again
depends on the http feature where Pax-Web and Jetty are the providing
bundles.
I still didn't get why you are actually in need of running inside Tomcat and
why it's not sufficient to run Karaf as is, since that is the preferred way
of running.
But back to your Issue, there is no ServletBridge available at least to my
understanding. The pax-exam project your talking of is used for testing
only, so this isn't a ServletBridge as provided by Felix. AFAIK there is
only one ServletBridge, it's the one from Felix. So you end up in
implementing this on your own. Regarding stripping out Pax-Web/Jetty from
Karaf won't work unless you provide your own feature set. So most likely you
will need to depend on the karaf minimal distribution and assembly your own
distribution.
Again this is only because you're trying to embed a OSGi-Container in a
Web-Container where the OSGi-Container already embeds a Web-Container (Jetty
in this case).
You really should rethink the deployment scenario, Obviously your in need of
OSGi capabilities and seem to be satisfied by Karaf, so why not use Karaf as
your OSGi/Web-Container?
Regards, Achim
2013/7/5 Mike Wilson <[email protected]>
Thanks Achim,
I didn't realize I was diverting from the favored way. Actually, I wasn't
aware of Pax being provisioned at all with my current feature set, as I
didn't expect any web stuff to be needed by them. Like Spring JMS that
normally wouldn't depend on web APIs, but in the Karaf feature world it
seems it does. I see many other features are quite eager to depend on "war"
or "http", so I get what you're saying about having to handle many things
manually. This is exactly what I don't want to do. The Felix Servlet Bridge
seemed like a good match as we're running on Felix, but we could change
that.
Is there any production quality servlet bridge available that we can use
with Pax? A search turned up the pax-exam-servlet-bridge module (3.x
version); is this what you had in mind and does it work with Pax 1.1.3 as
used in Karaf 2.3.0? I'd like to avoid having to roll my own.
After solving the servlet bridge matters, I'm thinking we need to disable
Jetty that is part of the standard http feature. How is this best done?
Best regards
Mike
Achim Nierbeck wrote:
Hi,
your scenario isn't really the favored way of using Karaf, why don't you use
Karaf as is?
Because of Pax-Web it will give you all that a std. Web-Container is capable
of and complies to the OSGi HTTP-Service spec.
To solve your issue you will need to install all required bundles without
features since those
usually depent on Pax-Web as it is the favored web container.
Another way of doing this could be to dump the felix http service and use a
custom adapted ServletBridge that uses the Pax-Web
implementation, it can be done. I know that there is a project that uses
Pax-Web with a custom ServletBridge.
regards, Achim
2013/7/4 Mike Wilson <[email protected]>
We are using Karaf (currently 2.3.0) embedded in Tomcat, using
the Felix Servlet Bridge to expose various functionality on
web pages.
On some startups (random behaviour) our OSGi:fied web servlets
are not reachable through Tomcat, and after some digging I've
found that this problem goes away if I remove the spring-jms,
feature because it is bringing in Pax Web:
spring-jms -> spring-web -> http (= Pax Web incl Jetty)
So I guess Felix and Pax Web will be competing about registering
web artifacts, therefore the random behaviour.
My question is how can we best resolve this problem? It seems a
lot of libraries we use end up referring to the "war" or "http"
features, bringing in Pax and its Jetty server, but we want to
do our web traffic through Tomcat via the servlet bridge.
How do we best override this behaviour? We'd like to stay on
"standard Karaf" as much as possible (to make upgrades easier)
so a solution with few and simple edits is desired...
Thanks
Mike Wilson
--
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home>
Commiter & Project Lead
blog <http://notizblog.nierbeck.de/>
