Re: PAX:WEB How many war bundles do pax-web support?

[Niclas Hedhman]

Wasn't history preserved when we moved to Github? I don't see Alin's work
pre-2010...

Niclas

On Mon, Oct 3, 2016 at 12:35 AM, 'Achim Nierbeck' via OPS4J <
ops4j@googlegroups.com> wrote:

> About a person year, with the prerequisite that the current implementation
> is well known.
>
> 1) Not really, certain people working on the code are paid to do so.
> 2) Nope, it's an open source project most people working on this do this
> in their private time.
> Sometimes those people (like me) don't even work on any related stuf
> anymore.
> 3) Hard to tell ... as we have people which get engaged for certain topics
> which move off after a certain amount of time
> Here's a complete list of recent developers [1]
>
>
> regards, Achim
>
> [1] - https://github.com/ops4j/org.ops4j.pax.web/graphs/contributors
>
> 2016-10-02 18:20 GMT+02:00 Pavel Kastornyy :
>
>> Achim, thank you for the information. So about one person year
>> if I understand you right.
>>
>> Could you also shortly answer the following questions:
>>
>> 1) is there any financial help from any companies?
>> 2) has the community tried to draw investments into the product?
>> 3) how many active developers are there at this time?
>>
>> Best regards,
>>
>>
>>
>> On 02.10.2016 18:47, 'Achim Nierbeck' via OPS4J wrote:
>>
>>> wow, that's a tough one ... :D
>>>
>>> if you take a look at Openhub [1] ... it'll tell you it took about 57
>>> years
>>> [2], or at least it's the amount of work worth it ;)
>>>
>>> Anyway it's hard to estimate as I've spent the last 6 years improving on
>>> it. Never the less if I would work on it full time 8h day
>>> with the knowledge I have right now. One person could redo it within
>>> maybe
>>> a year. But it's a wild guess ... might be faster, might take longer ...
>>> Of course I would expect it to have the same features and possibilities
>>> it
>>> has which makes it different to other implementations of the HttpService
>>> etc. Right now we have about 500 unit and integration tests running with
>>> every build [3].
>>> That functionality I would expect to be available after the re-write ;)
>>>
>>> BUT, the nice thing is. We can always start with a new branch and work on
>>> that in parallel.
>>> If there are enough people to work on it it should work.
>>>
>>> [1] - https://www.openhub.net/p/pax-web
>>> [2] - https://www.openhub.net/p/pax-web/estimated_cost
>>> [3] - http://ci.ops4j.org/jenkins/job/org.ops4j.pax.web/1028/testReport/
>>>
>>>
>>>
>>>
>>> 2016-10-02 15:39 GMT+02:00 iJava :
>>>
>>> Hi Achim

 Could you say (from the top of your head) approximatively how many hours
 may these changes need - 100/1000/5000/1?

 Best regards,

 воскресенье, 2 октября 2016 г., 15:40:23 UTC+3 пользователь Achim
 Nierbeck
 написал:

> Sounds like a good and interesting idea ...
> Right now only from the top of my head:
> The Pax-Web Runtime and therefore the different Implementations aren't
> made for this right now. So this would need a complete rewrite of how
> we're
> handling it. Another point would be how would web and white-board
> extender
> work with it. We could think about wiring those two closer to the core.
> Never the less an application deploying servlets will always need to
> add
> the virtual host environment, working with defaults could take care of
> that.
>
> We could consider to start this with a complete rewrite of Pax-Web and
> therefore aim for a 7.0.
>
> BUT ... I fear I won't have enough time to takle this. Considering the
> amount of time I spent in the past and about what it would take to
> have all
> the functionalities of Pax-Web re-written, and especially with my
> $dayJob +
> Family.
>
> regards, Achim
>
>
>
> 2016-10-02 5:35 GMT+02:00 Niclas Hedhman :
>
> Honestly, if this is to be fixed, I think Pax Web should support
>> Managed
>> Service Factory, and instantiate separate virtual host services
>> according
>> to a provided configuration. That configuration should contain which
>> WAB(s)
>> goes into that virtual host, together with any other virtual host
>> configuration.
>>
>> To me, that seems to be the right solution forward, maintains OSGi
>> compatibility, doesn't introduce new config args on WABs and doesn't
>> treat
>> "one domain" different than another.
>>
>> I think the tricky bit is to make the default case and the MSF
>> instantiations play nicely with each other, but that is an design
>> implementation detail at this stage.
>>
>> Cheers
>> Niclas
>>
>> On Sat, Oct 1, 2016 at 4:49 PM, iJava  wrote:
>>
>> I analyzed situation again and I am sure I am right. How I explain
>>> this
>>> - if *only*
>>> web-contextpath is used then all 

Re: PAX:WEB How many war bundles do pax-web support?

[Marc Schlegel]

Here are my two cents

Regarding the whiteboard-extender, I was actually thinking of moving this 
into the webcontainer, because due to the whiteboard-dto spec those two are 
closely related anyways. My idea was to deprecate the (upcoming) 
WhiteboardManager-service right away in order to merge those two modules in 
a 7.0 release. So that might solve one pain-point.

But another question is: do we need to rewrite everything in order to get a 
feature which might no be needed? Without knowing the business-case behind 
registering multiple contexts with the same name in different 
virtual-hosts, I still think that there are much cheaper alternatives: 
everything today moves away from heavy-installations (AppServers) in favor 
of dedicated containers. With OSGi and Pax-Web you can easily spawn 
multiple VMs, and have some proxy/webserver in front which manages the 
site/domain to look like one.

regards
Marc


Am Sonntag, 2. Oktober 2016 15:39:45 UTC+2 schrieb iJava:
>
> Hi Achim
>
> Could you say (from the top of your head) approximatively how many hours 
> may these changes need - 100/1000/5000/1?
>
> Best regards,
>
> воскресенье, 2 октября 2016 г., 15:40:23 UTC+3 пользователь Achim Nierbeck 
> написал:
>>
>> Sounds like a good and interesting idea ... 
>> Right now only from the top of my head:
>> The Pax-Web Runtime and therefore the different Implementations aren't 
>> made for this right now. So this would need a complete rewrite of how we're 
>> handling it. Another point would be how would web and white-board extender 
>> work with it. We could think about wiring those two closer to the core. 
>> Never the less an application deploying servlets will always need to add 
>> the virtual host environment, working with defaults could take care of that.
>>
>> We could consider to start this with a complete rewrite of Pax-Web and 
>> therefore aim for a 7.0.
>>  
>> BUT ... I fear I won't have enough time to takle this. Considering the 
>> amount of time I spent in the past and about what it would take to have all 
>> the functionalities of Pax-Web re-written, and especially with my $dayJob + 
>> Family. 
>>
>> regards, Achim 
>>
>>
>>
>> 2016-10-02 5:35 GMT+02:00 Niclas Hedhman :
>>
>>> Honestly, if this is to be fixed, I think Pax Web should support Managed 
>>> Service Factory, and instantiate separate virtual host services according 
>>> to a provided configuration. That configuration should contain which WAB(s) 
>>> goes into that virtual host, together with any other virtual host 
>>> configuration.
>>>
>>> To me, that seems to be the right solution forward, maintains OSGi 
>>> compatibility, doesn't introduce new config args on WABs and doesn't treat 
>>> "one domain" different than another.
>>>
>>> I think the tricky bit is to make the default case and the MSF 
>>> instantiations play nicely with each other, but that is an design 
>>> implementation detail at this stage.
>>>
>>> Cheers
>>> Niclas
>>>
>>> On Sat, Oct 1, 2016 at 4:49 PM, iJava  wrote:
>>>
 I analyzed situation again and I am sure I am right. How I explain this 
 - if *only*
 web-contextpath is used then all war bundles (wabs) are inside one 
 domain.
 Obvious if you need more then one domains (virtualhosts) this 
 limitation is 
 unpleasant. So I am sure that when bundle is deployed it must have 
 *two*
 settings:
   Layer one - virtualhosts (plural)
   Layer two - web-contextpath.
 In this case the deployer has all the advantages. He can create N sites
 And inside every virtualhost he can make N contexts if he needs.

 I am sure that this functionality must be developed. Pax-web is great 
 product
 and with such functionality it will have all main functionality of a 
 good web server.

 I would be glad to hear others opinion about such New Feature.

 Best regards,


 пятница, 30 сентября 2016 г., 18:14:33 UTC+3 пользователь iJava написал:

> Ok Achim.
>
> I understood the situation. You know the architecture of pax-web well. 
> Could you say - how difficult
> it can be to make some extender (plugin etc) to link wabs not to 
> web-contextpath but to virtualhosts
> and to make them all work with one port like it is in usual web 
> servers (for example apache).
> Please, note I don't care about specification - I care about normal 
> work.
>
> Best regards,
>
> пятница, 30 сентября 2016 г., 18:06:23 UTC+3 пользователь Achim 
> Nierbeck написал:
>>
>> I never said Pax-Web is a complete replacement for GlassFish, 
>> it's a WebContainer for OSGi environments, which fulfills the OSGi 
>> spec. 
>> It uses Jetty, Undertow or Tomcat to do so. AND it gives you most of 
>> the benefits of those underlying servers in the 
>> same way. If you're not satisfied because you expect something 
>> different. I'm 

Re: PAX:WEB How many war bundles do pax-web support?

[Pavel Kastornyy]

Ok, Achim. Thank you for detailed answers.

I currently need and use only the following subprojects:

pax-web-api-6.0.0-SNAPSHOT.jar
pax-web-deployer-6.0.0-SNAPSHOT.jar
pax-web-descriptor-6.0.0-SNAPSHOT.jar
pax-web-extender-war-6.0.0-SNAPSHOT.jar
pax-web-extender-whiteboard-6.0.0-SNAPSHOT.jar
pax-web-jetty-6.0.0-SNAPSHOT.jar
pax-web-jsp-6.0.0-SNAPSHOT.jar
pax-web-runtime-6.0.0-SNAPSHOT.jar
pax-web-spi-6.0.0-SNAPSHOT.jar

Firstly I will take some time to study them. If after analysis I can 
find and suggest some

solution which will require not so much time I will discuss it with you.

But I say in advance that if I will do something, it will be linked only 
with subprojects

I need and use. I think the reason can be easily understood.

Best regards,

On 02.10.2016 19:35, 'Achim Nierbeck' via OPS4J wrote:

About a person year, with the prerequisite that the current implementation
is well known.

1) Not really, certain people working on the code are paid to do so.
2) Nope, it's an open source project most people working on this do this in
their private time.
 Sometimes those people (like me) don't even work on any related stuf
anymore.
3) Hard to tell ... as we have people which get engaged for certain topics
which move off after a certain amount of time
 Here's a complete list of recent developers [1]


regards, Achim

[1] - https://github.com/ops4j/org.ops4j.pax.web/graphs/contributors

2016-10-02 18:20 GMT+02:00 Pavel Kastornyy :


Achim, thank you for the information. So about one person year
if I understand you right.

Could you also shortly answer the following questions:

1) is there any financial help from any companies?
2) has the community tried to draw investments into the product?
3) how many active developers are there at this time?

Best regards,



On 02.10.2016 18:47, 'Achim Nierbeck' via OPS4J wrote:


wow, that's a tough one ... :D

if you take a look at Openhub [1] ... it'll tell you it took about 57
years
[2], or at least it's the amount of work worth it ;)

Anyway it's hard to estimate as I've spent the last 6 years improving on
it. Never the less if I would work on it full time 8h day
with the knowledge I have right now. One person could redo it within maybe
a year. But it's a wild guess ... might be faster, might take longer ...
Of course I would expect it to have the same features and possibilities it
has which makes it different to other implementations of the HttpService
etc. Right now we have about 500 unit and integration tests running with
every build [3].
That functionality I would expect to be available after the re-write ;)

BUT, the nice thing is. We can always start with a new branch and work on
that in parallel.
If there are enough people to work on it it should work.

[1] - https://www.openhub.net/p/pax-web
[2] - https://www.openhub.net/p/pax-web/estimated_cost
[3] - http://ci.ops4j.org/jenkins/job/org.ops4j.pax.web/1028/testReport/




2016-10-02 15:39 GMT+02:00 iJava :

Hi Achim

Could you say (from the top of your head) approximatively how many hours
may these changes need - 100/1000/5000/1?

Best regards,

воскресенье, 2 октября 2016 г., 15:40:23 UTC+3 пользователь Achim
Nierbeck
написал:


Sounds like a good and interesting idea ...
Right now only from the top of my head:
The Pax-Web Runtime and therefore the different Implementations aren't
made for this right now. So this would need a complete rewrite of how
we're
handling it. Another point would be how would web and white-board
extender
work with it. We could think about wiring those two closer to the core.
Never the less an application deploying servlets will always need to add
the virtual host environment, working with defaults could take care of
that.

We could consider to start this with a complete rewrite of Pax-Web and
therefore aim for a 7.0.

BUT ... I fear I won't have enough time to takle this. Considering the
amount of time I spent in the past and about what it would take to have
all
the functionalities of Pax-Web re-written, and especially with my
$dayJob +
Family.

regards, Achim



2016-10-02 5:35 GMT+02:00 Niclas Hedhman :

Honestly, if this is to be fixed, I think Pax Web should support Managed

Service Factory, and instantiate separate virtual host services
according
to a provided configuration. That configuration should contain which
WAB(s)
goes into that virtual host, together with any other virtual host
configuration.

To me, that seems to be the right solution forward, maintains OSGi
compatibility, doesn't introduce new config args on WABs and doesn't
treat
"one domain" different than another.

I think the tricky bit is to make the default case and the MSF
instantiations play nicely with each other, but that is an design
implementation detail at this stage.

Cheers
Niclas

On Sat, Oct 1, 2016 at 4:49 PM, iJava  wrote:

I analyzed situation again and I am sure I am right. How I explain 

Re: PAX:WEB How many war bundles do pax-web support?

['Achim Nierbeck' via OPS4J]

About a person year, with the prerequisite that the current implementation
is well known.

1) Not really, certain people working on the code are paid to do so.
2) Nope, it's an open source project most people working on this do this in
their private time.
Sometimes those people (like me) don't even work on any related stuf
anymore.
3) Hard to tell ... as we have people which get engaged for certain topics
which move off after a certain amount of time
Here's a complete list of recent developers [1]


regards, Achim

[1] - https://github.com/ops4j/org.ops4j.pax.web/graphs/contributors

2016-10-02 18:20 GMT+02:00 Pavel Kastornyy :

> Achim, thank you for the information. So about one person year
> if I understand you right.
>
> Could you also shortly answer the following questions:
>
> 1) is there any financial help from any companies?
> 2) has the community tried to draw investments into the product?
> 3) how many active developers are there at this time?
>
> Best regards,
>
>
>
> On 02.10.2016 18:47, 'Achim Nierbeck' via OPS4J wrote:
>
>> wow, that's a tough one ... :D
>>
>> if you take a look at Openhub [1] ... it'll tell you it took about 57
>> years
>> [2], or at least it's the amount of work worth it ;)
>>
>> Anyway it's hard to estimate as I've spent the last 6 years improving on
>> it. Never the less if I would work on it full time 8h day
>> with the knowledge I have right now. One person could redo it within maybe
>> a year. But it's a wild guess ... might be faster, might take longer ...
>> Of course I would expect it to have the same features and possibilities it
>> has which makes it different to other implementations of the HttpService
>> etc. Right now we have about 500 unit and integration tests running with
>> every build [3].
>> That functionality I would expect to be available after the re-write ;)
>>
>> BUT, the nice thing is. We can always start with a new branch and work on
>> that in parallel.
>> If there are enough people to work on it it should work.
>>
>> [1] - https://www.openhub.net/p/pax-web
>> [2] - https://www.openhub.net/p/pax-web/estimated_cost
>> [3] - http://ci.ops4j.org/jenkins/job/org.ops4j.pax.web/1028/testReport/
>>
>>
>>
>>
>> 2016-10-02 15:39 GMT+02:00 iJava :
>>
>> Hi Achim
>>>
>>> Could you say (from the top of your head) approximatively how many hours
>>> may these changes need - 100/1000/5000/1?
>>>
>>> Best regards,
>>>
>>> воскресенье, 2 октября 2016 г., 15:40:23 UTC+3 пользователь Achim
>>> Nierbeck
>>> написал:
>>>
 Sounds like a good and interesting idea ...
 Right now only from the top of my head:
 The Pax-Web Runtime and therefore the different Implementations aren't
 made for this right now. So this would need a complete rewrite of how
 we're
 handling it. Another point would be how would web and white-board
 extender
 work with it. We could think about wiring those two closer to the core.
 Never the less an application deploying servlets will always need to add
 the virtual host environment, working with defaults could take care of
 that.

 We could consider to start this with a complete rewrite of Pax-Web and
 therefore aim for a 7.0.

 BUT ... I fear I won't have enough time to takle this. Considering the
 amount of time I spent in the past and about what it would take to have
 all
 the functionalities of Pax-Web re-written, and especially with my
 $dayJob +
 Family.

 regards, Achim



 2016-10-02 5:35 GMT+02:00 Niclas Hedhman :

 Honestly, if this is to be fixed, I think Pax Web should support Managed
> Service Factory, and instantiate separate virtual host services
> according
> to a provided configuration. That configuration should contain which
> WAB(s)
> goes into that virtual host, together with any other virtual host
> configuration.
>
> To me, that seems to be the right solution forward, maintains OSGi
> compatibility, doesn't introduce new config args on WABs and doesn't
> treat
> "one domain" different than another.
>
> I think the tricky bit is to make the default case and the MSF
> instantiations play nicely with each other, but that is an design
> implementation detail at this stage.
>
> Cheers
> Niclas
>
> On Sat, Oct 1, 2016 at 4:49 PM, iJava  wrote:
>
> I analyzed situation again and I am sure I am right. How I explain this
>> - if *only*
>> web-contextpath is used then all war bundles (wabs) are inside one
>> domain.
>> Obvious if you need more then one domains (virtualhosts) this
>> limitation is
>> unpleasant. So I am sure that when bundle is deployed it must have
>> *two*
>>
>> settings:
>>Layer one - virtualhosts (plural)
>>Layer two - web-contextpath.
>> In this case the 

Re: PAX:WEB How many war bundles do pax-web support?

[Pavel Kastornyy]

Achim, thank you for the information. So about one person year
if I understand you right.

Could you also shortly answer the following questions:

1) is there any financial help from any companies?
2) has the community tried to draw investments into the product?
3) how many active developers are there at this time?

Best regards,


On 02.10.2016 18:47, 'Achim Nierbeck' via OPS4J wrote:

wow, that's a tough one ... :D

if you take a look at Openhub [1] ... it'll tell you it took about 57 years
[2], or at least it's the amount of work worth it ;)

Anyway it's hard to estimate as I've spent the last 6 years improving on
it. Never the less if I would work on it full time 8h day
with the knowledge I have right now. One person could redo it within maybe
a year. But it's a wild guess ... might be faster, might take longer ...
Of course I would expect it to have the same features and possibilities it
has which makes it different to other implementations of the HttpService
etc. Right now we have about 500 unit and integration tests running with
every build [3].
That functionality I would expect to be available after the re-write ;)

BUT, the nice thing is. We can always start with a new branch and work on
that in parallel.
If there are enough people to work on it it should work.

[1] - https://www.openhub.net/p/pax-web
[2] - https://www.openhub.net/p/pax-web/estimated_cost
[3] - http://ci.ops4j.org/jenkins/job/org.ops4j.pax.web/1028/testReport/




2016-10-02 15:39 GMT+02:00 iJava :


Hi Achim

Could you say (from the top of your head) approximatively how many hours
may these changes need - 100/1000/5000/1?

Best regards,

воскресенье, 2 октября 2016 г., 15:40:23 UTC+3 пользователь Achim Nierbeck
написал:

Sounds like a good and interesting idea ...
Right now only from the top of my head:
The Pax-Web Runtime and therefore the different Implementations aren't
made for this right now. So this would need a complete rewrite of how we're
handling it. Another point would be how would web and white-board extender
work with it. We could think about wiring those two closer to the core.
Never the less an application deploying servlets will always need to add
the virtual host environment, working with defaults could take care of that.

We could consider to start this with a complete rewrite of Pax-Web and
therefore aim for a 7.0.

BUT ... I fear I won't have enough time to takle this. Considering the
amount of time I spent in the past and about what it would take to have all
the functionalities of Pax-Web re-written, and especially with my $dayJob +
Family.

regards, Achim



2016-10-02 5:35 GMT+02:00 Niclas Hedhman :


Honestly, if this is to be fixed, I think Pax Web should support Managed
Service Factory, and instantiate separate virtual host services according
to a provided configuration. That configuration should contain which WAB(s)
goes into that virtual host, together with any other virtual host
configuration.

To me, that seems to be the right solution forward, maintains OSGi
compatibility, doesn't introduce new config args on WABs and doesn't treat
"one domain" different than another.

I think the tricky bit is to make the default case and the MSF
instantiations play nicely with each other, but that is an design
implementation detail at this stage.

Cheers
Niclas

On Sat, Oct 1, 2016 at 4:49 PM, iJava  wrote:


I analyzed situation again and I am sure I am right. How I explain this
- if *only*
web-contextpath is used then all war bundles (wabs) are inside one
domain.
Obvious if you need more then one domains (virtualhosts) this
limitation is
unpleasant. So I am sure that when bundle is deployed it must have
*two*
settings:
   Layer one - virtualhosts (plural)
   Layer two - web-contextpath.
In this case the deployer has all the advantages. He can create N sites
And inside every virtualhost he can make N contexts if he needs.

I am sure that this functionality must be developed. Pax-web is great
product
and with such functionality it will have all main functionality of a
good web server.

I would be glad to hear others opinion about such New Feature.

Best regards,


пятница, 30 сентября 2016 г., 18:14:33 UTC+3 пользователь iJava написал:


Ok Achim.

I understood the situation. You know the architecture of pax-web well.
Could you say - how difficult
it can be to make some extender (plugin etc) to link wabs not to
web-contextpath but to virtualhosts
and to make them all work with one port like it is in usual web
servers (for example apache).
Please, note I don't care about specification - I care about normal
work.

Best regards,

пятница, 30 сентября 2016 г., 18:06:23 UTC+3 пользователь Achim
Nierbeck написал:

I never said Pax-Web is a complete replacement for GlassFish,
it's a WebContainer for OSGi environments, which fulfills the OSGi
spec.
It uses Jetty, Undertow or Tomcat to do so. AND it gives you most of
the benefits of those underlying 

Re: PAX:WEB How many war bundles do pax-web support?

['Achim Nierbeck' via OPS4J]

wow, that's a tough one ... :D

if you take a look at Openhub [1] ... it'll tell you it took about 57 years
[2], or at least it's the amount of work worth it ;)

Anyway it's hard to estimate as I've spent the last 6 years improving on
it. Never the less if I would work on it full time 8h day
with the knowledge I have right now. One person could redo it within maybe
a year. But it's a wild guess ... might be faster, might take longer ...
Of course I would expect it to have the same features and possibilities it
has which makes it different to other implementations of the HttpService
etc. Right now we have about 500 unit and integration tests running with
every build [3].
That functionality I would expect to be available after the re-write ;)

BUT, the nice thing is. We can always start with a new branch and work on
that in parallel.
If there are enough people to work on it it should work.

[1] - https://www.openhub.net/p/pax-web
[2] - https://www.openhub.net/p/pax-web/estimated_cost
[3] - http://ci.ops4j.org/jenkins/job/org.ops4j.pax.web/1028/testReport/




2016-10-02 15:39 GMT+02:00 iJava :

> Hi Achim
>
> Could you say (from the top of your head) approximatively how many hours
> may these changes need - 100/1000/5000/1?
>
> Best regards,
>
> воскресенье, 2 октября 2016 г., 15:40:23 UTC+3 пользователь Achim Nierbeck
> написал:
>>
>> Sounds like a good and interesting idea ...
>> Right now only from the top of my head:
>> The Pax-Web Runtime and therefore the different Implementations aren't
>> made for this right now. So this would need a complete rewrite of how we're
>> handling it. Another point would be how would web and white-board extender
>> work with it. We could think about wiring those two closer to the core.
>> Never the less an application deploying servlets will always need to add
>> the virtual host environment, working with defaults could take care of that.
>>
>> We could consider to start this with a complete rewrite of Pax-Web and
>> therefore aim for a 7.0.
>>
>> BUT ... I fear I won't have enough time to takle this. Considering the
>> amount of time I spent in the past and about what it would take to have all
>> the functionalities of Pax-Web re-written, and especially with my $dayJob +
>> Family.
>>
>> regards, Achim
>>
>>
>>
>> 2016-10-02 5:35 GMT+02:00 Niclas Hedhman :
>>
>>> Honestly, if this is to be fixed, I think Pax Web should support Managed
>>> Service Factory, and instantiate separate virtual host services according
>>> to a provided configuration. That configuration should contain which WAB(s)
>>> goes into that virtual host, together with any other virtual host
>>> configuration.
>>>
>>> To me, that seems to be the right solution forward, maintains OSGi
>>> compatibility, doesn't introduce new config args on WABs and doesn't treat
>>> "one domain" different than another.
>>>
>>> I think the tricky bit is to make the default case and the MSF
>>> instantiations play nicely with each other, but that is an design
>>> implementation detail at this stage.
>>>
>>> Cheers
>>> Niclas
>>>
>>> On Sat, Oct 1, 2016 at 4:49 PM, iJava  wrote:
>>>
 I analyzed situation again and I am sure I am right. How I explain this
 - if *only*
 web-contextpath is used then all war bundles (wabs) are inside one
 domain.
 Obvious if you need more then one domains (virtualhosts) this
 limitation is
 unpleasant. So I am sure that when bundle is deployed it must have
 *two*
 settings:
   Layer one - virtualhosts (plural)
   Layer two - web-contextpath.
 In this case the deployer has all the advantages. He can create N sites
 And inside every virtualhost he can make N contexts if he needs.

 I am sure that this functionality must be developed. Pax-web is great
 product
 and with such functionality it will have all main functionality of a
 good web server.

 I would be glad to hear others opinion about such New Feature.

 Best regards,


 пятница, 30 сентября 2016 г., 18:14:33 UTC+3 пользователь iJava написал:

> Ok Achim.
>
> I understood the situation. You know the architecture of pax-web well.
> Could you say - how difficult
> it can be to make some extender (plugin etc) to link wabs not to
> web-contextpath but to virtualhosts
> and to make them all work with one port like it is in usual web
> servers (for example apache).
> Please, note I don't care about specification - I care about normal
> work.
>
> Best regards,
>
> пятница, 30 сентября 2016 г., 18:06:23 UTC+3 пользователь Achim
> Nierbeck написал:
>>
>> I never said Pax-Web is a complete replacement for GlassFish,
>> it's a WebContainer for OSGi environments, which fulfills the OSGi
>> spec.
>> It uses Jetty, Undertow or Tomcat to do so. AND it gives you most of
>> the benefits of those