RE: Application Configuration
I have several xml files that I need to load from a web service application. The xml files are not packaged into a WAR file or any other cabinet. Where would be the best place to put the xml files and what would be the best way to read it? Asaf Lahav VP RD, Prima Grid LTD. Cellular: 972-54-4717955 Phone: 972-3-6540255 Fax: 972-3-6540254 -Original Message- From: Mark Petrovic [mailto:[EMAIL PROTECTED] Sent: Monday, May 08, 2006 8:10 PM To: Tomcat Users List Subject: Re: Application Configuration You can put those types of resources in your .war file and access them as resources. servlet.getClass().getResource(xmlfile.xml); type of scheme. On 5/8/06, Asaf Lahav [EMAIL PROTECTED] wrote: Hi everybody, I still need help on this. Please read below. *Asaf Lahav* *VP RD, Prima Grid LTD.* Cellular: 972-54-4717955 Phone: 972-3-6540255 Fax: 972-3-6540254 -- *From:* Asaf Lahav [mailto:[EMAIL PROTECTED] *Sent:* Monday, May 08, 2006 11:30 AM *To:* users@tomcat.apache.org *Subject:* Application Configuration Hi all, I'm building a web services application that requires configuration xml files. Is there a location where I should put the xml configuration files? Is there a best practice saying where to put configuration files? If there is, how am I expected to get the configuration info from there? Thanks in advance, *Asaf Lahav* *VP RD, Prima Grid LTD.* Cellular: 972-54-4717955 Phone: 972-3-6540255 Fax: 972-3-6540254 -- Mark AE6RT - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5 Upgrade Problems
I have found exactly the same problem, and it's bad news. The web application has LOTS of JSPs, and I really don't want to jam them in the root directory. Is there a solution? -- View this message in context: http://www.nabble.com/Tomcat-5.5-Upgrade-Problems-t1404562.html#a4379330 Sent from the Tomcat - User forum at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5 Upgrade Problems
On 4/6/06, prophecy [EMAIL PROTECTED] wrote: I've been getting this error after upgrading from Tomcat 5.0 to Tomcat 5.5: Only a type can be imported. com.x.MyClass resolves to a package And the only solution, that I found after hours of banging my head on the keyboard, is to put the jsp files in the root context directory. For instance, if the jsp files are at /index.jsp, it works fine. If it's at /somedir/index.jsp , it can't find the classes in the WEB-INF/classes dir. This is very strange behaviour, am I the only one that has seen this? I have multiple instances of Tomcat (5.5.9 - 5.5.17) running on various platforms, and haven't seen this anywhere. And I just did a quick test of moving a page with imports deeper into the directory structure, with no effect. So there's something else going on; without more specific info it's hard to say what. Can you make a simple WAR of a test case? -- Hassan Schroeder [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
2.4 servlet spec compliance (getContextPath)
Hi Tomcat Users, I was wondering if anyone knows of documentation or forum discussions around areas of the Java Sevlet Spec that Tomcat does not support. I noticed that the Tomcat implementation for HttpServletRequest getContextPath() returns a decoded string. The 2.3 and 2.4 spec and the API documentation state that the container does not decode this string. As an application programmer, it is difficult to determine the best way to handle different behavior across containers when they do not conform to the spec. Anyway, I decided to log a bug on Tomcat. See... http://issues.apache.org/bugzilla/show_bug.cgi?id=39503 I was a little surprised by the response and the fact that development didn't seem too interested in the issue... First of all, let me state that I don't care at all about the nonsensical things the specification says, and which has slipped in for whatever unintended reason. I will let you reopen the report if you wish to, but will ignore it completely, and let me assure you this will never get fixed. It's not a big deal, and I'll live with the decision but I was curious if there were posts or information about the process to determine what parts of the spec were not essential or just not clear. Is there information on any other areas of the spec that Tomcat has chosen not to implement or conform to? Granted, the spec is not always clear and there's room for interpretation, but it would be nice to know in advance where one might see divergence in containers. Thanks for any info. Kind regards, Carlin
Re: More virtual hosting problems!!
Doug, Thanks for your efforts to help. I am back with more questions. Hope you can still help. I created a folder called $CATALINA_HOME/rizapps like you suggested I added a war file called ROOT.war to this directory The entry for the virtual host in my $CATALINA_HOME/conf/server.xml looks like this.. Host name=www.eshipper.com appBase=rizapps unpackWARs=true autoDeploy=true xmlValidation=false xmlNamespaceAware=false /Host As you suggested, I also created a folder called $CATALINA_HOME/rizapps/META-INF with a file called context.xml which looks like this Context displayName=riz docBase=ROOT /Context The above works perfectly, but how do I add more apps to the rizapps folder? When I tried to change ROOT.war to riz.war (and correspondingly change the docBase to riz) it stopped working (not sure why). So if I have another app war called riz2.war where would i put this and what entry would i need to make in the context.xml file under the META-INF directory? Can I have more than 1 context element entry in the context.xml file (1 for each app under rizapps)?? Hope my question is clear and that you can help me here. Thanks, -Riz. Parsons Technical Services wrote: First to your issue below. Problems: The workDir belongs in the Host section and not in the context. The path to the workDir end in an underscore. The default app is usually in a folder called ROOT. The appBase would be better somewhere other than webapps. Maybe rizapps(my opinion) Otherwise it would conflict with an app called riz deployed in the default host. Host name=www.riz.com appBase=rizapps unpackWARs=true autoDeploy=true workDir=work/Catalina/riz xmlValidation=false xmlNamespaceAware=false Context displayName=riz docBase=ROOT path= /Context /Host There is a way to use the ROOT.xml to deploy the default app for a context. I am not familiar with it but this is my best guess. To retry your first attempt: Remove the Context element from above. Deploy you app in a war named ROOT.war Use META-INF/context.xml not ROOT.xml In the META-INF/context.xml file remove the path element. I ain't perfect so I may have a goof or three in the above stuff. Doug - Original Message - From: Rizwan Merchant [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Friday, May 12, 2006 4:39 PM Subject: Re: More virtual hosting problems!! dug deeper and figured that everytime I undeploy (delete the expanded application directory and replace the war file), the virtual host does not get resolved the first time the app is deployed. have to shut down the server and restart for it to work! any ideas? Please help... Rizwan Merchant wrote: Ok to add to the mix, here is some more weird stuff. I have the virtual host stuff working using the following entry in the server.xml Host name=www.riz.com appBase=webapps/riz unpackWARs=true autoDeploy=true xmlValidation=false xmlNamespaceAware=false Context displayName=riz docBase= path= workDir=work/Catalina/riz/_ /Context /Host when i start the server and type www.riz.com in the browser, it doesnt resolve. I then have to shut down the server and restart before www.riz.com gets resolved. So basically for my virtual hosting to work, I have to start the server twice to make it work!!! Weird Tim Lucia wrote: The link/text you posted says except when statically defining a Context in server.xml, which was the case in the example from the OP... The above statement is exactly opposite of what you posted, is it not? To my recollection, and despite the fact that it is (now) frowned upon, path=/something has always worked in server.xml... since my days with Tomcat 3.x. Tim -Original Message- From: Parsons Technical Services [mailto:[EMAIL PROTECTED] Sent: Friday, May 12, 2006 7:57 AM To: Tomcat Users List Subject: Re: More virtual hosting problems!! From http://tomcat.apache.org/tomcat-5.5-doc/config/context.html And look at the path element. The value of this field must not be set except when statically defining a Context in server.xml, as it will be inferred from the filenames used for either the .xml context file or the docBase. Now there is the issue of Tomcat version. What version is running? I was basing my info on an assumption of a 5.5.x path. The 5.0.x path is different. Doug - Original Message - From: Tim Lucia [EMAIL PROTECTED] To: 'Tomcat Users List' users@tomcat.apache.org Sent: Friday, May 12, 2006 6:48 AM Subject: RE: More virtual hosting problems!! Where is this documented? I have had no problem doing this. Since I now put context files in conf/[Engine]/[Host], I went back and added Context docBase=d:/tjl/Projects/log4jconfig path=/log4jconfig/ to my server.xml and http://localhost:8080/manager/list shows OK - Listed applications for virtual host localhost /admin:running:0:C:/Tomcat/server/webapps/admin
Re: Application Configuration
I can help you off list. Please mail me directly. Mark On 5/14/06, Asaf Lahav [EMAIL PROTECTED] wrote: I have several xml files that I need to load from a web service application. The xml files are not packaged into a WAR file or any other cabinet. Where would be the best place to put the xml files and what would be the best way to read it? Asaf Lahav VP RD, Prima Grid LTD. Cellular: 972-54-4717955 Phone: 972-3-6540255 Fax: 972-3-6540254 -Original Message- From: Mark Petrovic [mailto:[EMAIL PROTECTED] Sent: Monday, May 08, 2006 8:10 PM To: Tomcat Users List Subject: Re: Application Configuration You can put those types of resources in your .war file and access them as resources. servlet.getClass().getResource(xmlfile.xml); type of scheme. On 5/8/06, Asaf Lahav [EMAIL PROTECTED] wrote: Hi everybody, I still need help on this. Please read below. *Asaf Lahav* *VP RD, Prima Grid LTD.* Cellular: 972-54-4717955 Phone: 972-3-6540255 Fax: 972-3-6540254 -- *From:* Asaf Lahav [mailto:[EMAIL PROTECTED] *Sent:* Monday, May 08, 2006 11:30 AM *To:* users@tomcat.apache.org *Subject:* Application Configuration Hi all, I'm building a web services application that requires configuration xml files. Is there a location where I should put the xml configuration files? Is there a best practice saying where to put configuration files? If there is, how am I expected to get the configuration info from there? Thanks in advance, *Asaf Lahav* *VP RD, Prima Grid LTD.* Cellular: 972-54-4717955 Phone: 972-3-6540255 Fax: 972-3-6540254 -- Mark AE6RT - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mark AE6RT
Re: More virtual hosting problems!!
I need to clarify that the context.xml should be part of the war. Note I said should (my opinion again)for easy deployment of the app. To deploy a new app riz2, simply place the war in the rizapps folder. It should auto deploy and show up as www.eshipper.com/riz2 . The ROOT.war is a special case that deploys the app as the default app (same as path=). If you bundle the context.xml as part of the war it will be used. You can find further details for using the context at http://tomcat.apache.org/tomcat-5.5-doc/config/context.html Doug - Original Message - From: Rizwan Merchant [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Sunday, May 14, 2006 5:20 PM Subject: Re: More virtual hosting problems!! Doug, Thanks for your efforts to help. I am back with more questions. Hope you can still help. I created a folder called $CATALINA_HOME/rizapps like you suggested I added a war file called ROOT.war to this directory The entry for the virtual host in my $CATALINA_HOME/conf/server.xml looks like this.. Host name=www.eshipper.com appBase=rizapps unpackWARs=true autoDeploy=true xmlValidation=false xmlNamespaceAware=false /Host As you suggested, I also created a folder called $CATALINA_HOME/rizapps/META-INF with a file called context.xml which looks like this Context displayName=riz docBase=ROOT /Context The above works perfectly, but how do I add more apps to the rizapps folder? When I tried to change ROOT.war to riz.war (and correspondingly change the docBase to riz) it stopped working (not sure why). So if I have another app war called riz2.war where would i put this and what entry would i need to make in the context.xml file under the META-INF directory? Can I have more than 1 context element entry in the context.xml file (1 for each app under rizapps)?? Hope my question is clear and that you can help me here. Thanks, -Riz. Parsons Technical Services wrote: First to your issue below. Problems: The workDir belongs in the Host section and not in the context. The path to the workDir end in an underscore. The default app is usually in a folder called ROOT. The appBase would be better somewhere other than webapps. Maybe rizapps(my opinion) Otherwise it would conflict with an app called riz deployed in the default host. Host name=www.riz.com appBase=rizapps unpackWARs=true autoDeploy=true workDir=work/Catalina/riz xmlValidation=false xmlNamespaceAware=false Context displayName=riz docBase=ROOT path= /Context /Host There is a way to use the ROOT.xml to deploy the default app for a context. I am not familiar with it but this is my best guess. To retry your first attempt: Remove the Context element from above. Deploy you app in a war named ROOT.war Use META-INF/context.xml not ROOT.xml In the META-INF/context.xml file remove the path element. I ain't perfect so I may have a goof or three in the above stuff. Doug - Original Message - From: Rizwan Merchant [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Friday, May 12, 2006 4:39 PM Subject: Re: More virtual hosting problems!! dug deeper and figured that everytime I undeploy (delete the expanded application directory and replace the war file), the virtual host does not get resolved the first time the app is deployed. have to shut down the server and restart for it to work! any ideas? Please help... Rizwan Merchant wrote: Ok to add to the mix, here is some more weird stuff. I have the virtual host stuff working using the following entry in the server.xml Host name=www.riz.com appBase=webapps/riz unpackWARs=true autoDeploy=true xmlValidation=false xmlNamespaceAware=false Context displayName=riz docBase= path= workDir=work/Catalina/riz/_ /Context /Host when i start the server and type www.riz.com in the browser, it doesnt resolve. I then have to shut down the server and restart before www.riz.com gets resolved. So basically for my virtual hosting to work, I have to start the server twice to make it work!!! Weird Tim Lucia wrote: The link/text you posted says except when statically defining a Context in server.xml, which was the case in the example from the OP... The above statement is exactly opposite of what you posted, is it not? To my recollection, and despite the fact that it is (now) frowned upon, path=/something has always worked in server.xml... since my days with Tomcat 3.x. Tim -Original Message- From: Parsons Technical Services [mailto:[EMAIL PROTECTED] Sent: Friday, May 12, 2006 7:57 AM To: Tomcat Users List Subject: Re: More virtual hosting problems!! From http://tomcat.apache.org/tomcat-5.5-doc/config/context.html And look at the path element. The value of this field must not be set except when statically defining a Context in server.xml, as it will be inferred from the filenames used for either the .xml context file
Re: 2.4 servlet spec compliance (getContextPath)
Carlin Rogers [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Hi Tomcat Users,
I was wondering if anyone knows of documentation or forum discussions
around
areas of the Java Sevlet Spec that Tomcat does not support. I noticed that
the Tomcat implementation for HttpServletRequest getContextPath() returns
a
decoded string. The 2.3 and 2.4 spec and the API documentation state that
the container does not decode this string. As an application programmer,
it is difficult to determine the best way to handle different behavior
across containers when they do not conform to the spec. Anyway, I decided
to
log a bug on Tomcat. See...
http://issues.apache.org/bugzilla/show_bug.cgi?id=39503
I was a little surprised by the response and the fact that development
didn't seem too interested in the issue...
First of all, let me state that I don't care at all about the
nonsensical things
the specification says, and which has slipped in for whatever unintended
reason.
I will let you reopen the report if you wish to, but will ignore it
completely,
and let me assure you this will never get fixed.
Probably true. It adds way too much complexity to the code, for very little
gain. As a simple example, consider:
GET /my%20app%2fmy%20servlet%2fmy%20path%20info HTTP/1.1
It's not a big deal, and I'll live with the decision but I was curious if
there were posts or information about the process to determine what parts
of
the spec were not essential or just not clear.
Pretty much all of them have been discussed at length on [EMAIL PROTECTED]
and/or
BZ. The archives are your friend :).
Is there information on any other areas of the spec that Tomcat has chosen
not to implement or conform to? Granted, the spec is not always clear and
there's room for interpretation, but it would be nice to know in advance
where one might see divergence in containers. Thanks for any info.
Off the top of my head:
1) Extension-mapped welcome-pages -- Tomcat requires a physical resource to
be present to use it.
2) Flush after a forward -- The following doesn't work as expected:
try {
rd.forward(request, response);
} finally {
doSomeLongAndComplexDbUpdate(request, response);
}
3) Tomcat catches most cases, but doesn't strictly enforce that the
Request/Response passed to an include/forward *must* be either the original
Request/Response, or a Request/ResponseWrapper that wraps the orignal
Request/Response.
Kind regards,
Carlin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Help!Tomcat crashes:Waiting for instance(s) to be deallocated
Ciao thank you for your answer! Well we use our own connection-pool, with the close of the connection in each-finally call! Normally the connection is closed immediately but perhaps it's a thread problem! Can someone tell me if you can tune the thread behaviour is there any possiblity, or is it just a problem with tomcat 4.1? Thank you! Starki -- Initial Header --- From : Martyn Hiemstra [EMAIL PROTECTED] To : Tomcat Users List users@tomcat.apache.org Cc : Date : Thu, 11 May 2006 10:26:11 +0200 Subject : Re: Help!Tomcat crashes:Waiting for instance(s) to be deallocated Hi Starki78 I had this problem when using a singelton class that stored a datasource in it. Everytime I pressed F5 really fast the web server would hang and when I shutdown I got that same message. Apparently when pressing F5 very fast instead of the singelton only using 1 datasource (The one in the singelton) it loaded 5 datasources and then the connection pool was full. Since the pool timeouts where set to 5 minutes the server would appear to hang when in actual fact my code was waiting for an available datasource. I also get this when debugging my tomcat server using eclipse. If I'm debugging and one of the server threads is still debugging and I shutdown the server I get this message as well. I'm guessing that somewhere alot of threads are waiting to finish. The fact that you have 536 instances to be deallocated could mean you have a serious flaw in your code. Martyn starki78 schreef: Hi, we are working with Tomcat 4.1: I didn't find a proper cause in the log-files. Can someone help me please? How could this be possible?? 2006-05-11 06:53:35 StandardWrapper[/pss:action]: Waiting for 74 instance(s) to be deallocated 2006-05-11 06:53:36 StandardWrapper[/pss:jsp]: Waiting for 1 instance(s) to be deallocated 2006-05-11 06:53:36 StandardWrapper[/pss:default]: Waiting for 536 instance(s) to be deallocated - 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: 2.4 servlet spec compliance (getContextPath)
Bill Barker wrote:
Carlin Rogers [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Pretty much all of them have been discussed at length on [EMAIL PROTECTED] and/or
BZ. The archives are your friend :).
Is there information on any other areas of the spec that Tomcat has chosen
not to implement or conform to? Granted, the spec is not always clear and
there's room for interpretation, but it would be nice to know in advance
where one might see divergence in containers. Thanks for any info.
As a result of your report it prompted me to suggest that such a
resource exist, check out the developers list for my mails on the subject.
Off the top of my head:
1) Extension-mapped welcome-pages -- Tomcat requires a physical resource to
be present to use it.
2) Flush after a forward -- The following doesn't work as expected:
try {
rd.forward(request, response);
} finally {
doSomeLongAndComplexDbUpdate(request, response);
}
3) Tomcat catches most cases, but doesn't strictly enforce that the
Request/Response passed to an include/forward *must* be either the original
Request/Response, or a Request/ResponseWrapper that wraps the orignal
Request/Response.
I'm happy to collate all these issues from developers and users alike
feel free the email me privately to allow me to draft out some reference
documentation for each issue individually.
Darryl
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
