You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Geoff Longman (JIRA)" <ta...@jakarta.apache.org> on 2005/10/23 21:15:07 UTC
[jira] Created: (TAPESTRY-724) Tapestry may, in some cases, look for a page class in the wrong package
Tapestry may, in some cases, look for a page class in the wrong package
-----------------------------------------------------------------------
Key: TAPESTRY-724
URL: http://issues.apache.org/jira/browse/TAPESTRY-724
Project: Tapestry
Type: Bug
Components: Framework
Versions: 4.0
Reporter: Geoff Longman
Priority: Critical
I've been trying to come up with a patch but work has been getting crazy and I have been ill for days now.
A detailed description of the problem (and apossible solution) is to be found here:
http://wiki.apache.org/jakarta-tapestry/GeoffLongmanSandbox
In a nutshell, if a user references a Tapestry page whose class must be found from a given list of packages it may be the case that way they have referenced (by name) may mislead the ComponentClassProvider to look in the wrong package. If that happens, the class is not found and (in most cases) BasePage is assigned as the page class. Often this will break the application if the page depends on a class other than BasePage. Depending on how the app is set up there could be 3 or more legal ways to reference a page by name (path parts) but only one way will result in the right page class being located.
--
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: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
[jira] Assigned: (TAPESTRY-724) Tapestry may, in some cases, look for a page class in the wrong package
Posted by "Howard M. Lewis Ship (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-724?page=all ]
Howard M. Lewis Ship reassigned TAPESTRY-724:
---------------------------------------------
Assign To: Howard M. Lewis Ship
> Tapestry may, in some cases, look for a page class in the wrong package
> -----------------------------------------------------------------------
>
> Key: TAPESTRY-724
> URL: http://issues.apache.org/jira/browse/TAPESTRY-724
> Project: Tapestry
> Type: Bug
> Components: Framework
> Versions: 4.0
> Reporter: Geoff Longman
> Assignee: Howard M. Lewis Ship
> Priority: Critical
> Attachments: test.zip
>
> I've been trying to come up with a patch but work has been getting crazy and I have been ill for days now.
> A detailed description of the problem (and apossible solution) is to be found here:
> http://wiki.apache.org/jakarta-tapestry/GeoffLongmanSandbox
> In a nutshell, if a user references a Tapestry page whose class must be found from a given list of packages it may be the case that way they have referenced (by name) may mislead the ComponentClassProvider to look in the wrong package. If that happens, the class is not found and (in most cases) BasePage is assigned as the page class. Often this will break the application if the page depends on a class other than BasePage. Depending on how the app is set up there could be 3 or more legal ways to reference a page by name (path parts) but only one way will result in the right page class being located.
--
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: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
[jira] Commented: (TAPESTRY-724) Tapestry may, in some cases, look for a page class in the wrong package
Posted by "Geoff Longman (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-724?page=comments#action_12357380 ]
Geoff Longman commented on TAPESTRY-724:
----------------------------------------
It's a pickle for sure. What's the page name? There are too many ways to map different names to the same page. I'll spare you more blathering there are good examples in the wiki and even more in the mail I have sent you already.
> Tapestry may, in some cases, look for a page class in the wrong package
> -----------------------------------------------------------------------
>
> Key: TAPESTRY-724
> URL: http://issues.apache.org/jira/browse/TAPESTRY-724
> Project: Tapestry
> Type: Bug
> Components: Framework
> Versions: 4.0
> Reporter: Geoff Longman
> Assignee: Howard M. Lewis Ship
> Priority: Critical
> Attachments: test.zip
>
> I've been trying to come up with a patch but work has been getting crazy and I have been ill for days now.
> A detailed description of the problem (and apossible solution) is to be found here:
> http://wiki.apache.org/jakarta-tapestry/GeoffLongmanSandbox
> In a nutshell, if a user references a Tapestry page whose class must be found from a given list of packages it may be the case that way they have referenced (by name) may mislead the ComponentClassProvider to look in the wrong package. If that happens, the class is not found and (in most cases) BasePage is assigned as the page class. Often this will break the application if the page depends on a class other than BasePage. Depending on how the app is set up there could be 3 or more legal ways to reference a page by name (path parts) but only one way will result in the right page class being located.
--
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: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
[jira] Commented: (TAPESTRY-724) Tapestry may, in some cases, look for a page class in the wrong package
Posted by "Geoff Longman (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-724?page=comments#action_12359120 ]
Geoff Longman commented on TAPESTRY-724:
----------------------------------------
I'm thinking hard about how Spindle will work with a static project.
Here is the Spindle problem in capsule format.
Specless pages - Spindle has no notion of the "name" used to access the page.
Pages have templates, I can find those easily.
If I can work back from the template to the class/spec I'm laughing.
How to do this? Specless page templates are relative to the context root, and with the new exclusion of WEB-INF, I can eliminate templates under WEB-INF. yay!
So, any template in the context is a potential specless page.
Tapestry puts the fake spec relative to the namespace location (no path), I can duplicate this.
I have the path of the template, can I infer that the classname will be similar to that path?
ie: context:/pages/Foo.html implies <something>.pages.Foo is the class?
Specful pages - I can find the Spec - if the spec declares the class, fine.
If not, acrobatics ensue - this is the crux of this bug report.
Given (and this is all Spindle has to go with!):
/WEB-INF/pages/Foo.page
Assuming that Foo.page is not declared in the namespace file I think it's realistic that the *only way* someone can reference the page is "pages/Foo".
and thus the class will be <something>.pages.Foo
Is this true?
Now the scary part:
<page name="Foo" specification-path="pages/Foo.page"/>
<page name="Moo" specification-path="pages/Foo.page/>
If Foo.page declares the class - fine, no problem.
If not, I'm stuck. And this is where Tapestry will break at runtime in varied an interesting ways depending on what the user decides to name the class.
Perhaps the above should be an error? This is another special case and a hard thing I think for Tapestry to capture at runtime. Recall the above *is ok* if Foo.page declares its class explicity.
But, I'm thinking that Spindle *can* capture this case and mark an error.
So the question is: are you willing to let this "unfortunate ambiguity" remain in the Tapestry codebase?
I have a nugget of an idea on how Tapestry can capture the baddie situation and throw an error..
More to follow.
> Tapestry may, in some cases, look for a page class in the wrong package
> -----------------------------------------------------------------------
>
> Key: TAPESTRY-724
> URL: http://issues.apache.org/jira/browse/TAPESTRY-724
> Project: Tapestry
> Type: Bug
> Components: Framework
> Versions: 4.0
> Reporter: Geoff Longman
> Assignee: Howard M. Lewis Ship
> Priority: Critical
> Attachments: test.zip
>
> I've been trying to come up with a patch but work has been getting crazy and I have been ill for days now.
> A detailed description of the problem (and apossible solution) is to be found here:
> http://wiki.apache.org/jakarta-tapestry/GeoffLongmanSandbox
> In a nutshell, if a user references a Tapestry page whose class must be found from a given list of packages it may be the case that way they have referenced (by name) may mislead the ComponentClassProvider to look in the wrong package. If that happens, the class is not found and (in most cases) BasePage is assigned as the page class. Often this will break the application if the page depends on a class other than BasePage. Depending on how the app is set up there could be 3 or more legal ways to reference a page by name (path parts) but only one way will result in the right page class being located.
--
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: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
[jira] Commented: (TAPESTRY-724) Tapestry may, in some cases, look for a page class in the wrong package
Posted by "Jesse Kuhnert (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-724?page=comments#action_12359196 ]
Jesse Kuhnert commented on TAPESTRY-724:
----------------------------------------
Hey may have just been getting ready for what was going to be a fix? I did just see a bunch of new test cases that looked like they were created specifically for this ticket.
> Tapestry may, in some cases, look for a page class in the wrong package
> -----------------------------------------------------------------------
>
> Key: TAPESTRY-724
> URL: http://issues.apache.org/jira/browse/TAPESTRY-724
> Project: Tapestry
> Type: Bug
> Components: Framework
> Versions: 4.0
> Reporter: Geoff Longman
> Assignee: Howard M. Lewis Ship
> Priority: Critical
> Attachments: test.zip
>
> I've been trying to come up with a patch but work has been getting crazy and I have been ill for days now.
> A detailed description of the problem (and apossible solution) is to be found here:
> http://wiki.apache.org/jakarta-tapestry/GeoffLongmanSandbox
> In a nutshell, if a user references a Tapestry page whose class must be found from a given list of packages it may be the case that way they have referenced (by name) may mislead the ComponentClassProvider to look in the wrong package. If that happens, the class is not found and (in most cases) BasePage is assigned as the page class. Often this will break the application if the page depends on a class other than BasePage. Depending on how the app is set up there could be 3 or more legal ways to reference a page by name (path parts) but only one way will result in the right page class being located.
--
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: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
[jira] Resolved: (TAPESTRY-724) Tapestry may, in some cases, look for a page class in the wrong package
Posted by "Howard M. Lewis Ship (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-724?page=all ]
Howard M. Lewis Ship resolved TAPESTRY-724:
-------------------------------------------
Fix Version: 4.0
Resolution: Fixed
Geoff is not happy with this solution, but there it is. Main change was to ensure that pages couldn't be named "WEB-INF/Foo".
> Tapestry may, in some cases, look for a page class in the wrong package
> -----------------------------------------------------------------------
>
> Key: TAPESTRY-724
> URL: http://issues.apache.org/jira/browse/TAPESTRY-724
> Project: Tapestry
> Type: Bug
> Components: Framework
> Versions: 4.0
> Reporter: Geoff Longman
> Assignee: Howard M. Lewis Ship
> Priority: Critical
> Fix For: 4.0
> Attachments: test.zip
>
> I've been trying to come up with a patch but work has been getting crazy and I have been ill for days now.
> A detailed description of the problem (and apossible solution) is to be found here:
> http://wiki.apache.org/jakarta-tapestry/GeoffLongmanSandbox
> In a nutshell, if a user references a Tapestry page whose class must be found from a given list of packages it may be the case that way they have referenced (by name) may mislead the ComponentClassProvider to look in the wrong package. If that happens, the class is not found and (in most cases) BasePage is assigned as the page class. Often this will break the application if the page depends on a class other than BasePage. Depending on how the app is set up there could be 3 or more legal ways to reference a page by name (path parts) but only one way will result in the right page class being located.
--
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: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
[jira] Commented: (TAPESTRY-724) Tapestry may, in some cases, look for a page class in the wrong package
Posted by "Geoff Longman (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-724?page=comments#action_12356408 ]
Geoff Longman commented on TAPESTRY-724:
----------------------------------------
I'm not sure that banning /WEB-INF is the way to go. Consistency is what is being sacrificed right now.
Everyone's time is precious and pressures come from all sides. There is pressure on you Howard to take T4 to RC and I'm under pressure from another, albeit related, community to produce Spindle for T4. Now is a good time to address this issue since as of today I'm under orders from the boss (my wife) not work any more late nights until I kick this flu (which is now well into it's second week) anyways. You are right Howard, this is not a simple fix. I want to contribute what I find but the silence has been deafening.
Sometimes you have to raise your voice when it appears to fall on deaf ears.
> Tapestry may, in some cases, look for a page class in the wrong package
> -----------------------------------------------------------------------
>
> Key: TAPESTRY-724
> URL: http://issues.apache.org/jira/browse/TAPESTRY-724
> Project: Tapestry
> Type: Bug
> Components: Framework
> Versions: 4.0
> Reporter: Geoff Longman
> Assignee: Howard M. Lewis Ship
> Priority: Critical
> Attachments: test.zip
>
> I've been trying to come up with a patch but work has been getting crazy and I have been ill for days now.
> A detailed description of the problem (and apossible solution) is to be found here:
> http://wiki.apache.org/jakarta-tapestry/GeoffLongmanSandbox
> In a nutshell, if a user references a Tapestry page whose class must be found from a given list of packages it may be the case that way they have referenced (by name) may mislead the ComponentClassProvider to look in the wrong package. If that happens, the class is not found and (in most cases) BasePage is assigned as the page class. Often this will break the application if the page depends on a class other than BasePage. Depending on how the app is set up there could be 3 or more legal ways to reference a page by name (path parts) but only one way will result in the right page class being located.
--
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: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
[jira] Commented: (TAPESTRY-724) Tapestry may, in some cases, look for a page class in the wrong package
Posted by "Henri Dupre (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-724?page=comments#action_12359356 ]
Henri Dupre commented on TAPESTRY-724:
--------------------------------------
> >I see the page name as the real identity, and the fact that different pages can share the same page
> >specification to be an unfortunate ambiguity.
>
> Let me turn that around. If page specs can be associated with more than one class (whatever the name of the class is based on) there is possibly no to build a tool like Spindle that can reasonable handle it and still be user friendly.
I don't understand this case. Why and how would a spec be able to be associated with more than one class? I can understand mapping one spec to several page names but not mapping one spec to several classes.
If I understand the issue the problem to solve is deal with:
<page name="P1" specification-path="pages/Page"/>
<page name="P2" specification-path="pages/Page"/>
Why don't thow an error message in this case if there is no .page available?
I thought the .page specs were still fully supported.. so with a .page file, tapestry should be able to map from a page to a class without issues., right?
And allowing .page descriptions without a class doesn't make sense to me... Either you develop specless or not.
> Tapestry may, in some cases, look for a page class in the wrong package
> -----------------------------------------------------------------------
>
> Key: TAPESTRY-724
> URL: http://issues.apache.org/jira/browse/TAPESTRY-724
> Project: Tapestry
> Type: Bug
> Components: Framework
> Versions: 4.0
> Reporter: Geoff Longman
> Assignee: Howard M. Lewis Ship
> Priority: Critical
> Attachments: test.zip
>
> I've been trying to come up with a patch but work has been getting crazy and I have been ill for days now.
> A detailed description of the problem (and apossible solution) is to be found here:
> http://wiki.apache.org/jakarta-tapestry/GeoffLongmanSandbox
> In a nutshell, if a user references a Tapestry page whose class must be found from a given list of packages it may be the case that way they have referenced (by name) may mislead the ComponentClassProvider to look in the wrong package. If that happens, the class is not found and (in most cases) BasePage is assigned as the page class. Often this will break the application if the page depends on a class other than BasePage. Depending on how the app is set up there could be 3 or more legal ways to reference a page by name (path parts) but only one way will result in the right page class being located.
--
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: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
[jira] Updated: (TAPESTRY-724) Tapestry may, in some cases, look for a page class in the wrong package
Posted by "Geoff Longman (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-724?page=all ]
Geoff Longman updated TAPESTRY-724:
-----------------------------------
Attachment: test.zip
a project that demonstrates the problem. includes a JettyLauncher launch config but not the Tapestry jars or it's dependencies.
> Tapestry may, in some cases, look for a page class in the wrong package
> -----------------------------------------------------------------------
>
> Key: TAPESTRY-724
> URL: http://issues.apache.org/jira/browse/TAPESTRY-724
> Project: Tapestry
> Type: Bug
> Components: Framework
> Versions: 4.0
> Reporter: Geoff Longman
> Priority: Critical
> Attachments: test.zip
>
> I've been trying to come up with a patch but work has been getting crazy and I have been ill for days now.
> A detailed description of the problem (and apossible solution) is to be found here:
> http://wiki.apache.org/jakarta-tapestry/GeoffLongmanSandbox
> In a nutshell, if a user references a Tapestry page whose class must be found from a given list of packages it may be the case that way they have referenced (by name) may mislead the ComponentClassProvider to look in the wrong package. If that happens, the class is not found and (in most cases) BasePage is assigned as the page class. Often this will break the application if the page depends on a class other than BasePage. Depending on how the app is set up there could be 3 or more legal ways to reference a page by name (path parts) but only one way will result in the right page class being located.
--
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: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
[jira] Commented: (TAPESTRY-724) Tapestry may, in some cases, look for a page class in the wrong package
Posted by "Geoff Longman (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-724?page=comments#action_12359117 ]
Geoff Longman commented on TAPESTRY-724:
----------------------------------------
>So far, I've added tests to ensure that your case #3 is rejected out of hand. That is, page names that start with "/WEB-INF/" or "WEB-INF/" (case
>insensitive) are rejected out of hand. Example error message:
>Page name '/WEB-Inf/BadName' is not valid, as it directly references a file stored in the WEB-INF folder.
ok. a valid solution.
>I still see the only ambiguity is the page name vs. the specification path.
>You have "Page" mapped to "MyPage.page". Done this way, Tapestry doesn't locate the Java class "com.myfoo.MyPage" since it looks >for "com.myfoo.Page" instead.
>I'm having trouble seeing why this is a problem.
What about if someone does this?
<page name="P1" specification-path="pages/Page"/>
<page name="P2" specification-path="pages/Page"/>
Going to cause problems! The easy solution would be to ban the above outright but I think doing this would decrease the usefulness of specifying pages directly in the namespace xml.
Follows is a case in T3 where we found the ability to map two names to one spec useful...
We actually have this in our T3 application right now. We have a page that is show that has displays links ans styles them to look ike tabs. These tabs appear on the top of every page and thier behaviour is dependant on what page is displaying them. Call the tabs "Manage" and "Create". But, there are many pages that would are considered "Manage" pages and other that are considered "Create" pages. In the case of the "Create" there are 3 pages (a 3 step wizard).
If a "Manage" page is rendered, the Manage tab appears to be selected. The opposite applies for "Create" pages. There is also a 'home' page for each tab. Clicking the "Create" will always take the user to "CreateActivityStep1".
We have a component that renders the tabs. The component knows which pages (a map of page names) fall under each tab and also which is the 'home' page for each tab. When the Tab component renders, it chooses css for the tabs based on the name of the page it being rendered. A create page would cause the tab component to render the "Create" tab as selected and not clickable while the "Manage" tab is smaller and clickable.
Long story short we ran into a case where one page needed to be shown in both tabs. Since the component was keying off of the page name we aliased the shared page with two names, one each for the Manage and one for the Create cases. This was the easiest solution ( literally a 5 minute solution) as the page behaves exactly the same in both cases.
<page name="ConfirmActivitySaveManage" specification-path="pages/ConfirmActivitySave.page"/>
<page name="ConfirmActivitySaveCreate" specification-path="pages/ConfirmActivitySave.page"/>
So what would happen in this case? Our class is called ConfirmActivitySave.java and Tapestry would never find it.
Say we were managing, Tapestry would look for and fail to find ConfirmActivityManage.class. And **Tapestry would never ever look for ConfirmActivitySaveCreate"** since it chose BasePage when ConfirmActivityManage.class. Even worse, our page class is niether of the name options.
So I rename the class to ConfirmActivitySaveManage.java - this works only if the user visits a Manage page first and will fail if they visit the create tab first.
It's a contrived example, in the xml. I like the xml and don't ever see myself making a totally xml-less page.in this case I would continue to specify the classname
>The Java class is derived from the page name not the specification path. I think this is correct and is the path I prefer in the future, where the page
>class is always resolved from the page name BEFORE the page specification is located and read.
The future is the future. Tapestry 4 is what's going out the door soon.
>What we have here are two distrinct pages, "Page" and "MyPage", that share a single page specification, but are distinct from Tapestry's point of view.
>The key thing is that the page name drives the process, everything else is subservient to it. Its unfortunate that the current evolution of the framework
>yields these kinds of ambiguities.
You say that but when I look at the code, the spec is still resolved first. Every time.
>The solution is to follow Tapestry's rules for naming and not use the <page> element in the application specification.
But it's still allowed and Spindle must be able to handle it. Spindle has to handle **every possible legal case** or it will produce garbage.
>I don't want to introduce even more special cases that will cause even more of a headache to support in the future.
Too late man. There are so many special cases in there now. Tools don't have the luxury of picking and choosing what rules to abide by.
>At the core of this is the identity of the page; you are trying to make the identity be the page specification, and see ambiguities that you can reach that
>page specification with multiple names.
In all versions of Tapestry till now, the specification has been the identity object. Tap 3 fudged in a special case for specless pages but even then a fake specification was created to conform. Even now the specification is resolved BEFORE the class lookup occurs and fake specifications are still created as needed. If it walks like a duck and quacks like a duck...
But, the real problem, the killer problem , is if a specification file can have more than one class. Especially now with annotations contributing how does one "validate" a specification file if in some cases the annotations come from here and in some cases they come from there? Makes for a huge confusing pile of error markers on one file. Also, since the annotations in a page class can come from many other classes (superclasses, interfaces) I'm looking ahead to the same kind of problem when validating the annotations themselves. markers in the java files will have to be restricted to syntax errors as context specific errors would pile up again if say an interface was used in many pages. There needs to be one place where the context specific errors for A PAGE can pile up. The spec seems to be the logical place. The template is no good 'cuz there are potentially many templates for one page (internationalization). The case of a specless page is a case I can work around.
>I see the page name as the real identity, and the fact that different pages can share the same page
>specification to be an unfortunate ambiguity.
Let me turn that around. If page specs can be associated with more than one class (whatever the name of the class is based on) there is possibly no to build a tool like Spindle that can reasonable handle it and still be user friendly.
Ever wonder why there is no javascript IDE with the same capabiltiies of an Eclipse or IDEA? Too hard as so much depends on the runtime state. Tapestry is tripping close to that edge.
>Thus, from your point of view, we should always be looking for a Java class whose name matches the
>page spec, i.e., MyPage. From my point of view, the developer is in error to expect "Page" and "MyPage" to be the same page and use the same class.
Again I don't care if the classname aligns with the spec name. It has been an unwritten convention for a darn long time that the classname most often does align.
> Tapestry may, in some cases, look for a page class in the wrong package
> -----------------------------------------------------------------------
>
> Key: TAPESTRY-724
> URL: http://issues.apache.org/jira/browse/TAPESTRY-724
> Project: Tapestry
> Type: Bug
> Components: Framework
> Versions: 4.0
> Reporter: Geoff Longman
> Assignee: Howard M. Lewis Ship
> Priority: Critical
> Attachments: test.zip
>
> I've been trying to come up with a patch but work has been getting crazy and I have been ill for days now.
> A detailed description of the problem (and apossible solution) is to be found here:
> http://wiki.apache.org/jakarta-tapestry/GeoffLongmanSandbox
> In a nutshell, if a user references a Tapestry page whose class must be found from a given list of packages it may be the case that way they have referenced (by name) may mislead the ComponentClassProvider to look in the wrong package. If that happens, the class is not found and (in most cases) BasePage is assigned as the page class. Often this will break the application if the page depends on a class other than BasePage. Depending on how the app is set up there could be 3 or more legal ways to reference a page by name (path parts) but only one way will result in the right page class being located.
--
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: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [jira] Commented: (TAPESTRY-724) Tapestry may, in some cases,
look for a page class in the wrong package
Posted by Leonardo Quijano Vincenzi <le...@dtqsoftware.com>.
Howard Lewis Ship wrote:
> These bugs have to be fixed as well.
The question would be: just how important are them? Don't fall in the
trap of 'just keeping yourself busy' - the most important things should
go first.
(it's just advice)
> Tapestry is now nearly six years old. It is no way resemebles the
> code base when I first started. I made a number of really lucky
> guesses early on, and a couple of less than ideal choices. Some of the
> architectural issues are all but impossible to fix without completely
> disrupting backwards compatibility. At the core, I'm looking for a
> way to completley eliminate the rewind cycle and come up with a
> simpler, better way of getting data out of the request, through the
> components, and into the model properties.
>
Is there a plan to this somewhere we non-committers can contribute /
give feedback ?
>> can't I use @Parameter(required = true) in a page?).
>>
> Because pages don't have parameters, components do. You are looking
> for an entirely new concept in Tapestry ... one that may be valid, but
> simply isn't present today, so don't consider it a bug.
>
I'm considering it a limitation because I don't find any real reason as
why pages shouldn't have parameters. Anyway, I don't mind if it's
classified as a RFE or a critical bug, I'm just saying that it's nice to
have easily bookmarkeable pages (as in the ExternalService), with clear
parameters (name = value). The "required = true" is a good addition in
order to ensure pages have a valid state and avoid boilerplate code (the
"if(xxx == null) redirectToIndex()").
> I've been making passes through the database and taking on as many
> bugs as I can. We all have outside responsibilities to our lives and
> our clients, so things happen when they happen.
>
Of course, me too. I'm building a production system and it's important
to have stable software. Of course, I could use Tapestry 3, but then
again, it's been a while, and Tap 4 has a lot of added value I'd like to
use.
So, what about developer contributions? The main reason I have no
motivation to contribute code to the project is that the few attempts
I've tried to make have been ignored. People are busy? Maybe. But it's
such a waste of good, motivated, developers, don't you think?
--
Ing. Leonardo Quijano Vincenzi
Director Técnico
DTQ Software
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [jira] Commented: (TAPESTRY-724) Tapestry may, in some cases, look for a page class in the wrong package
Posted by Howard Lewis Ship <hl...@gmail.com>.
On 10/29/05, Leonardo Quijano Vincenzi <le...@dtqsoftware.com> wrote:
> My question about this and other important bug-cases is: are Tapestry
> commiters tired after all these years or something?? I recently invested
> in learning Tapestry and ditching JSF (which was a huge setback on a
> project I was working on), but I'm starting to think people here are in
> "fixing small bugs" mode
These bugs have to be fixed as well.
> and no one's paying attention to the
> architectural issues and the unnatural bugs (such as... why can't I use
> an @If condition to filter a text box?)
Tapestry is now nearly six years old. It is no way resemebles the
code base when I first started. I made a number of really lucky
guesses early on, and a couple of less than ideal choices. Some of the
architectural issues are all but impossible to fix without completely
disrupting backwards compatibility. At the core, I'm looking for a
way to completley eliminate the rewind cycle and come up with a
simpler, better way of getting data out of the request, through the
components, and into the model properties.
or strange limitations (why
> can't I use @Parameter(required = true) in a page?).
>
Because pages don't have parameters, components do. You are looking
for an entirely new concept in Tapestry ... one that may be valid, but
simply isn't present today, so don't consider it a bug.
> Maybe no one's looking well enough at the JIRA database, because there
> are lots of abandoned issues over there, and most recent commits have
> been of examples re-writing (what for? is it more important than fixing
> the problem with Checkboxes - FieldLabels?) or small bugs fixed.
I've been making passes through the database and taking on as many
bugs as I can. We all have outside responsibilities to our lives and
our clients, so things happen when they happen.
>
> As for Geoff's comment, I still fail to understand why the bug is so
> critical. The only concern about it it's the need of restarting the
> container in order to fix things. Maybe that's the primary concern about
> this. The other stuff can be solved through good conventions in the
> project, right ?
>
> --
> Ing. Leonardo Quijano Vincenzi
> Director Técnico
> DTQ Software
>
>
>
> Geoff Longman (JIRA) wrote:
> > [ http://issues.apache.org/jira/browse/TAPESTRY-724?page=comments#action_12356303 ]
> >
> > Geoff Longman commented on TAPESTRY-724:
> > ----------------------------------------
> >
> > Obviously I have not made my case clearly enough to generate even one comment. While this issue has been in JIRA for 6 days it has been a bug in my ear for 27 days and I emailed Howard privately on the first day.
> >
> > This all started as I'm trying to get Spindle updated for Tapestry 4 and I encountered what I feel is a serious bug in T4. It's behaviour that I'm loath to duplicate in Spindle as it is a tool that garners all of it's data from the static representation of a Tapestry project. The changes in the SpecificationResolver/PageLoader in T4 move this class lookup out of the static information and into the runtime behaviour of Tapestry. Spindle has never and will never try to duplicate the runtime behaviour of Tapestry.
> >
> > But that's beside the point, Tapestry is broken and nobody seems to care.
> >
> > I have ideas and suggestions on how to fix this but they are obviously skewed towards making my life as the Spindle developer easier and that may clash with the vision for Tapestry as a whole. Without any discussion on the issue I'm wasting my time even looking any further.
> >
> > Maybe I'm a bit short tempered as I have been ill for the last week but I'm fed up. I hate it that I feel driven to make the following statement...
> >
> > Consider Spindle for T4 on hold indefinitey until something moves on this issue.
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [jira] Commented: (TAPESTRY-724) Tapestry may, in some cases,
look for a page class in the wrong package
Posted by Leonardo Quijano Vincenzi <le...@dtqsoftware.com>.
My question about this and other important bug-cases is: are Tapestry
commiters tired after all these years or something?? I recently invested
in learning Tapestry and ditching JSF (which was a huge setback on a
project I was working on), but I'm starting to think people here are in
"fixing small bugs" mode and no one's paying attention to the
architectural issues and the unnatural bugs (such as... why can't I use
an @If condition to filter a text box?) or strange limitations (why
can't I use @Parameter(required = true) in a page?).
Maybe no one's looking well enough at the JIRA database, because there
are lots of abandoned issues over there, and most recent commits have
been of examples re-writing (what for? is it more important than fixing
the problem with Checkboxes - FieldLabels?) or small bugs fixed.
As for Geoff's comment, I still fail to understand why the bug is so
critical. The only concern about it it's the need of restarting the
container in order to fix things. Maybe that's the primary concern about
this. The other stuff can be solved through good conventions in the
project, right ?
--
Ing. Leonardo Quijano Vincenzi
Director Técnico
DTQ Software
Geoff Longman (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/TAPESTRY-724?page=comments#action_12356303 ]
>
> Geoff Longman commented on TAPESTRY-724:
> ----------------------------------------
>
> Obviously I have not made my case clearly enough to generate even one comment. While this issue has been in JIRA for 6 days it has been a bug in my ear for 27 days and I emailed Howard privately on the first day.
>
> This all started as I'm trying to get Spindle updated for Tapestry 4 and I encountered what I feel is a serious bug in T4. It's behaviour that I'm loath to duplicate in Spindle as it is a tool that garners all of it's data from the static representation of a Tapestry project. The changes in the SpecificationResolver/PageLoader in T4 move this class lookup out of the static information and into the runtime behaviour of Tapestry. Spindle has never and will never try to duplicate the runtime behaviour of Tapestry.
>
> But that's beside the point, Tapestry is broken and nobody seems to care.
>
> I have ideas and suggestions on how to fix this but they are obviously skewed towards making my life as the Spindle developer easier and that may clash with the vision for Tapestry as a whole. Without any discussion on the issue I'm wasting my time even looking any further.
>
> Maybe I'm a bit short tempered as I have been ill for the last week but I'm fed up. I hate it that I feel driven to make the following statement...
>
> Consider Spindle for T4 on hold indefinitey until something moves on this issue.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
[jira] Commented: (TAPESTRY-724) Tapestry may, in some cases, look for a page class in the wrong package
Posted by "Geoff Longman (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-724?page=comments#action_12356303 ]
Geoff Longman commented on TAPESTRY-724:
----------------------------------------
Obviously I have not made my case clearly enough to generate even one comment. While this issue has been in JIRA for 6 days it has been a bug in my ear for 27 days and I emailed Howard privately on the first day.
This all started as I'm trying to get Spindle updated for Tapestry 4 and I encountered what I feel is a serious bug in T4. It's behaviour that I'm loath to duplicate in Spindle as it is a tool that garners all of it's data from the static representation of a Tapestry project. The changes in the SpecificationResolver/PageLoader in T4 move this class lookup out of the static information and into the runtime behaviour of Tapestry. Spindle has never and will never try to duplicate the runtime behaviour of Tapestry.
But that's beside the point, Tapestry is broken and nobody seems to care.
I have ideas and suggestions on how to fix this but they are obviously skewed towards making my life as the Spindle developer easier and that may clash with the vision for Tapestry as a whole. Without any discussion on the issue I'm wasting my time even looking any further.
Maybe I'm a bit short tempered as I have been ill for the last week but I'm fed up. I hate it that I feel driven to make the following statement...
Consider Spindle for T4 on hold indefinitey until something moves on this issue.
> Tapestry may, in some cases, look for a page class in the wrong package
> -----------------------------------------------------------------------
>
> Key: TAPESTRY-724
> URL: http://issues.apache.org/jira/browse/TAPESTRY-724
> Project: Tapestry
> Type: Bug
> Components: Framework
> Versions: 4.0
> Reporter: Geoff Longman
> Priority: Critical
> Attachments: test.zip
>
> I've been trying to come up with a patch but work has been getting crazy and I have been ill for days now.
> A detailed description of the problem (and apossible solution) is to be found here:
> http://wiki.apache.org/jakarta-tapestry/GeoffLongmanSandbox
> In a nutshell, if a user references a Tapestry page whose class must be found from a given list of packages it may be the case that way they have referenced (by name) may mislead the ComponentClassProvider to look in the wrong package. If that happens, the class is not found and (in most cases) BasePage is assigned as the page class. Often this will break the application if the page depends on a class other than BasePage. Depending on how the app is set up there could be 3 or more legal ways to reference a page by name (path parts) but only one way will result in the right page class being located.
--
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: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
[jira] Commented: (TAPESTRY-724) Tapestry may, in some cases, look for a page class in the wrong package
Posted by "Howard M. Lewis Ship (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-724?page=comments#action_12359074 ]
Howard M. Lewis Ship commented on TAPESTRY-724:
-----------------------------------------------
So far, I've added tests to ensure that your case #3 is rejected out of hand. That is, page names that start with "/WEB-INF/" or "WEB-INF/" (case insensitive) are rejected out of hand. Example error message:
Page name '/WEB-Inf/BadName' is not valid, as it directly references a file stored in the WEB-INF folder.
I still see the only ambiguity is the page name vs. the specification path.
You have "Page" mapped to "MyPage.page". Done this way, Tapestry doesn't locate the Java class "com.myfoo.MyPage" since it looks for "com.myfoo.Page" instead.
I'm having trouble seeing why this is a problem.
The Java class is derived from the page name not the specification path. I think this is correct and is the path I prefer in the future, where the page class is always resolved from the page name BEFORE the page specification is located and read.
What we have here are two distrinct pages, "Page" and "MyPage", that share a single page specification, but are distinct from Tapestry's point of view. The key thing is that the page name drives the process, everything else is subservient to it. Its unfortunate that the current evolution of the framework yields these kinds of ambiguities.
The solution is to follow Tapestry's rules for naming and not use the <page> element in the application specification.
I don't want to introduce even more special cases that will cause even more of a headache to support in the future.
At the core of this is the identity of the page; you are trying to make the identity be the page specification, and see ambiguities that you can reach that page specification with multiple names. I see the page name as the real identity, and the fact that different pages can share the same page specification to be an unfortunate ambiguity. Thus, from your point of view, we should always be looking for a Java class whose name matches the page spec, i.e., MyPage. From my point of view, the developer is in error to expect "Page" and "MyPage" to be the same page and use the same class.
> Tapestry may, in some cases, look for a page class in the wrong package
> -----------------------------------------------------------------------
>
> Key: TAPESTRY-724
> URL: http://issues.apache.org/jira/browse/TAPESTRY-724
> Project: Tapestry
> Type: Bug
> Components: Framework
> Versions: 4.0
> Reporter: Geoff Longman
> Assignee: Howard M. Lewis Ship
> Priority: Critical
> Attachments: test.zip
>
> I've been trying to come up with a patch but work has been getting crazy and I have been ill for days now.
> A detailed description of the problem (and apossible solution) is to be found here:
> http://wiki.apache.org/jakarta-tapestry/GeoffLongmanSandbox
> In a nutshell, if a user references a Tapestry page whose class must be found from a given list of packages it may be the case that way they have referenced (by name) may mislead the ComponentClassProvider to look in the wrong package. If that happens, the class is not found and (in most cases) BasePage is assigned as the page class. Often this will break the application if the page depends on a class other than BasePage. Depending on how the app is set up there could be 3 or more legal ways to reference a page by name (path parts) but only one way will result in the right page class being located.
--
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: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
[jira] Commented: (TAPESTRY-724) Tapestry may, in some cases, look for a page class in the wrong package
Posted by "Jesse Kuhnert (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-724?page=comments#action_12359203 ]
Jesse Kuhnert commented on TAPESTRY-724:
----------------------------------------
After really reading all of these comments for the first time it sounds like a very tricky problem indeed. In the spirit of wanting to learn more about tapestry internally I can volunteer some cycles to work on this? Not that I should be able to make these kinds of decisions, but with the new branch that Howard made maybe there is soom room to play, and if it seems backwards compatible enough possibly even apply it to the 4.0 branch. I won't go any further into it unless someone says yay or nay.
> Tapestry may, in some cases, look for a page class in the wrong package
> -----------------------------------------------------------------------
>
> Key: TAPESTRY-724
> URL: http://issues.apache.org/jira/browse/TAPESTRY-724
> Project: Tapestry
> Type: Bug
> Components: Framework
> Versions: 4.0
> Reporter: Geoff Longman
> Assignee: Howard M. Lewis Ship
> Priority: Critical
> Attachments: test.zip
>
> I've been trying to come up with a patch but work has been getting crazy and I have been ill for days now.
> A detailed description of the problem (and apossible solution) is to be found here:
> http://wiki.apache.org/jakarta-tapestry/GeoffLongmanSandbox
> In a nutshell, if a user references a Tapestry page whose class must be found from a given list of packages it may be the case that way they have referenced (by name) may mislead the ComponentClassProvider to look in the wrong package. If that happens, the class is not found and (in most cases) BasePage is assigned as the page class. Often this will break the application if the page depends on a class other than BasePage. Depending on how the app is set up there could be 3 or more legal ways to reference a page by name (path parts) but only one way will result in the right page class being located.
--
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: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
[jira] Commented: (TAPESTRY-724) Tapestry may, in some cases, look for a page class in the wrong package
Posted by "Henri Dupre (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-724?page=comments#action_12356307 ]
Henri Dupre commented on TAPESTRY-724:
--------------------------------------
Specifying pages starting with /WEB-INF is IMO ugly. Would it make sense to ban specs prefixed by /WEB-INF?
> Tapestry may, in some cases, look for a page class in the wrong package
> -----------------------------------------------------------------------
>
> Key: TAPESTRY-724
> URL: http://issues.apache.org/jira/browse/TAPESTRY-724
> Project: Tapestry
> Type: Bug
> Components: Framework
> Versions: 4.0
> Reporter: Geoff Longman
> Priority: Critical
> Attachments: test.zip
>
> I've been trying to come up with a patch but work has been getting crazy and I have been ill for days now.
> A detailed description of the problem (and apossible solution) is to be found here:
> http://wiki.apache.org/jakarta-tapestry/GeoffLongmanSandbox
> In a nutshell, if a user references a Tapestry page whose class must be found from a given list of packages it may be the case that way they have referenced (by name) may mislead the ComponentClassProvider to look in the wrong package. If that happens, the class is not found and (in most cases) BasePage is assigned as the page class. Often this will break the application if the page depends on a class other than BasePage. Depending on how the app is set up there could be 3 or more legal ways to reference a page by name (path parts) but only one way will result in the right page class being located.
--
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: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
[jira] Commented: (TAPESTRY-724) Tapestry may, in some cases, look for a page class in the wrong package
Posted by "Geoff Longman (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-724?page=comments#action_12359080 ]
Geoff Longman commented on TAPESTRY-724:
----------------------------------------
Again, thx for the response. I will comment on the comment this evening.
> Tapestry may, in some cases, look for a page class in the wrong package
> -----------------------------------------------------------------------
>
> Key: TAPESTRY-724
> URL: http://issues.apache.org/jira/browse/TAPESTRY-724
> Project: Tapestry
> Type: Bug
> Components: Framework
> Versions: 4.0
> Reporter: Geoff Longman
> Assignee: Howard M. Lewis Ship
> Priority: Critical
> Attachments: test.zip
>
> I've been trying to come up with a patch but work has been getting crazy and I have been ill for days now.
> A detailed description of the problem (and apossible solution) is to be found here:
> http://wiki.apache.org/jakarta-tapestry/GeoffLongmanSandbox
> In a nutshell, if a user references a Tapestry page whose class must be found from a given list of packages it may be the case that way they have referenced (by name) may mislead the ComponentClassProvider to look in the wrong package. If that happens, the class is not found and (in most cases) BasePage is assigned as the page class. Often this will break the application if the page depends on a class other than BasePage. Depending on how the app is set up there could be 3 or more legal ways to reference a page by name (path parts) but only one way will result in the right page class being located.
--
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: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
[jira] Commented: (TAPESTRY-724) Tapestry may, in some cases, look for a page class in the wrong package
Posted by "Geoff Longman (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-724?page=comments#action_12356003 ]
Geoff Longman commented on TAPESTRY-724:
----------------------------------------
I'm looking for comment/reaction. I'm going on 5 days floored by the flu and will not be looking at the solution, if indeed a solution is at all desired, before next week.
> Tapestry may, in some cases, look for a page class in the wrong package
> -----------------------------------------------------------------------
>
> Key: TAPESTRY-724
> URL: http://issues.apache.org/jira/browse/TAPESTRY-724
> Project: Tapestry
> Type: Bug
> Components: Framework
> Versions: 4.0
> Reporter: Geoff Longman
> Priority: Critical
> Attachments: test.zip
>
> I've been trying to come up with a patch but work has been getting crazy and I have been ill for days now.
> A detailed description of the problem (and apossible solution) is to be found here:
> http://wiki.apache.org/jakarta-tapestry/GeoffLongmanSandbox
> In a nutshell, if a user references a Tapestry page whose class must be found from a given list of packages it may be the case that way they have referenced (by name) may mislead the ComponentClassProvider to look in the wrong package. If that happens, the class is not found and (in most cases) BasePage is assigned as the page class. Often this will break the application if the page depends on a class other than BasePage. Depending on how the app is set up there could be 3 or more legal ways to reference a page by name (path parts) but only one way will result in the right page class being located.
--
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: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
[jira] Commented: (TAPESTRY-724) Tapestry may, in some cases, look for a page class in the wrong package
Posted by "Howard M. Lewis Ship (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-724?page=comments#action_12357335 ]
Howard M. Lewis Ship commented on TAPESTRY-724:
-----------------------------------------------
Beginning to look over the wiki entry. First off, I don't think I ever intended <a jwcid="@PageLink" page="/WEB-INF/MyPage"/>
The rest of this bug is about dealing with ambiguities caused by the page name not matching the name of the specification file. This *is* why I am striving to eliminate the page spec, or (more specifically) to map as directly as possible from the page name to the page class, and find the page specification (if any) from there. This is an inversion of today, where the page name must be resolved to a page specification, but we also want to resolve it to a class name, without having to explicitly list it in the page spec.
But I'll continue looking this over.
> Tapestry may, in some cases, look for a page class in the wrong package
> -----------------------------------------------------------------------
>
> Key: TAPESTRY-724
> URL: http://issues.apache.org/jira/browse/TAPESTRY-724
> Project: Tapestry
> Type: Bug
> Components: Framework
> Versions: 4.0
> Reporter: Geoff Longman
> Assignee: Howard M. Lewis Ship
> Priority: Critical
> Attachments: test.zip
>
> I've been trying to come up with a patch but work has been getting crazy and I have been ill for days now.
> A detailed description of the problem (and apossible solution) is to be found here:
> http://wiki.apache.org/jakarta-tapestry/GeoffLongmanSandbox
> In a nutshell, if a user references a Tapestry page whose class must be found from a given list of packages it may be the case that way they have referenced (by name) may mislead the ComponentClassProvider to look in the wrong package. If that happens, the class is not found and (in most cases) BasePage is assigned as the page class. Often this will break the application if the page depends on a class other than BasePage. Depending on how the app is set up there could be 3 or more legal ways to reference a page by name (path parts) but only one way will result in the right page class being located.
--
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: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
[jira] Commented: (TAPESTRY-724) Tapestry may, in some cases, look for a page class in the wrong package
Posted by "Howard M. Lewis Ship (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-724?page=comments#action_12356334 ]
Howard M. Lewis Ship commented on TAPESTRY-724:
-----------------------------------------------
Geoff,
Try to calm down; just because I haven't commented doesn't mean it isn't important. My time to work on Tapestry is very fractured right now and this problem needs some serious study.
> Tapestry may, in some cases, look for a page class in the wrong package
> -----------------------------------------------------------------------
>
> Key: TAPESTRY-724
> URL: http://issues.apache.org/jira/browse/TAPESTRY-724
> Project: Tapestry
> Type: Bug
> Components: Framework
> Versions: 4.0
> Reporter: Geoff Longman
> Assignee: Howard M. Lewis Ship
> Priority: Critical
> Attachments: test.zip
>
> I've been trying to come up with a patch but work has been getting crazy and I have been ill for days now.
> A detailed description of the problem (and apossible solution) is to be found here:
> http://wiki.apache.org/jakarta-tapestry/GeoffLongmanSandbox
> In a nutshell, if a user references a Tapestry page whose class must be found from a given list of packages it may be the case that way they have referenced (by name) may mislead the ComponentClassProvider to look in the wrong package. If that happens, the class is not found and (in most cases) BasePage is assigned as the page class. Often this will break the application if the page depends on a class other than BasePage. Depending on how the app is set up there could be 3 or more legal ways to reference a page by name (path parts) but only one way will result in the right page class being located.
--
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: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
[jira] Commented: (TAPESTRY-724) Tapestry may, in some cases, look for a page class in the wrong package
Posted by "Geoff Longman (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-724?page=comments#action_12359180 ]
Geoff Longman commented on TAPESTRY-724:
----------------------------------------
I take it from this:
Modified: jakarta/tapestry/trunk/status.xml
URL: http://svn.apache.org/viewcvs/jakarta/tapestry/trunk/status.xml?rev=351507&r1=351506&r2=351507&view=diff
==============================================================================
--- jakarta/tapestry/trunk/status.xml (original)
+++ jakarta/tapestry/trunk/status.xml Thu Dec 1 14:29:33 2005
@@ -82,6 +82,8 @@
ListenerMapSource.createListenerMethodInvoker()</action>
<action type="fix" dev="HLS" fixes-bug="TAPESTRY-387" due-to="Kevin J. Menard, Jr.">Typographical Errors in
Documentation</action>
+ <action type="fix" dev="HLS" fixes-bug="TAPESTRY-724">Tapestry may, in some cases, look for a page class in the wrong package</action>
...that you consider the issue fixed?
Pls close this issue as I obviously have nothing more to contribute.
The handling of this issue leaves a very bad taste in my mouth. A bad taste that may linger for a while.
> Tapestry may, in some cases, look for a page class in the wrong package
> -----------------------------------------------------------------------
>
> Key: TAPESTRY-724
> URL: http://issues.apache.org/jira/browse/TAPESTRY-724
> Project: Tapestry
> Type: Bug
> Components: Framework
> Versions: 4.0
> Reporter: Geoff Longman
> Assignee: Howard M. Lewis Ship
> Priority: Critical
> Attachments: test.zip
>
> I've been trying to come up with a patch but work has been getting crazy and I have been ill for days now.
> A detailed description of the problem (and apossible solution) is to be found here:
> http://wiki.apache.org/jakarta-tapestry/GeoffLongmanSandbox
> In a nutshell, if a user references a Tapestry page whose class must be found from a given list of packages it may be the case that way they have referenced (by name) may mislead the ComponentClassProvider to look in the wrong package. If that happens, the class is not found and (in most cases) BasePage is assigned as the page class. Often this will break the application if the page depends on a class other than BasePage. Depending on how the app is set up there could be 3 or more legal ways to reference a page by name (path parts) but only one way will result in the right page class being located.
--
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: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org