Re: Tomcat6 - Context - aliases
Hello and thank you for your answers. Christopher Schultz-2 wrote why don't you just write a simple file-fetching servlet? They are dead-simple to write This looks very interesting. André Warnier wrote you probably do /not/ want bots to be able to point directly to the documents uploaded by users Yes indeed. Thanks for pointing this out. I was just speaking in general. André Warnier wrote Presumably, it is via a POST, to a servlet you have created. That servlet knows where to store the files that are uploaded, via some parameter which it reads somewhere. Yes. André Warnier wrote Christoper's (and my own) suggestion is to create a similar servlet that serves to download the files, and which would use the same parameter to know where to download them from. Again, it looks very interesting. Maybe it's what I've been looking for from the beginning. To @André Warnier: Thank you for the two references Automatic Application Deployment and Single Sign On. If any of you two can post the code of the file-fetching servlet, it would be great. Thanks and best regards. -- View this message in context: http://tomcat.10.n6.nabble.com/Tomcat6-Context-aliases-tp4678430p4756364.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat6 - Context - aliases
Léa Massiot wrote: ... If any of you two can post the code of the file-fetching servlet, it would be great. http://lmgtfy.com/?q=java+file+download+servlet :-) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat6 - Context - aliases
@André Warnier: Thank you. -- View this message in context: http://tomcat.10.n6.nabble.com/Tomcat6-Context-aliases-tp4678430p4762217.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat6 - Context - aliases
@André Warnier: Thank you for your detailed answer. As of your objections: 1) We don't agree with each other. I *DO* care about what URLs look like: a) in general, b) for some reasons related to the user's speaking language, c) for search engines, d) ... The URL of a link can be seen in many circumstances and is used in various ways both by humans and bots. 2) I want the resources (files and other things like databases) to be stored outside the servlets container and more precisely on another partition, especially if data get erased when the context which contains them is undeployed! André Warnier wrote Do you know that when a Context is undeployed by Tomcat, all its files are deleted ? This is certainly not what I want. I would expect Tomcat to provide a mechanism for it not to happen. (See my questions at the end of this post). André Warnier wrote with your method consisting of creating a new context on-the-fly Am I? I put an_alias_1.xml in /etc/tomcat6/Catalina/localhost/ once and only once (never touch it again afterwards). André Warnier wrote But this is a logical consequence of building a context from scratch, outside of you /w context, and having Tomcat serve it, without any kind of security protecting that location. It's not exactly my full responsibility. I'm looking for a solution, remember. I'm not especially keen on that solution. André Warnier wrote An undeploy of a Context does not generally happen by itself What is the probability of such an event occurring? If it's like a rm -R on the directory, I'll forget about it. So, given your thoughtful observations, here are my questions: 1) Can you tell me how to test a context undeployment in command line (not via Tomcat Manager please)? 2) Is there any way, I can prevent a context to be undeployed ever (like setting a specific option in a configuration file, in an_alias_1.xml for example)? 3) Is there any good example illustrating how to do a cross context authentication you can point me to? Thank you for helping and best regards. -- View this message in context: http://tomcat.10.n6.nabble.com/Tomcat6-Context-aliases-tp4678430p4715558.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat6 - Context - aliases
I edited my previous post at 1:14 PM 2012/04/09. Thanks. -- View this message in context: http://tomcat.10.n6.nabble.com/Tomcat6-Context-aliases-tp4678430p4715649.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat6 - Context - aliases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Léa, On 4/9/12 6:12 AM, Léa Massiot wrote: 1) We don't agree with each other. I *DO* care about what URLs look like: a) in general, b) for some reasons related to the user's speaking language, c) for search engines, d) ... The URL of a link can be seen in many circumstances and is used in various ways both by humans and bots. 2) I want the resources (files and other things like databases) to be stored outside the servlets container and more precisely on another partition, especially if data get erased when the context which contains them is undeployed! If you want to control the URL and the location of your files, why don't you just write a simple file-fetching servlet? They are dead-simple to write: then you have complete control over both URL and location of files, and you don't have to worry about your uploaded files being deleted because you can store them completely independently of your webapp's deployment directory(ies). Also, it will work across all versions of all servlet containers, and you don't have to rely on some vendor-specific configuration. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+C/+wACgkQ9CaO5/Lv0PCkbgCfX0J8o/F6Dfx30QWeNwWR++jO KC0AoLL6v3w04tmsag+ahHcib6b83Lc4 =bWUL -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat6 - Context - aliases
Léa Massiot wrote: @André Warnier: Thank you for your detailed answer. As of your objections: 1) We don't agree with each other. I *DO* care about what URLs look like: a) in general, b) for some reasons related to the user's speaking language, c) for search engines, d) ... One cannot argue with convictions. The URL of a link can be seen in many circumstances and is used in various ways both by humans and bots. I would point out nevertheless that, in the case of an application such as the one you describe, you probably do /not/ want bots to be able to point directly to the documents uploaded by users. In particular since you seem to want the documents to be acessed via a link which contains the original name of the file uploaded by the user. One may easily consider this as at least a lack of privacy. 2) I want the resources (files and other things like databases) to be stored outside the servlets container and more precisely on another partition, especially if data get erased when the context which contains them is undeployed! That is a good idea in general. One of the reasons is, that there is no guarantee that the location where the application is stored, is even writeable (apart from initially putting the application there of course); another being that you may not have room enough there for the uploaded files. André Warnier wrote Do you know that when a Context is undeployed by Tomcat, all its files are deleted ? This is certainly not what I want. I would expect Tomcat to provide a mechanism for it not to happen. (See my questions at the end of this post). See http://tomcat.apache.org/tomcat-7.0-doc/config/host.html#Automatic_Application_Deployment (but remember, this is Tomcat-centric; other servlet containers may have other rules, as long as they match the Servlet Specification). André Warnier wrote with your method consisting of creating a new context on-the-fly Am I? I put an_alias_1.xml in /etc/tomcat6/Catalina/localhost/ once and only once (never touch it again afterwards). That was not totally clear. What is also not clear, is how and when you do that. Any way, when you create such a Context file, in effect you are creating a new web application. To have the container protect this application in any way (iow controlling access to the user fils stored there), you would need to also have, in the application's docBase, a WEB-INF subdirectory containing a web.xml file which describes the security constraints of that application. André Warnier wrote But this is a logical consequence of building a context from scratch, outside of you /w context, and having Tomcat serve it, without any kind of security protecting that location. See above. That is what I meant. It's not exactly my full responsibility. I'm looking for a solution, remember. I'm not especially keen on that solution. I thought that you were the one developing that application ? See Christopher's answer. André Warnier wrote An undeploy of a Context does not generally happen by itself What is the probability of such an event occurring? If it's like a rm -R on the directory, I'll forget about it. So, given your thoughtful observations, here are my questions: 1) Can you tell me how to test a context undeployment in command line (not via Tomcat Manager please)? Yes, using the Tomcat Manager is the easiest way. One can also invoke the function of the Tomcat Manager, via command-line tools (wget, curl, etc..). And as indicated in the page mentioned above, it can also happen when modifying your Context file, modifying a directory etc.. My point is : accidents happen. But one doesn't have to make it easy for them to happen. You will have a directory where users upload their own files, perhaps many of them, and perhaps files that they would very much like not to loose. Putting these files at risk to be deleted, due to a misconfiguration or by an operator action which is not necessarily as evident as rm -R does not seem like a good idea. Nobody can decide for you what your real priorities are, between having nice URL's, and creating a system that is safe, controlled, and easy to manage. You have not explained how users upload their files. Presumably, it is via a POST, to a servlet you have created. That servlet knows where to store the files that are uploaded, via some parameter which it reads somewhere. Christoper's (and my own) suggestion is to create a similar servlet that serves to download the files, and which would use the same parameter to know where to download them from. (And, this parameter could be stored in either the web.xml of the application, or in a properties file, as explained by the article to which I pointed you earlier.) Tomcat itself would not know where the files are stored, so it could not undeploy them. Access control to the download (just as for the upload) would be done by the container protection of this application. And the
Re: Tomcat6 - Context - aliases
André Warnier wrote: Léa, Léa Massiot wrote: ... Actually I realized that even with the previous mechanism I used (using the aliases attribute of the Context element of the w/WEB-INF/context.xml file), I could directly retrieve a resource by typing its exact URL in a browser and without having to identify in any way prior to the retrieval... I think that what we are missing here, is what exactly you are trying to achieve. And personally (no offense intended) I have the feeling that what you are trying to do is fairly simple and classic, but that the way you are going about it makes it complicated and probably unsafe. Let me try to summarise. 1) upload of documents/files : - Users are able to access the webserver and to upload files/documents to it. You have not told us how that works, if there are several users or just one, if all users are uploading to the same location, if this capability is restricted (login) and so on.. - when a user uploads a file/document, this file/document gets written somewhere on the webserver. Where ? are there several upload locations ? and how is it decided what gets written where ? if 2 users upload a file/document with the same filename, does the second one overwrite the first ? 2) download of files/documents : - Users can (should) login to the webserver, and after that they are able to download files/documents. Do all users have access to all uploaded documents ? should it be so that each user (or group of users) only gets access to his own documents ? When a gicen user logs in, does he get a list of all the documents ? or a list of only his documents ? Does your application (/w ?) build a list of the files, as a html page with links, on which the user can just click to download a file/document ? and if so, what does bother you about the exact look of that link ? the user does not see the URL, he sees only what you choose to display, right ? iow in the link : a href=/an_alias_1/file_1.txtfile_1.txt/a the user only see the file_1.txt part, right ? And if the link was : a href=/w/something-else-altogether/12345file_1.txt/a the user would still only see file_1.txt, right ? So, if I summarise, the only part which is somewhat iffy, is that in your mechanism via Context, you are providing a URL which allows any user to just use that URL to retrieve a document (his or someone else's), without even having to login. But this is a logical consequence of building a context from scratch, outside of you /w context, and having Tomcat serve it, without any kind of security protecting that location. In other words, why not store the documents in a directory below your /w context (which would be protected by the web.xml of the /w context, and provide the user with a link like : a href=/w/files/userx/file_1.txtfile_1.txt/a I guess that I don't see why you would have to go through the bother of creating another Context on-the-fly (and then one without any access-control whatsovever). Of course, you /could/ store the files somewhere else, but then if that is a separate Tomcat context, you would need a separate authentication - or a cross-context authentication. And if that location is not a Tomcat context, then you would need your webapp to also retrieve and deliver the files to the clients (which is quite simple, and is the way I would have looked at it in the first place; and this would allow you to control who can access what). By the way, have you looked at the DAV application available for Tomcat ? See : http://wiki.apache.org/tomcat/Tomcat/WebDav Addendum, triggered by a response from Konstantin to another recent post on this list : Do you know that when a Context is undeployed by Tomcat, all its files are deleted ? An undeploy of a Context does not generally happen by itself, but with your method consisting of creating a new context on-the-fly, if ever an undeploy did happen, all the uploaded files in that Context would be deleted. Probably not what you want to risk. There are some things like that which are difficult to explain to users of your application.. ;-) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat6 - Context - aliases
Christopher Schultz-2 wrote Do you really need crossContext=true here? I guess not since - as I just tested - removing it doesn't change anything... Thank you. So I removed the crossContext attribute (and the path attribute) and the new contents of an_alias_1.xml are: -- Context docBase=/home/d1 / -- Christopher Schultz-2 wrote This is the first time you mentioned webapp w. Is that the main webapp? Yes. Christopher Schultz-2 wrote Why is that a problem? Actually I realized that even with the previous mechanism I used (using the aliases attribute of the Context element of the w/WEB-INF/context.xml file), I could directly retrieve a resource by typing its exact URL in a browser and without having to identify in any way prior to the retrieval... Christopher Schultz-2 wrote If you want /w/an_alias_1, then re-name your context deployment descriptor: $ mv an_alias_1.xml w\#an_alias_1.xml ... Actually, this is what I did but I didn't want to complicate my answer. Thank you. Christopher Schultz-2 wrote Maybe you just want to make it look like the resource belongs to the webapp. To the Webapp w, yes. Thank you for your comments and your interest. Best regards. -- View this message in context: http://tomcat.10.n6.nabble.com/Tomcat6-Context-aliases-tp4678430p4692232.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat6 - Context - aliases
Léa, Léa Massiot wrote: ... Actually I realized that even with the previous mechanism I used (using the aliases attribute of the Context element of the w/WEB-INF/context.xml file), I could directly retrieve a resource by typing its exact URL in a browser and without having to identify in any way prior to the retrieval... I think that what we are missing here, is what exactly you are trying to achieve. And personally (no offense intended) I have the feeling that what you are trying to do is fairly simple and classic, but that the way you are going about it makes it complicated and probably unsafe. Let me try to summarise. 1) upload of documents/files : - Users are able to access the webserver and to upload files/documents to it. You have not told us how that works, if there are several users or just one, if all users are uploading to the same location, if this capability is restricted (login) and so on.. - when a user uploads a file/document, this file/document gets written somewhere on the webserver. Where ? are there several upload locations ? and how is it decided what gets written where ? if 2 users upload a file/document with the same filename, does the second one overwrite the first ? 2) download of files/documents : - Users can (should) login to the webserver, and after that they are able to download files/documents. Do all users have access to all uploaded documents ? should it be so that each user (or group of users) only gets access to his own documents ? When a gicen user logs in, does he get a list of all the documents ? or a list of only his documents ? Does your application (/w ?) build a list of the files, as a html page with links, on which the user can just click to download a file/document ? and if so, what does bother you about the exact look of that link ? the user does not see the URL, he sees only what you choose to display, right ? iow in the link : a href=/an_alias_1/file_1.txtfile_1.txt/a the user only see the file_1.txt part, right ? And if the link was : a href=/w/something-else-altogether/12345file_1.txt/a the user would still only see file_1.txt, right ? So, if I summarise, the only part which is somewhat iffy, is that in your mechanism via Context, you are providing a URL which allows any user to just use that URL to retrieve a document (his or someone else's), without even having to login. But this is a logical consequence of building a context from scratch, outside of you /w context, and having Tomcat serve it, without any kind of security protecting that location. In other words, why not store the documents in a directory below your /w context (which would be protected by the web.xml of the /w context, and provide the user with a link like : a href=/w/files/userx/file_1.txtfile_1.txt/a I guess that I don't see why you would have to go through the bother of creating another Context on-the-fly (and then one without any access-control whatsovever). Of course, you /could/ store the files somewhere else, but then if that is a separate Tomcat context, you would need a separate authentication - or a cross-context authentication. And if that location is not a Tomcat context, then you would need your webapp to also retrieve and deliver the files to the clients (which is quite simple, and is the way I would have looked at it in the first place; and this would allow you to control who can access what). By the way, have you looked at the DAV application available for Tomcat ? See : http://wiki.apache.org/tomcat/Tomcat/WebDav - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat6 - Context - aliases
Konstantin Kolinko wrote You should remove the path attribute when Context is defined in an XML file. The name of the xml file itself specifies the path, not the attribute. Indeed. Thank you. Best regards. -- View this message in context: http://tomcat.10.n6.nabble.com/Tomcat6-Context-aliases-tp4678430p4689256.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat6 - Context - aliases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Léa, On 4/4/12 2:28 PM, Léa Massiot wrote: Context path=/an_alias_1 docBase=/home/d1 crossContext=true / Do you really need crossContext=true here? - This Configuration Descriptor is automatically deployed once saved. - I suppressed the Webapp w's WEB-INF\context.xml I had created. - I redeployed the Webapp w. This is the first time you mentioned webapp w. Is that the main webapp? = Now, when a user clicks on any link a href=/an_alias_1/file_ i.txt file_ i.txt /a it is successfully retrieved. Good. = What is still problematic to me, is that, when the user clicks on a link, the context or Webapp changes (from w to an_alias_1). Why is that a problem? The resources which are in /home/d1 are available directly by typing the following URL in a browser: http://hostname:8080/an_alias_1/file_ i.txt and not compulsorily through the Webapp w. Isn't that what you wanted? Or, do you want everything to be exposed through /w/an_alias_1? If you want /w/an_alias_1, then re-name your context deployment descriptor: $ mv an_alias_1.xml w\#an_alias_1.xml Honestly, though, I'm not sure it makes any difference: a URL is a URL. Maybe you just want to make it look like the resource belongs to the webapp. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk99pncACgkQ9CaO5/Lv0PB1fgCeJ+kv6Y/UH9NlG4gIJYK36juZ gE8An3r6kqhEUXY8pCwvb0A9v4YEvItG =trQU -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat6 - Context - aliases
Hello André, André Warnier wrote - you need to tell your webapp where the uploaded files should be stored/retrieved - you cannot do it via an alias under Tomcat v7 Exactly. André Warnier wrote - so instead of an alias, do it via a property in a properties file, which your webapp would read. This is (almost) a pure java solution, which would work under any servlet container of any version. I wish I knew how to do that and yes, I'm interested in an (almost) pure Java solution. May I precise what I did and what already works with Tomcat7: 1) When a user uploads a file to the server running Tomcat, I store the file, for example, in a directory: /home/d1/ 2) In a JSP, this user can view the list of the n files he uploaded: -- a href=/an_alias_1/file_1.txt file_1.txt /a ... a href=/an_alias_1/file_n.txt file_n.txt /a -- 3) In Tomcat7, I used the aliases properties of the Context element in META-INF/context.xml to (magically to me :/), let Tomcat map these addresses: -- /an_alias_1/file_1.txt ... /an_alias_1/file_n.txt -- to their real addresses on the filesystem: -- /home/d1/file_1.txt ... /home/d1/file_n.txt -- so that the user could click on one of these links and retrieve/view the corresponding resource. Of course, I read carefully what you wrote, it looks like I'm really missing something important because I have absolutely no idea how to implement the same mechanism using a properties file as you suggest... Would you be so very kind to to explain a bit more? Thank you and best regards. -- View this message in context: http://tomcat.10.n6.nabble.com/Tomcat6-Context-aliases-tp4678430p4686704.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat6 - Context - aliases
Ok. So, I found a solution, if I can call that a solution. - I created a file an_alias_1.xml in /etc/tomcat6/Catalina/localhost/ (the OS being Debian Squeeze). - Here are the contents of this an_alias_1.xml file: Context path=/an_alias_1 docBase=/home/d1 crossContext=true / - This Configuration Descriptor is automatically deployed once saved. - I suppressed the Webapp w's WEB-INF\context.xml I had created. - I redeployed the Webapp w. = Now, when a user clicks on any link a href=/an_alias_1/file_ i.txt file_ i.txt /a it is successfully retrieved. = What is still problematic to me, is that, when the user clicks on a link, the context or Webapp changes (from w to an_alias_1). The resources which are in /home/d1 are available directly by typing the following URL in a browser: http://hostname:8080/an_alias_1/file_ i.txt and not compulsorily through the Webapp w. Best regards. Ref. - a useful thread on stackoverflow: http://stackoverflow.com/questions/4575562/how-to-set-up-a-different-context-to-point-to-an-external-directory-outside-weba -- View this message in context: http://tomcat.10.n6.nabble.com/Tomcat6-Context-aliases-tp4678430p4687332.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat6 - Context - aliases
From: Léa Massiot [mailto:lmhe...@orange.fr] Subject: Re: Tomcat6 - Context - aliases Ok. So, I found a solution, if I can call that a solution. How about a much easier solution: install Tomcat 7. Easier to configure, faster, and more secure. Stop making your life difficult. - 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
Re: Tomcat6 - Context - aliases
2012/4/4 Léa Massiot lmhe...@orange.fr: Ok. So, I found a solution, if I can call that a solution. - I created a file an_alias_1.xml in /etc/tomcat6/Catalina/localhost/ (the OS being Debian Squeeze). - Here are the contents of this an_alias_1.xml file: Context path=/an_alias_1 docBase=/home/d1 crossContext=true / You should remove the path attribute when Context is defined in an XML file. The name of the xml file itself specifies the path, not the attribute. See Context chapter in configuration reference for details. - This Configuration Descriptor is automatically deployed once saved. - I suppressed the Webapp w's WEB-INF\context.xml I had created. - I redeployed the Webapp w. = Now, when a user clicks on any link a href=/an_alias_1/file_ i.txt file_ i.txt /a it is successfully retrieved. = What is still problematic to me, is that, when the user clicks on a link, the context or Webapp changes (from w to an_alias_1). The resources which are in /home/d1 are available directly by typing the following URL in a browser: http://hostname:8080/an_alias_1/file_ i.txt and not compulsorily through the Webapp w. Best regards. Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat6 - Context - aliases
Thank you all three for your last answers. André Warnier wrote this might help, in a container- and version-independent way : http://jaitechwriteups.blogspot.de/2007/01/how-to-read-properties-file-in-web.html I'm sorry, no offence... but I don't see how... :/ Pid * wrote Please define 'inside'. In this Web page: http://tomcat.apache.org/tomcat-7.0-doc/config/context.html (look for the first occurrence of the word aliases in this document), there is a description of what the aliases attribute is used for. Excerpt: This attribute provides a list of external locations from which to load resources for this context. When I use the word inside (maybe improperly) I intend to mean the opposite of what is called an external location in the documentation mentionned above. My requirements more clearly now I hope: I just want to know, what is the more basic mechanism which was used in Tomcat6 to do what the aliases attribute of the Context element of the context.xml file permits now to do in Tomcat7. Note 1: I had'nt realized this aliases attribute was container-version-dependent. I wouldn't have used it otherwise. Note 2: Maybe this mechanism has to be implemented directly in the Webapp's source code instead. Note 3: The interesting idea behind this external location notion is to be able to isolate ressources from the Webapp itself and yet being able to refer to them from inside the Webapp. Thank you for helping and best regards. -- View this message in context: http://tomcat.10.n6.nabble.com/Tomcat6-Context-aliases-tp4678430p4681421.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat6 - Context - aliases
Léa Massiot wrote: Thank you all three for your last answers. André Warnier wrote this might help, in a container- and version-independent way : http://jaitechwriteups.blogspot.de/2007/01/how-to-read-properties-file-in-web.html I'm sorry, no offence... but I don't see how... :/ No offence taken. What I meant (if I understood your basic issue properly) was : - you need to tell your webapp where the uploaded files should be stored/retrieved - you cannot do it via an alias under Tomcat v7 - so instead of an alias, do it via a property in a properties file, which your webapp would read This is (almost) a pure java solution, which would work under any servlet container of any version. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat6 - Context - aliases
Hi, Can I ask you some questions? 1. What version of Tomcat7 did you test? 2. Where do you place context.xml in Tomcat6? I don't know you are aware that context.xml placed in yourwebapp/META-INF/context.xml is automatically copied to TOMCAT_HOME/conf/Catalina/(hostname(usually localhost)/yourapp.xml. Once copied, Tomcat6 refers the one in TOMCAT_HOME/conf. Tomcat7.0.26 no longer copies context.xml. Regards, Teppei On 12/04/02 18:59, Léa Massiot lmhe...@orange.fr wrote: Hello, I've been struggling lately with the aliases attribute of the Context element of the context.xml file. I tested a Webapp with Tomcat7 and it appears to work properly. As a Debian user, Tomcat7 is not yet packaged in the current stable release Squeeze so I installed Tomcat6 instead. Result: the Webapp no longer works properly (as far as the aliases attribute is concerned). When I have a look at the Tomcat6 documentation (http://tomcat.apache.org/tomcat-6.0-doc/config/context.html), it looks like the Context element aliases attribute is not available. 1) Can you confirm it is not? 2) How can I workaround this problem? Thanks for helping. -- View this message in context: http://tomcat.10.n6.nabble.com/Tomcat6-Context-aliases-tp4678428p4678428.h tml Sent from the Tomcat - User mailing list archive at Nabble.com. - 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: Tomcat6 - Context - aliases
2012/4/2 Léa Massiot lmhe...@orange.fr: I've been struggling lately with the aliases attribute of the Context element of the context.xml file. I tested a Webapp with Tomcat7 and it appears to work properly. As a Debian user, Tomcat7 is not yet packaged in the current stable release Squeeze so I installed Tomcat6 instead. Result: the Webapp no longer works properly (as far as the aliases attribute is concerned). When I have a look at the Tomcat6 documentation (http://tomcat.apache.org/tomcat-6.0-doc/config/context.html), it looks like the Context element aliases attribute is not available. 1) Can you confirm it is not? aliases are a feature added to Tomcat 7. They are not available in earlier versions. The feature is too intrusive to ever consider its backporting. 2) How can I workaround this problem? Install Tomcat 7. Read RUNNING.txt for a start. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat6 - Context - aliases
Hello, Thank you for your answers. Teppei Yamada wrote 1. What version of Tomcat7 did you test? On a Windows XP machine: Tomcat 7.0.20 On a Debian Squeeze machine: Tomcat 7.0.22 Teppei Yamada wrote 2. Where do you place context.xml in Tomcat6? I don't know you are aware that context.xml placed in yourwebapp/META-INF/context.xml is automatically copied to TOMCAT_HOME/conf/Catalina/(hostname(usually localhost)/yourapp.xml. Once copied, Tomcat6 refers the one in TOMCAT_HOME/conf. Tomcat7.0.26 no longer copies context.xml. I placed context.xml in yourwebapp/META-INF/. I am aware of what you mentionned above. I remember reading that Tomcat6 copies context.xml to TOMCAT_HOME/conf/Catalina/(hostname(usually localhost)/yourapp.xml only the first time the Webapp is deployed. Konstantin Kolinko wrote aliases are a feature added to Tomcat 7. They are not available in earlier versions. The feature is too intrusive to ever consider its backporting. I see. Konstantin Kolinko wrote Install Tomcat 7. Read RUNNING.txt for a start. I prefer not to. As I wrote, Tomcat7 is not packaged yet in Debian stable Squeeze. For security reasons, I want to use only stable, packaged and up-to-date OS and software versions. I there any other workaround... I mean... I guess even before Tomcat7, people needed to declare such aliases. Thank you for your help and best regards. -- View this message in context: http://tomcat.10.n6.nabble.com/Tomcat6-Context-aliases-tp4678430p4678513.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat6 - Context - aliases
- Original Message - Hello, Thank you for your answers. Teppei Yamada wrote 1. What version of Tomcat7 did you test? On a Windows XP machine: Tomcat 7.0.20 On a Debian Squeeze machine: Tomcat 7.0.22 Teppei Yamada wrote 2. Where do you place context.xml in Tomcat6? I don't know you are aware that context.xml placed in yourwebapp/META-INF/context.xml is automatically copied to TOMCAT_HOME/conf/Catalina/(hostname(usually localhost)/yourapp.xml. Once copied, Tomcat6 refers the one in TOMCAT_HOME/conf. Tomcat7.0.26 no longer copies context.xml. I placed context.xml in yourwebapp/META-INF/. I am aware of what you mentionned above. I remember reading that Tomcat6 copies context.xml to TOMCAT_HOME/conf/Catalina/(hostname(usually localhost)/yourapp.xml only the first time the Webapp is deployed. Konstantin Kolinko wrote aliases are a feature added to Tomcat 7. They are not available in earlier versions. The feature is too intrusive to ever consider its backporting. I see. Konstantin Kolinko wrote Install Tomcat 7. Read RUNNING.txt for a start. +1 I prefer not to. As I wrote, Tomcat7 is not packaged yet in Debian stable Squeeze. I'm not a fan of using Tomcat from a package repo. For security reasons, I want to use only stable, packaged and up-to-date OS and software versions. I think your logic is backwards here. In my experience, the package manager repos almost always lag behind (sometimes WAY behind) on Tomcat versions. It might not seem to be a problem to hang a couple versions back, but you could miss a critical security patch this way. I would suggest that you install the latest release from tomcat.apache.org, and keep an eye on the mailing lists for announcements regarding security advisories and version updates. Dan I there any other workaround... I mean... I guess even before Tomcat7, people needed to declare such aliases. Thank you for your help and best regards. -- View this message in context: http://tomcat.10.n6.nabble.com/Tomcat6-Context-aliases-tp4678430p4678513.html Sent from the Tomcat - User mailing list archive at Nabble.com. - 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: Tomcat6 - Context - aliases
Thank you for your advice. And how did people do to declare aliases before the aliases attribute of the Context element was introduced in Tomcat7? -- View this message in context: http://tomcat.10.n6.nabble.com/Tomcat6-Context-aliases-tp4678430p4679060.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat6 - Context - aliases
On 02/04/2012 15:23, Léa Massiot wrote: Thank you for your advice. And how did people do to declare aliases before the aliases attribute of the Context element was introduced in Tomcat7? Either they did not, or they selected an alternative based on their use-case. What is your exact requirement? p -- View this message in context: http://tomcat.10.n6.nabble.com/Tomcat6-Context-aliases-tp4678430p4679060.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- [key:62590808] signature.asc Description: OpenPGP digital signature
Re: Tomcat6 - Context - aliases
Pid * wrote Either they did not, or they selected an alternative based on their use-case. I'm sure they did. You'll see below, my requirements are basic. Pid * wrote What is your exact requirement? - Users upload files to the server running Tomcat. - The Webapp stores these file on the hard disk in some directory which has nothing to do neither with the Webapp nor with the Tomcat engine. Let's name it d1. - I needed an alias for the directory d1 to refer to it from inside the Webapp. I created a META-INF/context.xml: ?xml version='1.0' encoding='UTF-8'? Context aliases=quot;/lt;an_alias_1=d1 /Context Of course, it works as expected with Tomcat7. I just want to do something equivalent which works with Tomcat6. Thank you for helping me and best regards. -- View this message in context: http://tomcat.10.n6.nabble.com/Tomcat6-Context-aliases-tp4678430p4679237.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat6 - Context - aliases
Léa Massiot wrote: Pid * wrote Either they did not, or they selected an alternative based on their use-case. I'm sure they did. You'll see below, my requirements are basic. Pid * wrote What is your exact requirement? - Users upload files to the server running Tomcat. - The Webapp stores these file on the hard disk in some directory which has nothing to do neither with the Webapp nor with the Tomcat engine. Let's name it d1. - I needed an alias for the directory d1 to refer to it from inside the Webapp. I created a META-INF/context.xml: ?xml version='1.0' encoding='UTF-8'? Context aliases=quot;/lt;an_alias_1=d1 /Context Of course, it works as expected with Tomcat7. I just want to do something equivalent which works with Tomcat6. this might help, in a container- and version-independent way : http://jaitechwriteups.blogspot.de/2007/01/how-to-read-properties-file-in-web.html - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat6 - Context - aliases
On 02/04/2012 16:14, Léa Massiot wrote: Pid * wrote Either they did not, or they selected an alternative based on their use-case. I'm sure they did. You'll see below, my requirements are basic. Pid * wrote What is your exact requirement? - Users upload files to the server running Tomcat. - The Webapp stores these file on the hard disk in some directory which has nothing to do neither with the Webapp nor with the Tomcat engine. Let's name it d1. - I needed an alias for the directory d1 to refer to it from inside the Webapp. Please define 'inside'. Does the application need to perform an internal forward, or does the client just need to be able to request the URL for the resource? In the latter case, put a Context file in: tomcat/conf/Catalina/$hostname/$alias.xml ?xml version='1.0' encoding='UTF-8'? Context docBase=/path/to/d1 /Context p I created a META-INF/context.xml: ?xml version='1.0' encoding='UTF-8'? Context aliases=quot;/lt;an_alias_1=d1 /Context Of course, it works as expected with Tomcat7. I just want to do something equivalent which works with Tomcat6. Thank you for helping me and best regards. -- View this message in context: http://tomcat.10.n6.nabble.com/Tomcat6-Context-aliases-tp4678430p4679237.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- [key:62590808] signature.asc Description: OpenPGP digital signature
Re: Tomcat6 - Context - aliases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Léa, On 4/2/12 6:45 AM, Léa Massiot wrote: Konstantin Kolinko wrote Install Tomcat 7. Read RUNNING.txt for a start. I prefer not to. As I wrote, Tomcat7 is not packaged yet in Debian stable Squeeze. Nor will it. Debian has a fairly conservative release strategy, and I suspect that Squeeze will *never* have a version of Tomcat 7 available to the package manager. For security reasons, I want to use only stable, packaged and up-to-date OS and software versions. You will probably have to upgrade to Wheezy (currently testing) which currently has Tomcat 7.0.26-1 (the -1 is Debian's additional patch level version number). Note that Debian isn't always so fast to back-port security patches so clinging to the Debian package manager doesn't necessarily make you more secure... it just makes your security someone else's problem which might be a mistake. I there any other workaround... I mean... I guess even before Tomcat7, people needed to declare such aliases. You could deploy multiple webapps to get the same behavior as 'aliases'. Or, you could merge your directories together as deploy-time. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk96EdcACgkQ9CaO5/Lv0PCtyQCfe2FdMDFI/E2741bvtjX+PmI9 KOcAn16rx4b2DHGwwwU16jIJ9B5B/TR2 =O/i8 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org