Tapestry
  1. Tapestry
  2. TAPESTRY-894

SpecificationResolverDelegate not consulted if component class found first

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 4.0
    • Fix Version/s: 4.1.1
    • Component/s: Framework
    • Labels:
      None

      Description

      I am attempting to put my components under WEB-INF/component. I used the example from the wiki: http://wiki.apache.org/jakarta-tapestry/PagesAndComponentsInWEB-INF.

      My component's .jwc file is not found. Tracing through the code I see that in ComponentSpecificationResolverImpl.searchForComponent(IRequestCycle), if the .jwc file is not found in the usual locations, a search is done for the class. If the class is found, it is assumed the .jwc must be in WEB-INF and the configured SpecificationResolverDelegate is never consulted.

      This does not seem correct. Shouldn't all efforts to locate the .jwc be exhausted before searching for the class?

        Activity

        Hide
        Jesse Kuhnert added a comment -

        Applied changes. As far as I can tell if there are any performance concerns with this new order of calls they will only affect people with caching disabled, so production will remain pristine and as fast as it currently is.

        Show
        Jesse Kuhnert added a comment - Applied changes. As far as I can tell if there are any performance concerns with this new order of calls they will only affect people with caching disabled, so production will remain pristine and as fast as it currently is.
        Hide
        Andreas Andreou added a comment -

        I'd go with keeping the current behavior as is
        and making searchForComponent, searchForComponentClass protected and adding
        a protected getter for _classFinder (in ComponentSpecificationResolverImpl)

        Show
        Andreas Andreou added a comment - I'd go with keeping the current behavior as is and making searchForComponent, searchForComponentClass protected and adding a protected getter for _classFinder (in ComponentSpecificationResolverImpl)
        Hide
        Martin Strand added a comment -

        Any progress on this? It looks like a quick fix - just switch the search order in searchForComponent()...
        Or, make searchForComponent protected so we can subclass ComponentSpecificationResolverImpl easily and override this behaviour.

        Show
        Martin Strand added a comment - Any progress on this? It looks like a quick fix - just switch the search order in searchForComponent()... Or, make searchForComponent protected so we can subclass ComponentSpecificationResolverImpl easily and override this behaviour.
        Hide
        Filip S. Adamsen added a comment -

        Okay, so I changed ComponentSpecificationResolverImpl.searchForComponent(IRequestCycle) to consult the delegate before searching for a class - and everything seems to work...

        Show
        Filip S. Adamsen added a comment - Okay, so I changed ComponentSpecificationResolverImpl.searchForComponent(IRequestCycle) to consult the delegate before searching for a class - and everything seems to work...
        Hide
        Filip S. Adamsen added a comment -

        I'd say this behaviour is counter-intuitive.

        The .jwc file might as well be where the class is - why would you assume it to be in WEB-INF?

        Perhaps there should be a component-spec-path configuration option? Or the SpecificationResolverDelegate could be consulted before assuming where the spec file is.

        I'll look into this later and see if I can fix this.

        Show
        Filip S. Adamsen added a comment - I'd say this behaviour is counter-intuitive. The .jwc file might as well be where the class is - why would you assume it to be in WEB-INF? Perhaps there should be a component-spec-path configuration option? Or the SpecificationResolverDelegate could be consulted before assuming where the spec file is. I'll look into this later and see if I can fix this.

          People

          • Assignee:
            Jesse Kuhnert
            Reporter:
            Mark Reynolds
          • Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development