sorry didn't want to bother you with my bla-bla-bla ...
therefore I have nothing else to say.

Advertising

regards, Achim
2016-10-12 13:35 GMT+02:00 iJava <pavelkastor...@gmail.com>:
> 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/JettyConfi
>>> gurationExtendedIntegrationTest.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/JettyConfi
>>> gurationExtendedIntegrationTest.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/interna
>>> l/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/interna
>>> l/HttpServiceStarted.java#L1136-L1166
>>>
>>> [7] - https://www.eclipse.org/jetty/documentation/9.3.x/configur
>>> ing-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-w
>>>>> eb-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.
>
--
Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
Software Architect / Project Manager / Scrum Master
--
--
------------------
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.