Here's an idea: If I have to edit features I might as well edit "http" in standard-features.xml, and remove the Jetty and Pax Jetty bundle. Could I also actually replace Pax Web's HttpService bundle with another HttpService, such as the Felix Servlet Bridge HttpService? Or do dependent features have hard dependencies on Pax, rather than on a standard HttpService? Best regards Mike Achim Nierbeck wrote:
Hi Mike, ok I understand though I don't have much to offer right now. I know that it has been done already with Pax-Web so you might ask for this at the pax-web mailinglist how/if it has been done. I hope people will tell you how they did it. This way you could build your own ServletBridge. There had been some discussion about having one for Pax-Web also but we never did get far with this, and I never had the need to built one. At the end you might still need to adapt parts of the features again. regards, Achim 2013/7/5 Mike Wilson <[email protected]> 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/> -- 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/>
