[
http://issues.apache.org/jira/browse/TAPESTRY-796?page=comments#action_12360192
]
Paul Cantrell commented on TAPESTRY-796:
----------------------------------------
Howard, please, there's no need to be so snotty. I floated my problem on the
user list (without a response), did in fact check the documentation, and
decided that the behavior I was seeing was genuinely incorrect. I submitted
this bug in good faith; I meant no disrespect by it.
So yes, it seems that mapping all my URL patterns individually does fix the
problem:
<servlet-mapping>
<servlet-name>tapestry</servlet-name>
<url-pattern>*.html</url-pattern>
</servlet-mapping>
...but because I make extensive use of custom URL encodings, my app is going to
end up having an awful wad of these mappings. And because *every* URL in the
app is meant to go through Tapestry, it seemed simpler just to use a single /*
mapping. (If I really enjoyed having scads of XML configuration, I'd be using
Struts!)
Yes, I'm not copying the documentation verbatim, but as far as I can tell, this
is a perfectly reasonable approach based on what documentation says. I'm afraid
I presumed it would not be an issue -- if the request makes it to Tapestry,
then Tapestry can parse it all by itself, right?
Well, wrong, obviously. However, I can't find anything in the documentation
that explains why, or warns against this.
If this is not a "real" bug, it is at least a "real" undesired behavior. At the
*very* least, the documentation should explicitly state what kinds of mappings
are permissible. At best, Tapestry should deal with any URL that comes its way,
and give developers the flexibility to fight configuration sprawl.
Again, please, I mean no disrespect to the excellent work of the Tapestry team.
I simply think that what I'm trying to do is reasonable, and Tapestry should
either support it, or explain clearly why it cannot work. That's all. Hang in
there, Howard; your users are your friends.
Cheers,
Paul
> page-service-encoder for external service no longer working
> -----------------------------------------------------------
>
> Key: TAPESTRY-796
> URL: http://issues.apache.org/jira/browse/TAPESTRY-796
> Project: Tapestry
> Type: Bug
> Versions: 4.0
> Environment: 4.0rc1, Tomcat 5.5.9, OS X 10.4.3
> Reporter: Paul Cantrell
>
> Using the page-service-encoder to map a file extension to the external page
> service no longer works.
> If I create these three files, the Home page correctly links to Page 2:
> Home.html:
> <html>
> <body>
> <h1>Home Page</h1>
> <a href="#" jwcid="@ExternalLink" page="Page2">Page 2</a>
> </html>
> Page2.html:
> <html>
> <body>
> <h1>Page 2</h1>
> </html>
> Page2.java:
> // insert default page package and imports here
> public class Page2 extends BasePage implements IExternalPage {
> public void activateExternalPage(Object[] x, IRequestCycle y) { }
> }
> However, if I add this single configuration to my Hivemodule:
> <contribution configuration-id="tapestry.url.ServiceEncoders">
> <page-service-encoder id="external" extension="html" service="external"
> />
> </contribution>
> ...then every link goes to the home page. The link on Home correctly gets
> encoded as /myapp/Page2.html, but that request just brings up the Home page
> again.
> No errors appear in the log file.
> The Tapestry servlet is mapped in web.xml as follows:
> <servlet>
> <servlet-name>tapestry</servlet-name>
> <servlet-class>org.apache.tapestry.ApplicationServlet</servlet-class>
> <load-on-startup>1</load-on-startup>
> </servlet>
> <servlet-mapping>
> <servlet-name>tapestry</servlet-name> <url-pattern>/*</url-pattern>
> </servlet-mapping>
> This didn't get a response on the user mailing list, so I'm presuming it's a
> legitimate bug.
> This worked in Tapestry 4.0b6, but broken when I upgraded to rc1.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
