Hi Achim

Are you there? Will you answer to my suggestion?

Best regards,

понедельник, 10 октября 2016 г., 9:07:15 UTC+3 пользователь iJava написал:
>
> Hi Achim
>
> Thank you for detailed explanation. However, I think soon google mailing 
> list will complain
> about our bla-bla-bla because there is still no result.
>
> Lets get closer to business.
> So, I think that web-contextpath musn't be across all connectors because 
> it's logically wrong.
>
> What I suggest after short analysis is:
> 1) The solution must be absolute backward compatible with pax-web 6.0. (I 
> need this feature
> and I can't wait ? time for version 7.0.0)
> 2) In deployed bundles there will be an optional(!) Virtual-Hosts setting 
> in manifest of war bundle.
> I think that even it there is any virtual-host settings separate from 
> bundles in the future,
>  it is bundle that must say to which virtual host it wants to belong to.
> 3) We add virtualHosts collection to org.ops4j.pax.web.service.spi.
> model.ServerModel + 
> fix all match* methods. Besides we fix match* in 
> JettyServerHandlerCollection 
> 4) it is necessary to allow war bundles with the same context if the have 
> virtual-hosts setting.
> I haven't looked yet where it can be done.
> 5) The suggested solution is a "first attempt" to see how it will be like 
> and will not
> require much time (which is the problem #1). If someone has time in future 
> he\she can
> always make the solution better.
>
> What will you say? 
>
> P.S. I considered only for jetty as I wrote above.
>
>
>
> понедельник, 10 октября 2016 г., 0:03:28 UTC+3 пользователь Achim Nierbeck 
> написал:
>>
>> I fully understand your problem, but it can't be solved easily. 
>> The registration of the Web-ContextPath is per Bundle and over all 
>> available Connections, while
>> the VirtualHost component only makes sure it's only available to 
>> VirtualHost X and the default Connector, while it's not available to 
>> VirtualHost Y. 
>>
>> So for example the following integration Test [1] shows it, the War is 
>> registered on the given ContextPath and for the given VirtualHost. The 
>> second tests this with the second connector [2]. 
>>
>> The Web-ContextPath is verified while the WABs are registerd through the 
>> web-Extender. [3]
>> And there a second WAB with the same Web-ContextPath is put on hold. 
>>
>> While the VirtualHost is added to the registering Bundle after the 
>> Web-ContextPath is registered, the final connection between the Bundle 
>> HttpContext (bound to the Bundle Context and therefore also to the 
>> WebContext path) is done while registering the HttpContext. 
>>
>> So what I got from your descriptions you actually require the second part 
>> of the jetty virtual host description [7]. 
>> This can't be done, as this kind of xml isn't parsed by Pax-Web as it's a 
>> mediation layer. 
>> In the end you can try to use a vanilla Jetty instead then. 
>>
>> [1] - 
>> https://github.com/ops4j/org.ops4j.pax.web/blob/master/pax-web-itest/pax-web-itest-container/pax-web-itest-container-jetty/src/test/java/org/ops4j/pax/web/itest/jetty/JettyConfigurationExtendedIntegrationTest.java#L66
>>
>> [2] - 
>> https://github.com/ops4j/org.ops4j.pax.web/blob/master/pax-web-itest/pax-web-itest-container/pax-web-itest-container-jetty/src/test/java/org/ops4j/pax/web/itest/jetty/JettyConfigurationExtendedIntegrationTest.java#L106-L111
>>
>> [3] - 
>> https://github.com/ops4j/org.ops4j.pax.web/blob/master/pax-web-extender-war/src/main/java/org/ops4j/pax/web/extender/war/internal/WebObserver.java#L129
>>
>> [4] - 
>> https://github.com/ops4j/org.ops4j.pax.web/blob/master/pax-web-extender-war/src/main/java/org/ops4j/pax/web/extender/war/internal/parser/WebAppParser.java#L797-L807
>>
>> [5] - 
>> https://github.com/ops4j/org.ops4j.pax.web/blob/master/pax-web-runtime/src/main/java/org/ops4j/pax/web/service/internal/HttpServiceStarted.java#L1136-L1166
>>
>> [6] - 
>> https://github.com/ops4j/org.ops4j.pax.web/blob/master/pax-web-runtime/src/main/java/org/ops4j/pax/web/service/internal/HttpServiceStarted.java#L1136-L1166
>>
>> [7] - 
>> https://www.eclipse.org/jetty/documentation/9.3.x/configuring-virtual-hosts.html
>>
>>
>> 2016-10-09 19:00 GMT+02:00 Pavel Kastornyy <pavelka...@gmail.com>:
>>
>>> Hi Achim,
>>>
>>> Please, answer to two questions:
>>>
>>> 1) What is the use of VirtualHost + Connectors?
>>>
>>> 2)I need the following: I have pax-web and jetty on port 8080
>>> (the port is set via org.osgi.service.http.port). And I have two
>>> bundles - A and B with the same web-contextpath: /
>>> Bundle A must be linked to example.com, bundle B to
>>> foo.example.com. Both bundles must be linked to port 8080.
>>> The problem is that if they have the same web-context only
>>> the first bundle is started, the servlets in the second are not
>>> instantiated. Can this be done via existing code?
>>>
>>> Best regards,
>>>
>>>
>>> On 09.10.2016 19:40, 'Achim Nierbeck' via OPS4J wrote:
>>>
>>>> Hi,
>>>>
>>>> hmm I'm not sure, maybe we could get rid of one, but when we started to
>>>> have this feature
>>>> jetty required both paramteres. The newer versions of Jetty only require
>>>> the Web-VirtualHost parameter.
>>>> It's in this method [1].
>>>> Regarding VirtualHosts and Connectors as far as I'm concerned, it has
>>>> already been implemented.
>>>> BUT I've never been able to verify it fully as I never tried with 
>>>> different
>>>> dns names. Only with different ports
>>>> on different connectors.
>>>> That's the part I documented and blogged about.
>>>> Have you tried to verify that this isn't already what you are looking 
>>>> for?
>>>>
>>>> regards, Achim
>>>>
>>>>
>>>>
>>>> [1] -
>>>>
>>>> https://github.com/ops4j/org.ops4j.pax.web/blob/master/pax-web-runtime/src/main/java/org/ops4j/pax/web/service/internal/HttpServiceStarted.java#L1136-L1166
>>>>
>>>>
>>>> 2016-10-09 11:47 GMT+02:00 iJava <pavelka...@gmail.com>:
>>>>
>>>> I don't know. If there must be two settings:
>>>>>
>>>>> Web-Connectors: myConnector
>>>>> Web-VirtualHosts: localhost
>>>>>
>>>>> then what is the name of the default connector?
>>>>> Because only with Web-VirtualHosts it doesn't work.
>>>>>
>>>>> I am looking forward to hearing what Achim will say.
>>>>>
>>>>> Best regards,
>>>>>
>>>>>
>>>>> воскресенье, 9 октября 2016 г., 12:31:22 UTC+3 пользователь Niclas 
>>>>> Hedhman
>>>>> написал:
>>>>>
>>>>>>
>>>>>> Hold on a sec... Looking at JIRAs and I see;
>>>>>>
>>>>>> https://ops4j1.jira.com/browse/PAXWEB-396
>>>>>> https://ops4j1.jira.com/browse/PAXWEB-490
>>>>>>
>>>>>> Isn't that exactly the same thing?
>>>>>>
>>>>>> Niclas
>>>>>>
>>>>>>
>>>>>> On Sun, Oct 9, 2016 at 3:34 PM, iJava <pavelka...@gmail.com> wrote:
>>>>>>
>>>>>> Niclas, besides look, all current settings are in bundle:
>>>>>>> 1) virtual hosts in bundle jetty-web.xml
>>>>>>> 2) context-path - in bundle manifest
>>>>>>> 3) web.xml - in bundle
>>>>>>> So, I suggest to put it there - let all the settings be in one place 
>>>>>>> -
>>>>>>> in bundle.
>>>>>>>
>>>>>>> воскресенье, 9 октября 2016 г., 9:26:29 UTC+3 пользователь Niclas
>>>>>>> Hedhman написал:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>> I would like to suggest that it is not advisable to put the virtual
>>>>>>>> host name into the bundle. That is IMNSHO at odds with the normal
>>>>>>>> flexibility available. I think that one way of doing it is through
>>>>>>>> configuration of Pax Web, such as an optional map of 
>>>>>>>> "Bundle-SymbolicName"
>>>>>>>> to "Virtual Host Name". There might be other...
>>>>>>>>
>>>>>>>> Niclas
>>>>>>>>
>>>>>>>> On Sun, Oct 9, 2016 at 11:03 AM, iJava <pavelka...@gmail.com> 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi Achim,
>>>>>>>>>
>>>>>>>>> I had some free time (it is 5 am now :) ) to take a look at pax-web
>>>>>>>>> sources.
>>>>>>>>> What I suggest after short analysis is:
>>>>>>>>> 1) The solution must be absolute backward compatible with pax-web 
>>>>>>>>> 6.0.
>>>>>>>>> (I need this feature
>>>>>>>>> and I can't wait ? time for version 7.0.0)
>>>>>>>>> 2) In deployed bundles there will be an optional(!) Virtual-Hosts
>>>>>>>>> setting in manifest of war bundle.
>>>>>>>>> I think that even it there is any virtual-host settings separate 
>>>>>>>>> from
>>>>>>>>> bundles in the future,
>>>>>>>>>   it is bundle that must say to which virtual host it wants to 
>>>>>>>>> belong
>>>>>>>>> to.
>>>>>>>>> 3) We add virtualHosts collection to 
>>>>>>>>> org.ops4j.pax.web.service.spi.model.ServerModel
>>>>>>>>> +
>>>>>>>>> fix all match* methods. Besides we fix match* in
>>>>>>>>> JettyServerHandlerCollection
>>>>>>>>> 4) it is necessary to allow war bundles with the same context if 
>>>>>>>>> the
>>>>>>>>> have virtual-hosts setting.
>>>>>>>>> I haven't looked yet where it can be done.
>>>>>>>>> 5) The suggested solution is a "first attempt" to see how it will 
>>>>>>>>> be
>>>>>>>>> like and will not
>>>>>>>>> require much time (which is the problem #1). If someone has time in
>>>>>>>>> future he\she can
>>>>>>>>> always make the solution better.
>>>>>>>>>
>>>>>>>>> What will you say?
>>>>>>>>>
>>>>>>>>> P.S. I considered only for jetty as I wrote above.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> понедельник, 3 октября 2016 г., 21:43:15 UTC+3 пользователь Achim
>>>>>>>>> Nierbeck написал:
>>>>>>>>>
>>>>>>>>>> Niclas ... I have no clue why he isn't shown ... according to
>>>>>>>>>> openhub.net he still is [1]
>>>>>>>>>>
>>>>>>>>>> Pavel, one could also always have 15 Microservices taking care of
>>>>>>>>>> those 15 domains.
>>>>>>>>>>
>>>>>>>>>> regards, Achim
>>>>>>>>>>
>>>>>>>>>> [1] - https://www.openhub.net/p/pax-web/users
>>>>>>>>>>
>>>>>>>>>> 2016-10-03 6:54 GMT+02:00 Pavel Kastornyy <pavelka...@gmail.com>:
>>>>>>>>>>
>>>>>>>>>> Hi Marc
>>>>>>>>>>>
>>>>>>>>>>> You are absolutely right - it is possible to use frontend server
>>>>>>>>>>> and use pax-web as backend server. But in this case pax-web
>>>>>>>>>>> in any serious production use can be used only as backend +
>>>>>>>>>>> if you have 15 domains you will manage 15 ports.
>>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 02.10.2016 21:46, Marc Schlegel wrote:
>>>>>>>>>>>
>>>>>>>>>>> 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/10000?
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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 <nic...@hedhman.org
>>>>>>>>>>>>>> >:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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 <pavelka...@gmail.com>
>>>>>>>>>>>>>>> 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 sorry to hear
>>>>>>>>>>>>>>>>>> but nothing we can do about.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> regards, Achim
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 2016-09-30 17:04 GMT+02:00 Achim Nierbeck <
>>>>>>>>>>>>>>>>>> bcan...@googlemail.com>:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Well, in that case try to use GlassFish again.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> GlassFish uses a complete different strategy.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Regards, Achim
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 2016-09-30 17:02 GMT+02:00 iJava <pavelka...@gmail.com>:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Something is wrong here. I worked with glassfish. 
>>>>>>>>>>>>>>>>>>> Everything
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> starts
>>>>>>>>>>>>>>>>>>>> with glassfish domain.
>>>>>>>>>>>>>>>>>>>> In one domain you usually have one http connector and 
>>>>>>>>>>>>>>>>>>>> one
>>>>>>>>>>>>>>>>>>>> https
>>>>>>>>>>>>>>>>>>>> connector. After that in
>>>>>>>>>>>>>>>>>>>> one domain you can have multiple virtual hosts. When you
>>>>>>>>>>>>>>>>>>>> deploy
>>>>>>>>>>>>>>>>>>>> osgi bundle you
>>>>>>>>>>>>>>>>>>>> in manifest have Web-ContextPath and VirtualServers. So 
>>>>>>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>>>>>> have N sites
>>>>>>>>>>>>>>>>>>>> (example.com, boo.org, blablabla.net) with 
>>>>>>>>>>>>>>>>>>>> WebContextPath
>>>>>>>>>>>>>>>>>>>> / and it
>>>>>>>>>>>>>>>>>>>> is not necessary
>>>>>>>>>>>>>>>>>>>>    to create new connectors for new ports.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I know it well, because I remember it took me some time 
>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>> make it
>>>>>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>>>>>> And I was very glad because it is easy to work with one
>>>>>>>>>>>>>>>>>>>> port then
>>>>>>>>>>>>>>>>>>>> with N.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Now you suggest me to go back and again work with N 
>>>>>>>>>>>>>>>>>>>> ports.
>>>>>>>>>>>>>>>>>>>> I am
>>>>>>>>>>>>>>>>>>>> shocked and killed.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> пятница, 30 сентября 2016 г., 17:49:30 UTC+3 
>>>>>>>>>>>>>>>>>>>> пользователь
>>>>>>>>>>>>>>>>>>>> Achim
>>>>>>>>>>>>>>>>>>>> Nierbeck написал:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> yes, you can only have one Web-ContextPath per WAB. 
>>>>>>>>>>>>>>>>>>>>> "/" is
>>>>>>>>>>>>>>>>>>>>> especially tricky since you can also have HttpService
>>>>>>>>>>>>>>>>>>>>> servlets listening on
>>>>>>>>>>>>>>>>>>>>> that one.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> regards, Achim
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 2016-09-30 16:46 GMT+02:00 iJava <pavelka...@gmail.com
>>>>>>>>>>>>>>>>>>>>> >:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Hi Achim
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Thank you for the links, I wil study them now. So, do 
>>>>>>>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>>>>>> understand it right -
>>>>>>>>>>>>>>>>>>>>>> accroding to specs I can have only one bundle with
>>>>>>>>>>>>>>>>>>>>>> web-contextpath / for one port ?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> пятница, 30 сентября 2016 г., 17:37:55 UTC+3 
>>>>>>>>>>>>>>>>>>>>>> пользователь
>>>>>>>>>>>>>>>>>>>>>> Achim
>>>>>>>>>>>>>>>>>>>>>> Nierbeck написал:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> It's in the spec ...
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Now, if you want to run virtual hosts, take a look at
>>>>>>>>>>>>>>>>>>>>>>> the links
>>>>>>>>>>>>>>>>>>>>>>> below.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> regards, Achim
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> [1] -
>>>>>>>>>>>>>>>>>>>>>>> https://github.com/ops4j/org.o
>>>>>>>>>>>>>>>>>>>>>>> ps4j.pax.web/blob/master/pax-w
>>>>>>>>>>>>>>>>>>>>>>> eb-itest/pax-web-itest-contain
>>>>>>>>>>>>>>>>>>>>>>> er/pax-web-itest-container-
>>>>>>>>>>>>>>>>>>>>>>> jetty/src/test/java/org/ops4j/
>>>>>>>>>>>>>>>>>>>>>>> pax/web/itest/jetty/JettyConfi
>>>>>>>>>>>>>>>>>>>>>>> gurationExtendedIntegrationTest.java
>>>>>>>>>>>>>>>>>>>>>>> [2] -
>>>>>>>>>>>>>>>>>>>>>>> https://github.com/ops4j/org.o
>>>>>>>>>>>>>>>>>>>>>>> ps4j.pax.web/blob/master/pax-w
>>>>>>>>>>>>>>>>>>>>>>> eb-itest/pax-web-itest-contain
>>>>>>>>>>>>>>>>>>>>>>> er/pax-web-itest-container-
>>>>>>>>>>>>>>>>>>>>>>> jetty/src/test/java/org/ops4j/
>>>>>>>>>>>>>>>>>>>>>>> pax/web/itest/jetty/JettyConfi
>>>>>>>>>>>>>>>>>>>>>>> gurationExtendedTwoIntegrationTest.java
>>>>>>>>>>>>>>>>>>>>>>> [3] -
>>>>>>>>>>>>>>>>>>>>>>> http://notizblog.nierbeck.de/2
>>>>>>>>>>>>>>>>>>>>>>> 013/01/bind-certain-web-applic
>>>>>>>>>>>>>>>>>>>>>>> ations-to-specific-httpconnectors/
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 2016-09-30 16:23 GMT+02:00 Pavel Kastornyy <
>>>>>>>>>>>>>>>>>>>>>>> pavelka...@gmail.com
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> :
>>>>>>>>>>>>>>>>>>>>>>>> Achim, I understand you, but why? If the domains are
>>>>>>>>>>>>>>>>>>>>>>>> different
>>>>>>>>>>>>>>>>>>>>>>>> why must I change web-contextpath? For example, lets
>>>>>>>>>>>>>>>>>>>>>>>> suppose
>>>>>>>>>>>>>>>>>>>>>>>> I have five different sites on one osgi and for 
>>>>>>>>>>>>>>>>>>>>>>>> every
>>>>>>>>>>>>>>>>>>>>>>>> site I
>>>>>>>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>>>>>>> separate wab (which is logical) and every wab has 
>>>>>>>>>>>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>>>>>>>>>>> one
>>>>>>>>>>>>>>>>>>>>>>>> context
>>>>>>>>>>>>>>>>>>>>>>>> - /. It is normal situation - take a look at any web
>>>>>>>>>>>>>>>>>>>>>>>> server.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On 30.09.2016 17:19, 'Achim Nierbeck' via OPS4J 
>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> The Manifest entry Web-ContextPath is the one in 
>>>>>>>>>>>>>>>>>>>>>>>> charge
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>>>>>>> where the
>>>>>>>>>>>>>>>>>>>>>>>>> application resides in.
>>>>>>>>>>>>>>>>>>>>>>>>> So in that case you need to make sure of different
>>>>>>>>>>>>>>>>>>>>>>>>> Web-ContextPaths.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> regards, Achim
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> 2016-09-30 16:09 GMT+02:00 iJava <
>>>>>>>>>>>>>>>>>>>>>>>>> pavelka...@gmail.com
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> :
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Hi Achim,
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Yes, you are right. The same web-contextpath in 
>>>>>>>>>>>>>>>>>>>>>>>>>> both
>>>>>>>>>>>>>>>>>>>>>>>>>> bundles:
>>>>>>>>>>>>>>>>>>>>>>>>>> /
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> But it seems to be a bug because in bundle A I 
>>>>>>>>>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>>>>>>>>> jetty-web.xml
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> <Configure
>>>>>>>>>>>>>>>>>>>>>>>>>> class="org.eclipse.jetty.servl
>>>>>>>>>>>>>>>>>>>>>>>>>> et.ServletContextHandler">
>>>>>>>>>>>>>>>>>>>>>>>>>>        <Set name="virtualHosts">
>>>>>>>>>>>>>>>>>>>>>>>>>>            <Array type="java.lang.String">
>>>>>>>>>>>>>>>>>>>>>>>>>>              <Item>example.com</Item>
>>>>>>>>>>>>>>>>>>>>>>>>>>              <Item>www.example.com</Item>
>>>>>>>>>>>>>>>>>>>>>>>>>>            </Array>
>>>>>>>>>>>>>>>>>>>>>>>>>>        </Set>
>>>>>>>>>>>>>>>>>>>>>>>>>> </Configure>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> and in bundle B I have jetty-web.xml
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> <Configure
>>>>>>>>>>>>>>>>>>>>>>>>>> class="org.eclipse.jetty.servl
>>>>>>>>>>>>>>>>>>>>>>>>>> et.ServletContextHandler">
>>>>>>>>>>>>>>>>>>>>>>>>>>        <Set name="virtualHosts">
>>>>>>>>>>>>>>>>>>>>>>>>>>            <Array type="java.lang.String">
>>>>>>>>>>>>>>>>>>>>>>>>>>              <Item>foo.example.com</Item>
>>>>>>>>>>>>>>>>>>>>>>>>>>              <Item>www.foo.example.com</Item>
>>>>>>>>>>>>>>>>>>>>>>>>>>            </Array>
>>>>>>>>>>>>>>>>>>>>>>>>>>        </Set>
>>>>>>>>>>>>>>>>>>>>>>>>>> </Configure>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> пятница, 30 сентября 2016 г., 16:54:24 UTC+3
>>>>>>>>>>>>>>>>>>>>>>>>>> пользователь
>>>>>>>>>>>>>>>>>>>>>>>>>> Achim Nierbeck
>>>>>>>>>>>>>>>>>>>>>>>>>> написал:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> this seems to be a rather strange bug. Do both of
>>>>>>>>>>>>>>>>>>>>>>>>>>> the war
>>>>>>>>>>>>>>>>>>>>>>>>>>> maybe have the
>>>>>>>>>>>>>>>>>>>>>>>>>>> same web-contextpath?
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> regards, Achim
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> 2016-09-30 14:09 GMT+02:00 iJava <
>>>>>>>>>>>>>>>>>>>>>>>>>>> pavelka...@gmail.com>:
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> It may seem to be funny question but I have the
>>>>>>>>>>>>>>>>>>>>>>>>>>>> following
>>>>>>>>>>>>>>>>>>>>>>>>>>>> situation. I
>>>>>>>>>>>>>>>>>>>>>>>>>>>> have two war bundles A and B.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> When I start and install only bundle A - it 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> works
>>>>>>>>>>>>>>>>>>>>>>>>>>>> ok. When
>>>>>>>>>>>>>>>>>>>>>>>>>>>> I start and
>>>>>>>>>>>>>>>>>>>>>>>>>>>> install only bundle B it works ok.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> When I try to install both of them always only 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>>>> first
>>>>>>>>>>>>>>>>>>>>>>>>>>>> works. The
>>>>>>>>>>>>>>>>>>>>>>>>>>>> servlet in the second bundle is not
>>>>>>>>>>>>>>>>>>>>>>>>>>>> instantiated. I tried to add
>>>>>>>>>>>>>>>>>>>>>>>>>>>> <load-on-startup>0</load-on-startup> to
>>>>>>>>>>>>>>>>>>>>>>>>>>>> servlet config
>>>>>>>>>>>>>>>>>>>>>>>>>>>> in web.xml but it didn't help.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Any ideas? Does anyone try to deploy more then 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> one
>>>>>>>>>>>>>>>>>>>>>>>>>>>> war
>>>>>>>>>>>>>>>>>>>>>>>>>>>> bundle on the same
>>>>>>>>>>>>>>>>>>>>>>>>>>>> osgi framework with pax-web 6.0?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>>> ------------------
>>>>>>>>>>>>>>>>>>>>>>>>>>>> OPS4J - <a href="http:
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>

-- 
-- 
------------------
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to