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 <pavelkastor...@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 - http://www.ops4j.org -
op...@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+un...@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 - op...@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+un...@googlegroups.com.
For more options, visit
https://groups.google.com/d/optout.
--
--
------------------
OPS4J - http://www.ops4j.org - op...@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+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/op
tout.
--
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 - op...@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+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/op
tout.
--
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 - op...@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+un...@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
--
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 - op...@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+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java
--
--
------------------
OPS4J - http://www.ops4j.org - op...@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+un...@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 - op...@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+un...@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 - op...@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+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java
--
--
------------------
OPS4J - http://www.ops4j.org - op...@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+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java
--
--
------------------
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.
--
--
------------------
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.
