5.5.9 unpackWARs=false
Are there any negative effects when choosing to set unpackWARs to false? Performance? Or what are the advantages to choose unpackWARS=true (I will not edit any expanded file)? Gernot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
unpackWARs
Does the setting unpackWARs affect performance during runtime? The WAR ends up unpacked to the 'work' directory regardless of this setting, correct? Bernard Durfee - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
problem with unpackWARs=false
Hello list, I have tomcat 5.5.7, and JDK/JRE 1.5 (update 2?) and would like to know after hours of searching and trying if there is a simple way to get the storefront webapp (from the O'reilly book programming jakarta struts) to NOT extract the storefront.war file (but still run) in the webapp directory under the tomcat home directory. I have heard that all that needs to change is the server.xml file in tomcat with unpackWARs=false ? Yet when I try to do this, do I need to set up a context / within that host/host ? obviously when I tried to set this to false I could not get it to work and when I tried to dabble with the context path and docbase I couldn't seem to find the right way to get this to work either. I have not changed the tomcat configuration besides what I have below. Also I know that I can run it normally when it wants to extract the war file, so I know there is no problems there. (hope this makes sense to some of the more inclined people out there) Host name=localhost appBase=webapps unpackWARs=false autoDeploy=false xmlValidation=false xmlNamespaceAware=false !--Context path=storefront docBase=d:\storefront debug=0 reloadable=true /-- /Host Thank you, -Otis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: unpackWARs incomplete when deployed with context.xml
On Wed, 16 Mar 2005 18:01:47 +0100 Lionel Farbos [EMAIL PROTECTED] wrote: Hi all, After some tests on TC4.1.31, deployment with context.xml and war unpacked, my unpacked tree is incomplete : static files, JSPs files and properties files (including web.xml) are missing :-( (but the Context is working fine) Is it the normal behaviour or I miss something ? I don't know This is the same with TC5.5 ? NO : it works well on TC5.5.7 : the war is copied in Host.appBase, then completely unpacked - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
unpackWARs incomplete when deployed with context.xml
Hi all, After some tests on TC4.1.31, deployment with context.xml and war unpacked, my unpacked tree is incomplete : static files, JSPs files and properties files (including web.xml) are missing :-( (but the Context is working fine) Is it the normal behaviour or I miss something ? This is the same with TC5.5 ? Some details : My testServlets.war is composed with : myStaticPages (html, images, css, ...) myJSPs META-INF/my_internal_resources.properties WEB-INF/classes/my_classes WEB-INF/lib/my_libs WEB-INF/web.xml I put $CATALINA_HOME/conf/Standalone/localhost/testServlets.xml with Context path=/testServlets docBase=testServlets debug=1 reloadable=true ... Resource name=jdbc/testServletsDB auth=Container type=javax.sql.DataSource/ ResourceParams name=jdbc/testServletsDB ... /ResourceParams Parameter name=PROJECT_NAME value=testServlets override=false/ /Context In server.xml, Engine = Standalone Host = localhost , appBase=webapps unpackWARs=true autoDeploy=false deployOnStartup=false deployXML=true I deploy with Tomcat Manager : /manager/html/install?installPath=/testServletsinstallConfig=file:///usr/local/tomcat/conf/Standalone/localhost/testServlets.xmlinstallWar=file:///tmp/testServlets.war When I test my servlet, ALMOST ALL IS FINE : getServletContext().getInitParameter(PROJECT_NAME) = testServlets ((DataSource)ctx.lookup(java:/comp/env/jdbc/testServletsDB)).getConnection() works getServletContext().getResource(/META-INF/my_internal_resources.properties) is valid BUT - getServletContext().getRealPath(/) = null - the war is unpacked in $CATALINA_HOME/work/Standalone/localhost/testsServlet/ (not in Context_docBase or Host_appBase) and is INCOMPLETE !!! (only WEB-INF directory but not my static files) So, If I want Apache to serve this static files,... how to ? In advance, thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Disadvantages to using unpackWARs=false?
Does anyone know if there are disadvantages to setting unpackWARs=false? What I'm wondering is if it then has to uncompress the .war file everytime a resource is accessed thus causing a performance hit? Jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Disadvantages to using unpackWARs=false?
Hi, Does anyone know if there are disadvantages to setting unpackWARs=false? What I'm wondering is if it then has to uncompress the .war file everytime a resource is accessed thus causing a performance hit? We don't uncompress the file on every resource request ;) That'd be fairly awful design. In fact, even with unpackWARs set to true, the WAR may still be unpacked by Tomcat *in its work directory* for internal use. It just means it won't be unpacked in the webapps directory, and therefore redeployment is easier. Yoav Shapira http://www.yoavshapira.com This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Disadvantages to using unpackWARs=false?
OK, thanks for the info. Like you mentioned, I was thinking that redeployment would be easier with it set to false. I just wanted to make sure that I wouldn't be incurring a performance hit and the expense of not having to mess around with an extra directory. Thanks. Jon - Original Message - From: Shapira, Yoav [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Thursday, November 18, 2004 11:08 AM Subject: RE: Disadvantages to using unpackWARs=false? Hi, Does anyone know if there are disadvantages to setting unpackWARs=false? What I'm wondering is if it then has to uncompress the .war file everytime a resource is accessed thus causing a performance hit? We don't uncompress the file on every resource request ;) That'd be fairly awful design. In fact, even with unpackWARs set to true, the WAR may still be unpacked by Tomcat *in its work directory* for internal use. It just means it won't be unpacked in the webapps directory, and therefore redeployment is easier. Yoav Shapira http://www.yoavshapira.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
unpackWARs=false = hot unzip for static resources
Hello ! I would like to have confirmation for this topic : Says a XML context file myapp.xml like this : Context docBase=C:\app.war path=/agoodapp reloadable=false privileged=false/ and unpackWARs set to false in Host tag and server.xml file. What does happen when the client call static resource (like HTML file) ? Is there an unzip call each time ? or something else (files stored in temp dir) ? Thanks, Arnaud
Re: unpackWARs=false = hot unzip for static resources
From what I have seen, everything gets unpacked anyway...just into the work directory instead of the webapps directory (with my version of tomcat - 4.1.29). Larry [EMAIL PROTECTED] 10/12/04 3:54 AM Hello ! I would like to have confirmation for this topic : Says a XML context file myapp.xml like this : Context docBase=C:\app.war path=/agoodapp reloadable=false privileged=false/ and unpackWARs set to false in Host tag and server.xml file. What does happen when the client call static resource (like HTML file) ? Is there an unzip call each time ? or something else (files stored in temp dir) ? Thanks, Arnaud - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Does unpackWARs setting work?
OK, here is my config: Host name=localhost debug=0 appBase=webapps unpackWARs=false autoDeploy=false Context path=/ngts reloadable=false docBase=/tmp/ngts/ngts/dist/ngts.war debug=0 / /Host When I start tomcat, I see everything unpacked into my work directory. What's up with that? Am I missing something here? Does unpackWARs=false mean something else? Larry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: unpackWARs and autoDeploy
And what is the difference then when I set unpackWARs=true? TIA, Gerardo On Mon, 23 Aug 2004, Donie Kelly wrote: How then does it do it when you set unpackWARs=false? It doesn't do it at all. You have to do it manually... Donie -Original Message- From: Anthony Colebourne [mailto:[EMAIL PROTECTED] Sent: 23 August 2004 10:58 To: [EMAIL PROTECTED] Subject: unpackWARs and autoDeploy Hi, How does Tomcat determine when to reload the app (using autoDeploy)? It appears to compare the time stamp on the war with the time stamp of the expanded directory. How then does it do it when you set unpackWARs=false? Thanks, Anthony. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
unpackWARs and autoDeploy
Hi, How does Tomcat determine when to reload the app (using autoDeploy)? It appears to compare the time stamp on the war with the time stamp of the expanded directory. How then does it do it when you set unpackWARs=false? Thanks, Anthony. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: unpackWARs and autoDeploy
How then does it do it when you set unpackWARs=false? It doesn't do it at all. You have to do it manually... Donie -Original Message- From: Anthony Colebourne [mailto:[EMAIL PROTECTED] Sent: 23 August 2004 10:58 To: [EMAIL PROTECTED] Subject: unpackWARs and autoDeploy Hi, How does Tomcat determine when to reload the app (using autoDeploy)? It appears to compare the time stamp on the war with the time stamp of the expanded directory. How then does it do it when you set unpackWARs=false? Thanks, Anthony. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: unpackWARs and autoDeploy
Hi, From looking at the documentation further it seems that if you have unpackWARs=false with autoDeploy=true then any new WARs will just get redeployed. See below. However I have not found this to be true! Perhaps this is a bug? Also if you update the context file in $CATALINA_HOME/conf/[enginename]/[hostname]/foo.xml the application is supposed to get redeployed (I have not tested this). Is there an internal Tomcat 'memory' that remembers the last timestamp on the files? As my initial thoughts about it comparing the timestamps of the war and the expanded war seem to be incorrect. --Doc--- Redeployment of a web application which has been deployed from a WAR when the WAR is updated: the expanded web application is removed, and the WAR is expanded again. This will not happen if the host is configured so that WARs are not expanded, in which case the webapp will be simply redeployed ---End Doc--- Thanks, Anthony. From: Donie Kelly How then does it do it when you set unpackWARs=false? It doesn't do it at all. You have to do it manually... Donie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5: default unpackWARs bahaviour?
Hi, I have war file to be deployed at /webapps. However, if i don't have a ending / at the end of docBase and path, it does not expand. So, one of the admins puts / at the end of docBase and path attriubtes in the Context, it starts to expand, however, it has been creating another problems. I am guessing it might be relate to xml parser issue. If anybody has the same problems and can share the thought and solutions, I would appreciate it very much. thanks, - Original Message - From: Shapira, Yoav [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Friday, May 28, 2004 8:54 AM Subject: RE: Tomcat 5: default unpackWARs bahaviour? Hi, Don't rely on a default value for unpackWARs: put it in your instructions that it must be true, because that's a place where your webapp deviates from the Servlet Specification (which only requires containers to support packed WARs). Yoav Shapira Millennium Research Informatics -Original Message- From: Simon Brooke [mailto:[EMAIL PROTECTED] Sent: Friday, May 28, 2004 6:28 AM To: 'Tomcat Users List' Subject: Tomcat 5: default unpackWARs bahaviour? -BEGIN PGP SIGNED MESSAGE- I'm busy writing installation instructions for a webapp, and I've just had my first draft sent back to me as 'much too technical and complex'. For the webapp to work, I need 'unpackWARs' to be true in the server.xml file. A lot of Tomcat 4 distributions I've seen (including the Debian one, which I mostly use) come with 'unpackWARs' false. In the 5.0.24 binary tarball I've downloaded from jakarta.apache.org unpackWARs is true. Is this policy? Can I rely on unpackWARs being true in Tomcat 5 distributions downloaded from jakarta.apache.org? If so it makes my installation instructions much simpler. Cheers Simon - -- [EMAIL PROTECTED] (Simon Brooke) http://www.jasmine.org.uk/~simon/ Tony Blair's epitaph, #1: Here lies Tony Blair. Tony Blair's epitaph, #2: Trust me. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: noconv iQCVAwUBQLcUO3r1UrYJMbiJAQFugQQAkgVMzf5onkPS/CUThcCXqEQnj3HdXVBZ QSq6gD0DUt8/wwWkVCbcFEU6nCE7884KzTXc3JDLd58G1qcP7lPwfnTon5eR8Zzr TF0vBzuPto2bJDCXGrBttOWFuNco1YFfMTu3wJYRSAJkyYBfmoX0LHEWR5s9fNfC tyhtCVnH2a8= =LGgP -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat 5: default unpackWARs bahaviour?
-BEGIN PGP SIGNED MESSAGE- I'm busy writing installation instructions for a webapp, and I've just had my first draft sent back to me as 'much too technical and complex'. For the webapp to work, I need 'unpackWARs' to be true in the server.xml file. A lot of Tomcat 4 distributions I've seen (including the Debian one, which I mostly use) come with 'unpackWARs' false. In the 5.0.24 binary tarball I've downloaded from jakarta.apache.org unpackWARs is true. Is this policy? Can I rely on unpackWARs being true in Tomcat 5 distributions downloaded from jakarta.apache.org? If so it makes my installation instructions much simpler. Cheers Simon - -- [EMAIL PROTECTED] (Simon Brooke) http://www.jasmine.org.uk/~simon/ Tony Blair's epitaph, #1: Here lies Tony Blair. Tony Blair's epitaph, #2: Trust me. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: noconv iQCVAwUBQLcUO3r1UrYJMbiJAQFugQQAkgVMzf5onkPS/CUThcCXqEQnj3HdXVBZ QSq6gD0DUt8/wwWkVCbcFEU6nCE7884KzTXc3JDLd58G1qcP7lPwfnTon5eR8Zzr TF0vBzuPto2bJDCXGrBttOWFuNco1YFfMTu3wJYRSAJkyYBfmoX0LHEWR5s9fNfC tyhtCVnH2a8= =LGgP -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 5: default unpackWARs bahaviour?
Hi, Don't rely on a default value for unpackWARs: put it in your instructions that it must be true, because that's a place where your webapp deviates from the Servlet Specification (which only requires containers to support packed WARs). Yoav Shapira Millennium Research Informatics -Original Message- From: Simon Brooke [mailto:[EMAIL PROTECTED] Sent: Friday, May 28, 2004 6:28 AM To: 'Tomcat Users List' Subject: Tomcat 5: default unpackWARs bahaviour? -BEGIN PGP SIGNED MESSAGE- I'm busy writing installation instructions for a webapp, and I've just had my first draft sent back to me as 'much too technical and complex'. For the webapp to work, I need 'unpackWARs' to be true in the server.xml file. A lot of Tomcat 4 distributions I've seen (including the Debian one, which I mostly use) come with 'unpackWARs' false. In the 5.0.24 binary tarball I've downloaded from jakarta.apache.org unpackWARs is true. Is this policy? Can I rely on unpackWARs being true in Tomcat 5 distributions downloaded from jakarta.apache.org? If so it makes my installation instructions much simpler. Cheers Simon - -- [EMAIL PROTECTED] (Simon Brooke) http://www.jasmine.org.uk/~simon/ Tony Blair's epitaph, #1: Here lies Tony Blair. Tony Blair's epitaph, #2: Trust me. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: noconv iQCVAwUBQLcUO3r1UrYJMbiJAQFugQQAkgVMzf5onkPS/CUThcCXqEQnj3HdXVBZ QSq6gD0DUt8/wwWkVCbcFEU6nCE7884KzTXc3JDLd58G1qcP7lPwfnTon5eR8Zzr TF0vBzuPto2bJDCXGrBttOWFuNco1YFfMTu3wJYRSAJkyYBfmoX0LHEWR5s9fNfC tyhtCVnH2a8= =LGgP -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 5: default unpackWARs bahaviour?
' format. alright, back to real work. -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Friday, May 28, 2004 7:55 AM To: Tomcat Users List Subject: RE: Tomcat 5: default unpackWARs bahaviour? Hi, Don't rely on a default value for unpackWARs: put it in your instructions that it must be true, because that's a place where your webapp deviates from the Servlet Specification (which only requires containers to support packed WARs). Yoav Shapira Millennium Research Informatics - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 5: default unpackWARs bahaviour?
Hi,
In short:
- Yes some of the spec parts use weak wording, e.g. may, take that up
with the spec JSR group (there's contact info on the JSR web page)
- It's clear that supporting a packed WAR is required
- It's clear that supporting open file system structure is optional
- No one is saying open file system support is forbidden, but it's
clearly not required, and therefore developers can't count on it being
available
- I don't know what server you had in mind that blew up a war and broke
it apart, but I do know that some Oracle servlet containers in the past
put the WAR in the database, and a filesystem was not available at all:
this is often cited as a compliant server that does not allow for
exploded WAR deployment.
Yoav Shapira
Millennium Research Informatics
-Original Message-
From: Mike Curwen [mailto:[EMAIL PROTECTED]
Sent: Friday, May 28, 2004 11:58 AM
To: 'Tomcat Users List'
Subject: RE: Tomcat 5: default unpackWARs bahaviour?
Please forgive this email. It's a self-improvement exercise. I didn't
take logic in University, so I'm genuinely asking the questions below.
I'm not being sarcastic ;) Only bother reading this if you're on
lunch,
and care to take a bit of a thought exercise.
I cannot find a single place in the spec (2.3 and 2.4) that states
unequivocaly that containers are only required to support archived
applications. (for interest, I used 'find' in acrobat on both versions,
to find 'WAR', 'archive' and 'required'). There's at least one place
that *might* be used to infer this, but I would disagree, which I
outline below. So before it all starts, can anyone point me to the
line
in the spec that states, in other language, and unequivaocaly, that a
servlet container is only required to support archived applications?
Some prelude:
From the glossary in the spec:
[b]web application[/b]
A collection of servlets, JSP pages , HTML documents, and
other web resources which might include image files, compressed
archives,
and other data. A web application may be packaged into an archive or
exist in
an open directory structure.
There's that word weak word, 'may'. So can we infer that if it MAY be A
and it MAY be B, that both A and B are *required* to be supported? Can
we infer that they *ought* to be supported? (is that middle ground even
possible; ie: if it only *ought* to support B, can you strongly say
that
B is even an option?)
SRV.3.5
SRV.4.5
Both contain similar weak language in regards to archived/open files
(may)
Then, in later sections (numerous) it starts to talk about things
(filters, classes, etc) that get packaged into the WAR or in the
WAR. The spec starts to adopt the assumption that your app is
archived.
But mainly, there's this in SRV.9.4, which I think is where people
infer
that containers need only support archives:
This specification defines a hierarchical structure used for
deployment
and
packaging purposes that can exist in an open file system, in an archive
file, or in
some other form. It is recommended, but not required, that servlet
containers
support this structure as a runtime representation.
1 An application can be in an open file system
2 An application can be in an archive file
3 An application can be in another form
4 A container is not required to support open file system.
5 A container is not required to support another form.
6 Therefore, a container is only required to support archive file.
First of all, both #4 and #5 are not (in my mind) spelled out by the
text of the spec I quoted. But lets assume they are. Is 6 then, a valid
inference? Because with one interpretation of the above paragraph, #6
must be a valid inference, and can therefore be used to assert that
containers must only support packed applications. 'cause like I said, I
can't find the line that says Containers are only required to support
archived web applications.
But here's how I have always read this paragraph, and please tell me
how
this is wrong.
This specification defines a [[hierarchical structure]] used for
deployment and
packaging purposes that can exist {in an open file system}, {in an
archive file}, or {in
some other form}. It is recommended, but not required, that servlet
containers
support [[this structure]] as a runtime representation.
So the [[ ]] are the matching elements. Containers should, but are not
required, to use the [[structure]] as a run-time representation. It
doesn't say anything regarding recommend/require about any of the
{representation choices}.
I'm trying to remember which one it was.. but back in the day, wasn't
there an app server (iPlanet maybe?) that would take a WAR file, and
then explode it all to hell, moving files here and there, classes over
here, etc, etc, and of course, the runtime representation didn't look
anything like the [[structure]]. I think that's what this paragraph is
talking about. A container is free to do whatever it wants, at runtime.
It is recommended that its runtime representation be the [[structure
Can .WAR files be compressed if unpackWARs=false?
hello, Just a quickie. Is there any problem with serving from a compressed .war file? I have been having problems which I cannot explain and have just realised that since using ANT I have been inadvertently compressing my .war file. I cannot find anything to say that this is a problem but have come across errors in the core dump with came from the use of zip classes. Anyway, anybody any similar experiences? Tomcat 4.0.4 Java 1.3.1 Andoni.
can I run an app. from a *compressed* .war file with unpackWARs=false ?
hello, Just a quickie. Is there any problem with serving from a compressed .war file? I have been having problems which I cannot explain and have just realised that since using ANT I have been inadvertently compressing my .war file. I cannot find anything to say that this is a problem but have come across errors in the core dump with came from the use of zip classes. Anyway, anybody any similar experiences? Tomcat 4.0.4 Java 1.3.1 Andoni.
RE: unpackWars
Howdy, One way that I know that seems to work with Tomcat is to call getServletContext().getRealPath() If it returns null, that means you are running as a WAR file. I'm not sure how reliable this is. Seems to be fine from what I've seen. This is more or less reliable. The original question is skewed at best, however, as a webapp is not supposed to know whether it's packed or not and certainly not supposed to run differently depending on whether it's packed or not. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: unpackWars
I noticed that getRealPath returns null when running packed. This makes sense because there is no real path; it's running from within the war. I didn't want to corrupt any responses with this. I also wanted to make sure this is reliable. Sounds as if it is. Thanks, Derrick -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2003 3:48 PM To: Tomcat Users List Subject: RE: unpackWars Howdy, One way that I know that seems to work with Tomcat is to call getServletContext().getRealPath() If it returns null, that means you are running as a WAR file. I'm not sure how reliable this is. Seems to be fine from what I've seen. This is more or less reliable. The original question is skewed at best, however, as a webapp is not supposed to know whether it's packed or not and certainly not supposed to run differently depending on whether it's packed or not. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This electronic transmission is strictly confidential to Smith Nephew and intended solely for the addressee. It may contain information which is covered by legal, professional or other privilege. If you are not the intended addressee, or someone authorized by the intended addressee to receive transmissions on behalf of the addressee, you must not retain, disclose in any form, copy or take any action in reliance on this transmission. If you have received this transmission in error, please notify the sender as soon as possible and destroy this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
unpackWars
Is there any way to query tomcat from my web app at runtime to find out whether it's running my web app as packed or unpacked? I wish to do some things differently for development purposes if running unpacked. I set unpackWARs in the Host element in the server.xml configuration file. Thanks, Derrick This electronic transmission is strictly confidential to Smith Nephew and intended solely for the addressee. It may contain information which is covered by legal, professional or other privilege. If you are not the intended addressee, or someone authorized by the intended addressee to receive transmissions on behalf of the addressee, you must not retain, disclose in any form, copy or take any action in reliance on this transmission. If you have received this transmission in error, please notify the sender as soon as possible and destroy this message.
Re: unpackWars
One way that I know that seems to work with Tomcat is to call getServletContext().getRealPath() If it returns null, that means you are running as a WAR file. I'm not sure how reliable this is. Seems to be fine from what I've seen. Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., The Leading Provider of Net Business Solutions http://www.novell.com [EMAIL PROTECTED] 8/6/03 1:38:39 PM Is there any way to query tomcat from my web app at runtime to find out whether it's running my web app as packed or unpacked? I wish to do some things differently for development purposes if running unpacked. I set unpackWARs in the Host element in the server.xml configuration file. Thanks, Derrick This electronic transmission is strictly confidential to Smith Nephew and intended solely for the addressee. It may contain information which is covered by legal, professional or other privilege. If you are not the intended addressee, or someone authorized by the intended addressee to receive transmissions on behalf of the addressee, you must not retain, disclose in any form, copy or take any action in reliance on this transmission. If you have received this transmission in error, please notify the sender as soon as possible and destroy this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Apache + Tomcat+4.0.6 (unpackWARs not decompress)
Hello, I work with Apache + Tomcat 4.0.6 and I want deploy war file. The problem is that when I start Tomcat not decompress File.war and therefore Apache cannot respond static files (*.gif,*.jpg... static files) The option unpackWARs=true is not working??? As it is the problem? Why it does not decompress? Is possible to do this in Tomcat 4.0.x? I have not found any information about this.It is not left but remedy that to decompress by hand? This is part of the configuration in my server.xml: Host name=localhost debug=0 appBase=/opt/app1 unpackWARs=true Valve className=org.apache.catalina.valves.AccessLogValve prefix=access_log. suffix=.txt pattern=common/ Logger className=org.apache.catalina.logger.FileLogger prefix=tomcat_log. suffix=.txt timestamp=true/ Context path=/hs docBase=FILE.war debug=0 privileged=true Listener className=org.apache.ajp.tomcat4.config.ApacheConfig jkConfig=/var/opt/app1/conf/mod_jk.conf workersConfig=/var/opt/app1/conf/workers.properties modJk=/usr/local/lib/apache/mod_jk.so jkLog=/var/opt/app1/logs/mod_jk.log jkDebug=error jkWorker=ajp13 forwardAll=false noRoot=false append=true / Resource name=jdbc/HTT auth=Container type=javax.sql.DataSource / ResourceParams name=jdbc/HTT parameter namefactory/name valueorg.apache.commons.dbcp.BasicDataSourceFactory/value /parameter AND MORE PARAMETERS OF DATASOURCE AND CLOSED TAGS Thanks in advance. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache + Tomcat+4.0.6 (unpackWARs not decompress)
you need to use autoDeploy, http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/host.html#Automatic%20Application%20Deployment At 21:52 15.07.2003 +0200, you wrote: Hello, I work with Apache + Tomcat 4.0.6 and I want deploy war file. The problem is that when I start Tomcat not decompress File.war and therefore Apache cannot respond static files (*.gif,*.jpg... static files) The option unpackWARs=true is not working??? As it is the problem? Why it does not decompress? Is possible to do this in Tomcat 4.0.x? I have not found any information about this.It is not left but remedy that to decompress by hand? This is part of the configuration in my server.xml: Host name=localhost debug=0 appBase=/opt/app1 unpackWARs=true Valve className=org.apache.catalina.valves.AccessLogValve prefix=access_log. suffix=.txt pattern=common/ Logger className=org.apache.catalina.logger.FileLogger prefix=tomcat_log. suffix=.txt timestamp=true/ Context path=/hs docBase=FILE.war debug=0 privileged=true Listener className=org.apache.ajp.tomcat4.config.ApacheConfig jkConfig=/var/opt/app1/conf/mod_jk.conf workersConfig=/var/opt/app1/conf/workers.properties modJk=/usr/local/lib/apache/mod_jk.so jkLog=/var/opt/app1/logs/mod_jk.log jkDebug=error jkWorker=ajp13 forwardAll=false noRoot=false append=true / Resource name=jdbc/HTT auth=Container type=javax.sql.DataSource / ResourceParams name=jdbc/HTT parameter namefactory/name valueorg.apache.commons.dbcp.BasicDataSourceFactory/value /parameter AND MORE PARAMETERS OF DATASOURCE AND CLOSED TAGS Thanks in advance. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
unpackWars not working
The following configuration is not unpacking my war file. I cannot understand why. unpackWARs is set to true. Can anyone help? Host name=localhost debug=0 appBase=webapps unpackWARs=true autoDeploy=true Listener className=org.apache.ajp.tomcat4.config.ApacheConfig append=true forwardAll=false noRoot=false/ !-- Need to set the pathname empty to avoid serializing sessions when tomcat stops. -- Context docBase=dora path=/dora reloadable=true override=true Manager className=org.apache.catalina.session.StandardManager pathname= /Manager /Context Thanks, Derrick This electronic transmission is strictly confidential to Smith Nephew and intended solely for the addressee. It may contain information which is covered by legal, professional or other privilege. If you are not the intended addressee, or someone authorized by the intended addressee to receive transmissions on behalf of the addressee, you must not retain, disclose in any form, copy or take any action in reliance on this transmission. If you have received this transmission in error, please notify the sender as soon as possible and destroy this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: unpackWars not working
could it be that it is not unpacking the war for the context that is already defined? hence it would overwrite that one maybe, what happens if you set docBase=dora.war would that be sufficient for you? Filip -Original Message- From: Koes, Derrick [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 26, 2003 4:08 PM To: [EMAIL PROTECTED] Subject: unpackWars not working The following configuration is not unpacking my war file. I cannot understand why. unpackWARs is set to true. Can anyone help? Host name=localhost debug=0 appBase=webapps unpackWARs=true autoDeploy=true Listener className=org.apache.ajp.tomcat4.config.ApacheConfig append=true forwardAll=false noRoot=false/ !-- Need to set the pathname empty to avoid serializing sessions when tomcat stops. -- Context docBase=dora path=/dora reloadable=true override=true Manager className=org.apache.catalina.session.StandardManager pathname= /Manager /Context Thanks, Derrick This electronic transmission is strictly confidential to Smith Nephew and intended solely for the addressee. It may contain information which is covered by legal, professional or other privilege. If you are not the intended addressee, or someone authorized by the intended addressee to receive transmissions on behalf of the addressee, you must not retain, disclose in any form, copy or take any action in reliance on this transmission. If you have received this transmission in error, please notify the sender as soon as possible and destroy this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: unpackWars not working
It would except that parts of my app depend on the war file being expanded. -Original Message- From: Filip Hanik [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 26, 2003 7:11 PM To: Tomcat Users List Subject: RE: unpackWars not working could it be that it is not unpacking the war for the context that is already defined? hence it would overwrite that one maybe, what happens if you set docBase=dora.war would that be sufficient for you? Filip -Original Message- From: Koes, Derrick [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 26, 2003 4:08 PM To: [EMAIL PROTECTED] Subject: unpackWars not working The following configuration is not unpacking my war file. I cannot understand why. unpackWARs is set to true. Can anyone help? Host name=localhost debug=0 appBase=webapps unpackWARs=true autoDeploy=true Listener className=org.apache.ajp.tomcat4.config.ApacheConfig append=true forwardAll=false noRoot=false/ !-- Need to set the pathname empty to avoid serializing sessions when tomcat stops. -- Context docBase=dora path=/dora reloadable=true override=true Manager className=org.apache.catalina.session.StandardManager pathname= /Manager /Context Thanks, Derrick This electronic transmission is strictly confidential to Smith Nephew and intended solely for the addressee. It may contain information which is covered by legal, professional or other privilege. If you are not the intended addressee, or someone authorized by the intended addressee to receive transmissions on behalf of the addressee, you must not retain, disclose in any form, copy or take any action in reliance on this transmission. If you have received this transmission in error, please notify the sender as soon as possible and destroy this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This electronic transmission is strictly confidential to Smith Nephew and intended solely for the addressee. It may contain information which is covered by legal, professional or other privilege. If you are not the intended addressee, or someone authorized by the intended addressee to receive transmissions on behalf of the addressee, you must not retain, disclose in any form, copy or take any action in reliance on this transmission. If you have received this transmission in error, please notify the sender as soon as possible and destroy this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: unpackWars not working
There is no other context other than the Default Context. -Original Message- From: Koes, Derrick Sent: Wednesday, March 26, 2003 7:15 PM To: 'Tomcat Users List' Subject: RE: unpackWars not working It would except that parts of my app depend on the war file being expanded. -Original Message- From: Filip Hanik [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 26, 2003 7:11 PM To: Tomcat Users List Subject: RE: unpackWars not working could it be that it is not unpacking the war for the context that is already defined? hence it would overwrite that one maybe, what happens if you set docBase=dora.war would that be sufficient for you? Filip -Original Message- From: Koes, Derrick [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 26, 2003 4:08 PM To: [EMAIL PROTECTED] Subject: unpackWars not working The following configuration is not unpacking my war file. I cannot understand why. unpackWARs is set to true. Can anyone help? Host name=localhost debug=0 appBase=webapps unpackWARs=true autoDeploy=true Listener className=org.apache.ajp.tomcat4.config.ApacheConfig append=true forwardAll=false noRoot=false/ !-- Need to set the pathname empty to avoid serializing sessions when tomcat stops. -- Context docBase=dora path=/dora reloadable=true override=true Manager className=org.apache.catalina.session.StandardManager pathname= /Manager /Context Thanks, Derrick This electronic transmission is strictly confidential to Smith Nephew and intended solely for the addressee. It may contain information which is covered by legal, professional or other privilege. If you are not the intended addressee, or someone authorized by the intended addressee to receive transmissions on behalf of the addressee, you must not retain, disclose in any form, copy or take any action in reliance on this transmission. If you have received this transmission in error, please notify the sender as soon as possible and destroy this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This electronic transmission is strictly confidential to Smith Nephew and intended solely for the addressee. It may contain information which is covered by legal, professional or other privilege. If you are not the intended addressee, or someone authorized by the intended addressee to receive transmissions on behalf of the addressee, you must not retain, disclose in any form, copy or take any action in reliance on this transmission. If you have received this transmission in error, please notify the sender as soon as possible and destroy this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This electronic transmission is strictly confidential to Smith Nephew and intended solely for the addressee. It may contain information which is covered by legal, professional or other privilege. If you are not the intended addressee, or someone authorized by the intended addressee to receive transmissions on behalf of the addressee, you must not retain, disclose in any form, copy or take any action in reliance on this transmission. If you have received this transmission in error, please notify the sender as soon as possible and destroy this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: unpackWars not working
OK, I see this is a known issue. H. I believe tomcat should first unpack the wars, THEN determine if docBase is valid. At any rate, it seems I have to design around this feature or submit a patch. -Original Message- From: Koes, Derrick Sent: Wednesday, March 26, 2003 7:17 PM To: 'Tomcat Users List' Subject: RE: unpackWars not working There is no other context other than the Default Context. -Original Message- From: Koes, Derrick Sent: Wednesday, March 26, 2003 7:15 PM To: 'Tomcat Users List' Subject: RE: unpackWars not working It would except that parts of my app depend on the war file being expanded. -Original Message- From: Filip Hanik [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 26, 2003 7:11 PM To: Tomcat Users List Subject: RE: unpackWars not working could it be that it is not unpacking the war for the context that is already defined? hence it would overwrite that one maybe, what happens if you set docBase=dora.war would that be sufficient for you? Filip -Original Message- From: Koes, Derrick [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 26, 2003 4:08 PM To: [EMAIL PROTECTED] Subject: unpackWars not working The following configuration is not unpacking my war file. I cannot understand why. unpackWARs is set to true. Can anyone help? Host name=localhost debug=0 appBase=webapps unpackWARs=true autoDeploy=true Listener className=org.apache.ajp.tomcat4.config.ApacheConfig append=true forwardAll=false noRoot=false/ !-- Need to set the pathname empty to avoid serializing sessions when tomcat stops. -- Context docBase=dora path=/dora reloadable=true override=true Manager className=org.apache.catalina.session.StandardManager pathname= /Manager /Context Thanks, Derrick This electronic transmission is strictly confidential to Smith Nephew and intended solely for the addressee. It may contain information which is covered by legal, professional or other privilege. If you are not the intended addressee, or someone authorized by the intended addressee to receive transmissions on behalf of the addressee, you must not retain, disclose in any form, copy or take any action in reliance on this transmission. If you have received this transmission in error, please notify the sender as soon as possible and destroy this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This electronic transmission is strictly confidential to Smith Nephew and intended solely for the addressee. It may contain information which is covered by legal, professional or other privilege. If you are not the intended addressee, or someone authorized by the intended addressee to receive transmissions on behalf of the addressee, you must not retain, disclose in any form, copy or take any action in reliance on this transmission. If you have received this transmission in error, please notify the sender as soon as possible and destroy this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This electronic transmission is strictly confidential to Smith Nephew and intended solely for the addressee. It may contain information which is covered by legal, professional or other privilege. If you are not the intended addressee, or someone authorized by the intended addressee to receive transmissions on behalf of the addressee, you must not retain, disclose in any form, copy or take any action in reliance on this transmission. If you have received this transmission in error, please notify the sender as soon as possible and destroy this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This electronic transmission is strictly confidential to Smith Nephew and intended solely for the addressee. It may contain information which is covered by legal, professional or other privilege. If you are not the intended addressee, or someone authorized by the intended addressee to receive transmissions on behalf of the addressee, you must not retain, disclose in any form, copy or take any action in reliance on this transmission. If you have received this transmission in error, please notify the sender as soon as possible and destroy this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: unpackWars not working
I guess the other option would be to muck with the startup files to delete sessions before starting up. Hm. -Original Message- From: Koes, Derrick Sent: Wednesday, March 26, 2003 7:36 PM To: 'Tomcat Users List' Subject: RE: unpackWars not working OK, I see this is a known issue. H. I believe tomcat should first unpack the wars, THEN determine if docBase is valid. At any rate, it seems I have to design around this feature or submit a patch. -Original Message- From: Koes, Derrick Sent: Wednesday, March 26, 2003 7:17 PM To: 'Tomcat Users List' Subject: RE: unpackWars not working There is no other context other than the Default Context. -Original Message- From: Koes, Derrick Sent: Wednesday, March 26, 2003 7:15 PM To: 'Tomcat Users List' Subject: RE: unpackWars not working It would except that parts of my app depend on the war file being expanded. -Original Message- From: Filip Hanik [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 26, 2003 7:11 PM To: Tomcat Users List Subject: RE: unpackWars not working could it be that it is not unpacking the war for the context that is already defined? hence it would overwrite that one maybe, what happens if you set docBase=dora.war would that be sufficient for you? Filip -Original Message- From: Koes, Derrick [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 26, 2003 4:08 PM To: [EMAIL PROTECTED] Subject: unpackWars not working The following configuration is not unpacking my war file. I cannot understand why. unpackWARs is set to true. Can anyone help? Host name=localhost debug=0 appBase=webapps unpackWARs=true autoDeploy=true Listener className=org.apache.ajp.tomcat4.config.ApacheConfig append=true forwardAll=false noRoot=false/ !-- Need to set the pathname empty to avoid serializing sessions when tomcat stops. -- Context docBase=dora path=/dora reloadable=true override=true Manager className=org.apache.catalina.session.StandardManager pathname= /Manager /Context Thanks, Derrick This electronic transmission is strictly confidential to Smith Nephew and intended solely for the addressee. It may contain information which is covered by legal, professional or other privilege. If you are not the intended addressee, or someone authorized by the intended addressee to receive transmissions on behalf of the addressee, you must not retain, disclose in any form, copy or take any action in reliance on this transmission. If you have received this transmission in error, please notify the sender as soon as possible and destroy this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This electronic transmission is strictly confidential to Smith Nephew and intended solely for the addressee. It may contain information which is covered by legal, professional or other privilege. If you are not the intended addressee, or someone authorized by the intended addressee to receive transmissions on behalf of the addressee, you must not retain, disclose in any form, copy or take any action in reliance on this transmission. If you have received this transmission in error, please notify the sender as soon as possible and destroy this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This electronic transmission is strictly confidential to Smith Nephew and intended solely for the addressee. It may contain information which is covered by legal, professional or other privilege. If you are not the intended addressee, or someone authorized by the intended addressee to receive transmissions on behalf of the addressee, you must not retain, disclose in any form, copy or take any action in reliance on this transmission. If you have received this transmission in error, please notify the sender as soon as possible and destroy this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This electronic transmission is strictly confidential to Smith Nephew and intended solely for the addressee. It may contain information which is covered by legal, professional or other privilege. If you are not the intended addressee, or someone authorized by the intended addressee to receive transmissions on behalf of the addressee, you must not retain, disclose in any form, copy or take any action in reliance on this transmission. If you have received this transmission
setting unpackWars=false
This afternoon I began to look at running some of our WAR files in Tomcat (4.0.4) without unpacking them. I set the unpackWars=false in server.xml. This seems pretty straightforward, although there appear to be some issues. None of the application that I try to run this way work now. These applications do work if I set unpackWars=true. An example is Cocoon. When I try and run Cocoon without unpacking it, I get some errors in Cocoon where it appears unable to find some of the classes it requires. If I look into the work directory, I find that some files have been unpacked there (as I expected), and notice that the classes in question actually do exist in a JAR in the WEB_INF\lib directory (as expected). So, in Cocoon's case, I am unable to compile the sitemap_xmap.java file. So my question is what am I missing? Are there some other configurable options that I should be aware of? What do I need to do to make an application run without unpacking the WAR file? I also noticed that the contents of the work directory are different depending on whether or not unpackWars is true of false. I could see that being expected behavior - but should it be? Thanks for any help. Craig S. Connell -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: setting unpackWars=false
On Mon, 13 Jan 2003, Craig S. Connell wrote: Date: Mon, 13 Jan 2003 13:12:41 -0500 From: Craig S. Connell [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: setting unpackWars=false This afternoon I began to look at running some of our WAR files in Tomcat (4.0.4) without unpacking them. I set the unpackWars=false in server.xml. This seems pretty straightforward, although there appear to be some issues. None of the application that I try to run this way work now. These applications do work if I set unpackWars=true. An example is Cocoon. When I try and run Cocoon without unpacking it, I get some errors in Cocoon where it appears unable to find some of the classes it requires. If I look into the work directory, I find that some files have been unpacked there (as I expected), and notice that the classes in question actually do exist in a JAR in the WEB_INF\lib directory (as expected). So, in Cocoon's case, I am unable to compile the sitemap_xmap.java file. So my question is what am I missing? Are there some other configurable options that I should be aware of? What do I need to do to make an application run without unpacking the WAR file? I also noticed that the contents of the work directory are different depending on whether or not unpackWars is true of false. I could see that being expected behavior - but should it be? The webapp itself has to be written so that it can work inside a WAR. Most commonly, that means using ServletContext.getResource() or ServletContext.getResourceAsStream() instead of file i/o in order to read webapp resources. You also cannot write to resources in a WAR (which I suspect Cocoon probably tries to do). Thanks for any help. Craig S. Connell Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: setting unpackWars=false
Hello Craig, One thing to watch out for when running an app directly from a .war file is that if the application is trying to do any File IO where it tries to load resources existing within the WAR structure, it won't work if the .war is not expanded into a directory. I've noticed various frameworks that ignore this and continue to use File IO. These apps *will* break. See if you are getting any stack traces in Tomcat's log files. You might want to turn Tomcat's debugging level up and check if any of these problems exist. Jake Monday, January 13, 2003, 12:12:41 PM, you wrote: CSC This afternoon I began to look at running some of our WAR files in CSC Tomcat (4.0.4) without unpacking them. I set the unpackWars=false in CSC server.xml. CSC This seems pretty straightforward, although there appear to be some CSC issues. None of the application that I try to run this way work now. CSC These applications do work if I set unpackWars=true. CSC An example is Cocoon. When I try and run Cocoon without unpacking it, I CSC get some errors in Cocoon where it appears unable to find some of the CSC classes it requires. If I look into the work directory, I find that CSC some files have been unpacked there (as I expected), and notice that the CSC classes in question actually do exist in a JAR in the WEB_INF\lib CSC directory (as expected). So, in Cocoon's case, I am unable to compile CSC the sitemap_xmap.java file. CSC So my question is what am I missing? Are there some other CSC configurable options that I should be aware of? What do I need to do to CSC make an application run without unpacking the WAR file? I also noticed CSC that the contents of the work directory are different depending on CSC whether or not unpackWars is true of false. I could see that being CSC expected behavior - but should it be? CSC Thanks for any help. CSC Craig S. Connell CSC -- CSC To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] CSC For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Best regards, Jacobmailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
unpackWARs=false?
Has anybody been able to deploy .war files with this set? unpackWARs=false If so can you post a mocked up part of your server.xml and directory structure please. Andoni. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: unpackWARs=false?
Hi, If you set this property, that's (almost) all you have to do. You don't need to add anything else to a standard server.xml, all you do is drop the .war file into Tomcat's /webapps folder. Check the logs generated by Tomcat if you can't get any further... - Chris - Original Message - From: Andoni [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Tuesday, December 17, 2002 11:14 AM Subject: unpackWARs=false? Has anybody been able to deploy .war files with this set? unpackWARs=false If so can you post a mocked up part of your server.xml and directory structure please. Andoni. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Tomcat 4.1.12 unpackWARs
I found some hint of this in past archives, and am wondering if this is a bug or if I am missing something. The following will not unpack a .war file existing in the appBase directory. Tomcat processes will start and then quickly die because according to the log messages generated, the docBase directory doesn't (yet) exist, which is true since the .war didn't first expand: Engine className=org.apache.catalina.connector.warp.WarpEngine defaultHost=localhost name=Tomcat-Apache Engine debug=0 Host name=localhost debug=9 appBase=webapps autoDeploy=true unpackWARs=true Realm className=org.apache.catalina.realm.MemoryRealm / Context path=/testapp docBase=testapp reloadable=true privileged=true debug=1 / /Host /Engine It will unpack correctly if no context is specified, and it will work as shown above if the docBase directory is already unpacked. This will also work if I set unpackWARs to false, and the docBase to the war file, but I really need the war to be expanded in this case. Is there a work-around for this behavior, other than manually unpacking? My environment is SuSE Linux 8.0, Apache 1.3.26, Tomcat 4.1.12. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 4.1.12 unpackWARs
This is intended behavior based on Tomcat's documentation. There is a bug on this. Don't have the bug number handy. Search http://nagoya.apache.org/bugzilla/ and search for it. I'm not sure I agree with the behavior either, but that's the way it is for now. Jake At 05:23 PM 10/9/2002 -0500, you wrote: I found some hint of this in past archives, and am wondering if this is a bug or if I am missing something. The following will not unpack a .war file existing in the appBase directory. Tomcat processes will start and then quickly die because according to the log messages generated, the docBase directory doesn't (yet) exist, which is true since the .war didn't first expand: Engine className=org.apache.catalina.connector.warp.WarpEngine defaultHost=localhost name=Tomcat-Apache Engine debug=0 Host name=localhost debug=9 appBase=webapps autoDeploy=true unpackWARs=true Realm className=org.apache.catalina.realm.MemoryRealm / Context path=/testapp docBase=testapp reloadable=true privileged=true debug=1 / /Host /Engine It will unpack correctly if no context is specified, and it will work as shown above if the docBase directory is already unpacked. This will also work if I set unpackWARs to false, and the docBase to the war file, but I really need the war to be expanded in this case. Is there a work-around for this behavior, other than manually unpacking? My environment is SuSE Linux 8.0, Apache 1.3.26, Tomcat 4.1.12. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
unpackWars performance/advantages/disadvantages?
Great, thanks for the response. I'd like to know if anyone has experience with deploying war files and then setting unpackWARs to false. Is there any advantage/disadvantage to doing this? Why would one want to? How does this affect performance? Any reasons for choosing one over the other? Thanks Dennis On Thu, 2002-09-12 at 14:11, Nome real wrote: That's the new behaviour for 4.1.x. See the RELEASE-NOTES. On 12 Sep 2002 08:12:34 -0600, Dennis Muhlestein [EMAIL PROTECTED] escreveu : De: Dennis Muhlestein [EMAIL PROTECTED] Data: 12 Sep 2002 08:12:34 -0600 Para: [EMAIL PROTECTED] Assunto: Tomcat 4.1.10 and symbolic links (linux) I've found many references to this problem on the list and in mail archives but none had to do with my situation and I don't know how to fix this. Because we have used other web containers in the past, our WEB-INF folder is not located in the root of the webapp. We have a symbolic link. The directory structure looks like this. ROOT/ ROOT/docs (jsp images etc) ROOT/WEB-INF/ ROOT/classes/ ROOT/jars There are sym links to make this work with tomcat. ROOT/docs/WEB-INF- ../WEB-INF ROOT/WEB-INF/classes- ../classes ROOT/WEB-INF/lib- ../jars This all worked fine with tomcat 4.0.4 but now with 4.1.10 I can't get it to recognize the web.xml I get the following: ContextConfig[]: Missing application web.xml, using defaults only If I remove the sym links and copy the data to the correct location, things start up, the web.xml is found. Is it just symbolic links in general or is there something I'm missing. Thanks for any input. -Dennis -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
unpackwars-true ??
Hi, Im using tomcat 4.0.2. Im use the defualt Host ... tag in my server.xml for my app contexts, always been fine till I needed to have one unpack wars automagically. Host name=localhost debug=0 appBase=webapps unpackWARs=true Now, I place a war file in the default webapps folder, and as id expect, it is unpacked. However, it is not unpacked in the context which i create !.. all other things appear to work fine. this is the context : Context path=/struts docBase=d:\webcontainer\struts debug=0/ The only difference is that this sites in a totally different place to the applications base specified in the Host tag. Im pretty sure it should still work though, everything else is fine.. Any help would be much appreciated. Thanks Mehdi Nejad - Senior Developer [EMAIL PROTECTED] ~~ Bluewave Ltd - Online Creations http://www.bluewave.com Tel. +44 (0)20 7706 3500 ~~ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: unpackwars-true ??
Hi, Now, I place a war file in the default webapps folder, and as id expect, it is unpacked. However, it is not unpacked in the context which i create !.. all other things appear to work fine. Does the name of the context, as specified in the context element of server.xml, match the war file name? Also, consider upgrading to 4.0.4 to get the latest bugfixes ;) Should be a trivial move from 4.0.2 to 4.0.4. Yoav Shapira Millennium ChemInformatics -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: unpackwars-true ??
** Does the name of the context, as specified in the context element of server.xml, match the war file name? the answer is no it doesnt, but neither does the example that works in the default webapps folder, i just specified localhost/jarname - and it extracted and worked. I shall upgradeTomcat - your right... Mehdi Shapira, Yoav [EMAIL PROTECTED] 13/08/2002 15:42 Please respond to Tomcat Users List To: Tomcat Users List [EMAIL PROTECTED] cc: Subject:RE: unpackwars-true ?? Hi, Now, I place a war file in the default webapps folder, and as id expect, it is unpacked. However, it is not unpacked in the context which i create !.. all other things appear to work fine. Does the name of the context, as specified in the context element of server.xml, match the war file name? Also, consider upgrading to 4.0.4 to get the latest bugfixes ;) Should be a trivial move from 4.0.2 to 4.0.4. Yoav Shapira Millennium ChemInformatics -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: unpackwars-true ??
Heres a quick turnaround for you ! I upgraded to tomcat 4.0.4. it appears not to have changed my server.xml file, and everything works still, which is nice. Everything appart from unpackwars=true that is :(, my war file is still not unpacking http://localhost/struts/blablabla gives a 404. any more ideas ? Mehdi [EMAIL PROTECTED] 13/08/2002 15:49 Please respond to Tomcat Users List To: Tomcat Users List [EMAIL PROTECTED] cc: Subject:RE: unpackwars-true ?? ** Does the name of the context, as specified in the context element of server.xml, match the war file name? the answer is no it doesnt, but neither does the example that works in the default webapps folder, i just specified localhost/jarname - and it extracted and worked. I shall upgradeTomcat - your right... Mehdi Shapira, Yoav [EMAIL PROTECTED] 13/08/2002 15:42 Please respond to Tomcat Users List To: Tomcat Users List [EMAIL PROTECTED] cc: Subject:RE: unpackwars-true ?? Hi, Now, I place a war file in the default webapps folder, and as id expect, it is unpacked. However, it is not unpacked in the context which i create !.. all other things appear to work fine. Does the name of the context, as specified in the context element of server.xml, match the war file name? Also, consider upgrading to 4.0.4 to get the latest bugfixes ;) Should be a trivial move from 4.0.2 to 4.0.4. Yoav Shapira Millennium ChemInformatics -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re[2]: unpackwars-true ??
Hello Mehdi, This is a known bug/feature. Don't remember which bug in Apache's bug database, but you should either be able to find it by search the list archives or searching the Apache bug database. http://marc.theaimsgroup.com/?l=tomcat-userr=1w=2 http://nagoya.apache.org/bugzilla/index.html I can kind of understand why it doesn't do it automatically since the Context element configuration could point directly to the .war file itself making the unpacking an extra unneeded step. However, I would think that if the docBase attribute points to a directory, Tomcat could look for the referenced directory. If that doesn't exist, it could then look for a .war file of the same name as the referenced directory (minus .war) at the same directory level as would contain the referenced directory and unpack it just like Tomcat normally does when the Context element doesn't exist. Jake Tuesday, August 13, 2002, 10:07:24 AM, you wrote: MNbc Heres a quick turnaround for you ! MNbc I upgraded to tomcat 4.0.4. it appears not to have changed my server.xml MNbc file, and everything works still, which is nice. MNbc Everything appart from unpackwars=true that is :(, my war file is still MNbc not unpacking MNbc http://localhost/struts/blablabla gives a 404. MNbc any more ideas ? MNbc Mehdi MNbc [EMAIL PROTECTED] MNbc 13/08/2002 15:49 MNbc Please respond to Tomcat Users List MNbc To: Tomcat Users List [EMAIL PROTECTED] MNbc cc: MNbc Subject:RE: unpackwars-true ?? MNbc ** Does the name of the context, as specified in the context element of MNbc server.xml, match the war file name? MNbc the answer is no it doesnt, but neither does the example that works in the MNbc default webapps folder, i just specified localhost/jarname - and it MNbc extracted and worked. MNbc I shall upgradeTomcat - your right... MNbc Mehdi MNbc Shapira, Yoav [EMAIL PROTECTED] MNbc 13/08/2002 15:42 MNbc Please respond to Tomcat Users List MNbc To: Tomcat Users List [EMAIL PROTECTED] MNbc cc: MNbc Subject:RE: unpackwars-true ?? MNbc Hi, Now, I place a war file in the default webapps folder, and as id MNbc expect, it is unpacked. However, it is not unpacked in the context which i MNbc create !.. all other things appear to work fine. MNbc Does the name of the context, as specified in the context element of MNbc server.xml, match the war file name? MNbc Also, consider upgrading to 4.0.4 to get the latest bugfixes ;) Should MNbc be a trivial move from 4.0.2 to 4.0.4. MNbc Yoav Shapira MNbc Millennium ChemInformatics MNbc -- MNbc To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] MNbc For additional commands, e-mail: mailto:[EMAIL PROTECTED] MNbc -- MNbc To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] MNbc For additional commands, e-mail: mailto:[EMAIL PROTECTED] MNbc -- MNbc To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] MNbc For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Best regards, Jacobmailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: unpackwars-true ??
It will unpack to the context matching the name of the war file, not what is specified in the web.xml file. The only other deployment issue I have run into is that you must have a temp directory under CATALINA_HOME; specifically taglib jars with internal tag lib descriptors will not deploy properly unless you do. Heres a quick turnaround for you ! I upgraded to tomcat 4.0.4. it appears not to have changed my server.xml file, and everything works still, which is nice. Everything appart from unpackwars=true that is :(, my war file is still not unpacking http://localhost/struts/blablabla gives a 404. any more ideas ? Mehdi -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
