Re: Weird issue setting up SSL on a WinDoze box
delete the file tcnative-1.dll and tomcat reverts to java based ssl and keystores. On Wednesday, January 22, 2014, James H. H. Lampert < jam...@touchtonecorp.com> wrote: > On 1/22/14 5:26 PM, Caldarale, Charles R wrote: > >> You have installed and enabled the APR connector, but are trying to use >> the Java keystore. >> > > Actually, *I* didn't do the installation (the fellow at the next desk over > did), and so I have no idea what options were selected. > > AS/400 installations use the Java SL mechanism. I know exactly nothing > about APR or OpenSSL (a certain line from "Men in Black" pretty much sums > it up, http://www.imdb.com/title/tt0119654/quotes?item=qt0402580 -- at > this point, I'm "Jay" and everybody else on this list is "Kay"). If I sound > frustrated, it's because I am. > > I'll be looking up the links you gave me tomorrow morning; anything else > anybody can do to enlighten me would be appreciated. > > -- > JHHL > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Weird issue setting up SSL on a WinDoze box
On 1/22/14 5:26 PM, Caldarale, Charles R wrote: You have installed and enabled the APR connector, but are trying to use the Java keystore. Actually, *I* didn't do the installation (the fellow at the next desk over did), and so I have no idea what options were selected. AS/400 installations use the Java SL mechanism. I know exactly nothing about APR or OpenSSL (a certain line from "Men in Black" pretty much sums it up, http://www.imdb.com/title/tt0119654/quotes?item=qt0402580 -- at this point, I'm "Jay" and everybody else on this list is "Kay"). If I sound frustrated, it's because I am. I'll be looking up the links you gave me tomorrow morning; anything else anybody can do to enlighten me would be appreciated. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Weird issue setting up SSL on a WinDoze box
> From: James H. H. Lampert [mailto:jam...@touchtonecorp.com] > Subject: Weird issue setting up SSL on a WinDoze box > Caused by: java.lang.Exception: Connector attribute SSLCertificateFile > must be defined when using SSL with APR > The relevant connector tag in server.xml is, on this installation, > maxThreads="150" scheme="https" secure="true" >keystoreFile="C:/Program Files/Apache Software > Foundation/Tomcat 7.0/wttomcat.ks" >keyAlias = "wintouch" >clientAuth="false" sslProtocol="TLS" /> You have installed and enabled the APR connector, but are trying to use the Java keystore. APR uses OpenSSL, so its configuration is quite different, as is the certificate file: http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#SSL_Support_-_APR/Native If you want to use the Java SSL mechanism (it's slower), comment out the APR listener in server.xml: http://tomcat.apache.org/tomcat-7.0-doc/config/listeners.html#APR_Lifecycle_Listener_-_org.apache.catalina.core.AprLifecycleListener - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Weird issue setting up SSL on a WinDoze box
I've set up at least half a dozen AS/400 installations of Tomcat, with SSL on 443, and once I got the hang of it, they went smoothly, and ran flawlessly. So now, I'm asked to do it on a WinDoze Server 2008 box, and it's not working. Netsat -na shows 443 listening when Tomcat is active, and not listening when it isn't, but if I try to connect to https://localhost/, I get nothing. I get this in the Catalina log file: Jan 22, 2014 6:23:45 PM org.apache.catalina.core.StandardService initInternal SEVERE: Failed to initialize connector [Connector[HTTP/1.1-443]] org.apache.catalina.LifecycleException: Failed to initialize component [Connector[HTTP/1.1-443]] at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:106) at org.apache.catalina.core.StandardService.initInternal(StandardService.java:559) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102) at org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:814) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102) at org.apache.catalina.startup.Catalina.load(Catalina.java:639) at org.apache.catalina.startup.Catalina.load(Catalina.java:664) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:281) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:455) Caused by: org.apache.catalina.LifecycleException: Protocol handler initialization failed at org.apache.catalina.connector.Connector.initInternal(Connector.java:983) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102) ... 12 more Caused by: java.lang.Exception: Connector attribute SSLCertificateFile must be defined when using SSL with APR at org.apache.tomcat.util.net.AprEndpoint.bind(AprEndpoint.java:467) at org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:640) at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:434) at org.apache.catalina.connector.Connector.initInternal(Connector.java:981) ... 13 more The relevant connector tag in server.xml is, on this installation, I tried it with and without the "C:"; no effect. The pathname looks right. The alias is correct. The keystore password is the default. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: running packed WAR files with embedded tomcat
Thanks for the example Valery. Even with your approach, I'm finding that
unless I create a directory "webapps" in the directory from which I run the
program, I get this exception:
java.io.IOException: Application base [{1}] for host [/tmp/./webapps] does
not exist or is not a directory.
It seems to me that the WAR is still needing to be unpacked prior to
running.
--john
On Wed, Jan 22, 2014 at 12:16 AM, Valery Shyshkin wrote:
> The code below works fine on my Win 7 PC
>
> final Tomcat tomcat = new Tomcat();
> tomcat.setPort(9191);
> //File baseDir = new File(System.getProperty("java.io.tmpdir"));
> File baseDir = new File(".");
> tomcat.addContext("", baseDir.getAbsolutePath());
> tomcat.addWebapp("/WebApplication2",
> "D:\\VnsTestApps\\Nb74Jetty\\WebApplication2\\dist\\WebApplication2.war");
>
> tomcat.start();
> tomcat.getServer().await();
>
>
>
> 2014/1/22 Valery Shyshkin
>
> > By the way it's not a suggestion it's a signature of the addWebApp
> > method.
> > I'll try to find my working code and send it.
> >
> >
> > 2014/1/22 Valery Shyshkin
> >
> >> Try:
> >>
> >> File baseDir = new File(System.getProperty("java.io.tmpdir"));
> >> tomcat.addContext("", baseDir.getAbsolutePath());
> >>
> >>
> >>
> >>
> >> 2014/1/22 John Cartwright - NOAA Federal
> >>
> >>> Thanks for the suggestion Valery, but swapping the arguments doesn't
> >>> work.
> >>>
> >>> --john
> >>>
> >>>
> >>>
> >>> On Tue, Jan 21, 2014 at 8:12 AM, Valery Shyshkin <
> vns.shysh...@gmail.com
> >>> >wrote:
> >>>
> >>> > May be tomcat.addWebapp(contextName,pathToWarFile) instead of
> >>> > tomcat.addWebapp(pathToWarFile, contextName) will help yoo.
> >>> >
> >>> >
> >>> > 2014/1/21 John Cartwright - NOAA Federal >
> >>> >
> >>> > > Hello All,
> >>> > >
> >>> > > I'm trying to create a very basic embeded tomcat 7 application to
> >>> host a
> >>> > > packed WAR file. My code looks like:
> >>> > >
> >>> > > Tomcat tomcat = new Tomcat()
> >>> > > tomcat.setPort(port)
> >>> > > tomcat.setBaseDir(".")
> >>> > > tomcat.addWebapp(pathToWarFile, contextName)
> >>> > >
> >>> > > It seems to work, but I'm getting an exception on startup
> complaining
> >>> > about
> >>> > > the missing webapps directory:
> >>> > >
> >>> > >SEVERE: Exception fixing docBase for context [/quickstart]
> >>> > >java.io.IOException: Application base [{1}] for host
> >>> > > [/private/tmp/./webapps] does not exist or is not a directory.
> >>> > >
> >>> > > Can someone please direct me to a better way to do this? Is
> >>> > > Tomcat#addWebapp not appropriate if hosting a packed WAR file?
> >>> > >
> >>> > > Thanks!
> >>> > >
> >>> > > --john
> >>> > >
> >>> >
> >>>
> >>
> >>
> >
>
Re: Create XA Datasource with DBCP/Tomcat 6
On 22/01/2014 17:04, Sylvain Goulmy wrote: > Hi, > > I'd like to create a XA datasource within Tomcat 6 but i don't find any > example to do so. Tomcat6 provides its own dbcp package but when i compare > it to the standard dbcp package i notice that class related to XA Driver > are missing. The following classes : > > org/apache/commons/dbcp/managed/DataSourceXAConnectionFactory.class > org/apache/commons/dbcp/managed/LocalXAConnectionFactory$LocalXAResource.class > org/apache/commons/dbcp/managed/LocalXAConnectionFactory.class > org/apache/commons/dbcp/managed/XAConnectionFactory.class > > are not part of the dbcp provided by Tomcat. > > Is there any way to define a XA Datasource with Tomcat 6 ? Add Apache Commons DBCP to your web application and use it directly. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Create XA Datasource with DBCP/Tomcat 6
Hi, I'd like to create a XA datasource within Tomcat 6 but i don't find any example to do so. Tomcat6 provides its own dbcp package but when i compare it to the standard dbcp package i notice that class related to XA Driver are missing. The following classes : org/apache/commons/dbcp/managed/DataSourceXAConnectionFactory.class org/apache/commons/dbcp/managed/LocalXAConnectionFactory$LocalXAResource.class org/apache/commons/dbcp/managed/LocalXAConnectionFactory.class org/apache/commons/dbcp/managed/XAConnectionFactory.class are not part of the dbcp provided by Tomcat. Is there any way to define a XA Datasource with Tomcat 6 ? Any feedback would be appreciated. Regards.
Re: [OT] RE: Cannot connect from outside using Tomcat 7/APR/SSL on AWS Windows system
Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Konstantin, On 1/22/14, 9:03 AM, Konstantin Preißer wrote: Hi Jeffrey, -Original Message- From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com] Sent: Tuesday, January 21, 2014 10:19 PM Eureka, I finally figured it out! It was a real eureka moment, some remembrance burned its way up from my subconscious and I had the answer. Ready guys? Really surprised no one mentioned it. It was Windows F-ing Firewall! Good to hear that you could find and solve the problem. (Off topic:) I HATE WINDOWS!! What I can't quite understand is, how one can "hate" Windows or its "F-ing" firewall, if they just do what they were configured to do... ;-) When setting up the Windows Firewall, I normally only create rules for specific (TCP) ports, not for specific executables, so that the firewall allows connections to a TCP port regardless of what the name or path of the executable is. Actually, as surprising as it can sometimes be, I find that the Windows firewall is better than iptables *because* it /can/ do things like this. You can make your system a bit safer. For instance, if your server is compromised (yes, I know, once you're owned, you're owned) and the attacker installs some malware of some kind, that malware will not be able to bind to a port or even make outgoing connections, even on "standard" outgoing ports -- for instance HTTP. Lots of malware connects to external C&C servers to give instructions, and the Windows wirewall makes it easy to prevent that from happening even when ports like 80 are used -- and typically left wide-open on servers. Of course, one could argue that the Windows Firewall needs to offer this, because it is inherently easier to infect with malware a Windows server than a Linux server. So it needs to compensate somehow.. ;-) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [OT] RE: Cannot connect from outside using Tomcat 7/APR/SSL on AWS Windows system
> -Original Message- > From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Sent: Wednesday, January 22, 2014 9:15 AM > To: Tomcat Users List > Subject: Re: [OT] RE: Cannot connect from outside using Tomcat > 7/APR/SSL on AWS Windows system > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Konstantin, > > On 1/22/14, 9:03 AM, Konstantin Preißer wrote: > > Hi Jeffrey, > > > >> -Original Message- From: Jeffrey Janner > >> [mailto:jeffrey.jan...@polydyne.com] Sent: Tuesday, January 21, > >> 2014 10:19 PM > > > >> Eureka, I finally figured it out! It was a real eureka moment, some > >> remembrance burned its way up from my subconscious and I had the > >> answer. Ready guys? Really surprised no one mentioned it. It was > >> Windows F-ing Firewall! > > > > Good to hear that you could find and solve the problem. > > > > (Off topic:) > > > >> I HATE WINDOWS!! > > > > What I can't quite understand is, how one can "hate" Windows or its > > "F-ing" firewall, if they just do what they were configured to > > do... ;-) > > > > When setting up the Windows Firewall, I normally only create rules > for > > specific (TCP) ports, not for specific executables, so that the > > firewall allows connections to a TCP port regardless of what the name > > or path of the executable is. > > Actually, as surprising as it can sometimes be, I find that the Windows > firewall is better than iptables *because* it /can/ do things like > this. You can make your system a bit safer. > > For instance, if your server is compromised (yes, I know, once you're > owned, you're owned) and the attacker installs some malware of some > kind, that malware will not be able to bind to a port or even make > outgoing connections, even on "standard" outgoing ports -- for instance > HTTP. > > Lots of malware connects to external C&C servers to give instructions, > and the Windows wirewall makes it easy to prevent that from happening > even when ports like 80 are used -- and typically left wide-open on > servers. > > - -chris +1 And another reason I had in mind when I originally set it up. Just have to remember to do it for each new install, or actually read my notes on the proper way to add an instance. Again, totally my own fault here all around, but unlike you youngsters, my mind don't work as well as it used to. I'm at the stage: A banana a day keeps the doctor away. Jeff - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [OT] RE: Cannot connect from outside using Tomcat 7/APR/SSL on AWS Windows system
> -Original Message- > From: Konstantin Preißer [mailto:kpreis...@apache.org] > Sent: Wednesday, January 22, 2014 8:03 AM > To: 'Tomcat Users List' > Subject: [OT] RE: Cannot connect from outside using Tomcat 7/APR/SSL on > AWS Windows system > > Hi Jeffrey, > > > -Original Message- > > From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com] > > Sent: Tuesday, January 21, 2014 10:19 PM > > > Eureka, I finally figured it out! > > It was a real eureka moment, some remembrance burned its way up from > > my subconscious and I had the answer. > > Ready guys? Really surprised no one mentioned it. > > It was Windows F-ing Firewall! > > Good to hear that you could find and solve the problem. > > (Off topic:) > > > I HATE WINDOWS!! > > What I can't quite understand is, how one can "hate" Windows or its "F- > ing" firewall, if they just do what they were configured to do... > ;-) > > When setting up the Windows Firewall, I normally only create rules for > specific (TCP) ports, not for specific executables, so that the > firewall allows connections to a TCP port regardless of what the name > or path of the executable is. > Well, I wouldn't run Windows at all, except my backup "staff" doesn’t/can't/won't understand Linux. That said, this is the only setup that I actually run the Windows software firewall (or Linux's iptables for that matter), because I don't really trust the Amazon security infrastructure on its own. All my own servers sit behind a firewall appliance that I know and trust and can monitor, and I generally can trust those persons who have internal access. The reason I did this as executables instead of just opening a set of ports (80,443), is that I wanted to be sure I caught any ports the executable might need in addition to the one's I know about directly. Plus, I like to run JMX for monitoring, and have several instances, each with their own JMX port set. So it's either do it by executable, or adding/updating a JMX rule each time I add a new instance, and likely run into this "why won't it work" problem all over again. Sort of a preference thingy I guess.
Re: Tomcat 7.0.50 tldValidation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 1/22/14, 10:15 AM, Mark Thomas wrote: > On 22/01/2014 14:12, Paul Beckett wrote: >> Does anyone know: > - Why this occurs only since 7.0.50 Changes to XML validation > introduced in 7.0.48->7.0.50 > > - Where the root issue is likely to be / how to fix it Psi probe > ships with an implementation of the standard tag library that > includes the following: > xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee > web-jsptaglibrary_2_0.xsd" > > in a tag library descriptor. The "web-jsptaglibrary_2_0.xsd" is a > hint to the location but that is not enough for Tomcat to identify > it. Later versions of the standard tag library use: > > xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee > http://java.sun.com/xml/ns/j2ee/web-jsptaglibrary_2_0.xsd"; > > which is unique so Tomcat is able to identify it. > > One could argue that web-jsptaglibrary_2_0.xsd should be sufficient > to identify location of the intended schema. Would it be worth it to include the spec-appropriate TLD Schema along with Tomcat so that simply mentioning the system id would be enough for Tomcat to recognize it when configuring the digester? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJS3+KkAAoJEBzwKT+lPKRYZjQQAJzIJIP9nQXs6CfKFoN8Y+Ay xDfCyiUgreAPvtCdGj6PbtsOQoei1sr+c52Dgyz7YYuMZjZhCYCF38BFhsNyhHrw SWRRs8MIqbYnR7NU2YX22HEcf84SCBXMNK7+K261zlGAFsuYCTFoeOaCx3z/f993 jiPbZfjY0cNHNKJS3VilItUzjdH73noWhjmAHUVQJ4gD5Aa+ZI2f5Enbw0lGXIm1 RSOLJ7+9Zm6AKqeJ+pI4mARxUK9crXqMbmaT/RZKj9zV3T0GrMcUvc7BtvGHsKTv JBckJKleb1dx1hCM1r9XqMvaQ8gU623NYDPq+9w6+cJQdR6oEtBCL3ayLfVTX5Dz PQqmvn8WZUxi7xuENvzlqljfmF6xoFKCfRTHmuiyusch77KsmVHMNJDkoEUhccrE G6Qy749nIIvvhaBMAzSD174XijSiBSAuJxn+zZyiojAcd9S37f4ZKn8cCnTPPZdp XRV3F/tD802qFfKHr887OxIchpKsyTlXSnWVuXYEasg09kPAYNCa6tCZ5xHRazr+ suwM301luStIs3EF+goix5H0njFaQO9bWvVNnjJyvKlQfxJqVyQseMCjDBwYa05C n55LJi0H0Jl3i7qmpLvVIzX54HsUsJiKYp6JCOlNYoVXaZm7xlVtWoZwXj370yX/ Bh3LLh2/gUMPEIn9QeaU =eXbe -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7.0.50 tldValidation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Paul, On 1/22/14, 10:20 AM, Christopher Schultz wrote: > Paul, > > On 1/22/14, 9:12 AM, Paul Beckett wrote: >> I've recently upgraded some of our tomcats from 7.0.47 to 7.0.50. >> After upgrading I got lots of the below errors recorded in >> catalina.out The errors are not logged if I disable >> tldValidation (either by settings tldValidation=false in >> context.xml or removing the CATALINA_OPTS property: >> org.apache.catalina.STRICT_SERVLET_COMPLIANCE=true . The errors >> occur in a number of applications, here is the beginning of one >> of the TLD files that seems to cause this issue:> version="1.0" encoding="UTF-8" ?> > xmlns="http://java.sun.com/xml/ns/j2ee"; >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; >> xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee >> web-jsptaglibrary_2_0.xsd"version="2.0"> > > When I copy/pasted the xsi:schemaLocation URL out of your document, > it appears there is a space between "j2ee" and > "web-jsptaglibrary_2_0.xsd". Should that have been a "/"? Or was > that a copy/paste error into your post? Never mind. Brain fart. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJS3+JfAAoJEBzwKT+lPKRYaZAP/iRXyt3btxde5FLHu+4flrx+ HmiwhhqvgcFDoO9fFc+yLk+o7XLW8UkhvhfTQ3HBNHRsPC8DgCx18tPCfxoxQutc e3b20n6clChiev7GUmPUqMSieBAYGLTWTL6WngF2CQ+wRRYpLTypXU0sPQSe3x3F 4/evKjepkvqR4+bpwkWTAfKO0DQqcIDKfb/lqTQ9fRUjx1fXXnEuEmss9OlqSzpX aElaZ7KwvtcTRjj1Gc+fusJQhhp/HDFdotL/VE+tAbfqXbP4sqk5MF2xUAoYddj2 U+SGJoU1nzKmw3t/1XrCJ2IszUXUiClLKUQbKwwUaIC5qqws3Qd6P8ZCWQXT6Q+/ /YDsVmX3v3F1O/1ioluwId4PGsv7BycbPlKP3GtSFetkMXjvjgqizxuvMETi3TnA FJKFZYyAztNiiGe5G6QwcFNycQNkcifrQ7+8ZyiINDrOSaifz4fnciWFbFdaD+5Y ZKrXuhzrLQnjqleSKEUs2yrDBa4pxoZh1mRc5KKpdwSMvNZlutA86nlKZ3qeKtmv 7kOADcGLArbWDL3pp36NENUon6ulF67ab+kV47zReW3nWW5kjPerZ49qSR4hc2qi w/2Rx8ApV3wg/L8S+QMBZQI7Ck2QqJnMok5CllYHnF0PvDAr7NNPnu1RYMtL2nrL 92ap4laQT+n18jKwztJh =pAvJ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7.0.50 tldValidation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Paul, On 1/22/14, 9:12 AM, Paul Beckett wrote: > I've recently upgraded some of our tomcats from 7.0.47 to 7.0.50. > After upgrading I got lots of the below errors recorded in > catalina.out The errors are not logged if I disable tldValidation > (either by settings tldValidation=false in context.xml or removing > the CATALINA_OPTS property: > org.apache.catalina.STRICT_SERVLET_COMPLIANCE=true . The errors > occur in a number of applications, here is the beginning of one of > the TLD files that seems to cause this issue: encoding="UTF-8" ?> http://java.sun.com/xml/ns/j2ee"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee > web-jsptaglibrary_2_0.xsd"version="2.0"> When I copy/pasted the xsi:schemaLocation URL out of your document, it appears there is a space between "j2ee" and "web-jsptaglibrary_2_0.xsd". Should that have been a "/"? Or was that a copy/paste error into your post? > Does anyone know:- Why this occurs only since 7.0.50- Where the > root issue is likely to be / how to fix it- Are there any > significant downsides to turning off tldValidation- The errors > don't appear to have stopped things working, can they be safely > ignored Other than the above, it's possible that the URL isn't reachable. Firewall or lack of direct connection to the Internet? It can be safely ignored if you don't need XML validation. Presumably, you have enabled validation because you actually want validation, so you should probably fix this. On another note, some Schema documents in their original locations may be quite slow to download. You might want to figure out how to plug-into the XML catalog mechanism Tomcat (hopefully!) uses to validate various XML documents it knows about (e.g. web.xml, etc.). Otherwise, you may find that deploying your webapp takes a long time just due to network lag. > Any advice / help would be greatly appreciated. Thanks,Paul > > WARNING: Parse Warning Error at line 6 column 19: > schema_reference.4: Failed to read schema document > 'web-jsptaglibrary_2_0.xsd', because 1) could not find the > document; 2) the document could not be read; 3) the root element of > the document is not .org.xml.sax.SAXParseException; > lineNumber: 6; columnNumber: 19; schema_reference.4: Failed to read > schema document 'web-jsptaglibrary_2_0.xsd', because 1) could not > find the document; 2) the document could not be read; 3) the root > element of the document is not .at > com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:198) > at > com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.warning(ErrorHandlerWrapper.java:99) > at > com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:433) > at > com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:368) > at > com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:325) > at > com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.findSchemaGrammar(XMLSchemaValidator.java:2457) > at > com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.handleStartElement(XMLSchemaValidator.java:1772) > at > com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.startElement(XMLSchemaValidator.java:746) > at > com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:378) > at > com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl$NSContentDriver.scanRootElementHook(XMLNSDocumentScannerImpl.java:604) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:3122) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(XMLDocumentScannerImpl.java:880) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:606) > at > com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:117) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:510) > at > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:848) > at > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:777) > at > com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141) > at > com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1213) > at > com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:649) > at > org.apache.tomcat.util.digester.Digester.parse(Digester.java:1561) > at > org.apache.catalina.startup.TldConfig.tldScanStream(TldConfig.java:537) > at > org.apache.catalina.startup.TldConfi
Re: Tomcat 7.0.50 tldValidation
On 22/01/2014 14:12, Paul Beckett wrote: > Does anyone know: - Why this occurs only since 7.0.50 Changes to XML validation introduced in 7.0.48->7.0.50 - Where the root issue is likely to be / how to fix it Psi probe ships with an implementation of the standard tag library that includes the following: xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee web-jsptaglibrary_2_0.xsd" in a tag library descriptor. The "web-jsptaglibrary_2_0.xsd" is a hint to the location but that is not enough for Tomcat to identify it. Later versions of the standard tag library use: xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-jsptaglibrary_2_0.xsd"; which is unique so Tomcat is able to identify it. One could argue that web-jsptaglibrary_2_0.xsd should be sufficient to identify location of the intended schema. - Are there any significant downsides to turning off tldValidation Only that if there are errors, you won't see them. - The errors don't appear to have stopped things working, can they be safely ignored Yes. Replacing the JSTL implementation in Psi Probe with the one from the examples app should also fix the issue. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] RE: Cannot connect from outside using Tomcat 7/APR/SSL on AWS Windows system
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Konstantin, On 1/22/14, 9:03 AM, Konstantin Preißer wrote: > Hi Jeffrey, > >> -Original Message- From: Jeffrey Janner >> [mailto:jeffrey.jan...@polydyne.com] Sent: Tuesday, January 21, >> 2014 10:19 PM > >> Eureka, I finally figured it out! It was a real eureka moment, >> some remembrance burned its way up from my subconscious and I had >> the answer. Ready guys? Really surprised no one mentioned it. It >> was Windows F-ing Firewall! > > Good to hear that you could find and solve the problem. > > (Off topic:) > >> I HATE WINDOWS!! > > What I can't quite understand is, how one can "hate" Windows or its > "F-ing" firewall, if they just do what they were configured to > do... ;-) > > When setting up the Windows Firewall, I normally only create rules > for specific (TCP) ports, not for specific executables, so that the > firewall allows connections to a TCP port regardless of what the > name or path of the executable is. Actually, as surprising as it can sometimes be, I find that the Windows firewall is better than iptables *because* it /can/ do things like this. You can make your system a bit safer. For instance, if your server is compromised (yes, I know, once you're owned, you're owned) and the attacker installs some malware of some kind, that malware will not be able to bind to a port or even make outgoing connections, even on "standard" outgoing ports -- for instance HTTP. Lots of malware connects to external C&C servers to give instructions, and the Windows wirewall makes it easy to prevent that from happening even when ports like 80 are used -- and typically left wide-open on servers. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJS3+BXAAoJEBzwKT+lPKRY90wP+wf4cgzEyOG0ygkZHsXto6Yq HFrJIUGq6f+G5GoJixkpMWGpyff8JoCwWGcvoR6FZ/BTEQRoDwFa/K6wJSgFdWJO 50YzSy/YR8eceApeRSd3GDK08Bs04ApOcZbkEhHdWIhSgko/afHXegYGswW0TYcQ sTarB6FjuDMytwMnEFzpfiAbkxdNPi5VjgISgQnZyuMp1e/+jVEX54E3NT3CcVvU 99FkCFz9fF/rf58ZV6OcOZJjpDFSkXR+AczBtngJ2J371tTKvf7gjny+L/NhTU40 VSCinqDAoV00OPvt+a1kDIDmxmVBKUSl/lFGtCKCzfBC9zaotuJNFsDdTZo6VSvn e952a3XlyoBS8KgI9d5wWuTy/tnQv/ACXTyvFYRdSPF4lcbVlyFJJte/oQ+sJwm6 iJsNlfiHzn3SMbYY2pgqYeE4FWyrO2xLaB6G6AggIoD4b8gJKgL+EENGf2/8g+hK 4kK78dFMyfFpaSbKs0HzQthi5L+/+QuRBwjfJ9Ha9P3hDjZwC6T5w/2AtrfCdEE+ UUtc/hnvnMAHRUZr09WFByv3QXk4SnmAzmJs3esGdWk3fIbZI9NGfq12JKAXxU/B tReqRDGkUW2rW0o4Gnkpi3Am8jVws6EsoNxI8pgVu8hzSPkZzjCpSOQLI03erCA5 UZlWdqV/De3Aq+hqJp8P =tJQA -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cannot connect from outside using Tomcat 7/APR/SSL on AWS Windows system
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jeffrey, On 1/21/14, 4:18 PM, Jeffrey Janner wrote: > > > Eureka, I finally figured it out! It was a real eureka moment, some > remembrance burned its way up from my subconscious and I had the > answer. Ready guys? Really surprised no one mentioned it. It was > Windows F-ing Firewall! I beat your analysis by an hour ;) Too bad I couldn't reach you with my telepathy. I would have needed Pid for that... > Since the server is hosted at AWS and I in no way trust their > minimal firewall they refer to as "security groups" (just a bunch > of iptables rules), I left the Windows Firewall up and running. I > haven't figured out a rule to apply to Tomcat in general, so I have > to set up a rule for each Tomcat instance (tied to the > bin\commons_deamon_name.exe file) and I hadn't done that for the > new install. Considering it's been a year since I had to do one of > these, I completely forgot about that step (doing it without my > notes). Once I did that for my new install, BINGO! It also explains > why the re-install of Tomcat 6 didn't work, since I was using a > different service name. If I re-installed with the old service > name, then it "mysteriously" worked, because the old firewall rule > was still in existance. > > Thanks for following me down this rabbit hole. I hope not to lead > you down another anytime soon. > > Jeff I HATE WINDOWS!! You know... Linux is available and even cheaper than Windows on AWS. ;) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJS3998AAoJEBzwKT+lPKRYdUQP/RoTLcmJ3ERoBFiJj8mx5nqQ 19o8gpiPzQDK0owQ5qrvFA3e1yDWHN+T1HvFuabZW3crq8RmlzHbYLyboSTc4VHq ixx33iUh3XE3XVDMknhXMz7BWwdeJt3xISvCHG2Rh4KcghmRpG5PmNog6GgRge39 VyR0HxphCSZy9yEJYPm7apLHy+l0F+GOU0LaeQG6GbtPcq2zq/nG/DAAB5fyLoah Jddsh3nmbvZjb3nZgUUZgPpXDGR/yw6mXxshCUtmqXwK5G1vG5+CdFpvRuwdDUy0 hF/aGF8YnBWU3hCYbJltL10TUPAsCrnv4KOPbKCRtolOq0vSETzhLk/tb7/BQrYE 9RZVa0/6dM7hSGNORwwVeuSChPgi4Dyt7IysOio2AyDSfpBVajoxHTiA+3hE5ppU R4Ef++kiQ52Pq7vDfzfiAhvmAg1ZrnN0PC066Sob6gtRule4KmM7usxGxayRB1v3 xccHIo5g/FIClFa2JEC7Rt8UV2C5bWxpGNOEtdP5X13+52bFl9pSGIa7J5xs42kt 5JnMOSLLVl5F5HQ9M1PFD1ptItUiYapZTwDsce6QEYkiP34kse5Rjq2tooxWdLKN JWNCZy5rdB4nL6W17r1ZR/Wp2+nUhvd3lvhGnpkxryWDpkIQNbhpkxBKjhUPV5VT rFtwHOpP+2GkgnZEtWzN =g3p9 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: the latest tomcat 7.0.50 has a problem when used through osgi (like eclipse)
thx :) On 22 January 2014 13:02, Mark Thomas wrote: > On 22/01/2014 11:56, Johan Compagner wrote: > > this is because tomcat expects that the 2 jars servlet-api.jar and > > jsp-api.jar are in the same classloader > > https://issues.apache.org/bugzilla/show_bug.cgi?id=56016 > > http://svn.us.apache.org/repos/asf/tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml > > Mark > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- Johan Compagner Servoy
Tomcat 7.0.50 tldValidation
I've recently upgraded some of our tomcats from 7.0.47 to 7.0.50. After upgrading I got lots of the below errors recorded in catalina.out The errors are not logged if I disable tldValidation (either by settings tldValidation=false in context.xml or removing the CATALINA_OPTS property: org.apache.catalina.STRICT_SERVLET_COMPLIANCE=true . The errors occur in a number of applications, here is the beginning of one of the TLD files that seems to cause this issue: http://java.sun.com/xml/ns/j2ee"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee web-jsptaglibrary_2_0.xsd" version="2.0"> Does anyone know:- Why this occurs only since 7.0.50- Where the root issue is likely to be / how to fix it- Are there any significant downsides to turning off tldValidation- The errors don't appear to have stopped things working, can they be safely ignored Any advice / help would be greatly appreciated. Thanks,Paul WARNING: Parse Warning Error at line 6 column 19: schema_reference.4: Failed to read schema document 'web-jsptaglibrary_2_0.xsd', because 1) could not find the document; 2) the document could not be read; 3) the root element of the document is not .org.xml.sax.SAXParseException; lineNumber: 6; columnNumber: 19; schema_reference.4: Failed to read schema document 'web-jsptaglibrary_2_0.xsd', because 1) could not find the document; 2) the document could not be read; 3) the root element of the document is not .at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:198) at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.warning(ErrorHandlerWrapper.java:99) at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:433) at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:368) at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:325) at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.findSchemaGrammar(XMLSchemaValidator.java:2457) at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.handleStartElement(XMLSchemaValidator.java:1772) at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.startElement(XMLSchemaValidator.java:746) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:378) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl$NSContentDriver.scanRootElementHook(XMLNSDocumentScannerImpl.java:604) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:3122) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(XMLDocumentScannerImpl.java:880) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:606) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:117) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:510) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:848) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:777) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1213) at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:649) at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1561) at org.apache.catalina.startup.TldConfig.tldScanStream(TldConfig.java:537) at org.apache.catalina.startup.TldConfig.tldScanJar(TldConfig.java:492) at org.apache.catalina.startup.TldConfig.access$100(TldConfig.java:61) at org.apache.catalina.startup.TldConfig$TldJarScannerCallback.scan(TldConfig.java:293) at org.apache.tomcat.util.scan.StandardJarScanner.process(StandardJarScanner.java:259) at org.apache.tomcat.util.scan.StandardJarScanner.scan(StandardJarScanner.java:178) at org.apache.catalina.startup.TldConfig.execute(TldConfig.java:266) at org.apache.catalina.startup.TldConfig.lifecycleEvent(TldConfig.java:562) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5343) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:
[OT] RE: Cannot connect from outside using Tomcat 7/APR/SSL on AWS Windows system
Hi Jeffrey, > -Original Message- > From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com] > Sent: Tuesday, January 21, 2014 10:19 PM > Eureka, I finally figured it out! > It was a real eureka moment, some remembrance burned its way up from > my subconscious and I had the answer. > Ready guys? Really surprised no one mentioned it. > It was Windows F-ing Firewall! Good to hear that you could find and solve the problem. (Off topic:) > I HATE WINDOWS!! What I can't quite understand is, how one can "hate" Windows or its "F-ing" firewall, if they just do what they were configured to do... ;-) When setting up the Windows Firewall, I normally only create rules for specific (TCP) ports, not for specific executables, so that the firewall allows connections to a TCP port regardless of what the name or path of the executable is. Regards, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: FarmWarDeployer ocassionally fails with "Application is being serviced"
I opened a Bug at https://issues.apache.org/bugzilla/show_bug.cgi?id=56051 I will give disabling automatic deployment a try and comment on the bug if that changes things. We are experimenting as well with just skipping the whole Cluster/FarmWarDeployer thing completely and just deploying through manager/curl on all nodes, as the application is stateless anyways. Thanks for your help! -Ursprüngliche Nachricht- Von: Mark Thomas [mailto:ma...@apache.org] Gesendet: Mittwoch, 22. Januar 2014 13:12 An: Tomcat Users List Betreff: Re: FarmWarDeployer ocassionally fails with "Application is being serviced" On 22/01/2014 10:24, Michael Gloegl wrote: > Can somebody shed any light here on what the "serviced" status means and how > we can avoid this FarmWarDeployer Failure? It usually means that the manager application or the auto deployment code is doing something (starting, stopping, deploying, undeploying etc) the web application. The Javadoc looks like it could do with some fixes. Looking at the docs and the code, the problem is that the FarmWarDeployer writes the WAR to the appBase and then marks it is serviced. This means that the auto deployment code may get there first which confuses the FarmWarDeployer. I'd say this is a bug in the FarmWarDeployer. Please open a Bugzilla entry. As a work-around, you should be able to disable automatic deployment (untested). Thanks, Mark - 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: FarmWarDeployer ocassionally fails with "Application is being serviced"
On 22/01/2014 10:24, Michael Gloegl wrote: > Can somebody shed any light here on what the "serviced" status means and how > we can avoid this FarmWarDeployer Failure? It usually means that the manager application or the auto deployment code is doing something (starting, stopping, deploying, undeploying etc) the web application. The Javadoc looks like it could do with some fixes. Looking at the docs and the code, the problem is that the FarmWarDeployer writes the WAR to the appBase and then marks it is serviced. This means that the auto deployment code may get there first which confuses the FarmWarDeployer. I'd say this is a bug in the FarmWarDeployer. Please open a Bugzilla entry. As a work-around, you should be able to disable automatic deployment (untested). Thanks, Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: the latest tomcat 7.0.50 has a problem when used through osgi (like eclipse)
On 22/01/2014 11:56, Johan Compagner wrote: > this is because tomcat expects that the 2 jars servlet-api.jar and > jsp-api.jar are in the same classloader https://issues.apache.org/bugzilla/show_bug.cgi?id=56016 http://svn.us.apache.org/repos/asf/tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
the latest tomcat 7.0.50 has a problem when used through osgi (like eclipse)
this is because tomcat expects that the 2 jars servlet-api.jar and
jsp-api.jar are in the same classloader
because org.apache.tomcat.util.descriptor.DigesterFactory has this method:
private static String idFor(String url) {
URL id = ServletContext.class.getResource("resources/" + url);
if (id == null) {
id = ServletContext.class.getResource("jsp/resources/" + url);
}
return id.toExternalForm();
}
thats kind of wrong, because ServletContext is in servlet-api but the
"jsp/resources/" dir is in the jsp-api.jar
so ServletContext should not be used to get the "jsp/resources" from the
js-api.jar
i think the code should be something like
private static String idFor(String url) {
URL id = ServletContext.class.getResource("resources/" + url);
if (id == null) {
id = JspContext.class.getResource("resources/" + url);
}
return id.toExternalForm();
}
So that at least the right classloader that also loads the JspContext is
used to get the jsp resources.
--
Johan Compagner
Servoy
FarmWarDeployer ocassionally fails with "Application is being serviced"
We are trying to use FarmWarDeployer at the moment, however it fails ocassionally on the "slave" nodes with the following log message: Jan 22, 2014 11:00:23 AM org.apache.catalina.ha.deploy.FarmWarDeployer messageReceived SEVERE: Application [/xxx] is being serviced. Touch war file [xxx.war] again! It occurs sporadically and after touching the war the deployment usually works in a second try. However it is pretty annoying because we always have to check if deployment might have failed or not on individual nodes. FarmWarDeployer does call mBeanServer.invoke(oname, "isServiced" ... to determine if an application is being considered "serviced", its documented with "Invoke the check method on the deployer." However I can find no information on what the "isServiced" MBean method actually does and how we can prevent this deployment error other than "try again". All the information I can find is that this method checks if an application is being serviced by another component. Can somebody shed any light here on what the "serviced" status means and how we can avoid this FarmWarDeployer Failure? Thanks in advance for any help, Michael - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Expected Date for Stable release of Tomcat version 8
On 22/01/2014 00:38, Melanie Langlois wrote: > Hi, > > Do you have an ETA for a stable release of Tomcat version 8? No. It depends on the feedback we get from the 8.0.x releases. We have had a number of RCs and the next release will be 8.0.0. I'd expect that to be beta. How many further releases it takes to get from beta to stable varies from major version to major version but I'd hope this would happen fairly quickly. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
