Return-Path: Delivered-To: apmail-myfaces-dev-archive@www.apache.org Received: (qmail 9822 invoked from network); 2 Aug 2010 19:57:42 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 2 Aug 2010 19:57:42 -0000 Received: (qmail 39113 invoked by uid 500); 2 Aug 2010 19:57:42 -0000 Delivered-To: apmail-myfaces-dev-archive@myfaces.apache.org Received: (qmail 39002 invoked by uid 500); 2 Aug 2010 19:57:41 -0000 Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "MyFaces Development" Delivered-To: mailing list dev@myfaces.apache.org Received: (qmail 38994 invoked by uid 99); 2 Aug 2010 19:57:41 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Aug 2010 19:57:41 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.22] (HELO thor.apache.org) (140.211.11.22) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Aug 2010 19:57:40 +0000 Received: from thor (localhost [127.0.0.1]) by thor.apache.org (8.13.8+Sun/8.13.8) with ESMTP id o72JvKSU004794 for ; Mon, 2 Aug 2010 19:57:20 GMT Message-ID: <16405510.123561280779040519.JavaMail.jira@thor> Date: Mon, 2 Aug 2010 15:57:20 -0400 (EDT) From: "Leonardo Uribe (JIRA)" To: dev@myfaces.apache.org Subject: [jira] Commented: (MYFACES-2628) Facelets ResourceSolver cant work In-Reply-To: <1264965790.539671269823887298.JavaMail.jira@brutus.apache.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/MYFACES-2628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12894678#action_12894678 ] Leonardo Uribe commented on MYFACES-2628: ----------------------------------------- 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. > Facelets ResourceSolver cant work > --------------------------------- > > Key: MYFACES-2628 > URL: https://issues.apache.org/jira/browse/MYFACES-2628 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314 > Affects Versions: 2.0.0-beta-3 > Environment: tomcat 6.0.20, java 1.6(mac osx), > Reporter: Mark Li > Original Estimate: 1h > Remaining Estimate: 1h > > 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. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.