One more question: Why isn't the Tomcat class used in the mainstream code and is only used in the test cases? In Tomcat 5.x and 6.x IIRC, Catalina used to extend Embedded.
On Tue, Feb 15, 2011 at 10:31 PM, Mark Thomas <ma...@apache.org> wrote: > On 15/02/2011 14:07, Afkham Azeez wrote: > > On Tue, Feb 15, 2011 at 6:54 PM, Caldarale, Charles R < > > chuck.caldar...@unisys.com> wrote: > > > >>> From: Afkham Azeez [mailto:afk...@gmail.com] > >>> Subject: Embedding Tomcat 7 > >> > >>> We need our webapps to be visible through > >>> multiple connectors. How can this be done? > >> > >> Connectors belong to the Service, so you can attach new ones with this: > >> Tomcat.getService().addConnector() > >> > > > > Thanks Chuck. I was able to figure that out. Also, I noticed a bug in the > > process. I added all my connectors using the addConnector method. > However, > > Tomcat starts an additional connector on port 8080. So, to avoid that I > had > > to set a dummy connector with no port. > > tomcat.setConnector(new Connector("HTTP/1.1")); > > That isn't a bug, that is by design. If you want to replace the default > connector on port 8080, use setConnector(). i.e. if you want 3 > connectors of your own and you don't want the default connector you'll > need one call to setConnector() and 2 to addConnector(). > > The JavaDoc could be clearer. Patches welcome. > > > the API would be cleaner if you could provide a method such as; > > Tomcat.addConnector(String scheme, String port); > > No it wouldn't. If we start down that road we'll end up with a whole > bunch of [add|set]Connector() methods with a whole bunch of different > attributes. That isn't cleaner. > > > There is also a problem with creating HTTPS connectors. Earlier, the now > > deprecated Embedded class automatically sets the "SSLEnabled" property > when > > you call Embedded.createConnector("https"). > > If you define an HTTPS connector, and don't set the SSLEnabled property, you get some weird error when you try to access an HTTPS URL. > That is by design and is true whether you are using the Tomcat class or > server.xml. The use of encryption, the value of scheme and the setting > of the secure attribute are all controlled separately to provide greater > flexibility - usually in reverse proxy situations. > > > Now we have to set all such > > attributes ourselves. So, the Tomcat API could be cleaned up. Perhaps it > may > > be a good idea to move some of the methods in Embedded to Tomcat. The > > Tomcat.addConnector() method could set these additional properties. > > That isn't going to happen. > OK. > > There is scope to make this class more flexible - e.g. specifying your > own Server or Service - but the expectation is that folks wanting that > degree of control will just write something from scratch anyway. > Yes, that is what I will end up doing. From what I understood, the Tomcat class makes the simple case simple, but the moment your scenarios starts getting a bit complex, the developer has to write something from scratch. Also, you'd have to look at the current implementation code to figure out how to do stuff, instead of simply referring to the API docs. > > Mark > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- Afkham Azeez Senior Software Architect & Product Manager, WSO2 WSAS; WSO2, Inc.; http://wso2.com Member; Apache Software Foundation; http://www.apache.org/ email: az...@wso2.com cell: +94 77 3320919 blog: http://blog.afkham.org twitter: http://twitter.com/afkham_azeez linked-in: http://lk.linkedin.com/in/afkhamazeez Lean . Enterprise . Middleware
