DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=39441>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=39441 Summary: new Deployer is all over the show Product: Tomcat 5 Version: 5.5.11 Platform: Other OS/Version: Windows 2000 Status: NEW Severity: major Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Hi guys, first: -- I think you guys really need to be listening to the feedback in this area, and not just telling people they can go elsewhere. This kind of answer says more about *your* code and whether it is up to scratch, due to its defensive/ aggressive nature, than about anything else. Please have a *proper* look at the Deployer stuff because having tried several approaches, and read quite a lot of docs, and having used TC for some time now; this all seems less than happy to me. Please talk to the project manager if there is still any confusion. -- I've been trying some slightly different Webapp Deployment under Tomcat 5.5 and run into problematic behaviours, with most of the Context specification methods. My goal is simple: to make Manager and my 'eonaJava' webapp available at /tomcat/manager and /tomcat/eonaJava paths within a largely Apache/ PHP system. Attempt 1, problem 1: - specifying Contexts into 'server.xml' with path and docBase - setting path as '/tomcat/eonaJava' etc - files deployed under 'webapps' This approach worked on the surface, but was deploying the app twice behind the scenes. It would appear the code fails to recognize 'docBase' matching with my explicitly-specified contetx path, or some such, don't really care. It worked for a while, but during debugging I realized that 'reloading' the app was reloading the wrong context; my code changes & deploy/ restart script were not resulting in changed behaviour in the executed app. BTW, behaviour of the app I was testing is socket-based in this area. Attempt 2, problem 2: - specifying Contexts into conf/[engine]/[host]/eonaJava.xml with path and docBase - setting path as '/tomcat/eonaJava' etc - files deployed under 'webapps' This worked great. For a while. Later on, it appears to have auto-magically removed the 'web.xml' file from the webapps/eonaJava/WEB-INF folder. Then everything was broken. Look, you guys already have a Working directory separate from where I can place my webapps. My deploy script copies files from development machine onto the host. My analysis is that if I am responsible for copying one set of files, I should be responsible for copying the context file too. I'm not going to give webservers access to my dev machine. I think the conf/ Context file mechanism should *parallel* the file deployment mechanism. As pointed out, you guys have a 'working' directory which I don't copy files into directly. You can create or delete, as required, over there. I expect my uploads, into the well-known and time-honoured 'webapps' directory, to be honoured and not treated as your second working (read 'mangling') directory. PLEASE REFER this to the PROJECT MANAGER because I think there may be some serious conceptual problems here. Now, there had been quite a lot of warnings from Deployer about docBase being inside appBase. Traditionally, webapps have always gone in the webapps/ folder. I tried the conf/ AppName/xml context mechanism since your doc warned that server.xml might not be supported in future. I'm going to state at this point, that 1) the documentation isn't clear or good enough. 2) major conceptual changes in Deployer behaviour and directory ownership are being introduced (my contention is that these aren't logically sound, either) 3) recognition of Apps to avoid double-deployment is broken/ Investigation 3, problem 3, not proceeded with: - looked at the doc for using META-INF/context.xml inside the webapp. - some docs recommend against this for security reasons. Didn't proceed with this due to 1) needing to specify the Manager with an explicit context-path and it being outside of webapps and 2) security recommendation against and need for extra directory. Attempt 4, successful so far: - went back to Contexts in 'server.xml' - set 'autoDeploy' false - set 'deployOnStartup' false This is still not satisfactory, due to the failure to match contexts under the same docBase and incorrect double-deployment. I should be able to copy my webapp files somewhere (let's go wild and say, perhaps, webapps/), copy an explicit context descriptor somewhere and have Tomcat deploy that application: 1) once only, and 2) according to my descriptor I cannot see how the Tomcat 5.5 deployer fulfills these fundamental requirements in a correct manner. As stated, there also appear to be significant conceptual problems with who owns the webapps directory. In the past this has traditionally been owned by the developer; with perhaps 'assistive' help from Tomcat. With the 5.5 Deployer this appears to be treated more like a second working directory. You've already got a directory, please stop tromping on my application deployment area. ---- Tomcat is a great product, and I respect the work that you guys have put into it, but the reason I've put the header and this footer is that I've already read the NG threads etc and I think you guys need to have a real think about this and talk with the product manager. Thanks for your great work and the best server development environment in existence, Regards Thomas -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
