DO NOT REPLY [Bug 44588] New: Apps are not available while they are being deployed
https://issues.apache.org/bugzilla/show_bug.cgi?id=44588 Summary: Apps are not available while they are being deployed Product: Tomcat 5 Version: 5.5.25 Platform: Macintosh OS/Version: Mac OS X 10.4 Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I'm using the deployment ant task to do a live deploy to our server at a colocation facility. It takes about 2 minutes to upload the application to the server. The application is down with a 404 (The requested resource (/) is not available) for that 2 minutes span. After the application finishes upload, the app reloads and works as expected. Since this application runs our main company web site, we want to minimize downtime. Is there a way that the deployer could upload the new app while the old one is still running, and then briefly take down the old site to reload the new one? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 44588] Apps are not available while they are being deployed
https://issues.apache.org/bugzilla/show_bug.cgi?id=44588 Mark Thomas <[EMAIL PROTECTED]> changed: What|Removed |Added Severity|normal |enhancement Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #1 from Mark Thomas <[EMAIL PROTECTED]> 2008-03-12 06:36:22 PST --- Not without a lot of re-work. The 'right' way to do this is with a simple cluster fronted by httpd. The sequence is then: - disable Tomcat A - wait for requests to finish on A - upgrade A - enable A - disable B - wait for requests to finish on B - upgrade B - enable B You can do all of this on a single machine and you end up with zero down time. Ask on the users list of you need help settign this up. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
tomcat native 1.1.13 for win32
Hi to all, I used to get the win32 tcnative at http://tomcat.heanet.ie/native/ but there is only a 1.1.12 there. Do you know alternate location ? Also, shouldn't we provide such win32/win64 binaries at tomcat.apache.org ? Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat native 1.1.13 for win32
Henri Gomez wrote: Hi to all, I used to get the win32 tcnative at http://tomcat.heanet.ie/native/ but there is only a 1.1.12 there. Do you know alternate location ? Nothing I am aware of. That is where they are currently uploaded to. Also, shouldn't we provide such win32/win64 binaries at tomcat.apache.org ? Hmm. The downloads page mentions crypto limitations but since httpd distributes binaries that include OpenSSL I don't see why we can't (providing we stick to the terms of the license). Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 44021] Deployer cannot deploy wars with #s
https://issues.apache.org/bugzilla/show_bug.cgi?id=44021 --- Comment #7 from Eric Benzacar <[EMAIL PROTECTED]> 2008-03-12 08:15:24 PST --- (In reply to comment #6) > (In reply to comment #5) > > Regarding the auto-deployment of /foo: > > This is the current behaviour of Tomcat. If I manually put a war into > > /foo/abc.war and create a foo#war.xml context file, Tomcat's auto-deployer > > will > > deploy both foo/abc.war and foo/. As far as I see it, this is expected > > behaviour. > This is currently an invalid configuration. The way I see this working would > be > a foo#abc.war file in the appBase which creates/uses a foo.abc.xml context > file. Really? Why would that be an invalid configuration? I was under the impression that the whole point of the # in the context file names was to allow sub-paths to the war file. Why are you looking to change that to using "." instead? > > Regarding a clash of foo#bar.war and foo#bar#too.war, that is one thing > > that I > > had not considered or taken into account. I can understand that to be > > confusing. The best suggestion I can have for that is to have the > > deployment > > of foo#bar#too.war fail if there is already something that is deployed at > > foo#bar.war, In fact, I am surprised that it does not already do this. > I think this needs to work. Maybe if the files are expanded to directories > named foo#bar and foo#bar#too? This could also fix the autodeployment of foo > problem. The problem with this, however, is that if foo#bar.war is deployed, you have to assume that any path under foo/bar belongs to the foo#bar.war file. For instance, foo#bar.war might have a path as foo/bar/eric/file.jsp. This is the current way that tomcat seems to work. Similarly, it might have a file under foo/bar/too/file.jsp, which would be properly served. Now, if suddenly we allow deployment of foo#bar#too.war, you would assume that to mean any paths under foo/bar/too would belong to the foo#bar#too.war application, and they should all be served under that war deployment. In which case, you'll run into a conflict. I'm not convinced that allowing foo#bar.war to be deployed as well as foo#bar#too.war will not cause significant conflicts and errors for some people who deploy conflicting paths without realizing it. Thanks, Eric -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 44021] Deployer cannot deploy wars with #s
https://issues.apache.org/bugzilla/show_bug.cgi?id=44021 --- Comment #8 from Mark Thomas <[EMAIL PROTECTED]> 2008-03-12 08:29:05 PST --- (In reply to comment #7) > Really? Why would that be an invalid configuration? I was under the > impression that the whole point of the # in the context file names was to > allow > sub-paths to the war file. Why are you looking to change that to using "." > instead? <>/foo/abc.war is invalid The "." was a typo on my part. I meant foo#abc.xml > Now, if suddenly we allow deployment of foo#bar#too.war, you would assume that > to mean any paths under foo/bar/too would belong to the foo#bar#too.war > application, and they should all be served under that war deployment. In > which > case, you'll run into a conflict. No conflict - the spec is quite clear. The request is handled by the context with the longest context path that matches the request. Under the current code you can deploy foo.xml, foo#bar.xml and foo#bar#too.xml and it will work (providing the docBases are outside the appBase). What the current code doesn't handle, and your patch needs to fix, is dropping the equivalent wars into the appBase. The more I think about it, the more I think expansion of a#b#c.war to a dir named a#b#c is the way to fix this. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat native 1.1.13 for win32
Mark Thomas wrote: Henri Gomez wrote: Hi to all, I used to get the win32 tcnative at http://tomcat.heanet.ie/native/ but there is only a 1.1.12 there. Do you know alternate location ? Nothing I am aware of. That is where they are currently uploaded to. Also, shouldn't we provide such win32/win64 binaries at tomcat.apache.org ? Hmm. The downloads page mentions crypto limitations but since httpd distributes binaries that include OpenSSL I don't see why we can't (providing we stick to the terms of the license). Doesn't this go back to the discussion of creating "releases" of tcnative connectors? Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36976] Tomcat VM does not shutdown with remote jmx enabled
https://issues.apache.org/bugzilla/show_bug.cgi?id=36976 --- Comment #15 from Mark <[EMAIL PROTECTED]> 2008-03-12 12:14:15 PST --- Is this issue fixed in Tomcat 6 (I'm using 6.0.13) per the stated resolution above? If so, I'm not seeing the changes. I still see both JAVA_OPTS and CATALINA_OPTS being used in start, run, and stop. Maybe I misunderstood the fix, so if someone could outline the fix more clearly, that would help. Thanks. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Tomcat Wiki] Update of "FAQ/Windows" by markt
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification. The following page has been changed by markt: http://wiki.apache.org/tomcat/FAQ/Windows -- 1. [#Q3 Can I turn off case sensitivity?] 1. [#Q4 Can I use NTLM authentication?] 1. [#Q5 I want to redeploy web applications, how do I prevent resources from getting locked?] + 1. [#Q6 Can I use UNC paths?] + 1. [#Q7 Why can't Tomcat see my mapped drive when running as a service?] == Answers == [[Anchor(Q1)]]'''Why do I get Out of Environment Space?''' @@ -30, +32 @@ Most locking issues will occur with JARs from /WEB-INF/lib, and are useally caused by access through URLs. Tomcat has mechanisms to allow avoiding locking. In Tomcat 5.0, a mechanism exists to prevent locking when accessing resources using the getResource method of the URL classloader (many applications, such as Xerces, do not set the use of caching to false before opening the URL connection, causing locking). If such a call occurs, resources inside the JARs will be extracted to the work directory of the web application. In Tomcat 5.5, this mechanism is disabled by default (as it has a non negligible influence on startup times, and is often useless), and can be enabled using the antiJARLocking attribute of the Context element. There is another lock prevention mechanism in Tomcat 5.5 (antiResourceLocking attribute), which will cause the web application files to be copied to the temp folder and run from this location. This has a larger impact on web application startup times, but obviously prevents locking on all resources of the web application. This also allows more flexible management operations as none of the web application resources will be locked, even while the web application is running (as a special note, when making changes JSPs without reloading the application, the changes has to be duplicated to the path where the web application resources have been copied in the temp folder). + [[Anchor(Q6)]]'''Can I use UNC paths?''' + + Yes. Make sure that the user that Tomcat is running as is able to access the path. This is particularly important when running Tomcat as a service since the local service account will '''not''' have the necessary permissions. + + [[Anchor(Q7)]]'''Why can't Tomcat see my mapped drive when running as a service?''' + + The mapped drives are part of a user's profile and they are not used when running as a service. You should be OK with UNC paths. + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36976] Tomcat VM does not shutdown with remote jmx enabled
https://issues.apache.org/bugzilla/show_bug.cgi?id=36976 --- Comment #16 from Rainer Jung <[EMAIL PROTECTED]> 2008-03-12 13:59:30 PST --- The change was applied to 6.0 shortly after 6.0.14. Unfortunately 6.0.15 wasn't released and 6.0.16 has a serious bug. You can look at the pretty simple fix for the startup script under http://svn.apache.org/viewvc?diff_format=h&view=rev&revision=558523 For TC 5.5 version 5.5.23 should have been the first official release with the fix. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38854] file-browser puts double quotes around war-file selected for upload (5.5. 15)
https://issues.apache.org/bugzilla/show_bug.cgi?id=38854 Mark Thomas <[EMAIL PROTECTED]> changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution||WORKSFORME --- Comment #2 from Mark Thomas <[EMAIL PROTECTED]> 2008-03-12 15:56:48 PST --- Must be a browser issue. It doesn't do it for me with FireFox. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 44021] Deployer cannot deploy wars with #s
https://issues.apache.org/bugzilla/show_bug.cgi?id=44021
--- Comment #9 from Jacob Kjome <[EMAIL PROTECTED]> 2008-03-12 19:40:02 PST ---
I presume that when Tomcat deploys a#b#c.war to a dir named a#b#c, it will also
deploy META-INF/context.xml contained in a#b#c.war to
${CATALINA_BASE}/conf/Engine/host/a#b#c.xml, correct?
Jake
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
