Re: Tomcat6 - Context - aliases

2012-04-10 Thread Léa Massiot
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

2012-04-10 Thread André Warnier

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

2012-04-10 Thread Léa Massiot
@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

2012-04-09 Thread Léa Massiot
@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

2012-04-09 Thread Léa Massiot
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

2012-04-09 Thread Christopher Schultz
-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

2012-04-09 Thread André Warnier

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

2012-04-07 Thread André Warnier

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

2012-04-06 Thread Léa Massiot

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

2012-04-06 Thread André Warnier

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

2012-04-05 Thread Léa Massiot

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

2012-04-05 Thread Christopher Schultz
-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

2012-04-04 Thread Léa Massiot
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

2012-04-04 Thread Léa Massiot
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

2012-04-04 Thread Caldarale, Charles R
 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-04-04 Thread Konstantin Kolinko
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

2012-04-03 Thread Léa Massiot
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

2012-04-03 Thread André Warnier

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

2012-04-02 Thread Teppei Yamada
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-04-02 Thread Konstantin Kolinko
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

2012-04-02 Thread Léa Massiot
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

2012-04-02 Thread Daniel Mikusa


- 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

2012-04-02 Thread Léa Massiot
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

2012-04-02 Thread Pid
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

2012-04-02 Thread Léa Massiot

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

2012-04-02 Thread André Warnier

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

2012-04-02 Thread Pid
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

2012-04-02 Thread Christopher Schultz
-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