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/>
