Uploaded image for project: 'Tapestry'
  1. Tapestry
  2. TAPESTRY-894

SpecificationResolverDelegate not consulted if component class found first

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: 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
        fsa 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
        fsa 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.
        Hide
        fsa 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
        fsa 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
        ms 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
        ms 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
        andyhot 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
        andyhot 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
        jkuhnert 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
        jkuhnert 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.

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development