Prevent session id from appearing in URL while being indexed by google
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.comclient=firefox-ahs=qLRrls=org.mozilla:en-US:officialchannel=sbei=d8COU_CRDJSmsQT_lIDoDQstart=80sa=Nbiw=1280bih=1199 -- 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 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.comclient=firefox-ahs=qLRrls=org.mozilla:en-US:officialchannel=sbei=d8COU_CRDJSmsQT_lIDoDQstart=80sa=Nbiw=1280bih=1199 -- 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: session-config tracking-modeCOOKIE/tracking-mode /session-config On Wed, Jun 4, 2014 at 6:58 AM, Dmitry Gusev dmitry.gu...@gmail.com 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.comclient=firefox-ahs=qLRrls=org.mozilla:en-US:officialchannel=sbei=d8COU_CRDJSmsQT_lIDoDQstart=80sa=Nbiw=1280bih=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
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: session-config tracking-modeCOOKIE/tracking-mode /session-config On Wed, Jun 4, 2014 at 6:58 AM, Dmitry Gusev dmitry.gu...@gmail.com 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.comclient=firefox-ahs=qLRrls=org.mozilla:en-US:officialchannel=sbei=d8COU_CRDJSmsQT_lIDoDQstart=80sa=Nbiw=1280bih=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
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 dmitry.gu...@gmail.com 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: session-config tracking-modeCOOKIE/tracking-mode /session-config On Wed, Jun 4, 2014 at 6:58 AM, Dmitry Gusev dmitry.gu...@gmail.com 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.comclient=firefox-ahs=qLRrls=org.mozilla:en-US:officialchannel=sbei=d8COU_CRDJSmsQT_lIDoDQstart=80sa=Nbiw=1280bih=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 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 gchrist...@cardaddy.com 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 dmitry.gu...@gmail.com 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: session-config tracking-modeCOOKIE/tracking-mode /session-config On Wed, Jun 4, 2014 at 6:58 AM, Dmitry Gusev dmitry.gu...@gmail.com 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.comclient=firefox-ahs=qLRrls=org.mozilla:en-US:officialchannel=sbei=d8COU_CRDJSmsQT_lIDoDQstart=80sa=Nbiw=1280bih=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
Thanks Dmitry. I'll move forward with that solution. On Wed, Jun 4, 2014 at 9:16 AM, Dmitry Gusev dmitry.gu...@gmail.com 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 gchrist...@cardaddy.com 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 dmitry.gu...@gmail.com 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: session-config tracking-modeCOOKIE/tracking-mode /session-config On Wed, Jun 4, 2014 at 6:58 AM, Dmitry Gusev dmitry.gu...@gmail.com 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.comclient=firefox-ahs=qLRrls=org.mozilla:en-US:officialchannel=sbei=d8COU_CRDJSmsQT_lIDoDQstart=80sa=Nbiw=1280bih=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: 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 mag...@kvalheim.eu 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 lance.j...@googlemail.com 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 gchrist...@cardaddy.com 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
On Wed, 04 Jun 2014 10:16:24 -0300, Dmitry Gusev dmitry.gu...@gmail.com 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: event triggering inside form loop
There's another interesting case (probably related to this problem). I'll
keep it very simple.
1) component1
...
t:ajaxformloop
t:component2/
/t:ajaxformloop
...
2) component2
...
t:component3/
...
void onMyEventFromComponent3 () {
// do something
}
3) component3
...
t:submit t:id=submit defer=false/
...
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 ilya.obsha...@gmail.com
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:
t:ajaxformloop
t:submit t:id=someId p:context=loopContext/
/t:ajaxformloop
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
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 dmitry.gu...@gmail.com 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: 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 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? 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 dmitry.gu...@gmail.com 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
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
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
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: 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 rhai...@allogy.com
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
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
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
