Re: Suggestion: Dispatcher interface should have return values as public constants
On 2014/06/04 (Jun), at 12:51 PM, Thiago H de Paula Figueiredo wrote: > I like this suggestion. :) Could you file a JIRA please? Filed: https://issues.apache.org/jira/browse/TAP5-2347 -- Robert Hailey - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5.3 - Localization is only partially implemented?
On 2014/05/20 (May), at 4:54 PM, Kalle Korhonen wrote: > I don't know if there's an existing issue around this. > Take a look and open a new one if no existing issues are found. Should be > straightforward to get it fixed. > > Kalle Filed: https://issues.apache.org/jira/browse/TAP5-2346 -- Robert Hailey
Re: Suggestion: Dispatcher interface should have return values as public constants
I like this suggestion. :) Could you file a JIRA please?
On Wed, 04 Jun 2014 14:35:45 -0300, Robert Hailey
wrote:
After writing yet another Dispatcher, I've come to think that the
Dispatcher interface should have return values as public constants.
The trouble is one of readability, and quite minor, but worse when there
is a bunch of return statements, or when reviewing a long dispatcher
(when you come to the end of the function, and have to reason... now, is
true or false the correct return value?).
Basically, I would change this:
028public interface Dispatcher
029{
036boolean dispatch(Request request, Response response) throws
IOException;
037}
To this:
public interface Dispatcher
{
boolean dispatch(Request request, Response response) throws
IOException;
public static final boolean HANDLED =true;
public static final boolean CONTINUE=false;
}
Which would let someone write "return HANDLED;" because the constants
come with the interface.
It's easy enough to add these constants in every dispatcher, but unlike
other (more errant) uses of interface constants that I've seen, this
seems to me to be very relevant to the contract of the interface; and it
could serve to make dispatchers more readable.
I don't think that Java inlines final constants anymore, so there could
be a trivial performance penalty.
Just a thought... very low-impact on my side.
--
Robert Hailey
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Suggestion: Dispatcher interface should have return values as public constants
After writing yet another Dispatcher, I've come to think that the Dispatcher
interface should have return values as public constants.
The trouble is one of readability, and quite minor, but worse when there is a
bunch of return statements, or when reviewing a long dispatcher (when you come
to the end of the function, and have to reason... now, is true or false the
correct return value?).
Basically, I would change this:
028public interface Dispatcher
029{
036boolean dispatch(Request request, Response response) throws
IOException;
037}
To this:
public interface Dispatcher
{
boolean dispatch(Request request, Response response) throws IOException;
public static final boolean HANDLED =true;
public static final boolean CONTINUE=false;
}
Which would let someone write "return HANDLED;" because the constants come with
the interface.
It's easy enough to add these constants in every dispatcher, but unlike other
(more errant) uses of interface constants that I've seen, this seems to me to
be very relevant to the contract of the interface; and it could serve to make
dispatchers more readable.
I don't think that Java inlines final constants anymore, so there could be a
trivial performance penalty.
Just a thought... very low-impact on my side.
--
Robert Hailey
Re: Prevent session id from appearing in URL while being indexed by google
Thanks Thiago, looks as if I had SessionState being used in the layout. On Wed, Jun 4, 2014 at 11:46 AM, Thiago H de Paula Figueiredo < thiag...@gmail.com> wrote: > On Wed, 04 Jun 2014 12:11:00 -0300, George Christman < > gchrist...@cardaddy.com> wrote: > > Hi Thiago, I just disabled coolkies within my browser and I'm finding >> every link is being generated with a session id despite not needing to be >> logged in. What would cause this? >> > > Any page with @Persist or @SessionState being visited can cause a session > to be created. Or code that calls the setXX() methods of > ApplicationStateManager. You don't need to be logged in to have an > HttpSession created. > > The session id generation is done by the servlet container, not Tapestry. > On the other hand, you can use the LinkRewriter API to change teh URLs > Tapestry generate. > > > -- > Thiago H. de Paula Figueiredo > Tapestry, Java and Hibernate consultant and developer > http://machina.com.br > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > -- George Christman www.CarDaddy.com P.O. Box 735 Johnstown, New York
Re: Prevent session id from appearing in URL while being indexed by google
On Wed, 04 Jun 2014 12:11:00 -0300, George Christman wrote: Hi Thiago, I just disabled coolkies within my browser and I'm finding every link is being generated with a session id despite not needing to be logged in. What would cause this? Any page with @Persist or @SessionState being visited can cause a session to be created. Or code that calls the setXX() methods of ApplicationStateManager. You don't need to be logged in to have an HttpSession created. The session id generation is done by the servlet container, not Tapestry. On the other hand, you can use the LinkRewriter API to change teh URLs Tapestry generate. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Prevent session id from appearing in URL while being indexed by google
George, you can try debugging this by implementing http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpSessionListener.html Put a breakpoint in sessionCreated and inspect the stack trace. Maybe this will help. On Wed, Jun 4, 2014 at 7:11 PM, George Christman wrote: > Hi Thiago, I just disabled coolkies within my browser and I'm finding every > link is being generated with a session id despite not needing to be logged > in. What would cause this? I'm not sure if this would effect things, but > I'm using remember me with tapestry-security, however I'm not logged in to > my account while it's still generating session id's. Any thoughts? > > > On Wed, Jun 4, 2014 at 10:46 AM, Thiago H de Paula Figueiredo < > thiag...@gmail.com> wrote: > > > On Wed, 04 Jun 2014 10:16:24 -0300, Dmitry Gusev > > > wrote: > > > > I don't think requiring cookies is a bad idea. > >> I think every normal user would have cookies enabled. > >> > > > > Some proxies mess up with cookies, causing them to not work. At my work > > I've got lots of client complaints because of that. > > > > I think the most important issue here is why the session is being created > > at first. It's even a performance issue. > > > > -- > > Thiago H. de Paula Figueiredo > > Tapestry, Java and Hibernate consultant and developer > > http://machina.com.br > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > > For additional commands, e-mail: users-h...@tapestry.apache.org > > > > > > > -- > George Christman > www.CarDaddy.com > P.O. Box 735 > Johnstown, New York > -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: Prevent session id from appearing in URL while being indexed by google
Hi Thiago, I just disabled coolkies within my browser and I'm finding every link is being generated with a session id despite not needing to be logged in. What would cause this? I'm not sure if this would effect things, but I'm using remember me with tapestry-security, however I'm not logged in to my account while it's still generating session id's. Any thoughts? On Wed, Jun 4, 2014 at 10:46 AM, Thiago H de Paula Figueiredo < thiag...@gmail.com> wrote: > On Wed, 04 Jun 2014 10:16:24 -0300, Dmitry Gusev > wrote: > > I don't think requiring cookies is a bad idea. >> I think every normal user would have cookies enabled. >> > > Some proxies mess up with cookies, causing them to not work. At my work > I've got lots of client complaints because of that. > > I think the most important issue here is why the session is being created > at first. It's even a performance issue. > > -- > Thiago H. de Paula Figueiredo > Tapestry, Java and Hibernate consultant and developer > http://machina.com.br > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > -- George Christman www.CarDaddy.com P.O. Box 735 Johnstown, New York
Re: event triggering inside form loop
There's another interesting case (probably related to this problem). I'll
keep it very simple.
1) component1
...
...
2) component2
...
...
void onMyEventFromComponent3 () {
// do something
}
3) component3
...
...
void onSelectedFromSubmit () {
componentResources.triggerEvent ( "myevent", null, null );
}
Expected: triggering submit triggers onMyEventFromComponent3 in parent.
Actual: onMyEventFromComponent3 is indeed triggered, but it happens with a
state related to the last iteration of the loop.
So probably there's something wrong with event propagation from child to
parent inside a loop? Any other ideas?
On Thu, May 22, 2014 at 9:07 AM, Ilya Obshadko
wrote:
> On Tue, May 20, 2014 at 11:09 PM, Thiago H de Paula Figueiredo <
> thiag...@gmail.com> wrote:
>
>> On Tue, 20 May 2014 14:45:48 -0300, Ilya Obshadko <
>> ilya.obsha...@gmail.com> wrote:
>>
>> Yes, this is it. I have a component which is looped over.
>>>
>>> class MyComponent {
>>>@Parameter
>>>private MyObject obj; // assigned inside a loop
>>>
>>>void onSelectedFromSubmitControl ( ... ) {
>>>}
>>> }
>>>
>>> 1) initially I tried to simply use MyObject instance passed as a
>>> parameter
>>> inside AjaxFormLoop;
>>>
>>
>> This won't work if you don't pass it as the context of Submit. Submit
>> passes to the event handler the context it receives, without any guessing.
>>
>> 2) then, I tried to pass this instance as context., getting the
>>> same results
>>>
>>
>> This will only work if you contribute a ValueEncoder for MyObject.
>>
>>
>> 3) finally, I tried to use obj.id as a context parameter instead -
>>> again,
>>> onSelectedFromSubmitControl was being called with context parameter
>>> belonging to the last iteration of the outside loop
>>>
>>
>> Outside loop? So there's nested loops?
>
>
> There's only one loop. By 'outside' I meant 'enclosing'.
>
> At this point I gave up and solved the problem otherwise, without having to
>>
>>> rely on t:submit context.
>>>
>>> I guess I understand your point, but t:submit does not encode context
>>> inside submission URL (unlike t:actionlink or t:eventlink). Probably
>>> that's
>>> the reason why my initial approach didn't work.
>>>
>>
>> If you're correct, and I haven't done any testing to know if you do, then
>> it's a bug. Have you tried, in a separate page, something similar but
>> simple enough to reproduce the problem?
>
>
> No, I didn't.
>
> In fact, when t:submit is being used inside a loop and IS NOT ENCLOSED BY
>>> OTHER COMPONENT, this scheme works.
>>>
>>
>> It shouldn't make any difference (not being enclosed by other component).
>> It may indicate an error in your part. It may be a bug in Submit. Looking
>> at the source (5.1, unfortunately I'm working on projects still using that
>> version), it seems to be a problem in Submit, but I won't be sure until I
>> run or see an example.
>
>
> The code I'm working on is not open source. I could create some private
> gists, if that works for you. Let me know.
>
>
>>
>> For example, in the same application I have constructs like:
>>>
>>>
>>>
>>>
>>>
>>
>> I'm not sure the p: prefix is actually valid here. t: is the one usually
>> used for non-block parameters, while p: is used for block ones.
>
>
> Never had any problem with p: prefix actually.
>
>
> --
> Ilya Obshadko
>
>
--
Ilya Obshadko
Re: Prevent session id from appearing in URL while being indexed by google
On Wed, 04 Jun 2014 10:16:24 -0300, Dmitry Gusev wrote: I don't think requiring cookies is a bad idea. I think every normal user would have cookies enabled. Some proxies mess up with cookies, causing them to not work. At my work I've got lots of client complaints because of that. I think the most important issue here is why the session is being created at first. It's even a performance issue. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: How to write to sitemap
Hi guys, I ended up using StreamResponse from the jumpstart example http://jumpstart.doublenegative.com.au/jumpstart/examples/navigation/returntypes1 along with JAXB. This appears to be working perfectly. On Tue, Jun 3, 2014 at 3:52 AM, Magnus Kvalheim wrote: > Hi. > Yes, you can generate the sitemap and place it an arbitrary location - > another domain even. > > You provide a path to the sitemap in the robots.txt (which is located on > our real domain) > > By doing so you have proven ownership of the domain and can basically host > the sitemap on any path/domain. > http://www.sitemaps.org/protocol.html#location > > For google you can also use the webmaster tools for domain verification and > can also upload the sitemap. > > best > Magnus > > > > On Tue, Jun 3, 2014 at 8:30 AM, Lance Java > wrote: > > > Another couple of options : > > > > 1. Assuming you're building with maven and you don't have an Index page > at > > root, save sitemap.xml to src/main/webapp and maven will add it to the > root > > of your war. Note that this file is considered read only one your app has > > started. > > > > 2. Use an index page. If the page activation context is sitemap.xml, > return > > a textstreamresponse containing the sitemap (classpath?). > > On 3 Jun 2014 03:01, "George Christman" > wrote: > > > > > Hi guys, I'm trying to automatically generate my sitemaps and I'm > having > > a > > > difficult time trying to figure out how to read/write to it. I > currently > > > have it in the root of my class path, is this the correct location? If > > so, > > > how do I read/write to it? > > > > > > I'm using sitemapgen4j and this example > > > http://www.codingpedia.org/ama/generate-sitemaps-with-sitemapgen4j/ > > > > > > -- > > > George Christman > > > www.CarDaddy.com > > > P.O. Box 735 > > > Johnstown, New York > > > > > > -- George Christman www.CarDaddy.com P.O. Box 735 Johnstown, New York
Re: Prevent session id from appearing in URL while being indexed by google
Thanks Dmitry. I'll move forward with that solution. On Wed, Jun 4, 2014 at 9:16 AM, Dmitry Gusev wrote: > I don't think requiring cookies is a bad idea. > I think every normal user would have cookies enabled. > > > On Wed, Jun 4, 2014 at 4:59 PM, George Christman > wrote: > > > I'm already using tomcat7. Do you think requiring all users to have > cookies > > enabled is a bad idea? > > > > > > On Wed, Jun 4, 2014 at 8:32 AM, Dmitry Gusev > > wrote: > > > > > I don't think you should migrate your app server to do this, your > current > > > server probably supports this feature too! > > > What is it btw? > > > > > > There will be side-effects: users without cookies won't be able to use > > > sessions in your app. > > > > > > > > > On Wed, Jun 4, 2014 at 4:28 PM, George Christman < > > gchrist...@cardaddy.com> > > > wrote: > > > > > > > Thanks Dmitry, so if I understand this correctly, I should be able to > > > just > > > > do the following and it should address the issue without side > effects? > > > > > > > > 3. Switch to Tomcat 7 ! > > > > > > > > The Servlet 3.0 standard gives you two ways to disable URL session > > > > rewriting. This works in Tomcat 7, Glassfish v3, and any other > Servlet > > > > 3.0-compliant servlet container. First, you can add this to your > > web.xml > > > > webapp config: > > > > > > > > > > > > COOKIE > > > > > > > > > > > > > > > > On Wed, Jun 4, 2014 at 6:58 AM, Dmitry Gusev > > > > > wrote: > > > > > > > > > Hi George, > > > > > > > > > > The ID appears in URLs if your app creates session for current > user & > > > > this > > > > > user has cookies disabled. > > > > > > > > > > You can either not create a session for guests, or disable session > ID > > > in > > > > > URLs in servlet container level, > > > > > here's an example for tomcat: > > > > > https://fralef.me/tomcat-disable-jsessionid-in-url.html > > > > > > > > > > > > > > > > > > > > On Wed, Jun 4, 2014 at 10:48 AM, George Christman < > > > > gchrist...@cardaddy.com > > > > > > > > > > > wrote: > > > > > > > > > > > Hi guys, I'm noticing Google is indexing a lot of pages with the > > > > session > > > > > id > > > > > > appended to the URL, how do I prevent this? Please see link below > > for > > > > > > example. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://www.google.com/search?q=site:cardaddy.com&client=firefox-a&hs=qLR&rls=org.mozilla:en-US:official&channel=sb&ei=d8COU_CRDJSmsQT_lIDoDQ&start=80&sa=N&biw=1280&bih=1199 > > > > > > > > > > > > -- > > > > > > George Christman > > > > > > www.CarDaddy.com > > > > > > P.O. Box 735 > > > > > > Johnstown, New York > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Dmitry Gusev > > > > > > > > > > AnjLab Team > > > > > http://anjlab.com > > > > > > > > > > > > > > > > > > > > > -- > > > > George Christman > > > > www.CarDaddy.com > > > > P.O. Box 735 > > > > Johnstown, New York > > > > > > > > > > > > > > > > -- > > > Dmitry Gusev > > > > > > AnjLab Team > > > http://anjlab.com > > > > > > > > > > > -- > > George Christman > > www.CarDaddy.com > > P.O. Box 735 > > Johnstown, New York > > > > > > -- > Dmitry Gusev > > AnjLab Team > http://anjlab.com > -- George Christman www.CarDaddy.com P.O. Box 735 Johnstown, New York
Re: Prevent session id from appearing in URL while being indexed by google
I don't think requiring cookies is a bad idea. I think every normal user would have cookies enabled. On Wed, Jun 4, 2014 at 4:59 PM, George Christman wrote: > I'm already using tomcat7. Do you think requiring all users to have cookies > enabled is a bad idea? > > > On Wed, Jun 4, 2014 at 8:32 AM, Dmitry Gusev > wrote: > > > I don't think you should migrate your app server to do this, your current > > server probably supports this feature too! > > What is it btw? > > > > There will be side-effects: users without cookies won't be able to use > > sessions in your app. > > > > > > On Wed, Jun 4, 2014 at 4:28 PM, George Christman < > gchrist...@cardaddy.com> > > wrote: > > > > > Thanks Dmitry, so if I understand this correctly, I should be able to > > just > > > do the following and it should address the issue without side effects? > > > > > > 3. Switch to Tomcat 7 ! > > > > > > The Servlet 3.0 standard gives you two ways to disable URL session > > > rewriting. This works in Tomcat 7, Glassfish v3, and any other Servlet > > > 3.0-compliant servlet container. First, you can add this to your > web.xml > > > webapp config: > > > > > > > > > COOKIE > > > > > > > > > > > > On Wed, Jun 4, 2014 at 6:58 AM, Dmitry Gusev > > > wrote: > > > > > > > Hi George, > > > > > > > > The ID appears in URLs if your app creates session for current user & > > > this > > > > user has cookies disabled. > > > > > > > > You can either not create a session for guests, or disable session ID > > in > > > > URLs in servlet container level, > > > > here's an example for tomcat: > > > > https://fralef.me/tomcat-disable-jsessionid-in-url.html > > > > > > > > > > > > > > > > On Wed, Jun 4, 2014 at 10:48 AM, George Christman < > > > gchrist...@cardaddy.com > > > > > > > > > wrote: > > > > > > > > > Hi guys, I'm noticing Google is indexing a lot of pages with the > > > session > > > > id > > > > > appended to the URL, how do I prevent this? Please see link below > for > > > > > example. > > > > > > > > > > > > > > > > > > > > > > > > > https://www.google.com/search?q=site:cardaddy.com&client=firefox-a&hs=qLR&rls=org.mozilla:en-US:official&channel=sb&ei=d8COU_CRDJSmsQT_lIDoDQ&start=80&sa=N&biw=1280&bih=1199 > > > > > > > > > > -- > > > > > George Christman > > > > > www.CarDaddy.com > > > > > P.O. Box 735 > > > > > Johnstown, New York > > > > > > > > > > > > > > > > > > > > > -- > > > > Dmitry Gusev > > > > > > > > AnjLab Team > > > > http://anjlab.com > > > > > > > > > > > > > > > > -- > > > George Christman > > > www.CarDaddy.com > > > P.O. Box 735 > > > Johnstown, New York > > > > > > > > > > > -- > > Dmitry Gusev > > > > AnjLab Team > > http://anjlab.com > > > > > > -- > George Christman > www.CarDaddy.com > P.O. Box 735 > Johnstown, New York > -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: Prevent session id from appearing in URL while being indexed by google
I'm already using tomcat7. Do you think requiring all users to have cookies enabled is a bad idea? On Wed, Jun 4, 2014 at 8:32 AM, Dmitry Gusev wrote: > I don't think you should migrate your app server to do this, your current > server probably supports this feature too! > What is it btw? > > There will be side-effects: users without cookies won't be able to use > sessions in your app. > > > On Wed, Jun 4, 2014 at 4:28 PM, George Christman > wrote: > > > Thanks Dmitry, so if I understand this correctly, I should be able to > just > > do the following and it should address the issue without side effects? > > > > 3. Switch to Tomcat 7 ! > > > > The Servlet 3.0 standard gives you two ways to disable URL session > > rewriting. This works in Tomcat 7, Glassfish v3, and any other Servlet > > 3.0-compliant servlet container. First, you can add this to your web.xml > > webapp config: > > > > > > COOKIE > > > > > > > > On Wed, Jun 4, 2014 at 6:58 AM, Dmitry Gusev > > wrote: > > > > > Hi George, > > > > > > The ID appears in URLs if your app creates session for current user & > > this > > > user has cookies disabled. > > > > > > You can either not create a session for guests, or disable session ID > in > > > URLs in servlet container level, > > > here's an example for tomcat: > > > https://fralef.me/tomcat-disable-jsessionid-in-url.html > > > > > > > > > > > > On Wed, Jun 4, 2014 at 10:48 AM, George Christman < > > gchrist...@cardaddy.com > > > > > > > wrote: > > > > > > > Hi guys, I'm noticing Google is indexing a lot of pages with the > > session > > > id > > > > appended to the URL, how do I prevent this? Please see link below for > > > > example. > > > > > > > > > > > > > > > > > > https://www.google.com/search?q=site:cardaddy.com&client=firefox-a&hs=qLR&rls=org.mozilla:en-US:official&channel=sb&ei=d8COU_CRDJSmsQT_lIDoDQ&start=80&sa=N&biw=1280&bih=1199 > > > > > > > > -- > > > > George Christman > > > > www.CarDaddy.com > > > > P.O. Box 735 > > > > Johnstown, New York > > > > > > > > > > > > > > > > -- > > > Dmitry Gusev > > > > > > AnjLab Team > > > http://anjlab.com > > > > > > > > > > > -- > > George Christman > > www.CarDaddy.com > > P.O. Box 735 > > Johnstown, New York > > > > > > -- > Dmitry Gusev > > AnjLab Team > http://anjlab.com > -- George Christman www.CarDaddy.com P.O. Box 735 Johnstown, New York
Re: Prevent session id from appearing in URL while being indexed by google
I don't think you should migrate your app server to do this, your current server probably supports this feature too! What is it btw? There will be side-effects: users without cookies won't be able to use sessions in your app. On Wed, Jun 4, 2014 at 4:28 PM, George Christman wrote: > Thanks Dmitry, so if I understand this correctly, I should be able to just > do the following and it should address the issue without side effects? > > 3. Switch to Tomcat 7 ! > > The Servlet 3.0 standard gives you two ways to disable URL session > rewriting. This works in Tomcat 7, Glassfish v3, and any other Servlet > 3.0-compliant servlet container. First, you can add this to your web.xml > webapp config: > > > COOKIE > > > > On Wed, Jun 4, 2014 at 6:58 AM, Dmitry Gusev > wrote: > > > Hi George, > > > > The ID appears in URLs if your app creates session for current user & > this > > user has cookies disabled. > > > > You can either not create a session for guests, or disable session ID in > > URLs in servlet container level, > > here's an example for tomcat: > > https://fralef.me/tomcat-disable-jsessionid-in-url.html > > > > > > > > On Wed, Jun 4, 2014 at 10:48 AM, George Christman < > gchrist...@cardaddy.com > > > > > wrote: > > > > > Hi guys, I'm noticing Google is indexing a lot of pages with the > session > > id > > > appended to the URL, how do I prevent this? Please see link below for > > > example. > > > > > > > > > > > > https://www.google.com/search?q=site:cardaddy.com&client=firefox-a&hs=qLR&rls=org.mozilla:en-US:official&channel=sb&ei=d8COU_CRDJSmsQT_lIDoDQ&start=80&sa=N&biw=1280&bih=1199 > > > > > > -- > > > George Christman > > > www.CarDaddy.com > > > P.O. Box 735 > > > Johnstown, New York > > > > > > > > > > > -- > > Dmitry Gusev > > > > AnjLab Team > > http://anjlab.com > > > > > > -- > George Christman > www.CarDaddy.com > P.O. Box 735 > Johnstown, New York > -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: Prevent session id from appearing in URL while being indexed by google
Thanks Dmitry, so if I understand this correctly, I should be able to just do the following and it should address the issue without side effects? 3. Switch to Tomcat 7 ! The Servlet 3.0 standard gives you two ways to disable URL session rewriting. This works in Tomcat 7, Glassfish v3, and any other Servlet 3.0-compliant servlet container. First, you can add this to your web.xml webapp config: COOKIE On Wed, Jun 4, 2014 at 6:58 AM, Dmitry Gusev wrote: > Hi George, > > The ID appears in URLs if your app creates session for current user & this > user has cookies disabled. > > You can either not create a session for guests, or disable session ID in > URLs in servlet container level, > here's an example for tomcat: > https://fralef.me/tomcat-disable-jsessionid-in-url.html > > > > On Wed, Jun 4, 2014 at 10:48 AM, George Christman > > wrote: > > > Hi guys, I'm noticing Google is indexing a lot of pages with the session > id > > appended to the URL, how do I prevent this? Please see link below for > > example. > > > > > > > https://www.google.com/search?q=site:cardaddy.com&client=firefox-a&hs=qLR&rls=org.mozilla:en-US:official&channel=sb&ei=d8COU_CRDJSmsQT_lIDoDQ&start=80&sa=N&biw=1280&bih=1199 > > > > -- > > George Christman > > www.CarDaddy.com > > P.O. Box 735 > > Johnstown, New York > > > > > > -- > Dmitry Gusev > > AnjLab Team > http://anjlab.com > -- George Christman www.CarDaddy.com P.O. Box 735 Johnstown, New York
Re: Prevent session id from appearing in URL while being indexed by google
Hi George, The ID appears in URLs if your app creates session for current user & this user has cookies disabled. You can either not create a session for guests, or disable session ID in URLs in servlet container level, here's an example for tomcat: https://fralef.me/tomcat-disable-jsessionid-in-url.html On Wed, Jun 4, 2014 at 10:48 AM, George Christman wrote: > Hi guys, I'm noticing Google is indexing a lot of pages with the session id > appended to the URL, how do I prevent this? Please see link below for > example. > > > https://www.google.com/search?q=site:cardaddy.com&client=firefox-a&hs=qLR&rls=org.mozilla:en-US:official&channel=sb&ei=d8COU_CRDJSmsQT_lIDoDQ&start=80&sa=N&biw=1280&bih=1199 > > -- > George Christman > www.CarDaddy.com > P.O. Box 735 > Johnstown, New York > -- Dmitry Gusev AnjLab Team http://anjlab.com
