Re: The default jetty configuration

[Achim Nierbeck]

Hi Benson,

looks like it, yes. But you could also register the configuration for your
static content as an OSGi service for ContextHandler. [1]

regards, Achim

[1] -
http://ops4j.github.io/pax/web/4.2.x/index.html#_advanced_jetty_configuration

2016-03-30 23:03 GMT+02:00 Benson Margulies :

> Achim,
>
> We build a Karaf Assembly that contains pax-web. The first time it starts
> up, a jetty.xml appears. I suppose that it is 'installing' pax-web at that
> point.
>
> So, we might want to grab that template and merge our own stuff into it
> rather than just package up a 'small' jetty.xml with our static content
> configuration.
>
>
> --benson
>
>
> On Wed, Mar 30, 2016 at 4:40 PM, Achim Nierbeck 
> wrote:
>
>> I'm pretty sure nothing will write a jetty.xml when karaf is started.
>> If you install pax-web for the first time it'll copy a jetty.xml as
>> "template" to the etc folder [1].
>> The way the feature service handles this, no it won't interfere, cause
>> only if the file doesn't exist it'll be copied.
>>
>> regarding the configuration, again take a look at the feature [1].
>>
>> regards, Achim
>>
>> [1] -
>> https://github.com/ops4j/org.ops4j.pax.web/blob/master/pax-web-features/src/main/resources/features.xml#L91-L96
>>
>>
>>
>> 2016-03-30 22:34 GMT+02:00 Benson Margulies :
>>
>>> We just noticed another fact.
>>>
>>> When Karaf starts up, pax-web or something writes out a jetty.xml to the
>>> etc directory where there was none before.
>>>
>>> Wouldn't this interfere with trying to change individual config
>>> parameters on the fly from the shell?
>>>
>>> If I have my own jetty.xml, it isn't replaced by some sort of merged-up
>>> config.
>>>
>>> It also writes out a cfg file, but that's less surprising to me.
>>>
>>> javax.servlet.context.tempdir =
>>> /Users/benson/x/rosapi1.5/assemblies/front-end/target/assembly/data/pax-web-jsp
>>> org.ops4j.pax.web.config.file =
>>> /Users/benson/x/rosapi1.5/assemblies/front-end/target/assembly/etc/jetty.xml
>>> org.osgi.service.http.port = 8181
>>>
>>> On Wed, Mar 30, 2016 at 3:52 PM, Achim Nierbeck >> > wrote:
>>>
 Hi Benson,

 yes, this is it. As demanded by the OSGi spec, the configuration for
 the server is done by configuration admin service.
 The jetty.xml is just available for convenience for specialized
 configurations. The same applies to the other two supported containers,
 Tomcat and Undertow.

 regards, Achim


 2016-03-30 21:34 GMT+02:00 Benson Margulies :

> OK, time for me to apologize.
>
> In the environment where I have a jetty.xml to add static content, I
> indeed have the setting in the cfg file.
>
> So, I decided to read the source. Here's the process I see, which
> elaborates on your email.
>
>
>1. 
> org.ops4j.pax.web.service.jetty.internal.ServerControllerImpl.Stopped#start
>creates the jetty server, passing in several config items from config 
> admin.
>2. If you supply a config.file, it might be a file, or it might be
>a directory, presumably containing multiple jetty XML files. You can 
> also
>supply a config.url, which presumably points to a single XML file. 
> However,
>if it's a dir and not a file, it's rejected as invalid. The URL takes
>precedence.
>3. Config admin wins over a classpath resource
>in org.ops4j.pax.web.service.jetty.internal.JettyServerImpl#start.
>4. The start method obtains the contents of the file, turns it
>into a resource, and passes it to Jetty configuration.
>5. The start method passes another set of config admin parameters
>to 
> org.ops4j.pax.web.service.jetty.internal.JettyServer#configureContext.
>6. 
> org.ops4j.pax.web.service.jetty.internal.ServerControllerImpl.Stopped#start
>looks to see if there is a 'master connector' as a result of processing
>whatever configuration came through above. If there isn't one, it 
> creates
>one programmatically.
>
> So, the net of all of this is that there is no jetty.xml file in the
> universe that represents the 'default configuration', and that a jetty.xml
> that defines no connectors on the port number from config admin is purely 
> a
> supplement to the automatic configuration.
>
> I'll see if I can some up with any way to reflect any of this into the
> doc as a proposed change.
>
>
> On Wed, Mar 30, 2016 at 2:50 PM, Achim Nierbeck <
> bcanh...@googlemail.com> wrote:
>
>> Hi Benson,
>>
>> please take a look at the pax-web documentation [1].
>> The rule of thumb for Pax-Web is:
>>
>> configuration given via configuration admin service overrules
>> anything configured via jetty.xml
>>
>> jetty.xml can be used for 

Re: The default jetty configuration

[Benson Margulies]

Achim,

We build a Karaf Assembly that contains pax-web. The first time it starts
up, a jetty.xml appears. I suppose that it is 'installing' pax-web at that
point.

So, we might want to grab that template and merge our own stuff into it
rather than just package up a 'small' jetty.xml with our static content
configuration.


--benson


On Wed, Mar 30, 2016 at 4:40 PM, Achim Nierbeck 
wrote:

> I'm pretty sure nothing will write a jetty.xml when karaf is started.
> If you install pax-web for the first time it'll copy a jetty.xml as
> "template" to the etc folder [1].
> The way the feature service handles this, no it won't interfere, cause
> only if the file doesn't exist it'll be copied.
>
> regarding the configuration, again take a look at the feature [1].
>
> regards, Achim
>
> [1] -
> https://github.com/ops4j/org.ops4j.pax.web/blob/master/pax-web-features/src/main/resources/features.xml#L91-L96
>
>
>
> 2016-03-30 22:34 GMT+02:00 Benson Margulies :
>
>> We just noticed another fact.
>>
>> When Karaf starts up, pax-web or something writes out a jetty.xml to the
>> etc directory where there was none before.
>>
>> Wouldn't this interfere with trying to change individual config
>> parameters on the fly from the shell?
>>
>> If I have my own jetty.xml, it isn't replaced by some sort of merged-up
>> config.
>>
>> It also writes out a cfg file, but that's less surprising to me.
>>
>> javax.servlet.context.tempdir =
>> /Users/benson/x/rosapi1.5/assemblies/front-end/target/assembly/data/pax-web-jsp
>> org.ops4j.pax.web.config.file =
>> /Users/benson/x/rosapi1.5/assemblies/front-end/target/assembly/etc/jetty.xml
>> org.osgi.service.http.port = 8181
>>
>> On Wed, Mar 30, 2016 at 3:52 PM, Achim Nierbeck 
>> wrote:
>>
>>> Hi Benson,
>>>
>>> yes, this is it. As demanded by the OSGi spec, the configuration for the
>>> server is done by configuration admin service.
>>> The jetty.xml is just available for convenience for specialized
>>> configurations. The same applies to the other two supported containers,
>>> Tomcat and Undertow.
>>>
>>> regards, Achim
>>>
>>>
>>> 2016-03-30 21:34 GMT+02:00 Benson Margulies :
>>>
 OK, time for me to apologize.

 In the environment where I have a jetty.xml to add static content, I
 indeed have the setting in the cfg file.

 So, I decided to read the source. Here's the process I see, which
 elaborates on your email.


1. 
 org.ops4j.pax.web.service.jetty.internal.ServerControllerImpl.Stopped#start
creates the jetty server, passing in several config items from config 
 admin.
2. If you supply a config.file, it might be a file, or it might be
a directory, presumably containing multiple jetty XML files. You can 
 also
supply a config.url, which presumably points to a single XML file. 
 However,
if it's a dir and not a file, it's rejected as invalid. The URL takes
precedence.
3. Config admin wins over a classpath resource
in org.ops4j.pax.web.service.jetty.internal.JettyServerImpl#start.
4. The start method obtains the contents of the file, turns it into
a resource, and passes it to Jetty configuration.
5. The start method passes another set of config admin parameters
to 
 org.ops4j.pax.web.service.jetty.internal.JettyServer#configureContext.
6. 
 org.ops4j.pax.web.service.jetty.internal.ServerControllerImpl.Stopped#start
looks to see if there is a 'master connector' as a result of processing
whatever configuration came through above. If there isn't one, it 
 creates
one programmatically.

 So, the net of all of this is that there is no jetty.xml file in the
 universe that represents the 'default configuration', and that a jetty.xml
 that defines no connectors on the port number from config admin is purely a
 supplement to the automatic configuration.

 I'll see if I can some up with any way to reflect any of this into the
 doc as a proposed change.


 On Wed, Mar 30, 2016 at 2:50 PM, Achim Nierbeck <
 bcanh...@googlemail.com> wrote:

> Hi Benson,
>
> please take a look at the pax-web documentation [1].
> The rule of thumb for Pax-Web is:
>
> configuration given via configuration admin service overrules anything
> configured via jetty.xml
>
> jetty.xml can be used for additional configuration which isn't
> configurable via properties / configuration admin service.
>
> Handlers are a special case, you can add those either via the
> jetty.xml or via OSGi services.
>
> regards, Achim
>
> [1] -
> http://ops4j.github.io/pax/web/4.2.x/index.html#_advanced_jetty_configuration
>
>
> 2016-03-30 18:26 GMT+02:00 Benson Margulies :
>
>> JB, something 

Re: The default jetty configuration

[Achim Nierbeck]

I'm pretty sure nothing will write a jetty.xml when karaf is started.
If you install pax-web for the first time it'll copy a jetty.xml as
"template" to the etc folder [1].
The way the feature service handles this, no it won't interfere, cause only
if the file doesn't exist it'll be copied.

regarding the configuration, again take a look at the feature [1].

regards, Achim

[1] -
https://github.com/ops4j/org.ops4j.pax.web/blob/master/pax-web-features/src/main/resources/features.xml#L91-L96



2016-03-30 22:34 GMT+02:00 Benson Margulies :

> We just noticed another fact.
>
> When Karaf starts up, pax-web or something writes out a jetty.xml to the
> etc directory where there was none before.
>
> Wouldn't this interfere with trying to change individual config parameters
> on the fly from the shell?
>
> If I have my own jetty.xml, it isn't replaced by some sort of merged-up
> config.
>
> It also writes out a cfg file, but that's less surprising to me.
>
> javax.servlet.context.tempdir =
> /Users/benson/x/rosapi1.5/assemblies/front-end/target/assembly/data/pax-web-jsp
> org.ops4j.pax.web.config.file =
> /Users/benson/x/rosapi1.5/assemblies/front-end/target/assembly/etc/jetty.xml
> org.osgi.service.http.port = 8181
>
> On Wed, Mar 30, 2016 at 3:52 PM, Achim Nierbeck 
> wrote:
>
>> Hi Benson,
>>
>> yes, this is it. As demanded by the OSGi spec, the configuration for the
>> server is done by configuration admin service.
>> The jetty.xml is just available for convenience for specialized
>> configurations. The same applies to the other two supported containers,
>> Tomcat and Undertow.
>>
>> regards, Achim
>>
>>
>> 2016-03-30 21:34 GMT+02:00 Benson Margulies :
>>
>>> OK, time for me to apologize.
>>>
>>> In the environment where I have a jetty.xml to add static content, I
>>> indeed have the setting in the cfg file.
>>>
>>> So, I decided to read the source. Here's the process I see, which
>>> elaborates on your email.
>>>
>>>
>>>1. 
>>> org.ops4j.pax.web.service.jetty.internal.ServerControllerImpl.Stopped#start
>>>creates the jetty server, passing in several config items from config 
>>> admin.
>>>2. If you supply a config.file, it might be a file, or it might be a
>>>directory, presumably containing multiple jetty XML files. You can also
>>>supply a config.url, which presumably points to a single XML file. 
>>> However,
>>>if it's a dir and not a file, it's rejected as invalid. The URL takes
>>>precedence.
>>>3. Config admin wins over a classpath resource
>>>in org.ops4j.pax.web.service.jetty.internal.JettyServerImpl#start.
>>>4. The start method obtains the contents of the file, turns it into
>>>a resource, and passes it to Jetty configuration.
>>>5. The start method passes another set of config admin parameters to
>>>org.ops4j.pax.web.service.jetty.internal.JettyServer#configureContext.
>>>6. 
>>> org.ops4j.pax.web.service.jetty.internal.ServerControllerImpl.Stopped#start
>>>looks to see if there is a 'master connector' as a result of processing
>>>whatever configuration came through above. If there isn't one, it creates
>>>one programmatically.
>>>
>>> So, the net of all of this is that there is no jetty.xml file in the
>>> universe that represents the 'default configuration', and that a jetty.xml
>>> that defines no connectors on the port number from config admin is purely a
>>> supplement to the automatic configuration.
>>>
>>> I'll see if I can some up with any way to reflect any of this into the
>>> doc as a proposed change.
>>>
>>>
>>> On Wed, Mar 30, 2016 at 2:50 PM, Achim Nierbeck >> > wrote:
>>>
 Hi Benson,

 please take a look at the pax-web documentation [1].
 The rule of thumb for Pax-Web is:

 configuration given via configuration admin service overrules anything
 configured via jetty.xml

 jetty.xml can be used for additional configuration which isn't
 configurable via properties / configuration admin service.

 Handlers are a special case, you can add those either via the jetty.xml
 or via OSGi services.

 regards, Achim

 [1] -
 http://ops4j.github.io/pax/web/4.2.x/index.html#_advanced_jetty_configuration


 2016-03-30 18:26 GMT+02:00 Benson Margulies :

> JB, something happens even if you do _not_ add that line to the pax
> web config file. I've added additional static content by just dropping in 
> a
> jetty.xml file that adds a connector. Is the difference that adding the
> web.cfg line causes your file to completely replace the default, instead 
> of
> supplementing it?
>
> I'm on this today because we're trying to establish the answer to the
> question of what idleTimeout is actually being used.
>
>
> On Wed, Mar 30, 2016 at 12:10 PM, Jean-Baptiste Onofré <
> 

Re: The default jetty configuration

[Benson Margulies]

We just noticed another fact.

When Karaf starts up, pax-web or something writes out a jetty.xml to the
etc directory where there was none before.

Wouldn't this interfere with trying to change individual config parameters
on the fly from the shell?

If I have my own jetty.xml, it isn't replaced by some sort of merged-up
config.

It also writes out a cfg file, but that's less surprising to me.

javax.servlet.context.tempdir =
/Users/benson/x/rosapi1.5/assemblies/front-end/target/assembly/data/pax-web-jsp
org.ops4j.pax.web.config.file =
/Users/benson/x/rosapi1.5/assemblies/front-end/target/assembly/etc/jetty.xml
org.osgi.service.http.port = 8181

On Wed, Mar 30, 2016 at 3:52 PM, Achim Nierbeck 
wrote:

> Hi Benson,
>
> yes, this is it. As demanded by the OSGi spec, the configuration for the
> server is done by configuration admin service.
> The jetty.xml is just available for convenience for specialized
> configurations. The same applies to the other two supported containers,
> Tomcat and Undertow.
>
> regards, Achim
>
>
> 2016-03-30 21:34 GMT+02:00 Benson Margulies :
>
>> OK, time for me to apologize.
>>
>> In the environment where I have a jetty.xml to add static content, I
>> indeed have the setting in the cfg file.
>>
>> So, I decided to read the source. Here's the process I see, which
>> elaborates on your email.
>>
>>
>>1. 
>> org.ops4j.pax.web.service.jetty.internal.ServerControllerImpl.Stopped#start
>>creates the jetty server, passing in several config items from config 
>> admin.
>>2. If you supply a config.file, it might be a file, or it might be a
>>directory, presumably containing multiple jetty XML files. You can also
>>supply a config.url, which presumably points to a single XML file. 
>> However,
>>if it's a dir and not a file, it's rejected as invalid. The URL takes
>>precedence.
>>3. Config admin wins over a classpath resource
>>in org.ops4j.pax.web.service.jetty.internal.JettyServerImpl#start.
>>4. The start method obtains the contents of the file, turns it into a
>>resource, and passes it to Jetty configuration.
>>5. The start method passes another set of config admin parameters to
>>org.ops4j.pax.web.service.jetty.internal.JettyServer#configureContext.
>>6. 
>> org.ops4j.pax.web.service.jetty.internal.ServerControllerImpl.Stopped#start
>>looks to see if there is a 'master connector' as a result of processing
>>whatever configuration came through above. If there isn't one, it creates
>>one programmatically.
>>
>> So, the net of all of this is that there is no jetty.xml file in the
>> universe that represents the 'default configuration', and that a jetty.xml
>> that defines no connectors on the port number from config admin is purely a
>> supplement to the automatic configuration.
>>
>> I'll see if I can some up with any way to reflect any of this into the
>> doc as a proposed change.
>>
>>
>> On Wed, Mar 30, 2016 at 2:50 PM, Achim Nierbeck 
>> wrote:
>>
>>> Hi Benson,
>>>
>>> please take a look at the pax-web documentation [1].
>>> The rule of thumb for Pax-Web is:
>>>
>>> configuration given via configuration admin service overrules anything
>>> configured via jetty.xml
>>>
>>> jetty.xml can be used for additional configuration which isn't
>>> configurable via properties / configuration admin service.
>>>
>>> Handlers are a special case, you can add those either via the jetty.xml
>>> or via OSGi services.
>>>
>>> regards, Achim
>>>
>>> [1] -
>>> http://ops4j.github.io/pax/web/4.2.x/index.html#_advanced_jetty_configuration
>>>
>>>
>>> 2016-03-30 18:26 GMT+02:00 Benson Margulies :
>>>
 JB, something happens even if you do _not_ add that line to the pax web
 config file. I've added additional static content by just dropping in a
 jetty.xml file that adds a connector. Is the difference that adding the
 web.cfg line causes your file to completely replace the default, instead of
 supplementing it?

 I'm on this today because we're trying to establish the answer to the
 question of what idleTimeout is actually being used.


 On Wed, Mar 30, 2016 at 12:10 PM, Jean-Baptiste Onofré  wrote:

> Correct.
>
> You can add in etc/org.ops4j.pax.web.cfg:
>
> org.ops4j.pax.web.config.file=${karaf.base}/etc/jetty.xml
>
> to provision your own jetty.xml.
>
> Regards
> JB
>
>
> On 03/30/2016 06:07 PM, Benson Margulies wrote:
>
>> Am I correct that none of the jetty.xml files in the Karaf source tree
>> are live in the standard package, and that the config falls back to
>> pax-web?
>>
>>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>


>>>
>>>
>>> --
>>>
>>> Apache Member
>>> Apache Karaf 

Re: The default jetty configuration

[Benson Margulies]

OK, time for me to apologize.

In the environment where I have a jetty.xml to add static content, I indeed
have the setting in the cfg file.

So, I decided to read the source. Here's the process I see, which
elaborates on your email.


   1. 
org.ops4j.pax.web.service.jetty.internal.ServerControllerImpl.Stopped#start
   creates the jetty server, passing in several config items from config admin.
   2. If you supply a config.file, it might be a file, or it might be a
   directory, presumably containing multiple jetty XML files. You can also
   supply a config.url, which presumably points to a single XML file. However,
   if it's a dir and not a file, it's rejected as invalid. The URL takes
   precedence.
   3. Config admin wins over a classpath resource
   in org.ops4j.pax.web.service.jetty.internal.JettyServerImpl#start.
   4. The start method obtains the contents of the file, turns it into a
   resource, and passes it to Jetty configuration.
   5. The start method passes another set of config admin parameters to
   org.ops4j.pax.web.service.jetty.internal.JettyServer#configureContext.
   6. 
org.ops4j.pax.web.service.jetty.internal.ServerControllerImpl.Stopped#start
   looks to see if there is a 'master connector' as a result of processing
   whatever configuration came through above. If there isn't one, it creates
   one programmatically.

So, the net of all of this is that there is no jetty.xml file in the
universe that represents the 'default configuration', and that a jetty.xml
that defines no connectors on the port number from config admin is purely a
supplement to the automatic configuration.

I'll see if I can some up with any way to reflect any of this into the doc
as a proposed change.


On Wed, Mar 30, 2016 at 2:50 PM, Achim Nierbeck 
wrote:

> Hi Benson,
>
> please take a look at the pax-web documentation [1].
> The rule of thumb for Pax-Web is:
>
> configuration given via configuration admin service overrules anything
> configured via jetty.xml
>
> jetty.xml can be used for additional configuration which isn't
> configurable via properties / configuration admin service.
>
> Handlers are a special case, you can add those either via the jetty.xml or
> via OSGi services.
>
> regards, Achim
>
> [1] -
> http://ops4j.github.io/pax/web/4.2.x/index.html#_advanced_jetty_configuration
>
>
> 2016-03-30 18:26 GMT+02:00 Benson Margulies :
>
>> JB, something happens even if you do _not_ add that line to the pax web
>> config file. I've added additional static content by just dropping in a
>> jetty.xml file that adds a connector. Is the difference that adding the
>> web.cfg line causes your file to completely replace the default, instead of
>> supplementing it?
>>
>> I'm on this today because we're trying to establish the answer to the
>> question of what idleTimeout is actually being used.
>>
>>
>> On Wed, Mar 30, 2016 at 12:10 PM, Jean-Baptiste Onofré 
>> wrote:
>>
>>> Correct.
>>>
>>> You can add in etc/org.ops4j.pax.web.cfg:
>>>
>>> org.ops4j.pax.web.config.file=${karaf.base}/etc/jetty.xml
>>>
>>> to provision your own jetty.xml.
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 03/30/2016 06:07 PM, Benson Margulies wrote:
>>>
 Am I correct that none of the jetty.xml files in the Karaf source tree
 are live in the standard package, and that the config falls back to
 pax-web?


>>> --
>>> Jean-Baptiste Onofré
>>> jbono...@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>
>>
>
>
> --
>
> Apache Member
> Apache Karaf  Committer & PMC
> OPS4J Pax Web  Committer &
> Project Lead
> blog 
> Co-Author of Apache Karaf Cookbook 
>
> Software Architect / Project Manager / Scrum Master
>
>

Re: The default jetty configuration

[Achim Nierbeck]

Hi Benson,

please take a look at the pax-web documentation [1].
The rule of thumb for Pax-Web is:

configuration given via configuration admin service overrules anything
configured via jetty.xml

jetty.xml can be used for additional configuration which isn't configurable
via properties / configuration admin service.

Handlers are a special case, you can add those either via the jetty.xml or
via OSGi services.

regards, Achim

[1] -
http://ops4j.github.io/pax/web/4.2.x/index.html#_advanced_jetty_configuration


2016-03-30 18:26 GMT+02:00 Benson Margulies :

> JB, something happens even if you do _not_ add that line to the pax web
> config file. I've added additional static content by just dropping in a
> jetty.xml file that adds a connector. Is the difference that adding the
> web.cfg line causes your file to completely replace the default, instead of
> supplementing it?
>
> I'm on this today because we're trying to establish the answer to the
> question of what idleTimeout is actually being used.
>
>
> On Wed, Mar 30, 2016 at 12:10 PM, Jean-Baptiste Onofré 
> wrote:
>
>> Correct.
>>
>> You can add in etc/org.ops4j.pax.web.cfg:
>>
>> org.ops4j.pax.web.config.file=${karaf.base}/etc/jetty.xml
>>
>> to provision your own jetty.xml.
>>
>> Regards
>> JB
>>
>>
>> On 03/30/2016 06:07 PM, Benson Margulies wrote:
>>
>>> Am I correct that none of the jetty.xml files in the Karaf source tree
>>> are live in the standard package, and that the config falls back to
>>> pax-web?
>>>
>>>
>> --
>> Jean-Baptiste Onofré
>> jbono...@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>


-- 

Apache Member
Apache Karaf  Committer & PMC
OPS4J Pax Web  Committer &
Project Lead
blog 
Co-Author of Apache Karaf Cookbook 

Software Architect / Project Manager / Scrum Master

Re: The default jetty configuration

[Benson Margulies]

JB, something happens even if you do _not_ add that line to the pax web
config file. I've added additional static content by just dropping in a
jetty.xml file that adds a connector. Is the difference that adding the
web.cfg line causes your file to completely replace the default, instead of
supplementing it?

I'm on this today because we're trying to establish the answer to the
question of what idleTimeout is actually being used.


On Wed, Mar 30, 2016 at 12:10 PM, Jean-Baptiste Onofré 
wrote:

> Correct.
>
> You can add in etc/org.ops4j.pax.web.cfg:
>
> org.ops4j.pax.web.config.file=${karaf.base}/etc/jetty.xml
>
> to provision your own jetty.xml.
>
> Regards
> JB
>
>
> On 03/30/2016 06:07 PM, Benson Margulies wrote:
>
>> Am I correct that none of the jetty.xml files in the Karaf source tree
>> are live in the standard package, and that the config falls back to
>> pax-web?
>>
>>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: The default jetty configuration

[Jean-Baptiste Onofré]

Correct.

You can add in etc/org.ops4j.pax.web.cfg:

org.ops4j.pax.web.config.file=${karaf.base}/etc/jetty.xml

to provision your own jetty.xml.

Regards
JB

On 03/30/2016 06:07 PM, Benson Margulies wrote:

Am I correct that none of the jetty.xml files in the Karaf source tree
are live in the standard package, and that the config falls back to pax-web?



--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

The default jetty configuration

[Benson Margulies]

Am I correct that none of the jetty.xml files in the Karaf source tree are
live in the standard package, and that the config falls back to pax-web?

Re: Embedding Karaf in a WAR (Tomcat)

[Nick Baker]

Our current approach is also a "migration" strategy. This is an unfortunate 
reality for those with large existing code-bases.

We anticipate "flipping the architecture" soon which will put Everything in 
Karaf. The non-OSGI libraries will be collected together as a "legacy" bundle. 
At that point we'll be leveraging PAX-Web instead of deploying inside an 
existing servlet container.

-Nick

From: Serge Huber >
Reply-To: "user@karaf.apache.org" 
>
Date: Wednesday, March 30, 2016 at 3:21 AM
To: "user@karaf.apache.org" 
>
Subject: Re: Embedding Karaf in a WAR (Tomcat)

Hi Achim and Martin,

Actually my own company is going through this transition, but for the moment 
our main application (CMS) still has to be deployed within web containers such 
as Tomcat or WebSphere. So using an Http Bridge is a hard requirement for the 
moment.

As soon as we can drop this requirement we will but in the meantime we want a 
bridge that can be as feature-ful as possible. Currently we use the Felix Http 
Bridge in production but I’m really hoping we can switch to the new Pax Web 
Bridge soon, as it is a *lot* better.

Yes it is indeed strange to have this bridge because you can potentially have a 
web application within a web application (but at the same time this is kinda 
cool, ok I’m a nerd :)). Anyway, I believe it can be an interesting migration 
path for a lot of existing web applications out there.

Let’s get everyone on Karaf & Pax Web :) Who needs Node.js ? :)

cheers,
  Serge…


On 29 mars 2016, at 17:47, Achim Nierbeck 
> wrote:

Hi Martin,

I'm still in favor of using plain Karaf with Web-Container instead of the 
opposite, but I can see the benefits for easier transition of doing the bridge 
thing. Thanks to the Help of Serge, we now have a special branch [1], cause the 
bridge is still work-in-progress [2].

regards, Achim

[1] - https://github.com/ops4j/org.ops4j.pax.web/tree/PAXWEB-606-Servlet-Bridge
[2] - https://ops4j1.jira.com/browse/PAXWEB-606

2016-03-29 16:45 GMT+02:00 mjelen 
>:
Hi Serge,

thank you for your reply! I'll look into the PAX Web Bridge, I guess the
right place to talk about it is the OPS4J Google Group.

I admit I haven't thought of looking at PAX Web for my purpose because I'd
seen it as having the opposite purpose of what I'm looking for - that is,
starting an embedded Tomcat (or Jetty or Undertow) rather than running
inside a Tomcat instance. Especially since I've read several comments from
Achim dissuading people from embedding Karaf in Tomcat (which I can
understand, I'm not happy about it myself and I'll keep trying to get rid of
this requirement).

Regards
Martin



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Embedding-Karaf-in-a-WAR-Tomcat-tp4045931p4046031.html
Sent from the Karaf - User mailing list archive at 
Nabble.com.



--

Apache Member
Apache Karaf  Committer & PMC
OPS4J Pax Web  Committer & 
Project Lead
blog 
Co-Author of Apache Karaf Cookbook 

Software Architect / Project Manager / Scrum Master

Re: Embedding Karaf in a WAR (Tomcat)

[Serge Huber]

Hi Achim and Martin, 

Actually my own company is going through this transition, but for the moment 
our main application (CMS) still has to be deployed within web containers such 
as Tomcat or WebSphere. So using an Http Bridge is a hard requirement for the 
moment. 

As soon as we can drop this requirement we will but in the meantime we want a 
bridge that can be as feature-ful as possible. Currently we use the Felix Http 
Bridge in production but I’m really hoping we can switch to the new Pax Web 
Bridge soon, as it is a *lot* better.

Yes it is indeed strange to have this bridge because you can potentially have a 
web application within a web application (but at the same time this is kinda 
cool, ok I’m a nerd :)). Anyway, I believe it can be an interesting migration 
path for a lot of existing web applications out there. 

Let’s get everyone on Karaf & Pax Web :) Who needs Node.js ? :) 

cheers,
  Serge… 


> On 29 mars 2016, at 17:47, Achim Nierbeck  wrote:
> 
> Hi Martin, 
> 
> I'm still in favor of using plain Karaf with Web-Container instead of the 
> opposite, but I can see the benefits for easier transition of doing the 
> bridge thing. Thanks to the Help of Serge, we now have a special branch [1], 
> cause the bridge is still work-in-progress [2].
> 
> regards, Achim 
> 
> [1] - 
> https://github.com/ops4j/org.ops4j.pax.web/tree/PAXWEB-606-Servlet-Bridge 
> 
> [2] - https://ops4j1.jira.com/browse/PAXWEB-606 
>  
> 
> 2016-03-29 16:45 GMT+02:00 mjelen  >:
> Hi Serge,
> 
> thank you for your reply! I'll look into the PAX Web Bridge, I guess the
> right place to talk about it is the OPS4J Google Group.
> 
> I admit I haven't thought of looking at PAX Web for my purpose because I'd
> seen it as having the opposite purpose of what I'm looking for - that is,
> starting an embedded Tomcat (or Jetty or Undertow) rather than running
> inside a Tomcat instance. Especially since I've read several comments from
> Achim dissuading people from embedding Karaf in Tomcat (which I can
> understand, I'm not happy about it myself and I'll keep trying to get rid of
> this requirement).
> 
> Regards
> Martin
> 
> 
> 
> --
> View this message in context: 
> http://karaf.922171.n3.nabble.com/Embedding-Karaf-in-a-WAR-Tomcat-tp4045931p4046031.html
>  
> 
> Sent from the Karaf - User mailing list archive at Nabble.com.
> 
> 
> 
> -- 
> 
> Apache Member
> Apache Karaf > Committer 
> & PMC
> OPS4J Pax Web  > Committer & Project Lead
> blog >
> Co-Author of Apache Karaf Cookbook  >
> 
> Software Architect / Project Manager / Scrum Master 
>