context loaded twice
hi, a strange thing i can't find a sollution for. i have a web app that runs in tomcat's root (placed in \webapps\ROOT). don't ask me why, it's just there. the controller servlet of the app has 1.. it also prints in output "START INIT" when loaded. when i start tomcat i see this: code: Apache Tomcat/4.1.31WebappLoader[]: Deploying class repositories to work directory C:\jakarta-tomcat-4.1.31\webapps\ROOT\work\org\apache\jspWebappLoader[]: Deploy class files /WEB-INF/classes to C:\jakarta-tomcat-4.1.31\webapps\ROOT\WEB-INF\classesWebappLoader[]: Reloading checks are enabled for this ContextStandardManager[]: Seeding random number generator class java.security.SecureRandomStandardManager[]: Seeding of random number generator has been completedStandardWrapper[ efault]: Loading container servlet defaultSTART INIT and then once more the same thing: code: WebappLoader[/]: Deploying class repositories to work directory C:\jakarta-tomcat-4.1.31\webapps\ROOT\work\org\apache\jspWebappLoader[/]: Deploy class files /WEB-INF/classes to C:\jakarta-tomcat-4.1.31\webapps\ROOT\WEB-INF\classesWebappLoader[/]: Reloading checks are enabled for this ContextStandardManager[/]: Seeding random number generator class java.security.SecureRandomStandardManager[/]: Seeding of random number generator has been completedStandardWrapper[/ efault]: Loading container servlet defaultSTART INIT tomcat not only prints the report twice, it loads the webapp twice, because right after the second time i get a nasty exception: code: ServerLifecycleListener: processContainerAddChild: Throwablejavax.management.InstanceAlreadyExistsException: Catalina:type=Context,path=/,host=localhost,service=Tomcat-Standalone at mx4j.server.MBeanServerImpl.register(MBeanServerImpl.java:1123) at mx4j.server.MBeanServerImpl.registerImpl(MBeanServerImpl.java:1054) at mx4j.server.MBeanServerImpl.registerMBeanImpl(MBeanServerImpl.java:1002) at mx4j.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:978) tomcat doesn't die, and the application runs ok. but still, i don't wanna leave it as it is,, knowing that something is wrong. any ideas? thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: session invalidation
hey jake and others, thanks for help.
i tried the same code on tc5.0.25 and it has the same
problem as tv 5.0.16.
the debugging showed that when i enter a site after
the session should be already invalidated,
the request passes the filter including the code block
that checks if session is valid.
from there it ccontinues as if the session would be
still alive and kicking. actually, it's still
alive . the session bound attributes are still
available and the redirections are made with the same
jsessionid in the rewrited url as earlier.
as i wrote, with cookies based session tracking (no
url rewriting) everything works fine.
the filter in my code only checks if the session is
valid, the invalidation is made in a regular
servlet, which makes me think that this is not related
to some filters-specific bug.
may be i'll post this to bugzilla later...
asher
- Original Message -
From: "Jacob Kjome" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: Monday, July 05, 2004 8:53 PM
Subject: Re: session invalidation
> At 10:15 AM 7/5/2004 +0200, you wrote:
> >Hello Ashert,
> >
> >may be you ran into the same prob as me
> >
> >i also had the problem, that URL-rewriting under Tomcat 5 did not work
> >although i explicitly used it. I found out, that URL-rewriting does only
> >work, if your application runs in the root context, looking like that in
> >server.xml:
> >
> >
> >
> >I was running my app under a named context:
> >
> >
> >
> >After changing the context definition to the first sample, URL-rewriting
> >worked fine
> >
> >hope this helps & best regards,
>
> Well, this helps very little. If you want to help, then provide the
> version of Tomcat5 you are working with. For all we know it is an old
> version with a quirky bug that has already been fixed in more recent
> versions. And if that is true, you are just adding to the confusion
saying
> it is broken when it isn't anymore. If it is still broken, however, it is
> your duty to report the bug so it can be fixed. Have you done that or
even
> checked if someone else reported it? The Tomcat developers are pretty
> responsive to fixing bugs. If you have the ability to describe and
> reproduce this bug and you neglect to do so, then you are doing a
> disservice to the Tomcat community. Some might disagree with the whole
"it
> is your duty" part. It is an unwritten rule that, if followed, will
> provide benefit to yourself and everyone else.
>
> Jake
>
>
> >Thilo
> >
> >>hello,
> >>
> >>1. a webapp has a filter, which filters all of the requests to
> >>application's servlets.
> >>2. the filter makes a simple check:
> >>if (session == null || session.getAttribute("abc") == null)
> >>//redirect the request to the login page;
> >>else
> >>//continue with it as it is
> >>3. if i invalidate the session, and then try to use back button of the
> >>browser the filter kicks me to the login page.
> >>on tomcat4 this works fine. at least i didn't see any problem ever.
> >>4. on tomcat 5 this logic works fine only with browser whith enabled
> >>cookies. using the session tracking with url rewriting doesn't
work.works
> >>the debugging shows that the flow runs into the code block that must
> >>invalidate the session, but it's not invalidated. i still can get
> >>back,see the pages and use the data stored in session!:(
> >>did u have any expirience with this stuff?
> >>thanks in advance.
> >>
> >>
> >>-
> >>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
> >
> >-
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: session invalidation
hey jacob,
i tried it on 5.0.16.
there is always a chance this was fixed since that version.
i didn't find anything about it in the bugzilla. that's why i posted
just to ask if someone already met this problem .
i posted another bug earlier (see my utf-8 problem posts) and got an
answer that this is not a bug, but the attached solution didn't solve my
problem.
when i reposted, the answer was that i should write to this board.
and please, leave the DUTIES stuff for other discussions.
asher.
- Original Message -
From: "Jacob Kjome" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: Monday, July 05, 2004 8:53 PM
Subject: Re: session invalidation
> At 10:15 AM 7/5/2004 +0200, you wrote:
> >Hello Ashert,
> >
> >may be you ran into the same prob as me
> >
> >i also had the problem, that URL-rewriting under Tomcat 5 did not work
> >although i explicitly used it. I found out, that URL-rewriting does only
> >work, if your application runs in the root context, looking like that in
> >server.xml:
> >
> >
> >
> >I was running my app under a named context:
> >
> >
> >
> >After changing the context definition to the first sample, URL-rewriting
> >worked fine
> >
> >hope this helps & best regards,
>
> Well, this helps very little. If you want to help, then provide the
> version of Tomcat5 you are working with. For all we know it is an old
> version with a quirky bug that has already been fixed in more recent
> versions. And if that is true, you are just adding to the confusion
saying
> it is broken when it isn't anymore. If it is still broken, however, it is
> your duty to report the bug so it can be fixed. Have you done that or
even
> checked if someone else reported it? The Tomcat developers are pretty
> responsive to fixing bugs. If you have the ability to describe and
> reproduce this bug and you neglect to do so, then you are doing a
> disservice to the Tomcat community. Some might disagree with the whole
"it
> is your duty" part. It is an unwritten rule that, if followed, will
> provide benefit to yourself and everyone else.
>
> Jake
>
>
> >Thilo
> >
> >>hello,
> >>
> >>1. a webapp has a filter, which filters all of the requests to
> >>application's servlets.
> >>2. the filter makes a simple check:
> >>if (session == null || session.getAttribute("abc") == null)
> >>//redirect the request to the login page;
> >>else
> >>//continue with it as it is
> >>3. if i invalidate the session, and then try to use back button of the
> >>browser the filter kicks me to the login page.
> >>on tomcat4 this works fine. at least i didn't see any problem ever.
> >>4. on tomcat 5 this logic works fine only with browser whith enabled
> >>cookies. using the session tracking with url rewriting doesn't
work.works
> >>the debugging shows that the flow runs into the code block that must
> >>invalidate the session, but it's not invalidated. i still can get
> >>back,see the pages and use the data stored in session!:(
> >>did u have any expirience with this stuff?
> >>thanks in advance.
> >>
> >>
> >>-
> >>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
> >
> >-
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: utf-8 with tomcat 5: second round
sorry, no struts are involved.
- Original Message -
From: "M.Hockings" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 05, 2004 7:04 PM
Subject: Re: utf-8 with tomcat 5: second round
> Hi Asher,
>
> It looks like you are using Struts? If so then setting the encoding in
> the response is too late as the Struts runtime has already set it.
>
> Look into using a filter (that is what I do) for your webapp, I expect
> that should solve your problem.
>
> You can Google about for more on utf-8 and Struts.
>
> http://www.anassina.com/struts/i18n/i18n.html
>
> Good luck
>
> Mike
>
>
> Asher Tarnopolski wrote:
> > hey mark, thanks for response.
> > i run the code i pasted below.
> > for example, i enter one hebrew letter. it's utf
> > code is 1488.
> > on tc 4.0.xx i get the following results:
> >
> > 7 (the length of its utf-8 code)
> > א (the letter itself in utf-8 encoding)
> > א(same as above parsed to be visible in browser)
> >
> > in tc 5 i get this:
> > 1(which already lets me know that this is not really utf-8)
> > the entered hebrew letter
> > the entered hebrew letter (nothing is parsed, so '&' signed wasn't even
met)
> > this is it.
> >
> > - Original Message -
> > From: "Mark Thomas" <[EMAIL PROTECTED]>
> > To: "'Tomcat Users List'" <[EMAIL PROTECTED]>; "'Asher
> > Tarnopolski'" <[EMAIL PROTECTED]>
> > Sent: Sunday, July 04, 2004 8:46 PM
> > Subject: RE: utf-8 with tomcat 5: second round
> >
> >
> >
> >>Asher,
> >>
> >>A few questions...
> >>
> >>What do you put in the text box on the form and what output do you see?
> >>
> >>Are you really using "" or do you
> >
> > mean
> >
> >>?
> >>
> >>When I did my test I copied your UTF-8 character form the bugzilla
report
> >
> > and
> >
> >>pasted into the text box. I was seeing question marks in the output
until
> >
> > I
> >
> >>added the <[EMAIL PROTECTED] pageEncoding="UTF-8"%> The test was on XP (as per the
> >
> > bug
> >
> >>report) and I assume you used IE as the browser.
> >>
> >>The URI encoding is a red herring in this case. Because you are using
post
> >
> > it is
> >
> >>only the request encoding that matters.
> >>
> >>The full text of my test JSP is below.
> >>
> >>Mark
> >>
> >><%@ page language="java" import="java.lang.*,java.util.*" %>
> >><%@ page pageEncoding="UTF-8" %>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >><%
> >>request.setCharacterEncoding("UTF-8");
> >>
> >>if(request.getParameter("source")!=null)
> >>{
> >> out.println(request.getParameter("source").length()+"");
> >>
> >> out.println(request.getParameter("source"));
> >>
> >> StringBuffer sb = new StringBuffer();
> >> for(int i=0; i >> {
> >>if(request.getParameter("source").charAt(i) == '&')
> >> sb.append("&");
> >>else
> >> sb.append(request.getParameter("source").charAt(i));
> >>
> >> }
> >> out.println(""+ sb.toString());
> >>}
> >>%>
> >>
> >>
> >>
> >>
> >>
> >>
> >>>-Original Message-
> >>>From: Asher Tarnopolski [mailto:[EMAIL PROTECTED]
> >>>Sent: Sunday, July 04, 2004 6:25 PM
> >>>To: [EMAIL PROTECTED]
> >>>Subject: utf-8 with tomcat 5: second round
> >>>
> >>>hi folks,
> >>>i've published a question about it a couple of days ago, but
> >>>didn't get any responses.
> >>>i've tried some things i found in bugzilla, but they didn't
> >>>help. so, i wanna try to get your help once more.
> >>>once more about my problem:
> >>>i try to send utf-8 encoded parameters in POST body, but they
> >>>arrived encoded in ISO...
> >>>this worked perfectly with tomcat 4.0.x.
> >>>from the info i've
Re: utf-8 with tomcat 5: second round
hey mark, thanks for response.
i run the code i pasted below.
for example, i enter one hebrew letter. it's utf
code is 1488.
on tc 4.0.xx i get the following results:
7 (the length of its utf-8 code)
א (the letter itself in utf-8 encoding)
א(same as above parsed to be visible in browser)
in tc 5 i get this:
1(which already lets me know that this is not really utf-8)
the entered hebrew letter
the entered hebrew letter (nothing is parsed, so '&' signed wasn't even met)
this is it.
- Original Message -
From: "Mark Thomas" <[EMAIL PROTECTED]>
To: "'Tomcat Users List'" <[EMAIL PROTECTED]>; "'Asher
Tarnopolski'" <[EMAIL PROTECTED]>
Sent: Sunday, July 04, 2004 8:46 PM
Subject: RE: utf-8 with tomcat 5: second round
> Asher,
>
> A few questions...
>
> What do you put in the text box on the form and what output do you see?
>
> Are you really using "" or do you
mean
> ?
>
> When I did my test I copied your UTF-8 character form the bugzilla report
and
> pasted into the text box. I was seeing question marks in the output until
I
> added the <[EMAIL PROTECTED] pageEncoding="UTF-8"%> The test was on XP (as per the
bug
> report) and I assume you used IE as the browser.
>
> The URI encoding is a red herring in this case. Because you are using post
it is
> only the request encoding that matters.
>
> The full text of my test JSP is below.
>
> Mark
>
> <%@ page language="java" import="java.lang.*,java.util.*" %>
> <%@ page pageEncoding="UTF-8" %>
>
>
>
>
>
>
>
>
>
> <%
> request.setCharacterEncoding("UTF-8");
>
> if(request.getParameter("source")!=null)
> {
> out.println(request.getParameter("source").length()+"");
>
> out.println(request.getParameter("source"));
>
> StringBuffer sb = new StringBuffer();
> for(int i=0; i {
> if(request.getParameter("source").charAt(i) == '&')
> sb.append("&");
> else
> sb.append(request.getParameter("source").charAt(i));
>
> }
> out.println(""+ sb.toString());
> }
> %>
>
>
>
>
>
>
> > -Original Message-
> > From: Asher Tarnopolski [mailto:[EMAIL PROTECTED]
> > Sent: Sunday, July 04, 2004 6:25 PM
> > To: [EMAIL PROTECTED]
> > Subject: utf-8 with tomcat 5: second round
> >
> > hi folks,
> > i've published a question about it a couple of days ago, but
> > didn't get any responses.
> > i've tried some things i found in bugzilla, but they didn't
> > help. so, i wanna try to get your help once more.
> > once more about my problem:
> > i try to send utf-8 encoded parameters in POST body, but they
> > arrived encoded in ISO...
> > this worked perfectly with tomcat 4.0.x.
> > from the info i've got from a developer at bugzilla i learned
> > that the difference between tc4.0 and tc5
> > that causes the change is actually in coyote http1.1
> > connector. there is an attribute
> > called useBodyEncodingForURI which was set to "true" in tc4,
> > but became "false" in tc5.
> > setting it to "true" together with <%@ page
> > pageEncoding="UTF-8" %> and
> > <%request.setCharacterEncoding("UTF-8");%> will make the difference.
> > i made the change, the jsp tags are in the code and coyote
> > settings look like this now:
> >
> >
> >
> > >maxThreads="150" minSpareThreads="25"
> > maxSpareThreads="75"
> >enableLookups="false" redirectPort="8443"
> > acceptCount="100"
> >debug="0" connectionTimeout="2"
> >useBodyEncodingForURI="true"
> >disableUploadTimeout="true" />
> >
> >
> > but this doesn't help! another request to bugzilla didn't
> > help either, i was told that this is not a bug in tomcat,
> > so they are not going to deal with the question. well, may be
> > it's not a tomcat bug, but it should be some kind of bug.
> > any ideas?
> >
> > my testing code comes here:
> >
> >
> >
> > <[EMAIL PROTECTED] contentType="text/html; charset=utf-8"%>
> > <[EMAIL PROTECTED] pageEncoding="utf-8"%>
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > <%
> > request.setCharacterEncoding("UTF-8");
> >
> > if(request.getParameter("source")!=null)
> > {
> > out.println(request.getParameter("source").length()+"");
> >
> > out.println(request.getParameter("source"));
> >
> > StringBuffer sb = new StringBuffer();
> > for(int i=0; i > {
> > if(request.getParameter("source").charAt(i) == '&')
> > sb.append("&");
> > else
> > sb.append(request.getParameter("source").charAt(i));
> >
> > }
> > out.println(""+ sb.toString());
> > }
> > %>
> >
> >
> >
> >
> >
> >
> >
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
utf-8 with tomcat 5: second round
hi folks,
i've published a question about it a couple of days ago, but didn't get any responses.
i've tried some things i found in bugzilla, but they didn't help. so, i wanna try to
get your help once more.
once more about my problem:
i try to send utf-8 encoded parameters in POST body, but they arrived encoded in ISO...
this worked perfectly with tomcat 4.0.x.
from the info i've got from a developer at bugzilla i learned that the difference
between tc4.0 and tc5
that causes the change is actually in coyote http1.1 connector. there is an attribute
called useBodyEncodingForURI which was set to "true" in tc4, but became "false" in tc5.
setting it to "true" together with <%@ page pageEncoding="UTF-8" %> and
<%request.setCharacterEncoding("UTF-8");%> will make the difference.
i made the change, the jsp tags are in the code and coyote settings look like this now:
but this doesn't help! another request to bugzilla didn't help either, i was told that
this is not a bug in tomcat,
so they are not going to deal with the question. well, may be it's not a tomcat bug,
but it should be some kind of bug.
any ideas?
my testing code comes here:
<[EMAIL PROTECTED] contentType="text/html; charset=utf-8"%>
<[EMAIL PROTECTED] pageEncoding="utf-8"%>
<%
request.setCharacterEncoding("UTF-8");
if(request.getParameter("source")!=null)
{
out.println(request.getParameter("source").length()+"");
out.println(request.getParameter("source"));
StringBuffer sb = new StringBuffer();
for(int i=0; i"+ sb.toString());
}
%>
utf-8 with tomcat 5
hey folks,
to show you what is it all about i wrote a small app which shows the
html utf-8 codes of the entered string. this is the jsp code:
<%if(request.getParameter("source")!=null){
request.setCharacterEncoding("UTF-8");
out.println(request.getParameter("source").length()+"");
out.println(request.getParameter("source")); StringBuffer sb = new StringBuffer();
for(int i=0; i"+
sb.toString());}%>
well, as you see, this code block gets a utf-8 encoded parameter from
a request, outputs its length, the parameter itself, and its html
utf-8 codes.
to test it i send a hebrew letter ALEF. on tomcat 4.xx everything
works perfect and i get the following response:
7
א
א
(in case you don't see it here, it's 7 , alef's utf-8 code and alef's utf-8
code parsed to be visible in browser)
cool. then i run the same code on tomcat 5.0.16 and KABOOM. this is
what i get:
2
א
א
(in case you don't see it here: it's 2, and twice alef as it would be
passed in windows-1255 or iso... where the hell utf-8 is gone?)
all this makes me understand that tomcat 5 has some bug influenting
its utf-8 support. how comes the parameter length of one char is 2?!
thanks in advance.
