You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Stan Silvert (JIRA)" <in...@incubator.apache.org> on 2005/02/04 17:28:56 UTC
[jira] Created: (MYFACES-101) Inefficient portlet dependency fix
Inefficient portlet dependency fix
----------------------------------
Key: MYFACES-101
URL: http://issues.apache.org/jira/browse/MYFACES-101
Project: MyFaces
Type: Improvement
Versions: Nightly Build
Reporter: Stan Silvert
Priority: Minor
The Portlet Integration Framework created a dependency on the portlet jar. Shortly after the code was integrated, someone removed the dependency by catching and ignoring the NoClassDefFoundError that results if you don't have the portlet jar in your classpath.
While it is good that we remove the dependency for JSF applications that are not running in a portal, the current fix is very inefficient because it causes multiple exceptions to be thrown, caught, and ignored with virtually every request.
Example of current fix:
try{
if (externalContext.getRequest() instanceof PortletRequest) {
externalContext.dispatch(viewId);
return;
}
}catch(NoClassDefFoundError exception){
// Portlet api jar isn't in the classpath.
}
What is needed is a better way to determine if the request is coming from a portlet. The solution must not rely on the Portlet API and also must never generate exceptions.
My proposed soultion is to put a flag in the portlet session. The flag will be set in the MyFacesGenericPortlet. So the new code will look something like this instead:
if (externalContext.getSessionMap().get(MyFacesGenericPortlet.PORTLET_REQUEST_FLAG) != null)
if (externalContext.getRequest() instanceof PortletRequest) {
externalContext.dispatch(viewId);
return;
}
}
What would be even better is a solution that factors out the if statements and solves the problem using polymorphism. However, that would incur a major refactoring of many components. At some point this major refactoring should be done so that MyFaces could support requests that come from a third source (Servlet, Portlet, and something else). But I do not recommend the refactoring at this time. For now, the instances where MyFaces needs to check for a portlet request or response is confined to two source files. It is manageable.
I'll leave this out for comment for a few days before submitting a patch.
--
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
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Updated: (MYFACES-101) Inefficient portlet dependency fix
Posted by "Stan Silvert (JIRA)" <in...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-101?page=history ]
Stan Silvert updated MYFACES-101:
---------------------------------
Attachment: patch.txt
> Inefficient portlet dependency fix
> ----------------------------------
>
> Key: MYFACES-101
> URL: http://issues.apache.org/jira/browse/MYFACES-101
> Project: MyFaces
> Type: Improvement
> Versions: Nightly Build
> Reporter: Stan Silvert
> Assignee: Stan Silvert
> Priority: Minor
> Attachments: PortletUtil.java, patch.txt, portletpatch.diff
>
> The Portlet Integration Framework created a dependency on the portlet jar. Shortly after the code was integrated, someone removed the dependency by catching and ignoring the NoClassDefFoundError that results if you don't have the portlet jar in your classpath.
> While it is good that we remove the dependency for JSF applications that are not running in a portal, the current fix is very inefficient because it causes multiple exceptions to be thrown, caught, and ignored with virtually every request.
> Example of current fix:
> try{
> if (externalContext.getRequest() instanceof PortletRequest) {
> externalContext.dispatch(viewId);
> return;
> }
> }catch(NoClassDefFoundError exception){
> // Portlet api jar isn't in the classpath.
> }
> What is needed is a better way to determine if the request is coming from a portlet. The solution must not rely on the Portlet API and also must never generate exceptions.
> My proposed soultion is to put a flag in the portlet session. The flag will be set in the MyFacesGenericPortlet. So the new code will look something like this instead:
> if (externalContext.getSessionMap().get(MyFacesGenericPortlet.PORTLET_REQUEST_FLAG) != null)
> if (externalContext.getRequest() instanceof PortletRequest) {
> externalContext.dispatch(viewId);
> return;
> }
> }
> What would be even better is a solution that factors out the if statements and solves the problem using polymorphism. However, that would incur a major refactoring of many components. At some point this major refactoring should be done so that MyFaces could support requests that come from a third source (Servlet, Portlet, and something else). But I do not recommend the refactoring at this time. For now, the instances where MyFaces needs to check for a portlet request or response is confined to two source files. It is manageable.
> I'll leave this out for comment for a few days before submitting a patch.
--
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
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Reopened: (MYFACES-101) Inefficient portlet dependency fix
Posted by "Stan Silvert (JIRA)" <in...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-101?page=history ]
Stan Silvert reopened MYFACES-101:
----------------------------------
Assign To: Stan Silvert (was: Matthias Weßendorf)
Reopened. There was still a problem with this in an environment where the portlet API was not available. PortletUtil was using a static final member variable from MyFacesGenericPortlet. This would cause a rather strange ClassNotFoundException: org/apache/myfaces/portlet/MyFacesGenericPortlet. While the MyFacesGenericPortlet class would be available, its parent class GenericPortlet would not be.
Someone had come along and put try/catch blocks around the methods in PortletUtil to mask the problem.
To fix this properly, I am moving the member variable from MyFacesGenericPortlet to PortletUtil.
> Inefficient portlet dependency fix
> ----------------------------------
>
> Key: MYFACES-101
> URL: http://issues.apache.org/jira/browse/MYFACES-101
> Project: MyFaces
> Type: Improvement
> Versions: Nightly Build
> Reporter: Stan Silvert
> Assignee: Stan Silvert
> Priority: Minor
> Attachments: PortletUtil.java, portletpatch.diff
>
> The Portlet Integration Framework created a dependency on the portlet jar. Shortly after the code was integrated, someone removed the dependency by catching and ignoring the NoClassDefFoundError that results if you don't have the portlet jar in your classpath.
> While it is good that we remove the dependency for JSF applications that are not running in a portal, the current fix is very inefficient because it causes multiple exceptions to be thrown, caught, and ignored with virtually every request.
> Example of current fix:
> try{
> if (externalContext.getRequest() instanceof PortletRequest) {
> externalContext.dispatch(viewId);
> return;
> }
> }catch(NoClassDefFoundError exception){
> // Portlet api jar isn't in the classpath.
> }
> What is needed is a better way to determine if the request is coming from a portlet. The solution must not rely on the Portlet API and also must never generate exceptions.
> My proposed soultion is to put a flag in the portlet session. The flag will be set in the MyFacesGenericPortlet. So the new code will look something like this instead:
> if (externalContext.getSessionMap().get(MyFacesGenericPortlet.PORTLET_REQUEST_FLAG) != null)
> if (externalContext.getRequest() instanceof PortletRequest) {
> externalContext.dispatch(viewId);
> return;
> }
> }
> What would be even better is a solution that factors out the if statements and solves the problem using polymorphism. However, that would incur a major refactoring of many components. At some point this major refactoring should be done so that MyFaces could support requests that come from a third source (Servlet, Portlet, and something else). But I do not recommend the refactoring at this time. For now, the instances where MyFaces needs to check for a portlet request or response is confined to two source files. It is manageable.
> I'll leave this out for comment for a few days before submitting a patch.
--
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
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Resolved: (MYFACES-101) Inefficient portlet dependency fix
Posted by "Stan Silvert (JIRA)" <my...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-101?page=history ]
Stan Silvert resolved MYFACES-101:
----------------------------------
Resolution: Fixed
Fix Version: 1.0.9 beta
> Inefficient portlet dependency fix
> ----------------------------------
>
> Key: MYFACES-101
> URL: http://issues.apache.org/jira/browse/MYFACES-101
> Project: MyFaces
> Type: Improvement
> Versions: Nightly Build
> Reporter: Stan Silvert
> Assignee: Stan Silvert
> Priority: Minor
> Fix For: 1.0.9 beta
> Attachments: PortletUtil.java, patch.txt, portletpatch.diff
>
> The Portlet Integration Framework created a dependency on the portlet jar. Shortly after the code was integrated, someone removed the dependency by catching and ignoring the NoClassDefFoundError that results if you don't have the portlet jar in your classpath.
> While it is good that we remove the dependency for JSF applications that are not running in a portal, the current fix is very inefficient because it causes multiple exceptions to be thrown, caught, and ignored with virtually every request.
> Example of current fix:
> try{
> if (externalContext.getRequest() instanceof PortletRequest) {
> externalContext.dispatch(viewId);
> return;
> }
> }catch(NoClassDefFoundError exception){
> // Portlet api jar isn't in the classpath.
> }
> What is needed is a better way to determine if the request is coming from a portlet. The solution must not rely on the Portlet API and also must never generate exceptions.
> My proposed soultion is to put a flag in the portlet session. The flag will be set in the MyFacesGenericPortlet. So the new code will look something like this instead:
> if (externalContext.getSessionMap().get(MyFacesGenericPortlet.PORTLET_REQUEST_FLAG) != null)
> if (externalContext.getRequest() instanceof PortletRequest) {
> externalContext.dispatch(viewId);
> return;
> }
> }
> What would be even better is a solution that factors out the if statements and solves the problem using polymorphism. However, that would incur a major refactoring of many components. At some point this major refactoring should be done so that MyFaces could support requests that come from a third source (Servlet, Portlet, and something else). But I do not recommend the refactoring at this time. For now, the instances where MyFaces needs to check for a portlet request or response is confined to two source files. It is manageable.
> I'll leave this out for comment for a few days before submitting a patch.
--
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
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Updated: (MYFACES-101) Inefficient portlet dependency fix
Posted by "Stan Silvert (JIRA)" <in...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-101?page=history ]
Stan Silvert updated MYFACES-101:
---------------------------------
Attachment: portletpatch.diff
Implementation of fix for this issue.
> Inefficient portlet dependency fix
> ----------------------------------
>
> Key: MYFACES-101
> URL: http://issues.apache.org/jira/browse/MYFACES-101
> Project: MyFaces
> Type: Improvement
> Versions: Nightly Build
> Reporter: Stan Silvert
> Priority: Minor
> Attachments: PortletUtil.java, portletpatch.diff
>
> The Portlet Integration Framework created a dependency on the portlet jar. Shortly after the code was integrated, someone removed the dependency by catching and ignoring the NoClassDefFoundError that results if you don't have the portlet jar in your classpath.
> While it is good that we remove the dependency for JSF applications that are not running in a portal, the current fix is very inefficient because it causes multiple exceptions to be thrown, caught, and ignored with virtually every request.
> Example of current fix:
> try{
> if (externalContext.getRequest() instanceof PortletRequest) {
> externalContext.dispatch(viewId);
> return;
> }
> }catch(NoClassDefFoundError exception){
> // Portlet api jar isn't in the classpath.
> }
> What is needed is a better way to determine if the request is coming from a portlet. The solution must not rely on the Portlet API and also must never generate exceptions.
> My proposed soultion is to put a flag in the portlet session. The flag will be set in the MyFacesGenericPortlet. So the new code will look something like this instead:
> if (externalContext.getSessionMap().get(MyFacesGenericPortlet.PORTLET_REQUEST_FLAG) != null)
> if (externalContext.getRequest() instanceof PortletRequest) {
> externalContext.dispatch(viewId);
> return;
> }
> }
> What would be even better is a solution that factors out the if statements and solves the problem using polymorphism. However, that would incur a major refactoring of many components. At some point this major refactoring should be done so that MyFaces could support requests that come from a third source (Servlet, Portlet, and something else). But I do not recommend the refactoring at this time. For now, the instances where MyFaces needs to check for a portlet request or response is confined to two source files. It is manageable.
> I'll leave this out for comment for a few days before submitting a patch.
--
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
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Updated: (MYFACES-101) Inefficient portlet dependency fix
Posted by "Stan Silvert (JIRA)" <in...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-101?page=history ]
Stan Silvert updated MYFACES-101:
---------------------------------
Attachment: PortletUtil.java
Static utility class makes the impl cleaner.
> Inefficient portlet dependency fix
> ----------------------------------
>
> Key: MYFACES-101
> URL: http://issues.apache.org/jira/browse/MYFACES-101
> Project: MyFaces
> Type: Improvement
> Versions: Nightly Build
> Reporter: Stan Silvert
> Priority: Minor
> Attachments: PortletUtil.java, portletpatch.diff
>
> The Portlet Integration Framework created a dependency on the portlet jar. Shortly after the code was integrated, someone removed the dependency by catching and ignoring the NoClassDefFoundError that results if you don't have the portlet jar in your classpath.
> While it is good that we remove the dependency for JSF applications that are not running in a portal, the current fix is very inefficient because it causes multiple exceptions to be thrown, caught, and ignored with virtually every request.
> Example of current fix:
> try{
> if (externalContext.getRequest() instanceof PortletRequest) {
> externalContext.dispatch(viewId);
> return;
> }
> }catch(NoClassDefFoundError exception){
> // Portlet api jar isn't in the classpath.
> }
> What is needed is a better way to determine if the request is coming from a portlet. The solution must not rely on the Portlet API and also must never generate exceptions.
> My proposed soultion is to put a flag in the portlet session. The flag will be set in the MyFacesGenericPortlet. So the new code will look something like this instead:
> if (externalContext.getSessionMap().get(MyFacesGenericPortlet.PORTLET_REQUEST_FLAG) != null)
> if (externalContext.getRequest() instanceof PortletRequest) {
> externalContext.dispatch(viewId);
> return;
> }
> }
> What would be even better is a solution that factors out the if statements and solves the problem using polymorphism. However, that would incur a major refactoring of many components. At some point this major refactoring should be done so that MyFaces could support requests that come from a third source (Servlet, Portlet, and something else). But I do not recommend the refactoring at this time. For now, the instances where MyFaces needs to check for a portlet request or response is confined to two source files. It is manageable.
> I'll leave this out for comment for a few days before submitting a patch.
--
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
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira