Re: separating deployment of classes/lib/config from web content (jsp's/html)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jason, On 8/25/2010 4:06 PM, Jason Britton wrote: We have a separate department that is more marketing/static content than it is anything, they'll put their own stuff up on the website that for the most part is not under revision control Any reason not to have this under revision control? All our tag libraries, main web workflows (ecommerce), search functionality, page templates etc. are under revision control, we are happy subversion users after escaping from starteam some time ago. Sounds good. Our classes, web.xml, libs are deployed in one war file for our main site, deployment configuration managed by JDeveloper project, I'm not proud of this but we are migrating off of Oracle app server and I plan to take a look at Eclipse for ide and change our project builds to use maven or ant. We have other traditional web apps whose content/config/classes/libs are all traditionally packed up and deployed in a war. So it's just the static content that needs to be modified by the designers? Okay, how do they typically place their files after they're ready? Samba? WebDAV? FTP? Do they drop them straight into production, or is there a staging area? I'm wondering if you can integrate staging with subversion and then always build from subversion. I highly recommend always building from your repository... that way, you always know what versions of files are out there. As for my previous problem separating config/lib/classes from content. I ended up using a symlink on WEB-INF directory on ROOT context, I've got app called foo, ROOT/WEB-INF is symlinked to FOO's WEB-INF directory. I can redeploy FOO and ROOT gets new config/classes/lib via symlink and I don't have to worry about docBase of ROOT getting undeployed. Be careful: some versions of Tomcat will effectively do an 'rm -rf' /across/ symlinks that live within deployment directories. Make sure Tomcat's euid doesn't have rights to delete your stuff. Good luck, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkx2eCEACgkQ9CaO5/Lv0PAX/QCfU9r4lXbHcEnYHyqAYopuXjwb aiMAoKgw6iSoPB/3t4YZEsHfTxvKXqdi =VfWA -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: separating deployment of classes/lib/config from web content (jsp's/html)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jason, On 8/24/2010 2:38 PM, Jason Britton wrote: The short answer is: you can't separate the components of a webapp out into separate locations. Thanks for the response P. Understood and agreed as to the function and purpose of .war file. The reasoning for the separation is that in our current environment we have users from 3 or so other departments accustomed to being able to drag html and jsp files up to our web server (good bad or otherwise). With a change to tomcat as our app server, I could provide that same sort of access where jsp and html docs are just moved into the docBase directory at will by multiple individuals, but I would never be able to undeploy that directory without fear of losing all the jsp and html files they may have tossed in there. This sounds completely insane. You have developers changing things in a whim and no record of the changes they're making? Consider using a revision-tracking system for this sort of thing. There are at least two quite popular free ones: CVS and Subversion. Once you have a revision-tracking system, you can pull the current version from the repository and nobody has to do any copying of files into a shared location. This is generally known as a nightly build. Each dev works separately, and the nightly build has everything that's been committed to the revision-tracking repository. I would have to resort to hand copying in class file/config and lib changes into the WEB-INF so as not to risk losing any content files on a redeployment. This also sounds completely insane. You need to have a sane deployment process. Generally, when developing a web application, you can feel free to have all your .java files, .jsps, static content, etc. scattered all over the place. Once it's time to deploy, though, it's time to sew everything up into a WAR (whether it's actually a .war file or just on the disk with the same directory/file structure). I highly recommend using Apache ant for this sort of thing: there's a war command that you can use where you can specify all the places where source files should come from. Boom: instant .war file. We rigged our current application server (Oracle OAS 10.1.3.4) to allow this separation of content from configuration/classes/lib but that is neither here nor there. Exactly. That is completely independent of the servlet specification, and therefore vendor-specific. I'd be happy to share some ant scripts and suggestions for development directory structure if you'd like. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkx1ai0ACgkQ9CaO5/Lv0PDpgACgxEoUknZR9Tp7MqV+p+xcmJ5V fLkAn2iscxe2UzZGQP8IFBfK8gzped9J =oE8j -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: separating deployment of classes/lib/config from web content (jsp's/html)
:) I got a good laugh out of your response Christopher and I appreciate you taking the time to guide a possibly astray developer but let me hopefully put your mind somewhat at ease in regards to our development practices/environment. Not claiming we have anything resembling a perfect process either. We have a separate department that is more marketing/static content than it is anything, they'll put their own stuff up on the website that for the most part is not under revision control, but backed up and they each have their own local copies, heavy dreamweaver users and we'll give them tag libraries to use for some dynamic content here and there. All our tag libraries, main web workflows (ecommerce), search functionality, page templates etc. are under revision control, we are happy subversion users after escaping from starteam some time ago. Our classes, web.xml, libs are deployed in one war file for our main site, deployment configuration *managed by JDeveloper project, I'm not proud of this but we are migrating off of Oracle app server and I plan to take a look at Eclipse for ide and change our project builds to use maven or ant. We have other traditional web apps whose content/config/classes/libs are all traditionally packed up and deployed in a war. As for my previous problem separating config/lib/classes from content. I ended up using a symlink on WEB-INF directory on ROOT context, I've got app called foo, ROOT/WEB-INF is symlinked to FOO's WEB-INF directory. I can redeploy FOO and ROOT gets new config/classes/lib via symlink and I don't have to worry about docBase of ROOT getting undeployed. Tried aliases context attribute in 7.0, just couldn't get it to provide same separation symlink did, or I just wasn't using it correctly. Jason I would have to resort to hand copying in class file/config and lib changes into the WEB-INF so as not to risk losing any content files on a redeployment. This also sounds completely insane. You need to have a sane deployment process. Generally, when developing a web application, you can feel free to have all your .java files, .jsps, static content, etc. scattered all over the place. Once it's time to deploy, though, it's time to sew everything up into a WAR (whether it's actually a .war file or just on the disk with the same directory/file structure). I highly recommend using Apache ant for this sort of thing: there's a war command that you can use where you can specify all the places where source files should come from. Boom: instant .war file. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: separating deployment of classes/lib/config from web content (jsp's/html)
On 24/08/2010 18:14, Jason Britton wrote: I'm trying to configure a tomcat context that I could deploy the classes, libs, web.xml using a .war file but the actual jsp's, html, web content would not be packed up in the .war file and would live in a directory outside of the exploded war directory. I need to be able to redeploy my classes/libs/web.xml without removing/redeploying the web content (html/jsp's). I would rather not have to hand copy class file/lib/configuration changes into my context WEB-INF directory but right now that seems as my only option if I do not want to rely on having my web content bundled into my .war. I have tried modifying my context's docBase to point outside of the host's appBase but that did not have desired effect as it changed the location of where my WEB-INF directory and web-content needed to go, when I really want to separate the location of the configuration,libs,classes of my context from the web content. I'm running tomcat 6.0.29 on 64 bit RHEL 5. Apache 2.2.16 sits infront of tomcat. Any advice or kicks in the right direction would be greatly appreciated. The short answer is: you can't separate the components of a webapp out into separate locations. Longer answer: JSPs get compiled into Servlets, which then deliver the response for requests which match the path of the JSP. The Servlets are classes. If you precompile the application, they'll need to be in WEB-INF/classes, if you don't they'll live in a tomcat/work subdirectory. The container delegates a request to a web application with a matching path prefix. Unmatched requests go to the default application, 'ROOT'. Thusly, each webapp must know how to deliver resources for the requests it receives. Webapps are supposed to be self-contained. You can, of course, deploy separate apps for different paths, perhaps placing all images in separate app called (surprisingly) '/images'. Your intended strategy is counter to how to a Servlet container is supposed to work, so if you're going to have a constant struggle trying to make it work any other way. Cut your losses now try to work with the container. p 0x62590808.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: separating deployment of classes/lib/config from web content (jsp's/html)
On 24/08/2010 18:14, Jason Britton wrote: I'm trying to configure a tomcat context that I could deploy the classes, libs, web.xml using a .war file but the actual jsp's, html, web content would not be packed up in the .war file and would live in a directory outside of the exploded war directory. I need to be able to redeploy my classes/libs/web.xml without removing/redeploying the web content (html/jsp's). I would rather not have to hand copy class file/lib/configuration changes into my context WEB-INF directory but right now that seems as my only option if I do not want to rely on having my web content bundled into my .war. I have tried modifying my context's docBase to point outside of the host's appBase but that did not have desired effect as it changed the location of where my WEB-INF directory and web-content needed to go, when I really want to separate the location of the configuration,libs,classes of my context from the web content. I'm running tomcat 6.0.29 on 64 bit RHEL 5. Apache 2.2.16 sits infront of tomcat. Any advice or kicks in the right direction would be greatly appreciated. In Tomcat 7 you could use an alias. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: separating deployment of classes/lib/config from web content (jsp's/html)
The short answer is: you can't separate the components of a webapp out into separate locations. Thanks for the response P. Understood and agreed as to the function and purpose of .war file. The reasoning for the separation is that in our current environment we have users from 3 or so other departments accustomed to being able to drag html and jsp files up to our web server (good bad or otherwise). With a change to tomcat as our app server, I could provide that same sort of access where jsp and html docs are just moved into the docBase directory at will by multiple individuals, but I would never be able to undeploy that directory without fear of losing all the jsp and html files they may have tossed in there. I would have to resort to hand copying in class file/config and lib changes into the WEB-INF so as not to risk losing any content files on a redeployment. We rigged our current application server (Oracle OAS 10.1.3.4) to allow this separation of content from configuration/classes/lib but that is neither here nor there. Thanks for your input. Jason
Re: separating deployment of classes/lib/config from web content (jsp's/html)
In Tomcat 7 you could use an alias. Mark Definitely interested. Is there a time frame on when 7 will have a non-beta release? Thanks for the heads up. Jason
Re: separating deployment of classes/lib/config from web content (jsp's/html)
On 24/08/2010 20:00, Jason Britton wrote: In Tomcat 7 you could use an alias. Mark Definitely interested. Is there a time frame on when 7 will have a non-beta release? Thanks for the heads up. The more people that test it and report problems, the sooner it will be out of beta. Hint, hint :) Some *very* rough download stats from the middle of last month suggest that the split for downloads was: 5.5.x - 60% 6.0.x - 30% 7.0.x - 10% Given that those figures would are for 7.0.0 and the bug fixes that went into 7.0.2, that is actually quite encouraging. There is no fixed time-scale but the signs are encouraging for it being relatively soon. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: separating deployment of classes/lib/config from web content (jsp's/html)
I'll put tomcat 7 on our dev environment and have a go at it. I'm excited about the alias functionality, thanks so much for pointing it out Mark, from the 7.0 docs: aliases attribute of the context element: This attribute provides a list of external locations from which to load resources for this context. The list of aliases should be of the form /aliasPath1=docBase1,/aliasPath2=docBase2 where aliasPathN must include a leading '/' and docBaseN must be an absolute path to either a .war file or a directory. A resource will be searched for in the first docBaseN for which aliasPathN is a leading path segment of the resource. If there is no such alias, then the resource will be searched in the usual way. Using '/' as an aliasPath is not allowed. Consider using docBase instead. **These external locations will not be emptied if the context is un-deployed.** On Tue, Aug 24, 2010 at 1:19 PM, Mark Thomas ma...@apache.org wrote: On 24/08/2010 20:00, Jason Britton wrote: In Tomcat 7 you could use an alias. Mark Definitely interested. Is there a time frame on when 7 will have a non-beta release? Thanks for the heads up. The more people that test it and report problems, the sooner it will be out of beta. Hint, hint :) Some *very* rough download stats from the middle of last month suggest that the split for downloads was: 5.5.x - 60% 6.0.x - 30% 7.0.x - 10% Given that those figures would are for 7.0.0 and the bug fixes that went into 7.0.2, that is actually quite encouraging. There is no fixed time-scale but the signs are encouraging for it being relatively soon. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
