You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by Mike Wilson <mi...@hotmail.com> on 2013/07/05 01:42:33 UTC
karaf with servlet bridge (was: how best handle unwanted features brought in as dependencies?)
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 <mi...@hotmail.com>
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
Re: karaf with servlet bridge (was: how best handle unwanted features
brought in as dependencies?)
Posted by Achim Nierbeck <bc...@googlemail.com>.
Hi Mike,
yeah this might as well could be done.
Regards, Achim
2013/7/5 Mike Wilson <mi...@hotmail.com>
> **
> 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 <mi...@hotmail.com>
>
>> **
>> 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 <mi...@hotmail.com>
>>
>>> **
>>> 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 <mi...@hotmail.com>
>>>
>>>> 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/>
RE: karaf with servlet bridge (was: how best handle unwanted features brought in as dependencies?)
Posted by Mike Wilson <mi...@hotmail.com>.
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 <mi...@hotmail.com>
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 <mi...@hotmail.com>
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 <mi...@hotmail.com>
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/>
Re: karaf with servlet bridge (was: how best handle unwanted features
brought in as dependencies?)
Posted by Achim Nierbeck <bc...@googlemail.com>.
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 <mi...@hotmail.com>
> **
> 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 <mi...@hotmail.com>
>
>> **
>> 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 <mi...@hotmail.com>
>>
>>> 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/>
RE: karaf with servlet bridge (was: how best handle unwanted features brought in as dependencies?)
Posted by Mike Wilson <mi...@hotmail.com>.
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 <mi...@hotmail.com>
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 <mi...@hotmail.com>
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/>
Re: karaf with servlet bridge (was: how best handle unwanted features
brought in as dependencies?)
Posted by Achim Nierbeck <bc...@googlemail.com>.
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 <mi...@hotmail.com>
> **
> 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 <mi...@hotmail.com>
>
>> 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/>