Bug 647501 - RHQ SortableColumnHeaderRenderer should not extend com.sun....CommandLinkRendere
Summary: RHQ SortableColumnHeaderRenderer should not extend com.sun....CommandLinkRendere
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: RHQ Project
Classification: Other
Component: Core UI
Version: 3.0.0
Hardware: Unspecified
OS: Unspecified
low
medium
Target Milestone: ---
: ---
Assignee: Ian Springer
QA Contact: Mike Foley
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-10-28 15:16 UTC by Brad Maxwell
Modified: 2013-08-06 00:38 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2012-07-06 23:11:18 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker EMBJOPR-346 0 Major Closed ClassNotFound com.sun.faces.renderkit.html_basic.CommandLinkRenderer 2012-08-01 14:27:32 UTC

Description Brad Maxwell 2010-10-28 15:16:44 UTC
Description of problem:

The org.rhq.core.gui.table.renderer.SortableColumnHeaderRenderer is extending com.sun.faces.renderkit.html_basic.CommandLinkRenderer;

Because of this it is dependant on the Sun JSF Implementation, meaning it cannot run on Myfaces or other JSF implementations.

http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=blob;f=modules/core/gui/src/main/java/org/rhq/core/gui/table/renderer/SortableColumnHeaderRenderer.java;h=1f80312c6946a8abd06f40dd83ca8f835594f4f0;hb=HEAD

The rhq code should delegate to a JSF renderer if it needs to call its functionality instead of extending it.  I can't find exact article I was looking for, but [1] talks a little bit about it.

[1] http://java.sun.com/developer/technicalArticles/J2EE/jsf_renderers/

The fix would be to get the renderer for (family=javax.faces.Command, rendererType=javax.faces.Link).  Then invoke it. 

If you need most of the particular renderers functionality, you could create a Base class that extends javax.faces.render.Renderer, have it take in the family and rendererType.  Then implement all of the Renderer methods and inside the methods have them call getRenderer(family,renderType) and invoke the method.  Such as the example below: 

public ExtendJSFRenderer extends javax.faces.render.Renderer
{
 public ExtendJSFRenderer(String family, String rendererType)
 {
  this.family = family;
  this.rendererType = rendererType;
 }

protected Renderer getRenderer ()
{
    FacesContext context = FacesContext.getCurrentInstance ();
    return getRenderer ( context );
}

protected Renderer getRenderer ( FacesContext context )
{
    return context.getRenderKit().getRenderer ( this.family, this.rendererType );
}
public void decode ( FacesContext context, UIComponent component )
{
    getRenderer ( context ).decode ( context, component );
}
public boolean getRendersChildren ()
{
 return getRenderer ().getRendersChildren ();
}
...
}


If you created this base class ExtendJSFRenderer, then the only change to the rhq code would be 

public SortableColumnHeaderRenderer()
{
  super ( "javax.faces.Command", "javax.faces.Link" );
}



How reproducible:


Steps to Reproduce:
1.  Remove the Sun JSF implementation and put the MyFaces Implementation in and it will get a ClassNotFound. 

  
Actual results:
ClassNotFound com.sun.faces.renderkit.html_basic.CommandLinkRenderer;

Expected results:
No ClassNotFound

Comment 1 Ian Springer 2012-06-18 15:47:55 UTC
The usage of com.sun.faces.renderkit.html_basic.CommandLinkRenderer in org.rhq.core.gui.table.renderer.SortableColumnHeaderRenderer is not the only usage of Sun JSF RI classes in RHQ. There is also the following:

1) two usages of com.sun.faces.renderkit.RenderKitUtils in org.rhq.core.gui.table.renderer.AbstractButtonRenderer

2) several usages of com.sun.faces.util.MessageUtils in org.rhq.core.gui.table.renderer.AbstractRenderer

In order to remove the dependency on the Sun JSF RI, these usages would need to be refactored as well. This is a considerable amount of work, and, in my opinion, not worth the effort.

Comment 2 Larry O'Leary 2012-07-06 23:11:18 UTC
The Seam documentation provided with EAP 5 indicates that Sun JSF is recommended[1]. As such, and based on comment 1 along with the replacement of admin-console in EAP 6 and the replacement of JSF in JON 3.0, I am closing this BZ as WONTFIX. If there is a supportability change by the downstream EAP product, please feel free to provide the complete details via an RFE for EAP/Embedded JOPR for a complete Product/Program Management review.




[1]: http://docs.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/5/html/Seam_Reference_Guide/Migration.html#Migration12.JSF12

Comment 3 JBoss JIRA Server 2012-07-06 23:14:42 UTC
Larry O'Leary <loleary> updated the status of jira EMBJOPR-346 to Closed

Comment 4 JBoss JIRA Server 2012-07-06 23:14:42 UTC
Larry O'Leary <loleary> made a comment on jira EMBJOPR-346

Upstream https://bugzilla.redhat.com/show_bug.cgi?id=647501 has been closed as WONTFIX due to the complexity of the fix combined with the limited use and deprecation of Embedded JOPR as admin-console for EAP 5 and the replacement of JSF in the upstream RHQ project.


Note You need to log in before you can comment on or make changes to this bug.