Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.0-beta-3
    • Fix Version/s: 2.1.0
    • Component/s: JSR-314
    • Labels:
      None
    • Environment:
      tomcat 6.0.20, java 1.6(mac osx),

      Description

      In facelets 1.1.14, I can load page from classpath via ResourceSolver,
      by in myfaces 2.0.0-beta-3, I cant do this, because 'DefaultRestoreViewSupport.checkResourceExists' method check the resource exists using 'servletContext.getResource(path);', should do some delegate.

        Activity

        Hide
        Leonardo Uribe added a comment -

        Finally a fix for this one was included in JSF 2.1. See:

        http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-893

        for details.

        Show
        Leonardo Uribe added a comment - Finally a fix for this one was included in JSF 2.1. See: http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-893 for details.
        Hide
        Leonardo Uribe added a comment - - edited

        There is no reason to expose it, but note ResourceResolver is part of the current api, and there is a web config param:

        javax.faces.FACELETS_RESOURCE_RESOLVER

        used to override it. This class is used by the vdl to retrieve facelet xhtml files and construct Facelet instances (in this case DefaultFacelet instances). My first idea looking this stuff is why there is a param for create an instance to an object that I can't retrieve from the place it could be useful?

        Thinking more about it the problem is the vdl should be responsible to indicate if the viewId is valid or not, on in other words, if there is a source file that can generate a view with the viewId identifier. In jsp case it just should try to locate a .jsp file with the same name, in facelets case check this condition using the ResourceResolver instance (in the default case it does the same a jsp case but for xhtml files). Note FaceletViewDeclarationLanguage.createFaceletFactory creates an instance of ResourceResolver and pass it to DefaultFaceletFactory. Maybe we should send an email to jsr-314-open, so this could be included in jsf 2.1.

        To solve this issue maybe we can hold a duplicate instance to ResourceResolver, one on facelets vdl (specifically on the factory) and the other one on RestoreViewSupport instance. After all, this class is expected to be stateless, so it will be no problem.

        Suggestions are welcome.

        Show
        Leonardo Uribe added a comment - - edited There is no reason to expose it, but note ResourceResolver is part of the current api, and there is a web config param: javax.faces.FACELETS_RESOURCE_RESOLVER used to override it. This class is used by the vdl to retrieve facelet xhtml files and construct Facelet instances (in this case DefaultFacelet instances). My first idea looking this stuff is why there is a param for create an instance to an object that I can't retrieve from the place it could be useful? Thinking more about it the problem is the vdl should be responsible to indicate if the viewId is valid or not, on in other words, if there is a source file that can generate a view with the viewId identifier. In jsp case it just should try to locate a .jsp file with the same name, in facelets case check this condition using the ResourceResolver instance (in the default case it does the same a jsp case but for xhtml files). Note FaceletViewDeclarationLanguage.createFaceletFactory creates an instance of ResourceResolver and pass it to DefaultFaceletFactory. Maybe we should send an email to jsr-314-open, so this could be included in jsf 2.1. To solve this issue maybe we can hold a duplicate instance to ResourceResolver, one on facelets vdl (specifically on the factory) and the other one on RestoreViewSupport instance. After all, this class is expected to be stateless, so it will be no problem. Suggestions are welcome.
        Hide
        Bernd Bohmann added a comment -

        Independent of the suffix mapping problem, why we need a standard way to expose the current ResourceResolver instance?

        Show
        Bernd Bohmann added a comment - Independent of the suffix mapping problem, why we need a standard way to expose the current ResourceResolver instance?
        Hide
        Leonardo Uribe added a comment -

        Because to resolve suffix mapping when the view is resolved it is necessary to check if the resource exists or not. If a request receive something like /mypage.jsf, it is necessary to check if the resource is /myfaces.xhtml or /myfaces.jsp or /myfaces.jspx, and this is done checking if the resource file exists or not. Right now, if someone overrides the ResourceResolver, the current algorithm continues looking for the resources on the same locations, ignoring ResourceResolver interface.

        Maybe we can use ResourceResolver.resolveUrl for this, if it returns null the resource does not exists otherwise it exists, but there is no standard way to expose the current ResourceResolver instance.

        Show
        Leonardo Uribe added a comment - Because to resolve suffix mapping when the view is resolved it is necessary to check if the resource exists or not. If a request receive something like /mypage.jsf, it is necessary to check if the resource is /myfaces.xhtml or /myfaces.jsp or /myfaces.jspx, and this is done checking if the resource file exists or not. Right now, if someone overrides the ResourceResolver, the current algorithm continues looking for the resources on the same locations, ignoring ResourceResolver interface. Maybe we can use ResourceResolver.resolveUrl for this, if it returns null the resource does not exists otherwise it exists, but there is no standard way to expose the current ResourceResolver instance.
        Hide
        Bernd Bohmann added a comment -

        @Leonardo
        Why we need a standard way to get the current ResourceResolver?

        Show
        Bernd Bohmann added a comment - @Leonardo Why we need a standard way to get the current ResourceResolver?
        Hide
        Mark Li added a comment -

        ok, thx

        Show
        Mark Li added a comment - ok, thx
        Hide
        Leonardo Uribe added a comment -

        I check this one and the conclusion was this one is a problem related to the spec. There is no standard way to get the current ResourceResolver instaces, but the is way to override it. We have to report this one to jsr-314-open mailing list.

        Show
        Leonardo Uribe added a comment - I check this one and the conclusion was this one is a problem related to the spec. There is no standard way to get the current ResourceResolver instaces, but the is way to override it. We have to report this one to jsr-314-open mailing list.
        Hide
        Mark Li added a comment -

        this is my suggestion:

        orginal:
        public final class ServletExternalContextImpl extends ExternalContext implements ReleaseableExternalContext
        {
        .....

        @Override
        public URL getResource(final String path) throws MalformedURLException

        { checkNull(path, "path"); return _servletContext.getResource(path); }

        }

        to
        public final class ServletExternalContextImpl extends ExternalContext implements ReleaseableExternalContext
        {
        .....

        @Override
        public URL getResource(final String path) throws MalformedURLException

        { checkNull(path, "path"); FaceletsResolver resolver = ....; URL url = resolver.resolveUrl(path); return url; }

        }

        Of cource, the DefaultFaceletsResolver class should not use context.getExternalContext().getResource(url) any more.

        Show
        Mark Li added a comment - this is my suggestion: orginal: public final class ServletExternalContextImpl extends ExternalContext implements ReleaseableExternalContext { ..... @Override public URL getResource(final String path) throws MalformedURLException { checkNull(path, "path"); return _servletContext.getResource(path); } } to public final class ServletExternalContextImpl extends ExternalContext implements ReleaseableExternalContext { ..... @Override public URL getResource(final String path) throws MalformedURLException { checkNull(path, "path"); FaceletsResolver resolver = ....; URL url = resolver.resolveUrl(path); return url; } } Of cource, the DefaultFaceletsResolver class should not use context.getExternalContext().getResource(url) any more.
        Hide
        Mark Li added a comment -

        I also find DefaultViewHandlerSupport.checkResourceExists has the same problem, after change these two method, facelets ResourceSolver can work properly.

        Show
        Mark Li added a comment - I also find DefaultViewHandlerSupport.checkResourceExists has the same problem, after change these two method, facelets ResourceSolver can work properly.

          People

          • Assignee:
            Leonardo Uribe
            Reporter:
            Mark Li
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 1h
              1h
              Remaining:
              Remaining Estimate - 1h
              1h
              Logged:
              Time Spent - Not Specified
              Not Specified

                Development