Hi Mike, yeah this might as well could be done.
Regards, Achim 2013/7/5 Mike Wilson <[email protected]> > ** > 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/> > > -- 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/>
