Hi, after having implemented some merge algorithm, I figured out that this is all wrong because the host entity does not define to which addresses the tomcat instance listens, but allows to have different configurations (e.g. valves) for different virtual hosts, so the listening addresses and the tomcat hosts are actually completely unrelated. For the normal configuration without tomcat-server.xml it is completely sufficient to have one single default host that serves requests to all virtual hosts (as the config admin information does not contain any host specidic configuration anyway). Instead the listening addresses have to go into the connectors.
The current implementation makes sure that there is one connector for the HTTP and/or HTTPS port configured in the config admin settings. If no such connector exists (from the configuration) one is created (without address which means that it listens to all addresses). So my proposal would be to remove all the host merge logic and just make sure that the default host of the engine configured in the tomcat instance exists (and create one if it doesn't). Additionally the connector merge logic needs to be extended, but I am a but unsure about what makes most sense here. I might have a closer look into the jetty implementation again, but from an outside point of view I see the folloeing use cases: 1. User A does not care about listening address configuration at all. He has defined a port and wants the container to listen to all his addresses in his port. He may or may not have a tomcat-config.xml and if he defined a connector in there, it uses the same port as the port configured in the config admin service and did not configure any address. For this user the current setup is just fine, the connector is either instantiated from the tomcat-server.xml or created afterwards from the config admin properties. (It does not matter that the listening addresses from the config admin properties are ignored as they both default to listen to all addresses). 2. User B wants to limit the listening address to one address (for HTTP and HTTPS). With the current implementation he can achieve this by defining connectors with the HTTP and HTTPS ports and configure them appropriately in config-server.xml. he cannot configure that via config admin properties. 3. User C wants to limit the listening address to one address for HTTP only, but not for HTTPS (e.g. HTTP is supposed to be accessible only from the internal network, HTTPS is supposed to be accessible from all networks). With the current implementation he can also configure that by defining the appropriate connectors in the tomcat-server.xml. I would guess for user A everything we can think up is ok. For user B ist might be good to have an option to configure address specifc connectors also from config/admin information, so he does not need a config-server.xml at all. To create a solution that can also make user C happy is more difficutl. He might have some elaborate and different configuration for his connectors and he cannot un-define the config/admin properties. So my idea would be to do the following: if there is already a connector for the port available, we just use it as it is (the user has configured it in his config-server.xml, so this is likely what he wants). This is the current behaviour. If there is no such connector, we create connectors honoring the listening addresses. This might kind of violate the config admin configuration first paradigm, but will give users usually what they want. What do you think? Best regards Stephan Am Freitag, 3. März 2017 20:25:10 UTC+1 schrieb Achim Nierbeck: > > Hi Stephan, > > see my comments inline :-) > > regards, Achim > > > 2017-03-03 14:51 GMT+01:00 Stephan Siano <[email protected] <javascript:>> > : > >> Hi, >> >> I am working on [PAXWEB-630] Interpret and use the tomcat-server.xml. >> While doing so, I came across an interesting problem. >> >> The tomcat-server.xml can configure host entries (and this does make >> sense, since that allows to add additional configurations like valves to >> the host). >> >> However, after the config file parsing the mergeConfiguration() method of >> EmbeddedTomcat will change the name of the host configured with the >> EmbeddedTomcatInstance to the first listeningAddress in the configuration >> (and will add new hosts to the engine configured at the engine attribute of >> the EmbeddedTomcatInstance). The first host will be set as defaultHost to >> the engine. Does that really make sense? If I understand the jetty coding >> correctly they try to match the listeningAddresses from the configuration >> with those from the configration file (and add the missing ones). Wouldn't >> that make more sense or is there a reason why the mechanism is as it is >> (except that it is easier to implement that way)? >> >> > AFAICR when I created a first shot for this, I basically moved the way > it's handled with jetty to tomcat. > But what you describe here, that sounds more like a bug, cause the way > it's handled for jetty is the way it's supposed to be. > > >> For the connectors the org.osgi.service.http.enabled and >> org.osgi.service.https.enabled properties take precedence over everything >> else (if they are set to false, all http or https connectors are removed). >> Aside from that a connector for org.osgi.service.http.port and >> org.osgi.service.https.port is added if it does not already exist in the >> config file. I would guess that makes sense. >> > > > >> >> Can you explain how the merge behaviour of the hosts is supposed to be? >> > > The idea behind this is > A) osgi properties are always master > B) external jetty or tomcat configurations are always add-ons > as we're running in an OSGi env, the OSGi spec rules for the > configuration, external configurations are an "add-on" from Pax-Web. > > Therefore if there is a configuration available from an native > configuration which collides with the "default" configuration coming from > the osgi properties, the Host configuration from the OSGi properties > rules. > All other configurations are add-ons. > > > >> >> Are my assumptions about the connectors correct? >> >> Best regards >> Stephan >> >> -- >> -- >> ------------------ >> OPS4J - http://www.ops4j.org - [email protected] <javascript:> >> >> --- >> 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 [email protected] <javascript:>. >> 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 - [email protected] --- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
