You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Ray Holme <ra...@yahoo.com.INVALID> on 2015/06/02 13:42:08 UTC
jar files - where - please explain
I have been using tomcat for a while and have several applications. Some jar files are specific to an application and make sense to be in .../webapps/APPLICATION/WEB-INF/lib and some are used in multiple applications so they need to appear in each applications lib. One shared jar file is my own common code, but then there are many things that are pulled from the net (e.g. mail.jar). In addition I put one jar file in the top tomcate ../lib directory as it is used by everything for DB access (jaybird...jar in my case.
Since I use Linux, ALL of these extra jar files are maintained somewhere else (same linux file system required) and I hard link them to the above named places so I don't need multiple copies and one update serves all (with a web restart, natch).
So, here are my questions: 1) Is there any reason why the SQL library (jaybird above) needs to be in the .../lib (top tomcat directory) or could it be in the WEB-INF/lib directory too? If the latter is OK, then it becomes part of the WAR file when I distribute and thus saves an extra step when this jar updates. Also, by putting it (logically) there in the application lib(s), it evokes more security if I understand the purpose of doing this (see next question).
2) Could I also put my own common jar file in the top tomcat .../lib directory? I am confident that it does NOT have insecure code so logic says it could be there, but having it in the WAR file might be a better option anyway as I do add things to it. In other words, if I were confident in the source for say mail.jar and knew it was secure, it too could be in the top directory (with the caveat that it no longer is in the WAR file).
Question 1 would be useful as it makes distributions more easy and totally effective if all can be in the WAR file. Question 2 is just for me to understand better how tomcat works - I don't think I want to move the application jars to the tomcat lib.
Many thanks for improving my understanding.
Re: jar files - where - please explain
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Ray,
On 6/4/15 8:01 AM, Ray Holme wrote:
>> Inside the WAR or having the WAR as a symlnk?
>
> OK, I did a test and YES inside a WAR file
> ${CATALINA_HOME}/webapps/Application/WEB-INF/lib/*.jarfiles ARE
> expanded if they are symbolic links to real files.
What? The JAR utility does not support symlinks, so your JAR tool is
likely putting the whole file into the WAR archive.
Now, ZIP files *do* support symlinks, but I'll bet that Java will
fall-over if you try to open a ZIP file and it encounters a symlink in
there.
> (My bad for not testing before). Now I am really in trouble. I
> have an application which has a
> ${CATALINA_HOME}/webapps/Application/photosdirectory which is a
> symbolic link
Pointing where?
> with the following line in the
> ${CATALINA_HOME}/conf/Catalina/localhost/Application.xml file:
> aliases="/photos=/opt/web_bigDirs/Applicationi_photos" - I NEVER
> wanted this link expanded!!!
Tomcat doesn't expand anything. If you have a WAR file with an "alias"
configured in it, it will just access the aliased directory directly.
> The idea is to have multiple deployment places (hoping someday when
> testing done), each having their own photos on file and never
> deploy my own test photos.
Can you explain this in a little more detail? Remember that nobody
here has any idea what your application does, or what you expect to
happen.
> I was assuming this would work.
"Trust But Verify"?
> I tested and double DARN, "jar cf" expands the link pulling in all
> the sub files - this totally frustrates my intention. I wanted a
> symbolic link there for Unix based machines and just an empty
> directory for Microsoft OS(s). Perhaps if I remove my symbolic
> link the "aliases" parameter will work anyway.
The aliases setting is completely independent from any symlink
business you've got going on.
> I will have to try that when I get a chance. I certainly don't
> want to distribute the contents of this "directory" in a war file
> (it could be HUGE).
I would just use the aliases setting and remove the symlink entirely.
The entire purpose of "aliases" is to allow you to have the effect of
symlinks, but do it in a safe way (that doesn't delete all your
symlinked files when you undeploy the web application, for instance).
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJVcH7bAAoJEBzwKT+lPKRYwKEP/0nrcgRPykFIioBnPhPEUv1J
PeOpUpKrsSCHBjgIq691Bo1nZTWkdCAiplC/rBv7VRw3iW6d1oGkdQcK3xV66wiS
xlU2RwGfVYjau0Vbn/gTi4IimAMYYuzLWwYUOv9c9zNCcsctJlCVLksO9XDTHOdU
wl3D54WENVuAxFxP0P9iIoT1UEu0myAQHtcO0ez0uvdzt1DkaFR+EkJHDWcBPjPB
cqvHXOYHzR6Ixv4Z3t+8DprmPHgIHQxjPlt4OhEIgGFqE0q1oDA6VKjdDcRETdQB
Q0v6eynBC43w7Ac61R6KU6zNXxpxTWL+8+xZ9dqAy8zlJmsDqLUXt8SkDGc9mkJR
lcELbmfKttsHIgoVydyBjS8WyvpAYYkS8MLj/ntpb1w7lWuKHV6tHkcyX2pSfOEG
g1sMUU8P4/rCrFk69/1GJkP9DUL1nfIskGybQ1cTPuBs5m1tPIgVVhSf8swOLdYl
6tkG+9+H8x8ICW/kuggSmiD8aKpl3+NBmfxRhzUJBNSDUDIsyGCp4vT2usAExyu4
SEaC5XlB18uNvIoZrDWx7naodWiMRIgTCno0cJyNgq+NpxlRJ7NbOHpa8xzwK0gV
RG1vzP6jvSxIHioIk/W+R7+hiWU2DyzePAIhVsCTcvf96CmMuYtub3x+WYF5vEnM
ZCBcvR4CU2ba0oIZQcXB
=N8tQ
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] jar files - where - please explain
Posted by Ray Holme <ra...@yahoo.com.INVALID>.
>Inside the WAR or having the WAR as a symlnk?
OK, I did a test and YES inside a WAR file ${CATALINA_HOME}/webapps/Application/WEB-INF/lib/*.jarfiles ARE expanded if they are symbolic links to real files. (My bad for not testing before).Now I am really in trouble. I have an application which has a ${CATALINA_HOME}/webapps/Application/photosdirectory which is a symbolic link with the following line in the ${CATALINA_HOME}/conf/Catalina/localhost/Application.xmlfile: aliases="/photos=/opt/web_bigDirs/Applicationi_photos" - I NEVER wanted this link expanded!!!The idea is to have multiple deployment places (hoping someday when testing done), each having their own photos on file and never deploy my own test photos. I was assuming this would work. I tested and double DARN, "jar cf" expands the link pulling in all the sub files - this totally frustrates my intention. I wanted a symbolic link there for Unix based machines and just an empty directory for Microsoft OS(s). Perhaps if I remove my symbolic link the "aliases" parameter will work anyway. I will have to try that when I get a chance. I certainly don't want to distribute the contents of this "directory" in a war file (it could be HUGE).
On Thursday, June 4, 2015 3:15 AM, Mark Thomas <ma...@apache.org> wrote:
On 03/06/2015 21:57, Christopher Schultz wrote:
> Mark,
>
> On 6/3/15 3:53 PM, Mark Thomas wrote:
>> On 03/06/2015 20:48, Christopher Schultz wrote:
>
>> <snip/>
>
>>> I don't understand the underlying reasons why Tomcat treats
>>> symlinks specially...
>
>> <snip/>
>
>> It is to do with case sensitivity on non case sensitive file
>> systems. The check we have to add on Windows to stop things like
>> JSP source disclosure by requesting /index.Jsp also blocks
>> symlinks.
>
>> Removing that check (and hence enabling symlinks) is safe on a
>> case sensitive file system and unsafe on a non-case sensitive file
>> system.
>
> Is that protection require something that can be detected by software,
> and then only applied when necessary?
In theory, yes.
In practise, given the security sensitivity of this I'd be very, very
cautious about changing it.
> For instance, most UNIX filesystems have symlinks and case-sensitive
> filesystems, and these checks would not be necessary. Plus, users in
> those environments are quite used to using symlinks in place of real
> files.
>
> Windows users rarely use symbolic links, and have a case-sensitive
> filesystem, and these checks are certainly necessary. Prohibiting
> symbolic linking (by default) in this environment is probably okay.
>
> Mac OS X is a bit odd in that it's got all of the great things about a
> traditional UNIX filesystem except that it's got a better chance of
> being case-insensitive because HFS+ allows both semantics, but the
> default is unfortunately case-insensitive. In this environment, it's
> probably okay to prevent symbolic links unless he user forces them
> back on.
>
> The obvious way to check for case-sensitivity would be to create a
> file in the work directory with a certain name in mixed-case like
> "TestFile.txt" and then try to open it with an all-lowercase name
> ("textfile.txt") and see if it exists. Then, we could enable or
> disable this kind of checking.
>
> Does anyone have any comments about something like that?
>
> We probably have a lot of places where we "resolve" filenames but I'm
> guessing we don't have a single utility method to do the work;
Wrong :)
> probably just new File(new File(file).getCanonicalPath()) or something
> like that wherever it's needed. If we unified all those accesses in a
> single place, it would be easy to change these semantics for different
> environments.
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/webresources/AbstractFileResourceSet.java?view=annotate#l54
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [OT] jar files - where - please explain
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Ray Holme [mailto:rayholme@yahoo.com.INVALID]
> Subject: Re: [OT] jar files - where - please explain
> I may be off base here, but IMHO Windoze does not support symbolic links
Yes, you're off base. Windows symlinks have been available since Vista. GIYF. For example:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365680%28v=vs.85%29.aspx
- 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] jar files - where - please explain
Posted by Ray Holme <ra...@yahoo.com.INVALID>.
>> For instance, most UNIX filesystems have symlinks and
>> case-sensitive filesystems, and these checks would not be
>> necessary. Plus, users in those environments are quite used to
>> using symlinks in place of real files.
>>
Using Unix and Linux for a LONG time, love symlinks as they work across file systems and oh so much more.>> Windows users rarely use symbolic links, and have a
>> case-sensitive filesystem, and these checks are certainly
>> necessary. Prohibiting symbolic linking (by default) in this
>> environment is probably okay.
I may be off base here, but IMHO Windoze does not support symbolic links, or fork or ...It is more like a partial Unix (was built on the idea, but not fully formed).
>>
>> Mac OS X is a bit odd in that it's got all of the great things
>> about a traditional UNIX filesystem except that it's got a better
>> chance of being case-insensitive because HFS+ allows both
>> semantics, but the default is unfortunately case-insensitive. In
>> this environment, it's probably okay to prevent symbolic links
>> unless he user forces them back on.
>>
Not a big user of OSX - not aware it supported case-insensitive. When I used it I treated it like Unix with case sensitive files and had NO problems.
>> The obvious way to check for case-sensitivity would be to create
>> a file in the work directory with a certain name in mixed-case
>> like "TestFile.txt" and then try to open it with an all-lowercase
>> name ("textfile.txt") and see if it exists. Then, we could enable
>> or disable this kind of checking.
Sounds like the right approach.
On Thursday, June 4, 2015 12:32 PM, Christopher Schultz <ch...@christopherschultz.net> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mark,
On 6/4/15 3:15 AM, Mark Thomas wrote:
> On 03/06/2015 21:57, Christopher Schultz wrote:
>> Mark,
>>
>> On 6/3/15 3:53 PM, Mark Thomas wrote:
>>> On 03/06/2015 20:48, Christopher Schultz wrote:
>>
>>> <snip/>
>>
>>>> I don't understand the underlying reasons why Tomcat treats
>>>> symlinks specially...
>>
>>> <snip/>
>>
>>> It is to do with case sensitivity on non case sensitive file
>>> systems. The check we have to add on Windows to stop things
>>> like JSP source disclosure by requesting /index.Jsp also
>>> blocks symlinks.
>>
>>> Removing that check (and hence enabling symlinks) is safe on a
>>> case sensitive file system and unsafe on a non-case sensitive
>>> file system.
>>
>> Is that protection require something that can be detected by
>> software, and then only applied when necessary?
>
> In theory, yes.
>
> In practise, given the security sensitivity of this I'd be very,
> very cautious about changing it.
Agreed. There is probably some edge-case I'm not considering.
...but it *would* be nice to let symlinks work :)
>> For instance, most UNIX filesystems have symlinks and
>> case-sensitive filesystems, and these checks would not be
>> necessary. Plus, users in those environments are quite used to
>> using symlinks in place of real files.
>>
>> Windows users rarely use symbolic links, and have a
>> case-sensitive filesystem, and these checks are certainly
>> necessary. Prohibiting symbolic linking (by default) in this
>> environment is probably okay.
>>
>> Mac OS X is a bit odd in that it's got all of the great things
>> about a traditional UNIX filesystem except that it's got a better
>> chance of being case-insensitive because HFS+ allows both
>> semantics, but the default is unfortunately case-insensitive. In
>> this environment, it's probably okay to prevent symbolic links
>> unless he user forces them back on.
>>
>> The obvious way to check for case-sensitivity would be to create
>> a file in the work directory with a certain name in mixed-case
>> like "TestFile.txt" and then try to open it with an all-lowercase
>> name ("textfile.txt") and see if it exists. Then, we could enable
>> or disable this kind of checking.
>>
>> Does anyone have any comments about something like that?
>>
>> We probably have a lot of places where we "resolve" filenames but
>> I'm guessing we don't have a single utility method to do the
>> work;
>
> Wrong :)
>
>> probably just new File(new File(file).getCanonicalPath()) or
>> something like that wherever it's needed. If we unified all those
>> accesses in a single place, it would be easy to change these
>> semantics for different environments.
>
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/web
resources/AbstractFileResourceSet.java?view=annotate#l54
Nice
>
work.
So the code in there uses canonical paths, and when you canonicalize a
symlink, you end up with the location of the "real" file, not the
symlink, and everything goes boom at that point. Is my understanding
correct?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJVcH1nAAoJEBzwKT+lPKRYML8QAJJUxzgzTdrkvXHAF2W/OqKs
yuca0UF0tGU72iPptVAF7Rsja1X+Bfi8V0SU7LWLtIP9VKaDTj1Vt2DNrCbArDPB
lRMZlWNYBA/L/1HHh1wzk4CE1O5BcFQMUyKuzlvHFOhoN7LqSsiJoAPQLqrtM0rc
0VVtX51PBaB6QWzwwjTOUyJHto3CinPShekOhEUanSoSU5TO7wcpaqEwYK0YCZQx
ATy0g7bg07RAfBzhZpgGmFzKDhIesNfD7RcCYYnktSr0LXIr8Onio+IQeyFjInGH
bV5fSDaDmxlMvcWl8LrHtJqhw8B4qIKayXXtzeHongpgOKe6CsSLz8MaetWmb3QL
8S8IocN0XoLjegrWjmOyDNwRZo5/G9LpbFxBtMxY1uwW8pQ54Nk0hY5pAOcF8rGF
B4gLxcAQy6L7Ml0ob26SdZufowy8QPgB8BGqHdH3jiUTiuoFoVX8QSXIEVnGqoy6
gxmvEjb6M5VkLkaib3F/4M+OSGg5n+ea45WqTUpLinfX37sC/HBL6bBrRRbFpAKk
30N8YOsblx4D2YbVe7M1HYvxcBOUoIBQxMSONg/VHArTgSdveA3BvhrHDOXY6WMf
6g/WTLNpHAaNBjlifRQCsCxr0wMAjGb8MFCxFDjDhR5Zz3VyWDCa0RWJ4UjfKIyj
yRJd9Zxq45iPU0k7DBoD
=2ME1
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] jar files - where - please explain
Posted by Mark Thomas <ma...@apache.org>.
On 04/06/2015 17:31, Christopher Schultz wrote:
<snip/>
>>> We probably have a lot of places where we "resolve" filenames but
>>> I'm guessing we don't have a single utility method to do the
>>> work;
>
>> Wrong :)
>
>>> probably just new File(new File(file).getCanonicalPath()) or
>>> something like that wherever it's needed. If we unified all those
>>> accesses in a single place, it would be easy to change these
>>> semantics for different environments.
>
>> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/web
> resources/AbstractFileResourceSet.java?view=annotate#l54
>
> Nice
>
> work.
>
> So the code in there uses canonical paths, and when you canonicalize a
> symlink, you end up with the location of the "real" file, not the
> symlink, and everything goes boom at that point. Is my understanding
> correct?
Correct.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] jar files - where - please explain
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mark,
On 6/4/15 3:15 AM, Mark Thomas wrote:
> On 03/06/2015 21:57, Christopher Schultz wrote:
>> Mark,
>>
>> On 6/3/15 3:53 PM, Mark Thomas wrote:
>>> On 03/06/2015 20:48, Christopher Schultz wrote:
>>
>>> <snip/>
>>
>>>> I don't understand the underlying reasons why Tomcat treats
>>>> symlinks specially...
>>
>>> <snip/>
>>
>>> It is to do with case sensitivity on non case sensitive file
>>> systems. The check we have to add on Windows to stop things
>>> like JSP source disclosure by requesting /index.Jsp also
>>> blocks symlinks.
>>
>>> Removing that check (and hence enabling symlinks) is safe on a
>>> case sensitive file system and unsafe on a non-case sensitive
>>> file system.
>>
>> Is that protection require something that can be detected by
>> software, and then only applied when necessary?
>
> In theory, yes.
>
> In practise, given the security sensitivity of this I'd be very,
> very cautious about changing it.
Agreed. There is probably some edge-case I'm not considering.
...but it *would* be nice to let symlinks work :)
>> For instance, most UNIX filesystems have symlinks and
>> case-sensitive filesystems, and these checks would not be
>> necessary. Plus, users in those environments are quite used to
>> using symlinks in place of real files.
>>
>> Windows users rarely use symbolic links, and have a
>> case-sensitive filesystem, and these checks are certainly
>> necessary. Prohibiting symbolic linking (by default) in this
>> environment is probably okay.
>>
>> Mac OS X is a bit odd in that it's got all of the great things
>> about a traditional UNIX filesystem except that it's got a better
>> chance of being case-insensitive because HFS+ allows both
>> semantics, but the default is unfortunately case-insensitive. In
>> this environment, it's probably okay to prevent symbolic links
>> unless he user forces them back on.
>>
>> The obvious way to check for case-sensitivity would be to create
>> a file in the work directory with a certain name in mixed-case
>> like "TestFile.txt" and then try to open it with an all-lowercase
>> name ("textfile.txt") and see if it exists. Then, we could enable
>> or disable this kind of checking.
>>
>> Does anyone have any comments about something like that?
>>
>> We probably have a lot of places where we "resolve" filenames but
>> I'm guessing we don't have a single utility method to do the
>> work;
>
> Wrong :)
>
>> probably just new File(new File(file).getCanonicalPath()) or
>> something like that wherever it's needed. If we unified all those
>> accesses in a single place, it would be easy to change these
>> semantics for different environments.
>
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/web
resources/AbstractFileResourceSet.java?view=annotate#l54
Nice
>
work.
So the code in there uses canonical paths, and when you canonicalize a
symlink, you end up with the location of the "real" file, not the
symlink, and everything goes boom at that point. Is my understanding
correct?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJVcH1nAAoJEBzwKT+lPKRYML8QAJJUxzgzTdrkvXHAF2W/OqKs
yuca0UF0tGU72iPptVAF7Rsja1X+Bfi8V0SU7LWLtIP9VKaDTj1Vt2DNrCbArDPB
lRMZlWNYBA/L/1HHh1wzk4CE1O5BcFQMUyKuzlvHFOhoN7LqSsiJoAPQLqrtM0rc
0VVtX51PBaB6QWzwwjTOUyJHto3CinPShekOhEUanSoSU5TO7wcpaqEwYK0YCZQx
ATy0g7bg07RAfBzhZpgGmFzKDhIesNfD7RcCYYnktSr0LXIr8Onio+IQeyFjInGH
bV5fSDaDmxlMvcWl8LrHtJqhw8B4qIKayXXtzeHongpgOKe6CsSLz8MaetWmb3QL
8S8IocN0XoLjegrWjmOyDNwRZo5/G9LpbFxBtMxY1uwW8pQ54Nk0hY5pAOcF8rGF
B4gLxcAQy6L7Ml0ob26SdZufowy8QPgB8BGqHdH3jiUTiuoFoVX8QSXIEVnGqoy6
gxmvEjb6M5VkLkaib3F/4M+OSGg5n+ea45WqTUpLinfX37sC/HBL6bBrRRbFpAKk
30N8YOsblx4D2YbVe7M1HYvxcBOUoIBQxMSONg/VHArTgSdveA3BvhrHDOXY6WMf
6g/WTLNpHAaNBjlifRQCsCxr0wMAjGb8MFCxFDjDhR5Zz3VyWDCa0RWJ4UjfKIyj
yRJd9Zxq45iPU0k7DBoD
=2ME1
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] jar files - where - please explain
Posted by Mark Thomas <ma...@apache.org>.
On 03/06/2015 21:57, Christopher Schultz wrote:
> Mark,
>
> On 6/3/15 3:53 PM, Mark Thomas wrote:
>> On 03/06/2015 20:48, Christopher Schultz wrote:
>
>> <snip/>
>
>>> I don't understand the underlying reasons why Tomcat treats
>>> symlinks specially...
>
>> <snip/>
>
>> It is to do with case sensitivity on non case sensitive file
>> systems. The check we have to add on Windows to stop things like
>> JSP source disclosure by requesting /index.Jsp also blocks
>> symlinks.
>
>> Removing that check (and hence enabling symlinks) is safe on a
>> case sensitive file system and unsafe on a non-case sensitive file
>> system.
>
> Is that protection require something that can be detected by software,
> and then only applied when necessary?
In theory, yes.
In practise, given the security sensitivity of this I'd be very, very
cautious about changing it.
> For instance, most UNIX filesystems have symlinks and case-sensitive
> filesystems, and these checks would not be necessary. Plus, users in
> those environments are quite used to using symlinks in place of real
> files.
>
> Windows users rarely use symbolic links, and have a case-sensitive
> filesystem, and these checks are certainly necessary. Prohibiting
> symbolic linking (by default) in this environment is probably okay.
>
> Mac OS X is a bit odd in that it's got all of the great things about a
> traditional UNIX filesystem except that it's got a better chance of
> being case-insensitive because HFS+ allows both semantics, but the
> default is unfortunately case-insensitive. In this environment, it's
> probably okay to prevent symbolic links unless he user forces them
> back on.
>
> The obvious way to check for case-sensitivity would be to create a
> file in the work directory with a certain name in mixed-case like
> "TestFile.txt" and then try to open it with an all-lowercase name
> ("textfile.txt") and see if it exists. Then, we could enable or
> disable this kind of checking.
>
> Does anyone have any comments about something like that?
>
> We probably have a lot of places where we "resolve" filenames but I'm
> guessing we don't have a single utility method to do the work;
Wrong :)
> probably just new File(new File(file).getCanonicalPath()) or something
> like that wherever it's needed. If we unified all those accesses in a
> single place, it would be easy to change these semantics for different
> environments.
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/webresources/AbstractFileResourceSet.java?view=annotate#l54
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] jar files - where - please explain
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mark,
On 6/3/15 3:53 PM, Mark Thomas wrote:
> On 03/06/2015 20:48, Christopher Schultz wrote:
>
> <snip/>
>
>> I don't understand the underlying reasons why Tomcat treats
>> symlinks specially...
>
> <snip/>
>
> It is to do with case sensitivity on non case sensitive file
> systems. The check we have to add on Windows to stop things like
> JSP source disclosure by requesting /index.Jsp also blocks
> symlinks.
>
> Removing that check (and hence enabling symlinks) is safe on a
> case sensitive file system and unsafe on a non-case sensitive file
> system.
Is that protection require something that can be detected by software,
and then only applied when necessary?
For instance, most UNIX filesystems have symlinks and case-sensitive
filesystems, and these checks would not be necessary. Plus, users in
those environments are quite used to using symlinks in place of real
files.
Windows users rarely use symbolic links, and have a case-sensitive
filesystem, and these checks are certainly necessary. Prohibiting
symbolic linking (by default) in this environment is probably okay.
Mac OS X is a bit odd in that it's got all of the great things about a
traditional UNIX filesystem except that it's got a better chance of
being case-insensitive because HFS+ allows both semantics, but the
default is unfortunately case-insensitive. In this environment, it's
probably okay to prevent symbolic links unless he user forces them
back on.
The obvious way to check for case-sensitivity would be to create a
file in the work directory with a certain name in mixed-case like
"TestFile.txt" and then try to open it with an all-lowercase name
("textfile.txt") and see if it exists. Then, we could enable or
disable this kind of checking.
Does anyone have any comments about something like that?
We probably have a lot of places where we "resolve" filenames but I'm
guessing we don't have a single utility method to do the work;
probably just new File(new File(file).getCanonicalPath()) or something
like that wherever it's needed. If we unified all those accesses in a
single place, it would be easy to change these semantics for different
environments.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJVb2o/AAoJEBzwKT+lPKRY6REQALYt4gPup33oDcMo6Rp6kW7P
3OFP4M3fGcYZ4tu3aFI+wlGhp/ikBwNUMCFoLrtITIbNJ6EDl4KZOUUdUUjldjd0
uFHC8AQcKoU62Z36vUYknmTmtD39/ibQJ6orv6/L6sN5UZE5fYTIwkw/qN1VEwCk
YCLGK+oJl3daYEuo4md4IVeGPOWC9COQ5VPY/OVfHk4m/cfRWCdTwjsFcs256wKj
kgTBWiZaclr8zVaTCUWVdyUAahdzJ7k90Sp1anZpJUm1XKOC8ySc3z5ygvep1JZD
3IBB49QZXYwQuVj43t96QzxcRmBUf+KeaZ7QLfi/+cIonhy5uLoMxzON/njZtvIC
TTQhPJjE53wIcqHttI7BgiwqvgmuSJHAhlFc39sHWQFqqgxDBudoGngfK9BITd/Y
oxg+at2IZaTfM9JM7kirt/oppUkif1tELaU44iJFT4vnVTLRZ3AvxBOG6mOWoWkx
5+pIzoOlOmQdhZUxQS3ziX+QDt3wz8vb6Y0EMuUCqc3wEHLeLkoeTguPIE2YQopN
zh5y1eZ9mlGppXoRxHrnvtRPtxsXTQnEakyMGGcY2oQOmsl5TLvrJfMLmeoM5UIv
sGdoy6kg5fuxWQRxIj2JcOgmgmS5wTCyV4K0dYm4z0NLp08THivEMVaVgBkEplZL
9kVcfiuD4aNCn5HXzCNd
=3XAR
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: jar files - where - please explain
Posted by Mark Thomas <ma...@apache.org>.
On 03/06/2015 20:48, Christopher Schultz wrote:
<snip/>
> I don't
> understand the underlying reasons why Tomcat treats symlinks
> specially...
<snip/>
It is to do with case sensitivity on non case sensitive file systems.
The check we have to add on Windows to stop things like JSP source
disclosure by requesting /index.Jsp also blocks symlinks.
Removing that check (and hence enabling symlinks) is safe on a case
sensitive file system and unsafe on a non-case sensitive file system.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: jar files - where - please explain
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Ray,
On 6/3/15 9:44 AM, Ray Holme wrote:
>> I'm curious as to why you are using hard links instead of
>> symlinks. If you copy a new file over a hard link, you un-couple
>> it from the rest of the series of hard links. If you do the same
>> with symlinks, the result is probably more what you were
>> expecting. There are other disadvantages with hard links
>> including not really knowing that it's a link (symlinks are
>> obvious) and they can't span across filesystems.
>
> Again correct, but for a while tomcat did not allow me to have
> symbolic links (or I did not know about the way to overcome that
> in the xml file). In any case, I solved the problem with a shell
> script that makes sure the hard links are correct AFTER a complete
> compilation set is done.
Okay. I think you just have to set allowLinking="true". I don't
understand the underlying reasons why Tomcat treats symlinks
specially... I'm used to using *NIX utilities where the presence of a
link (instead of a "real" file) isn't important unless you are
specifically looking for a link (e.g. using readlink() instead of read()
).
> The other problem (which may or may not be a problem - I have not
> tried in a while) is making a WAR file. I cannot have symbolic
> links then.
Inside the WAR or having the WAR as a symlnk? You should be able to
symlink WAR files, but you may have to have that allowLinking="true"
(though not in META-INF/context.xml, since that's /inside/ the WAR, of
course).
> The target machine running the application just gets the WAR file
> and NOT the directory containing the assorted jars. But perhaps I
> should re-explore that one.
I'm not sure what you mean, the "target machine". Perhaps this is a
deployment issue and not a Tomcat one?
> And by the way, you can edit the hard link file AND all versions
> change.
That's opening an existing file (inode) and changing the contents.
Hard links are references to inodes, so this isn't surprising.
> You can also "cat >file" and all hard links remain.
This depends upon how the shell treats output redirection. One can
truncate an existing file in-place, or one can delete the existing
file and replace it. The former will give you the behavior you
observe, while the latter will break your links (because you create a
new inode).
> It is ONLY when you move a file over one of the links that the
> hard links are unlinked. Curious!
cp will erase the existing file (well, the directory entry) and put
the new one into its place, rather than re-writing the file.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJVb1oQAAoJEBzwKT+lPKRYDxYQAMdrUiLfmQfGkJw23ExCd6Ns
EqRL0YuCUvi1V1RXGlzDqjNHttgBaYR9XhcvKU+qp8JQF1KIMiBqWa4SR+70/Hij
QaD+zFjbz6LWjDrB8Xq9HFXx7LItUe/mEs1fvyfOfzksZUoIdzjXCLG9jzVoEB0N
cOExkSoT0rt/f7tjRfBXQBl+89j/tROukzHpMqtdYuUrWlTQIkeeRIh2C8TSBcGX
YiiSQCVbr+5vOVCX7W2/gwOkBJffWYqKCZwno6RjszdVs0wmVtRV7ka+/SIpNp6T
f2KYw+js0oFJzPoLVAlPCCHezNTKOdmlaK4GPDDYvc8/KK06zXNOh59c0+tMZ66i
XCCJy5MYDK09u0eYMomdYOKINYizmlZ2I9rDRwUCukAMFrRd/4pFZXG5XgoPecFE
oTltiMCntoKN9+HVarMP3jP8P3FFsaMuDp+maliaV4jByDbP18JX2A75+EyngXHx
yUIwbpZxE4KSObxpYSebJutuibHmflMBQ6c1lQ3pTbW6kga2rOWs+tGU4EN1u6a6
eSiyyhHu2y0REqDLkXdXL285BUuiRgty6XQmx9rvbYnsLU3AImrDk7AKLqZmDuAL
ueZprqSkOJW98lxQiXbE2G900hpKcSen5Jl6BOZrzcuI6Aw9LZ9YZ6kfYTlaCrUh
BKfLKzZ9ZtYSUchRU0Cg
=fuwD
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: jar files - where - please explain
Posted by Ray Holme <ra...@yahoo.com.INVALID>.
>Really? Tomcat 6.0 replaced the server/lib/, shared/lib/, and
common/lib/ directories in favor of a single, unified lib/ directory.
That doesn't strike you as an important change?
Again, you are right. Single is much better, but I still only needed one link for the SQL jar and moving that to lib from shared made little difference to me conceptually.
>I'm curious as to why you are using hard links instead of symlinks. If
you copy a new file over a hard link, you un-couple it from the rest
of the series of hard links. If you do the same with symlinks, the
result is probably more what you were expecting. There are other
disadvantages with hard links including not really knowing that it's a
link (symlinks are obvious) and they can't span across filesystems.
Again correct, but for a while tomcat did not allow me to have symbolic links (or I did not know about the way to overcome that in the xml file). In any case, I solved the problem with a shell script that makes sure the hard links are correct AFTER a complete compilation set is done. The other problem (which may or may not be a problem - I have not tried in a while) is making a WAR file. I cannot have symbolic links then. The target machine running the application just gets the WAR file and NOT the directory containing the assorted jars. But perhaps I should re-explore that one.
And by the way, you can edit the hard link file AND all versions change. You can also "cat >file" and all hard links remain. It is ONLY when you move a file over one of the links that the hard links are unlinked. Curious!
On Wednesday, June 3, 2015 8:47 AM, Christopher Schultz <ch...@christopherschultz.net> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Ray,
On 6/2/15 6:42 PM, Ray Holme wrote:
> I have not seen changes to the lib structures for any of the tomcat
> releases I have used and that spans back 5 years or more (well OK,
> at one point symbolic links worked, now they don't unless I change
> the xml file).
Really? Tomcat 6.0 replaced the server/lib/, shared/lib/, and
common/lib/ directories in favor of a single, unified lib/ directory.
That doesn't strike you as an important change?
> Thanks for the answer. I would have moved the jaybird thing only
> so WAR files included it, but it sounds like a bad idea if
> clobbers connection pools - thought there was ONE pool per
> application.
There is a chicken-and-egg problem with the context ClassLoader which
makes it difficult for the container to set up the context using Java
classes that are hosted from within that application. Anything the
driver depends upon also needs to be available to the container's
ClassLoader.
> Agreed to leave all else as is, the hard link solution solves the
> problem of multiple copies nicely. Just cannot do that in
> Microsoft land, but that is OK as all Microsoft versions I support
> only have one application running.
I'm curious as to why you are using hard links instead of symlinks. If
you copy a new file over a hard link, you un-couple it from the rest
of the series of hard links. If you do the same with symlinks, the
result is probably more what you were expecting. There are other
disadvantages with hard links including not really knowing that it's a
link (symlinks are obvious) and they can't span across filesystems.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJVbvd8AAoJEBzwKT+lPKRYgLEQAKST0dzmy9f7esRk8SvAxtjY
2nqc+SIRe32hdO9C0iIUY+pOTgDHKvi+PEXV7FCC6CXRRKhjZrB19iHMJaz3jZPY
RElw58YAuI1pLMVXV6qMnJ4PmIHbwu5Uy1fDs0XBlNA8nZe7rxbnS6snYu3MqjPt
WP5udl9DCB5SBkl99nHbH5At1qkOfOmhBycfvCIqDZlkA9QxA+HFh/Rq+enJryMK
lH0lO1JbmdY6fRrOA4cppkyp79qpUpBA5hEMsyrrvDF34wENFLjPeZKD8Rz+X6v6
C+MRB04z8GapYpasl+KemnPaW2oLosaCjulMjHVIWCP4KxTKGveAC+cEyCwnuTRW
MXZyVhp/uycHf/WgPMITyBtkj+vIt/U5kalX87hDzxaEq3yHAaa7Yqkdwqi9W1AZ
3XttVcz33vmTnRKykSNPK4IEPuhGtjNup6qOdIP9P0onJOk6gZ3KY7SL0T7Y8jJA
lIU4Exmjv8ZC5tgDenVexehtCGVjqZJiOFNGEkW3W1Jzn7QhTZhKbYB7POxB9WFq
Z0n5nxGppvzhGXf54nFqpSHEn4XxCmeVCLBIheRw0AseUW0X7qVZ+F4NVl+6Llwo
wHnd1NlRO4X9AA/GylVDb5N017SFHtJ/53M2roUK8itV8aECU4xVKguTndykUnYR
8ucTDAUSB+LeOEbDUmaJ
=Hq/T
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: jar files - where - please explain
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Ray,
On 6/2/15 6:42 PM, Ray Holme wrote:
> I have not seen changes to the lib structures for any of the tomcat
> releases I have used and that spans back 5 years or more (well OK,
> at one point symbolic links worked, now they don't unless I change
> the xml file).
Really? Tomcat 6.0 replaced the server/lib/, shared/lib/, and
common/lib/ directories in favor of a single, unified lib/ directory.
That doesn't strike you as an important change?
> Thanks for the answer. I would have moved the jaybird thing only
> so WAR files included it, but it sounds like a bad idea if
> clobbers connection pools - thought there was ONE pool per
> application.
There is a chicken-and-egg problem with the context ClassLoader which
makes it difficult for the container to set up the context using Java
classes that are hosted from within that application. Anything the
driver depends upon also needs to be available to the container's
ClassLoader.
> Agreed to leave all else as is, the hard link solution solves the
> problem of multiple copies nicely. Just cannot do that in
> Microsoft land, but that is OK as all Microsoft versions I support
> only have one application running.
I'm curious as to why you are using hard links instead of symlinks. If
you copy a new file over a hard link, you un-couple it from the rest
of the series of hard links. If you do the same with symlinks, the
result is probably more what you were expecting. There are other
disadvantages with hard links including not really knowing that it's a
link (symlinks are obvious) and they can't span across filesystems.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJVbvd8AAoJEBzwKT+lPKRYgLEQAKST0dzmy9f7esRk8SvAxtjY
2nqc+SIRe32hdO9C0iIUY+pOTgDHKvi+PEXV7FCC6CXRRKhjZrB19iHMJaz3jZPY
RElw58YAuI1pLMVXV6qMnJ4PmIHbwu5Uy1fDs0XBlNA8nZe7rxbnS6snYu3MqjPt
WP5udl9DCB5SBkl99nHbH5At1qkOfOmhBycfvCIqDZlkA9QxA+HFh/Rq+enJryMK
lH0lO1JbmdY6fRrOA4cppkyp79qpUpBA5hEMsyrrvDF34wENFLjPeZKD8Rz+X6v6
C+MRB04z8GapYpasl+KemnPaW2oLosaCjulMjHVIWCP4KxTKGveAC+cEyCwnuTRW
MXZyVhp/uycHf/WgPMITyBtkj+vIt/U5kalX87hDzxaEq3yHAaa7Yqkdwqi9W1AZ
3XttVcz33vmTnRKykSNPK4IEPuhGtjNup6qOdIP9P0onJOk6gZ3KY7SL0T7Y8jJA
lIU4Exmjv8ZC5tgDenVexehtCGVjqZJiOFNGEkW3W1Jzn7QhTZhKbYB7POxB9WFq
Z0n5nxGppvzhGXf54nFqpSHEn4XxCmeVCLBIheRw0AseUW0X7qVZ+F4NVl+6Llwo
wHnd1NlRO4X9AA/GylVDb5N017SFHtJ/53M2roUK8itV8aECU4xVKguTndykUnYR
8ucTDAUSB+LeOEbDUmaJ
=Hq/T
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: jar files - where - please explain
Posted by Ray Holme <ra...@yahoo.com.INVALID>.
Humble apologies, I have not seen changes to the lib structures for any of the tomcat releases I have used and that spans back 5 years or more (well OK, at one point symbolic links worked, now they don't unless I change the xml file).
Thanks for the answer. I would have moved the jaybird thing only so WAR files included it, but it sounds like a bad idea if clobbers connection pools - thought there was ONE pool per application.
Agreed to leave all else as is, the hard link solution solves the problem of multiple copies nicely. Just cannot do that in Microsoft land, but that is OK as all Microsoft versions I support only have one application running.
Many thanks - I understand better why things are as they are.
:=]
On Tuesday, June 2, 2015 10:10 AM, Mark Thomas <ma...@apache.org> wrote:
On 02/06/2015 14:52, David kerber wrote:
> On 6/2/2015 9:11 AM, Ray Holme wrote:
>> Currently using apache-tomcat-7.0.35. Not sure that matters as no
>> behavior has changed in prior releases.
That kind of response when asked for further information - especially
when the information is as basic as which Tomcat version is being used
(you failed to give any indication of the Tomcat version you are using
and we see questions from folks using Tomcat 3 all the way up to the
unreleased Tomcat 9) - is very frustrating for those of us trying to
help and does nothing to encourage us to continue to help.
> It does matter, because the directory layouts have changed in the
> various major versions.
It also matters since later versions of Tomcat are more relaxed about
where they will load JDBC drivers from.
>> On Tuesday, June 2, 2015 8:56 AM, Mark Thomas <ma...@apache.org>
>> wrote:
>>
>>
>> On 02/06/2015 12:42, Ray Holme wrote:
>>> I have been using tomcat for a while and have several applications.
>>> Some jar files are specific to an application and make sense to be in
>>> .../webapps/APPLICATION/WEB-INF/lib and some are used in multiple
>>> applications so they need to appear in each applications lib. One
>>> shared jar file is my own common code, but then there are many things
>>> that are pulled from the net (e.g. mail.jar). In addition I put one
>>> jar file in the top tomcate ../lib directory as it is used by
>>> everything for DB access (jaybird...jar in my case.
>>> Since I use Linux, ALL of these extra jar files are maintained
>>> somewhere else (same linux file system required) and I hard link them
>>> to the above named places so I don't need multiple copies and one
>>> update serves all (with a web restart, natch).
>>> So, here are my questions: 1) Is there any reason why the SQL library
>>> (jaybird above) needs to be in the .../lib (top tomcat directory) or
>>> could it be in the WEB-INF/lib directory too?
Yes. It needs to be in $CATALINA_BASE/lib so it is visible to the
connection pool implementation.
Putting another copy in WEB-INF/lib is theoretically safe (it should be
a NO-OP) but can often trigger class loading issues (if the app refers
to any of the classes in the JAR directly).
See the Tomcat 8 migration guide for how this changes in 8.0.x.
>>> If the latter is OK,
>>> then it becomes part of the WAR file when I distribute and thus saves
>>> an extra step when this jar updates. Also, by putting it (logically)
>>> there in the application lib(s), it evokes more security if I
>>> understand the purpose of doing this (see next question).
>>> 2) Could I also put my own common jar file in the top tomcat .../lib
>>> directory? I am confident that it does NOT have insecure code so
>>> logic says it could be there, but having it in the WAR file might be
>>> a better option anyway as I do add things to it. In other words, if I
>>> were confident in the source for say mail.jar and knew it was secure,
>>> it too could be in the top directory (with the caveat that it no
>>> longer is in the WAR file).
Yes you can put your own JARs in $CATALINA_BASE/lib but beware of issues
with singletons, caches etc. The downside is that it makes it impossible
to use different versions of your JAR with different web applications
(unless you put the classes in different packages) which typically
forces you to upgrade all your applications at the same time.
>>> Question 1 would be useful as it makes distributions more easy and
>>> totally effective if all can be in the WAR file. Question 2 is just
>>> for me to understand better how tomcat works - I don't think I want
>>> to move the application jars to the tomcat lib.
>>> Many thanks for improving my understanding.
Personally, I'd would:
- aim to keep my web applications dependencies to a minimum
- package all the dependencies in WEB-INF/lib
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: jar files - where - please explain
Posted by Mark Thomas <ma...@apache.org>.
On 02/06/2015 14:52, David kerber wrote:
> On 6/2/2015 9:11 AM, Ray Holme wrote:
>> Currently using apache-tomcat-7.0.35. Not sure that matters as no
>> behavior has changed in prior releases.
That kind of response when asked for further information - especially
when the information is as basic as which Tomcat version is being used
(you failed to give any indication of the Tomcat version you are using
and we see questions from folks using Tomcat 3 all the way up to the
unreleased Tomcat 9) - is very frustrating for those of us trying to
help and does nothing to encourage us to continue to help.
> It does matter, because the directory layouts have changed in the
> various major versions.
It also matters since later versions of Tomcat are more relaxed about
where they will load JDBC drivers from.
>> On Tuesday, June 2, 2015 8:56 AM, Mark Thomas <ma...@apache.org>
>> wrote:
>>
>>
>> On 02/06/2015 12:42, Ray Holme wrote:
>>> I have been using tomcat for a while and have several applications.
>>> Some jar files are specific to an application and make sense to be in
>>> .../webapps/APPLICATION/WEB-INF/lib and some are used in multiple
>>> applications so they need to appear in each applications lib. One
>>> shared jar file is my own common code, but then there are many things
>>> that are pulled from the net (e.g. mail.jar). In addition I put one
>>> jar file in the top tomcate ../lib directory as it is used by
>>> everything for DB access (jaybird...jar in my case.
>>> Since I use Linux, ALL of these extra jar files are maintained
>>> somewhere else (same linux file system required) and I hard link them
>>> to the above named places so I don't need multiple copies and one
>>> update serves all (with a web restart, natch).
>>> So, here are my questions: 1) Is there any reason why the SQL library
>>> (jaybird above) needs to be in the .../lib (top tomcat directory) or
>>> could it be in the WEB-INF/lib directory too?
Yes. It needs to be in $CATALINA_BASE/lib so it is visible to the
connection pool implementation.
Putting another copy in WEB-INF/lib is theoretically safe (it should be
a NO-OP) but can often trigger class loading issues (if the app refers
to any of the classes in the JAR directly).
See the Tomcat 8 migration guide for how this changes in 8.0.x.
>>> If the latter is OK,
>>> then it becomes part of the WAR file when I distribute and thus saves
>>> an extra step when this jar updates. Also, by putting it (logically)
>>> there in the application lib(s), it evokes more security if I
>>> understand the purpose of doing this (see next question).
>>> 2) Could I also put my own common jar file in the top tomcat .../lib
>>> directory? I am confident that it does NOT have insecure code so
>>> logic says it could be there, but having it in the WAR file might be
>>> a better option anyway as I do add things to it. In other words, if I
>>> were confident in the source for say mail.jar and knew it was secure,
>>> it too could be in the top directory (with the caveat that it no
>>> longer is in the WAR file).
Yes you can put your own JARs in $CATALINA_BASE/lib but beware of issues
with singletons, caches etc. The downside is that it makes it impossible
to use different versions of your JAR with different web applications
(unless you put the classes in different packages) which typically
forces you to upgrade all your applications at the same time.
>>> Question 1 would be useful as it makes distributions more easy and
>>> totally effective if all can be in the WAR file. Question 2 is just
>>> for me to understand better how tomcat works - I don't think I want
>>> to move the application jars to the tomcat lib.
>>> Many thanks for improving my understanding.
Personally, I'd would:
- aim to keep my web applications dependencies to a minimum
- package all the dependencies in WEB-INF/lib
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: jar files - where - please explain
Posted by David kerber <dc...@verizon.net>.
On 6/2/2015 9:11 AM, Ray Holme wrote:
> Currently using apache-tomcat-7.0.35. Not sure that matters as no behavior has changed in prior releases.
It does matter, because the directory layouts have changed in the
various major versions.
>
>
>
> On Tuesday, June 2, 2015 8:56 AM, Mark Thomas <ma...@apache.org> wrote:
>
>
> On 02/06/2015 12:42, Ray Holme wrote:
>> I have been using tomcat for a while and have several applications. Some jar files are specific to an application and make sense to be in .../webapps/APPLICATION/WEB-INF/lib and some are used in multiple applications so they need to appear in each applications lib. One shared jar file is my own common code, but then there are many things that are pulled from the net (e.g. mail.jar). In addition I put one jar file in the top tomcate ../lib directory as it is used by everything for DB access (jaybird...jar in my case.
>> Since I use Linux, ALL of these extra jar files are maintained somewhere else (same linux file system required) and I hard link them to the above named places so I don't need multiple copies and one update serves all (with a web restart, natch).
>> So, here are my questions: 1) Is there any reason why the SQL library (jaybird above) needs to be in the .../lib (top tomcat directory) or could it be in the WEB-INF/lib directory too? If the latter is OK, then it becomes part of the WAR file when I distribute and thus saves an extra step when this jar updates. Also, by putting it (logically) there in the application lib(s), it evokes more security if I understand the purpose of doing this (see next question).
>> 2) Could I also put my own common jar file in the top tomcat .../lib directory? I am confident that it does NOT have insecure code so logic says it could be there, but having it in the WAR file might be a better option anyway as I do add things to it. In other words, if I were confident in the source for say mail.jar and knew it was secure, it too could be in the top directory (with the caveat that it no longer is in the WAR file).
>> Question 1 would be useful as it makes distributions more easy and totally effective if all can be in the WAR file. Question 2 is just for me to understand better how tomcat works - I don't think I want to move the application jars to the tomcat lib.
>> Many thanks for improving my understanding.
>>
>
> Tomcat version?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: jar files - where - please explain
Posted by Ray Holme <ra...@yahoo.com.INVALID>.
Currently using apache-tomcat-7.0.35. Not sure that matters as no behavior has changed in prior releases.
On Tuesday, June 2, 2015 8:56 AM, Mark Thomas <ma...@apache.org> wrote:
On 02/06/2015 12:42, Ray Holme wrote:
> I have been using tomcat for a while and have several applications. Some jar files are specific to an application and make sense to be in .../webapps/APPLICATION/WEB-INF/lib and some are used in multiple applications so they need to appear in each applications lib. One shared jar file is my own common code, but then there are many things that are pulled from the net (e.g. mail.jar). In addition I put one jar file in the top tomcate ../lib directory as it is used by everything for DB access (jaybird...jar in my case.
> Since I use Linux, ALL of these extra jar files are maintained somewhere else (same linux file system required) and I hard link them to the above named places so I don't need multiple copies and one update serves all (with a web restart, natch).
> So, here are my questions: 1) Is there any reason why the SQL library (jaybird above) needs to be in the .../lib (top tomcat directory) or could it be in the WEB-INF/lib directory too? If the latter is OK, then it becomes part of the WAR file when I distribute and thus saves an extra step when this jar updates. Also, by putting it (logically) there in the application lib(s), it evokes more security if I understand the purpose of doing this (see next question).
> 2) Could I also put my own common jar file in the top tomcat .../lib directory? I am confident that it does NOT have insecure code so logic says it could be there, but having it in the WAR file might be a better option anyway as I do add things to it. In other words, if I were confident in the source for say mail.jar and knew it was secure, it too could be in the top directory (with the caveat that it no longer is in the WAR file).
> Question 1 would be useful as it makes distributions more easy and totally effective if all can be in the WAR file. Question 2 is just for me to understand better how tomcat works - I don't think I want to move the application jars to the tomcat lib.
> Many thanks for improving my understanding.
>
Tomcat version?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: jar files - where - please explain
Posted by Mark Thomas <ma...@apache.org>.
On 02/06/2015 12:42, Ray Holme wrote:
> I have been using tomcat for a while and have several applications. Some jar files are specific to an application and make sense to be in .../webapps/APPLICATION/WEB-INF/lib and some are used in multiple applications so they need to appear in each applications lib. One shared jar file is my own common code, but then there are many things that are pulled from the net (e.g. mail.jar). In addition I put one jar file in the top tomcate ../lib directory as it is used by everything for DB access (jaybird...jar in my case.
> Since I use Linux, ALL of these extra jar files are maintained somewhere else (same linux file system required) and I hard link them to the above named places so I don't need multiple copies and one update serves all (with a web restart, natch).
> So, here are my questions: 1) Is there any reason why the SQL library (jaybird above) needs to be in the .../lib (top tomcat directory) or could it be in the WEB-INF/lib directory too? If the latter is OK, then it becomes part of the WAR file when I distribute and thus saves an extra step when this jar updates. Also, by putting it (logically) there in the application lib(s), it evokes more security if I understand the purpose of doing this (see next question).
> 2) Could I also put my own common jar file in the top tomcat .../lib directory? I am confident that it does NOT have insecure code so logic says it could be there, but having it in the WAR file might be a better option anyway as I do add things to it. In other words, if I were confident in the source for say mail.jar and knew it was secure, it too could be in the top directory (with the caveat that it no longer is in the WAR file).
> Question 1 would be useful as it makes distributions more easy and totally effective if all can be in the WAR file. Question 2 is just for me to understand better how tomcat works - I don't think I want to move the application jars to the tomcat lib.
> Many thanks for improving my understanding.
>
Tomcat version?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org