Re: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest Authentication problem
Am 17.03.2015 um 15:40 schrieb Sascha Skorupa: Hi Rainer, currently not (Apache 2.2) but it might be an option to upgrade the OS and the Apache if it leads to a solution. OK. But think twice, whether it is better to just compile mod_jk from sources or do the big update. Updating to 2.4 will bring many interesting achievements, but just for fixing this issue quickly it would be better to update mod_jk, even if this means switching to a non-OS-provided variant. If you seriously plan the 2.4 update and you have a test system, I could provide you with the non-trivial workaround letting Apache set the cookie. You would need to thoroughly test this though. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: java.lang.NullPointerException at org.apache.jasper.JspCompilationContext.getTldResourcePath(JspCompilationContext.java:536) when starting Embedded Tomcat Instance
Hi, I manually set the TldCache in my context and get rid of the NullPointerException. But now I'm getting following exception org.apache.jasper.JasperException: The absolute uri: http://tiles.apache.org/tags-tiles cannot be resolved in either web.xml or the jar files deployed with this application at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:55) at org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:277) at org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:75) at org.apache.jasper.compiler.TagLibraryInfoImpl.generateTldResourcePath(TagLibraryInfoImpl.java:240) at org.apache.jasper.compiler.TagLibraryInfoImpl.init(TagLibraryInfoImpl.java:124) at org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:411) at org.apache.jasper.compiler.Parser.parseDirective(Parser.java:469) at org.apache.jasper.compiler.Parser.parseElements(Parser.java:1430) at org.apache.jasper.compiler.Parser.parse(Parser.java:139) at org.apache.jasper.compiler.ParserController.doParse(ParserController.java:227) at org.apache.jasper.compiler.ParserController.parse(ParserController.java:100) at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:199) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:356) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:336) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:323) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:570) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:356) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:396) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:340) at javax.servlet.http.HttpServlet.service(HttpServlet.java:725) at org.wso2.carbon.ui.JspServlet.service(JspServlet.java:175) at org.wso2.carbon.ui.TilesJspServlet.service(TilesJspServlet.java:80) at javax.servlet.http.HttpServlet.service(HttpServlet.java:725) at org.eclipse.equinox.http.helper.ContextPathServletAdaptor.service(ContextPathServletAdaptor.java:37) at org.eclipse.equinox.http.servlet.internal.ServletRegistration.service(ServletRegistration.java:61) at org.eclipse.equinox.http.servlet.internal.ProxyServlet.processAlias(ProxyServlet.java:128) at org.eclipse.equinox.http.servlet.internal.ProxyServlet.service(ProxyServlet.java:68) at javax.servlet.http.HttpServlet.service(HttpServlet.java:725) at org.wso2.carbon.tomcat.ext.servlet.DelegationServlet.service(DelegationServlet.java:64) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:291) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:721) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:466) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:391) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:318) at org.eclipse.equinox.http.servlet.internal.RequestDispatcherAdaptor.forward(RequestDispatcherAdaptor.java:30) at org.eclipse.equinox.http.helper.ContextPathServletAdaptor$RequestDispatcherAdaptor.forward(ContextPathServletAdaptor.java:362) at org.apache.tiles.servlet.context.ServletTilesRequestContext.forward(ServletTilesRequestContext.java:198) at org.apache.tiles.servlet.context.ServletTilesRequestContext.dispatch(ServletTilesRequestContext.java:185) at org.apache.tiles.impl.BasicTilesContainer.render(BasicTilesContainer.java:419) at org.apache.tiles.impl.BasicTilesContainer.render(BasicTilesContainer.java:370) at org.wso2.carbon.ui.action.ActionHelper.render(ActionHelper.java:52) at org.wso2.carbon.ui.TilesJspServlet.service(TilesJspServlet.java:101) at javax.servlet.http.HttpServlet.service(HttpServlet.java:725) at org.eclipse.equinox.http.helper.ContextPathServletAdaptor.service(ContextPathServletAdaptor.java:37) at org.eclipse.equinox.http.servlet.internal.ServletRegistration.service(ServletRegistration.java:61) at org.eclipse.equinox.http.servlet.internal.ProxyServlet.processAlias(ProxyServlet.java:128) at org.eclipse.equinox.http.servlet.internal.ProxyServlet.service(ProxyServlet.java:68) at javax.servlet.http.HttpServlet.service(HttpServlet.java:725) at org.wso2.carbon.tomcat.ext.servlet.DelegationServlet.service(DelegationServlet.java:64) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:291) at
AW: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest Authentication problem
Indeed, it seems a little bit strange and certainly you are right. I think the main reason is that it would be more complicated to maintain the system with regular security updates. It has to be a manual process. Somehow or other we need a working solution. It is also an option to fix DigestAuthenticator class in tomcat6 to split digest authentication header like it is done in tomcat7, because this is the real cause of the problem - the regular expression submitted to the split method cannot properly handle unquoted parameters at the end of the auth header line. Thank you for your constructive input. -sascha Von: Christopher Schultz [ch...@christopherschultz.net] Gesendet: Dienstag, 17. März 2015 17:10 Bis: Tomcat Users List Betreff: Re: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest Authentication problem -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Rainer, On 3/17/15 11:12 AM, Rainer Jung wrote: Am 17.03.2015 um 15:40 schrieb Sascha Skorupa: Hi Rainer, currently not (Apache 2.2) but it might be an option to upgrade the OS and the Apache if it leads to a solution. OK. But think twice, whether it is better to just compile mod_jk from sources or do the big update. +1 I find it hard to believe that you (or your NOC) would be willing to upgrade the OS and the web server to use an alternative solution, but not willing to upgrade to a newer version of single, specialized module for the web server. Note that you don't have to have a compiler on the target system; you just need to be able to cross-compile to that test system (or do what I do and have a spare server with identical architecture, etc. available for module builds). Updating to 2.4 will bring many interesting achievements, but just for fixing this issue quickly it would be better to update mod_jk, even if this means switching to a non-OS-provided variant. +1 Building is trivial. If you seriously plan the 2.4 update and you have a test system, I could provide you with the non-trivial workaround letting Apache set the cookie. You would need to thoroughly test this though. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVCFHcAAoJEBzwKT+lPKRYOQAQAJnIlsepWBvZlO438/zwXIYM WI0X3LspAUt1v1c0JOXagL5VUdZO68/euBV7rmoKaHvo11lEH5lFQ9M91unvRWer d7AQZoTc1+VQDcnBrGDzw6M7jQqlKf2Y7Jadlj9TfNm68cwCYFhpan1Wcv/XCMpy /1Q5j/gW77AdPNpAvtFGOXZ0HPbMpkC+ZpsfFjgpOrwUBPL195xpQXM5nJLoYpAa 7uR34FCAbIIR0Glho/IHqzadxrSBq3AEVZau1uiGi3t8BjuWcOfq85bMZ0dCGdl+ Hlj6wKaTpS6AJi9By5d0xbXkqu5wBY2qFgY6wNq/cHO/Js+svPPMtME7eUZiOPAY t2dUszkzqw0JOEqTN0I1gr0cGVOhJYbHMAdCHrb15FtWACeQVHVK7ikI0GJvKMG3 8EUIW21go3ID4jHBpexMC23QZDKfDTIhzx9Ec300lxRbjkfzpTCEvu3mM36w6y7+ fsRPPkpY0KqFe25nYw/DZCMS4KeAZ5dZSQa3sQSYgpozP71UrRZJw2+cqdALj29Q Ozru/eLGLAvJuOKbXgSMIBfEQugx8vTGzE60Db7e61thMPmyHXlHqi1+zKDnODej g6kbQtNDhak+0AfI2oFbmvHGz+hN8bAJa62hA/3jDKiYphxwH2JpJW4qmcs7HI91 qRp/u8yrAe8S/UAc+x+2 =95gA -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Multiple SSL certificates on one Instance
-Original Message- From: Rory Kelly [mailto:rory.ke...@fernsoftware.com] Sent: Monday, March 16, 2015 7:53 AM To: Tomcat Users List Subject: Multiple SSL certificates on one Instance Hey guys, I’ve a bad feeling what I’m trying to do is impossible, and I’m going to have to implement a different solution. Been hunting for an answer, but couldn’t find anything definite. I’m running Tomcat 8.0.18, Java 1.7.0_75-b13, Ubuntu 14.04. I have multiple sites running on Virtual Hosts on the instance. For a bit of background, I am intending on creating a 2-server load balanced system using nginx as a balancer on virtual servers (Best I can do, given our hosting/not possible to move away from it) I need each site to be protected by its own SSL certificate, provided by the client for each site. Can I actually have multiple SSL certs with Tomcat Virtual Hosts, or am I going to have to go learn nginx/httpd and provide it that way? Thanks, Rory Rory - The guys have all given some hints that this is probably coming, but not yet here. The rest of the answers depends on your ultimate requirements. If you require that all the hosts are truly virtual, i.e. they all listen to the same IP-port combo, then it's definitely easier/better to terminate the SSL on your NGINX load-balancer, which presumably already has the needed support. There are some minor adjustments on the Tomcat connector config, but they are adequately explained in the Tomcat docs. Plus terminating on the load-balancer will save some processing cycles in Tomcat. If you have the ability to assign multiple IP-port combo, then there's really only 1 way to do it on the Tomcat side: Create a unique Service tree for each host. This tree will have its own Engine, Connector, Valve, Host, etc. entries, basically everything you might need that can't be put at the Global level. Be sure to specify both an HTTP and HTTPS connector so that TRANSPORT GUARANTEE will function properly. Trying to do it all inside one Service tree is just asking for trouble. If you go back in the archives a year or so, I think I posted a sample server.xml implementing the above. Jeff - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [Tomcat8] What happened to WebappLoader.addRepository()?
On 17/03/2015 18:30, Ed Rouse wrote:
-Original Message-
From: Pilkington, Simon [mailto:simo...@amazon.com]
Sent: Tuesday, March 17, 2015 12:45 PM
To: users@tomcat.apache.org
Subject: [Tomcat8] What happened to WebappLoader.addRepository()?
Hey tomcat users,
The javadoc for WebappLoader still tells me to use addRepository(), but
that method no longer exists. My team has implemented an extension of
WebappLoader that looked like this:
http://cp.mcafee.com/d/1jWVIq3zqb2rzydPhOCYrKrhKCqenTzhOe7cCQrFCzBZUQsL
9ICQrFCzBZUQszxP1J6WpEVvd7aabPxLURrFUalAv3UYKrlAv3UYKrKXHXRTT-LPz5TCnA-
LsKyev7szsQsIFICzBzBHEShhlKYPOEuvkzaT0QSyrjdTdTdAVPmEBCjGHrpZGSS9_M079R
lJIOUXHBQaSPlFo01PlJIj_brfjVgT3WWxYs0nO6Hb1mKEv7wsrrFYq5U_dKc2WrWr9EVjb
_6HtfelAv3UYK2FRlJI-
Rrr4_U02rs7e3zpFr1dlrrdUQKCy01iuPd41flBLxW1EwDkQg0bV3lBwHnkfzSE80LRGQBe
IiNEEd598S-UrI1Lf5-sL
http://cp.mcafee.com/d/2DRPoAd3hJ5xdNN6VEVjudTdETjd7bXNEV73CjqdQPhO-
YqenASjqdQPhO-
YqehMVwSztcQsLCzB55VMTYqJQY5aOfxYundGOfxYundTtRZWXX_nVNyXPbOvnKnh7fzKhK
qemkSjhONORQr8EGTupVkffGhBrwqrjdFCXCXCOsVHkiP9RlJI-
Rrr4_U03AWGSSptXHBQaSPlFo01PlJIj_brfjVgT3WWxYs0nO6Hb1mKEv7wsrrFYq5U_dKc
2WrWr9EVjb_6HtfelAv3UYK2FRlJI-
Rrr4_U02rs7e3zpFr1dlrrdUQKCy01iuPd41flBLxW1EwDkQg0bV3lBwHnkfzSE80LRGQBe
IiNEEd598S-UrHrI5
@Override
protected void startInternal() throws LifecycleException {
// validate the context, which is used for debugging messages
Context context;
{
Container container = getContainer();
if (container == null) {
throw new LifecycleException(Container is null?!);
}
if (!(container instanceof Context)) {
throw new LifecycleException(Container is not an
instance of Context?!);
}
context = (Context) container;
}
if (ENVIRONMENT_ROOT != null ENVIRONMENT_ROOT.length() 0) {
// validate targetPackage
if (null == targetPackage) {
throw new LifecycleException(
Missing required Loader attribute
\targetPackage\ in Context configuration +
context.getConfigFile());
}
try {
// Excluded jars are those already pulled in by tomcat.
SetString allExcludedJars = getAllExcludedJars();
SetString reallyExcludedJars = new HashSetString();
// add JARs from target package as repositories
// getPackageClasspath finds the list of jars I want to
include for this webapp.
for (String jar : getPackageClasspath(targetPackage)) {
File file = new File(ENVIRONMENT_ROOT, jar);
// skip bad and unwanted JARs
if (allExcludedJars.contains(jar) || isBadJar(file))
{
reallyExcludedJars.add(jar);
} else {
// TODO: HOW TO FIX ME??
addRepository(file.toURI().toString());
}
}
log.info(Context path \ + context.getPath() + \
excluding JARs: + reallyExcludedJars);
} catch (IOException e) {
throw new LifecycleException(
Problem setting classpath for context path \
+ context.getPath() + \,
e);
}
// getRepositoriesString() has been renamed to
getLoaderRepositoriesString()...
log.info(Context path \ + context.getPath() + \ using
classpath: + getRepositoriesString());
} else {
log.warning(MyWebappLoader seems to be used outside of my
environment. Delegating to parent.);
}
super.startInternal();
}
Can the community help me figure out how to upgrade this for tomcat 8?
JarResourceSet jrs = new JarResourceSet(Context.getResources(), /,
file.getAbsolutePath(), /);
Context.getResources().addPostResources(jrs);
Bad idea. That will mount the contents of the JAR at the root of the web
application.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [Tomcat8] What happened to WebappLoader.addRepository()?
-Original Message-
From: Pilkington, Simon [mailto:simo...@amazon.com]
Sent: Tuesday, March 17, 2015 12:45 PM
To: users@tomcat.apache.org
Subject: [Tomcat8] What happened to WebappLoader.addRepository()?
Hey tomcat users,
The javadoc for WebappLoader still tells me to use addRepository(), but
that method no longer exists. My team has implemented an extension of
WebappLoader that looked like this:
http://cp.mcafee.com/d/1jWVIq3zqb2rzydPhOCYrKrhKCqenTzhOe7cCQrFCzBZUQsL
9ICQrFCzBZUQszxP1J6WpEVvd7aabPxLURrFUalAv3UYKrlAv3UYKrKXHXRTT-LPz5TCnA-
LsKyev7szsQsIFICzBzBHEShhlKYPOEuvkzaT0QSyrjdTdTdAVPmEBCjGHrpZGSS9_M079R
lJIOUXHBQaSPlFo01PlJIj_brfjVgT3WWxYs0nO6Hb1mKEv7wsrrFYq5U_dKc2WrWr9EVjb
_6HtfelAv3UYK2FRlJI-
Rrr4_U02rs7e3zpFr1dlrrdUQKCy01iuPd41flBLxW1EwDkQg0bV3lBwHnkfzSE80LRGQBe
IiNEEd598S-UrI1Lf5-sL
http://cp.mcafee.com/d/2DRPoAd3hJ5xdNN6VEVjudTdETjd7bXNEV73CjqdQPhO-
YqenASjqdQPhO-
YqehMVwSztcQsLCzB55VMTYqJQY5aOfxYundGOfxYundTtRZWXX_nVNyXPbOvnKnh7fzKhK
qemkSjhONORQr8EGTupVkffGhBrwqrjdFCXCXCOsVHkiP9RlJI-
Rrr4_U03AWGSSptXHBQaSPlFo01PlJIj_brfjVgT3WWxYs0nO6Hb1mKEv7wsrrFYq5U_dKc
2WrWr9EVjb_6HtfelAv3UYK2FRlJI-
Rrr4_U02rs7e3zpFr1dlrrdUQKCy01iuPd41flBLxW1EwDkQg0bV3lBwHnkfzSE80LRGQBe
IiNEEd598S-UrHrI5
@Override
protected void startInternal() throws LifecycleException {
// validate the context, which is used for debugging messages
Context context;
{
Container container = getContainer();
if (container == null) {
throw new LifecycleException(Container is null?!);
}
if (!(container instanceof Context)) {
throw new LifecycleException(Container is not an
instance of Context?!);
}
context = (Context) container;
}
if (ENVIRONMENT_ROOT != null ENVIRONMENT_ROOT.length() 0) {
// validate targetPackage
if (null == targetPackage) {
throw new LifecycleException(
Missing required Loader attribute
\targetPackage\ in Context configuration +
context.getConfigFile());
}
try {
// Excluded jars are those already pulled in by tomcat.
SetString allExcludedJars = getAllExcludedJars();
SetString reallyExcludedJars = new HashSetString();
// add JARs from target package as repositories
// getPackageClasspath finds the list of jars I want to
include for this webapp.
for (String jar : getPackageClasspath(targetPackage)) {
File file = new File(ENVIRONMENT_ROOT, jar);
// skip bad and unwanted JARs
if (allExcludedJars.contains(jar) || isBadJar(file))
{
reallyExcludedJars.add(jar);
} else {
// TODO: HOW TO FIX ME??
addRepository(file.toURI().toString());
}
}
log.info(Context path \ + context.getPath() + \
excluding JARs: + reallyExcludedJars);
} catch (IOException e) {
throw new LifecycleException(
Problem setting classpath for context path \
+ context.getPath() + \,
e);
}
// getRepositoriesString() has been renamed to
getLoaderRepositoriesString()...
log.info(Context path \ + context.getPath() + \ using
classpath: + getRepositoriesString());
} else {
log.warning(MyWebappLoader seems to be used outside of my
environment. Delegating to parent.);
}
super.startInternal();
}
Can the community help me figure out how to upgrade this for tomcat 8?
JarResourceSet jrs = new JarResourceSet(Context.getResources(), /,
file.getAbsolutePath(), /);
Context.getResources().addPostResources(jrs);
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [Tomcat8] What happened to WebappLoader.addRepository()?
On 17/03/2015 16:45, Pilkington, Simon wrote: Hey tomcat users, The javadoc for WebappLoader still tells me to use addRepository(), but that method no longer exists. My team has implemented an extension of WebappLoader that looked like this: snip/ addRepository(file.toURI().toString()); snip/ Can the community help me figure out how to upgrade this for tomcat 8? Look at the new resources implementation [1]. You probably want to use org.apache.catalina.webresources.FileResourceSet with an webappMount of /WEB-INF/lib/name-of-jar.jar Mark [1] http://tomcat.apache.org/tomcat-8.0-doc/config/resources.html - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [Tomcat8] What happened to WebappLoader.addRepository()?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Simon,
On 3/17/15 12:45 PM, Pilkington, Simon wrote:
The javadoc for WebappLoader still tells me to use addRepository(),
but that method no longer exists. My team has implemented an
extension of WebappLoader that looked like this:
https://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/loader/WebappLoader.html
https://tomcat.apache.org/tomcat-8.0-doc/api/org/apache/catalina/loader/WebappLoader.html
@Override protected void startInternal() throws LifecycleException
{ // validate the context, which is used for debugging messages
Context context; { Container container = getContainer(); if
(container == null) { throw new LifecycleException(Container is
null?!); } if (!(container instanceof Context)) { throw new
LifecycleException(Container is not an instance of Context?!); }
context = (Context) container; }
if (ENVIRONMENT_ROOT != null ENVIRONMENT_ROOT.length() 0) { //
validate targetPackage if (null == targetPackage) { throw new
LifecycleException( Missing required Loader attribute
\targetPackage\ in Context configuration +
context.getConfigFile()); }
try { // Excluded jars are those already pulled in by tomcat.
SetString allExcludedJars = getAllExcludedJars(); SetString
reallyExcludedJars = new HashSetString(); // add JARs from target
package as repositories // getPackageClasspath finds the list of
jars I want to include for this webapp. for (String jar :
getPackageClasspath(targetPackage)) { File file = new
File(ENVIRONMENT_ROOT, jar); // skip bad and unwanted JARs if
(allExcludedJars.contains(jar) || isBadJar(file)) {
reallyExcludedJars.add(jar); } else { // TODO: HOW TO FIX ME??
addRepository(file.toURI().toString());
Try addURL().
} } log.info(Context path \ + context.getPath() + \ excluding
JARs: + reallyExcludedJars); } catch (IOException e) { throw new
LifecycleException( Problem setting classpath for context path \
+ context.getPath() + \, e); }
// getRepositoriesString() has been renamed to
getLoaderRepositoriesString()... log.info(Context path \ +
context.getPath() + \ using classpath: +
getRepositoriesString()); } else { log.warning(MyWebappLoader
seems to be used outside of my environment. Delegating to
parent.); }
super.startInternal(); }
Can the community help me figure out how to upgrade this for tomcat
8?
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJVCGiJAAoJEBzwKT+lPKRYEAMQAKQfIesZ/xJpQNeIZBlNJkLZ
TRDfBR0rgwcyPGnEOFklj90iIhh0VDcpe/StVzK7XI1/2MjeRCMfb6DdrAbz/lFh
mm5wOuBQ76eY8HqF7/BPX525rvaB89O5bs0dI7kLvtUHNn7trvcnD80YVvSB7g7Y
9tbbNIJGbCPkcqLnD6CLXJtYM0bXo17s8VeyRepqjmXkuKEdWutCDIE1BO1TAPi4
rMA5KesRTrpC289ZCwt8E6uD6DhKc5rGj+V0lrT3X0tLr8nzY70io+4uwoxQjfkQ
QBcO9lzDJWAchM1gx71+0KZCmSlmGR5pWHGt5ysfaSh/20dtB86Qtd3zg+Q22pfH
bakBde8c120PVez/sD9FlFElwKaC6DnBcNwUpfGa2c5RHJaRzpPh/Lhm1QbF1v7L
hmNmlz6C0fBy2N2bXH4p38sz+uP1nH+4TrgoH9gOCRnSe3WhjWyhljsllJQt77Oc
gtflvUqsBNtnOVt1OhViSlM6LLzqyKKj7SeagCn3ZuJ4o0MUODznXt+J4m24/gTT
VbThvj+IfDpvCupswhiosPq6ZIHy6Uz2Ki7BNwQGlFHsPpaSR/1fm/Bn1Nrghraw
jG5Q8yId1B+TeXvnRiZj2IfOkoFK2uY52nH6S8e7Vj2lt3D9PrsTjO6prfEcvSHF
9jX+M5GIgX7DAm5o9ox/
=xMdv
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
AW: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest Authentication problem
Rainer, thank you for this hint, but unfortunately, this feature is too new to be included in any current mod_jk linux package and building it from source it not an option for a production environment. Too bad because that is exactly what we need that. Christopher, your suggestion sounds interesting. Would it be an option for future releases of tomcat? Sascha -Ursprüngliche Nachricht- Von: Christopher Schultz [mailto:ch...@christopherschultz.net] Gesendet: Freitag, 13. März 2015 19:24 An: Tomcat Users List Betreff: Re: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest Authentication problem -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Rainer, On 3/13/15 12:15 PM, Rainer Jung wrote: Am 13.03.2015 um 16:28 schrieb Christopher Schultz: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 3/12/15 1:13 PM, Mark Thomas wrote: On 12/03/2015 15:20, Sascha Skorupa wrote: Hi, here: http://grokbase.com/t/tomcat/users/13bvsbwb8s/multiple-servers-and- digest-authentication the same problem is described and the recommended solution is to use sticky load balancing. But, the problem in a tomcat cluster is that the session ID is generated after a successful authentication. The first http response (401 with Authentication Header) does not contain a session ID. How should sticky load balancing be configured or how to enforce session id generation before authentication? Most load-balancers have various options for doing this that don't depend on the back-end server at all. Perhaps an option in Tomcat that will force the creation of a session when a DIGEST authentication is requested might be useful. This would tie e.g. mod_jk to the proper back-end server. I'm not sure how this could be done using mod_jk without such a feature, or changes to mod_jk itself to annotate the request with the chosen worker, which could then be converted into a cookie in order to keep the node-hint associated with the client. Yes, mod_jk can help since version 1.2.38: Look for set_session_cookie on http://tomcat.apache.org/connectors-doc/reference/workers.html. Using that attribute you can let mod_jk set the cookie, if it doesn't find one already set by Tomcat. You need to also set session_cookie=JSESSIONID and session_cookie_path=/myapp where you adjust myapp to your context path. Oh, good: I had missed that feature. Thanks for pointing it out! - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVAytTAAoJEBzwKT+lPKRYO9EP/1NnmcKmXYwYYvtnb97dMZmz NI7GIaZYDhx1NLb7w5UFDrPNhaAvBDSvzmNxnhZPfdPcwUK93k95+KVymrpI49xh wJ7wbBlFPJcB6coK35jwp0oZnfKbUyHFZ6Qr/r4fbrd57PDqCKGLc/6YicY11nm+ 3EGCYHKe/B2orPNJvw+B5ZCm4cJFwh/VWespkAylCWbqJV1k882zG4MJEwZWgXdn FBLggaCW1N5V6LNAhKiwyrrZrcV9TY3zoMI4Dd8M8yzq8MoTbUK2g2sYZh0LNm0d 0ZbcE07uBUgO5NamNk049vSK+yx0gfHmnL1Gst/jdQ23I8876cTYNCkJKyb0/uDq x5nv2K+dYj1rDeak3j4PS35W+Z6C/SCyp8n3W2L16xtLYtDRQTYv4OTOv1oVTuA2 UueFMwnqRoJV24nLathp29RnjODK7shYce1JqShiAVXzyKSgAkWsu2J8V07txUjP 4v+E0LrWOGEimvHfrOYqdTmH+Ed6YEcttrYU2ddH1g2z4Hz9n+S+fsO2fQgLhY/S V6RluOXfAlg6+IFEtW7DW2PzXuQxOHfKfIX3dlBDGrJGoYNFdYY+uaZO6TPyp7qR UVO9BRA0Roxtpvn7TpJJjygjNXM7uac5MMeCJtA4KPd29PT0sxAnJv+NYpYJ1F35 XROKEh5OIpcNKOPxBoof =w+jN -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: java.lang.NullPointerException at org.apache.jasper.JspCompilationContext.getTldResourcePath(JspCompilationContext.java:536) when starting Embedded Tomcat Instance
Hi,
2015-03-17 15:16 GMT+02:00 Thusitha Thilina Dayaratne thusit...@wso2.com:
Hi
Hi Violeta
Hi,
2015-03-16 15:07 GMT+02:00 Thusitha Thilina Dayaratne
thusit...@wso2.com
:
ERROR {org.apache.catalina.core.ApplicationDispatcher} -
Servlet.service() for servlet bridgeservlet threw exception
java.lang.NullPointerException
at
org.apache.jasper.JspCompilationContext.getTldResourcePath(JspCompilationContext.java:536)
at
org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:410)
at
org.apache.jasper.compiler.Parser.parseDirective(Parser.java:469)
at
org.apache.jasper.compiler.Parser.parseElements(Parser.java:1430)
at org.apache.jasper.compiler.Parser.parse(Parser.java:139)
snip/
I can't figure out the reason to get this NullPointerException.
Can someone help me out?
If we knew which version of Tomcat 8 you were using, someone could
look
at the relevant source code to try to figure out what was going
on.
I'm using tomcat version *8.0.20*
Browse to the sourcecode of v8.0.20 of tomcat here:
public TldResourcePath getTldResourcePath(String uri) {
return getOptions().getTldCache().getTldResourcePath(uri);
}
Thanks for the quick response
Obviously either getOptions() or getTldCache() is returning null.
I debug the code as you suggest and found that getTldCache() is null.
In the code As I understand there are 2 point which set the *tldCache*
variable
one is the setTldCache() method and other is
public static TldCache getInstance(ServletContext servletContext) {
if (servletContext == null) {
throw new IllegalArgumentException(Localizer.getMessage(
org.apache.jasper.compiler.TldCache.servletContextNull));
}
return (TldCache)
servletContext.getAttribute(SERVLET_CONTEXT_ATTRIBUTE_NAME);
}
If you can attach a debugger try to see whether the code below is
invoked:
org.apache.jasper.servlet.JasperInitializer.onStartup(SetClass?,
ServletContext) {
.
context.setAttribute(TldCache.SERVLET_CONTEXT_ATTRIBUTE_NAME,
new TldCache(context,
scanner.getUriTldResourcePathMap(),
scanner.getTldResourcePathTaglibXmlMap()));
}
I have checked that as well. But that method didn't get hot when I'm
debugging the source.
what could be the reason?
You wrote that you are running an embedded Tomcat. Is that true?
In Tomcat 8, Jasper initialization is implemented as a standard
ServletContainderInitializer (check Servlet specification).
So you should ensure
that org.apache.jasper.servlet.JasperInitializer.onStartup is invoked
during web app startup
Could someone tell me how can I make sure that this method get call during
the web app startup?
You didn't tell us whether you are embedding Tomcat or not.
If you are embedding it which jar files from Tomcat distribution you are
using etc.
You can start debugging
with org.apache.catalina.startup.ContextConfig.webConfig()
- processServletContainerInitializers(sContext);
Regards,
Violeta
Best Regards
Thusitha
Re: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest Authentication problem
Hi Sascha, Am 17.03.2015 um 13:02 schrieb Sascha Skorupa: Rainer, thank you for this hint, but unfortunately, this feature is too new to be included in any current mod_jk linux package and building it from source it not an option for a production environment. Too bad because that is exactly what we need that. are you using Apache 2.4? In that case I might have an alternative recipe for you. Regards, Rainer Christopher, your suggestion sounds interesting. Would it be an option for future releases of tomcat? Sascha -Ursprüngliche Nachricht- Von: Christopher Schultz [mailto:ch...@christopherschultz.net] Gesendet: Freitag, 13. März 2015 19:24 An: Tomcat Users List Betreff: Re: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest Authentication problem -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Rainer, On 3/13/15 12:15 PM, Rainer Jung wrote: Am 13.03.2015 um 16:28 schrieb Christopher Schultz: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 3/12/15 1:13 PM, Mark Thomas wrote: On 12/03/2015 15:20, Sascha Skorupa wrote: Hi, here: http://grokbase.com/t/tomcat/users/13bvsbwb8s/multiple-servers-and- digest-authentication the same problem is described and the recommended solution is to use sticky load balancing. But, the problem in a tomcat cluster is that the session ID is generated after a successful authentication. The first http response (401 with Authentication Header) does not contain a session ID. How should sticky load balancing be configured or how to enforce session id generation before authentication? Most load-balancers have various options for doing this that don't depend on the back-end server at all. Perhaps an option in Tomcat that will force the creation of a session when a DIGEST authentication is requested might be useful. This would tie e.g. mod_jk to the proper back-end server. I'm not sure how this could be done using mod_jk without such a feature, or changes to mod_jk itself to annotate the request with the chosen worker, which could then be converted into a cookie in order to keep the node-hint associated with the client. Yes, mod_jk can help since version 1.2.38: Look for set_session_cookie on http://tomcat.apache.org/connectors-doc/reference/workers.html. Using that attribute you can let mod_jk set the cookie, if it doesn't find one already set by Tomcat. You need to also set session_cookie=JSESSIONID and session_cookie_path=/myapp where you adjust myapp to your context path. Oh, good: I had missed that feature. Thanks for pointing it out! - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVAytTAAoJEBzwKT+lPKRYO9EP/1NnmcKmXYwYYvtnb97dMZmz NI7GIaZYDhx1NLb7w5UFDrPNhaAvBDSvzmNxnhZPfdPcwUK93k95+KVymrpI49xh wJ7wbBlFPJcB6coK35jwp0oZnfKbUyHFZ6Qr/r4fbrd57PDqCKGLc/6YicY11nm+ 3EGCYHKe/B2orPNJvw+B5ZCm4cJFwh/VWespkAylCWbqJV1k882zG4MJEwZWgXdn FBLggaCW1N5V6LNAhKiwyrrZrcV9TY3zoMI4Dd8M8yzq8MoTbUK2g2sYZh0LNm0d 0ZbcE07uBUgO5NamNk049vSK+yx0gfHmnL1Gst/jdQ23I8876cTYNCkJKyb0/uDq x5nv2K+dYj1rDeak3j4PS35W+Z6C/SCyp8n3W2L16xtLYtDRQTYv4OTOv1oVTuA2 UueFMwnqRoJV24nLathp29RnjODK7shYce1JqShiAVXzyKSgAkWsu2J8V07txUjP 4v+E0LrWOGEimvHfrOYqdTmH+Ed6YEcttrYU2ddH1g2z4Hz9n+S+fsO2fQgLhY/S V6RluOXfAlg6+IFEtW7DW2PzXuQxOHfKfIX3dlBDGrJGoYNFdYY+uaZO6TPyp7qR UVO9BRA0Roxtpvn7TpJJjygjNXM7uac5MMeCJtA4KPd29PT0sxAnJv+NYpYJ1F35 XROKEh5OIpcNKOPxBoof =w+jN -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: java.lang.NullPointerException at org.apache.jasper.JspCompilationContext.getTldResourcePath(JspCompilationContext.java:536) when starting Embedded Tomcat Instance
Hi
Hi Violeta
Hi,
2015-03-16 15:07 GMT+02:00 Thusitha Thilina Dayaratne thusit...@wso2.com
:
ERROR {org.apache.catalina.core.ApplicationDispatcher} -
Servlet.service() for servlet bridgeservlet threw exception
java.lang.NullPointerException
at
org.apache.jasper.JspCompilationContext.getTldResourcePath(JspCompilationContext.java:536)
at
org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:410)
at org.apache.jasper.compiler.Parser.parseDirective(Parser.java:469)
at org.apache.jasper.compiler.Parser.parseElements(Parser.java:1430)
at org.apache.jasper.compiler.Parser.parse(Parser.java:139)
snip/
I can't figure out the reason to get this NullPointerException.
Can someone help me out?
If we knew which version of Tomcat 8 you were using, someone could
look
at the relevant source code to try to figure out what was going on.
I'm using tomcat version *8.0.20*
Browse to the sourcecode of v8.0.20 of tomcat here:
public TldResourcePath getTldResourcePath(String uri) {
return getOptions().getTldCache().getTldResourcePath(uri);
}
Thanks for the quick response
Obviously either getOptions() or getTldCache() is returning null.
I debug the code as you suggest and found that getTldCache() is null.
In the code As I understand there are 2 point which set the *tldCache*
variable
one is the setTldCache() method and other is
public static TldCache getInstance(ServletContext servletContext) {
if (servletContext == null) {
throw new IllegalArgumentException(Localizer.getMessage(
org.apache.jasper.compiler.TldCache.servletContextNull));
}
return (TldCache)
servletContext.getAttribute(SERVLET_CONTEXT_ATTRIBUTE_NAME);
}
If you can attach a debugger try to see whether the code below is
invoked:
org.apache.jasper.servlet.JasperInitializer.onStartup(SetClass?,
ServletContext) {
.
context.setAttribute(TldCache.SERVLET_CONTEXT_ATTRIBUTE_NAME,
new TldCache(context,
scanner.getUriTldResourcePathMap(),
scanner.getTldResourcePathTaglibXmlMap()));
}
I have checked that as well. But that method didn't get hot when I'm
debugging the source.
what could be the reason?
You wrote that you are running an embedded Tomcat. Is that true?
In Tomcat 8, Jasper initialization is implemented as a standard
ServletContainderInitializer (check Servlet specification).
So you should ensure
that org.apache.jasper.servlet.JasperInitializer.onStartup is invoked
during web app startup
Could someone tell me how can I make sure that this method get call during
the web app startup?
Best Regards
Thusitha
On Tue, Mar 17, 2015 at 9:37 AM, Thusitha Thilina Dayaratne
thusit...@wso2.com wrote:
Hi Violeta,
2015-03-16 15:33 GMT+02:00 Thusitha Thilina Dayaratne thusit...@wso2.com
:
Hi Violeta
Hi,
2015-03-16 15:07 GMT+02:00 Thusitha Thilina Dayaratne
thusit...@wso2.com
:
ERROR {org.apache.catalina.core.ApplicationDispatcher} -
Servlet.service() for servlet bridgeservlet threw exception
java.lang.NullPointerException
at
org.apache.jasper.JspCompilationContext.getTldResourcePath(JspCompilationContext.java:536)
at
org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:410)
at
org.apache.jasper.compiler.Parser.parseDirective(Parser.java:469)
at
org.apache.jasper.compiler.Parser.parseElements(Parser.java:1430)
at org.apache.jasper.compiler.Parser.parse(Parser.java:139)
snip/
I can't figure out the reason to get this NullPointerException.
Can someone help me out?
If we knew which version of Tomcat 8 you were using, someone could
look
at the relevant source code to try to figure out what was going on.
I'm using tomcat version *8.0.20*
Browse to the sourcecode of v8.0.20 of tomcat here:
public TldResourcePath getTldResourcePath(String uri) {
return getOptions().getTldCache().getTldResourcePath(uri);
}
Thanks for the quick response
Obviously either getOptions() or getTldCache() is returning null.
I debug the code as you suggest and found that getTldCache() is null.
In the code As I understand there are 2 point which set the *tldCache*
variable
one is the setTldCache() method and other is
public static TldCache getInstance(ServletContext servletContext) {
if (servletContext == null) {
throw new IllegalArgumentException(Localizer.getMessage(
org.apache.jasper.compiler.TldCache.servletContextNull));
}
return (TldCache)
servletContext.getAttribute(SERVLET_CONTEXT_ATTRIBUTE_NAME);
}
If you can attach a debugger try to see whether the code below is
invoked:
org.apache.jasper.servlet.JasperInitializer.onStartup(SetClass?,
ServletContext) {
.
Re: java.lang.NullPointerException at org.apache.jasper.JspCompilationContext.getTldResourcePath(JspCompilationContext.java:536) when starting Embedded Tomcat Instance
2015-03-17 15:16 GMT+02:00 Thusitha Thilina Dayaratne thusit...@wso2.com:
Hi
Hi Violeta
Hi,
2015-03-16 15:07 GMT+02:00 Thusitha Thilina Dayaratne
thusit...@wso2.com
:
ERROR {org.apache.catalina.core.ApplicationDispatcher} -
Servlet.service() for servlet bridgeservlet threw exception
java.lang.NullPointerException
at
org.apache.jasper.JspCompilationContext.getTldResourcePath(JspCompilationContext.java:536)
at
org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:410)
at
org.apache.jasper.compiler.Parser.parseDirective(Parser.java:469)
at
org.apache.jasper.compiler.Parser.parseElements(Parser.java:1430)
at org.apache.jasper.compiler.Parser.parse(Parser.java:139)
snip/
I can't figure out the reason to get this NullPointerException.
Can someone help me out?
If we knew which version of Tomcat 8 you were using, someone could
look
at the relevant source code to try to figure out what was going
on.
I'm using tomcat version *8.0.20*
Browse to the sourcecode of v8.0.20 of tomcat here:
public TldResourcePath getTldResourcePath(String uri) {
return getOptions().getTldCache().getTldResourcePath(uri);
}
Thanks for the quick response
Obviously either getOptions() or getTldCache() is returning null.
I debug the code as you suggest and found that getTldCache() is null.
In the code As I understand there are 2 point which set the *tldCache*
variable
one is the setTldCache() method and other is
public static TldCache getInstance(ServletContext servletContext) {
if (servletContext == null) {
throw new IllegalArgumentException(Localizer.getMessage(
org.apache.jasper.compiler.TldCache.servletContextNull));
}
return (TldCache)
servletContext.getAttribute(SERVLET_CONTEXT_ATTRIBUTE_NAME);
}
If you can attach a debugger try to see whether the code below is
invoked:
org.apache.jasper.servlet.JasperInitializer.onStartup(SetClass?,
ServletContext) {
.
context.setAttribute(TldCache.SERVLET_CONTEXT_ATTRIBUTE_NAME,
new TldCache(context,
scanner.getUriTldResourcePathMap(),
scanner.getTldResourcePathTaglibXmlMap()));
}
I have checked that as well. But that method didn't get hot when I'm
debugging the source.
what could be the reason?
You wrote that you are running an embedded Tomcat. Is that true?
In Tomcat 8, Jasper initialization is implemented as a standard
ServletContainderInitializer (check Servlet specification).
So you should ensure
that org.apache.jasper.servlet.JasperInitializer.onStartup is invoked
during web app startup
Could someone tell me how can I make sure that this method get call during
the web app startup?
You didn't tell us whether you are embedding Tomcat or not.
Thanks for response and I'm Sorry for missing the info in previous mail.
Yes I'm embedding tomcat version 8.0.20
If you are embedding it which jar files from Tomcat distribution you are
using etc.
I'm using following tomcat jars
- tomcat-embed-core
- tomcat-embed-jasper
- tomcat-websocket-api
- tomcat-embed-websocket
- tomcat-jasper
You can start debugging
with org.apache.catalina.startup.ContextConfig.webConfig()
- processServletContainerInitializers(sContext);
Thanks
Regards
Thusitha
On Tue, Mar 17, 2015 at 6:56 PM, Violeta Georgieva miles...@gmail.com
wrote:
Hi,
2015-03-17 15:16 GMT+02:00 Thusitha Thilina Dayaratne thusit...@wso2.com
:
Hi
Hi Violeta
Hi,
2015-03-16 15:07 GMT+02:00 Thusitha Thilina Dayaratne
thusit...@wso2.com
:
ERROR {org.apache.catalina.core.ApplicationDispatcher} -
Servlet.service() for servlet bridgeservlet threw exception
java.lang.NullPointerException
at
org.apache.jasper.JspCompilationContext.getTldResourcePath(JspCompilationContext.java:536)
at
org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:410)
at
org.apache.jasper.compiler.Parser.parseDirective(Parser.java:469)
at
org.apache.jasper.compiler.Parser.parseElements(Parser.java:1430)
at org.apache.jasper.compiler.Parser.parse(Parser.java:139)
snip/
I can't figure out the reason to get this NullPointerException.
Can someone help me out?
If we knew which version of Tomcat 8 you were using, someone
could
look
at the relevant source code to try to figure out what was going
on.
I'm using tomcat version *8.0.20*
Browse to the sourcecode of v8.0.20 of tomcat here:
public TldResourcePath getTldResourcePath(String uri) {
return getOptions().getTldCache().getTldResourcePath(uri);
}
Thanks for the quick response
Obviously either getOptions() or getTldCache() is returning null.
I debug the code as you suggest and found that
AW: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest Authentication problem
Hi Rainer, currently not (Apache 2.2) but it might be an option to upgrade the OS and the Apache if it leads to a solution. Regards sascha -Ursprüngliche Nachricht- Von: Rainer Jung [mailto:rainer.j...@kippdata.de] Gesendet: Dienstag, 17. März 2015 15:00 An: Tomcat Users List Betreff: Re: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest Authentication problem Hi Sascha, Am 17.03.2015 um 13:02 schrieb Sascha Skorupa: Rainer, thank you for this hint, but unfortunately, this feature is too new to be included in any current mod_jk linux package and building it from source it not an option for a production environment. Too bad because that is exactly what we need that. are you using Apache 2.4? In that case I might have an alternative recipe for you. Regards, Rainer Christopher, your suggestion sounds interesting. Would it be an option for future releases of tomcat? Sascha -Ursprüngliche Nachricht- Von: Christopher Schultz [mailto:ch...@christopherschultz.net] Gesendet: Freitag, 13. März 2015 19:24 An: Tomcat Users List Betreff: Re: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest Authentication problem -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Rainer, On 3/13/15 12:15 PM, Rainer Jung wrote: Am 13.03.2015 um 16:28 schrieb Christopher Schultz: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 3/12/15 1:13 PM, Mark Thomas wrote: On 12/03/2015 15:20, Sascha Skorupa wrote: Hi, here: http://grokbase.com/t/tomcat/users/13bvsbwb8s/multiple-servers-and - digest-authentication the same problem is described and the recommended solution is to use sticky load balancing. But, the problem in a tomcat cluster is that the session ID is generated after a successful authentication. The first http response (401 with Authentication Header) does not contain a session ID. How should sticky load balancing be configured or how to enforce session id generation before authentication? Most load-balancers have various options for doing this that don't depend on the back-end server at all. Perhaps an option in Tomcat that will force the creation of a session when a DIGEST authentication is requested might be useful. This would tie e.g. mod_jk to the proper back-end server. I'm not sure how this could be done using mod_jk without such a feature, or changes to mod_jk itself to annotate the request with the chosen worker, which could then be converted into a cookie in order to keep the node-hint associated with the client. Yes, mod_jk can help since version 1.2.38: Look for set_session_cookie on http://tomcat.apache.org/connectors-doc/reference/workers.html. Using that attribute you can let mod_jk set the cookie, if it doesn't find one already set by Tomcat. You need to also set session_cookie=JSESSIONID and session_cookie_path=/myapp where you adjust myapp to your context path. Oh, good: I had missed that feature. Thanks for pointing it out! - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVAytTAAoJEBzwKT+lPKRYO9EP/1NnmcKmXYwYYvtnb97dMZmz NI7GIaZYDhx1NLb7w5UFDrPNhaAvBDSvzmNxnhZPfdPcwUK93k95+KVymrpI49xh wJ7wbBlFPJcB6coK35jwp0oZnfKbUyHFZ6Qr/r4fbrd57PDqCKGLc/6YicY11nm+ 3EGCYHKe/B2orPNJvw+B5ZCm4cJFwh/VWespkAylCWbqJV1k882zG4MJEwZWgXdn FBLggaCW1N5V6LNAhKiwyrrZrcV9TY3zoMI4Dd8M8yzq8MoTbUK2g2sYZh0LNm0d 0ZbcE07uBUgO5NamNk049vSK+yx0gfHmnL1Gst/jdQ23I8876cTYNCkJKyb0/uDq x5nv2K+dYj1rDeak3j4PS35W+Z6C/SCyp8n3W2L16xtLYtDRQTYv4OTOv1oVTuA2 UueFMwnqRoJV24nLathp29RnjODK7shYce1JqShiAVXzyKSgAkWsu2J8V07txUjP 4v+E0LrWOGEimvHfrOYqdTmH+Ed6YEcttrYU2ddH1g2z4Hz9n+S+fsO2fQgLhY/S V6RluOXfAlg6+IFEtW7DW2PzXuQxOHfKfIX3dlBDGrJGoYNFdYY+uaZO6TPyp7qR UVO9BRA0Roxtpvn7TpJJjygjNXM7uac5MMeCJtA4KPd29PT0sxAnJv+NYpYJ1F35 XROKEh5OIpcNKOPxBoof =w+jN -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Multiple SSL certificates on one Instance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Stefan, On 3/16/15 5:03 PM, Stefan Frei wrote: 2 points: configure the reverse proxy is simpler. s/simpler/possible/ tomcat may be harder to troubleshoot issues. Tomcat can't even do SNI at this point. i would take the prxy to do that, in fact we use squid rev-proxy to solve exact the same problem. It's nice not to have to introduce a reverse proxy unless it's actually necessary. Tomcat should really support SNI. - -chris 2015-03-16 14:16 GMT+01:00 Mark Thomas ma...@apache.org: On 16/03/2015 12:53, Rory Kelly wrote: Hey guys, I’ve a bad feeling what I’m trying to do is impossible, and I’m going to have to implement a different solution. Been hunting for an answer, but couldn’t find anything definite. I’m running Tomcat 8.0.18, Java 1.7.0_75-b13, Ubuntu 14.04. I have multiple sites running on Virtual Hosts on the instance. For a bit of background, I am intending on creating a 2-server load balanced system using nginx as a balancer on virtual servers (Best I can do, given our hosting/not possible to move away from it) I need each site to be protected by its own SSL certificate, provided by the client for each site. Can I actually have multiple SSL certs with Tomcat Virtual Hosts, or am I going to have to go learn nginx/httpd and provide it that way? https://bz.apache.org/bugzilla/show_bug.cgi?id=57108 Mark Thanks, Rory - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVCFARAAoJEBzwKT+lPKRYnSoQAI7II/iU2t/GrKj9F7c8suPr InjFD2BhHWIGqAzWiKQAOmoozgqLuGX6ME/Qmxd69eEoOLQelq0/ZJCA+VuH/Epk C5hMBflHwQPD9UHb98nxRzQ3FaXW2Jdh6qk1weYa696Ol/2cHabEs4MYaTHVlQvq E8dV6R0dhE4cU08tft0KCyk/i+OgTmyJpC6fxqxXjgoduauiLE9owzErywojWy7d PR7M/twuM5XGJBYY59oFDHZO0zrshMBxzHWmw1xHIMde5eDtlyeQo+xVzA7PiDpt LHGi9U0SX8MPR1+Vl9EZ0LdKxvIvpduFPleBDWub85iGKBdMUAiuYaknD2hZGCxF 4rDlOVpQpuHp9Sxk9TqTRG7vYMQR5wJpTtnvyBnZm7ls0VkBXaR9IiG9/LtUUHEh eVHux1XjYmDnnZb83FQ+C5QX2xDsJ53zjvtEgagEucMDWwf+cQwXCl1VLLemBHeF wem0sR225hGmD+FDDE7dqYvAQLzi4JbTXpOU6JZYBJVAvG+zg3stCcQJHdjp82GV bxSUlmE8jr3AWqNBhpOUdVkNbb0h8Eb6GU0in4TilD3AxAPwi5UOtpfFRE9mIm/F r2fN9Pzx3DQGikl1X2rRkjStLtZDh1PuB6IMg26Sq4HXtDD6ZABhGouxOWnb/oBz 4gSd0Em4+w8qkGr7bZBq =thve -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest Authentication problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Rainer, On 3/17/15 11:12 AM, Rainer Jung wrote: Am 17.03.2015 um 15:40 schrieb Sascha Skorupa: Hi Rainer, currently not (Apache 2.2) but it might be an option to upgrade the OS and the Apache if it leads to a solution. OK. But think twice, whether it is better to just compile mod_jk from sources or do the big update. +1 I find it hard to believe that you (or your NOC) would be willing to upgrade the OS and the web server to use an alternative solution, but not willing to upgrade to a newer version of single, specialized module for the web server. Note that you don't have to have a compiler on the target system; you just need to be able to cross-compile to that test system (or do what I do and have a spare server with identical architecture, etc. available for module builds). Updating to 2.4 will bring many interesting achievements, but just for fixing this issue quickly it would be better to update mod_jk, even if this means switching to a non-OS-provided variant. +1 Building is trivial. If you seriously plan the 2.4 update and you have a test system, I could provide you with the non-trivial workaround letting Apache set the cookie. You would need to thoroughly test this though. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVCFHcAAoJEBzwKT+lPKRYOQAQAJnIlsepWBvZlO438/zwXIYM WI0X3LspAUt1v1c0JOXagL5VUdZO68/euBV7rmoKaHvo11lEH5lFQ9M91unvRWer d7AQZoTc1+VQDcnBrGDzw6M7jQqlKf2Y7Jadlj9TfNm68cwCYFhpan1Wcv/XCMpy /1Q5j/gW77AdPNpAvtFGOXZ0HPbMpkC+ZpsfFjgpOrwUBPL195xpQXM5nJLoYpAa 7uR34FCAbIIR0Glho/IHqzadxrSBq3AEVZau1uiGi3t8BjuWcOfq85bMZ0dCGdl+ Hlj6wKaTpS6AJi9By5d0xbXkqu5wBY2qFgY6wNq/cHO/Js+svPPMtME7eUZiOPAY t2dUszkzqw0JOEqTN0I1gr0cGVOhJYbHMAdCHrb15FtWACeQVHVK7ikI0GJvKMG3 8EUIW21go3ID4jHBpexMC23QZDKfDTIhzx9Ec300lxRbjkfzpTCEvu3mM36w6y7+ fsRPPkpY0KqFe25nYw/DZCMS4KeAZ5dZSQa3sQSYgpozP71UrRZJw2+cqdALj29Q Ozru/eLGLAvJuOKbXgSMIBfEQugx8vTGzE60Db7e61thMPmyHXlHqi1+zKDnODej g6kbQtNDhak+0AfI2oFbmvHGz+hN8bAJa62hA/3jDKiYphxwH2JpJW4qmcs7HI91 qRp/u8yrAe8S/UAc+x+2 =95gA -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[Tomcat8] What happened to WebappLoader.addRepository()?
Hey tomcat users,
The javadoc for WebappLoader still tells me to use addRepository(), but that
method no longer exists. My team has implemented an extension of WebappLoader
that looked like this:
https://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/loader/WebappLoader.html
https://tomcat.apache.org/tomcat-8.0-doc/api/org/apache/catalina/loader/WebappLoader.html
@Override
protected void startInternal() throws LifecycleException {
// validate the context, which is used for debugging messages
Context context;
{
Container container = getContainer();
if (container == null) {
throw new LifecycleException(Container is null?!);
}
if (!(container instanceof Context)) {
throw new LifecycleException(Container is not an instance of
Context?!);
}
context = (Context) container;
}
if (ENVIRONMENT_ROOT != null ENVIRONMENT_ROOT.length() 0) {
// validate targetPackage
if (null == targetPackage) {
throw new LifecycleException(
Missing required Loader attribute \targetPackage\ in
Context configuration +
context.getConfigFile());
}
try {
// Excluded jars are those already pulled in by tomcat.
SetString allExcludedJars = getAllExcludedJars();
SetString reallyExcludedJars = new HashSetString();
// add JARs from target package as repositories
// getPackageClasspath finds the list of jars I want to include
for this webapp.
for (String jar : getPackageClasspath(targetPackage)) {
File file = new File(ENVIRONMENT_ROOT, jar);
// skip bad and unwanted JARs
if (allExcludedJars.contains(jar) || isBadJar(file)) {
reallyExcludedJars.add(jar);
} else {
// TODO: HOW TO FIX ME??
addRepository(file.toURI().toString());
}
}
log.info(Context path \ + context.getPath() + \ excluding
JARs: + reallyExcludedJars);
} catch (IOException e) {
throw new LifecycleException(
Problem setting classpath for context path \ +
context.getPath() + \,
e);
}
// getRepositoriesString() has been renamed to
getLoaderRepositoriesString()...
log.info(Context path \ + context.getPath() + \ using
classpath: + getRepositoriesString());
} else {
log.warning(MyWebappLoader seems to be used outside of my
environment. Delegating to parent.);
}
super.startInternal();
}
Can the community help me figure out how to upgrade this for tomcat 8?
