> From: David Smith [mailto:[EMAIL PROTECTED]
> Subject: Re: Webapps inexplicably losing access to
> common/shared classloaders
>
> H. only fixed by a system restart? This sounds like an
> environment variable is changed during start or stop and the
> new value is bad. Your start and
Timothy Collett wrote:
Now, this seems to happen *every* time I stop and restart Tomcat...
I'm somewhat at a loss to see what could be put into a bad state by
stopping and restarting Tomcat, but put back in a good state by
restarting the computer. Shouldn't everything be cleaned up by
stopp
> From: IT Desk [mailto:[EMAIL PROTECTED]
> Subject: Re: tomcat inserts leading / on include file
>
> I tried a few things and the only thing that worked was as below.
What should also work is removing the context entry from inside the
element, and placing a cut down version in META-INF/context
- Original Message
From: "Caldarale, Charles R" [EMAIL PROTECTED]
>> From: Rashmi Rubdi [mailto:[EMAIL PROTECTED]
>> Subject: Re: Web spiders - disabling jsessionid
>>
>> I think then, setting cookies to "true", or simply leaving
>> out the cookies attribute should solve the original p
I tried a few things and the only thing that worked was as below.
PLUS also changing the httpd.conf VirtualHost DocumentRoot
to also point to /home/perap/htdocs/perap/ROOT.
In my case, I had to keep the Context entry but a more "normal" webapp
probably would not need it.
Thanks for al
> From: Art [mailto:[EMAIL PROTECTED]
> Subject: standard Apache 2.2 & Tomcat 5.5 config to avoid open-proxies
>
> In Apache 2.2 mod_proxy_ajp seems to be the preferred way of
> connecting Apache as a frontend to Tomcat as a backend.
Do you really need to complicate your life that way? Is ther
> From: Rashmi Rubdi [mailto:[EMAIL PROTECTED]
> Subject: Re: Web spiders - disabling jsessionid
>
> I think then, setting cookies to "true", or simply leaving
> out the cookies attribute should solve the original poster's
> problem with disabling JSESSIONID
Except for the paranoid clients tha
In Apache 2.2 mod_proxy_ajp seems to be the preferred way of connecting
Apache as a frontend to Tomcat as a backend. So it would seem I must
use a forward and reverse proxy with this version of the Apache server.
It would seem that there would be a standard config thay would not
create an open pr
- Original Message
From: "Caldarale, Charles R" [EMAIL PROTECTED]
>>From: Rashmi Rubdi [mailto:[EMAIL PROTECTED]
>>
>> There's no jsessionid appended at the end of URLs that the
>> bot requests.
>Depends on what the value of the cookies attribute for the is;
>if false, or the app ch
> From: Leon Rosenberg [mailto:[EMAIL PROTECTED]
> Subject: Re: Web spiders - disabling jsessionid
>
> It's completely OT, but once a customer of mine has placed a
> direct-login link to the public accessible test-system for the newest
> project on a crawled site, so that google not only logged i
> From: Rashmi Rubdi [mailto:[EMAIL PROTECTED]
> Subject: Re: Web spiders - disabling jsessionid
>
> There's no jsessionid appended at the end of URLs that the
> bot requests.
Depends on what the value of the cookies attribute for the is;
if false, or the app chooses to rewrite the URL with it
> Caldarale, Charles R wrote:
> Filter with wrapper ServletResponse is IMO the best solution.
> You can apply it to almost every application without touching the code.
>>Perhaps that is the /quickest/ solution, but I would argue that the best
>>solution is not to create a session if you don't actu
On 12/1/06, Caldarale, Charles R <[EMAIL PROTECTED]> wrote:
> From: Len Popp [mailto:[EMAIL PROTECTED]
> Subject: Re: Web spiders - disabling jsessionid
>
> On my site (as on many others) you can browse the site without a
> session, but if you want to log in (to add content or to use
> personaliz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mikolaj,
Mikolaj Rydzewski wrote:
> Caldarale, Charles R wrote:
>> That contradicts what Len said about his site:
>>
>> "On my site (as on many others) you can browse the site without a
>> session, but if you want to log in (to add content or to use
>
On 12/1/06, Caldarale, Charles R <[EMAIL PROTECTED]> wrote:
> From: Chris Adams [mailto:[EMAIL PROTECTED]
> Subject: RE: Web spiders - disabling jsessionid
>
> That's not true. A session id is assigned the moment you hit
> the site.
That contradicts what Len said about his site:
"On my site (a
Caldarale, Charles R wrote:
That's not true. A session id is assigned the moment you hit
the site.
That contradicts what Len said about his site:
"On my site (as on many others) you can browse the site without a
session, but if you want to log in (to add content or to use
personalized se
> From: Chris Adams [mailto:[EMAIL PROTECTED]
> Subject: RE: Web spiders - disabling jsessionid
>
> That's not true. A session id is assigned the moment you hit
> the site.
That contradicts what Len said about his site:
"On my site (as on many others) you can browse the site without a
session
| From: Joel Klein [mailto:[EMAIL PROTECTED]
| Sent: Friday, 01 December, 2006 11:19
|
| The odd thing that needs an explanation, if a firewall is responsible,
| is that these machines were working fine.
Has anyone installed any OS patches or fixes on these machines? Windows
XP will helpfully in
When I change JNDI environment entries in the admin app or from the
manager app's jmxproxy, those changes are not reflected in the Context
I'm getting in my app when I do
new InitialContext().lookup("java:comp/env/test")
Since I'm doing that per-call in my webapp (and printing the result
directly
> 1) Sessions are not created unless logged in.
That's not true. A session id is assigned the moment you hit the site.
Set your browser to prompt before accepting cookies and you'll see the
JSESSIONID cookie being sent before you login.
This is done to support anonymous users, and still manage
> From: Len Popp [mailto:[EMAIL PROTECTED]
> Subject: Re: Web spiders - disabling jsessionid
>
> On my site (as on many others) you can browse the site without a
> session, but if you want to log in (to add content or to use
> personalized settings) you need a session.
O.k., now I'm confused.
1
On 12/1/06, Christopher Schultz <[EMAIL PROTECTED]> wrote:
Mikolaj,
Back to the original question...
Mikolaj Rydzewski wrote:
> As you may know url rewriting feature is not a nice thing when spiders
> come to index your site -
> http://gabrito.com/post/javas-seo-blunder-jsessionid.
So, the pro
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mikolaj,
Back to the original question...
Mikolaj Rydzewski wrote:
> As you may know url rewriting feature is not a nice thing when spiders
> come to index your site -
> http://gabrito.com/post/javas-seo-blunder-jsessionid.
So, the problem is that y
Tim wrote:
Is there a curses-based browser on the machines you could use via ssh?
Not that I know of.
Can you try doing the same thing from the machines themselves--ssh
in, then telnet localhost 8080?
Connecting via telnet on the machines themselves also doesn't work.
The only other thing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris,
Chris Adams wrote:
> Your empirical data really isn't useful, because it's based upon an
> assumption that could very easily be false.
Good point. Still, nobody has given any source for this information, so
I'm inclined to consider it a myth f
On Dec 1, 2006, at 10:35 AM, Caldarale, Charles R wrote:
Do you have servlet-api.jar in more than one place? It must only
be in
common/lib, and nowhere else. You can also get the above error if
HttpServlet.class is packaged in some other jar.
Nope, it's only there. I even unzipped every si
Just thought I'd join this [probably not appropriate for this list :)]
conversation real quickly :)
Why do you assume that there would be a 1:1 or even 2:1 ratio between
the Googlebot and the "google-incognito" hits?
It would be very likely that Google, since it does play nice with agent
strings,
> From: Timothy Collett [mailto:[EMAIL PROTECTED]
> Subject: Re: Webapps inexplicably losing access to
> common/shared classloaders
>
> Dec 1, 2006 8:54:05 AM org.apache.catalina.startup.HostConfig
> deployDirectory
> SEVERE: Error deploying web application directory WCMS-Online
> java.lang.No
Hello Christopher,
When I check my access logs I could imagine
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
beeing a google.bot.
Of course I don't know it for sure, cause I'm don't do any seo
cloaking here, and don't care. But one could go to seo boards, pick
the posted ip-adresses for cloa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Leon,
Leon Rosenberg wrote:
> you believe everything you've been told ?:-)
Well, I've been told by you, and I don't believe you. ;)
> google has 3 (at least 3 known) user agents : google, mozzila with
> google-bot in the agent string (the one you se
On Dec 1, 2006, at 10:00 AM, Caldarale, Charles R wrote:
Agreed, not if this is all happening within one process. Any chance
some thread in one of your webapps is changing the current
directory for
the process? That can result in rather strange and erratic behavior,
depending on which classl
> From: Timothy Collett [mailto:[EMAIL PROTECTED]
> Subject: Re: Webapps inexplicably losing access to
> common/shared classloaders
>
> I did check, but I don't see how any permissions setup could
> possibly create this situation...
Agreed, not if this is all happening within one process. Any
Leon Rosenberg wrote:
google uses this 3rd agent to check your site from another ip adress,
whether you do some ugly seo stuff, like cloacking etc.
Seems possible.
so please don't do it, if you rely on being found.
I think that just removing ;jsessionid=XXX for the first one won't make
much ha
On Dec 1, 2006, at 8:45 AM, Caldarale, Charles R wrote:
From: Timothy Collett [mailto:[EMAIL PROTECTED]
Subject: Re: Webapps inexplicably losing access to
common/shared classloaders
Now, this seems to happen *every* time I stop and restart Tomcat...
Does anything happen to the access permissi
you believe everything you've been told ?:-)
google has 3 (at least 3 known) user agents : google, mozzila with
google-bot in the agent string (the one you sent) and another one,
which is just Mozilla/5.0.
google uses this 3rd agent to check your site from another ip adress,
whether you do some
> From: Timothy Collett [mailto:[EMAIL PROTECTED]
> Subject: Re: Webapps inexplicably losing access to
> common/shared classloaders
>
> Now, this seems to happen *every* time I stop and restart Tomcat...
Does anything happen to the access permissions or other security
attributes of the common a
Now, this seems to happen *every* time I stop and restart Tomcat...
I'm somewhat at a loss to see what could be put into a bad state by
stopping and restarting Tomcat, but put back in a good state by
restarting the computer. Shouldn't everything be cleaned up by
stopping Tomcat, or not cle
Wrong. Google is very clear about not hiding user agent - as well as a
the other major bots.
Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html
Just just for Googlebot in the user-agent header.
-Tim
Leon Rosenberg wrote:
On 12/1/06, Tim Funk <[EMAIL PROTECTED]> wrote:
T
On 12/1/06, Tim Funk <[EMAIL PROTECTED]> wrote:
The easiest is the filter and custom HttpServletResponse which overrides
encodeURL() to do nothing.
It could be made one step smarter by checking if the User agent is a
search engine bot to selectively execute or not.
How do you want to achieve
The easiest is the filter and custom HttpServletResponse which overrides
encodeURL() to do nothing.
It could be made one step smarter by checking if the User agent is a
search engine bot to selectively execute or not.
-Tim
Mikolaj Rydzewski wrote:
Hi,
As you may know url rewriting feature
Hello,
we use filter in web.xml as you said: StripSessionIdFilter. Works
fine. Not that much overhead.
Regards
Andrew Stepanenko,
Ternopil, Ukraine
http://unf.tane.edu.ua
On 12/1/06, Mikolaj Rydzewski <[EMAIL PROTECTED]> wrote:
Hi,
As you may know url rewriting feature is not a nice thing whe
Hi,
As you may know url rewriting feature is not a nice thing when spiders
come to index your site -
http://gabrito.com/post/javas-seo-blunder-jsessionid.
There are a few solutions I'm thinking of:
* configuration at Tomcat / web.xml level to disable/enable url
rewriting (unfortunate
As far as I'm aware (I did a quick check) all the bytecode gen'ing is
done in one place which as at the Entity level. Because the Collection
API is all interfaces it's easy to swap in a lazy collection
implementation without resorting to bytecode.
Hopefully he'll add it in to the core as it's a r
Mark Thomas wrote:
Thanks. There should be some kind of errata on Tomcat website. To help
people not to loose few hours to dig through google and mail archives.
http://issues.apache.org/bugzilla/query.cgi?product=Tomcat%205
I don't expect such problems when I follow official documentati
Mikolaj Rydzewski wrote:
> Mark Thomas wrote:
>>> Can somebody confirm that similiar setup works for him? Or where is the
>>> mistake?
>>>
>> No mistake, it is http://issues.apache.org/bugzilla/show_bug.cgi?id=40668
>>
> Thanks. There should be some kind of errata on Tomcat website. To help
Hello
using tomcat 5.5.20.
I set up the docBase in my application-context.xml to use a symlink
which points to the most current version. New versions are installed
each in it's own directory and afterwards the symlink is changed to the
new location.
But tomcat5.5 recognizes the short removal o
Hi
I am fighting with Tomcat for a couple of days and I cannot find a cause
to the problem.
I am using Tomcat 5.5.16 and it is configured to run HTTP on port 8081
and HTTPS on port 8444.
The problem:
The application runs properly over HTTP. However over HTTPS the number
of threads keep inc
Hi All,
We have a web application that communicates with siebel server 7.5.3. There is
a firewall between web
server and siebel server.When we start our web application it works fine but
after sometime connection
request to siebel fails.Session timout value for TCP connections on firewall is
3
Mark Thomas wrote:
Can somebody confirm that similiar setup works for him? Or where is the
mistake?
No mistake, it is http://issues.apache.org/bugzilla/show_bug.cgi?id=40668
Thanks. There should be some kind of errata on Tomcat website. To help
people not to loose few hours to dig throu
49 matches
Mail list logo
