date:20111017


Alright guys, thanks for your help.



Pid * wrote:
> 
> On 14/10/2011 16:31, Mark Thomas wrote:
>> On 14/10/2011 16:15, Mark H. Wood wrote:
>>> This I can agree with.  They don't allow application managers
>>> access to Tomcat's config., but anyone can drop stuff into
>>> /etc/init.d, whence it will run as root?  Really?  Something is not
>>> right here.
> 
> +1  These support guys need firing...
> 
>> Is it just me, or is the simple privilege escalation attack that this
>> makes possible the quickest way to solve this? :) Granted, it isn't
>> the best way to solve it but boy would I be tempted in your shoes.
> 
> Yes, quite.
> 
> 
> p
> 
> 
>  
> 

-- 
View this message in context: 
http://old.nabble.com/Configure-tomcat-using-init.d-tp32650998p32665384.html
Sent from the Tomcat - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Multiple session cookies names

2011-10-17 Thread Peter Cipov


Hello,
I would like to use multiple session cookie names in tomcat and tomcat  
chooses http attribute.

For example: SESSION_APP_CLIENT - for  fronted application
 SESSION_APP_ADMIN - for admin part

I would like to have separate sessions for security reasons and for  
possibility to have opened tab per application module in browser (one for  
user, and one for admin) with separate sessions.


I have an application deployed on root level and I am using tomcat 7.

In current state, tomcat uses standard JSESSIONID or string value defined  
context.xml


It is there a way to accomplish this?



Best Regards

--
Peter Cipov



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Multiple session cookies names

2011-10-17 Thread Mark Thomas

On 17/10/2011 10:31, Peter Cipov wrote:
> Hello,
> I would like to use multiple session cookie names in tomcat and tomcat
> chooses http attribute.
> For example: SESSION_APP_CLIENT - for  fronted application
>  SESSION_APP_ADMIN - for admin part
> 
> I would like to have separate sessions for security reasons and for
> possibility to have opened tab per application module in browser (one
> for user, and one for admin) with separate sessions.
> 
> I have an application deployed on root level and I am using tomcat 7.
> 
> In current state, tomcat uses standard JSESSIONID or string value
> defined context.xml
> 
> It is there a way to accomplish this?

Yes. Read the servlet 3 spec and/or the Context configuration docs.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Configure tomcat using init.d


Thanks Hassan for your help.

I found the version (Red Hat 4.1.2-50).

Regarding the the deploy, I know that by storing a file under
Catalina->localhost-> myAppName.xml in which I specify the path of the WAR I
would not need to copy WAR under wepApps but Tomcat will do it by itself. Is
that correct?

For the context.xml, shall I create it, since there's no file so called in
META-INF.

Many thanks.


Hassan Schroeder-2 wrote:
> 
> On Fri, Oct 14, 2011 at 1:52 AM, ettoregia  wrote:
> 
>> My system: Linux, the version I'don't know how to realize, since I've got
>> just an ssh connection and typing some command I've not been able to
>> discover it, maybe you can help me out on this as well.
> 
> `cat /proc/version` should give you something useful.
> 
>> Alright, I need to deploy .war file under tomcat that actually has 4
>> engines
>> (5.5, 6.0.16, 6.0.18, 7.0), and as I'm used to, I would put under
>> /conf/Catalina/localhost, of the engine 6.0.18, a file called
>> .xml to specify the context path of my webApp then I would
>> modify
>> the server.xml to specify the jdbc connection and the like. As I've no
>> rights to modify anything under the tomcat's home the IT guy told me to
>> use
>> the folder init.d/ in order to use any script at boot time to
>> accomplish the configuration above.
> 
> Huh? Your app's context path should be taken from the name of the
> WAR file, and the JDBC config should be contained in the WAR file
> in a META-INF/context.xml file.
> 
> Nothing else required. Other than an better IT department. :-)
> 
> -- 
> Hassan Schroeder  hassan.schroe...@gmail.com
> http://about.me/hassanschroeder
> twitter: @hassan
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> 
> 

-- 
View this message in context: 
http://old.nabble.com/Configure-tomcat-using-init.d-tp32650998p32665821.html
Sent from the Tomcat - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Is incoming connection request queue totally ordered?

2011-10-17 Thread Stevo Slavić

Hello Tomcat users,

Are HTTP and AJP connector incoming connection request queues totally
ordered (FIFO)? Just want to make sure whether connection requests
waiting for executor will fight for it once one becomes available, or
will the order connection request were made be respected.

Regards,
Stevo.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Multiple war files for a single webapp or context

2011-10-17 Thread Konstantin Kolinko

2011/10/17 Ziggy :
> I have an application that has the following structure
>
>    $TOMCAT_HOME/webapps/myapp
>                |-css
>                    |-myapp.css
>                |-js
>                    |-myapp.js
>                |-forum
>                    |-index.jsp
>                    |-list.jsp
>                    |-users.jsp
>                |-Articles
>                    |-index.jsp
>                    |-ListArticles.jsp
>                |-Guestbook
>                    |-viewGuestBook.jsp
>                    |-AddnewEntry.jsp
>                |-WEB-INF
>                    |-classes
>                        com
>                         |-myapp
>                            |-forum
>                                |-DisplayForum.class
>                                |-ListUsers.class
>                            |-article
>                                |-ArticleList.class
>                                |-AddArticle.class
>                            |-guestbk
>                                |-LoadGuestBook.class
>                                |-ProcessGuestBook.class
>
> The application is delivered as a war file (i.e. myapp.war) and is deployed
> into the $TOMCAT_HOME/webapps folder. If any of the files change (either the
> jsp, css, js or java files) i have to always rebuild the whole war file.
> This means i deploy every single file on every release.
>
> I am wondering if there is a way to deploy specific areas of the
> application. I am particularly interested if it is possible to separate the
> application into multiple war files. i.e. myapp.war, articles.war and
> forum.war. I would like to still access the application via the same context
> i.e. http://0.0.0.0/myapp even though multiple war files are used.
>
> Using this approach, i will be able to deliver just the module that was
> affected by the change. Is this at all possible?
>
> I dont mind having to restart the container after each war file is deployed.
>

You are not saying what Tomcat version you are using.

It is possible to create wars for nested context. E.g. to separate scripts into
myapp#js.war
-> the root of this web application will be /myapp/js/

Note that all web applications are independent of each other, so you
need to have separate web.xml for each of them, and you cannot access
to code that belongs to another web application.

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Multiple war files for a single webapp or context

2011-10-17 Thread Ziggy

Would the nested context approach allow access to session data from one war
file to the other?

Thanks

On Mon, Oct 17, 2011 at 12:08 PM, Konstantin Kolinko  wrote:

> 2011/10/17 Ziggy :
> > I have an application that has the following structure
> >
> >$TOMCAT_HOME/webapps/myapp
> >|-css
> >|-myapp.css
> >|-js
> >|-myapp.js
> >|-forum
> >|-index.jsp
> >|-list.jsp
> >|-users.jsp
> >|-Articles
> >|-index.jsp
> >|-ListArticles.jsp
> >|-Guestbook
> >|-viewGuestBook.jsp
> >|-AddnewEntry.jsp
> >|-WEB-INF
> >|-classes
> >com
> > |-myapp
> >|-forum
> >|-DisplayForum.class
> >|-ListUsers.class
> >|-article
> >|-ArticleList.class
> >|-AddArticle.class
> >|-guestbk
> >|-LoadGuestBook.class
> >|-ProcessGuestBook.class
> >
> > The application is delivered as a war file (i.e. myapp.war) and is
> deployed
> > into the $TOMCAT_HOME/webapps folder. If any of the files change (either
> the
> > jsp, css, js or java files) i have to always rebuild the whole war file.
> > This means i deploy every single file on every release.
> >
> > I am wondering if there is a way to deploy specific areas of the
> > application. I am particularly interested if it is possible to separate
> the
> > application into multiple war files. i.e. myapp.war, articles.war and
> > forum.war. I would like to still access the application via the same
> context
> > i.e. http://0.0.0.0/myapp even though multiple war files are used.
> >
> > Using this approach, i will be able to deliver just the module that was
> > affected by the change. Is this at all possible?
> >
> > I dont mind having to restart the container after each war file is
> deployed.
> >
>
> You are not saying what Tomcat version you are using.
>
> It is possible to create wars for nested context. E.g. to separate scripts
> into
> myapp#js.war
> -> the root of this web application will be /myapp/js/
>
> Note that all web applications are independent of each other, so you
> need to have separate web.xml for each of them, and you cannot access
> to code that belongs to another web application.
>
> Best regards,
> Konstantin Kolinko
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Multiple war files for a single webapp or context

2011-10-17 Thread Konstantin Kolinko

2011/10/17 Ziggy :
> Would the nested context approach allow access to session data from one war
> file to the other?
>

No. Session id may be the same, but Session object itself will be different.

All webapps, by definition, are independent of each other.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Multiple session cookies names

2011-10-17 Thread Peter Cipov


Can you be more specific please ?

Dne Mon, 17 Oct 2011 12:00:18 +0200 Mark Thomas   
napsal(a):



On 17/10/2011 10:31, Peter Cipov wrote:

Hello,
I would like to use multiple session cookie names in tomcat and tomcat
chooses http attribute.
For example: SESSION_APP_CLIENT - for  fronted application
 SESSION_APP_ADMIN - for admin part

I would like to have separate sessions for security reasons and for
possibility to have opened tab per application module in browser (one
for user, and one for admin) with separate sessions.

I have an application deployed on root level and I am using tomcat 7.

In current state, tomcat uses standard JSESSIONID or string value
defined context.xml

It is there a way to accomplish this?


Yes. Read the servlet 3 spec and/or the Context configuration docs.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org








-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Multiple session cookies names

2011-10-17 Thread Konstantin Kolinko

2. For Tomcat 6 read "Context" chapter in the configuration reference,
for Tomcat 7 download and read the Servlet 3.0 specification. Both
allow to configure session cookie names, but the way to configure it
differs between Tomcat versions.
1. Do not top-post

2011/10/17 Peter Cipov :
> Can you be more specific please ?
>
> Dne Mon, 17 Oct 2011 12:00:18 +0200 Mark Thomas 
> napsal(a):
>
>> On 17/10/2011 10:31, Peter Cipov wrote:
>>>
>>> Hello,
>>> I would like to use multiple session cookie names in tomcat and tomcat
>>> chooses http attribute.
>>> For example: SESSION_APP_CLIENT - for  fronted application
>>>             SESSION_APP_ADMIN - for admin part
>>>
>>> I would like to have separate sessions for security reasons and for
>>> possibility to have opened tab per application module in browser (one
>>> for user, and one for admin) with separate sessions.
>>>
>>> I have an application deployed on root level and I am using tomcat 7.
>>>
>>> In current state, tomcat uses standard JSESSIONID or string value
>>> defined context.xml
>>>
>>> It is there a way to accomplish this?
>>
>> Yes. Read the servlet 3 spec and/or the Context configuration docs.
>>
>> Mark
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Configure tomcat using init.d

2011-10-17 Thread Hassan Schroeder

On Mon, Oct 17, 2011 at 3:04 AM, ettoregia  wrote:

> Regarding the the deploy, I know that by storing a file under
> Catalina->localhost-> myAppName.xml in which I specify the path of the WAR I
> would not need to copy WAR under wepApps but Tomcat will do it by itself. Is
> that correct?

Sorry, I'm not sure what you're asking. You need to place your WAR
file *somewhere* to deploy it.

Personally I just put it in the appBase directory, eliminating the step
you describe above.

> For the context.xml, shall I create it, since there's no file so called in
> META-INF.

Yes.

-- 
Hassan Schroeder  hassan.schroe...@gmail.com
http://about.me/hassanschroeder
twitter: @hassan

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Configure tomcat using init.d


I know, but storing the file it's less invasive. At least that suggest the
Tomcat doc.


Hassan Schroeder-2 wrote:
> 
> On Mon, Oct 17, 2011 at 3:04 AM, ettoregia  wrote:
> 
>> Regarding the the deploy, I know that by storing a file under
>> Catalina->localhost-> myAppName.xml in which I specify the path of the
>> WAR I
>> would not need to copy WAR under wepApps but Tomcat will do it by itself.
>> Is
>> that correct?
> 
> Sorry, I'm not sure what you're asking. You need to place your WAR
> file *somewhere* to deploy it.
> 
> Personally I just put it in the appBase directory, eliminating the step
> you describe above.
> 
>> For the context.xml, shall I create it, since there's no file so called
>> in
>> META-INF.
> 
> Yes.
> 
> -- 
> Hassan Schroeder  hassan.schroe...@gmail.com
> http://about.me/hassanschroeder
> twitter: @hassan
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> 
> 

-- 
View this message in context: 
http://old.nabble.com/Configure-tomcat-using-init.d-tp32650998p32667860.html
Sent from the Tomcat - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Tomcat Manager


Hi everybody,

I'm using Tomcat 6.0.33 and at localhost:8080 it shows correctly.
When I try to access the tomcat manager link I get an 404 page error.

It says the resource is unavailable, the only row in the
conf/Catalina/localhost/manager.xml & host-manager.xml is 

"
"

Any ideas on what could be the problem?
-- 
View this message in context: 
http://old.nabble.com/Tomcat-Manager-tp32667906p32667906.html
Sent from the Tomcat - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: filters on j_security_check

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chema,

On 10/16/2011 1:55 PM, Chema wrote:
>> 
>> 
>> 
>> Frankly, if you're using Spring Security, I'd stick with it. I
>> myself am thinking of making the switch.
>> 
>> 
> Yes, I tried it and like it , but I need Single Sign On support and
> the solutions what Spring Security offers are complicated to
> implement by me

sf does not support SSO at all, so there's definitely no reason for
you to switch.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6cRs8ACgkQ9CaO5/Lv0PCtHwCgxA1AkaSclPEsb06SHcKaLF2F
T4EAoIItWnxsiIAnzh+kKW6Lji2cjjVl
=gqf5
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Configure tomcat using init.d

2011-10-17 Thread Hassan Schroeder

On Mon, Oct 17, 2011 at 8:01 AM, ettoregia  wrote:
>
> I know, but storing the file it's less invasive. At least that suggest the
> Tomcat doc.

Sorry, I'm afraid I don't follow that. But whatever works for you :-)

-- 
Hassan Schroeder  hassan.schroe...@gmail.com
http://about.me/hassanschroeder
twitter: @hassan

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat Manager

2011-10-17 Thread Tim Watts

On Mon, 2011-10-17 at 08:08 -0700, ettoregia wrote:
> Hi everybody,
> 
> I'm using Tomcat 6.0.33 and at localhost:8080 it shows correctly.

Does "localhost:8080 it shows correctly" mean you can see a process
listening on it?

> When I try to access the tomcat manager link I get an 404 page error.
> 

What URL are you using? Did you enable access (i.e. are you really
getting a 404 and not a 403)?

http://tomcat.apache.org/tomcat-6.0-doc/manager-howto.html#Configuring_Manager_Application_Access


> It says the resource is unavailable, the only row in the
> conf/Catalina/localhost/manager.xml & host-manager.xml is 
> 
> "
>  />"
> 
> Any ideas on what could be the problem?



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat Manager




Tim Watts-3 wrote:
> 
> On Mon, 2011-10-17 at 08:08 -0700, ettoregia wrote:
>> Hi everybody,
>> 
>> I'm using Tomcat 6.0.33 and at localhost:8080 it shows correctly.
> 
> Does "localhost:8080 it shows correctly" mean you can see a process
> listening on it?
> 
> Yes it does.
> 
>> When I try to access the tomcat manager link I get an 404 page error.
>> 
> 
> What URL are you using? Did you enable access (i.e. are you really
> getting a 404 and not a 403)?
> 
> Yes is a 404, before there was an error saying that I didn't configure the
> role admin..
> Then It started working fine. After few days I had to delete those files
> under conf/Catalina/localhost.
> Now they're there again.
> 
> 
> http://tomcat.apache.org/tomcat-6.0-doc/manager-howto.html#Configuring_Manager_Application_Access
> 
> 
>> It says the resource is unavailable, the only row in the
>> conf/Catalina/localhost/manager.xml & host-manager.xml is 
>> 
>> "
>> > />"
>> 
>> Any ideas on what could be the problem?
> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> 
> 

-- 
View this message in context: 
http://old.nabble.com/Tomcat-Manager-tp32667906p32668409.html
Sent from the Tomcat - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Session across Realm and Servlet

2011-10-17 Thread Tim Watts

On Mon, 2011-10-17 at 01:10 +0530, sailendra karthik wrote:
> On Sun, Oct 16, 2011 at 5:16 PM, Chema  wrote:
> 
> > >   In my Custom Realm Implementation iam autheticating some user and
> > > allowing
> > > him to access my webapps(servlets or filters) (my application)
> > >  This authentication session i need it to be reused in my webapp(to avoid
> > > another authentication)  if it is an authorized session.
> > >  So for this purpose i want to set an object in the session and reuse
> > that
> > > object(connection Object) at my servlets level.
> > >
> > > How can i over come this
> > >
> >
> >
> > You can use a Filter and check if remote user is setted.
> > I do it this way to load user info into user http session
> >
> 
> As you said that can work using Filters,
> But the requirement is that it needs Tomcat level authentication.
> 
>  or else i dont know whether i completely misunderstood the concept of
> realms.

>From what you've described so far, I see no reason why the standard
realms tomcat provides wouldn't meet your needs. I suggest that you may
not quite understand how the standard authentication mechanisms work.
Try re-reading the documentation on them. No sense re-inventing a wheel
that already rolls to your satisfaction. Or are we missing some crucial
details?




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat Manager

2011-10-17 Thread Tim Watts

On Mon, 2011-10-17 at 09:07 -0700, ettoregia wrote:
> 
> 
> Tim Watts-3 wrote:
> > 
> > On Mon, 2011-10-17 at 08:08 -0700, ettoregia wrote:
> > 
> >> When I try to access the tomcat manager link I get an 404 page error.
> >> 
> > 
> > What URL are you using? Did you enable access (i.e. are you really
> > getting a 404 and not a 403)?
> > 
> > Yes is a 404, before there was an error saying that I didn't configure the
> > role admin..
> > Then It started working fine. After few days I had to delete those files
> > under conf/Catalina/localhost.
> > Now they're there again.
> > 

So when you mouse-over the link, it shows
"http://localhost:8080/manager/html";, right?

It sounds like somehow the manager app got undeployed.
Do /webapps/manager & /webapps/host-manager exist? Are they non-empty?

Is autoDeploy still enabled? What does your  tag for localhost
look like? Is there any other non-default configuration that could be
tripping you up?


> > 
> > http://tomcat.apache.org/tomcat-6.0-doc/manager-howto.html#Configuring_Manager_Application_Access
> > 
> > 
> >> It says the resource is unavailable, the only row in the
> >> conf/Catalina/localhost/manager.xml & host-manager.xml is 
> >> 
> >> "
> >>  >> />"
> >> 
> >> Any ideas on what could be the problem?
> > 
> > 
> > 
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> > 
> > 
> > 
> 



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

JspServlet - Unexpected behavior, possible bug...




Greetings,

I am new to this list and I apologize in advance if this has been  
covered (although searching the archives did not lead me to a related  
thread):


In my web application I need to utilize the JSP servlet, but I need to  
use a different servlet mapping:



jsp
/jsp/*



This mapping works great, but I have noticed an odd thing:

- If I request a URL that references an existing JSP it works.
http://localhost:8080/test/jsp/index.jsp

- If I request a URL that references a file that does not exist I get  
a 404 error, as expected.

http://localhost:8080/test/jsp/doesnotexist


- If I request a URL (with a trailing "/" character) that references  
an existing directory within the the JSP servlet's purview. I get a  
404 error (which seems reasonable).

http://localhost:8080/test/jsp/foo

- BUT, If I request a URL (without a trailing slash) that references  
an existing directory within the the JSP servlet's purview, I get an  
HTTP status 500 (Internal Server Error).

http://localhost:8080/test/jsp/foo

I think this is incorrect behavior.

When I do the same experiment with the default servlet I get an empty  
directory, but no error.


I looked at the Tomcat code referenced by the stack trace:
org.apache.jasper.JasperException: File "/jsp/foo" not found
	 
org 
.apache 
.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java: 
51)
	 
org 
.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java: 
409)
	 
org 
.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java: 
116)

org.apache.jasper.compiler.JspUtil.getInputStream(JspUtil.java:851)
	 
org 
.apache 
.jasper 
.xmlparser.XMLEncodingDetector.getEncoding(XMLEncodingDetector.java:108)
	 
org 
.apache 
.jasper 
.compiler 
.ParserController.determineSyntaxAndEncoding(ParserController.java:348)
	 
org 
.apache.jasper.compiler.ParserController.doParse(ParserController.java: 
207)
	 
org 
.apache 
.jasper 
.compiler.ParserController.parseDirectives(ParserController.java:120)

org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:180)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:354)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:334)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:321)
	 
org 
.apache 
.jasper.JspCompilationContext.compile(JspCompilationContext.java:592)
	 
org 
.apache 
.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:328)
	org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java: 
313)

org.apache.jasper.servlet.JspServlet.service(JspServlet.java:260)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
And I can see that in JspServlet in lines 312 - 316:
try {
wrapper.service(request, response, precompile);
} catch (FileNotFoundException fnfe) {
handleMissingResource(request, response, jspUri);
}
The call is being serviced. Unfortunately when this problem occurs a  
"JasperException" is throw, not a FileNotFoundException and the  
handleMissingResource() path way is skipped


Any thoughts? It strikes me that this situation is one that can easily  
be incurred by a type in the URL and so I don't that that an HTTP  
staus of 500 should be returned in this situation.



Thanks,

Nathan


= = =
Nathan Potterndp at opendap.org
OPeNDAP, Inc.+1.541.231.3317





-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Error message - website login

Can you help me with this error message please? All the other computers in
our office can get access - this is a client website, so I need help with my
computer.

Thanks,
Ann

 HTTP Status 403 - Access is denied
--

*type* Status report

*message* *Access is denied*

*description* *Access to the specified resource (Access is denied) has been
forbidden.*
--
Apache Tomcat/6.0.28

RE: JspServlet - Unexpected behavior, possible bug...

> From: Nathan Potter [mailto:npot...@opendap.org] 
> Subject: JspServlet - Unexpected behavior, possible bug...

> In my web application I need to utilize the JSP servlet, but 
> I need to use a different servlet mapping:
>  
>  jsp
>  /jsp/*
>  

Before going any further, please explain why you think you need to do that.  
(I.e., what's the actual requirement?)

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: JspServlet - Unexpected behavior, possible bug...

we figured it out - thank you

On Mon, Oct 17, 2011 at 1:14 PM, Caldarale, Charles R <
chuck.caldar...@unisys.com> wrote:

> > From: Nathan Potter [mailto:npot...@opendap.org]
> > Subject: JspServlet - Unexpected behavior, possible bug...
>
> > In my web application I need to utilize the JSP servlet, but
> > I need to use a different servlet mapping:
> >  
> >  jsp
> >  /jsp/*
> >  
>
> Before going any further, please explain why you think you need to do that.
>  (I.e., what's the actual requirement?)
>
>  - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
> MATERIAL and is thus for use only by the intended recipient. If you received
> this in error, please contact the sender and delete the e-mail and its
> attachments from all computers.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Is incoming connection request queue totally ordered?


Stevo Slavić wrote:

Hello Tomcat users,

Are HTTP and AJP connector incoming connection request queues totally
ordered (FIFO)? Just want to make sure whether connection requests
waiting for executor will fight for it once one becomes available, or
will the order connection request were made be respected.

As ar as I know, this is something controlled by the TCP/IP stack of your host.  It is not 
dependent on Tomcat or Java.  Tomcat (through Java) just "accepts" a waiting connection, 
and gets the one which the native TCP/IP stack returns.
But yes, intuitively, it should always be a FIFO. I have a feeling that a lot of things 
would not work quite right if it wasn't. And it would certainly be unfair.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [OT] Configure tomcat using init.d

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mark,

On 10/14/2011 11:15 AM, Mark H. Wood wrote:
> On Fri, Oct 14, 2011 at 07:33:28AM -0700, Hassan Schroeder wrote:
>> On Fri, Oct 14, 2011 at 1:52 AM, ettoregia  
>> wrote:
>>> My system: Linux, the version I'don't know how to realize, 
>>> since I've got just an ssh connection and typing some command 
>>> I've not been able to discover it, maybe you can help me out
>>> on this as well.
>> 
>> `cat /proc/version` should give you something useful.
> 
> 'uname -a' is another possibility.

I'm running Debian Squeeze:

$ uname -a
Linux dev 2.6.32-5-openvz-amd64 #1 SMP Wed May 18 23:53:57 UTC 2011
i686 GNU/Linux

No mention of Debian.

$ cat /proc/version
Linux version 2.6.32-5-openvz-amd64 (Debian 2.6.32-34squeeze1)
(da...@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Wed
May 18 23:53:57 UTC 2011

Ooh, Debian everywhere.

Looks like Hassan's suggestion is better.

I usually do:

$ cat /etc/issue
Debian GNU/Linux 6.0 \n \l

I didn't know there was a /proc/version. Maybe I'll start using that,
as it has more information.

> This I can agree with.  They don't allow application managers 
> access to Tomcat's config., but anyone can drop stuff into 
> /etc/init.d, whence it will run as root?  Really?  Something is
> not right here.

Technically, things in /etc/init.d don't run as root just because they
are there. Most rc.d-based systems use /etc/rc[runlevel].d/* as
startup scripts, and those are symlinked to /etc/init.d. Putting a
file into /etc/init.d isn't a direct exploit, but it's pretty close.

> That init script would need to start Yet Another Tomcat Instance. 
> Is that what IT wants?  That has implications for memory demand, 
> port and address space, and linking among app.s.  Maybe the IT guy 
> understands how Tomcat works, but I think I would explore the 
> possibility that he doesn't.

+1

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6cgVAACgkQ9CaO5/Lv0PDETACgorbI/rr9VyrqW8Be2FWgBthm
gIEAn0pPW7uw5nsS2Zl8y8EjwFr2A+CY
=Ehot
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Error message - website login

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ann,

On 10/17/2011 1:20 PM, Ann Ramsey wrote:
> Can you help me with this error message please? All the other
> computers in our office can get access - this is a client website,
> so I need help with my computer.

I hate to have to do this, but:

http://catb.org/~esr/faqs/smart-questions.html

> HTTP Status 403 - Access is denied --
> 
> *type* Status report
> 
> *message* *Access is denied*
> 
> *description* *Access to the specified resource (Access is denied)
> has been forbidden.* -- Apache
> Tomcat/6.0.28

Well, at least we know that Tomcat is involved in *some* way.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6cghIACgkQ9CaO5/Lv0PA65QCgrhOVcbyNiMKVQsYM589ybtTZ
KnkAoL8D5tgvZDB22VQUdReWz7/fX+tm
=0n8T
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: JspServlet - Unexpected behavior, possible bug...

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ann,

On 10/17/2011 2:29 PM, Ann Ramsey wrote:
> we figured it out - thank you

What was the problem? This isn't tech support: this is a community of
volunteers and users. How about helping them out and explaining what
went wrong so others can figure it out in the future?

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6cgqEACgkQ9CaO5/Lv0PBeUgCfZoxXT9aJeS2NoZ6Q2aKCd0Fm
xX0An3saUAY3FW+37V5FaNXZyHUbCjEs
=7MOk
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Is incoming connection request queue totally ordered?

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Stevo,

On 10/17/2011 6:23 AM, Stevo Slavić wrote:
> Are HTTP and AJP connector incoming connection request queues
> totally ordered (FIFO)?

I would expect them to be, though I would also expect them to be separate.

> Just want to make sure whether connection requests waiting for
> executor will fight for it once one becomes available, or will the
> order connection request were made be respected.

If you have one executor but two connectors, the executor should
service both connectors (roughly) equally. I think this will come down
to the scheduler, either at the Java level or at the OS level.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6cgy4ACgkQ9CaO5/Lv0PDCCwCeJLQeLfSN3Ns277l/e5pDVgwc
A20AnjXERvfWKSeXFTeodUO+tFktl45D
=fwz1
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Is incoming connection request queue totally ordered?

> From: André Warnier [mailto:a...@ice-sa.com] 
> Subject: Re: Is incoming connection request queue totally ordered?

> As ar as I know, this is something controlled by the TCP/IP 
> stack of your host.  

And by network topology.

> It is not dependent on Tomcat or Java.

Not necessarily true; Tomcat or the JVM could queue connect requests 
internally, and might not maintain order.  (I haven't looked at the code, so I 
don't know what actually happens.)

> But yes, intuitively, it should always be a FIFO.

I don't think that assumption is warranted.  Given that different packets 
between a pair of IP nodes may take wildly different routes over the network, 
there's no guarantee on the order of arrival of TCP connection requests from a 
client to a server.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

Re: Is incoming connection request queue totally ordered?

Thank you - we figured it out.

On Mon, Oct 17, 2011 at 2:22 PM, André Warnier  wrote:

> Stevo Slavić wrote:
>
>> Hello Tomcat users,
>>
>> Are HTTP and AJP connector incoming connection request queues totally
>> ordered (FIFO)? Just want to make sure whether connection requests
>> waiting for executor will fight for it once one becomes available, or
>> will the order connection request were made be respected.
>>
>> As ar as I know, this is something controlled by the TCP/IP stack of your
> host.  It is not dependent on Tomcat or Java.  Tomcat (through Java) just
> "accepts" a waiting connection, and gets the one which the native TCP/IP
> stack returns.
> But yes, intuitively, it should always be a FIFO. I have a feeling that a
> lot of things would not work quite right if it wasn't. And it would
> certainly be unfair.
>
> --**--**-
> To unsubscribe, e-mail: 
> users-unsubscribe@tomcat.**apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: [OT] Configure tomcat using init.d

Thank you - we figured it out.

On Mon, Oct 17, 2011 at 2:26 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Mark,
>
> On 10/14/2011 11:15 AM, Mark H. Wood wrote:
> > On Fri, Oct 14, 2011 at 07:33:28AM -0700, Hassan Schroeder wrote:
> >> On Fri, Oct 14, 2011 at 1:52 AM, ettoregia 
> >> wrote:
> >>> My system: Linux, the version I'don't know how to realize,
> >>> since I've got just an ssh connection and typing some command
> >>> I've not been able to discover it, maybe you can help me out
> >>> on this as well.
> >>
> >> `cat /proc/version` should give you something useful.
> >
> > 'uname -a' is another possibility.
>
> I'm running Debian Squeeze:
>
> $ uname -a
> Linux dev 2.6.32-5-openvz-amd64 #1 SMP Wed May 18 23:53:57 UTC 2011
> i686 GNU/Linux
>
> No mention of Debian.
>
> $ cat /proc/version
> Linux version 2.6.32-5-openvz-amd64 (Debian 2.6.32-34squeeze1)
> (da...@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Wed
> May 18 23:53:57 UTC 2011
>
> Ooh, Debian everywhere.
>
> Looks like Hassan's suggestion is better.
>
> I usually do:
>
> $ cat /etc/issue
> Debian GNU/Linux 6.0 \n \l
>
> I didn't know there was a /proc/version. Maybe I'll start using that,
> as it has more information.
>
> > This I can agree with.  They don't allow application managers
> > access to Tomcat's config., but anyone can drop stuff into
> > /etc/init.d, whence it will run as root?  Really?  Something is
> > not right here.
>
> Technically, things in /etc/init.d don't run as root just because they
> are there. Most rc.d-based systems use /etc/rc[runlevel].d/* as
> startup scripts, and those are symlinked to /etc/init.d. Putting a
> file into /etc/init.d isn't a direct exploit, but it's pretty close.
>
> > That init script would need to start Yet Another Tomcat Instance.
> > Is that what IT wants?  That has implications for memory demand,
> > port and address space, and linking among app.s.  Maybe the IT guy
> > understands how Tomcat works, but I think I would explore the
> > possibility that he doesn't.
>
> +1
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk6cgVAACgkQ9CaO5/Lv0PDETACgorbI/rr9VyrqW8Be2FWgBthm
> gIEAn0pPW7uw5nsS2Zl8y8EjwFr2A+CY
> =Ehot
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Is incoming connection request queue totally ordered?


Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Stevo,

On 10/17/2011 6:23 AM, Stevo Slavić wrote:

Are HTTP and AJP connector incoming connection request queues
totally ordered (FIFO)?


I would expect them to be, though I would also expect them to be separate.


+1.  Good point, forgot that element.
HTTP = 1 FIFO; AJP = another FIFO.




Just want to make sure whether connection requests waiting for
executor will fight for it once one becomes available, or will the
order connection request were made be respected.


If you have one executor but two connectors, the executor should
service both connectors (roughly) equally. I think this will come down
to the scheduler, either at the Java level or at the OS level.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6cgy4ACgkQ9CaO5/Lv0PDCCwCeJLQeLfSN3Ns277l/e5pDVgwc
A20AnjXERvfWKSeXFTeodUO+tFktl45D
=fwz1
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org





-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Is incoming connection request queue totally ordered?

Thank you - we figured it out.

On Mon, Oct 17, 2011 at 2:44 PM, André Warnier  wrote:

> Christopher Schultz wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Stevo,
>>
>> On 10/17/2011 6:23 AM, Stevo Slavić wrote:
>>
>>> Are HTTP and AJP connector incoming connection request queues
>>> totally ordered (FIFO)?
>>>
>>
>> I would expect them to be, though I would also expect them to be separate.
>>
>
> +1.  Good point, forgot that element.
> HTTP = 1 FIFO; AJP = another FIFO.
>
>
>> Just want to make sure whether connection requests waiting for
>>> executor will fight for it once one becomes available, or will the
>>> order connection request were made be respected.
>>>
>>
>> If you have one executor but two connectors, the executor should
>> service both connectors (roughly) equally. I think this will come down
>> to the scheduler, either at the Java level or at the OS level.
>>
>> - -chris
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v1.4.10 (MingW32)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iEYEARECAAYFAk6cgy4ACgkQ9CaO5/**Lv0PDCCwCeJLQeLfSN3Ns277l/**e5pDVgwc
>> A20AnjXERvfWKSeXFTeodUO+**tFktl45D
>> =fwz1
>> -END PGP SIGNATURE-
>>
>> --**--**-
>> To unsubscribe, e-mail: 
>> users-unsubscribe@tomcat.**apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>>
>
> --**--**-
> To unsubscribe, e-mail: 
> users-unsubscribe@tomcat.**apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

RE: Is incoming connection request queue totally ordered?

> From: Ann Ramsey [mailto:ann.m.ram...@gmail.com] 
> Subject: Re: Is incoming connection request queue totally ordered?

> Thank you - we figured it out.

Besides learning how to ask questions in a reasonable manner, you also need to 
learn not to respond to threads completely unrelated to your topic.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

Re: JspServlet - Unexpected behavior, possible bug...




Does that mean that you figured out what I was talking about or how to  
correct/adjust the behavior?


I'm just curious if I did find a minor issue...



Nathan



On Oct 17, 2011, at 11:29 AM, Ann Ramsey wrote:


we figured it out - thank you

On Mon, Oct 17, 2011 at 1:14 PM, Caldarale, Charles R <
chuck.caldar...@unisys.com> wrote:


From: Nathan Potter [mailto:npot...@opendap.org]
Subject: JspServlet - Unexpected behavior, possible bug...



In my web application I need to utilize the JSP servlet, but
I need to use a different servlet mapping:

jsp
/jsp/*



Before going any further, please explain why you think you need to  
do that.

(I.e., what's the actual requirement?)

- Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE  
PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you  
received
this in error, please contact the sender and delete the e-mail and  
its

attachments from all computers.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org




= = =
Nathan Potterndp at opendap.org
OPeNDAP, Inc.+1.541.231.3317





-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: JspServlet - Unexpected behavior, possible bug...

Honestly, I'm just using another person's login. We don't really have an IT
guy, so I don't understand all the responses. I really appreciate everyone
responding though. You guys are very nice to respond!

Regards,
Ann

On Mon, Oct 17, 2011 at 2:55 PM, Nathan Potter  wrote:

>
>
> Does that mean that you figured out what I was talking about or how to
> correct/adjust the behavior?
>
> I'm just curious if I did find a minor issue...
>
>
>
> Nathan
>
>
>
> On Oct 17, 2011, at 11:29 AM, Ann Ramsey wrote:
>
> we figured it out - thank you
>>
>> On Mon, Oct 17, 2011 at 1:14 PM, Caldarale, Charles R <
>> chuck.caldar...@unisys.com> wrote:
>>
>>  From: Nathan Potter [mailto:npot...@opendap.org]
 Subject: JspServlet - Unexpected behavior, possible bug...

>>>
>>> In my web application I need to utilize the JSP servlet, but
 I need to use a different servlet mapping:

jsp
/jsp/*


>>>
>>> Before going any further, please explain why you think you need to do
>>> that.
>>> (I.e., what's the actual requirement?)
>>>
>>> - Chuck
>>>
>>>
>>> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
>>> MATERIAL and is thus for use only by the intended recipient. If you
>>> received
>>> this in error, please contact the sender and delete the e-mail and its
>>> attachments from all computers.
>>>
>>>
>>> --**--**
>>> -
>>> To unsubscribe, e-mail: 
>>> users-unsubscribe@tomcat.**apache.org
>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>
>>>
>>>
> = = =
> Nathan Potterndp at opendap.org
> OPeNDAP, Inc.+1.541.231.3317
>
>
>
>
>
> --**--**-
> To unsubscribe, e-mail: 
> users-unsubscribe@tomcat.**apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

RE: JspServlet - Unexpected behavior, possible bug...

> From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
> Subject: Re: JspServlet - Unexpected behavior, possible bug...

> On 10/17/2011 2:29 PM, Ann Ramsey wrote:
> > we figured it out - thank you

> What was the problem?

It appears Ms Ramsey is completely clueless concerning use of mailing lists...

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

Re: Is incoming connection request queue totally ordered?

Listen, the answers were all Greek to me. If you guys are going to REALLY
help non-IT people deal with TomCat, you might want to speak English in your
responses, so that we know if you're addressing our problem or not.

On Mon, Oct 17, 2011 at 2:53 PM, Caldarale, Charles R <
chuck.caldar...@unisys.com> wrote:

> > From: Ann Ramsey [mailto:ann.m.ram...@gmail.com]
> > Subject: Re: Is incoming connection request queue totally ordered?
>
> > Thank you - we figured it out.
>
> Besides learning how to ask questions in a reasonable manner, you also need
> to learn not to respond to threads completely unrelated to your topic.
>
>  - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
> MATERIAL and is thus for use only by the intended recipient. If you received
> this in error, please contact the sender and delete the e-mail and its
> attachments from all computers.
>
>

Re: Is incoming connection request queue totally ordered?

Caldarale, Charles R wrote:
From: André Warnier [mailto:a...@ice-sa.com] 
Subject: Re: Is incoming connection request queue totally ordered?

As ar as I know, this is something controlled by the TCP/IP 
stack of your host.  

And by network topology.

I was talking about what happens one the targeted server has received the connection 
request and queued it.  I believe that is also what the OP meant.

It is not dependent on Tomcat or Java.

Not necessarily true; Tomcat or the JVM could queue connect requests 
internally, and might not maintain order.  (I haven't looked at the code, so I 
don't know what actually happens.)

But yes, intuitively, it should always be a FIFO.

I don't think that assumption is warranted.  Given that different packets 
between a pair of IP nodes may take wildly different routes over the network, 
there's no guarantee on the order of arrival of TCP connection requests from a 
client to a server.

True.  But if we are talking about what happens when the connection requests (to a single 
interface) have actually been received and queued by the target server, I would still find 
it deliberately vicious on the part of the TCP/IP stack programmer to scramble the queuing 
order. Wouldn't you ?
And apart from being deliberately confusing, this would probably be more difficult to 
program, and create additional issues of contention. New requests could keep coming and 
starve much older requests.  Not saying it's not possible, but I wouldn't hire the guy who 
did this to design the watchdog system for a nuclear power plant.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: JspServlet - Unexpected behavior, possible bug...

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Nathan,

On 10/17/2011 12:47 PM, Nathan Potter wrote:
> - BUT, If I request a URL (without a trailing slash) that
> references an existing directory within the the JSP servlet's
> purview, I get an HTTP status 500 (Internal Server Error). 
> http://localhost:8080/test/jsp/foo
> 
> I think this is incorrect behavior.
> 
> When I do the same experiment with the default servlet I get an
> empty directory, but no error.
> 
> I looked at the Tomcat code referenced by the stack trace: 
> org.apache.jasper.JasperException: File "/jsp/foo" not found 
> org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:51)
>
>  
> org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:409)
>
>  
> org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:116)
>
>  
> org.apache.jasper.compiler.JspUtil.getInputStream(JspUtil.java:851)
>
> 
org.apache.jasper.xmlparser.XMLEncodingDetector.getEncoding(XMLEncodingDetector.java:108)
> 
> org.apache.jasper.compiler.ParserController.determineSyntaxAndEncoding(ParserController.java:348)
>
>  
> org.apache.jasper.compiler.ParserController.doParse(ParserController.java:207)
>
>  
> org.apache.jasper.compiler.ParserController.parseDirectives(ParserController.java:120)
>
>  
> org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:180)
>
> 
org.apache.jasper.compiler.Compiler.compile(Compiler.java:354)
> org.apache.jasper.compiler.Compiler.compile(Compiler.java:334) 
> org.apache.jasper.compiler.Compiler.compile(Compiler.java:321) 
> org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:592)
>
>  
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:328)
>
>  
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:313)
>
>  org.apache.jasper.servlet.JspServlet.service(JspServlet.java:260) 
> javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 
> And I can see that in JspServlet in lines 312 - 316:
> 
> try { wrapper.service(request, response, precompile); } catch
> (FileNotFoundException fnfe) { handleMissingResource(request,
> response, jspUri); }
> 
> The call is being serviced. Unfortunately when this problem occurs
> a "JasperException" is throw, not a FileNotFoundException and the 
> handleMissingResource() path way is skipped
> 
> Any thoughts? It strikes me that this situation is one that can
> easily be incurred by a type in the URL and so I don't that that an
> HTTP staus of 500 should be returned in this situation.

I'd be interested to see what else happened. It looks like JspServlet
is trying to compile the directory. The "file" (the directory) *does*
exist, so you don't get a FileNotFoundException. This seems like an
edge case that the JspServlet wasn't designed to handle.

So, I'd bet that this is a bug, but nobody cares but you. :)

What version are you using? The numbers don't match 7.0.x trunk, but I
was able to trace-through the call stack to here in JspUtils.java:

public static InputStream getInputStream(String fname, JarFile
jarFile,
JspCompilationContext ctxt, ErrorDispatcher err)
throws JasperException, IOException {

inputStream in = null;

if (jarFile != null) {
String jarEntryName = fname.substring(1, fname.length());
ZipEntry jarEntry = jarFile.getEntry(jarEntryName);
if (jarEntry == null) {
err.jspError("jsp.error.file.not.found", fname);
}
in = jarFile.getInputStream(jarEntry);
} else {
in = ctxt.getResourceAsStream(fname);
}

if (in == null) {
err.jspError("jsp.error.file.not.found", fname);
}

return in;
}

Looks like the null-checks here cause the problem you're seeing.

Either the JAR file containing the resource can't find a ZipEntry or
the ServletContext can't load a resource from the (disk, WAR, etc.).

ZipEntry returns null when asked for an input stream (that is, no
exception is thrown) for a directory, as does ServletContext.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6ciukACgkQ9CaO5/Lv0PCa2ACbBJIyTIt0hscpDhIRwaUI5MGl
S+4AnA9uGxXHJlP0bnxUASZLoWiZyHzy
=klJI
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [OT] JspServlet - Unexpected behavior, possible bug...

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ann,

On 10/17/2011 4:01 PM, Ann Ramsey wrote:
> Honestly, I'm just using another person's login. We don't really
> have an IT guy, so I don't understand all the responses. I really
> appreciate everyone responding though. You guys are very nice to
> respond!

It looks like you think every message is about your topic. This is a
multi-topic, high-volume mailing list. Be aware that other people are
discussing other things.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6ciyQACgkQ9CaO5/Lv0PCstQCggjMnFIi/fjMj/sourXTCBKfL
3nUAn0YQ6d5T69zckHMOmxU1dFM81Qkm
=DQvP
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Is incoming connection request queue totally ordered?

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chuck,

On 10/17/2011 3:42 PM, Caldarale, Charles R wrote:
>> From: André Warnier [mailto:a...@ice-sa.com] Subject: Re: Is
>> incoming connection request queue totally ordered?
> 
>> As ar as I know, this is something controlled by the TCP/IP
>> stack of your host.
> 
> And by network topology.

I think Andre was not considering network topology since the queue is
entirely on the server. Once the request has been received (or,
really, the first properly routable packet), it goes into *a* queue
which no longer depends on such factors.

>> But yes, intuitively, it should always be a FIFO.
> 
> I don't think that assumption is warranted.  Given that different 
> packets between a pair of IP nodes may take wildly different
> routes over the network, there's no guarantee on the order of
> arrival of TCP connection requests from a client to a server.

Assuming that the requests arrive at a server in a particular order
(in time), both Andre and Stevo are speculating that the
OS/JVM/connector queue(s) are all FIFOs, which is a reasonable
assumption unless the OS is doing some kind of QOS priority-queuing
based upon ... I dunno, maybe remote IP address or something like that.

Fairness isn't guaranteed at any level, really, but is probably a
reasonable assumption.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6cjBgACgkQ9CaO5/Lv0PDaugCffTrWNT7Jqg4xifscpAqm12cT
aw4An0wxqvHQ9sGae78tt2WhitcLt+tO
=iMvX
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Is incoming connection request queue totally ordered?

> From: Ann Ramsey [mailto:ann.m.ram...@gmail.com] 
> Subject: Re: Is incoming connection request queue totally ordered?

> Listen, the answers were all Greek to me. If you guys are 
> going to REALLY help non-IT people deal with TomCat, you 
> might want to speak English in your responses, so that we 
> know if you're addressing our problem or not.

Please learn how to use a mailing list.  There are many topics being discussed 
here, yours is only one of them.  Every time you respond to a topic unrelated 
to the issue you brought up, you're only annoying everyone and embarrassing 
yourself.  Learn to read the subject line, if nothing else.

No one has attempted to address your problem, since the question was incoherent 
and contained literally no useful information.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Is incoming connection request queue totally ordered?

Ann Ramsey wrote:

Listen, the answers were all Greek to me. If you guys are going to REALLY
help non-IT people deal with TomCat, you might want to speak English in your
responses, so that we know if you're addressing our problem or not.

Well, all I can say is that it doesn't really look like you've figured it out.
The way to use a mailing list, I mean.

Detailed explanation : after all the responses you have sent to various unrelated threads
on this mailing list, it has now become a bit confusing which problem was yours, and who
figured out what. You have probably also confused a number of other people who have asked
their own questions, but for which you have now answered (in their name) that you figured
it out, thank you.

A mailing list such as this one (and most other similar ones) is a bit different from a
chat forum. When someone has a question, they send a message, with a subject.
The people trying to help here (all volunteers, doing this on their own free time), answer
the questions individually, *by subject*, taking care to reply only to each message
individually, and preserving the original subject of the particular message to which they
are responding. That helps keeping things organised, so that the person who asked the
original question would actually find the answers to their own question, by looking at the
sequence of messages that have their original subject.

In other words, maybe what got you confused is that you thought that all these messages
were answering your original question, when in reality each one was answering another
question from someone else. Not so ?

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Error message - website login


Ann Ramsey wrote:

Can you help me with this error message please? All the other computers in
our office can get access - this is a client website, so I need help with my
computer.

Thanks,
Ann

 HTTP Status 403 - Access is denied
--

*type* Status report

*message* *Access is denied*

*description* *Access to the specified resource (Access is denied) has been
forbidden.*
--
Apache Tomcat/6.0.28


Ann,

Assuming this is your one and original question, and forgetting for the moment all the 
mis-targeted answers and messages,


The above error means :

1) that the Tomcat server which you are trying to access, for the URL that you are trying 
to access on it, has what is called "security constraints".
In other words, it can only be accessed by certain users after they login, or maybe only 
by certain workstations within a certain range of IP adresses or some similar constraint.


2) that the workstation which you are using does not meet these constraints, and as a 
result Tomcat rejects the access attempt.


More than this, one cannot say, because you do not provide enough information for anyone 
to say more.




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [OT] Is incoming connection request queue totally ordered?


P.S. (with additional apologies for the top-posting)
I realise that I have myself fallen as a victim of the confusion, and responded to the 
off-topic and off-thread message.

My apologies to the original poster of this thread.


André Warnier wrote:

Ann Ramsey wrote:

Listen, the answers were all Greek to me. If you guys are going to REALLY
help non-IT people deal with TomCat, you might want to speak English 
in your

responses, so that we know if you're addressing our problem or not.



Well, all I can say is that it doesn't really look like you've figured 
it out.

The way to use a mailing list, I mean.

Detailed explanation : after all the responses you have sent to various 
unrelated threads on this mailing list, it has now become a bit 
confusing which problem was yours, and who figured out what.  You have 
probably also confused a number of other people who have asked their own 
questions, but for which you have now answered (in their name) that you 
figured it out, thank you.


A mailing list such as this one (and most other similar ones) is a bit 
different from a chat forum.  When someone has a question, they send a 
message, with a subject.
The people trying to help here (all volunteers, doing this on their own 
free time), answer  the questions individually, *by subject*, taking 
care to reply only to each message individually, and preserving the 
original subject of the particular message to which they are 
responding.  That helps keeping things organised, so that the person who 
asked the original question would actually find the answers to their own 
question, by looking at the sequence of messages that have their 
original subject.


In other words, maybe what got you confused is that you thought that all 
these messages were answering your original question, when in reality 
each one was answering another question from someone else. Not so ?



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org





-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: JspServlet - Unexpected behavior, possible bug...

> From: Nathan Potter [mailto:npot...@opendap.org] 
> Subject: Re: JspServlet - Unexpected behavior, possible bug...

> Does that mean that you figured out what I was talking about or how to  
> correct/adjust the behavior?

No, but hopefully Ms Ramsey will now stop polluting the mailing list.  Let's go 
back to my original question:

> In my web application I need to utilize the JSP servlet, but
> I need to use a different servlet mapping:
> 
> jsp
> /jsp/*
> 

Before going any further, please explain why you think you need to do that.  
(I.e., what's the actual requirement?)

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: JspServlet - Unexpected behavior, possible bug...


Chuck,

I may not NEED to do it. It's just what I figured out to do.

Historically, the servlet that I am working with has been the default  
servlet. Tomcat's default servlet was used to serve docs from a  
subdirectory of the context dir, and everything else was dynamically  
generated by the default servlet. JSP was never used so no there was  
no issue there.


A new feature has been added to the web application that requires JSP.  
But because an alternative default servlet is defined, this disables  
the use of the JspServlet using the *.jsp url-pattern in the servlet  
mapping. (This may be caused by a failure to properly implement the  
alternate default servlet?? I don't know how to tell.)


Attempting to change back to the Tomcat default servlet will cause a  
change in the URL scheme of the web application, at least to the best  
of my understanding (because our servlet would now be mapped to some / 
name/* pattern).  Our installed user base will not accept a new  
version of product that requires all their URLs will to be different.  
This is probably even true w.r.t. changing the context name, but  
that's an installation decision not a mandate.


So all this brings me to say that the need is for my servlet to be the  
default servlet and I need JSP to work.



What I thought to do was:



hyrax
/*
/hyrax/*



jsp
/jsp/*
/admin/*
/error/*


Which worked, but when accessing the URL:

http://localhost:8080/myContext/admin

I would get back a 500 error.

And:

http://localhost:8080/myContext/admin/

Would return the (index.jsp) welcome page.

Now, one might argue that the first URL should 404, or one might argue  
that it should redirect to the 2nd URL. But I think it's a tough  
argument to make that it should return a 500 error.


And I didn't see anywhere in the documentation that said you SHOULDN'T  
use the JSP Servlet this way...


I wrote a work around by subclassing  
org.apache.jasper.servlet.JspServlet and wrapping/overriding the  
service() method with a check for the directory w/o the trailing slash  
condition and returning a redirect when it happens and passing the  
call down to super.service() when it doesn't. That works great, but I  
figured the 500 error wasn't a desired behavior so I wrote in to the  
list about it, as the documentation at Tomcat home indicated that all  
bug reports should begin here.



N









On Oct 17, 2011, at 11:14 AM, Caldarale, Charles R wrote:


From: Nathan Potter [mailto:npot...@opendap.org]
Subject: JspServlet - Unexpected behavior, possible bug...



In my web application I need to utilize the JSP servlet, but
I need to use a different servlet mapping:

jsp
/jsp/*



Before going any further, please explain why you think you need to  
do that.  (I.e., what's the actual requirement?)


- Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE  
PROPRIETARY MATERIAL and is thus for use only by the intended  
recipient. If you received this in error, please contact the sender  
and delete the e-mail and its attachments from all computers.



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



= = =
Nathan Potterndp at opendap.org
OPeNDAP, Inc.+1.541.231.3317





-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: JspServlet - Unexpected behavior, possible bug...



On Oct 17, 2011, at 1:07 PM, Christopher Schultz wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Nathan,

On 10/17/2011 12:47 PM, Nathan Potter wrote:

- BUT, If I request a URL (without a trailing slash) that
references an existing directory within the the JSP servlet's
purview, I get an HTTP status 500 (Internal Server Error).
http://localhost:8080/test/jsp/foo

I think this is incorrect behavior.

When I do the same experiment with the default servlet I get an
empty directory, but no error.

I looked at the Tomcat code referenced by the stack trace:
org.apache.jasper.JasperException: File "/jsp/foo" not found
org
.apache
.jasper
.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:51)


org
.apache
.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:409)


org
.apache
.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:116)


org.apache.jasper.compiler.JspUtil.getInputStream(JspUtil.java:851)



org
.apache
.jasper
.xmlparser.XMLEncodingDetector.getEncoding(XMLEncodingDetector.java: 
108)


org 
.apache 
.jasper 
.compiler 
.ParserController.determineSyntaxAndEncoding(ParserController.java: 
348)



org 
.apache 
.jasper.compiler.ParserController.doParse(ParserController.java:207)



org 
.apache 
.jasper 
.compiler.ParserController.parseDirectives(ParserController.java:120)



org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:180)



org.apache.jasper.compiler.Compiler.compile(Compiler.java:354)

org.apache.jasper.compiler.Compiler.compile(Compiler.java:334)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:321)
org 
.apache 
.jasper.JspCompilationContext.compile(JspCompilationContext.java:592)



org 
.apache 
.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:328)



org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java: 
313)


org.apache.jasper.servlet.JspServlet.service(JspServlet.java:260)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)

And I can see that in JspServlet in lines 312 - 316:

try { wrapper.service(request, response, precompile); } catch
(FileNotFoundException fnfe) { handleMissingResource(request,
response, jspUri); }

The call is being serviced. Unfortunately when this problem occurs
a "JasperException" is throw, not a FileNotFoundException and the
handleMissingResource() path way is skipped

Any thoughts? It strikes me that this situation is one that can
easily be incurred by a type in the URL and so I don't that that an
HTTP staus of 500 should be returned in this situation.


I'd be interested to see what else happened. It looks like JspServlet
is trying to compile the directory. The "file" (the directory) *does*
exist, so you don't get a FileNotFoundException. This seems like an
edge case that the JspServlet wasn't designed to handle.


Exactly. It tries to open the resource (in the case a directory) as a  
stream and that's when it errors into a JasperException






So, I'd bet that this is a bug, but nobody cares but you. :)

What version are you using? The numbers don't match 7.0.x trunk, but I
was able to trace-through the call stack to here in JspUtils.java:

   public static InputStream getInputStream(String fname, JarFile
jarFile,
   JspCompilationContext ctxt, ErrorDispatcher err)
   throws JasperException, IOException {

   inputStream in = null;

   if (jarFile != null) {
   String jarEntryName = fname.substring(1, fname.length());
   ZipEntry jarEntry = jarFile.getEntry(jarEntryName);
   if (jarEntry == null) {
   err.jspError("jsp.error.file.not.found", fname);
   }
   in = jarFile.getInputStream(jarEntry);
   } else {
   in = ctxt.getResourceAsStream(fname);
   }

   if (in == null) {
   err.jspError("jsp.error.file.not.found", fname);
   }

   return in;
   }

Looks like the null-checks here cause the problem you're seeing.

Either the JAR file containing the resource can't find a ZipEntry or
the ServletContext can't load a resource from the (disk, WAR, etc.).

ZipEntry returns null when asked for an input stream (that is, no
exception is thrown) for a directory, as does ServletContext.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6ciukACgkQ9CaO5/Lv0PCa2ACbBJIyTIt0hscpDhIRwaUI5MGl
S+4AnA9uGxXHJlP0bnxUASZLoWiZyHzy
=klJI
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



= = =
Nathan Potterndp at opendap.org
OPeNDAP, Inc.+1.541.231.3317





-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache

RE: Multiple war files for a single webapp or context

> From: Ziggy [mailto:zigg...@gmail.com] 
> Subject: Multiple war files for a single webapp or context

> If any of the files change (either the jsp, css, js or java 
> files) i have to always rebuild the whole war file.  This 
> means i deploy every single file on every release.

Why is that a problem?

> I am wondering if there is a way to deploy specific areas of 
> the application.

You might want to look at these:
http://tomcat.apache.org/tomcat-7.0-doc/config/resources.html
http://tomcat.apache.org/tomcat-7.0-doc/config/loader.html#VirtualWebappLoader_Implementation

> Using this approach, i will be able to deliver just the module 
> that was affected by the change.

Be careful; that sounds like a recipe for introducing inconsistencies.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [OT] Is incoming connection request queue totally ordered?

2011-10-17 Thread Stevo Slavić

Yes, I meant what happens once connection requests are in the queue,
regardless if it's AJP connection requests queue, or HTTP connection
requests. I wasn't considering that part, but thanks for clarifying,
if the two connectors (I guess it applies even if there are two
connectors for same protocol as long as they) share same executor
there's concurrency involved in using this shared resource.

Needed to understand how Tomcat handles connector connection requests
queues to determine whether request processing order can be
guaranteed.

Thank you all for once again great Tomcat community feedback!

Regards,
Stevo.

On Mon, Oct 17, 2011 at 10:39 PM, André Warnier  wrote:
> P.S. (with additional apologies for the top-posting)
> I realise that I have myself fallen as a victim of the confusion, and
> responded to the off-topic and off-thread message.
> My apologies to the original poster of this thread.
>
>
> André Warnier wrote:
>>
>> Ann Ramsey wrote:
>>>
>>> Listen, the answers were all Greek to me. If you guys are going to REALLY
>>> help non-IT people deal with TomCat, you might want to speak English in
>>> your
>>> responses, so that we know if you're addressing our problem or not.
>>>
>>
>> Well, all I can say is that it doesn't really look like you've figured it
>> out.
>> The way to use a mailing list, I mean.
>>
>> Detailed explanation : after all the responses you have sent to various
>> unrelated threads on this mailing list, it has now become a bit confusing
>> which problem was yours, and who figured out what.  You have probably also
>> confused a number of other people who have asked their own questions, but
>> for which you have now answered (in their name) that you figured it out,
>> thank you.
>>
>> A mailing list such as this one (and most other similar ones) is a bit
>> different from a chat forum.  When someone has a question, they send a
>> message, with a subject.
>> The people trying to help here (all volunteers, doing this on their own
>> free time), answer  the questions individually, *by subject*, taking care to
>> reply only to each message individually, and preserving the original subject
>> of the particular message to which they are responding.  That helps keeping
>> things organised, so that the person who asked the original question would
>> actually find the answers to their own question, by looking at the sequence
>> of messages that have their original subject.
>>
>> In other words, maybe what got you confused is that you thought that all
>> these messages were answering your original question, when in reality each
>> one was answering another question from someone else. Not so ?
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: [OT] Is incoming connection request queue totally ordered?

> From: Stevo Slavić [mailto:ssla...@gmail.com] 
> Subject: Re: [OT] Is incoming connection request queue totally ordered?

> Needed to understand how Tomcat handles connector connection 
> requests queues to determine whether request processing order
> can be guaranteed.

The point I was trying to make is that the order they're processed in Tomcat or 
the JVM is moot, since you can't guarantee the order in which they arrive at 
the server on which Tomcat is running.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: JspServlet - Unexpected behavior, possible bug...

> From: Nathan Potter [mailto:npot...@opendap.org] 
> Subject: Re: JspServlet - Unexpected behavior, possible bug...

> A new feature has been added to the web application that requires
> JSP.  But because an alternative default servlet is defined, this
> disables the use of the JspServlet using the *.jsp url-pattern in
> the servlet mapping.

O.k., now I think I understand the problem: the servlet spec requires matching 
of "/*" before "*.jsp", so hyrax sees the JSP requests as well as the ones it 
should get.  But rather than try remapping the JSP servlet, perhaps something 
like the UrlRewriteFilter (http://www.tuckey.org/urlrewrite/) might be more 
appropriate.  You could set the mapping for hyrax to just "/hyrax/*" (removing 
"/*") and configure the filter to redirect or forward appropriate requests to 
the /hyrax path.  Everything else could remain unchanged.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: JspServlet - Unexpected behavior, possible bug...

On Oct 17, 2011, at 5:38 PM, Caldarale, Charles R wrote:

From: Nathan Potter [mailto:npot...@opendap.org]
Subject: Re: JspServlet - Unexpected behavior, possible bug...

A new feature has been added to the web application that requires
JSP.  But because an alternative default servlet is defined, this
disables the use of the JspServlet using the *.jsp url-pattern in
the servlet mapping.

O.k., now I think I understand the problem: the servlet spec  
requires matching of "/*" before "*.jsp", so hyrax sees the JSP  
requests as well as the ones it should get.  But rather than try  
remapping the JSP servlet, perhaps something like the  
UrlRewriteFilter (http://www.tuckey.org/urlrewrite/) might be more  
appropriate.  You could set the mapping for hyrax to just "/hyrax/ 
*" (removing "/*") and configure the filter to redirect or forward  
appropriate requests to the /hyrax path.

I don't see how to do it without using a rewrite rule for every thing  
in the top level collection of URL's. I think if you try to rewrite  
the root of the context that it's going to disable other services you  
have running.

The problem is that you're rewriting "/context/" to "/context/hyrax"  
so stuff that was being served from things other than the default  
servlet (hyrax) such as "/docs" are going to get rewritten too. I  
don't see how a rewrite rule can avoid that

For example - I have a servlet mapped to the url-pattern "/gateway/*",  
and previously it's URL was http:/localhost:8080/contextName/gateway  
if we rewrite /contextName/ -> /contextName/hyrax then the old gateway  
url will be getting serviced here:  http:/localhost:8080/contextName/ 
hyrax/gateway

Am I mistaken in this?

Nathan

Everything else could remain unchanged.

- Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE  
PROPRIETARY MATERIAL and is thus for use only by the intended  
recipient. If you received this in error, please contact the sender  
and delete the e-mail and its attachments from all computers.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

= = =
Nathan Potterndp at opendap.org
OPeNDAP, Inc.+1.541.231.3317

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: JspServlet - Unexpected behavior, possible bug...

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Nathan,

On 10/17/2011 4:50 PM, Nathan Potter wrote:
> Historically, the servlet that I am working with has been the
> default servlet. Tomcat's default servlet was used to serve docs
> from a subdirectory of the context dir, and everything else was
> dynamically generated by the default servlet. JSP was never used so
> no there was no issue there.

I'm guessing that "the default servlet" really has at least two
meanings above.. it's not at all clear what you're talking about.

> A new feature has been added to the web application that requires
> JSP. But because an alternative default servlet is defined, this
> disables the use of the JspServlet using the *.jsp url-pattern in
> the servlet mapping. (This may be caused by a failure to properly
> implement the alternate default servlet?? I don't know how to
> tell.)

Wait, what? Changing the default servlet un-maps the JSP servlet?
Something must be wrong with your configuration.

> What I thought to do was:
> 
>  hyrax 
> /* /hyrax/* 
> 

FYI those two mappings are redundant: /* includes /hyrax/*. A "*"
doesn't mean "anything but a /", it indicates that anything that
starts with "/hyrax/" should be mapped to the "hyrax" servlet. URL
mappings in web.xml aren't as expressive as just about anyone would
like them to be. Specifically, they are neither simple globs nor are
they regular expressions.

>  jsp 
> /jsp/* 
> /admin/* 
> /error/* 

What's wrong with the default, which is "/*.jsp" for the JSP servlet?
Do you have files with the .jsp extension that you need served without
actually invoking the JSP servlet?

> Which worked, but when accessing the URL:
> 
> http://localhost:8080/myContext/admin
> 
> I would get back a 500 error.

So don't do that :)

> And:
> 
> http://localhost:8080/myContext/admin/
> 
> Would return the (index.jsp) welcome page.

I would have expected an error, same as above.

> Now, one might argue that the first URL should 404, or one might
> argue that it should redirect to the 2nd URL. But I think it's a
> tough argument to make that it should return a 500 error.

If you implemented your default servlet in the same way that Tomcat's
is done, then a redirect from /admin -> /admin/ will occur. It looks
like you haven't done that. But, if you haven't, then why does the JSP
servlet get invoked? You mapped it to "/admin/*", not to "/admin"...

> And I didn't see anywhere in the documentation that said you
> SHOULDN'T use the JSP Servlet this way...
> 
> I wrote a work around by subclassing 
> org.apache.jasper.servlet.JspServlet and wrapping/overriding the 
> service() method with a check for the directory w/o the trailing
> slash condition and returning a redirect when it happens and
> passing the call down to super.service() when it doesn't. That
> works great, but I figured the 500 error wasn't a desired behavior
> so I wrote in to the list about it, as the documentation at Tomcat
> home indicated that all bug reports should begin here.

Let's see the change you made. It might not work under all circumstances.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6cz5AACgkQ9CaO5/Lv0PAs0ACfUhNocwUmqavtJ8ilBn5QZPBT
kscAnjRDeapkGccOE4MvsWVqoteuN7wK
=IgYU
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: JspServlet - Unexpected behavior, possible bug...

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Nathan,

On 10/17/2011 8:56 PM, Nathan Potter wrote:
> I don't see how to do it without using a rewrite rule for every
> thing in the top level collection of URL's. I think if you try to
> rewrite the root of the context that it's going to disable other
> services you have running.

Note that Tomcat maps DefaultServlet to "/" and not to "/*". You could
try that mapping to see if the JSP stuff clears up. You really
shouldn't need to re-map *.jsp.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6c0A8ACgkQ9CaO5/Lv0PB12ACgl9m85VUJg0V8p29xBPNtSitD
Y9AAoI0aBURjb3cxlL23uwpI6s7HxNUQ
=wytw
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: JspServlet - Unexpected behavior, possible bug...

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Nathan,

On 10/17/2011 4:53 PM, Nathan Potter wrote:
> On Oct 17, 2011, at 1:07 PM, Christopher Schultz wrote:
> 
>> I'd be interested to see what else happened. It looks like 
>> JspServlet is trying to compile the directory. The "file" (the 
>> directory) *does* exist, so you don't get a
>> FileNotFoundException. This seems like an edge case that the
>> JspServlet wasn't designed to handle.
> 
> Exactly. It tries to open the resource (in the case a directory) as
> a stream and that's when it errors into a JasperException .

No, it doesn't cause an error to open the stream: the stream comes
back null and Tomcat interprets that as an error: just not the one you
expected (JasperException instead of FileNotFoundException).

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6c0XkACgkQ9CaO5/Lv0PD+fQCfWi3oonLEgvY9P/iD2hDJW7Fs
hKEAn1czpFZF2j7pwldKrz1bl8CcJBMG
=gRHl
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [OT] Is incoming connection request queue totally ordered?

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chuck,

On 10/17/2011 5:57 PM, Caldarale, Charles R wrote:
>> From: Stevo Slavić [mailto:ssla...@gmail.com] Subject: Re: [OT]
>> Is incoming connection request queue totally ordered?
> 
>> Needed to understand how Tomcat handles connector connection 
>> requests queues to determine whether request processing order can
>> be guaranteed.
> 
> The point I was trying to make is that the order they're processed
> in Tomcat or the JVM is moot, since you can't guarantee the order
> in which they arrive at the server on which Tomcat is running.

+1

- -chris

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6c0dQACgkQ9CaO5/Lv0PAoXwCeMG/nB4dIDBfktIjLrAf/fNuA
XBsAn2zu/xMlzj+2qa3RJJij/dVH2zV8
=+5Xc
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: JspServlet - Unexpected behavior, possible bug...



On Oct 17, 2011, at 6:00 PM, Christopher Schultz wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Nathan,

On 10/17/2011 4:50 PM, Nathan Potter wrote:

Historically, the servlet that I am working with has been the
default servlet. Tomcat's default servlet was used to serve docs
from a subdirectory of the context dir, and everything else was
dynamically generated by the default servlet. JSP was never used so
no there was no issue there.


I'm guessing that "the default servlet" really has at least two
meanings above.. it's not at all clear what you're talking about.


Oh sorry, by default servlet I mean the servlet mapped to "/" or "/*"  
in the web application. I've been trying to say the "tomcat default  
servlet" if I mean org.apache.catalina.servlets.DefaultServlet. I'll  
try to more more explicit.



A new feature has been added to the web application that requires
JSP. But because an alternative default servlet is defined, this
disables the use of the JspServlet using the *.jsp url-pattern in
the servlet mapping. (This may be caused by a failure to properly
implement the alternate default servlet?? I don't know how to
tell.)


Wait, what? Changing the default servlet un-maps the JSP servlet?
Something must be wrong with your configuration.







What I thought to do was:

 hyrax
/* /hyrax/*



FYI those two mappings are redundant: /* includes /hyrax/*. A "*"
doesn't mean "anything but a /", it indicates that anything that
starts with "/hyrax/" should be mapped to the "hyrax" servlet. URL
mappings in web.xml aren't as expressive as just about anyone would
like them to be. Specifically, they are neither simple globs nor are
they regular expressions.


You would think that they would be redundant but in fact the server  
behaves differently if you use them both.

Having both means that you the same page here:

context/

and here:

context/hyrax/

Which has been the expected behavior.







 jsp
/jsp/*
/admin/*
/error/* 


What's wrong with the default, which is "/*.jsp" for the JSP servlet?
Do you have files with the .jsp extension that you need served without
actually invoking the JSP servlet?


No, but if you assign a servlet to "/" or "/*" it gets call  
foreverything before anything starting with "*". Basically starts with  
"/" trumps starts with "*" when applying url patterns.





Which worked, but when accessing the URL:

http://localhost:8080/myContext/admin

I would get back a 500 error.


So don't do that :)


:)




And:

http://localhost:8080/myContext/admin/

Would return the (index.jsp) welcome page.


I would have expected an error, same as above.


index.jsp is in the welcome-file-list and apparently the JspServlet is  
good with that.






Now, one might argue that the first URL should 404, or one might
argue that it should redirect to the 2nd URL. But I think it's a
tough argument to make that it should return a 500 error.


If you implemented your default servlet in the same way that Tomcat's
is done, then a redirect from /admin -> /admin/ will occur.


It is sort of like tomcat but different.

But this is the point. Look at the stack trace. The error is coming  
from the Jasper JspServlet - my code is not being called. The  
JspServlet is getting tapped to respond to the request URL http://localhost:8080/contextName/admin




It looks
like you haven't done that. But, if you haven't, then why does the JSP
servlet get invoked? You mapped it to "/admin/*", not to "/admin"...


That's the question isn't it




And I didn't see anywhere in the documentation that said you
SHOULDN'T use the JSP Servlet this way...

I wrote a work around by subclassing
org.apache.jasper.servlet.JspServlet and wrapping/overriding the
service() method with a check for the directory w/o the trailing
slash condition and returning a redirect when it happens and
passing the call down to super.service() when it doesn't. That
works great, but I figured the 500 error wasn't a desired behavior
so I wrote in to the list about it, as the documentation at Tomcat
home indicated that all bug reports should begin here.


Let's see the change you made. It might not work under all  
circumstances.


Oh I'm sure it won't. It's a work around, not a patch by any means.  
Here's the important part:


public class JspServlet extends org.apache.jasper.servlet.JspServlet {

public void service(HttpServletRequest request,  
HttpServletResponse response) throws IOException, ServletException {


String jspUri  = request.getServletPath();

String pathInfo = request.getPathInfo();
if (pathInfo != null) {
jspUri += pathInfo;
}
String realPath =   context.getRealPath(jspUri);


File f = new File(realPath);

if(f.exists()  &&  f.isDirectory()) {
String contextPath = context.getContextPath();
StringBuilder redirectUrl = new  
StringBuilder().append(contextPath).append(jspUri).append("/");


response.sendRedirec

Re: JspServlet - Unexpected behavior, possible bug...

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Nathan,

On 10/17/2011 9:21 PM, Nathan Potter wrote:
> No, but if you assign a servlet to "/" or "/*" it gets call 
> foreverything before anything starting with "*". Basically starts
> with "/" trumps starts with "*" when applying url patterns.

If I'm reading that right (read it 5 or 6 times to just be sure I thin
I understand it), you are saying that:

a. Mapping Tomcat's DefaultServlet to "/" and
b. Mapping Tomcat's JSP Servlet to "*.jsp"

will result in DefaultServlet serving all content, and the JSP servlet
never running.

Since that's the default configuration described above and JSPs and
static content certainly do work properly under the default
configuration, I must (still) be reading that incorrectly.

> But this is the point. Look at the stack trace. The error is coming
> from the Jasper JspServlet - my code is not being called. The
> JspServlet is getting tapped to respond to the request URL 
> http://localhost:8080/contextName/admin

So there is no redirect going on? Obviously, redirects don't show in
stack traces...

>> It looks like you haven't done that. But, if you haven't, then
>> why does the JSP servlet get invoked? You mapped it to
>> "/admin/*", not to "/admin"...
> 
> That's the question isn't it

You didn't post the entire stack trace, so it's hard to tell.

>> Let's see the change you made. It might not work under all
>> circumstances.
> 
> Oh I'm sure it won't. It's a work around, not a patch by any
> means. Here's the important part:
> 
> public class JspServlet extends
> org.apache.jasper.servlet.JspServlet {
> 
> public void service(HttpServletRequest request,
> HttpServletResponse response) throws IOException, ServletException
> {
> 
> String jspUri  = request.getServletPath();
> 
> String pathInfo = request.getPathInfo(); if (pathInfo != null) { 
> jspUri += pathInfo; } String realPath =
> context.getRealPath(jspUri);
> 
> File f = new File(realPath);

Oh, yeah, that definitely won't work: calling getRealPath isn't
reliable because you can't guarantee a "real" filesystem supporting
the webapp. It would be better to call ServletContext.getResource() or
something like that.

>> if(f.exists()  &&  f.isDirectory()) {

Without a java.io.File, this is of course impossible.

Any fix should probably be applied in JspUtils.getInputStream. I'm not
a big fan of throwing FileNotFoundException for things that aren't
java.io.File objects (ignoring the Java API's behavior :) but I wonder
if a subclass of JasperException could be used in these situations.

In the case of the ZipEntry, you can ask a ZipEntry if it's a
directory: if so, maybe an even more explicit exception could be
thrown. When a ZipEntry isn't involved (e.g. serving directly off the
filesystem where the URI results in an attempt to get a stream for a
directory), it's less clear what to do other than throwing a
JasperFileNotFoundException or whatever.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6c2AAACgkQ9CaO5/Lv0PDdowCgiXGwX0c523f/jzgH7psJD761
Fb8An2V4nhD7xFbKfkdxl75jxTvtPrSn
=cLPU
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: JspServlet - Unexpected behavior, possible bug...

> From: Nathan Potter [mailto:npot...@opendap.org] 
> Subject: Re: JspServlet - Unexpected behavior, possible bug...

> by default servlet I mean the servlet mapped to "/" or "/*"  

And right there is your terminology problem.  The default servlet is the one 
mapped to "/"; anything mapped to "/*" is _not_ the default servlet, but due to 
servlet spec rules, it will receive all otherwise unmatched requests, since 
"/*" is a longer string than "/"; the default servlet will never see any 
requests in this case.

> Having both means that you the same page here:
>  context/
> and here:
>  context/hyrax/
> Which has been the expected behavior.

Assuming that the word left out of the first sentence is "see" (or equivalent), 
the "/hyrax" mapping is still redundant; removing it will still get a match due 
to "/*" for the hyrax servlet.

> No, but if you assign a servlet to "/" or "/*" it gets call  
> foreverything before anything starting with "*".

Not true; "/*" will beat "*.jsp", but "/" does not beat "*.jsp".  Check the 
rules in the spec.

Maybe we need to see all of your servlet mappings in your web.xml.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

[ANN] PSI Probe 2.3.0 has Tomcat 7 support

2011-10-17 Thread Mark Lewis

All,

PSI Probe 2.3.0 was just released.  This latest version includes support for
Tomcat 7, a Spanish translation, and a number of other improvements.

There is more information on our Google Code project page:
http://code.google.com/p/psi-probe/

- Mark

RE: JspServlet - Unexpected behavior, possible bug...

> From: Nathan Potter [mailto:npot...@opendap.org] 
> Subject: Re: JspServlet - Unexpected behavior, possible bug...

> I don't see how to do it without using a rewrite rule for 
> every thing in the top level collection of URL's.

You only need to have the filter invoked when the true DefaultServlet would 
have been, so it would handle only otherwise unmatched requests.  Use the 
 element rather than  inside the , 
specifying "default" as the value.  Leave the hyrax servlet mapped to 
"/hyrax/*" (and possibly "/hyrax"), the DefaultServlet at "/", the JspServlet 
at "*.jsp", and have the filter adjust the path only if it's something you want 
hyrax to process.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: JspServlet - Unexpected behavior, possible bug...

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chuck,

On 10/17/2011 10:11 PM, Caldarale, Charles R wrote:
>> From: Nathan Potter [mailto:npot...@opendap.org] Subject: Re:
>> JspServlet - Unexpected behavior, possible bug...
> 
>> I don't see how to do it without using a rewrite rule for every
>> thing in the top level collection of URL's.
> 
> You only need to have the filter invoked when the true
> DefaultServlet would have been, so it would handle only otherwise
> unmatched requests.  Use the  element rather than
>  inside the , specifying "default" as
> the value. Leave the hyrax servlet mapped to "/hyrax/*" (and
> possibly "/hyrax"), the DefaultServlet at "/", the JspServlet at
> "*.jsp", and have the filter adjust the path only if it's something
> you want hyrax to process.

I'm not entirely sure, but that may require Nathan to explicitly
define define Tomcat's DefaultServlet in his own web.xml file. I seem
to recall having to explicitly define the JspServlet for certain
things (maybe just for init-params).

Nathan, if you try to use default in your
 and Tomcat throws an exception or just doesn't see
like it's working, try explicitly defining (and mapping) Tomcat's
DefaultServlet in your own web.xml.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6c6CUACgkQ9CaO5/Lv0PAV2wCfYHSe9Wnk+fQMxiMTIi9+zw1+
5EoAnj9tzaFSnw4iqLLvE42gkPPp4TPo
=ZblJ
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [ANN] PSI Probe 2.3.0 has Tomcat 7 support

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mark,

On 10/17/2011 9:55 PM, Mark Lewis wrote:
> PSI Probe 2.3.0 was just released.  This latest version includes
> support for Tomcat 7, a Spanish translation, and a number of other
> improvements.

Great to hear that PSI Probe (née Lambda Probe) is still alive and
kicking. Keep up the good work!

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6c6HkACgkQ9CaO5/Lv0PBYEwCglC/DDZpUO12qUxZcGumpvoa3
xXQAn0TYYeVr+Ow9UnRP74QRKygp0AiJ
=PeFp
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: JspServlet - Unexpected behavior, possible bug...



On Oct 17, 2011, at 6:08 PM, Christopher Schultz wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Nathan,

On 10/17/2011 4:53 PM, Nathan Potter wrote:

On Oct 17, 2011, at 1:07 PM, Christopher Schultz wrote:


I'd be interested to see what else happened. It looks like
JspServlet is trying to compile the directory. The "file" (the
directory) *does* exist, so you don't get a
FileNotFoundException. This seems like an edge case that the
JspServlet wasn't designed to handle.


Exactly. It tries to open the resource (in the case a directory) as
a stream and that's when it errors into a JasperException .


No, it doesn't cause an error to open the stream: the stream comes
back null and Tomcat interprets that as an error: just not the one you
expected (JasperException instead of FileNotFoundException).




Well the pint I was making was that it wasn't the one that  
org.apache.jasper.servlet.JspServlet was expecting, thus causing the  
500 response.


- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6c0XkACgkQ9CaO5/Lv0PD+fQCfWi3oonLEgvY9P/iD2hDJW7Fs
hKEAn1czpFZF2j7pwldKrz1bl8CcJBMG
=gRHl
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



= = =
Nathan Potterndp at opendap.org
OPeNDAP, Inc.+1.541.231.3317





-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: JspServlet - Unexpected behavior, possible bug...

On Oct 17, 2011, at 6:41 PM, Caldarale, Charles R wrote:

From: Nathan Potter [mailto:npot...@opendap.org]
Subject: Re: JspServlet - Unexpected behavior, possible bug...

by default servlet I mean the servlet mapped to "/" or "/*"

And right there is your terminology problem.  The default servlet is  
the one mapped to "/"; anything mapped to "/*" is _not_ the default  
servlet, but due to servlet spec rules, it will receive all  
otherwise unmatched requests, since "/*" is a longer string than  
"/"; the default servlet will never see any requests in this case.

OK, I guess I wasn't clear on the details of this. That precisely fits  
the behaviors I have been seeing.

Having both means that you the same page here:
context/
and here:
context/hyrax/
Which has been the expected behavior.

Assuming that the word left out of the first sentence is "see" (or  
equivalent), the "/hyrax" mapping is still redundant; removing it  
will still get a match due to "/*" for the hyrax servlet.

That's true - but the webapp will not return the same page as context/

I realize that this is truly perverse, but the idea is that you get  
the same exact page both an contex/ and context/hyrax/  the reason you  
don't is because the hyrax servlet returns pages that allow the user  
to browse a directed graph of holdings. When you leave out the /hyrax/ 
* mapping then the url that ends in context/ will return the top of  
these holdings ("/"in a relative sense), and the url that ends in  
context/hyrax/ will return the holdings (if they exisit) for the top  
level collection called hyrax ("/hyrax/"). The desired result is for  
both context/ and context/hyrax/ to return the exact same page, the  
top ("/") of the hyrax servlets holdings.

No, but if you assign a servlet to "/" or "/*" it gets call
foreverything before anything starting with "*".

Not true; "/*" will beat "*.jsp", but "/" does not beat "*.jsp".   
Check the rules in the spec.

I did in fact read the spec. but I guess I didn't fully get this bit.

Maybe we need to see all of your servlet mappings in your web.xml.

- Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE  
PROPRIETARY MATERIAL and is thus for use only by the intended  
recipient. If you received this in error, please contact the sender  
and delete the e-mail and its attachments from all computers.

= = =
Nathan Potterndp at opendap.org
OPeNDAP, Inc.+1.541.231.3317

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: JspServlet - Unexpected behavior, possible bug...



On Oct 17, 2011, at 6:36 PM, Christopher Schultz wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Nathan,

On 10/17/2011 9:21 PM, Nathan Potter wrote:

No, but if you assign a servlet to "/" or "/*" it gets call
foreverything before anything starting with "*". Basically starts
with "/" trumps starts with "*" when applying url patterns.


If I'm reading that right (read it 5 or 6 times to just be sure I thin
I understand it), you are saying that:

a. Mapping Tomcat's DefaultServlet to "/" and
b. Mapping Tomcat's JSP Servlet to "*.jsp"

will result in DefaultServlet serving all content, and the JSP servlet
never running.


Almost. When I map our servlet to "/*".  Then we see the problem.



Since that's the default configuration described above and JSPs and
static content certainly do work properly under the default
configuration, I must (still) be reading that incorrectly.


But this is the point. Look at the stack trace. The error is coming
from the Jasper JspServlet - my code is not being called. The
JspServlet is getting tapped to respond to the request URL
http://localhost:8080/contextName/admin


So there is no redirect going on? Obviously, redirects don't show in
stack traces...


I brought all the tomcat code into my IDE and set break points and all  
that - my code is not accessed.






It looks like you haven't done that. But, if you haven't, then
why does the JSP servlet get invoked? You mapped it to
"/admin/*", not to "/admin"...


That's the question isn't it


You didn't post the entire stack trace, so it's hard to tell.


I haven't been able to figure out how to get that to appear in the  
Tomcat log. I use the logback log4j package and I have turned on  
logging and added appenders fro org.apache and turned it up to all and  
I haven't gotten any output...






Let's see the change you made. It might not work under all
circumstances.


Oh I'm sure it won't. It's a work around, not a patch by any
means. Here's the important part:

public class JspServlet extends
org.apache.jasper.servlet.JspServlet {

public void service(HttpServletRequest request,
HttpServletResponse response) throws IOException, ServletException
{

String jspUri  = request.getServletPath();

String pathInfo = request.getPathInfo(); if (pathInfo != null) {
jspUri += pathInfo; } String realPath =
context.getRealPath(jspUri);

File f = new File(realPath);


Oh, yeah, that definitely won't work: calling getRealPath isn't
reliable because you can't guarantee a "real" filesystem supporting
the webapp. It would be better to call ServletContext.getResource() or
something like that.


if(f.exists()  &&  f.isDirectory()) {


Without a java.io.File, this is of course impossible.

Any fix should probably be applied in JspUtils.getInputStream. I'm not
a big fan of throwing FileNotFoundException for things that aren't
java.io.File objects (ignoring the Java API's behavior :) but I wonder
if a subclass of JasperException could be used in these situations.

In the case of the ZipEntry, you can ask a ZipEntry if it's a
directory: if so, maybe an even more explicit exception could be
thrown. When a ZipEntry isn't involved (e.g. serving directly off the
filesystem where the URI results in an attempt to get a stream for a
directory), it's less clear what to do other than throwing a
JasperFileNotFoundException or whatever.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6c2AAACgkQ9CaO5/Lv0PDdowCgiXGwX0c523f/jzgH7psJD761
Fb8An2V4nhD7xFbKfkdxl75jxTvtPrSn
=cLPU
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



= = =
Nathan Potterndp at opendap.org
OPeNDAP, Inc.+1.541.231.3317





-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: JspServlet - Unexpected behavior, possible bug...

On Oct 17, 2011, at 7:11 PM, Caldarale, Charles R wrote:

From: Nathan Potter [mailto:npot...@opendap.org]
Subject: Re: JspServlet - Unexpected behavior, possible bug...

I don't see how to do it without using a rewrite rule for
every thing in the top level collection of URL's.

You only need to have the filter invoked when the true  
DefaultServlet would have been, so it would handle only otherwise  
unmatched requests.
Use the  element rather than  inside the  
, specifying "default" as the value.  Leave the  
hyrax servlet mapped to "/hyrax/*" (and possibly "/hyrax"), the  
DefaultServlet at "/", the JspServlet at "*.jsp", and have the  
filter adjust the path only if it's something you want hyrax to  
process.

So is the idea to identify to the filter: "These are the things for  
the org.apache.catalina.servlets.DefaultServlet" and then send  
everything else to Hyrax? Can it be configured like that?

- Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE  
PROPRIETARY MATERIAL and is thus for use only by the intended  
recipient. If you received this in error, please contact the sender  
and delete the e-mail and its attachments from all computers.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

= = =
Nathan Potterndp at opendap.org
OPeNDAP, Inc.+1.541.231.3317

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: JspServlet - Unexpected behavior, possible bug...



On Oct 17, 2011, at 7:44 PM, Christopher Schultz wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chuck,

On 10/17/2011 10:11 PM, Caldarale, Charles R wrote:

From: Nathan Potter [mailto:npot...@opendap.org] Subject: Re:
JspServlet - Unexpected behavior, possible bug...



I don't see how to do it without using a rewrite rule for every
thing in the top level collection of URL's.


You only need to have the filter invoked when the true
DefaultServlet would have been, so it would handle only otherwise
unmatched requests.  Use the  element rather than
 inside the , specifying "default" as
the value. Leave the hyrax servlet mapped to "/hyrax/*" (and
possibly "/hyrax"), the DefaultServlet at "/", the JspServlet at
"*.jsp", and have the filter adjust the path only if it's something
you want hyrax to process.


I'm not entirely sure, but that may require Nathan to explicitly
define define Tomcat's DefaultServlet in his own web.xml file. I seem
to recall having to explicitly define the JspServlet for certain
things (maybe just for init-params).

Nathan, if you try to use default in your
 and Tomcat throws an exception or just doesn't see
like it's working, try explicitly defining (and mapping) Tomcat's
DefaultServlet in your own web.xml.




OK thanks!




- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6c6CUACgkQ9CaO5/Lv0PAV2wCfYHSe9Wnk+fQMxiMTIi9+zw1+
5EoAnj9tzaFSnw4iqLLvE42gkPPp4TPo
=ZblJ
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



= = =
Nathan Potterndp at opendap.org
OPeNDAP, Inc.+1.541.231.3317





-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: JspServlet - Unexpected behavior, possible bug...



On Oct 17, 2011, at 6:02 PM, Christopher Schultz wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Nathan,

On 10/17/2011 8:56 PM, Nathan Potter wrote:

I don't see how to do it without using a rewrite rule for every
thing in the top level collection of URL's. I think if you try to
rewrite the root of the context that it's going to disable other
services you have running.


Note that Tomcat maps DefaultServlet to "/" and not to "/*". You could
try that mapping to see if the JSP stuff clears up. You really
shouldn't need to re-map *.jsp.


That breaks a bunch of other stuff because of the changes in the  
responses to methods in HttpServletRequest.


:(



- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6c0A8ACgkQ9CaO5/Lv0PB12ACgl9m85VUJg0V8p29xBPNtSitD
Y9AAoI0aBURjb3cxlL23uwpI6s7HxNUQ
=wytw
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



= = =
Nathan Potterndp at opendap.org
OPeNDAP, Inc.+1.541.231.3317





-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: JspServlet - Unexpected behavior, possible bug...