sorry didn't want to bother you with my bla-bla-bla ... therefore I have nothing else to say.
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.
