[JAVASERVERFACES_SPEC_PUBLIC-868] Drop support for CURRENT_COMPONENT CURRENT_COMPOSITE_COMPONENT in FacesContext attrs map Created: 19/Jul/10  Updated: 01/Aug/14  Resolved: 19/Oct/10

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: 2.0
Fix Version/s: 2.1

Type: Bug Priority: Major
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File changebundle.txt     Text File i868.patch     Text File i868.patch     Text File i868.patch    
Issuezilla Id: 868
Status Whiteboard:

size_medium importance_large

Tags: adf, adf_medium, changelog_2_1

 Description   

The JSF specification contains the following:

/**

  • <p class="changed_added_2_0">The key to which the
  • <code>UIComponent</code> currently being processed will be
  • associated with within the {@link FacesContext} attributes map.</p>
    *
    * @see javax.faces.context.FacesContext#getAttributes()
    *
    * @since 2.0
    */
    public static final String CURRENT_COMPONENT =
    "javax.faces.component.CURRENT_COMPONENT";

    /**
    * <p class="changed_added_2_0">The key to which the
    * <em>composite</em> <code>UIComponent</code> currently being
    * processed will be associated with within the {@link FacesContext}
  • attributes map.</p>
    *
  • @see javax.faces.context.FacesContext#getAttributes()
    *
  • @since 2.0
    */
    public static final String CURRENT_COMPOSITE_COMPONENT =
    "javax.faces.component.CURRENT_COMPOSITE_COMPONENT";

The guarantee that the current and current composite components are
available through FacesContext.getAttributes() doesn't seem right for
several reasons:
1) It isn't useful. The static methods
UIComponent.getCurrentComponent() and
UIComponent.getCurrentCompositeComponent() are more convenient and typesafe.
2) It is dangerous. If the values of these attributes is set, the
current stack will be messed up
3) When we aren't using the particular space-inefficient implementation
the JSF RI currently uses, maintaining these attributes just in case a
developer tries to request them is a waste



 Comments   
Comment by Ed Burns [ 19/Jul/10 ]

M4

This was filed as https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1623

Comment by Ed Burns [ 10/Aug/10 ]

Created an attachment (id=264)
Fix for this bug, first iteration

Comment by Ed Burns [ 11/Aug/10 ]

Fix checked in Committed revision 8549.

Comment by Ed Burns [ 13/Sep/10 ]

add changelog_2_1 keyword

Comment by Ed Burns [ 20/Sep/10 ]

Ensure changelog_2_1 is in keywords list

Comment by Ed Burns [ 19/Oct/10 ]

On a related note, it was discovered that invokeOnComponent did not do the requisit
pushComponentToEL(), popComponentFromEL().

Here is a patch to make that happen.

Comment by Ed Burns [ 19/Oct/10 ]

Created an attachment (id=309)
Fix for adding

{push,pop}

Component

{From,To}

EL()

Comment by Ed Burns [ 19/Oct/10 ]

Created an attachment (id=310)
Fix for the invokeOncomponent portion of this issue, second iteration

Comment by Ed Burns [ 19/Oct/10 ]

Created an attachment (id=311)
Fixed test failures.

Comment by Ed Burns [ 19/Oct/10 ]

Committed revision 8675.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-810] Access to component ancestor chain during Facelets handler processing Created: 25/May/10  Updated: 12/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: 2.0
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: aschwart Assignee: Unassigned
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 810
Status Whiteboard:

size_large importance_medium

Tags: adf

 Description   

We have various JSP tag implementations that walk up the component ancestor chain during tag execution
for one reason or another. While porting these tags to Facelets, we have been forced to work around the
fact that Facelets does not connect the ancestor chain until after children have been processed.

While it may be too late to change Facelets behavior now, it would be helpful to provide access to the
ancestor chain through some API so that Facelets handlers can interact with parent/ancestor components.



 Comments   
Comment by Ed Burns [ 27/May/10 ]

2.1.

Comment by Ed Burns [ 01/Jun/10 ]

Add adf keyword

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

edburns

Comment by Ed Burns [ 24/Jun/10 ]

Change target milestone.

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.





[JAVASERVERFACES_SPEC_PUBLIC-809] Simplify external view loading requirements Created: 25/May/10  Updated: 01/Aug/14  Resolved: 09/Mar/12

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Navigation
Affects Version/s: 2.0
Fix Version/s: 2.2 Sprint 11 B

Type: Bug Priority: Major
Reporter: aschwart Assignee: Ed Burns
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 2 hours
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issue Links:
Dependency
depends on JAVASERVERFACES_SPEC_PUBLIC-719 Need method to map viewId to resource... Closed
Issuezilla Id: 809
Status Whiteboard:

size_large importance_medium

Tags: adf

 Description   

In Facelets 1.x, it was possible to implement load views from external locations (such as the class path,
or a repository) by providing a ResourceResolver implementation.

The ResourceResolver is also present in JSF 2, so this is still possible. However, there is a new
requirement. Implicit navigation calls ExternalContext.getResource() to determine whether a view id
corresponds to a physical resource. If ExternalContext.getResource() returns a non-null URL, implicit
navigation to the view id is allowed.

This contract is not ideal, as:

1. It is non-obvious.
2. It requires hooking into multiple locations.
3. It makes it difficult to distinguish between requests for view ids vs. other types of resources.

Regarding #3… ExternalContext.getResource() may be used for all sorts of resources. In our case we
only want to search our external repositories when a view id is requested, but not, say, when someone
calls getResource() to load some other type of file (eg. a style sheet).

We need to introduce a cleaner contract that simplifies the responsibilities for custom view loading
implementations.



 Comments   
Comment by Ed Burns [ 27/May/10 ]

2.1.

Comment by Ed Burns [ 01/Jun/10 ]

Add adf keyword

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by kito75 [ 19/Apr/11 ]

I think it'd make sense to unify the resource-handling mechanism with the ResourceResolver. This would solve a few issues:

(1) Provide the ability to load Facelet views from a JAR without writing a custom class.
(2) Provide a single entry point for customizing resource resolution and view resolution.
(3) Allow views (or sets of views) to be versioned and localized
(4) Lay the groundwork for application modules – a set of views, images, stylesheets, etc., inside of a JAR file.

Basically, all we'd need is to define a mapping between a URL and a view within a resource library. A sensible default with the ability to override it in faces-config.xml would suffice.

Comment by kito75 [ 20/Apr/11 ]

Related issues:

Make flows reusable http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-730
Support for modular, reusable, fragments of a web application http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-532
Plugin System http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-970

Comment by Ed Burns [ 24/Feb/12 ]

As evidence of the problem listed in the summary of the bug:

3. It makes it difficult to distinguish between requests for view ids vs. other types of resources.

Consider this ad hoc log output from getResource():

INFO: getResource: /index.xhtml
INFO: getResource: /resources/compositeTest/foo.xhtml
INFO: getResource: /resources/ezcomp/LoginProductName.png
INFO: getResource: /resources/ezcomp/add-rem_header.gif
INFO: getResource: /resources/ezcomp/alertbackground_bottom_left.gif
INFO: getResource: /resources/ezcomp/alertbackground_bottom_right.gif
INFO: getResource: /resources/ezcomp/alertbackground_middle.gif
INFO: getResource: /resources/ezcomp/alertbackground_top.gif
INFO: getResource: /resources/ezcomp/alertbackground_top_left.gif
INFO: getResource: /resources/ezcomp/alertbackground_top_right.gif
INFO: getResource: /resources/ezcomp/background_border_bottom.gif
INFO: getResource: /resources/ezcomp/bg_gradient.gif
INFO: getResource: /resources/ezcomp/bg_gradient_disabled.gif
INFO: getResource: /resources/ezcomp/bg_gradient_selected.gif
INFO: getResource: /resources/ezcomp/bkgrnd.gif
INFO: getResource: /resources/ezcomp/calpop_dropshadow.png
INFO: getResource: /resources/ezcomp/calpop_footer_grad.gif
INFO: getResource: /resources/ezcomp/colorAndMedia.css
INFO: getResource: /resources/ezcomp/column_hdr_gradient.gif
INFO: getResource: /resources/ezcomp/column_hdr_hov_gradient.gif
INFO: getResource: /resources/ezcomp/column_hdr_sort_gradient.gif
INFO: getResource: /resources/ezcomp/column_hdr_sort_hov_gradient.gif
INFO: getResource: /resources/ezcomp/commontaskssection.css
INFO: getResource: /resources/ezcomp/componentWithBackingJavaClass.groovy
INFO: getResource: /resources/ezcomp/componentWithBackingJavaClass.xhtml
INFO: getResource: /resources/ezcomp/css_master.css
INFO: getResource: /resources/ezcomp/css_ns6up.css
INFO: getResource: /resources/ezcomp/date_time_gradient.jpg
INFO: getResource: /resources/ezcomp/dot.gif
INFO: getResource: /resources/ezcomp/failed_small.gif
INFO: getResource: /resources/ezcomp/grad1.gif
INFO: getResource: /resources/ezcomp/grad2.gif
INFO: getResource: /resources/ezcomp/gradation-grey.gif
INFO: getResource: /resources/ezcomp/gradlogbot.jpg
INFO: getResource: /resources/ezcomp/gradlogsides.jpg
INFO: getResource: /resources/ezcomp/gradlogtop.jpg
INFO: getResource: /resources/ezcomp/gradtblhdr.gif
INFO: getResource: /resources/ezcomp/gradtblhdrsrt.gif
INFO: getResource: /resources/ezcomp/gradtblttl.jpg
INFO: getResource: /resources/ezcomp/grouprow_gradient.gif
INFO: getResource: /resources/ezcomp/header-short.gif
INFO: getResource: /resources/ezcomp/help_btnnav_gradient.jpg
INFO: getResource: /resources/ezcomp/indeterminate.gif
INFO: getResource: /resources/ezcomp/layout.css
INFO: getResource: /resources/ezcomp/left-pane-background.gif
INFO: getResource: /resources/ezcomp/leftBottom.gif
INFO: getResource: /resources/ezcomp/leftTop.gif
INFO: getResource: /resources/ezcomp/left_pane_grad.jpg
INFO: getResource: /resources/ezcomp/level1_background.jpg
INFO: getResource: /resources/ezcomp/level1_deselect.jpg
INFO: getResource: /resources/ezcomp/level1_selected-1lev.jpg
INFO: getResource: /resources/ezcomp/level1_selected-1lvl.jpg
INFO: getResource: /resources/ezcomp/level1_selected-left.jpg
INFO: getResource: /resources/ezcomp/level1_selected-middle.jpg
INFO: getResource: /resources/ezcomp/level1_selected-right.jpg
INFO: getResource: /resources/ezcomp/level1_selected.jpg
INFO: getResource: /resources/ezcomp/level2_background.jpg
INFO: getResource: /resources/ezcomp/level2_deselect.jpg
INFO: getResource: /resources/ezcomp/level2_selected-left.jpg
INFO: getResource: /resources/ezcomp/level2_selected-middle.jpg
INFO: getResource: /resources/ezcomp/level2_selected-right.jpg
INFO: getResource: /resources/ezcomp/level2_selected.gif
INFO: getResource: /resources/ezcomp/level2_selected.jpg
INFO: getResource: /resources/ezcomp/level3_background.gif
INFO: getResource: /resources/ezcomp/level3_deselect.jpg
INFO: getResource: /resources/ezcomp/level3_selected.jpg
INFO: getResource: /resources/ezcomp/lite_column_hdr_gradient.gif
INFO: getResource: /resources/ezcomp/lite_column_hdr_hov_gradient.gif
INFO: getResource: /resources/ezcomp/lite_column_hdr_sort_gradient.gif
INFO: getResource: /resources/ezcomp/lite_column_hdr_sort_hov_gradient.gif
INFO: getResource: /resources/ezcomp/login-backimage.jpg
INFO: getResource: /resources/ezcomp/loginPanel.groovy
INFO: getResource: /resources/ezcomp/loginPanel.properties
INFO: getResource: /resources/ezcomp/loginPanel.xhtml
INFO: getResource: /resources/ezcomp/masthead-background.jpg
INFO: getResource: /resources/ezcomp/masthead-sun-background.jpg
INFO: getResource: /resources/ezcomp/masthead_button.gif
INFO: getResource: /resources/ezcomp/masthead_button_over.gif
INFO: getResource: /resources/ezcomp/masthead_link_enabled.gif
INFO: getResource: /resources/ezcomp/masthead_link_roll.gif
INFO: getResource: /resources/ezcomp/minitab_background.jpg
INFO: getResource: /resources/ezcomp/minitab_deselect.jpg
INFO: getResource: /resources/ezcomp/minitab_selected.jpg
INFO: getResource: /resources/ezcomp/mult_column_hdr_sort_gradient.gif
INFO: getResource: /resources/ezcomp/primary-disabled.gif
INFO: getResource: /resources/ezcomp/primary-enabled.gif
INFO: getResource: /resources/ezcomp/primary-mini-enabled.gif
INFO: getResource: /resources/ezcomp/primary-mini-roll.gif
INFO: getResource: /resources/ezcomp/primary-roll.gif
INFO: getResource: /resources/ezcomp/progressBar.css
INFO: getResource: /resources/ezcomp/reg-slice.gif
INFO: getResource: /resources/ezcomp/rightBottom.gif
INFO: getResource: /resources/ezcomp/rightTop.gif
INFO: getResource: /resources/ezcomp/s-curve.gif
INFO: getResource: /resources/ezcomp/sec-masthead-background.jpg
INFO: getResource: /resources/ezcomp/secondary-disabled.gif
INFO: getResource: /resources/ezcomp/secondary-enabled.gif
INFO: getResource: /resources/ezcomp/secondary-mini-enabled.gif
INFO: getResource: /resources/ezcomp/secondary-mini-roll.gif
INFO: getResource: /resources/ezcomp/secondary-roll.gif
INFO: getResource: /resources/ezcomp/still-indeterminate.gif
INFO: getResource: /resources/ezcomp/table2.css
INFO: getResource: /resources/ezcomp/table_titlebar_gradient.gif
INFO: getResource: /resources/ezcomp/tipbackground.gif
INFO: getResource: /resources/ezcomp/typography.css
INFO: getResource: /resources/ezcomp/version_brand.jpg
INFO: getResource: /resources/ezcomp/wizbdy_minitab_background.jpg

Add to the above the use of ExternalContext.getResource() to determine the existence of a view for conditional navigation, and you have a good idea of all the places that need to be touched to accommodate this new API.

Comment by Ed Burns [ 24/Feb/12 ]

Callpaths to ExternalContext.getResource()

Usage1: During RestoreViewPhase when trying to load a page to get its
<f:metadata> section.

csf.context.ExternalContextImpl.getResource(ExternalContextImpl.java:527)
csf.fclts.util.Resource.getResourceUrl(Resource.java:106)
csf.fclts.impl.DefaultResourceResolver.resolveUrl(DefaultResourceResolver.java:77)
csf.fclts.impl.DefaultFaceletFactory.resolveURL(DefaultFaceletFactory.java:252)
csf.fclts.impl.DefaultFaceletFactory.resolveURL(DefaultFaceletFactory.java:295)
csf.fclts.impl.DefaultFaceletFactory.getMetadataFacelet(DefaultFaceletFactory.java:231)
csf.appl.view.ViewMetadataImpl.createMetadataView(ViewMetadataImpl.java:114)
csf.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:241)
csf.lifecycle.Phase.doPhase(Phase.java:101)
csf.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:122)
csf.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:158)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:640)

Usage2: When trying to render a button whose action uses conditional
navigation.

csf.context.ExternalContextImpl.getResource(ExternalContextImpl.java:527)
csf.fclts.util.Resource.getResourceUrl(Resource.java:106)
csf.fclts.impl.DefaultResourceResolver.resolveUrl(DefaultResourceResolver.java:77)
csf.appl.view.FaceletViewHandlingStrategy.viewExists(FaceletViewHandlingStrategy.java:799)
csf.appl.view.MultiViewHandler.derivePhysicalViewId(MultiViewHandler.java:564)
csf.appl.view.MultiViewHandler.deriveViewId(MultiViewHandler.java:451)
csf.appl.NavigationHandlerImpl.findImplicitMatch(NavigationHandlerImpl.java:557)
csf.appl.NavigationHandlerImpl.getViewId(NavigationHandlerImpl.java:309)
csf.appl.NavigationHandlerImpl.getNavigationCase(NavigationHandlerImpl.java:125)
csf.systest.implicitnav.ImplicitNavigationBean.getCurrentActionUrl(ImplicitNavigationBean.java:59)
sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
javax.el.BeanELResolver.getValue(BeanELResolver.java:363)
csf.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176)
csf.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203)
com.sun.el.parser.AstValue.getValue(AstValue.java:138)
com.sun.el.parser.AstValue.getValue(AstValue.java:183)
com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:224)
csf.fclts.el.TagValueExpression.getValue(TagValueExpression.java:109)
javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:194)
javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:182)
javax.faces.component.UIOutput.getValue(UIOutput.java:169)
csf.renderkit.html_basic.HtmlBasicInputRenderer.getValue(HtmlBasicInputRenderer.java:205)
csf.renderkit.html_basic.HtmlBasicRenderer.getCurrentValue(HtmlBasicRenderer.java:355)
csf.renderkit.html_basic.HtmlBasicRenderer.encodeEnd(HtmlBasicRenderer.java:164)
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:875)
javax.faces.component.UIComponent.encodeAll(UIComponent.java:1799)
javax.faces.render.Renderer.encodeChildren(Renderer.java:168)
javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:845)
javax.faces.component.UIComponent.encodeAll(UIComponent.java:1792)
javax.faces.component.UIComponent.encodeAll(UIComponent.java:1795)
javax.faces.component.UIComponent.encodeAll(UIComponent.java:1795)
csf.appl.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:402)
csf.appl.view.MultiViewHandler.renderView(MultiViewHandler.java:127)
csf.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:121)
csf.lifecycle.Phase.doPhase(Phase.java:101)
csf.lifecycle.LifecycleImpl.render(LifecycleImpl.java:179)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:641)

Usage3: When trying to get the viewId on an initial page request.

csf.context.ExternalContextImpl.getResource(ExternalContextImpl.java:528)
csf.fclts.util.Resource.getResourceUrl(Resource.java:106)
csf.fclts.impl.DefaultResourceResolver.resolveUrl(DefaultResourceResolver.java:77)
csf.appl.view.FaceletViewHandlingStrategy.viewExists(FaceletViewHandlingStrategy.java:799)
csf.appl.view.MultiViewHandler.convertViewId(MultiViewHandler.java:527)
csf.appl.view.MultiViewHandler.derivePhysicalViewId(MultiViewHandler.java:547)
csf.appl.view.MultiViewHandler.deriveLogicalViewId(MultiViewHandler.java:458)
csf.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:229)
csf.lifecycle.Phase.doPhase(Phase.java:101)
csf.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:122)
csf.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:158)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:640)

Usage4: When trying to serve up a resource request from the filesystem.

csf.context.ExternalContextImpl.getResource(ExternalContextImpl.java:528)
csf.appl.resource.WebappResourceHelper.findResource(WebappResourceHelper.java:185)
csf.appl.resource.ResourceManager.findResource(ResourceManager.java:419)
csf.appl.resource.ResourceManager.doLookup(ResourceManager.java:248)
csf.appl.resource.ResourceManager.findResource(ResourceManager.java:185)
csf.appl.resource.ResourceHandlerImpl.createResource(ResourceHandlerImpl.java:172)
csf.appl.resource.ResourceHandlerImpl.createResource(ResourceHandlerImpl.java:152)
csf.fclts.tag.jsf.CompositeComponentTagLibrary.getCompositeComponentResource(CompositeComponentTagLibrary.java:155)
csf.fclts.tag.jsf.CompositeComponentTagLibrary.containsTagHandler(CompositeComponentTagLibrary.java:121)
csf.fclts.tag.CompositeTagLibrary.containsTagHandler(CompositeTagLibrary.java:177)
csf.fclts.compiler.CompilationManager.pushTag(CompilationManager.java:295)
csf.fclts.compiler.SAXCompiler$CompilationHandler.startElement(SAXCompiler.java:266)
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:501)
com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.startElement(XMLDTDValidator.java:767)
com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:400)
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2756)
com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648)
com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:140)
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:511)
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:808)
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119)
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205)
com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522)
javax.xml.parsers.SAXParser.parse(SAXParser.java:395)
javax.xml.parsers.SAXParser.parse(SAXParser.java:198)
csf.fclts.compiler.SAXCompiler.doCompile(SAXCompiler.java:434)
csf.fclts.compiler.SAXCompiler.doCompile(SAXCompiler.java:410)
csf.fclts.compiler.Compiler.compile(Compiler.java:124)
csf.fclts.impl.DefaultFaceletFactory.createFacelet(DefaultFaceletFactory.java:401)
csf.fclts.impl.DefaultFaceletFactory.access$100(DefaultFaceletFactory.java:102)
csf.fclts.impl.DefaultFaceletFactory$1.newInstance(DefaultFaceletFactory.java:183)
csf.fclts.impl.DefaultFaceletFactory$1.newInstance(DefaultFaceletFactory.java:181)
csf.fclts.impl.DefaultFaceletCache$1.newInstance(DefaultFaceletCache.java:83)
csf.fclts.impl.DefaultFaceletCache$1.newInstance(DefaultFaceletCache.java:78)
csf.util.ExpiringConcurrentCache$1.call(ExpiringConcurrentCache.java:99)
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
java.util.concurrent.FutureTask.run(FutureTask.java:138)
csf.util.ExpiringConcurrentCache.get(ExpiringConcurrentCache.java:114)
csf.fclts.impl.DefaultFaceletCache.getFacelet(DefaultFaceletCache.java:121)
csf.fclts.impl.DefaultFaceletCache.getFacelet(DefaultFaceletCache.java:62)
csf.fclts.impl.DefaultFaceletFactory.getFacelet(DefaultFaceletFactory.java:278)
csf.fclts.impl.DefaultFaceletFactory.getFacelet(DefaultFaceletFactory.java:223)
csf.appl.view.FaceletViewHandlingStrategy.buildView(FaceletViewHandlingStrategy.java:768)
csf.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:100)
csf.lifecycle.Phase.doPhase(Phase.java:101)
csf.lifecycle.LifecycleImpl.render(LifecycleImpl.java:179)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:641)

Usage5: When trying to find a ScriptComponent Resource for a Composite
Component.

csf.context.ExternalContextImpl.getResource(ExternalContextImpl.java:527)
csf.appl.resource.WebappResourceHelper.findResource(WebappResourceHelper.java:185)
csf.appl.resource.ResourceManager.findResource(ResourceManager.java:419)
csf.appl.resource.ResourceManager.doLookup(ResourceManager.java:248)
csf.appl.resource.ResourceManager.findResource(ResourceManager.java:185)
csf.appl.resource.ResourceHandlerImpl.createResource(ResourceHandlerImpl.java:172)
csf.appl.resource.ResourceHandlerImpl.createResource(ResourceHandlerImpl.java:152)
csf.appl.view.FaceletViewHandlingStrategy.getScriptComponentResource(FaceletViewHandlingStrategy.java:340)
csf.appl.applImpl.createComponent(ApplicationImpl.java:962)
csf.fclts.tag.jsf.CompositeComponentTagHandler.createComponent(CompositeComponentTagHandler.java:165)
csf.fclts.tag.jsf.ComponentTagHandlerDelegateImpl.createComponent(ComponentTagHandlerDelegateImpl.java:500)
csf.fclts.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:157)
javax.faces.view.fclts.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
javax.faces.view.fclts.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
javax.faces.view.fclts.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
csf.fclts.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184)
javax.faces.view.fclts.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
javax.faces.view.fclts.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
javax.faces.view.fclts.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
csf.fclts.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184)
javax.faces.view.fclts.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
javax.faces.view.fclts.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
csf.fclts.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
javax.faces.view.fclts.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
csf.fclts.compiler.EncodingHandler.apply(EncodingHandler.java:86)
csf.fclts.impl.DefaultFacelet.apply(DefaultFacelet.java:152)
csf.appl.view.FaceletViewHandlingStrategy.buildView(FaceletViewHandlingStrategy.java:774)
csf.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:100)
csf.lifecycle.Phase.doPhase(Phase.java:101)
csf.lifecycle.LifecycleImpl.render(LifecycleImpl.java:179)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:641)

Usage6: When trying to render out the markup for a stylesheet reference
in the HEAD.

csf.context.ExternalContextImpl.getResource(ExternalContextImpl.java:527)
csf.appl.resource.WebappResourceHelper.findResource(WebappResourceHelper.java:185)
csf.appl.resource.ResourceManager.findResource(ResourceManager.java:419)
csf.appl.resource.ResourceManager.doLookup(ResourceManager.java:248)
csf.appl.resource.ResourceManager.findResource(ResourceManager.java:185)
csf.appl.resource.ResourceHandlerImpl.createResource(ResourceHandlerImpl.java:172)
csf.appl.resource.ResourceHandlerImpl.createResource(ResourceHandlerImpl.java:152)
csf.renderkit.html_basic.StylesheetRenderer.encodeEnd(StylesheetRenderer.java:97)
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:875)
javax.faces.component.UIComponent.encodeAll(UIComponent.java:1799)
csf.renderkit.html_basic.HeadRenderer.encodeHeadResources(HeadRenderer.java:105)
csf.renderkit.html_basic.HeadRenderer.encodeEnd(HeadRenderer.java:92)
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:875)
javax.faces.component.UIComponent.encodeAll(UIComponent.java:1799)
javax.faces.component.UIComponent.encodeAll(UIComponent.java:1795)
csf.appl.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:402)
csf.appl.view.MultiViewHandler.renderView(MultiViewHandler.java:127)
csf.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:121)
csf.lifecycle.Phase.doPhase(Phase.java:101)
csf.lifecycle.LifecycleImpl.render(LifecycleImpl.java:179)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:641)

Comment by Ed Burns [ 29/Feb/12 ]

Spoke to Kito Mann today. It emerged that it might make sense to leverage the ResourceHandler (fixing its many problems first) for this purpose.

This might make it possible to deprecated the Facelets ResourceResolver.

Comment by Ed Burns [ 09/Mar/12 ]

Sending jsf-api/src/main/java/javax/faces/application/ResourceHandler.java
Sending jsf-api/src/main/java/javax/faces/application/ResourceHandlerWrapper.java
Sending jsf-api/src/main/java/javax/faces/view/ViewDeclarationLanguage.java
Sending jsf-api/src/main/java/javax/faces/view/facelets/FaceletFactory.java
Sending jsf-api/src/main/java/javax/faces/view/facelets/FaceletFactoryWrapper.java
Sending jsf-api/src/main/java/javax/faces/view/facelets/ResourceResolver.java
Sending jsf-ri/src/main/java/com/sun/faces/application/resource/ResourceHandlerImpl.java
Sending jsf-ri/src/main/java/com/sun/faces/application/view/FaceletViewHandlingStrategy.java
Sending jsf-ri/src/main/java/com/sun/faces/facelets/impl/DefaultFaceletFactory.java
Sending jsf-ri/src/main/java/com/sun/faces/facelets/impl/DefaultResourceResolver.java
Transmitting file data ..........
Committed revision 9755.

Comment by arjan tijms [ 20/Mar/13 ]

Regarding #3… ExternalContext.getResource() may be used for all sorts of resources. In our case we
only want to search our external repositories when a view id is requested, but not, say, when someone
calls getResource() to load some other type of file (eg. a style sheet).

I know the issue is resolved and closed, but I'm just wondering about the original intend.

The description makes it sound like ExternalContext.getResource() has to be overridden in addition to providing a ResourceResolver to fully support loading views from another location. Supposedly implicit navigation directly called ExternalContext.getResource().

But, this is not what happens at all in JSF 2.1.

Implicit navigation and all other cases that need to interact with the physical location of the view already go through the ResourceResolver. This is clear from the stacktraces Ed posted on 24/Feb/12 09:13 PM

So, in order to satisfy "we only want to search our external repositories when a view id is requested", the existing ResourceResolver already fully did the job and "2. It requires hooking into multiple locations." doesn't apply.

Maybe I'm completely missing something though.

The new mechanism does seem inline with the comment made by kito on 19/Apr/11

Comment by aschwart [ 21/Mar/13 ]

Hi Arjan -

The description makes it sound like ExternalContext.getResource() has to be overridden in addition to providing a ResourceResolver to fully support loading views from another location. Supposedly implicit navigation directly called ExternalContext.getResource().

But, this is not what happens at all in JSF 2.1.

Right.

The issue was originally filed back in 2010, before 2.1 existed.

In 2.0.x, Mojarra's MultiViewHandler.convertViewId() contains the following logic:

if (context.getExternalContext().getResource(convertedViewId) != null)

Unknown macro: { // RELEASE_PENDING (rlubke,driscoll) cache the lookup return convertedViewId; }

This code is checking for the presence of a view corresponding to a viewId by calling ExternalContext.getResource(). This of course fails for views that are known to the ResourceResolver, but are not accessible via ExternalContext.getResource(). As such, frameworks that plug into the ResourceResolver to enhance the set of views that are available must also plug into ExternalContext.getResource().

We addressed this in 2.1.x with the addition of ViewDeclarationLanguage.viewExists().

As of 2.1.x, the above MultiViewHandler code has been replaced with:

if (vdl.viewExists(context, convertedViewId))

Unknown macro: { // RELEASE_PENDING (rlubke,driscoll) cache the lookup return convertedViewId; }

And FaceletViewHandlingStrategy implements this as:

return faceletFactory.getResourceResolver().resolveUrl(viewId) != null;

This removes the need for frameworks that provide a ResourceResolver to also plug into ExternalContext.getResource().

Comment by aschwart [ 21/Mar/13 ]

BTW, Arjan - thank you for http://jdevelopment.nl/jsf-22/ !! :-D

Comment by arjan tijms [ 21/Mar/13 ]

The issue was originally filed back in 2010, before 2.1 existed.
[...]
This removes the need for frameworks that provide a ResourceResolver to also plug into ExternalContext.getResource().

Okay, it's clear now Basically this issue was already solved by the addition of ViewDeclarationLanguage.viewExists() in 2.1 and could have been closed then (but it's still great 2.2 went a bit beyond the initial solution). Thanks for the explanation.

thank you for http://jdevelopment.nl/jsf-22/

You're welcome! Incidentally, it's for that page mostly that I was wondering about the intent of this issue I also wondered about this since for the OmniFace's extensionless URL support I make heavy use of the ResourceResolver and feared I might have missed something.

Thanks again for explaining.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-808] Move SystemEventListener implementation from UIComponent down to UIComponentBase. Created: 25/May/10  Updated: 01/Aug/14  Resolved: 20/Sep/10

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: 2.0
Fix Version/s: 2.1

Type: Bug Priority: Major
Reporter: aschwart Assignee: rogerk
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Attachments: Text File changebundle.txt    
Issuezilla Id: 808
Status Whiteboard:

size_small importance_large

Tags: adf, changelog_2_1

 Description   

UIComponent provides implementations for:

  • subscribeToEvent
  • unsubscribeFromEvent
  • getListenersForEventClass

And also provides storage for system event listeners.

However, UIComponent does not provdie state saving for system event listeners. This is implemented
by UIComponentBase.

As a result, components that extend UIComponent directly cannot leverage the default system event
listener method implementations, since:

1. The listeners will not be state saved by UIComponent.
2. There is no way for a subclass to access the listeners for custom state saving purposes.

These concrete method implementations do not belong on UIComponent. They should be pushed
down to UIComponentBase. Components that subclass UIComponent can provide their own system
event listener storage/state saving.



 Comments   
Comment by Ed Burns [ 27/May/10 ]

2.1.

Comment by Ed Burns [ 01/Jun/10 ]

Add adf keyword

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 28/Jun/10 ]

target 2.1_gf31_m4

Comment by rogerk [ 10/Aug/10 ]

target

Comment by rogerk [ 01/Sep/10 ]

Starting

Comment by rogerk [ 01/Sep/10 ]

Created an attachment (id=277)
Changes (Revision 1)

Comment by rogerk [ 01/Sep/10 ]

Changes attached. All existing component system event tests continue to run
successfully.

Comment by Ed Burns [ 01/Sep/10 ]

r=edburns

Comment by rogerk [ 01/Sep/10 ]

Checked in.

Comment by Ed Burns [ 13/Sep/10 ]

add changelog_2_1 keyword

Comment by Ed Burns [ 13/Sep/10 ]

Update status for JCP ChangeLog.

Comment by Ed Burns [ 20/Sep/10 ]

Ensure changelog_2_1 is in keywords list

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-802] Ajax fileupload capabilities Created: 17/May/10  Updated: 23/Dec/13  Resolved: 30/Apr/13

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Ajax/JavaScript
Affects Version/s: 2.0
Fix Version/s: 2.2

Type: Improvement Priority: Critical
Reporter: werpu12 Assignee: Ed Burns
Resolution: Fixed Votes: 10
Labels: None
Remaining Estimate: 6 days, 8 hours, 3 minutes
Time Spent: 15 hours, 57 minutes
Original Estimate: 1 week
Environment:

Operating System: All
Platform: Macintosh


Attachments: Text File 20110613-i_spec_802_mods.txt     Text File 20111208-i_spec_802-mods.patch     File 20121102-werpu-AjaxFileupload.odt    
Issue Links:
Dependency
depends on GLASSFISH-16740 Unable to get "multipart/form-data" r... Resolved
depends on JAVASERVERFACES_SPEC_PUBLIC-149 Provide way to discover the JSF spec ... Closed
blocks JAVASERVERFACES-2573 Implement "ajax" file upload Closed
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1197 Support multiple attribute on h:input... Open
is related to JAVASERVERFACES-3122 Migrate test for spec issue #802 to t... Closed
Issuezilla Id: 802
Status Whiteboard:

size_medium importance_large draft

Tags: adf

 Description   

The main issue with the current implementation is, that fileupload the ajax way
is not working properly.

The problem simply is, that fileupload component and multipart form requests
both are a second class citizen in the JEE world and html generally.
There is no way to submit a fileupload via ajax currently, however there is an
iframe based method to do it.

But for that an iframe transport layer is missing, since the current spec only
talks abut queued asynchronous xhr requests.

see http://www.openjs.com/articles/ajax/ajax_file_upload/

for more information....



 Comments   
Comment by Ed Burns [ 24/May/10 ]

New features, 2.1.

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 08/Jun/10 ]

Comments from issue 647 Note that from a spec perspective, I believe that the main issue is that
jsf.ajax.response() expects a XHR
object, which it uses to grab the responseXML. However, XHR cannot be used in the multi-part form case
(requires iframe-based postback), and as such no XHR object is available to pass off to jsf.ajax.response().

Comment by Ed Burns [ 08/Jun/10 ]
      • Issue 647 has been marked as a duplicate of this issue. ***
Comment by Ed Burns [ 08/Jun/10 ]

adf keyword

Comment by Ed Burns [ 24/Jun/10 ]

Change target milestone.

Comment by rogerk [ 30/Jun/10 ]

triage - Folks have been asking for this.

Comment by ganeshpuri [ 30/Jun/10 ]

would be great to be able to do AJAX uploads with 2.1

Comment by werpu12 [ 09/Jul/10 ]

Ok I am doing some prototyping on this issue within the realms of myfaces (since
I am not allowed to do that for Mojarra)
So far I have something preliminary up and running which has yet to be committed
which pushes the current lifecycle over iframes insteas of xhr. However I found
something in the spec which is some sort of a blocker. The spec requires for a
valid ajax request that Faces-Request:partial/ajax is set in the request header.
I do not think you can tamper on form level (which in fact the iframe solution
is) with that. The result of leaving it out is that the impl thinks this is not
an ajax request and then renders the full page instead of the response xml.

I am going to investigate further if setting the request header is possible on
the iframe solution. Otherwise we have to revamp the spec here a little bit.

Comment by werpu12 [ 14/Jul/10 ]

Ok the issue with the current specification in the ajax dection and triggering
of the partial mechanisms is following. I was able to patch the
PartialViewHandler up so that the entire lifecycle works with the iframe transport.

The problem really is we currently have two mechanisms, one identifying that it
is a partial request, the other one, that it is an Ajax request.
Both work over request headers, for the iframe case we have to weaken the spec
here a little bit to allow the same over
request parameters, since there seems to be no way to submit a new header param
via a normal form submit.

The idea is following, introduce a third type, iframe request, and allow both
ajax request, iframe request and partial request also be submitted over simple
request parameters instead of header params (so both type of values can trigger
a valid partial lifecycle a request header parameter or a normal request parameter)
Once a valid iframe request can trigger the partial lifecycle everything else
behaves just as it would in the xhr case (for the server both usecases are just
post requests)

As for the proposed mechanism. My personal idea is to enqueue an iframe request
just like we would a normal xhr post request in our asynchronous queue and just
treat it from outside like we we an xhr request. I have this running for most
browsers already I just have a sync issue for heavy load on IE6, which I will
investigate later into, but the pattern looks good to me that it might be
implementable.

(see the preliminary snapshot code here http://www.pastebin.org/396667 and
http://www.pastebin.org/396646 from my myfaces based prototype)
The reason for this is synchronisation issues which the queue eliminates.

As how and when we trigger the mechanism is a little bit unclear to me still, my
personal guess is that an auto switch between xhr and iframe in case of an
embedded executed fileupload might make the most sense to keep the api simple),
I will try to find out more once my prototype can finally do the fileupload.

Comment by Ed Burns [ 28/Jul/10 ]

Please make sure to look at https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?
id=690

Comment by Ed Burns [ 28/Jul/10 ]

Also make sure to look at https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=861

Comment by Ed Burns [ 29/Jul/10 ]

Werner suggests the attribute set for t:inputFileUpload as a guide

http://www.jsftoolbox.com/documentation/tomahawk/09-TagReference/tomahawk-inputFileUpload.html

Comment by Ed Burns [ 02/Sep/10 ]

Even though Werner has done most of the preparatory work on this issue, I still have to move it to JSF
2.2.

Comment by markcolletteice [ 14/Apr/11 ]

In ICEfaces ACE, the fileEntry component uses the [hidden] iframe technique. We have to fake out the partial/ajax request, as well as extract the uploaded file(s) and translate the multi-part request to not be multi-part, so that JSF will run. And then in the browser, when handling the response, we have to fake out the XHR response object, using what we get from the iframe response, so that page updates will be handled.

It would be nice to collaborate on moving parts of this into JSF, so that everyone's different file upload components could be built on a common infrastructure.

One critical issue to us is that we don't follow the pattern of simply sticking the file contents into a temporary byte[] or file, like the other component frameworks do. We allow for either directly writing the file to the end file-system destination that the application specified, or using a callback interface for chunking the file data, without buffering the whole file, to the application, so that it can virus scan the file contents, or re-transmit it to another server via a socket, or write it to a database. So, we'd like the file processing to be custom for the component framework, that way we're not limited by a lowest common denominator handling of file data.

http://wiki.icefaces.org/display/ICE/FileEntry
http://www.icefaces.org/docs/v2_latest/ace/tld/ace/fileEntry.html
http://wiki.icefaces.org/display/ICE/Incremental+Upload+Processing+Using+FileEntryCallback

Comment by Neil Griffin [ 19/Apr/11 ]

I'm very happy to see that Ajax-based file upload is being discussed. But for the sake of completeness, I think that the old Web 1.0 multipart/form-data technique should be supported, as was discussed in http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-690

In my comments there,mentioned that I implemented a solution in the PortletFaces Bridge. It's working quite nicely – no need for Servlet 3.0, no need for a filter. Everything works great. Making this work in a Servlet-based JSF like Mojarra should be a piece of cake.

Comment by tedgoddard [ 21/Apr/11 ]

The approach to resolving this should be to provide additional APIs that make it possible to plug different transports into the JSF request/response cycle:

  • allow a partial response to be requested without a custom HTTP header
  • support new HTML5/XMLHttpRequest features that include file parts
  • expose JSF form serialization to String as JavaScript API
  • ensure that jsf.ajax.response can easily be called by external code (context and jsfResponse do not seem to be entirely public parameters)
Comment by werpu12 [ 21/Apr/11 ]

Actually that is how we prototyped it for myfaces. We dont have an official api, but we have configuration options which allow to choose a certain transport type.

So you can define jsf.ajax.request with additional myfaces:

{transportType: "iframeRequest"}

etc.. options to force the system into an iframe request.

We also allow an auto transport option where the system changes from the default xhr level1 into iframe if a multipart file upload situation is detected.

The problem with xhr level3 simply is or was the last time I looked at it that most browsers issued multipart requests without length attributes which rendered most fileupload libraries useless (and broke one of the two related specs in that area)
so an auto fallback to xhr level3 is definitely given the state of affairs a no go.

But as I see it xhr level3 is a good option if you can support it properly because it also allows some kind of progress notification so if this issue is started we also should opt for xhr level3 optionally.

The http header issue was another one. Currently the jsf ajax cycle is determined over custom http header, which is a no go in an iframe scenario because you only can send parameters, this needs to be fixed (and I did an internal fallback in myfaces to fix this but this is currently an implementation detail.

the jsf.ajax.response is another issue relatively unrelated, in myfaces we have some internal params which fix some internal issues, like how do you fix the issue of having an update and your original element is detached as well as its parent form. Those kind issues simply have to be taken care of in the official spec then I guess the jsf.ajax.response is really public.
I guess mojarra has 1-2 of those extra bugfix params as well.
But actually in case of myfaces I just got this bugreport in and it indeed is a bug in our impl because the call to the jsf.ajax.response should work without any extra params.

Comment by Ed Burns [ 06/Jun/11 ]

Bulk assign all of Sheetal's spec issues to me.

Comment by Ed Burns [ 08/Dec/11 ]

Neil committed his version of the work to https://svn.java.net/svn/mojarra~svn/branches/FILE_UPLOAD

These are the files that differ from the state of the tree when he created that branch.

These files were committed in r9162.

Index: common/ant/dependencies.xml
Index: jsf-api/doc/file-props.xml
Index: jsf-api/doc/standard-html-renderkit-base.xml
Index: jsf-api/doc/standard-html-renderkit.xml
Index: jsf-api/src/main/java/javax/faces/component/UploadedFile.java
Index: jsf-ri/conf/share/html_basic.taglib.xml
Index: jsf-ri/src/main/java/com/sun/faces/context/ExternalContextImpl.java
Index: jsf-ri/src/main/java/com/sun/faces/context/RequestParameterMapMultiPartImpl.java
Index: jsf-ri/src/main/java/com/sun/faces/context/RequestParameterMapFactory.java
Index: jsf-ri/src/main/java/com/sun/faces/context/RequestParameterValuesMapMultiPartImpl.java
Index: jsf-ri/src/main/java/com/sun/faces/facelets/tag/jsf/html/HtmlDecorator.java
Index: jsf-ri/src/main/java/com/sun/faces/facelets/tag/jsf/html/HtmlLibrary.java
Index: jsf-ri/src/main/java/com/sun/faces/renderkit/html_basic/FileRenderer.java
Index: jsf-ri/src/main/java/com/sun/faces/renderkit/html_basic/TextRenderer.java
Index: jsf-ri/src/main/java/com/sun/faces/component/UploadedFileImpl.java
Index: jsf-ri/src/main/resources/com/sun/faces/standard-html-renderkit-impl.xml

Comment by Ed Burns [ 08/Dec/11 ]

Notes from merging in Neil's work.

Comment by Ed Burns [ 08/Dec/11 ]

In progress patch.

Comment by Ed Burns [ 09/Dec/11 ]

muellermi
@edburns Will JSF's AJAX file upload offer functions to display progress? Or suport multi-file uploads?

Comment by werpu12 [ 09/Dec/11 ]

Progress is not possible with existing html means, XHR Level 2 in the long run will support it. Not sure if the spec can specifiy a progress event which if supported can be fired and if not does nothing except to go from 0 to 100, it would make sense. Same I think goes for multiple file uploads.
(Cannot remember if the existing iframe method supports multiple file uploads)

Comment by Ed Burns [ 16/Dec/11 ]

Move to Sprint 10, but at leas we have the non-Ajax portion committed.

Comment by Ed Burns [ 03/Feb/12 ]

Move to sprint 11

Comment by robweaver [ 13/Apr/12 ]

Just updated to 3.1.2 (Build 23) and the FileUpload on PrimeFaces broke (I think due to this issue).

Upload widget acts as if the upload is working, but never hits the back end event handler.

Reverting to 3.1 with no changes to WAR and the file upload works again.

Would be glad to help diagnose this issue.

Any target date for the fix, and is there a workaround ?

Comment by Ed Burns [ 13/Apr/12 ]

Hello robweaver,

Can I ask you please to file this in the GLASSFISH JIRA? I know some multipart upload changes were done in GlassFish 3.1.2 and t's quite possible this has nothing to do with Mojarra JSF implementation. At any rate, it certainly doesn't have anything to do with the spec.

http://java.net/jira/browse/GLASSFISH

Thanks,
Ed

Comment by robweaver [ 15/Apr/12 ]

Thanks, I thought I was entering it on the GlassFish issue, sorry see http://java.net/jira/browse/GLASSFISH-18444 which appears to be my issue.

Apologies for the incorrect entry.

Comment by rogerk [ 23/May/12 ]

There currently is a bug in the implementation - see: http://java.net/jira/browse/JAVASERVERFACES-2420. However, if the page author specifies a "value" attribute it should be rendered.

Comment by Ed Burns [ 15/Oct/12 ]

Werner prepared this document prior to a 60 minute Google+ hangout we had today. We edited the document during the meeting.

Comment by Ed Burns [ 16/Oct/12 ]

See < http://tim-vm9.us.oracle.com:7070/hudson/job/trunk-test-glassfish-4_0/442/ >.

Comment by Ed Burns [ 06/Nov/12 ]

Werner had some additional feedback.

Comment by arjan tijms [ 30/Apr/13 ]

As JSF 2.2 went final, shouldn't this issue be closed?

Comment by rogerk [ 30/Apr/13 ]

Fixed for 2.2

Comment by jid1 [ 03/Jun/13 ]

Did the "multiple" attribute make it into the spec?

Comment by Ed Burns [ 10/Jun/13 ]

Well, yes and no. I just tested it.

Here's the yes part.

You can say this:

<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:ui="http://xmlns.jcp.org/jsf/facelets"
      xmlns:f="http://xmlns.jcp.org/jsf/core"
      xmlns:h="http://xmlns.jcp.org/jsf/html"
      xmlns:p="http://xmlns.jcp.org/jsf/passthrough">
    <h:head></h:head>

    <h:form id="form" enctype="multipart/form-data" prependId="false">
        
        <p><h:inputFile id="file" value="#{fileUploadBean.uploadedFile}" p:multiple="multiple"> 
             <f:validator validatorId="FileValidator" />
           </h:inputFile>
        </p>
...

and it renders correctly:

        <p><input id="file" type="file" name="file" multiple="multiple" />

but the no part is that each of the files in the multiple list is overwritten when the next one is processed.

Comment by Ed Burns [ 10/Jun/13 ]

I have filed < https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1197 > to cover this. We'll get to it in 2.3.





[JAVASERVERFACES_SPEC_PUBLIC-793] A comment different than <!-- -->, not sent to the HTML output, shall be allowed in JSF xhtml files. Created: 11/May/10  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: 2.1
Fix Version/s: None

Type: New Feature Priority: Minor
Reporter: grunt2000 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Dependency
depends on JAVASERVERFACES_SPEC_PUBLIC-697 more XML-centric model for Facelets Closed
Issuezilla Id: 793
Status Whiteboard:

size_medium importance_large

Tags: adf, adf_high

 Description   

Currently, any <!-- --> comment is sent to the HTML output, if this parameter is
not set in faces-config.xml:

<context-param>
<param-name>facelets.SKIP_COMMENTS</param-name>
<param-value>true</param-value>
</context-param>

This is often done to avoid publishing comments that most of the time have for
audience the developers. However, if the choice is done to skip the comments,
all will be skipped, and you won't be able to send any public information you
would really like to see in comments, and more than that, special statements for
browser management (of the kind <!-- [IE7 ...] -->) won't reach the output.

Another way, if the facelets.SKIP_COMMENTS isn't used, is to surround each
internal comment with
<ui:remove><!-- My comment --></ui:remove>,
provided an initial declaration
xmlns:ui="http://java.sun.com/jsf/facelets"
is written at the beginning of the JSF xhtml file.

Whatever, choosing to edit the xml(s) files to add facelets.SKIP_COMMENTS or
surrounding internal comments with <ui:remove> +
xmlns:ui="http://java.sun.com/jsf/facelets", is clumsy.

Some kind of comment should be created
<%-- --%> or any other style, that would set an internal comment never published
in the HTML output.



 Comments   
Comment by grunt2000 [ 11/May/10 ]

(small mistake: the facelets.SKIP_COMMENTS context param is set in the web.xml
file, and not faces-config.xml).

Comment by Ed Burns [ 24/May/10 ]

Behavior change, move to 2.1.

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by rogerk [ 21/Jun/10 ]

ownership

Comment by rogerk [ 28/Jun/10 ]

target 2.1_gf31_m4

Comment by Ed Burns [ 28/Jun/10 ]

Target Milestone 4

Comment by rogerk [ 10/Aug/10 ]

target

Comment by Ed Burns [ 11/Aug/10 ]

Also take a look at
<https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1768>.

Comment by rogerk [ 31/Aug/10 ]

starting

Comment by rogerk [ 31/Aug/10 ]

If you really need another comment that is not passed to output, I can introduce
a <ui:comment> tag that behaves the same as <ui:remove>. As you know, XML only
recognizes a distinguished set of characters and patterns (for example <%-- -->
would cause a SAX Parser Exception).

Comment by grunt2000 [ 01/Sep/10 ]

If a comment is added, it should not be a <ui:comment> one.

First, because in order to put a comment in an xhtml, the developer should not
have to add a:
xmlns:ui="http://java.sun.com/jsf/facelets" at the beginning of his files.

Implementing a pure comment in xhtml file must be a core feature of JSF, not
involving any tricks from the developer and being easy of use. <ui:comment> is
far too long to write.

Once JSP used <%! %> for hidden comments.
What about declaring something like: <' ... '> as an internal comment and
disallow JSF parsing its content?

Please, please, please... NOTHING beginning with <ui: !
Please no!

Comment by rogerk [ 01/Sep/10 ]

For most cases, a JSF 2.0 xhtml page will already require the
xmlns:ui="http://java.sun.com/jsf/facelets" declaration.
Again, to do what you ask for a smaller subset of JSF XHTML pages will require
some custom parsing at least to remove the special characters for the comment
before JSF (Facelets) parsing occurs - otherwise you will end up with SAX parse
exception. If you are worried about the length of <ui:comment> then perhaps a
shorter tag name.

Comment by rogerk [ 01/Sep/10 ]

Lower priority.

Comment by rogerk [ 02/Sep/10 ]

This may need more discussion if the reporter is not satisfied.
Will need to reevaluate for 2.2.

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Set priority to Minor





[JAVASERVERFACES_SPEC_PUBLIC-792] Cannot call UIComponent.getCurrentComponent() from UIComponent.restoreState() or UIComponent.saveState() Created: 11/May/10  Updated: 12/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: 2.0
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: lu4242 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 792
Status Whiteboard:

size_medium importance_large

Tags: adf

 Description   

From jsr-314-open list:

The javadoc of UIComponent.processRestoreState() says this:

"....Perform the component tree processing required by the Restore View phase
of the request processing lifecycle for all facets of this component, all
children of this component, and this component itself, as follows.

  • Call the restoreState() method of this component.
  • Call pushComponentToEL(javax.faces.context.FacesContext,
    javax.faces.component.UIComponent).
  • Call the processRestoreState() method of all facets and children of this
    UIComponent in the order determined by a call to getFacetsAndChildren(). After
    returning from the processRestoreState() method on a child or facet, call
    popComponentFromEL(javax.faces.context.FacesContext)..."

The javadoc of UIComponent.processSaveState() says this:

".....Perform the component tree processing required by the state saving portion
of the Render Response phase of the request processing lifecycle for all facets
of this component, all children of this component, and this component itself, as
follows.

  • consult the transient property of this component. If true, just return null.
  • Call pushComponentToEL(javax.faces.context.FacesContext,
    javax.faces.component.UIComponent).
  • Call the processSaveState() method of all facets and children of this
    UIComponent in the order determined by a call to getFacetsAndChildren(),
    skipping children and facets that are transient. Ensure that
    popComponentFromEL(javax.faces.context.FacesContext) is called correctly after
    each child or facet.
  • Call the saveState() method of this component.
  • Encapsulate the child state and your state into a Serializable Object and
    return it....."

The question is: Doesn't suppose that when you call
UIComponent.getCurrentComponent() inside UIComponent.restoreState(), it returns
the "current component"?. There is one case when we need to do this call and is
on the wrapper used by UIComponent.subscribeToEvent(). The javadoc of this
method says this:

"....Install the listener instance referenced by argument componentListener as a
listener for events of type eventClass originating from this specific instance
of UIComponent. The default implementation creates an inner SystemEventListener
instance that wraps argument componentListener as the listener argument. This
inner class must call through to the argument componentListener in its
implementation of
SystemEventListener.processEvent(javax.faces.event.SystemEvent) and its
implementation of SystemEventListener.isListenerForSource(java.lang.Object)
must return true if the instance class of this UIComponent is assignable from
the argument to isListenerForSource...."

Both myfaces and mojarra has the wrapper described by the javadoc, and that one
is responsible to save/restore the system event listeners attached. To restore
the "component" reference required, both implementations call
UIComponent.getCurrentComponent() and both call processEvent but for the parent!.

It is obviously a bug (I don't see a valid reason why do the algorithm
described), if you look other methods like processDecodes, you see the right
pattern:

  • If the rendered property of this UIComponent is false, skip further
    processing.
  • Call pushComponentToEL(javax.faces.context.FacesContext,
    javax.faces.component.UIComponent).
  • Call the processDecodes() method of all facets and children of this
    UIComponent, in the order determined by a call to getFacetsAndChildren().
  • Call the decode() method of this component.
  • Call popComponentFromEL(javax.faces.context.FacesContext) from inside of a
    finally block, just before returning.
  • If a RuntimeException is thrown during decode processing, call
    FacesContext.renderResponse() and re-throw the exception.

I'll change myfaces algorithm to look like processDecodes(). But anyway, it is
necessary to do the proper change on mojarra and on spec javadoc.



 Comments   
Comment by Ed Burns [ 11/May/10 ]

LU> To restore the "component" reference required, both implementations
LU> call UIComponent.getCurrentComponent() and both call processEvent
LU> but for the parent!

Is the bug that we call processEvent on the parent, and not the
"correct" instance?

Comment by Ed Burns [ 18/May/10 ]

>>>>> On Tue, 11 May 2010 11:29:26 -0500, Leonardo Uribe said:

LU> In this case, I'm thinking the bug is do not include restoreState /
LU> saveState on the call. In other words, instead do this:

LU> * Call the restoreState() method of this component.
LU> * Call pushComponentToEL(javax.faces.context.FacesContext,
LU> javax.faces.component.UIComponent).
LU> * Call the processRestoreState() method of all facets and children of
LU> this UIComponent in the order determined by a call to
LU> getFacetsAndChildren(). After returning from the processRestoreState()
LU> method on a child or facet, call
LU> popComponentFromEL(javax.faces.context.FacesContext)..."

LU> Do the following

LU> * Call pushComponentToEL(javax.faces.context.FacesContext,
LU> javax.faces.component.UIComponent).
LU> * Call the restoreState() method of this component.
LU> * Call the processRestoreState() method of all facets and children of
LU> this UIComponent in the order determined by a call to
LU> getFacetsAndChildren(). After returning from the processRestoreState()
LU> method on a child or facet, call
LU> popComponentFromEL(javax.faces.context.FacesContext)..."

LU> In myfaces code, I found I did the latests in our pss algorithm. Really I
LU> discover this bug when I disable pss and try a tomahawk example. As it was
LU> described, both myfaces and mojarra fell in the ilusion the latest strategy
LU> was used.

Comment by Ed Burns [ 24/May/10 ]
      • Issue 799 has been marked as a duplicate of this issue. ***
Comment by Ed Burns [ 24/May/10 ]

take ownership.

Comment by Ed Burns [ 26/May/10 ]

I made the change in my local workspace and am now re-running our automated test suite.

Comment by Ed Burns [ 26/May/10 ]

Hmm, I ran into a very strange case when I changed the code as you suggested.

Before the change: this works

nesting05.xhtml uses composite component

<ez:nesting6 id="nesting6" bean="#

{compositeBean}

" />

the composite component has this:

<composite:interface>
<composite:attribute name="bean" required="true" />
</composite:interface>

<composite:implementation>
<ez:nesting7 id="nesting7" action="#

{cc.attrs.bean.action}

"
actionListener="#

{cc.attrs.bean.actionListener}

"
validator="#

{cc.attrs.bean.validate}

"
valueChangeListener="#

{cc.attrs.bean.valueChange}

"
bean="#

{cc.attrs.bean}

"/>
</composite:implementation>

nesting7.xhtml has

<composite:interface>
<composite:attribute name="action" method-signature="String method()"
targets="form1:command" />
<composite:attribute name="actionListener" method-signature="void
method(javax.faces.event.ActionEvent)" targets="form2:command2" />
<composite:attribute name="validator" method-signature="void
validate(javax.faces.context.FacesContext, javax.faces.component.UIComponent, java.lang.Object)"
targets="form4:input" />
<composite:attribute name="valueChangeListener" method-signature="void
valueChange(javax.faces.event.ValueChangeEvent)" targets="form5:input2" />
<composite:attribute name="bean" type="com.sun.faces.composite.CompositeBean" />
</composite:interface>
<composite:implementation>
<h:form id="form1">
<h:commandButton id="command" value="action" />
</h:form>
<br />
<h:form id="form2">
<h:commandButton id="command2" value="actionListener" />
</h:form>
<br />
<h:form id="form3">
<h:commandButton id="command3" value="custom" action="#

{cc.attrs.bean.custom}

"/>
</h:form>
<br />
<h:form id="form4">
<h:inputText id="input" />
<h:commandButton id="command" value="valiator"/>
</h:form>
<br />
<h:form id="form5">
<h:inputText id="input2" />
<h:commandButton id="command" value="valueChange" />
</h:form>
</composite:implementation>

Clicking the action button with id "command" gives me:

Action invoked: nesting6:nesting7:form1:command.

With the change in place, I get a facelets error stating that "bean" is a required attribute, even
though it is, in fact, given on the using page, nesting05.xhtml.

Rather than investigate this further, I'm going to push this to 2.1.

Comment by lu4242 [ 28/May/10 ]

Strange. That example does not seems to be related. There is not any problems in
myfaces, because the only place where UIComponent.getCurrentComponent() is
called is from UIComponent system event listener wrapper. I think it is safe to
do the change (at least on myfaces codebase), because it is very unlikely this
scenario happens.

Comment by Ed Burns [ 01/Jun/10 ]

Add adf keyword

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 24/Jun/10 ]

GlassFish 3.1 M6 at the latest.

Comment by Ed Burns [ 24/Jun/10 ]

ADF issues targeted at GlassFish 3.1 M5

Comment by Ed Burns [ 03/Nov/10 ]

2.2

Comment by Ed Burns [ 19/Dec/13 ]

2.3

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.





[JAVASERVERFACES_SPEC_PUBLIC-782] Fix PostAddToViewEvent and PreRemoveFromViewEvent publishing conditions Created: 31/Mar/10  Updated: 01/Aug/14  Resolved: 01/Nov/10

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: 2.0
Fix Version/s: 2.1

Type: Bug Priority: Critical
Reporter: lu4242 Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 782
Status Whiteboard:

size_small importance_large

Tags: adf

 Description   

There is a discussion unde the topic:

[jsr-314-open] PostAddToViewEvent publishing conditions

Here the first email describing it:

Actually the event publishing conditions of
PostAddToViewEvent/PreRemoveFromViewEvent are not very clear. These conditions
depends if partial state saving is used or not and if facelets updates the view
or not. The problem is this fact is not very intuitive, so for write code
correctly the user needs to be aware of that, in other words this should be
documented somewhere. Also, there are some technical questions that could be of
interest on this mailing list and myfaces dev list too.

In theory, PostAddToViewEvent is used in this cases:

  • h:outputScript and h:outputStylesheet renderers uses it to relocate component
    resources to UIViewRoot facet "head" or "body" target (h:outputStylesheet by
    default to "head"). Note "head" and "body" facets are transient.
  • cc:insertChildren and cc:insertFacet, to relocate components to some place
    inside cc:implementation. The reason why we do that through a listener attached
    to PostAddToViewEvent is we need to take into account the case of nested
    composite components using cc:insertFacet/cc:insertChildren. Note when the
    component tree is built the first time, PostAddToViewEvent is propagated from
    root to nodes.
  • When Partial State Saving is enabled, it is necessary to attach a listener to
    PostAddToViewEvent/PreRemoveFromViewEvent, so if some user add/remove a
    component, we can keep track of those changes and save/restore the component
    tree properly, in other words, support component addition or removal
    programatically.

Now, the instants of time where PostAddToViewEvent is published are:

  • With Partial State Saving enabled
  • When the view is build at first time.
  • In a postback when the view is build but before the state of the component
    is restored.
  • With Partial State Saving disabled
  • When the view is build at first time.
  • In a postback when the view is "refreshed", because all component nodes are
    detached and attached to the tree. In other words, on render response phase,
    vdl.buildView is called and in this case facelets algorithm add all transient
    components (usually all html markup not saved), and to do that, it detach and
    attach all components to be in right order. This also has some other
    implications, like c:if tag depends on this to work correctly.

A developer that is not aware of this fact could think that PostAddToViewEvent
is called when the view is build.

This is true with PSS is enabled, but is not true when PSS is disabled. On this
topic:

[jsr-314-open] add component resources depending on the owner component state

It was described why PostAddToViewEvent cannot be used in that case. But let's
change a litte bit the problem. We have a custom component that creates some
other on PostAddToViewEvent and add it as a children. It should work but in fact
it only works when PSS is enabled, with PSS disabled that code will cause a
duplicate id exception. Of course, the developer can solve it with some effort
but the point is we are not consider the element of least surprise.

But this fact this is only the tip of the iceberg. In mojarra (this was already
fixed on myfaces), components relocated by cc:insertChildren or cc:insertFacet
does not have state when PSS is disabled, because when the view is "refreshed"
the components are created again, but facelets algorithm remove all components
with no bound to a facelet tag handler, and then the listeners attached to
PostAddToViewEvent relocates the new ones, so this effect is not notice at first
view.

Do you remember PostAddToViewEvent propagation ordering is important by
cc:insertChildren/cc:insertFacet? well, with PSS disabled, the ordering now is
from nodes to root, because all nodes are detached and attached from nodes to
root, so in myfaces we did something like this (I removed some non relevant code
to be more clear):

try
{
if (refreshTransientBuild)

{ context.setProcessingEvents(false); }

// populate UIViewRoot
_getFacelet(renderedViewId).apply(context, view);
}
finally
{
if (refreshTransientBuild)

{ context.setProcessingEvents(true); // When the facelet is applied, all components are removed and added from view, // but the difference resides in the ordering. Since the view is // being refreshed, if we don't do this manually, some tags like // cc:insertChildren or cc:insertFacet will not work correctly, because // we expect PostAddToViewEvent will be propagated from parent to child, and // facelets refreshing algorithm do the opposite. FaceletViewDeclarationLanguage._publishPreRemoveFromViewEvent(context, view); FaceletViewDeclarationLanguage._publishPostAddToViewEvent(context, view); }

}

In few words, disable event processing, and fire PostAddToViewEvent and
PreRemoveFromViewEvent in the expected order to build the tree correctly. If we
don't do this, h:outputScript and h:outputStylesheet will not work correctly
(remember that UIViewRoot "head" and "body" facets are transient, so if these
components are relocated, are in fact transient too). Also, care must be taken
to prevent the listener of programatic component addition/removal register
components on this time.

The conclusion based on this reasoning, it is clear the need of new event that
be specific for relocate components (keep it simple for christ sake!). This
event should be propagated for all components in the tree after the view is
build from root to nodes. It could be good to have some clearification about the
real intention of PostAddToViewEvent/PreRemoveFromViewEvent. Really, better
names for those events are
PostAddToComponentTreeEvent/PreRemoveFromComponentTreeEvent.

On this link:

https://issues.apache.org/jira/browse/MYFACES-2638

attachment: MYFACES-2638-3.patch

I attached a proposal to fix this issue, based on myfaces code. The idea is
create a event called javax.faces.event.PostBuildRefreshViewEvent. This event
is quite different from the one proposed in:

[jsr-314-open] add component resources depending on the owner component state

because there is one case this one is not published: when partial state saving
is enabled and there is no call to vdl.buildView for refresh. I also notice that
there is no "inheritance" between events, that means, if I have two events and
one extends from the other and there is a listener attached to the parent, when
the child event is raised the listener is not notified.

h:outputScript, h:outputStylesheet, cc:insertChildren, cc:insertFacet needs to
attach its listeners to that event too, to give the chance to relocate their
related components correctly. The listener that track changes on the component
tree and mark them to be saved/restored fully does not need to listen this event.

PostAddToViewEvent/PreRemoveFromViewEvent should continue working as always,
the important here is disable event processing while we are refreshing the view.
The side effect is components added to the component tree when view is refreshed
(c:if case) will not receive that event.

If we want to avoid that side effect, the proposal is change
PostBuildRefreshViewEvent to PostBuildViewEvent, this one will be an event
specific for relocation and that one should be published after the view is
build, in other words, in the same place as we are doing
PostBuildRefreshViewEvent but for all cases, but that one requires remove
the register of the listeners to PostAddToViewEvent on h:outputScript and
related. Also, it is necessary to indicate in some way when publish
PostAddToViewEvent/PreRemoveFromViewEvent by facelets algorithm for
build/refresh view, because it is there where we have the knowledge about when
propagate it or not.

I think at this point it is clear the problem and the possible direction to
solve it.



 Comments   
Comment by Ed Burns [ 19/May/10 ]

P2 for 2.0 Rev a.

Comment by Ed Burns [ 24/May/10 ]

New behavior. Move to 2.1

Comment by Ed Burns [ 01/Jun/10 ]

Add adf keyword

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

edburns

Comment by Ed Burns [ 24/Jun/10 ]

GlassFish 3.1 M6 at the latest.

Comment by Ed Burns [ 24/Jun/10 ]

ADF issues targeted at GlassFish 3.1 M5

Comment by Ed Burns [ 01/Nov/10 ]

Fixed

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-777] Define API to allow pluggable Facelet cache management Created: 25/Mar/10  Updated: 09/Jan/15  Resolved: 25/Oct/10

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: 2.0
Fix Version/s: 2.1

Type: New Feature Priority: Major
Reporter: aschwart Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Attachments: Text File changebundle.txt     Zip Archive i777-newfiles.zip     Text File i777.patch    
Issue Links:
Dependency
blocks JAVASERVERFACES_SPEC_PUBLIC-1121 FaceletCache: some caching is incorre... Open
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1346 Parties that decorate FaceletCacheFac... Resolved
Issuezilla Id: 777
Status Whiteboard:

size_small importance_large

Tags: adf, changelog_2_1

 Description   

The JSF2 Facelets API provides applications/frameworks with control over how Facelets files are
located/loaded via the javax.faces.view.facelets.ResourceResolver. We leverage this API to allow loading
of user-specific, personalized/customized Facelets files from an external source (eg. from a rdbms).

While ResourceResolver allows us to load these user-specific views, we run into scalability problems
due to the default caching strategy for Facelet objects. In particular, DefaultFaceletFactory (now an
internal/implementation class) caches all Facelet objects forever. This does not work for our use case.
We need the ability to prune user-specific Facelet objects from the cache in response to application
activity.

Logging this issue to request that we expose a new API that allows applications/frameworks to control
Facelet object caching behavior.



 Comments   
Comment by Ed Burns [ 17/May/10 ]

Move to 2.1

Comment by Ed Burns [ 01/Jun/10 ]

Add adf keyword

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

edburns

Comment by Ed Burns [ 24/Jun/10 ]

GlassFish 3.1 M6 at the latest.

Comment by Ed Burns [ 24/Jun/10 ]

ADF issues targeted at GlassFish 3.1 M5

Comment by Ed Burns [ 19/Jul/10 ]

See https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1592 for ideas on how to solve this one.

Comment by Ed Burns [ 07/Sep/10 ]

After discussion with Max Starets, I am uploading a revised zip of the new and
modified files for the spec API for this issue.

Comment by Ed Burns [ 07/Sep/10 ]

Created an attachment (id=278)
Proposed API for this issue, second iteration. Will send to Expert Community

Comment by Ed Burns [ 08/Sep/10 ]

Created an attachment (id=279)
Fix for this bug, second iteration

Comment by Ed Burns [ 09/Sep/10 ]

Committed revision 8601.

Comment by Ed Burns [ 13/Sep/10 ]

add changelog_2_1 keyword

Comment by Ed Burns [ 13/Sep/10 ]

Update status for JCP ChangeLog.

Comment by Ed Burns [ 20/Sep/10 ]

Ensure changelog_2_1 is in keywords list

Comment by Ed Burns [ 23/Oct/10 ]

Created an attachment (id=315)
Spec language

Comment by Ed Burns [ 25/Oct/10 ]

Committed revision 8681.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-719] Need method to map viewId to resource path Created: 11/Jan/10  Updated: 01/Nov/12  Resolved: 01/Nov/12

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Resources
Affects Version/s: 2.0
Fix Version/s: 2.2 Sprint 11 B

Type: Improvement Priority: Major
Reporter: daschneider Assignee: Ed Burns
Resolution: Fixed Votes: 13
Labels: None
Remaining Estimate: 3 days
Time Spent: Not Specified
Original Estimate: 3 days
Environment:

Operating System: All
Platform: All


Attachments: Text File 20120307-0002-i_spec_719_snapshot.patch     Text File 20120309-0034-i_spec_719.patch     Text File changebundle.txt    
Issue Links:
Dependency
blocks JAVASERVERFACES_SPEC_PUBLIC-809 Simplify external view loading requir... Closed
Related
is related to JAVASERVERFACES-2401 Regression: Resolving resources via E... Closed
Issuezilla Id: 719
Status Whiteboard:

cat2 frame size_medium importance_medium

Tags: adf, adf_high

 Description   

The current JSF specification does not provide a standard plugable mechanism for
mapping a viewId to the resource path for the resource that will render the
view. Although the specification doesn't state that the requested viewId be
literally the resource path of the VDL document some parts of the RI assume this
with code similar to:

String viewId = FacesContext.getViewRoot().getViewId();
Object resource = externalContext.getResource(viewId);

This breaks applications that want to have some type of indirection or mapping
between viewIds and physical resources (e.g. viewId "/x/y/z" is rendered using
document "/a/b/foo.jspx").

Apache Trinidad solves this problem with a plugable interface called a
PageResolver (see
http://myfaces.apache.org/trinidad/trinidad-api/apidocs/index.html). This may
server as an model for how to provide this capability in the standard.



 Comments   
Comment by Ed Burns [ 04/Mar/10 ]

cat2

Comment by Ed Burns [ 22/Mar/10 ]

frame

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by sheetalv [ 10/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

edburns

Comment by Ed Burns [ 24/Jun/10 ]

Change target milestone.

Comment by Ed Burns [ 06/Jul/10 ]

Move back to GlassFish 3.1 M4

Comment by Ed Burns [ 22/Jul/10 ]

Put ADF stuff in keywords, not status_whiteboard

Comment by Ed Burns [ 10/Aug/10 ]

Per 20100810 scrum, move to M5

Comment by Ed Burns [ 01/Nov/10 ]

Move to 2.2.

Comment by Ed Burns [ 24/Feb/12 ]

Issue JAVASERVERFACES_SPEC_PUBLIC-719 asks for something like Apache
Trinidad PageResolver to be added to the JSF 2.2 spec. This issue is
linked to JAVASERVERFACES_SPEC_PUBLIC-809. I'm trying to discover how
best to proceed on these two linked issues and I think the key lies in
re-learning how we use ExternalContext.getResource().

Here are the usages that I have discovered thus far:

Usage1: During RestoreViewPhase when trying to load a page to get its
<f:metadata> section.

Usage2: When trying to render a button whose action uses conditional
navigation.

Usage3: When trying to get the viewId on an initial page request.

Usage4: When trying to serve up a resource request from the filesystem.

Usage5: When trying to find a ScriptComponent Resource for a Composite
Component.

Usage6: When trying to render out the markup for a stylesheet reference
in the HEAD.

There may be others, possibly from the application space as well.

Both 719 and 809 want some kind of API to allow loading resources.
Before proceeding, I want to get people to weigh in to say that the
existing API, decorating the ExternalContext and overriding
getResource(), is not sufficient. Why is it not sufficient?

Comment by Ed Burns [ 07/Mar/12 ]

snapshot

Comment by Ed Burns [ 07/Mar/12 ]

Sending jsf-ri/src/main/java/com/sun/faces/application/ApplicationAssociate.java
Sending jsf-ri/src/main/java/com/sun/faces/application/resource/ClasspathResourceHelper.java
Adding jsf-ri/src/main/java/com/sun/faces/application/resource/ClientResourceInfo.java
Adding jsf-ri/src/main/java/com/sun/faces/application/resource/FaceletResourceHelper.java
Adding jsf-ri/src/main/java/com/sun/faces/application/resource/FaceletResourceInfo.java
Adding jsf-ri/src/main/java/com/sun/faces/application/resource/Resource.java
Sending jsf-ri/src/main/java/com/sun/faces/application/resource/ResourceHelper.java
Sending jsf-ri/src/main/java/com/sun/faces/application/resource/ResourceImpl.java
Sending jsf-ri/src/main/java/com/sun/faces/application/resource/ResourceInfo.java
Sending jsf-ri/src/main/java/com/sun/faces/application/resource/ResourceManager.java
Sending jsf-ri/src/main/java/com/sun/faces/application/resource/WebappResourceHelper.java
Sending jsf-ri/src/main/java/com/sun/faces/facelets/impl/DefaultResourceResolver.java
Deleting jsf-ri/src/main/java/com/sun/faces/facelets/util/Resource.java
Sending jsf-ri/test/com/sun/faces/application/resource/TestResourceManager.java
Transmitting file data .............
Committed revision 9748.

Comment by Ed Burns [ 09/Mar/12 ]

Sending jsf-api/src/main/java/javax/faces/application/ResourceHandler.java
Sending jsf-ri/build-tests.xml
Adding jsf-ri/src/main/java/com/sun/faces/application/resource/FaceletLibraryInfo.java
Sending jsf-ri/src/main/java/com/sun/faces/application/resource/FaceletResourceHelper.java
Sending jsf-ri/src/main/java/com/sun/faces/application/resource/ResourceManager.java
Sending jsf-ri/src/main/java/com/sun/faces/facelets/impl/DefaultResourceResolver.java
Sending jsf-ri/systest/build.xml
Sending jsf-ri/systest/web/ajax/ajaxEcho.xhtml
Sending jsf-ri/test/com/sun/faces/application/resource/TestResourceHandlerImpl.java
Sending jsf-ri/test/com/sun/faces/application/resource/TestResourceImpl.java
Sending jsf-ri/test/com/sun/faces/application/resource/TestResourceManager.java
Deleting jsf-ri/web/test/resources/nvLibrary/images
Adding (bin) jsf-ri/web/test/root-duke.gif
Adding jsf-ri/web/test/rootLibrary
Adding (bin) jsf-ri/web/test/rootLibrary/rootLibrary-duke.gif
Transmitting file data .............
Committed revision 9752.

Comment by Ed Burns [ 09/Mar/12 ]

Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-719
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-719/build.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-719/i_spec_719_old_resource_resolver_war
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-719/i_spec_719_old_resource_resolver_war/pom.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-719/i_spec_719_old_resource_resolver_war/src
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-719/i_spec_719_old_resource_resolver_war/src/main
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-719/i_spec_719_old_resource_resolver_war/src/main/java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-719/i_spec_719_old_resource_resolver_war/src/main/java/com
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-719/i_spec_719_old_resource_resolver_war/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-719/i_spec_719_old_resource_resolver_war/src/main/java/com/sun/faces
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-719/i_spec_719_old_resource_resolver_war/src/main/java/com/sun/faces/test
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-719/i_spec_719_old_resource_resolver_war/src/main/java/com/sun/faces/test/i_spec_719_old_resource_resolver_war
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-719/i_spec_719_old_resource_resolver_war/src/main/java/com/sun/faces/test/i_spec_719_old_resource_resolver_war/MyResourceResolver.java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-719/i_spec_719_old_resource_resolver_war/src/main/java/com/sun/faces/test/i_spec_719_old_resource_resolver_war/Resource.java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-719/i_spec_719_old_resource_resolver_war/src/main/resources
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-719/i_spec_719_old_resource_resolver_war/src/main/webapp
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-719/i_spec_719_old_resource_resolver_war/src/main/webapp/WEB-INF
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-719/i_spec_719_old_resource_resolver_war/src/main/webapp/WEB-INF/beans.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-719/i_spec_719_old_resource_resolver_war/src/main/webapp/WEB-INF/web.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-719/i_spec_719_old_resource_resolver_war/src/main/webapp/i_spec_719_old_resource_resolver.xhtml
Sending jsf-test/build.xml
Transmitting file data ........
Committed revision 9753.

Comment by Ed Burns [ 09/Mar/12 ]

Sending jsf-api/src/main/java/javax/faces/application/ResourceHandler.java
Sending jsf-api/src/main/java/javax/faces/application/ResourceHandlerWrapper.java
Sending jsf-api/src/main/java/javax/faces/view/ViewDeclarationLanguage.java
Sending jsf-api/src/main/java/javax/faces/view/facelets/FaceletFactory.java
Sending jsf-api/src/main/java/javax/faces/view/facelets/FaceletFactoryWrapper.java
Sending jsf-api/src/main/java/javax/faces/view/facelets/ResourceResolver.java
Sending jsf-ri/src/main/java/com/sun/faces/application/resource/ResourceHandlerImpl.java
Sending jsf-ri/src/main/java/com/sun/faces/application/view/FaceletViewHandlingStrategy.java
Sending jsf-ri/src/main/java/com/sun/faces/facelets/impl/DefaultFaceletFactory.java
Sending jsf-ri/src/main/java/com/sun/faces/facelets/impl/DefaultResourceResolver.java
Transmitting file data ..........
Committed revision 9755.

Comment by dougd [ 02/Apr/12 ]

It appears that there is a side effect with the fix on this issue.

The code that appears to be causing the failures is below. What it looks like to me is that if toStream is not an instanceof ClientResourceInfo we just end up going off into the weeds.

public InputStream getInputStream(ResourceInfo toStream, FacesContext ctx)
throws IOException {

// PENDING(edburns): this is a sub-optimal implementation choice
// done in the interest of prototyping. It's never a good idea
// to do a switch statement based on the type of an object.

InputStream in = null;

if (toStream instanceof ClientResourceInfo) {
ClientResourceInfo resource = (ClientResourceInfo) toStream;

in = getInputStreamFromClientInfo(resource, ctx);
if (null == in) {
ClientResourceInfo resourceWithoutLocalePrefix =
new ClientResourceInfo(resource, false);
in = getInputStreamFromClientInfo(resourceWithoutLocalePrefix, ctx);
if (null != in)

{ resource.copy(resourceWithoutLocalePrefix); }

}

} else

{ // PENDING(edburns): get the input stream from the facelet ResourceInfo. <------- "Offending Code" }

return in;

}

Comment by Ed Burns [ 05/Apr/12 ]

http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1085 http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-719

SECTION: 1085 changes
----------------------------

M jsf-api/src/main/java/javax/faces/context/ExternalContext.java

  • Specify support for httpOnly.

M jsf-ri/src/main/java/com/sun/faces/context/ExternalContextImpl.java

  • implement new spec requirement.

A test/agnostic/externalContext
A test/agnostic/externalContext/basic
A test/agnostic/externalContext/basic/nbactions.xml
A test/agnostic/externalContext/basic/src
A test/agnostic/externalContext/basic/src/test
A test/agnostic/externalContext/basic/src/test/java
A test/agnostic/externalContext/basic/src/test/java/com
A test/agnostic/externalContext/basic/src/test/java/com/sun
A test/agnostic/externalContext/basic/src/test/java/com/sun/faces
A test/agnostic/externalContext/basic/src/test/java/com/sun/faces/test
A test/agnostic/externalContext/basic/src/test/java/com/sun/faces/test/agnostic
A test/agnostic/externalContext/basic/src/test/java/com/sun/faces/test/agnostic/externalContext
A test/agnostic/externalContext/basic/src/test/java/com/sun/faces/test/agnostic/externalContext/basic
A test/agnostic/externalContext/basic/src/test/java/com/sun/faces/test/agnostic/externalContext/basic/CookieIT.java
A test/agnostic/externalContext/basic/src/main
A test/agnostic/externalContext/basic/src/main/java
A test/agnostic/externalContext/basic/src/main/java/com
A test/agnostic/externalContext/basic/src/main/java/com/sun
A test/agnostic/externalContext/basic/src/main/java/com/sun/faces
A test/agnostic/externalContext/basic/src/main/java/com/sun/faces/test
A test/agnostic/externalContext/basic/src/main/java/com/sun/faces/test/agnostic
A test/agnostic/externalContext/basic/src/main/java/com/sun/faces/test/agnostic/externalContext
A test/agnostic/externalContext/basic/src/main/java/com/sun/faces/test/agnostic/externalContext/basic
A test/agnostic/externalContext/basic/src/main/java/com/sun/faces/test/agnostic/externalContext/basic/Bean.java
A test/agnostic/externalContext/basic/src/main/resources
A test/agnostic/externalContext/basic/src/main/resources/META-INF
A test/agnostic/externalContext/basic/src/main/resources/META-INF/services
A test/agnostic/externalContext/basic/src/main/webapp
A test/agnostic/externalContext/basic/src/main/webapp/index.xhtml
A test/agnostic/externalContext/basic/src/main/webapp/WEB-INF
A test/agnostic/externalContext/basic/src/main/webapp/WEB-INF/beans.xml
A test/agnostic/externalContext/basic/src/main/webapp/WEB-INF/web.xml
A test/agnostic/externalContext/basic/pom.xml
A test/agnostic/externalContext/pom.xml
A test/util/src/main/java/com/sun/faces/test/util/HttpUtils.java

  • I was forced to test this using the new system because Cactus doesn't
    support the new cookie methods introduced in Servlet 3.0.

SECTION: 719 changes
----------------------------

M jsf-ri/src/main/java/com/sun/faces/application/resource/ClasspathResourceHelper.java

  • No test for this one because the TCK test has it. I plan to copy the
    intent of the TCK test, though.

SECTION: Build changes
----------------------

M jsf-ri/systest/build-tests.xml
A test/agnostic/renderKit
A test/agnostic/renderKit/basic
A test/agnostic/renderKit/basic/nbactions.xml
A test/agnostic/renderKit/basic/src
A test/agnostic/renderKit/basic/src/test
A test/agnostic/renderKit/basic/src/test/java
A test/agnostic/renderKit/basic/src/test/java/com
A test/agnostic/renderKit/basic/src/test/java/com/sun
A test/agnostic/renderKit/basic/src/test/java/com/sun/faces
A test/agnostic/renderKit/basic/src/test/java/com/sun/faces/test
A test/agnostic/renderKit/basic/src/test/java/com/sun/faces/test/agnostic
A test/agnostic/renderKit/basic/src/test/java/com/sun/faces/test/agnostic/renderKit
A test/agnostic/renderKit/basic/src/test/java/com/sun/faces/test/agnostic/renderKit/basic
A test/agnostic/renderKit/basic/src/test/java/com/sun/faces/test/agnostic/renderKit/basic/CustomRenderKitIT.java
A test/agnostic/renderKit/basic/src/main
A test/agnostic/renderKit/basic/src/main/java
A test/agnostic/renderKit/basic/src/main/java/com
A test/agnostic/renderKit/basic/src/main/java/com/sun
A test/agnostic/renderKit/basic/src/main/java/com/sun/faces
A test/agnostic/renderKit/basic/src/main/java/com/sun/faces/test
A test/agnostic/renderKit/basic/src/main/java/com/sun/faces/test/render
A + test/agnostic/renderKit/basic/src/main/java/com/sun/faces/test/render/ButtonRenderer.java
A + test/agnostic/renderKit/basic/src/main/java/com/sun/faces/test/render/CustomRenderKitImpl.java
A + test/agnostic/renderKit/basic/src/main/java/com/sun/faces/test/render/CustomResponseWriter.java
A + test/agnostic/renderKit/basic/src/main/java/com/sun/faces/test/render/FormRenderer.java
A + test/agnostic/renderKit/basic/src/main/java/com/sun/faces/test/render/TextRenderer.java
A test/agnostic/renderKit/basic/src/main/webapp
A + test/agnostic/renderKit/basic/src/main/webapp/renderkit03.jsp
A + test/agnostic/renderKit/basic/src/main/webapp/renderkit03A.jsp
A test/agnostic/renderKit/basic/src/main/webapp/WEB-INF
A test/agnostic/renderKit/basic/src/main/webapp/WEB-INF/faces-config.xml
A test/agnostic/renderKit/basic/src/main/webapp/WEB-INF/beans.xml
A test/agnostic/renderKit/basic/src/main/webapp/WEB-INF/web.xml
A test/agnostic/renderKit/basic/pom.xml
A test/agnostic/renderKit/pom.xml
D jsf-ri/systest/web/renderkit03.jsp
D jsf-ri/systest/web/renderkit03A.jsp

  • remove troublesome test testrenderkit03, move it over to the new system.

This reduces the test count by two on the old side, but increases it
by one on the new side.

M test/agnostic/pom.xml

  • add two new modules:

+ <module>externalContext</module>
+ <module>renderKit</module>

M test/pom.xml

  • Move util to the top. Manfred said it wasn't necessary, but I observed it was.

SECTION: 730 changes

M jsf-api/src/main/java/javax/faces/flow/Flow.java

  • Make this serializable.

Sending jsf-api/src/main/java/javax/faces/context/ExternalContext.java
Sending jsf-api/src/main/java/javax/faces/flow/Flow.java
Sending jsf-ri/build-tests.xml
Sending jsf-ri/src/main/java/com/sun/faces/application/resource/ClasspathResourceHelper.java
Sending jsf-ri/src/main/java/com/sun/faces/context/ExternalContextImpl.java
Sending jsf-ri/systest/build-tests.xml
Deleting jsf-ri/systest/web/renderkit03.jsp
Deleting jsf-ri/systest/web/renderkit03A.jsp
Adding test/agnostic/externalContext
Adding test/agnostic/externalContext/basic
Adding test/agnostic/externalContext/basic/nbactions.xml
Adding test/agnostic/externalContext/basic/pom.xml
Adding test/agnostic/externalContext/basic/src
Adding test/agnostic/externalContext/basic/src/main
Adding test/agnostic/externalContext/basic/src/main/java
Adding test/agnostic/externalContext/basic/src/main/java/com
Adding test/agnostic/externalContext/basic/src/main/java/com/sun
Adding test/agnostic/externalContext/basic/src/main/java/com/sun/faces
Adding test/agnostic/externalContext/basic/src/main/java/com/sun/faces/test
Adding test/agnostic/externalContext/basic/src/main/java/com/sun/faces/test/agnostic
Adding test/agnostic/externalContext/basic/src/main/java/com/sun/faces/test/agnostic/externalContext
Adding test/agnostic/externalContext/basic/src/main/java/com/sun/faces/test/agnostic/externalContext/basic
Adding test/agnostic/externalContext/basic/src/main/java/com/sun/faces/test/agnostic/externalContext/basic/Bean.java
Adding test/agnostic/externalContext/basic/src/main/resources
Adding test/agnostic/externalContext/basic/src/main/resources/META-INF
Adding test/agnostic/externalContext/basic/src/main/resources/META-INF/services
Adding test/agnostic/externalContext/basic/src/main/webapp
Adding test/agnostic/externalContext/basic/src/main/webapp/WEB-INF
Adding test/agnostic/externalContext/basic/src/main/webapp/WEB-INF/beans.xml
Adding test/agnostic/externalContext/basic/src/main/webapp/WEB-INF/web.xml
Adding test/agnostic/externalContext/basic/src/main/webapp/index.xhtml
Adding test/agnostic/externalContext/basic/src/test
Adding test/agnostic/externalContext/basic/src/test/java
Adding test/agnostic/externalContext/basic/src/test/java/com
Adding test/agnostic/externalContext/basic/src/test/java/com/sun
Adding test/agnostic/externalContext/basic/src/test/java/com/sun/faces
Adding test/agnostic/externalContext/basic/src/test/java/com/sun/faces/test
Adding test/agnostic/externalContext/basic/src/test/java/com/sun/faces/test/agnostic
Adding test/agnostic/externalContext/basic/src/test/java/com/sun/faces/test/agnostic/externalContext
Adding test/agnostic/externalContext/basic/src/test/java/com/sun/faces/test/agnostic/externalContext/basic
Adding test/agnostic/externalContext/basic/src/test/java/com/sun/faces/test/agnostic/externalContext/basic/CookieIT.java
Adding test/agnostic/externalContext/pom.xml
Sending test/agnostic/pom.xml
Adding test/agnostic/renderKit
Adding test/agnostic/renderKit/basic
Adding test/agnostic/renderKit/basic/nbactions.xml
Adding test/agnostic/renderKit/basic/pom.xml
Adding test/agnostic/renderKit/basic/src
Adding test/agnostic/renderKit/basic/src/main
Adding test/agnostic/renderKit/basic/src/main/java
Adding test/agnostic/renderKit/basic/src/main/java/com
Adding test/agnostic/renderKit/basic/src/main/java/com/sun
Adding test/agnostic/renderKit/basic/src/main/java/com/sun/faces
Adding test/agnostic/renderKit/basic/src/main/java/com/sun/faces/test
Adding test/agnostic/renderKit/basic/src/main/java/com/sun/faces/test/render
Adding test/agnostic/renderKit/basic/src/main/java/com/sun/faces/test/render/ButtonRenderer.java
Adding test/agnostic/renderKit/basic/src/main/java/com/sun/faces/test/render/CustomRenderKitImpl.java
Adding test/agnostic/renderKit/basic/src/main/java/com/sun/faces/test/render/CustomResponseWriter.java
Adding test/agnostic/renderKit/basic/src/main/java/com/sun/faces/test/render/FormRenderer.java
Adding test/agnostic/renderKit/basic/src/main/java/com/sun/faces/test/render/TextRenderer.java
Adding test/agnostic/renderKit/basic/src/main/webapp
Adding test/agnostic/renderKit/basic/src/main/webapp/WEB-INF
Adding test/agnostic/renderKit/basic/src/main/webapp/WEB-INF/beans.xml
Adding test/agnostic/renderKit/basic/src/main/webapp/WEB-INF/faces-config.xml
Adding test/agnostic/renderKit/basic/src/main/webapp/WEB-INF/web.xml
Adding test/agnostic/renderKit/basic/src/main/webapp/renderkit03.jsp
Adding test/agnostic/renderKit/basic/src/main/webapp/renderkit03A.jsp
Adding test/agnostic/renderKit/basic/src/test
Adding test/agnostic/renderKit/basic/src/test/java
Adding test/agnostic/renderKit/basic/src/test/java/com
Adding test/agnostic/renderKit/basic/src/test/java/com/sun
Adding test/agnostic/renderKit/basic/src/test/java/com/sun/faces
Adding test/agnostic/renderKit/basic/src/test/java/com/sun/faces/test
Adding test/agnostic/renderKit/basic/src/test/java/com/sun/faces/test/agnostic
Adding test/agnostic/renderKit/basic/src/test/java/com/sun/faces/test/agnostic/renderKit
Adding test/agnostic/renderKit/basic/src/test/java/com/sun/faces/test/agnostic/renderKit/basic
Adding test/agnostic/renderKit/basic/src/test/java/com/sun/faces/test/agnostic/renderKit/basic/CustomRenderKitIT.java
Adding test/agnostic/renderKit/pom.xml
Sending test/pom.xml
Adding test/util/src/main/java/com/sun/faces/test/util/HttpUtils.java
Transmitting file data .............................
Committed revision 9794.

Comment by rogerk [ 03/May/12 ]

This fix caused a regression. See: http://java.net/jira/browse/JAVASERVERFACES-2401

Comment by rogerk [ 03/May/12 ]

Specifically, it was trunk commit revision 9752 that caused the regression.

Comment by Ed Burns [ 01/Nov/12 ]

Re-closing this because I have created JAVASERVERFACES_SPEC_PUBLIC-1141 to cover the specific case mentioned in JAVASERVERFACES-2401.





[JAVASERVERFACES_SPEC_PUBLIC-696] Option to suppress xml declaration in Facelets Created: 11/Dec/09  Updated: 01/Aug/14  Resolved: 03/Nov/10

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: 2.0
Fix Version/s: 2.1

Type: Bug Priority: Blocker
Reporter: mojavelinux Assignee: rogerk
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File changebundle.txt    
Issuezilla Id: 696
Status Whiteboard:

size_large importance_large

Tags: adf, changelog_2_1

 Description   

The XML declaration is added to the Facelets template to make the tooling happy,
but Facelets allows this markup to pass straight through the browser. The
problem is that there are certain browsers which choke (or behave differently)
when the XML declaration is included in the rendered response.

The XML declaration really has no business being in the rendered output, so the
best approach is to have Facelets suppress this markup. But if there are
developers who prefer it, perhaps because they are using Facelets to generate an
XML feed, then there should be a setting somewhere that allows them to control
the terminus of the declaration (either suppressed or passed through). This is
no different than the "omitXmlDeclaration" setting on most XML printers,
including XSLT.

What's odd is that Facelets does not pass through the DTD declaration, which is
arguably even more of a problem. However, there is an easy workaround. Simply
include a DTD-generating tag.



 Comments   
Comment by mojavelinux [ 11/Dec/09 ]

Target milestone.

Comment by mojavelinux [ 11/Dec/09 ]

Also, the same problem exists for CDATA.

We (quoting Andy Schwartz) run into similar problems with CDATA sections. For
example, the following code uses the Trinidad trh:script component to insert a
script into the page:

<trh:script>
<![CDATA[
if (0 < 1) alert("Woohoo! Zero is less than one!");
]]>
</trh:script>

The CDATA section is meant to apply to the Facelets page itself - not to the
generated content. That is, the CDATA section provides a way to tell the
Facelets parser not to parse the specified character data. This is not intended
to be used as an instruction to the browser (just to Facelets XML parser).
However, Facelets passes the CDATA through to the browser. As a result, in the
case where we render HTML content, we end up with bogus CDATA sections inside of
our generated HTML document, which causes the browsers to get confused.

Comment by driscoll [ 11/Dec/09 ]

Unforunately, unlike the xml declaration (which you'll almost always want to
leave off, thanks MS), CDATA is something that you'll often want to include in
your page.

In fact, CDATA is something that users may want to include in the page sent to
the browser in the same page as a CDATA block that they don't want to send to
the browser. Ick.

In the specific case mentioned, the Trinidad script component, it should be
possible for the component to detect and properly process the included text -
that's what Mojarra does for script tags, in fact.

So, I'd love to see a different example, if anyone has one.

Comment by mojavelinux [ 18/Dec/09 ]

Update target milestone to 2.0 Rev a

Comment by Ed Burns [ 04/Mar/10 ]

cat2

Comment by Ed Burns [ 17/May/10 ]

Move to 2.1

Comment by Ed Burns [ 22/Jun/10 ]

edburns

Comment by Ed Burns [ 22/Jun/10 ]

triage

Comment by Ed Burns [ 24/Jun/10 ]

GlassFish 3.1 M6 at the latest.

Comment by Ed Burns [ 24/Jun/10 ]

Move these to M5

Comment by Ed Burns [ 22/Jul/10 ]

Move to M4. Add ADF keyword because it's related to issue 697.

Comment by Ed Burns [ 26/Jul/10 ]

Created an attachment (id=262)
Fix for this bug, first iteration.

Comment by Ed Burns [ 27/Jul/10 ]

Fix checked in. r8517

Comment by Hanspeter Duennenberger [ 27/Jul/10 ]

r=dueni

Comment by Ed Burns [ 13/Sep/10 ]

add changelog_2_1 keyword

Comment by Ed Burns [ 20/Sep/10 ]

Ensure changelog_2_1 is in keywords list

Comment by Ed Burns [ 01/Nov/10 ]

This needs to be removed from the spec in favor of what we have in <facelets-processing>

Comment by Ed Burns [ 01/Nov/10 ]

Roger.

Comment by Ed Burns [ 03/Nov/10 ]

Committed revision 8701.
Rolled this out in favor of what we did on issue 490.

Comment by Ed Burns [ 03/Nov/10 ]

Resolved in issue 490.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-647] Allow file upload via Ajax Created: 08/Oct/09  Updated: 01/Aug/14  Resolved: 08/Jun/10

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Ajax/JavaScript
Affects Version/s: 2.0
Fix Version/s: 2.1

Type: New Feature Priority: Major
Reporter: driscoll Assignee: javaserverfowner
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 647
Status Whiteboard:

cat2 frame

Tags: adf

 Description   

Via iframe, as Trinidad does.



 Comments   
Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by aschwart [ 12/Feb/10 ]

Note that from a spec perspective, I believe that the main issue is that jsf.ajax.response() expects a XHR
object, which it uses to grab the responseXML. However, XHR cannot be used in the multi-part form case
(requires iframe-based postback), and as such no XHR object is available to pass off to jsf.ajax.response().

Comment by Ed Burns [ 04/Mar/10 ]

cat2

Comment by Ed Burns [ 22/Mar/10 ]

frame

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by Ed Burns [ 01/Jun/10 ]

Add adf keyword

Comment by Ed Burns [ 08/Jun/10 ]

duplicate

      • This issue has been marked as a duplicate of 802 ***
Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-636] Clarification of Facelets-only (non-JSP) functionality Created: 24/Sep/09  Updated: 12/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: 2.0
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: aschwart Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Attachments: Text File validator06.jspx    
Issuezilla Id: 636
Status Whiteboard:

cat1 frame size_large importance_large

Tags: adf

 Description   

I would like to see the spec provide more explicit documentation of exactly which new features are not
available in JSP. I sent the following two proposals to the EG list:

1. Let's update the spec to state specifically what functionality (down to the tag/tag library level) is not
supported in JSP.

It is possible that this information is already present, but if not, I would like to see a section that
contains a list of all of the new tags that were added in JSF 2 that are specific to Facelets (ie. not
available in JSP).

2. Let's update the Facelets PDL docs to identify tags that are not present in JSP.

For example, the PDL doc for f:ajax should state that it is not available in JSP.

Regarding #1... I think it is important to have this information available in a centralized location, where
it can be easily found/understood by JSP users. #2 should also help to avoid confusion.



 Comments   
Comment by Ed Burns [ 24/Sep/09 ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete api subcomponent

Comment by rogerk [ 24/Feb/10 ]

Target 2.0 Rev A

Comment by Ed Burns [ 04/Mar/10 ]

cat1

Comment by Ed Burns [ 15/Mar/10 ]

facelets

Comment by Ed Burns [ 15/May/10 ]

These are valid 2.0 Rev a issues

Comment by Ed Burns [ 24/May/10 ]

take ownership.

Comment by Ed Burns [ 02/Jun/10 ]

Please make sure to see issue 1402.

Comment by Ed Burns [ 07/Jun/10 ]

This is not a technically difficult issue, but it is a time consuming one.

I think the best way to do it is empirically. I'm writing an HtmlUnit test suite that exercises the jsp
accessible supported/unsupported status of the big ticket new features in JSF2.

So far it's looking like this:

public void testUnsupportedFeaturesAreUnsupported() throws Exception

{ // These features are not implemented in JSP assert500Response("/faces/jsf2jsp/head-gives-500.jspx"); assert500Response("/faces/jsf2jsp/body-gives-500.jspx"); assert500Response("/faces/jsf2jsp/outputScript-gives-500.jspx"); assert500Response("/faces/jsf2jsp/outputStylesheet-gives-500.jspx"); assert500Response("/faces/jsf2jsp/button-gives-500.jspx"); assert500Response("/faces/jsf2jsp/link-gives-500.jspx"); assert500Response("/faces/jsf2jsp/resource-ELResolver-gives-500.jspx"); assert500Response("/faces/jsf2jsp/ajax-gives-500.jspx"); assert500Response("/faces/jsf2jsp/event-gives-500.jspx"); assert500Response("/faces/jsf2jsp/metadata-gives-500.jspx"); }

public void testSupportedFeaturesAreSupported() throws Exception

{ // These features are implemented in JSP HtmlPage page = getPage("/faces/jsf2jsp/commandButton-parameter-children-gives-hidden- fields.jspx"); HtmlSubmitInput button = (HtmlSubmitInput) page.getElementById("reload"); page = button.click(); String text = page.asText(); assertTrue(text.contains("name01=value01")); assertTrue(text.contains("name02=value02")); page = getPage("/faces/jsf2jsp/resources.jspx"); text = page.asXml(); assertTrue(text.contains("duke.gif")); assertTrue(text.contains("vLibrary")); assertTrue(text.contains("2_01_1")); assert200Response("/faces/jsf2jsp/selectManyJsf2Features.jspx"); Test validatorTest = ValidatorTestCase.suite(); TestResult validatorResult = new TestResult(); validatorTest.run(validatorResult); assertTrue(validatorResult.failureCount() == 0); }
Comment by Ed Burns [ 07/Jun/10 ]

Because this issue is labor intensive, I'm wondering if we should push it to 2.1?

Comment by Ed Burns [ 11/Jun/10 ]

Move to 2.1.

Comment by Ed Burns [ 11/Jun/10 ]

Copy this from Neil Griffin's google doc linked from issue 714.

Availability of f:validateBean and f:validateRequired in JSP

Section 10.4 outlines the f: namespaced tags that are only applicable to Facelets (and not JSP). In that
section, f:validateBean, and f:validateRequired are listed. However, they are both listed as working with
JSP as well (kind of like f:validateRegex), as can be seen from the JSP TLDDocs [1].

According to Dan Allen: "those tags only work partially in JSP. Yes, they work as single field validators.
But the branch validator capability does not work (wrapping the validator tag around a branch). The
later feature is Facelets only. So the validators do have their feet in both ponds, but only Facelets has full
support. I suppose we could mention this tidbit in the JSP section."

I agree with Dan that it should be mentoned in the JSP section, but also, that f:validateBean and
f:validateRequired belong in both Section 10.4 and 9.4, with the limits of their functionality described in
each section.

[1] https://javaserverfaces.dev.java.net/nonav/docs/2.0/pdldocs/jsp/index.html

Comment by Ed Burns [ 22/Jun/10 ]

triage

Comment by Ed Burns [ 24/Jun/10 ]

GlassFish 3.1 M6 at the latest.

Comment by Ed Burns [ 24/Jun/10 ]

ADF issues targeted at GlassFish 3.1 M5

Comment by Ed Burns [ 01/Jul/10 ]

Created an attachment (id=248)
jsf-ri/systest/web/validator06.jspx

Comment by Ed Burns [ 08/Jul/10 ]

I discovered that f:viewParam exists in the JSP jsf_core.tld. Does it really work?

Comment by Ed Burns [ 01/Sep/10 ]

Move to m6

Comment by Ed Burns [ 01/Sep/10 ]

Must be done by September 30th.

Comment by Ed Burns [ 10/Sep/10 ]

Move these to 2.2

Comment by Ed Burns [ 13/Sep/10 ]

changelog

Comment by Ed Burns [ 13/Sep/10 ]

remove changelog_2_1 keyword.

Comment by Ed Burns [ 21/Aug/13 ]

The specification of StateManagementStrategy is too tight and needs to be loosened to allow greater flexibility of implementation.

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.





[JAVASERVERFACES_SPEC_PUBLIC-631] Specify target facet name when inserting into composite component Created: 18/Sep/09  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Uncategorized
Affects Version/s: 2.0
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: aschwart Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Attachments: Text File 631-cc-insertFacet-targetName.patch     Zip Archive composite-component-targets-test-2.zip     File composite-component-targets-test.war    
Issuezilla Id: 631
Status Whiteboard:

size_medium importance_medium

Tags: adf

 Description   

As discussed on jsr-314-open...

As currently specified, composite:insertFacet's "name" attribute serves two purposes:

1. It identifies the name of the facet on the containing composite component to insert.
2. It identifies the name of the facet on the target component into which the facet is being inserted.

As a result, the name of the facet exposed by the composite component must match the name of the
facet on the implementation component into which the facet is being inserted. So, for example, if I
have a composite component as follows:

<composite:interface>
<composite:facet name="caption"/>
</composite:interface>

<composite:implementation>
<h:panelGrid>
<composite:insertFacet name="caption"/>
</h:panelGrid>
</composite:implementation>

Everything is happy, since both the composite component and the h:panelGrid expose a "caption" facet.

However, if I want to define a composite component with two h:panelGrid components and two
captions:

<composite:interface>
<composite:facet name="caption"/>
<composite:facet name="backupCaption"/>
</composite:interface>

<composite:implementation>
<h:panelGrid>
<composite:insertFacet name="caption"/>
</h:panelGrid>

<h:panelGrid>
<!-- Uh oh. -->
<composite:insertFacet name="backupCaption"/>
</h:panelGrid>
</composite:implementation>

I am out of luck, since I now have a mismatch between the composite component facet name and the
h:panelGrid facet name.

I think that we could/should solve this in one of two ways:

1. Add an attribute to composite:insertFacet that allows a target facet name to be specified:

<h:panelGrid>
<composite:insertFacet name="backupCaption" targetName="caption"/>
</h:panelGrid>

2. Specify that the target facet name can be picked up from a wrapping <f:facet> tag:

<h:panelGrid>
<f:facet name="caption">
<composite:insertFacet name="backupCaption"/>
</f:facet>
</h:panelGrid>



 Comments   
Comment by Ed Burns [ 24/Sep/09 ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete api subcomponent

Comment by Ed Burns [ 04/Mar/10 ]

Because we now have renderFacet and insertFacet, I'm wondering if this is still valid? Can you re-
open if so?

Comment by aschwart [ 30/Sep/10 ]

I find the insertFacet tag to be useless without this fix. I think that we should address this, perhaps for
2.2.

Comment by Ed Burns [ 30/Sep/10 ]

Don't know how this ended up being assigned to javaserverfowner. I thought we
re-assigned all of those.

Comment by lu4242 [ 27/Oct/10 ]

Created an attachment (id=322)
Patch with solution involving add "targetName" attribute

Comment by lu4242 [ 27/Oct/10 ]

Created an attachment (id=323)
WAR file from test project

Comment by lu4242 [ 27/Oct/10 ]

Created an attachment (id=324)
Test demo using maven. To run type: mvn clean -Djsf=mojarra jetty:run

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by Jakob Korherr [ 31/Oct/10 ]

IMHO it should be targeted for 2.1

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-533] Externalization of application metadata Created: 27/Feb/09  Updated: 15/Mar/13  Resolved: 15/Mar/13

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Configuration/Bootstrapping
Affects Version/s: 2.2 Sprint 8
Fix Version/s: 2.2 Sprint 14

Type: Improvement Priority: Minor
Reporter: daschneider Assignee: Ed Burns
Resolution: Fixed Votes: 12
Labels: None
Σ Remaining Estimate: 1 week, 2 days, 18 hours, 39 minutes Remaining Estimate: 1 week, 2 days, 18 hours, 39 minutes
Σ Time Spent: 5 hours, 21 minutes Time Spent: 5 hours, 21 minutes
Σ Original Estimate: 1 week, 3 days Original Estimate: 1 week, 3 days
Environment:

Operating System: All
Platform: All


Issue Links:
Dependency
blocks JAVASERVERFACES-2509 Implement FacesConfigDocumentPopulato... Closed
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-730 Make flows reusable Closed
Sub-Tasks:
Key
Summary
Type
Status
Assignee
JAVASERVERFACES_SPEC_PUBLIC-421 Configuration at runtime needed Sub-task Open  
Issuezilla Id: 533
Status Whiteboard:

cat2 frame size_large importance_medium

Tags: adf, adf_high

 Description   

The JSF specification defines the format and syntax for files containing the
framework's metadata (e.g. faces-config.xml). The drawback to this is it limits
the ability to reuse the base JSF implementation in a framework that extends it.
A plugable API that allowed metadata to be feed into the base implementation
this would open up a number of doors for extending the base JSF functionality.



 Comments   
Comment by Ed Burns [ 24/Sep/09 ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by rogerk [ 05/Mar/10 ]

cat2

Comment by Ed Burns [ 17/Mar/10 ]

frame

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by Ed Burns [ 01/Feb/12 ]

After thinking about this some more, wouldn't this better be solved at the platform level?

Comment by Ed Burns [ 02/Feb/12 ]

After consulting with a key stakeholder from ADF, I've decided to de-prioritize this, noting that JAVASERVERFACES_SPEC_PUBLIC-730 will likely address most of what's important at this issue.

I'll leave the FixVersion as Unknown, excluding it from consideration for 2.2.

Comment by Ed Burns [ 13/Feb/12 ]

I spoke with David Schneider from ADFc on 20120207. He advised me that a simple specification for this issue would satisfy. Here it is.

Modify the spec so that there's an API that is called exactly once, at startup, that will give an instance of org.w3c.dom.Document when called. This Document will be included in the list of Documents that form the runtime representation of the Application Configuration Resources.

As usual, items specified in WEB-INF/faces-config.xml will take precedence over other items.

Comment by tedgoddard [ 21/Feb/12 ]

If the scope of this feature is reduced to the previous comment: expose a parsed DOM (immutable or cloned for each caller) for each configuration file, it is not controversial and implementation would be straightforward.

Comment by Ed Burns [ 12/Sep/12 ]

Manfred suggested using META-INF/services instead of an annotation. I asked David Schneider about this and he was OK with that approach.

I'll rework this issue to use that approach.

Comment by Ed Burns [ 12/Sep/12 ]

New approach. Simpler to implement.

Comment by Ed Burns [ 15/Mar/13 ]

Andy Schwartz made some suggestions.





[JAVASERVERFACES-3071] javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL doesn't work at all Created: 28/Oct/13  Updated: 04/Dec/14  Resolved: 14/Nov/13

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.2.4
Fix Version/s: 2.2.5

Type: Bug Priority: Major
Reporter: kithouna Assignee: Manfred Riem
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GlassFish 4.0


Attachments: Zip Archive emptystring.zip    
Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1203 Empty String as Null is not effective... Closed
Tags: ADF, INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL, empty, null, string, web-xml

 Description   

javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL in web.xml doesn't work at all with Mojarra 2.2.1 and 2.2.4. I created a very basic test project and ran it on GlassFish 3.1.2.2 with Mojarra 2.1.10 (changed EE version in POM to 6) and it works fine, but using 2.2.1 or 2.2.4 on GlassFish 4.0 (EE version changed to 7) the setter for a text input field is called with an empty string instead of null.



 Comments   
Comment by Manfred Riem [ 28/Oct/13 ]

Please send your reproducer to issues@javaserverfaces.java.net. Thanks!

Comment by Manfred Riem [ 29/Oct/13 ]

From email to issues@javaserverfaces.java.net

https://java.net/jira/browse/JAVASERVERFACES-3071

Just leave the input field empty and press the submit button.

Using Mojarra 2.2.4 I get:

Information: Constructed testcases.emptystring.TestBean@1007b020
Information: Getting string: null
Information: Setting string from null to
Information: Saving string:
Information: Getting string:

It should read (and does with Mojarra 2.1.10 on GF 3.1.2.2, EE versions in POM changed to 6):

Information: Constructed testcases.emptystring.TestBean@1007b020
Information: Getting string: null
Information: Setting string from null to null
Information: Saving string: null
Information: Getting string: null


Alle Postfächer an einem Ort. Jetzt wechseln und E-Mail-Adresse mitnehmen! Rundum glücklich mit freenetMail

Comment by Manfred Riem [ 14/Nov/13 ]

It was determined this is an EL issue and the EL implementation has been fixed to fix this.

Comment by adrianosch [ 27/Feb/14 ]

Where can we find the updated EL impl artifact? I've been searching for it, but '3.0' is the latest version in maven central.

Comment by dbenegiamo [ 09/Apr/14 ]

Hi, Mojarra version 2.2.5 still have this issue. Mandred, could you kindly point to the proper fix? What we have to update instead of Mojarra?

Comment by rekiem87 [ 10/Apr/14 ]

Latest glassfish build (4.0.1) still have the issue, workaround finded in http://stackoverflow.com/questions/21880017/interpret-empty-string-submitted-values-as-null-not-working

Comment by codylerum [ 30/Jul/14 ]

This is a Wildfly 8.1.0.Final issue as well. Does anyone know which EL3 version or UEL issues fixes this?

Comment by codylerum [ 31/Jul/14 ]

This is fixed in EL org.glassfish:javax.el 3.0.1-b05 which is being pulled into wildfly 8.x

Comment by mauromol [ 03/Dec/14 ]

We are in December and javax.el 3.0.1-b05 is not yet available on Maven Central.
Also, the "Won't Fix" on UEL-13 is not encouraging...

Comment by Manfred Riem [ 03/Dec/14 ]

See http://repo1.maven.org/maven2/org/glassfish/javax.el/3.0.1-b05/ which has been available since 7 July 2014

Comment by mauromol [ 03/Dec/14 ]

Hmm... thank you, I was looking at javax.el:javax.el-api, which does not have version 3.0.1-b05.
Anyway, if I understand it correctly, there's nothing I can do with such a library update in my web application unless I change Tomcat's own JAR (also Tomcat 8 seems to suffer from this problem). Am I correct?

Comment by Manfred Riem [ 03/Dec/14 ]

Yes Tomcat would have to patch their EL

Comment by mauromol [ 03/Dec/14 ]

But I doubt they will ever do, since the did the opposite fix:
https://issues.apache.org/bugzilla/show_bug.cgi?id=56522
because of the EL specification has this requirement: EL_SPEC-18
I'm wondering what was fixed in Glassfish implementation: did they go against the specification?

Meanwhile, I really need some kind of workaround for my JSF environment. JAVASERVERFACES_SPEC_PUBLIC-1203 mentions an ELResolver... should I add it to my faces.config.xml inside <el-resolver>? I'm already using a SpringBeanFacesELResolver, does this interfere in some way? (I don't know how {{ELResolver}}s are chained...).
Sorry for asking here, but I already spent a lot of time to try to find out a solution: a converter doesn't do the trick, org.apache.el.parser.COERCE_TO_ZERO=false system property, which is suggested in some StackOverflow questions and blogs, doesn't work in Tomcat 8... I don't know what to do rather than post-process all my beans after a successful submission

Of course, javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is already set to true in web.xml...

Comment by Manfred Riem [ 03/Dec/14 ]

You will have to raise the issue in the EL_SPEC mailing list.

Yes you can add another ELResolver, but the ordering is dependent on your faces-config.xml and the other JARs included.

Comment by mauromol [ 04/Dec/14 ]

Just for the records, a new issue has been filed for Tomcat too, at least to give the chance to override this via a custom EL resolver.
https://issues.apache.org/bugzilla/show_bug.cgi?id=57309





[JAVASERVERFACES-3033] Issue 2494 optimization is not compatible with Trinidad's view root caching Created: 17/Sep/13  Updated: 08/Jan/14  Resolved: 17/Dec/13

Status: Closed
Project: javaserverfaces
Component/s: facelets
Affects Version/s: 2.1.26
Fix Version/s: 2.2.5

Type: Bug Priority: Major
Reporter: aschwart Assignee: Manfred Riem
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on JAVASERVERFACES-3102 Forward port changes from 2.1.20-01 t... Closed
blocks JAVASERVERFACES-3024 UIComponent.isCompositeComponent retu... Closed
Duplicate
is duplicated by JAVASERVERFACES-3059 wrong ids and wrong values after ajax... Closed
Tags: ADF

 Description   

The fix for this issue:

JAVASERVERFACES-2494 JSF page performance degrades significantly as page size increases.
https://java.net/jira/browse/JAVASERVERFACES-2494

Optimizes ComponentSupport.findChildByTagId() by introducing a Map<tagId, component> that is used to locate components via an O(1) lookup instead of via the more expensive component tree walk that was previously used.

However, this fix imposes a new requirement: the Map<tagId, component> must be fully populated prior to re-executing tags in render response.

This map is (primarily) populated in two places: FaceletFullStateManagementStrategy() puts components into the map when visiting them during state restoration. UIComponent.setInView() does the same.

Unfortunately, neither of these mechanisms comes into play when using Trinidad's view root caching optimization.

The view root caching optimization trades off memory for speed: it stores a reference to current component tree in session scope in order to avoid the (time) overhead of restoring the component tree from state on each postback. With this optimization enabled (which is the default for Trinidad-based apps), we do not delegate to FaceletFullStateManagementStrategy and do not call through to setInView().

As a result, the Map<tagId, component> is never populated.

This leads to undesirable behavior during tag re-execution in render response. Since the facelet component map is not populated, ComponentSupport.findChildByTagId() always returns null. In turn, ComponenTagHandlerDelegateImpl always creates new UIComponent instances, even for cases where the component already exists in the component tree.

This causes two problems:

1. Performance: re-creating all components on each postback request is a significant source of new overhead.
2. Functional: re-creating all components on each postback means that we lose any local state held in the previously-created components.

While the performance problem described in JAVASERVERFACES-2494 is clearly a critical problem that needs to be solved, I am opening this issue to request that we revisit the current fix.

I would recommend that we consider implementing a fix using a strategy similar to what we did back in 2010 for the equivalent problem in JSP. See:

JAVASERVERFACES-1620 getChild()/removeOldFacets()/removeOldChildren() exhibit O(n^2) behavior
https://java.net/jira/browse/JAVASERVERFACES-1620

This approach provides a similar performance improvement without imposing any new requirements relating to management/population of a tagId -> component map.



 Comments   
Comment by Manfred Riem [ 22/Oct/13 ]

When fixing this make sure the use case as described in issue #3059 is also verified.

Comment by Manfred Riem [ 17/Dec/13 ]

Fixed in 2.2.5 as a consequence of the forward port





[JAVASERVERFACES-3024] UIComponent.isCompositeComponent returns a wrong value on restoreTree() Created: 10/Sep/13  Updated: 08/Jan/14  Resolved: 26/Dec/13

Status: Closed
Project: javaserverfaces
Component/s: composite components
Affects Version/s: 2.2.2
Fix Version/s: 2.2.5

Type: Bug Priority: Major
Reporter: mysticfall Assignee: Manfred Riem
Resolution: Cannot Reproduce Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on JAVASERVERFACES-3033 Issue 2494 optimization is not compat... Closed
Related
is related to JAVASERVERFACES-3102 Forward port changes from 2.1.20-01 t... Closed
Tags: ADF, composite-component, state

 Description   

I have a composite component which contains a PrimeFaces' Tree component. Problem is, on an Ajax postback request, when partial state saving is disabled, tree nodes in side the tree component got duplicated thus resulting an IllegalArgumentException thrown by com.sun.faces.util.Util.checkIdUniqueness().

Upon a closer look, it boils down to the following cause :

  1. Upon postback, the restore view phase delegates to FaceletFullStateManagementStrategy to restore the component tree.
  2. In FaceletFullStateManagementStrategy.restoreTree() invokes setParent() in the composite UINamingContainer, thus triggers pushComponentToEL.
  3. In pushComponentToEL, it checks to see if it's a composite component but as component's attributes are not restored yet, it returns false and caches the result.
  4. Now, FaceletFullStateManagementStrategy.restoreComponentState() visits the composite component second time, but as the value is already cached it returns false again even though the attributes are now restored.
  5. Failing to recognize it's a composite component, pushComponentToEL does not bind an implicit cc variable to the EL context, which causes the TreeNode's root node to be resolved as null, as it was bind to _# {cc.attrs.node}

    _

  6. In PrimeFaces implementation, the Tree component does not propagate vistTree call to its children when the root node resolves to null.
  7. As the tree nodes are not visited by the FaceletFullStateManagementStrategy, they are missing from ComponentSupport.getFaceletComponentMap() so it creates another copy from the VDL template.

Stacktraces representing above situation are as follows :

(first visit)

	UIComponent.isCompositeComponent(UIComponent) 행: 2112	
	UINamingContainer(UIComponent).pushComponentToEL(FacesContext, UIComponent) 행: 1985	
	UIComponentBase.publishAfterViewEvents(FacesContext, Application, UIComponent) 행: 2244	
	UINamingContainer(UIComponentBase).doPostAddProcessing(FacesContext, UIComponent) 행: 1927	
	UINamingContainer(UIComponentBase).setParent(UIComponent) 행: 447	
	UIComponentBase$ChildrenList.add(UIComponent) 행: 2679	
	UIComponentBase$ChildrenList.add(Object) 행: 2651	
	FaceletFullStateManagementStrategy.restoreTree(FacesContext, String, Object[]) 행: 534	
	FaceletFullStateManagementStrategy.restoreView(FacesContext, String, String) 행: 571	
	StateManagerImpl.restoreView(FacesContext, String, String) 행: 138	
	FaceletViewHandlingStrategy(ViewHandlingStrategy).restoreView(FacesContext, String) 행: 123	
	FaceletViewHandlingStrategy.restoreView(FacesContext, String) 행: 580	
	MultiViewHandler.restoreView(FacesContext, String) 행: 148	
	RestoreViewPhase.execute(FacesContext) 행: 197	
	RestoreViewPhase(Phase).doPhase(FacesContext, Lifecycle, ListIterator<PhaseListener>) 행: 101	
	RestoreViewPhase.doPhase(FacesContext, Lifecycle, ListIterator<PhaseListener>) 행: 121	
	LifecycleImpl.execute(FacesContext) 행: 198	
	FacesServlet.service(ServletRequest, ServletResponse) 행: 646	

(second visit)

	UINamingContainer(UIComponentBase).restoreState(FacesContext, Object) 행: 1591	
	FaceletFullStateManagementStrategy$2.visit(VisitContext, UIComponent) 행: 350	
	FullVisitContext.invokeVisitCallback(UIComponent, VisitCallback) 행: 151	
	UINamingContainer(UIComponent).visitTree(VisitContext, VisitCallback) 행: 1729	
	UINamingContainer.visitTree(VisitContext, VisitCallback) 행: 174	
	HtmlForm(UIComponent).visitTree(VisitContext, VisitCallback) 행: 1740	
	HtmlForm(UIForm).visitTree(VisitContext, VisitCallback) 행: 371	
	HtmlBody(UIComponent).visitTree(VisitContext, VisitCallback) 행: 1740	
	UIViewRoot(UIComponent).visitTree(VisitContext, VisitCallback) 행: 1740	
	FaceletFullStateManagementStrategy.restoreComponentState(FacesContext, HashMap<String,Object>) 행: 335	
	FaceletFullStateManagementStrategy.restoreView(FacesContext, String, String) 행: 586	
	StateManagerImpl.restoreView(FacesContext, String, String) 행: 138	
	FaceletViewHandlingStrategy(ViewHandlingStrategy).restoreView(FacesContext, String) 행: 123	
	FaceletViewHandlingStrategy.restoreView(FacesContext, String) 행: 580	
	MultiViewHandler.restoreView(FacesContext, String) 행: 148	
	RestoreViewPhase.execute(FacesContext) 행: 197	
	RestoreViewPhase(Phase).doPhase(FacesContext, Lifecycle, ListIterator<PhaseListener>) 행: 101	
	RestoreViewPhase.doPhase(FacesContext, Lifecycle, ListIterator<PhaseListener>) 행: 121	
	LifecycleImpl.execute(FacesContext) 행: 198	
	FacesServlet.service(ServletRequest, ServletResponse) 행: 646

It seems that it's been caused by this change :

I'm not sure if it's intended behavior or not. But it seems that either Mojarra or PrimeFaces implementation should be changed in order to support composite component properly.

Could you investigate into this issue please? Thanks!



 Comments   
Comment by Manfred Riem [ 12/Sep/13 ]

Discussion started on dev@javaserverfaces.java.net

Comment by vahid_pashaei [ 03/Dec/13 ]

Hi,

I'm having the same problem.
I dynamically change src attribute of include tag.
I don't have this problem on jsf 2.2.0 but when I up grate my jsf version to 2.2.1 my program throw exception.

Comment by Manfred Riem [ 26/Dec/13 ]

Using the latest 2.2.5-SNAPSHOT I am unable to reproduce this. This was most probably fixed as a consequence of the forward port of JAVASERVERFACES-3102 . Thanks!





[JAVASERVERFACES-2977] Components get rendered twice Created: 01/Aug/13  Updated: 23/Jan/14  Resolved: 27/Dec/13

Status: Closed
Project: javaserverfaces
Component/s: composite components
Affects Version/s: 2.1.22
Fix Version/s: 2.2.5

Type: Bug Priority: Major
Reporter: jscharnow Assignee: Manfred Riem
Resolution: Fixed Votes: 6
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Tomcat 7.0.11, Windows 7


Tags: ADF, adf

 Description   

This problem is observable from 2.1.22 onwards (and is likely related to JAVASERVERFACES-2494). Problem occurs also in 2.2.1.
During render response phase, included composite components may be rendered twice (which leads to duplicate IDs in case fixed IDs are used).
Some background on the scenario:
The application exclusively uses AJAX for navigation/rendering once opened.
The component below renders fine initially (i.e. in the only "ajax-less" case). The problem occurs when it gets rerendered using the AJAX request.
Unfortunately the same component renders also fine in a similar, but less complex use case (~300 JSF components instead of >2500)

Find below some snippets

Simplified composite component implementation dialog.xhtml
[...]
<composite:implementation>
<!-- component implementation start -->
<h:panelGroup id="#

{cc.attrs.cmpId}" layout="block" style="display:none; width: 500px;">
<h:panelGroup id="#{cc.attrs.cmpId}

DlgContent" layout="block">
<composite:insertChildren />
</h:panelGroup>
</h:panelGroup>
<!-- component implementation end -->
</composite:implementation>

[...]

Used with

<ccomp:dialog
cmpId="#

{coreLayoutBean.idYesNoDlg}

"
title="#

{dialogBean.dialogTitle}

"
handler="#

{dialogBean.yesNoDlgHandler}

"
showOkButton="true"
showCancelButton="true"
okText="#

{coretexts.btnYes}

"
cancelText="#

{coretexts.btnNo}

"
width= "350"
openImmediately="true"
>
<h:outputText escape="false" value="#

{dialogBean.yesNoQuestion}

"/>
</ccomp:dialog>

Rendered with 2.1.22 (including error):
[...]
+id: j_idt923
type:
<!-- component implementation start -->

+id: dlgYesNo <===============
type: javax.faces.component.html.HtmlPanelGroup@1d3f905
+id: dlgYesNoDlgContent
type: javax.faces.component.html.HtmlPanelGroup@181c482
+id: j_idt922
type: javax.faces.component.html.HtmlOutputText@1f36a7c
+id: j_idt924
type:
<!-- component implementation end -->

+id: j_idt1368
type:
<!-- component implementation start -->

+id: dlgYesNo <===============
type: javax.faces.component.html.HtmlPanelGroup@18f5954
+id: dlgYesNoDlgContent
type: javax.faces.component.html.HtmlPanelGroup@31b95f
+id: j_idt1369
type:
<!-- component implementation end -->
[...]

Rendered with 2.1.21 (without error):
[...]
+id: j_idt86
type:
<!-- component implementation start -->

+id: dlgYesNo
type: javax.faces.component.html.HtmlPanelGroup@27738
+id: dlgYesNoDlgContent
type: javax.faces.component.html.HtmlPanelGroup@1e12aac
+id: j_idt417
type: javax.faces.component.html.HtmlOutputText@1013415
+id: j_idt87
type:
<!-- component implementation end -->
[...]



 Comments   
Comment by Manfred Riem [ 13/Aug/13 ]

Please send a reproducing example to issues@javaserverfaces.java.net. Thanks!

Comment by jscharnow [ 16/Aug/13 ]

@Manfred:
Unfortunately this occurs only in our complete business application, so I cannot provide a simple example. Is there any hook inside JSF where composite components are added to the tree to debug this?

Comment by josefreire [ 16/Aug/13 ]

We're also having this issue. We're working on a simple example to demonstrate the problem.

Comment by josefreire [ 16/Aug/13 ]

Ok. I've got a simple working example. Will send it to issues@javaserverfaces.java.net within an hour.

It apears that the c:if tag inside a composite component is being silently ignored.

Comment by Ed Burns [ 22/Aug/13 ]

adding adf tag

Comment by jboz [ 23/Oct/13 ]

Hello,

Have you found a solution or a workaround ?
We have the same pb in our enterprise application.
I have tested newer 2.1.x version unsuccessful. The only solution found is to downgrade jsf version (back to 2.1.18 for example).
But this solution is not acceptable.

Comment by tyemykuga [ 28/Nov/13 ]

Hi,

I'm having the same problem on the 2.1.x version.
Have you found a solution or a workaround?

Comment by vahid_pashaei [ 03/Dec/13 ]

Hi,

I'm having the same problem.
I dynamically change src attribute of include tag.
I don't have this problem on jsf 2.2.0 but when I up grate my jsf version to 2.2.1 my program throw exception.

Comment by gus.ehr [ 06/Dec/13 ]

Hi there.

I'm still trying to reproduce it on simple project.
Here we've got a workaround converting a custom panel composite component to a "facelets component".

Comment by jspies [ 20/Dec/13 ]

I also have this issue, it does seem that c:if is not respected in composite components after ajax rendering. I do not have the issue in 2.1.18 but do in 2.1.24

Comment by Manfred Riem [ 27/Dec/13 ]

Unable to reproduce using 2.2.5-SNAPSHOT, most probably as a consequence of the forward port of JAVASERVERFACES-3102

Comment by jspies [ 27/Dec/13 ]

Is this going to be fixed in 2.1.x? We can't update to 2.2 yet but would like the performance benefits of 2.1.22 which we can't use with this issue. Thanks!

Comment by gus.ehr [ 28/Dec/13 ]

I've filled a task to backport this issue to the 2.1.x branch.
Thank you!

Comment by Christoph_W. [ 08/Jan/14 ]

Checked against 2.1.27-SNAPSHOT which fixes the bug also.

Comment by Christoph_W. [ 15/Jan/14 ]

I am sorry, but my check was wrong. This bug still exists in 2.1.27!

Comment by tyemykuga [ 15/Jan/14 ]

Christoph_W, I sent a reproducing example and opened another issue about it: https://java.net/jira/browse/JAVASERVERFACES-3147.

Comment by fischermatte [ 22/Jan/14 ]

any chance the bug is going to be fixed in 2.1.x?

Comment by fischermatte [ 22/Jan/14 ]

due to this issue, we got stucked now at 2.1.21

Comment by gus.ehr [ 23/Jan/14 ]

Hello fischermatte.

We're are discussing about this on issue 3147: https://java.net/jira/browse/JAVASERVERFACES-3147.





[JAVASERVERFACES-2844] ADF Essentials application (ADF Faces, EJB, JPA) fails intermittently in any browser, works ok in Weblogic Created: 10/Apr/13  Updated: 07/Nov/13  Resolved: 07/Nov/13

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: westend Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7, 64 bits. Java EE 6 SDK Update 4 with JDK 7 (with Glassfish 3.1.2.2). JDeveloper 11.1.2.3


Tags: ADF, adf, lifecycle, session

 Description   

Hello,

I have an ADF application developed using ADF Faces, EJB, JPA, in Jdeveloper 11.1.2.3. It works perfectly in the integrated Weblogic.

Then I make the changes in the application, following de recommended steps in http://docs.oracle.com/cd/E35521_01/web.111230/e16182/toc.htm, to deploy it in GlassFish Server v3.1.2.2. with ADF Essentials.

But when executing the application I get the following error intermittently in any browser, getting the following text in the browser:

HTTP Status 500 - ADF_FACES-30179:For more information, please see the server's error log for an entry beginning with: The UIViewRoot is null.
Fatal exception during PhaseId: RESTORE_VIEW 1.
--------------------------------------------------------------------------------

type Status report

messageADF_FACES-30179:For more information, please see the server's error log for an entry beginning with: The UIViewRoot is null.
Fatal exception during PhaseId: RESTORE_VIEW 1.

descriptionThe server encountered an internal error (ADF_FACES-30179:For more information, please see the server's error log for an entry beginning with: The UIViewRoot is null.
Fatal exception during PhaseId: RESTORE_VIEW 1.) that prevented it from fulfilling this request.
--------------------------------------------------------------------------------

GlassFish Server Open Source Edition 3.1.2.2

There seems to be a problem with the session in which it is in a non-closed state but then it contains nothing. Any ideas on what is going on? Any fixes?

Many thanks!!

and in the server log file:
[#|2013-04-10T10:57:38.167+0100|WARNING|glassfish3.1.2|oracle.adfinternal.view.faces.context.RichExceptionHandler|_ThreadID=89;_ThreadName=Thread-2;|ADF_FACES-60098:Faces lifecycle receives unhandled exceptions in phase RESTORE_VIEW 1
oracle.adf.controller.ControllerException: ADFC-00008: Failed to find DataControlFrame for a task flow.
+ at oracle.adfinternal.controller.util.Utils.createAndLogControllerException(Utils.java:212)+
+ at oracle.adfinternal.controller.util.model.DCFrameImpl.makeCurrent(DCFrameImpl.java:137)+
+ at oracle.adfinternal.controller.state.ViewPortContextImpl.makeCurrent(ViewPortContextImpl.java:1038)+
+ at oracle.adfinternal.controller.state.RequestState.setCurrentViewPortContext(RequestState.java:216)+
+ at oracle.adfinternal.controller.state.ControllerState.setRequestState(ControllerState.java:877)+
+ at oracle.adfinternal.controller.state.ControllerState.synchronizeStatePart1(ControllerState.java:376)+
+ at oracle.adfinternal.controller.application.SyncNavigationStateListener.beforePhase(SyncNavigationStateListener.java:219)+
+ at oracle.adfinternal.controller.lifecycle.ADFLifecycleImpl$PagePhaseListenerWrapper.beforePhase(ADFLifecycleImpl.java:550)+
+ at oracle.adfinternal.controller.lifecycle.LifecycleImpl.internalDispatchBeforeEvent(LifecycleImpl.java:100)+
+ at oracle.adfinternal.controller.lifecycle.LifecycleImpl.dispatchBeforePagePhaseEvent(LifecycleImpl.java:147)+
+ at oracle.adfinternal.controller.faces.lifecycle.ADFPhaseListener$PhaseInvokerImpl.dispatchBeforePagePhaseEvent(ADFPhaseListener.java:119)+
+ at oracle.adfinternal.controller.faces.lifecycle.ADFPhaseListener.beforePhase(ADFPhaseListener.java:63)+
+ at oracle.adfinternal.controller.faces.lifecycle.ADFLifecyclePhaseListener.beforePhase(ADFLifecyclePhaseListener.java:44)+
+ at oracle.adfinternal.view.faces.lifecycle.LifecycleImpl._executePhase(LifecycleImpl.java:327)+
+ at oracle.adfinternal.view.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:202)+
+ at javax.faces.webapp.FacesServlet.service(FacesServlet.java:508)+
+ at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1550)+
+ at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)+
+ at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)+
+ at oracle.adf.model.servlet.ADFBindingFilter.doFilter(ADFBindingFilter.java:173)+
+ at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)+
+ at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)+
+ at oracle.adfinternal.view.faces.webapp.rich.RegistrationFilter.doFilter(RegistrationFilter.java:125)+
+ at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl$FilterListChain.doFilter(TrinidadFilterImpl.java:468)+
+ at oracle.adfinternal.view.faces.activedata.AdsFilter.doFilter(AdsFilter.java:60)+
+ at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl$FilterListChain.doFilter(TrinidadFilterImpl.java:468)+
+ at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:293)+
+ at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:199)+
+ at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92)+
+ at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)+
+ at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)+
+ at oracle.adf.library.webapp.LibraryFilter.doFilter(LibraryFilter.java:180)+
+ at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)+
+ at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)+
+ at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)+
+ at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)+
+ at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)+
+ at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)+
+ at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161)+
+ at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:331)+
+ at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)+
+ at com.sun.enterprise.v3.services.impl.ContainerMapper$AdapterCallable.call(ContainerMapper.java:317)+
+ at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)+
+ at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:860)+
+ at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:757)+
+ at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1056)+
+ at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:229)+
+ at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)+
+ at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)+
+ at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)+
+ at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)+
+ at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)+
+ at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)+
+ at com.sun.grizzly.ContextTask.run(ContextTask.java:71)+
+ at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)+
+ at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)+
+ at java.lang.Thread.run(Thread.java:722)+

#]


 Comments   
Comment by Hong Zhang [ 10/Apr/13 ]

As the issue talks about non-closed session, assign to web team for initial evaluation..

Comment by Shing Wai Chan [ 11/Apr/13 ]

Assign to JSF team.

Comment by Manfred Riem [ 12/Apr/13 ]

Can you send a reproducing example to issues@javaserverfaces.java.net?

Comment by westend [ 18/Apr/13 ]

A simple application like the JDeveloper ADF tutorial works fine.

So we are providing the ear file of the application (ftp://ftp.iac.es/out/ADFwestend/catsolar.ear). To deploy it in GlassFish it is necessary to create a JDBC Resource jdbc/catXADS that uses a valid connection pool (that responds to ping, we have used the example HR database)

Once deployed, you access it with localhost:8080/ To reproduce the error you will eventually stumble into it if you click on the language flag icon in the upper right (if you click fast enough!). Using IE you get it earlier.

If you need anything else please ask. TIA!

Comment by Manfred Riem [ 21/May/13 ]

Can you please try it on version 2.1.7-01?

Comment by westend [ 23/May/13 ]

Hi, same error, even removing the WEB-INF/lib/jsf-api.jar and WEB-INF/lib/jsf-impl.jar from the .ear that insistently get deployed with JDeveloper 1.2.4 and substituting them for the javax.faces.jar of 2.1.7-01

Comment by Manfred Riem [ 12/Aug/13 ]

Since this is an issue with ADF essentials have you asked them?

Comment by westend [ 19/Aug/13 ]

we opened an issue in the OTN forums at approximately the same time, but got no response:
https://forums.oracle.com/thread/2525044

Comment by westend [ 03/Sep/13 ]

I'm happy to inform that it has been solved with ADF Essentials 12.1.2 deploying on a Glassfish 3.1.2.2 from JDeveloper 12c. Thanks for the feedback!

Comment by Manfred Riem [ 07/Nov/13 ]

Closing as per reporter





[JAVASERVERFACES-2533] InitFacesContext thread local can leak across applications Created: 09/Oct/12  Updated: 14/Dec/12  Resolved: 14/Dec/12

Status: Closed
Project: javaserverfaces
Component/s: context
Affects Version/s: 2.1.7
Fix Version/s: 2.1.17, 2.2.0-m08

Type: Bug Priority: Major
Reporter: aschwart Assignee: Manfred Riem
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES-2398 Remaining reference to com.sun.faces.... Closed
Tags: ADF

 Description   

We have a test suite that runs against an app server (WLS) that has multiple ear/war files deployed.

The test suite fails sporadically.

The failures typically occur under some servlet other than the FacesServlet - eg. inside of Trinidad's ResourceServlet.

The reason for the failures come down to the fact that FacesContext.getCurrentInstance() is returning an InitFacesContext... but not the InitFacesContext for the current application!

Let's use a simplified example to demonstrate the problem.

We've got 2 JSF-based applications with the following context paths:

  • /app1
  • / app2

Both of these apps also have the Trinidad ResourceServlet mapped to the "/trinidad-resource" servlet path.

When a request of the form:

/app1/trinidad-resource/foo.js

Arrives at app1's ResourceServlet, from time to time we'll see FacesContext.getCurrentInstance() returning app2's InitFacesContext. As a result, app2's ServletContext leaks into app1 and a range of failures can occur.

This problem is a regression related to changes made for:

http://java.net/jira/browse/GLASSFISH-11984
http://java.net/jira/browse/GLASSFISH-15632

In revision 8826 of:

https://svn.java.net/svn/mojarra~svn/branches/MOJARRA_2_1X_ROLLING

This commit removes a key call to InitFacesContext.release() that had previously been made in ConfigureListener.contextInitialized().

Instead, the intention seems to be to allow the InitFacesContext to be cleaned up at the first call to FacesServlet.service().

However, this assumes that FacesService.service() will be called immediately on the same thread after ConfigureListener.contextInitialized() completes.

This is not a valid assumption and leaves open the following path to an InitFacesContext/ServletContext/ThreadLocal leak:

1. Request arrives at /app2/trinidad-resource.
2. app2 is initialized.
3. ConfigureListener.contextInitalized() sets up app2's the InitFacesContext
4. Request completes without hitting the FacesServlet.
5. Thread is returned to the app server's thread pool, with app2's InitFacesContext.
6. A request arrives at /app1/trinidad-resource
7. A thread is pulled from the app server's thread pool to service the request.
8. As luck would have it, this thread happens to have the thread local with app2's InitFacesContext.
9. Some of app1's code calls FacesContext.getCurrentInstance() to grab the FacesContext.
10. app1 now has access to app2's InitFacesContext/ServletContext.
11. Bad things happen.

Given that:

a) There is no guarantee that FacesServlet.service() will be called on the same thread after ConfigureListener.contextInitialized() is called. And...
b) There is no guarantee that the app server will clean up random thread locals before re-using a thread for some other request.

Mojarra need to ensure that it cleans up any thread locals that it sets up before the end of each request. I believe this means that ConfigureListener.contextInitialized() must call release() on the InitFacesContext, as was previously the case before the above fixes were applied.



 Comments   
Comment by Manfred Riem [ 09/Oct/12 ]

Please try this with the 2.1.13 (the latest to date) and let me know if you see the same problem.

Comment by aschwart [ 09/Oct/12 ]

Verified that this reproduces against Mojarra 2.1.13. This is expected given that ConfigureListener.contextInitialized() does not release the InitFacesContext in 2.1.13.

Comment by Manfred Riem [ 14/Dec/12 ]

This is no longer an issue since before any request to a Servlet a request listener now makes sure that no InitFaces context will be active. So FacesContext.getCurrentInstance will now return null if called from outside of the JSF lifecycle.





[JAVASERVERFACES-2395] unnecessary state saved for temporary trees when using partial state saving. Created: 23/Apr/12  Updated: 22/May/12  Resolved: 22/May/12

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.1.7
Fix Version/s: 2.1.9, 2.2.0-m03

Type: Bug Priority: Major
Reporter: gabfest Assignee: Manfred Riem
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 3 days
Original Estimate: Not Specified

Attachments: Text File changebundle.txt     Zip Archive newfiles.zip    
Tags: ADF, performance, state_saving

 Description   

During rendering we sometimes add a subtree, render, then remove the subtree. In full state saving by the time you get to doing state saving the subtree is gone and there's nothing to state save.

Previously in partial state saving if you added a subtree but removed it, the handleRemoveEvent code went through the add list and if the component was in the add list then it removed it from the add list, this way we didn't try to add it during restore view. Here's the old code I'm looking at in StateContext.AddRemoveListener:

private void handleRemoveEvent(FacesContext context,
PreRemoveFromViewEvent event) {

// CODE HERE REMOVED

if (dynamicAdds != null && dynamicAdds.containsKey(clientId))

{ dynamicAdds.remove(clientId); }

// CODE HERE REMOVED
}

I don't see anything similar in the new code, it looks to me like the subtree is state saved and on restore view you try to add/remove the subtree.



 Comments   
Comment by gabfest [ 23/Apr/12 ]

This behavior looks like it was changed as part of the fix for Issue 1826

Comment by Manfred Riem [ 23/Apr/12 ]

If you mark a sub tree as transient it is not tracked for the purposes of dynamic manipulation and as such is also not state saved. Relevant code can be found in the AddRemoveListener.handleAdd and handleRemove. See https://svn.java.net/svn/mojarra~svn/branches/MOJARRA_2_1X_ROLLING/jsf-ri/src/main/java/com/sun/faces/context/StateContext.java

Comment by Manfred Riem [ 22/May/12 ]

Auto pruning of the dynamic adds and removes is done once a dynamic component
is added or removed.





[JAVASERVERFACES-2390] Children component reorder leads to exception and reorder failure Created: 19/Apr/12  Updated: 03/Jul/12  Resolved: 03/Jul/12

Status: Closed
Project: javaserverfaces
Component/s: state saving
Affects Version/s: 2.1.8
Fix Version/s: 2.1.9

Type: Bug Priority: Major
Reporter: prakashudupa Assignee: Manfred Riem
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive Application73.zip    
Tags: ADF, dynamic

 Description   

In Trinidad framework, we have a customization / changeManager feature, one of the subfeatures there is to be able to reorder child components of the same parent. The usecase is a very common Design-time at Run-time feature where the components are reordered inside same container parent by Drag-And-Drop in a canvas. This feature is broken when we are trying to update to Mojarra 2.1.8, so this is a regression from Mojarra 2.1.7 for which we are requesting a fix a.s.a.p.

I have tried to scale down this feature in a simple managed bean code and attached the testcase. All I'm doing in the managed bean is re-ordering children, and expecting that 1. if the component tree state is restored by RI, the new order is restored, or 2. if the jsf page is re-read and tags re-executed, then RI should re-instate the children is in its original index.

To test it, run the 'Trinidad_testpage.jsf' page provided as testcase (note the components are from Trinidad, so you will need to include Trinidad library, you can yourself emulate the behavior in any other component library you wish, since the essense of defect is showcased). In the page, click on the button, this is expected to reorder the two outputText children (you will see this happen fine in 2.1.7). In 2.1.8, instead, the following exception is encountered and the reorder fails.

It seems that RI is calling on the List implementation to add a child at a index greater than zero, at a point when there were no children at all.

Note that
1. The issue happens only for facelets case, not JSP.
2. The issue happens when partial state saving is enabled or disabled.

About the attached testcase:
1. application73.zip is a JDeveloper workspace, if you have JDev installed, it is convenient for you to just run it.
2. If you do not have JDev, then you can extract out / study the code in 'ChangeBeanOne.java' , 'DebugPhaseListener.java', 'Trinidad_testpage.jsf' and it should be easy for you to do the same using any component library / IDE.
3. It is assumed that you would run it first in 2.1.7 to see all is well, and then you can instead use the 2.1.8 jar provided in the zip file to see the issue (in JDev it is easy, you remove the included JSF 2.1 library, and add the included jars as the top entry in class path for the test app)



 Comments   
Comment by prakashudupa [ 19/Apr/12 ]

java.lang.IndexOutOfBoundsException: index:1 size:0
at org.apache.myfaces.trinidad.component.ChildArrayList.add(ChildArrayList.java:47)
at org.apache.myfaces.trinidad.component.ChildArrayList.add(ChildArrayList.java:33)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.adjustIndexOfDynamicChildren(ComponentTagHandlerDelegateImpl.java:239)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:201)
at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184)
at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184)
at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
at oracle.adfinternal.view.faces.facelets.rich.RichDocumentHandler.applyNextHandler(RichDocumentHandler.java:69)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184)
at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
at com.sun.faces.facelets.tag.jsf.core.ViewHandler.apply(ViewHandler.java:164)
at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:86)
at com.sun.faces.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:152)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.buildView(FaceletViewHandlingStrategy.java:774)
at org.apache.myfaces.trinidadinternal.application.ViewDeclarationLanguageFactoryImpl$ChangeApplyingVDLWrapper.buildView(ViewDeclarationLanguageFactoryImpl.java:345)
at oracle.adfinternal.view.faces.lifecycle.ResponseRenderManager._processViewDefinitionLanguage(ResponseRenderManager.java:105)
at oracle.adfinternal.view.faces.lifecycle.ResponseRenderManager.runRenderView(ResponseRenderManager.java:41)
at oracle.adfinternal.view.faces.lifecycle.LifecycleImpl._renderResponse(LifecycleImpl.java:1111)
at oracle.adfinternal.view.faces.lifecycle.LifecycleImpl._executePhase(LifecycleImpl.java:395)
at oracle.adfinternal.view.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:243)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:279)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:253)
at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:135)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:340)
at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:25)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:74)
at oracle.adf.share.http.ServletADFFilter.doFilter(ServletADFFilter.java:65)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:74)
at oracle.adfinternal.view.faces.webapp.rich.RegistrationFilter.doFilter(RegistrationFilter.java:106)
at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl$FilterListChain.doFilter(TrinidadFilterImpl.java:478)
at oracle.adfinternal.view.faces.activedata.AdsFilter.doFilter(AdsFilter.java:60)
at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl$FilterListChain.doFilter(TrinidadFilterImpl.java:478)
at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:303)
at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:208)
at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:74)
at oracle.security.jps.ee.http.JpsAbsFilter$1.run(JpsAbsFilter.java:136)
at java.security.AccessController.doPrivileged(Native Method)
at oracle.security.jps.util.JpsSubject.doAsPrivileged(JpsSubject.java:315)
at oracle.security.jps.ee.util.JpsPlatformUtil.runJaasMode(JpsPlatformUtil.java:440)
at oracle.security.jps.ee.http.JpsAbsFilter.runJaasMode(JpsAbsFilter.java:119)
at oracle.security.jps.ee.http.JpsAbsFilter.doFilter(JpsAbsFilter.java:216)
at oracle.security.jps.ee.http.JpsFilter.doFilter(JpsFilter.java:81)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:74)
at oracle.dms.servlet.DMSServletFilter.doFilter(DMSServletFilter.java:173)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:74)
at weblogic.servlet.internal.RequestEventsFilter.doFilter(RequestEventsFilter.java:27)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:74)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3290)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3256)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
at weblogic.servlet.provider.WlsSubjectHandle.run(WlsSubjectHandle.java:57)
at weblogic.servlet.internal.WebAppServletContext.doSecuredExecute(WebAppServletContext.java:2164)
at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2090)
at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2068)
at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1528)
at weblogic.servlet.provider.ContainerSupportProviderImpl$WlsRequestExecutor.run(ContainerSupportProviderImpl.java:254)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:263)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:222)

Comment by Manfred Riem [ 19/Apr/12 ]

Can you try it tomorrow (4/20/2012) with the latest SNAPSHOT and tell me if you still see the issue?

Comment by prakashudupa [ 19/Apr/12 ]

If you can email me the jsf-api*.jar and jsf-impl*.jar as soon as it is available, I can test it.
If it will be in some location that I can download from, give me the URL.

Comment by Manfred Riem [ 19/Apr/12 ]

The following locations contain the API and Impl jars, please get the one that
is build tonight.

API https://maven.java.net/content/repositories/snapshots/com/sun/faces/jsf-api/
Impl https://maven.java.net/content/repositories/snapshots/com/sun/faces/jsf-impl/

Comment by prakashudupa [ 20/Apr/12 ]

I tested this in today's staged jars, the issue continues to occur there.
For records, here is the manifest of the staged jsf-api-2.1.8.jar, which by time stamp I think indicates yesterday's SNAPSHOT, let me know if it is not.

Implementation-Title: Mojarra
Probe-Provider-Xml-File-Names: META-INF/mojarra-jsf-api-probe-provider
.xml
Tool: Bnd-0.0.249
DSTAMP: 20120419
TODAY: April 19 2012
TSTAMP: 1428
DocName: JavaServer Faces API
Implementation-Vendor: Oracle America, Inc.
Implementation-Vendor-Id: com.sun
Specification-Title: JavaServer Faces
Bundle-License: http://glassfish.java.net/nonav/public/CDDL+GPL.html
LICENSEFILE: /files/hudson/workspace/MOJARRA_2_1X_ROLLING_DEPLOY/MOJAR
RA_2_1X_ROLLING/legal/jsf-cddl/LICENSE.txt
Bundle-SymbolicName: org.glassfish.javax.faces
Extension-Name: javax.faces
Implementation-Version: 2.1.8-
Bundle-Name: JavaServer Faces API 2.1.8 (20120419-1428-)
DynamicImport-Package: org.glassfish.flashlight.provider
Bundle-Version: 2.1.8
Bnd-LastModified: 1334871019926
Bundle-ManifestVersion: 2
Bundle-Description: Mojarra JSF API (javax.faces/2.1) 2.1.8 (20120419-
1428-)
Specification-Version: 2.1
Include-Resource: META-INF=build/classes/META-INF,build/classes
Import-Package: javax.el;version="2.2.1",javax.servlet;version="3.0",j
avax.servlet.http;version="3.0",javax.servlet.jsp;version="2.1",javax
.servlet.jsp.jstl.sql;version="1.2",javax.servlet.jsp.tagext;version=
"2.1",javax.validation;resolution:=optional,javax.validation.groups;r
esolution:=optional
Bundle-DocURL: http://download.oracle.com/javaee/6/api/

Comment by prakashudupa [ 20/Apr/12 ]

Note: This occurred in 2.1.4 and 2.1.8., but not in 2.1.7.

Comment by Manfred Riem [ 30/May/12 ]

Can you verify if it works against the 2.1.8 release or the latest 2.1.9 SNAPSHOT?

Comment by Manfred Riem [ 19/Jun/12 ]

Can you please verify against 2.1.9? Thanks!

Comment by prakashudupa [ 03/Jul/12 ]

I tested this in 2.1.9, the issue appears solved there. Thanks Manfred !!

For records, here is the manifest of the jsf-api-2.1.9.jar, that I used:

Implementation-Title: Mojarra
Probe-Provider-Xml-File-Names: META-INF/mojarra-jsf-api-probe-provider
.xml
Tool: Bnd-0.0.249
DSTAMP: 20120531
TODAY: May 31 2012
TSTAMP: 2113
DocName: JavaServer Faces API
Implementation-Vendor: Oracle America, Inc.
Implementation-Vendor-Id: com.sun
Specification-Title: JavaServer Faces
Bundle-License: http://glassfish.java.net/nonav/public/CDDL+GPL.html
LICENSEFILE: /Users/rkitain/jsf/mojarra/tags/2.1.9/legal/jsf-cddl/LICE
NSE.txt
Bundle-SymbolicName: org.glassfish.javax.faces
Extension-Name: javax.faces
Implementation-Version: 2.1.9-
Bundle-Name: JavaServer Faces API 2.1.9 (20120531-2113-)
DynamicImport-Package: org.glassfish.flashlight.provider
Bundle-Version: 2.1.9
Bnd-LastModified: 1338513251922
Bundle-ManifestVersion: 2
Bundle-Description: Mojarra JSF API (javax.faces/2.1) 2.1.9 (20120531-
2113-)
Specification-Version: 2.1
Include-Resource: META-INF=build/classes/META-INF,build/classes
Import-Package: javax.el;version="2.2.1",javax.servlet;version="3.0",j
avax.servlet.http;version="3.0",javax.servlet.jsp;version="2.1",javax
.servlet.jsp.jstl.sql;version="1.2",javax.servlet.jsp.tagext;version=
"2.1",javax.validation;resolution:=optional,javax.validation.groups;r
esolution:=optional
Bundle-DocURL: http://download.oracle.com/javaee/6/api/





[JAVASERVERFACES-2374] Forward Port Issue 2371 to Trunk Created: 06/Apr/12  Updated: 02/Nov/12  Resolved: 15/May/12

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: None
Fix Version/s: 2.2.0-m03

Type: Bug Priority: Major
Reporter: rogerk Assignee: Manfred Riem
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES-2335 Forward Port System Event Acid Test F... Closed
Tags: ADF, dynamic

 Description   

The fixes for http://java.net/jira/browse/JAVASERVERFACES-2371 need to be forward ported to trunk.
This should be done after http://java.net/jira/browse/JAVASERVERFACES-2335 is complete.



 Comments   
Comment by rogerk [ 06/Apr/12 ]

Assign

Comment by Manfred Riem [ 15/May/12 ]

Changes are attached to issue #2335





[JAVASERVERFACES-2373] Component moves - reparenting looses the component in the tree completely Created: 04/Apr/12  Updated: 14/May/12  Resolved: 14/May/12

Status: Closed
Project: javaserverfaces
Component/s: state saving
Affects Version/s: 2.1.7
Fix Version/s: 2.1.8

Type: Bug Priority: Major
Reporter: prakashudupa Assignee: Manfred Riem
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 day
Original Estimate: Not Specified
Environment:

Any environment


Attachments: Java Source File ChangeBeanOne.java     Text File changebundle-fss.txt     Zip Archive changebundle-newfiles.zip     Text File changebundle.txt     Zip Archive changebundle2-newfiles.zip     Text File changebundle2.txt     Text File changebundle3.txt     Zip Archive newfiles-fss.zip     File testCase.jsf    
Issue Links:
Related
is related to JAVASERVERFACES-2335 Forward Port System Event Acid Test F... Closed
Tags: ADF, dynamic

 Description   

In Trinidad framework, we have a customization / changeManager feature, one of the subfeatures there is to be able to move components around in the tree. The usecase is a very common Design-time at Run-time feature where the components are moved by Drag-And-Drop in a canvas. This feature is broken when we recently tried to update to Mojarra 2.1.7, so this is a regression from Mojarra for which we are requesting a fix a.s.a.p.

I have tried to scale down this feature in a simple managed bean code and attached the testcase. All I'm doing in the managed bean is reparenting the component to move, and expecting that 1. if the component tree state is restored by RI, the component is in its destination, or 2. if the jsf page is re-read and tags re-executed, then RI should re-instate the component is in its original position, and remove the component from its destination. The component being in its original position was the behavior from Mojarra until 2.1.7. From 2.1.7 onwards, the component that was moved is no more in the tree.

To test it, run the facelets jsf page provided as testcase (note the components are from Trinidad, so you will need to include Trinidad library, you can yourself emulate the behavior in any other component library you wish, since the essense of defect is showcased). In the page, click on the first button, that will move the component inside PanelBox1. If you set breakpoint in the bean code, you will see reparenting successful.

After this, when the page is re-rendered, the component is expected to be re-introduced in its original position (because it is in the page definition whose tags are processed), this was the behavior so far. However this behavior is no more 2.1.7 onwards, notice that the component is no more restored to the original location (this is the issue).



 Comments   
Comment by Manfred Riem [ 11/Apr/12 ]

Can you supply at test case without Trinidad?

Comment by prakashudupa [ 11/Apr/12 ]

I work on ADF Faces components / tags which is built on Trinidad, the issue needs some component library to be used, I'm not familiar with any other component library lower than Trinidad.
I think the issue is explained well above, and attached code is easy to understand, you should be able to see the same issue in whatever library you try (like JSF tag lib for eg.).

Comment by rogerk [ 17/Apr/12 ]

Here is my review of the recent changes:

1. Missing copyrights (2012)
2. StateManagementStrategyImpl has commented line (316?):
+// actions.add(action);
3. StateContext : handleAdd method:
Can you explain why you had to do:
+ component.setId(null);
+ component.setId(id);

4. test agnostic pom

  • need to add "dynamic" module

5. From the original eventTest Acid test ui, everything passes
except the toggle test.

All Mojarra tests run successfully.

Comment by Manfred Riem [ 19/Apr/12 ]

1. Addressed missing copyright.
2. Removed that line (it was used for debugging).
3. component.setId(id) was used to reset the clientId.
4. Added 'dynamic' module.
5. Wrote a new test to execute old toggle test.

Comment by Ed Burns [ 19/Apr/12 ]
  • Add a landing page for the test app that has links to the pages used
    by the HtmlUnit tests.
  • In StateManagementStrategyImpl.reapplyDynamicActions(), don't bother
    with the saving aside and restoring of the trackViewModifications
    property, as this is done already.

In the same method, add a comment to state the precondition that the
caller is responsible for ensuring the trackViewModifications property
is correctly saved and restored around the invocation of this method.

  • Rename method StateManagementStrategyImpl.findComponent().
    Suggestion: locateComponentByClientId().
  • In addition to the suggested name change,
    StateManagementStrategyImpl.findComponent() may not operate correctly
    in partial traversal situations, with or without iterating components.
    Rewrite this method to first try to locate the component using
    UIComponent.invokeOnComponent(). Usage examples abound in the code.
    If that doesn't succeed in finding a component, then you can do your
    manual traversal.
  • At the earliest point in time when this can be safely done, please add
    a try/finally block that ensures the dynamicActions are cleared from
    the stateContext after they have been processed.
  • In StateManagementStrategyImpl.pruneAndReAddDynamicActions() keep only the so-called "english" part of the comment.
  • In toggle.xhtml, remove text that mentions a "red box".

Apply these changes, run the tests, and let me have one more look at it. Then let's get this puppy in!

Comment by Manfred Riem [ 19/Apr/12 ]

Done the changes as requested by Ed

Comment by Ed Burns [ 19/Apr/12 ]

This looks good. Please commit to the 2.1 branch.

r=edburns

Comment by Manfred Riem [ 19/Apr/12 ]

Applied to 2.1 branch

svn commit -m "Fixes http://java.net/jira/browse/JAVASERVERFACES-2373, r=edburns, tracking components that are removed so we
can readd them if requested, add toggle and move test, see issue for more information"
Sending jsf-ri\src\main\java\com\sun\faces\application\view\FaceletViewHandlingStrategy.java
Sending jsf-ri\src\main\java\com\sun\faces\application\view\StateManagementStrategyImpl.java
Sending jsf-ri\src\main\java\com\sun\faces\context\StateContext.java
Sending jsf-ri\src\main\java\com\sun\faces\facelets\tag\jsf\ComponentSupport.java
Sending jsf-ri\src\main\java\com\sun\faces\facelets\tag\jsf\ComponentTagHandlerDelegateImpl.java
Sending jsf-ri\src\main\java\com\sun\faces\util\ComponentStruct.java
Adding test\agnostic\dynamic
Adding test\agnostic\dynamic\nbactions.xml
Adding test\agnostic\dynamic\pom.xml
Adding test\agnostic\dynamic\src
Adding test\agnostic\dynamic\src\main
Adding test\agnostic\dynamic\src\main\java
Adding test\agnostic\dynamic\src\main\java\com
Adding test\agnostic\dynamic\src\main\java\com\sun
Adding test\agnostic\dynamic\src\main\java\com\sun\faces
Adding test\agnostic\dynamic\src\main\java\com\sun\faces\test
Adding test\agnostic\dynamic\src\main\java\com\sun\faces\test\agnostic
Adding test\agnostic\dynamic\src\main\java\com\sun\faces\test\agnostic\dynamic
Adding test\agnostic\dynamic\src\main\java\com\sun\faces\test\agnostic\dynamic\MoveComponentBean.java
Adding test\agnostic\dynamic\src\main\java\com\sun\faces\test\agnostic\dynamic\ToggleBean.java
Adding test\agnostic\dynamic\src\main\java\com\sun\faces\test\agnostic\dynamic\ToggleComponent.java
Adding test\agnostic\dynamic\src\main\resources
Adding test\agnostic\dynamic\src\main\webapp
Adding test\agnostic\dynamic\src\main\webapp\WEB-INF
Adding test\agnostic\dynamic\src\main\webapp\WEB-INF\dynamic.taglib.xml
Adding test\agnostic\dynamic\src\main\webapp\WEB-INF\faces-config.xml
Adding test\agnostic\dynamic\src\main\webapp\WEB-INF\glassfish-web.xml
Adding test\agnostic\dynamic\src\main\webapp\WEB-INF\web.xml
Adding test\agnostic\dynamic\src\main\webapp\index.xhtml
Adding test\agnostic\dynamic\src\main\webapp\moveComponent.xhtml
Adding test\agnostic\dynamic\src\main\webapp\toggle.xhtml
Adding test\agnostic\dynamic\src\test
Adding test\agnostic\dynamic\src\test\java
Adding test\agnostic\dynamic\src\test\java\com
Adding test\agnostic\dynamic\src\test\java\com\sun
Adding test\agnostic\dynamic\src\test\java\com\sun\faces
Adding test\agnostic\dynamic\src\test\java\com\sun\faces\test
Adding test\agnostic\dynamic\src\test\java\com\sun\faces\test\agnostic
Adding test\agnostic\dynamic\src\test\java\com\sun\faces\test\agnostic\dynamic
Adding test\agnostic\dynamic\src\test\java\com\sun\faces\test\agnostic\dynamic\Issue2373IT.java
Sending test\agnostic\pom.xml
Transmitting file data ....................
Committed revision 9869.

Comment by Manfred Riem [ 19/Apr/12 ]

Marking resolved pending testing

Comment by Manfred Riem [ 19/Apr/12 ]

Guarding against stateContext being null, or stateContext.getDynamicActions being null

Comment by Manfred Riem [ 19/Apr/12 ]

svn commit -m "Fixes http://java.net/jira/browse/JAVASERVERFACES-2373, r=edburns, guard against stateContext and stateContext.getDynamicActions being null"
Sending jsf-ri\src\main\java\com\sun\faces\application\view\StateManagementStrategyImpl.java
Transmitting file data .
Committed revision 9870.

Comment by Manfred Riem [ 19/Apr/12 ]

Marking resolved again.

Comment by Manfred Riem [ 19/Apr/12 ]

Make sure we don't call reapplyDynamicActions when doing full state saving

Comment by Manfred Riem [ 09/May/12 ]

Changes to make FSS working again with dynamic components

Comment by Ed Burns [ 14/May/12 ]

http://java.net/jira/browse/JAVASERVERFACES-2373

These are Ed's notes when reviewing the 20120509 changebundle.
Actionable comments addressed to Manfred start with mriem:.

Please look through these suggestions and address my comments. I think I'd like to see another iteration.

SECTION: test changes

M jsf-ri/test/com/sun/faces/application/TestViewHandlerImpl.java
M jsf-ri/test/com/sun/faces/context/TestStateContext.java
M jsf-ri/test/com/sun/faces/component/visit/TestTreeWithUIDataVisit.java
M test/agnostic/dynamic/src/test/java/com/sun/faces/test/agnostic/dynamic/Issue2373IT.java
A test/agnostic/dynamic/src/main/java/com/sun/faces/test/agnostic/dynamic/RemoveComponentBean.java
M test/agnostic/dynamic/src/main/webapp/index.xhtml
A test/agnostic/dynamic/src/main/webapp/removeComponent.xhtml

SECTION: State Management changes

M jsf-ri/src/main/java/com/sun/faces/application/StateManagerImpl.java

General comments on this class:

  • Overall, this class looks much cleaner, but I'm always suspicious of
    code that looks dramatically simpler, because stuff that looks dirty
    is often just bugfixes. Nonetheless, I'll trust that your changes
    simultaneously add clarity, remove complexity, and preserve bug fixes.
    That's a tall order, though!
  • mriem: Four or so methods and two inner classes have been removed.
    Where did these end up?
  • Remove apologies from class javadoc.
  • Remove ctor, moved to JspStateManagementStrategy.
  • Remove all ivars, moved to JspStateManagementStrategy.

In method saveView():

  • mriem: on line 69, you access the context local variable, but check
    for its nullness on line 71. That's an NPE waiting to happen.
  • mriem: you've removed the id uniqueness check from this method. I
    assume it will show up somewhere else. Please verify that it does.

In method restoreView():

  • mriem: you've removed the wordy comment about the need to clone the
    tree... Is that business handled somewhere else now? Yes: looks like
    it's in the new class JspStateManagementStrategy.

A jsf-ri/src/main/java/com/sun/faces/application/view/JspStateManagementStrategy.java

  • Assume the responsibilities from the former StateManagerImpl.java

M jsf-ri/src/main/java/com/sun/faces/application/view/StateManagementStrategyImpl.java

  • Removed. Functionality taken over by pair of classes:
    FaceletPartialStateManagementStrategy and
    FaceletFullStateManagementStrategy.
  • mriem: But I note that

./test/unit/src/main/java/com/sun/faces/application/view/StateManagementStrategyImpl.java

still has this old implementation. Is that intentional?

A jsf-ri/src/main/java/com/sun/faces/application/view/FaceletPartialStateManagementStrategy.java

Global comments:

  • mriem: you have a zero arg ctor, but it's only called by test code
    (and cactus code no less). To guard against someone calling that ctor
    for real, perhaps invent some kind of magic argument that is checked
    by the ctor and throws an IllegalStateException if it's not right?
    Something like a string with a value known by the test and the real
    code? The test will pass the literal string?
  • Again, this looks much cleaner.
  • In method saveView():

Ahh, here is the id uniqueness check.

How about adding a context param that makes this off when ProjectStage
is Development? After sitting through Leonardo Uribe's MyFaces vs
Mojarra performance comparison, I'm ready to entertain such
expediences.
A jsf-ri/src/main/java/com/sun/faces/application/view/FaceletFullStateManagementStrategy.java

  • mriem: please add a comment that explains why this class looks so
    similar to JspStateManagementStrategy. And a question for you, how
    does this actually differ from JspStateManagementStrategy?

M jsf-ri/src/main/java/com/sun/faces/context/StateContext.java

  • change name of method partialStateSaving() to be
    isPartialStateSaving(). Otherwise this file is unchanged.

M jsf-ri/src/main/java/com/sun/faces/facelets/tag/jsf/ComponentSupport.java

  • Change callsite of partialStateSaving().

M jsf-ri/src/main/java/com/sun/faces/application/view/FaceletViewHandlingStrategy.java

  • I note that FaceletPartialStateManagementStrategy has a
    locateComponentByClientId() method, and FaceletViewHandlingStrategy
    does too. How are these to incarnations of the same named method
    related? Can this be moved to Util?
Comment by Manfred Riem [ 14/May/12 ]

M jsf-ri/src/main/java/com/sun/faces/application/StateManagerImpl.java

1. The methods have moved to both FaceletFullStateManagementStrategy and JspStateManagementStrategy.

2. In method saveView: will be moving that context.getViewRoot down into if block

3. Uniqueness check shows up in each of the StateManagementStrategy impls as it is their responsibility.

4. Correct, see 1. above.

test/unit/src/main/java/com/sun/faces/application/view/StateManagementStrategyImpl.java

1. This is your local workspace playing a trick on you. The test/unit project downloads the latest
installed copy from your local Maven repo. If you did not build using mvn.deploy.snapshot.local this
is why that is happening. It won't be part of the commit.

Global comments:

1. Not sure what you mean to convey here. Yes it is possible to construct an instance of a particular
implementation of the StateManagementStrategies.

A jsf-ri/src/main/java/com/sun/faces/application/view/FaceletFullStateManagementStrategy.java

They look so similar because they both originated from the same source. Eventually I hope we can
make it so the JSP part can be turned off completely. Separating it out should make that easier.

M jsf-ri/src/main/java/com/sun/faces/application/view/FaceletViewHandlingStrategy.java

Correct, more refactoring will need to be done but I did want to have a point where we could push it
into a release. Eventually the dynamic parts of each StateManagementStrategy will be pulled up into FaceletViewHandlingStrategy and each StateManagementStrategy just saves state (and does not need to
know about how to handle dynamic components).

The id uniqueness check.

I would like to delay that until after this issue. Lets file an issue to keep track of that.


Can we go ahead and get this in with the fix for StateManagerImpl #2 in place?

Comment by Ed Burns [ 14/May/12 ]

MR> Can we go ahead and get this in with the fix for StateManagerImpl #2 in place?

Yes, please go ahead. r=edburns.

Comment by Manfred Riem [ 14/May/12 ]

Changes committed

Comment by Manfred Riem [ 14/May/12 ]

Verified and closing





[JAVASERVERFACES-2335] Forward Port System Event Acid Test Fixes (1826) Created: 28/Feb/12  Updated: 02/Nov/12  Resolved: 16/May/12

Status: Closed
Project: javaserverfaces
Component/s: state saving
Affects Version/s: None
Fix Version/s: 2.2.0-m03

Type: Bug Priority: Major
Reporter: rogerk Assignee: Manfred Riem
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 day
Original Estimate: Not Specified

Attachments: Text File changebundle.txt     Zip Archive newfiles.zip    
Issue Links:
Duplicate
is duplicated by JAVASERVERFACES-1972 Facelets drops changes to the compone... Closed
Related
is related to JAVASERVERFACES-1826 SystemEvent Acid Test Closed
is related to JAVASERVERFACES-2371 regression of fix for 1553, componen... Closed
is related to JAVASERVERFACES-2372 regression: for partial state saving ... Closed
is related to JAVASERVERFACES-2373 Component moves - reparenting looses ... Closed
is related to JAVASERVERFACES-2374 Forward Port Issue 2371 to Trunk Closed
Tags: ADF, dynamic

 Description   

Forward port changes for http://java.net/jira/browse/JAVASERVERFACES-1826 to the trunk.



 Comments   
Comment by Manfred Riem [ 17/Apr/12 ]

Include the changes for 2371, 2372, 2373 in this as well

Comment by Manfred Riem [ 15/May/12 ]

All the changes needed for 1826, 2371, 2372 and 2373 coming
from the 2.1 branch are included in this forward port.

See the respective issues for explanations of the changes.

Comment by Ed Burns [ 16/May/12 ]

I ran the full tests with this changebundle applied and all 2271 tests passed.

Please commit it to the trunk!

Ed





[JAVASERVERFACES-2285] markInitialstate not called for newly added components Created: 09/Jan/12  Updated: 21/Sep/12  Resolved: 18/Jun/12

Status: Closed
Project: javaserverfaces
Component/s: state saving
Affects Version/s: 2.1.4
Fix Version/s: 2.1.10

Type: Bug Priority: Minor
Reporter: gabfest Assignee: Manfred Riem
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: ADF, dynamic, performance

 Description   

If you are using partial state saving then markInitialState is called on the full tree in restore view. But then in render response new components may be added to the tree (for example if you're using a foreach), and markInitialState will not be called on the newly added components. This shouldn't lead to incorrect behavior, but it will result in full state saving for these newly added components.



 Comments   
Comment by gabfest [ 09/Jan/12 ]

here's the code in FaceletViewHandlingStrategy, note that if the view is populated, markInitialState is not called:

    /**
     * Build the view.
     * @param ctx the {@link FacesContext} for the current request
     * @param view the {@link UIViewRoot} to populate based
     *  of the Facelet template
     * @throws IOException if an error occurs building the view.
     */
    @Override
    public void buildView(FacesContext ctx, UIViewRoot view)
    throws IOException {
        StateContext stateCtx = StateContext.getStateContext(ctx);
        if (Util.isViewPopulated(ctx, view)) {
            Facelet f = faceletFactory.getFacelet(view.getViewId());
            // Disable events from being intercepted by the StateContext by
            // virute of re-applying the handlers. 
            try {
                stateCtx.setTrackViewModifications(false);
                f.apply(ctx, view);
            } finally {
                stateCtx.setTrackViewModifications(true);
            }
            return;
        }

        view.setViewId(view.getViewId());

        if (LOGGER.isLoggable(Level.FINE)) {
            LOGGER.fine("Building View: " + view.getViewId());
        }
        if (faceletFactory == null) {
            ApplicationAssociate associate = ApplicationAssociate.getInstance(ctx.getExternalContext());
            faceletFactory = associate.getFaceletFactory();
            assert (faceletFactory != null);
        }
        RequestStateManager.set(ctx,
                                RequestStateManager.FACELET_FACTORY,
                                faceletFactory);
        Facelet f = faceletFactory.getFacelet(view.getViewId());

        // populate UIViewRoot
        try {
            ctx.getAttributes().put(IS_BUILDING_INITIAL_STATE, Boolean.TRUE);
            stateCtx.setTrackViewModifications(false);
            f.apply(ctx, view);
            doPostBuildActions(ctx, view);
        } finally {
            ctx.getAttributes().remove(IS_BUILDING_INITIAL_STATE);
        }
        ctx.getApplication().publishEvent(ctx,
                                          PostAddToViewEvent.class,
                                          UIViewRoot.class,
                                          view);
        markInitialState(ctx, view);
        
        Util.setViewPopulated(ctx, view);

    }
Comment by gabfest [ 09/Jan/12 ]

Note that there is an api initialStateMarked to check if deltas are already being tracked:
http://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/component/PartialStateHolder.html#initialStateMarked%28%29

Comment by Manfred Riem [ 28/Feb/12 ]

When a dynamic component gets added make sure we mark its initial state after adding it to the component tree. Note we are only calling markInitialState when the component is added to a parent that is within the view.

Comment by rogerk [ 08/Mar/12 ]

State saving assign.
The patch needs to be fixed so that the call to markInitialState happens within the isInView conditional.

Comment by rogerk [ 08/Mar/12 ]

I did indeed verify that with this patch this test fails:
[junit] Testsuite: com.sun.faces.systest.dynamic1757.Issue1757TestCase
[junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.788 sec
[junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.788 sec
[junit]
[junit] Testcase: testDynamicComponents took 0.658 sec
[junit] FAILED
[junit] null
[junit] junit.framework.AssertionFailedError
[junit] at com.sun.faces.systest.dynamic1757.Issue1757TestCase.testDynamicComponents(Issue1757TestCase.java:104)
[junit] at com.sun.faces.htmlunit.HtmlUnitFacesTestCase.runTest(HtmlUnitFacesTestCase.java:633)

This test adds a dynamic component to the view and it displays fine on initial request (view).
After post back, the component disappears. This test works fine without the patch in this issue.

Comment by Manfred Riem [ 13/Jun/12 ]

I have verified on ui:repeat, c:forEach and h:dataTable that the component tree it uses is properly marked for partial state saving. So I am closing this issue as "Cannot Reproduce"

Comment by gabfest [ 13/Jun/12 ]

Can you describe your test? Did you actually change the number of items in the c:foreach after postback, for example add an item in an actionListener?

When you say "the component tree it uses is properly marked for partial state saving", do you mean that markInitialState is called for the new components?

Comment by Manfred Riem [ 14/Jun/12 ]

After talking to gabfest I have identified one scenario that needs fixing

Comment by Manfred Riem [ 18/Jun/12 ]

I have verified that the forEach handler is properly applying changes when triggered within the context of a Facelets call (restoreView or renderView). So this issue will now be closed as "Cannot Reproduce".

Comment by TomaszKurpios [ 18/Sep/12 ]

Hello, this problem unfortunately still appears in Mojarra 2.1.13. Let's take a look at the following facelet:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
          "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html
	xmlns="http://www.w3.org/1999/xhtml"
	xmlns:h="http://java.sun.com/jsf/html"
	xmlns:c="http://java.sun.com/jsp/jstl/core"
	xmlns:f="http://java.sun.com/jsf/core"
>
<f:view contentType="text/html">
	<h:head/>
	<h:body>
		<h:form id="f">
			<c:if test="#{not empty sessionScope['a']}">
				<h:outputText value="text" id="text"/>
			</c:if>
			<h:outputText value="text2" id="text2" />
			<h:commandButton id="action" value="action" action="#{sessionScope.put('a','a')}" render="f"/>
		</h:form>
	</h:body>
</f:view>
</html>

(I am using JBoss EL for parametrized action in commandButton, but this action could be as well delegated to a managed bean).

How state saving applies to output texts with ids text and text2 on first request to the page (GET) and subsequent requests using command button (POST)

  text text2
GET request no state saving - component is not in the tree yet UIOutput.saveState returns null
each subsequent POST request UIOutput.saveState returns 6-element Object array, which contains a 9-element Object array, which contains various objects UIOutput.saveState returns null

I think it is crucial for memory performance that in such case state saving for dynamically components returns null. It is often the case that large parts of pages are excluded from component tree by means of <c:if> tag for time and memory performance reasons, but it seems not to work as expected.

Comment by TomaszKurpios [ 18/Sep/12 ]

Small correction: render attribute on <h:commandButton> is unnecessary

Comment by Manfred Riem [ 18/Sep/12 ]

Can you please open a new issue for what you are seeing and attach a small JSF application with sources that reproduces the above mentioned problem. Thanks!

Comment by TomaszKurpios [ 18/Sep/12 ]

Thanks for the answer. I will have more time to prepare such application next week, so I'll do it then.

Comment by TomaszKurpios [ 21/Sep/12 ]

The new issue is JAVASERVERFACES-2518.





[JAVASERVERFACES-2282] Contents of CDATA blocks consumed in facelets-processing jspx/xml Created: 06/Jan/12  Updated: 08/Nov/12  Resolved: 08/Nov/12

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: aschwart Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File 20120201-1538-i_mojarra_2282.patch    
Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1064 Clarify facelets-processing CDATA han... Closed
Tags: ADF

 Description   

When <facelets-processing> mode is set to jspx/xml, the JSF implementation should strip the CDATA section wrappers (ie. "<![CDATA[" and "]]>"). These wrappers should not be represented in the corresponding UIComponent tree or be passed through in the rendered content.

Currently, the CDATA section wrappers are removed, but this is implemented by removing the entire CDATA block, including any nested text content. This is not the desired behavior - ie. the text content itself should survive - only the CDATA wrapper constructs should be removed.

See:

http://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2012-01/message/2

For more details.



 Comments   
Comment by rogerk [ 06/Jan/12 ]

Assign

Comment by Ed Burns [ 18/Jan/12 ]

Need to be extra careful about Ajax with respect to CDATA.

Comment by Ed Burns [ 01/Feb/12 ]

Committed to trunk.

Sending jsf-ri/src/main/java/com/sun/faces/facelets/compiler/SAXCompiler.java
Sending jsf-ri/systest-per-webapp/process-as-jspx/src/java/com/sun/faces/systest/ProcessAsJspxTestCase.java
Sending jsf-ri/systest-per-webapp/process-as-jspx/web/jspxview.jspx
Transmitting file data ...
Committed revision 9632.

Comment by Ed Burns [ 02/Feb/12 ]

Committed to 2.1 branch.

Sending jsf-ri/src/main/java/com/sun/faces/facelets/compiler/SAXCompiler.java
Sending jsf-ri/systest-per-webapp/process-as-jspx/src/java/com/sun/faces/systest/ProcessAsJspxTestCase.java
Sending jsf-ri/systest-per-webapp/process-as-jspx/web/jspxview.jspx
Transmitting file data ...
Committed revision 9637.

Comment by Ed Burns [ 08/Nov/12 ]

At Manfred's request, verifying that this is done. I manually inspected the jspx source file and found this content related to the issue:

<![CDATA[ <p>This is CDATA content</p> ]]>

And there is this text in a JUnit testcase:


    private final static Pattern XmlDeclaration = Pattern.compile("(?s)^<\\?xml(\\s)*version=.*\\?>.*");
    private final static Pattern XmlDoctype = Pattern.compile("(?s).*<!DOCTYPE.*>.*");
    private final static Pattern XmlPI = Pattern.compile("(?s).*<\\?xml-stylesheet.*\\?>.*");
    private final static Pattern CDATASection = Pattern.compile("(?s).*<!\\[CDATA\\[ .*\\]\\]>.*");
    private final static Pattern Comment = Pattern.compile("(?s).*<!--.*-->.*");
    private final static Pattern EscapedText = Pattern.compile("(?s).*&amp;lt;context-param&amp;gt;.*");
    private final static Pattern NotEscapedText = Pattern.compile("(?s).*&lt;context-param&gt;.*");


    public void testProcessAsJspx() throws Exception {

        String xml = getRawMarkup("/faces/jspxview.jspx");
        assertFalse(XmlDoctype.matcher(xml).matches());
        assertFalse(XmlDeclaration.matcher(xml).matches());
        assertFalse(XmlPI.matcher(xml).matches());
        assertFalse(CDATASection.matcher(xml).matches());
        assertTrue(xml.matches("(?s).*<p>This\\s+is\\s+CDATA\\s+content</p>.*"));
        assertTrue(NotEscapedText.matcher(xml).matches());
        assertFalse(Comment.matcher(xml).matches());
    }

Therefore, I assert that this code proves the correctness of this bug fix. It follows that I need to prove that this testcase is actually run, and actually passes.

On the trunk, this test passed just yesterday.

http://hudson-sca.us.oracle.com/view/MOJARRA_ALL/job/MOJARRA_TRUNK_DEPLOY/327/testReport/com.sun.faces.systest/ProcessAsJspxTestCase/

On 2.1.x, this test passed just today.

http://hudson-sca.us.oracle.com/view/MOJARRA_ALL/job/MOJARRA_2_1X_ROLLING_DEPLOY/232/testReport/com.sun.faces.systest/ProcessAsJspxTestCase/

Therefore, I conclude that this is fixed.





[JAVASERVERFACES-2030] uneven calls to pushComponentToEL and popComponentFromEL in processSaveState Created: 15/Apr/11  Updated: 28/May/13  Resolved: 28/May/13

Status: Closed
Project: javaserverfaces
Component/s: state saving
Affects Version/s: 2.1.1
Fix Version/s: 2.1.23, 2.2.1

Type: Bug Priority: Major
Reporter: gabfest Assignee: Manfred Riem
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File changebundle.txt    
Status Whiteboard:

size_medium importance_medium

Tags: ADF

 Description   

The statemanager is causing processSaveState on javax.faces.component.UIComponentBase to be called. Note that the code is calling pushComponentToEL, but not always calling popComponentFromEL, here's
the code:

public Object processSaveState(FacesContext context) {

if (context == null)

{ throw new NullPointerException(); }

if (this.isTransient())

{ return null; }

Object[] stateStruct = new Object[2];
Object[] childState = EMPTY_ARRAY;

pushComponentToEL(context, null);

// Process this component itself
stateStruct[MY_STATE] = saveState(context);

// determine if we have any children to store
int count = this.getChildCount() + this.getFacetCount();
if (count > 0) {

// this arraylist will store state
List<Object> stateList = new ArrayList<Object>(count);

// if we have children, add them to the stateList
if (this.getChildCount() > 0) {
Iterator kids = getChildren().iterator();
UIComponent kid;
while (kids.hasNext()) {
kid = (UIComponent) kids.next();
if (!kid.isTransient())

{ stateList.add(kid.processSaveState(context)); popComponentFromEL(context); }

}
}

pushComponentToEL(context, null);

// if we have facets, add them to the stateList
if (this.getFacetCount() > 0) {
Iterator myFacets = getFacets().entrySet().iterator();
UIComponent facet;
Object facetState;
Object[] facetSaveState;
Map.Entry entry;
while (myFacets.hasNext()) {
entry = (Map.Entry) myFacets.next();
facet = (UIComponent) entry.getValue();
if (!facet.isTransient())

{ facetState = facet.processSaveState(context); popComponentFromEL(context); facetSaveState = new Object[2]; facetSaveState[0] = entry.getKey(); facetSaveState[1] = facetState; stateList.add(facetSaveState); }

}
}

// finally, capture the stateList and replace the original,
// EMPTY_OBJECT_ARRAY Object array
childState = stateList.toArray();
}

stateStruct[CHILD_STATE] = childState;
return stateStruct;
}

In general things still work because components are keeping count of their ref counts with field _isPushedAsCurrentRefCount and automatically popping in certain cases. Here's the code for javax.faces.component.UIComponent.popComponentFromEL()

public final void popComponentFromEL(FacesContext context)
{
if (context == null)

{ throw new NullPointerException(); }

// detect cases where the stack has become unbalanced. Due to how
UIComponentBase
// implemented pushing and pooping of components from the ELContext,
components that
// overrode just one of encodeBegin or encodeEnd, or only called super
in one case
// will become unbalanced. Detect and correct for those cases here.

// detect case where push was never called. In that case, pop should
be a no-op
if (_isPushedAsCurrentRefCount < 1)
return;

Map<Object, Object> contextAttributes = context.getAttributes();

ComponentStack componentELStack =
_getComponentELStack(_CURRENT_COMPONENT_STACK_KEY,

contextAttributes);

// check for the other unbalanced case, a component was pushed but
never popped. Keep
// popping those components until we get to our component
for (UIComponent topComponent = componentELStack.peek();
topComponent != this;
topComponent = componentELStack.peek())

{ topComponent.popComponentFromEL(context); }

// pop ourselves off of the stack
UIComponent popped = componentELStack.pop();
_isPushedAsCurrentRefCount--;
// update the current component with the new top of stack. We only do
this because of the spec
contextAttributes.put(UIComponent.CURRENT_COMPONENT,
componentELStack.peek());

// if we're a composite component, we also have to pop ourselves off of
the
// composite stack
if (UIComponent.isCompositeComponent(this))

{ ComponentStack compositeELStack=_getComponentELStack(_CURRENT_COMPOSITE_COMPONENT_STACK_KEY, contextAttributes); compositeELStack.pop(); // update the current composite component with the new top of stack. // We only do this because of the spec contextAttributes.put(UIComponent.CURRENT_COMPOSITE_COMPONENT, compositeELStack.peek()); }

}

However what's happening at the end of state saving is components are getting pushed but not popped from the stack at the very end, so for some components _isPushedAsCurrentRefCount is not 0 at the end of the request. In general this is ok because when you restore the view you create new component instances, and they have _isPushedAsCurrentRefCount set to 0.

However when you use trinidad we have cache the comopnent tree when the context param org.apache.myfaces.trinidad.CACHE_VIEW_ROOT is true, so at postback we start with a tree where _isPushedAsCurrentRefCount is not 0 for some components, which is causing an NPE.

The processRestoreState code should be fixed to call popComponentFromEL appropriately.



 Comments   
Comment by rogerk [ 02/May/11 ]

Sounds like you have a good handle on the problem. Can you supply a potential patch for us to try?

Comment by Manfred Riem [ 10/Jan/13 ]

Can you supply us with a patch or an example application (with sources) that demonstrates the problem, please send it to issues@javaserverfaces.java.net? Can you try on the latest 2.1 release?

Comment by gabfest [ 10/Jan/13 ]

Sorry, unfortunately our bug db no longer has the test case. But if you look at the code it's very obvious that processSaveState pushes the context for itself, but it never pops the context for itself. It has to call popComponentFromEL in the loop for the children because similarly the child has pushed the context for itself but not popped it. Obviously leaf components with no children never have pop called.

Comment by Manfred Riem [ 08/Mar/13 ]

Can you verify if the latest 2.1 release is also affected?

Comment by gabfest [ 09/Mar/13 ]

I'm looking here: https://svn.java.net/svn/mojarra~svn/branches/MOJARRA_2_1X_ROLLING/jsf-api/src/main/java/javax/faces/component/UIComponentBase.java

code looks the same, so yet it's also affected.

Comment by Manfred Riem [ 28/May/13 ]

Applied to 2.1 branch,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES-2030, r=rogerk, reordered so pushComponentToEL and popComponentFromEL happen correctly"
Sending jsf-api\src\main\java\javax\faces\component\UIComponentBase.java
Transmitting file data .
Committed revision 11974.

Comment by Manfred Riem [ 28/May/13 ]

Applied to 2.2 branch,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES-2030, r=rogerk, reordered so pushComponentToEL and popComponentFromEL happen correctly"
Sending jsf-api\src\main\java\javax\faces\component\UIComponentBase.java
Transmitting file data .
Committed revision 11975.





[JAVASERVERFACES-1937] Web application using Mojarra 2.1.0-b11 fails to deploy on Tomcat 7.0.6 Created: 02/Feb/11  Updated: 26/Jun/12  Resolved: 10/Mar/11

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.1.0
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Holger Stenzhorn Assignee: Ed Burns
Resolution: Fixed Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File 20110302-0048-i_jsf_1937.patch    
Status Whiteboard:

size_large importance_large

Tags: adf

 Description   

I updated the jsf-api.jar and jsf-impl.jar files of my web application which I deploy on Tomcat 7.0.6 from version 2.0.3 to 2.1.0-b11. With the former version the web application worked fine but with the newer version the deployment fails:

02.02.2011 23:33:38 org.apache.catalina.core.StandardContext listenerStart
SCHWERWIEGEND: Error configuring application listener of class com.sun.faces.application.ServletContextSensitiveSingletonStore
java.lang.InstantiationException: com.sun.faces.application.ServletContextSensitiveSingletonStore
at java.lang.Class.newInstance0(Class.java:340)
at java.lang.Class.newInstance(Class.java:308)
at org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:119)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4458)
at org.apache.catalina.core.StandardContext$1.call(StandardContext.java:5004)
at org.apache.catalina.core.StandardContext$1.call(StandardContext.java:4999)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
02.02.2011 23:33:38 org.apache.catalina.core.StandardContext listenerStart
SCHWERWIEGEND: Skipped installing application listeners due to previous error(s)

Is this issue related or the same as described in Ted Goddard's (last) comment in http://jira.icefaces.org/browse/ICE-6486? (i.e. that com.sun.faces.config.DelegatingAnnotationProvider has code that is specific to GlassFish and thus fails on Tomcat 7.0.6)



 Comments   
Comment by Ed Burns [ 01/Mar/11 ]

I suspect this was fixed by my fix for GLASSFISH-15809.

I'm running the automated tests on it now.

Comment by Ed Burns [ 01/Mar/11 ]

In progress.

Comment by vdweij [ 03/Mar/11 ]

I experience the same with Jetty (8.0.0.M2). From version 2.1.0-b09 up until 2.1.0-b11 my annotated classes are not discovered any more. Version 2.1.0 also fails when running in Jetty.

When debugging I noticed that DelegateToGlassFishAnnotationScanner is used.

Comment by Ed Burns [ 04/Mar/11 ]

vdwejj: can you try the patch?

Comment by balusc [ 04/Mar/11 ]

I experience the same on Tomcat 7.0.8 and JBoss AS 6.0.0.

It isn't entirely clear to me what tools to use to apply the patch. A snapshot JAR somewhere would be more helpful.

Comment by jhorstmann [ 05/Mar/11 ]

I applied the patch using

~/Source/java.net/mojarra/trunk$ patch -p0 < ~/Downloads/20110302-0048-i_jsf_1937.patch

Since a rebuild with ant did not fix the problem at first, I tried again with a clean build. It seems the real fix for the above stacktrace was the removal of jsf-ri/src/main/java/com/sun/faces/application/ServletContextSensitiveSingletonStore.java in revision 8887 as a fix for http://java.net/jira/browse/GLASSFISH-15985

So svn trunk revision 8899 + this patch makes my test app work on a current tomcat.

Comment by vdweij [ 06/Mar/11 ]

Ed Burns: I'll try the patch and report back.

Is the patch already available in a binary? I spotted a recent 2.1.1-b02 version in maven repo.

Comment by Holger Stenzhorn [ 06/Mar/11 ]

It seems that the introduced fixes work: Whereas 2.1.1-b01 still produced the reported exception version 2.1.1-b02 works fine.

Comment by vdweij [ 07/Mar/11 ]

I tried 2.1.1-b02 but to no avail. My annotated components remain undiscovered.

The class com.sun.faces.vendor.WebContainerInjectionProvider still implements AnnotationScanner, ergo patch 20110302-0048-i_jsf_1937 has not been applied to this version yet.

After manually applying the patch, annotated managed beans and converters are properly detected.

What boggles me is that (unpatched) version 2.1.1-b02 appears to work for Tomcat where it fails for Jetty. Perhaps different issues?

Comment by Holger Stenzhorn [ 07/Mar/11 ]

My original issue was about Tomcat 7 not starting up and throwing an exception and not about annotations not being discovered. So I guess when the class ServletContextSensitiveSingletonStore was removed my actual problem (see the stacktrace) was fixed.

Comment by jhorstmann [ 07/Mar/11 ]

@vdweij, I was using Weld instead of the jsf annotations in my test and that worked. I retried with the jsf annotations and the container started up okay but did not initialize my managed beans. Thats probably the same behaviour you are seeing on jetty.

Comment by vdweij [ 07/Mar/11 ]

@Holger Stenzhorn; The original issue is indeed different. As long as the patch works for both we can say they are related.

@jhorstmann: Thanks for retrying with plain jsf. it confirms my finding.

Comment by balusc [ 08/Mar/11 ]

2.1.1-b02 didn't work for us on JBoss 6.0.0, the javax.faces.bean annotated beans weren't constructed/initialized. Even the @Singleton EJBs with @PostConstruct weren't postconstructed at all.

2.0.3 works fine for us, but the major reason to upgrade to at least 2.1 is issue 1842 (unnecessary creation of session by Facelets, this is undesired in the public module of our webapplication).

Comment by vdweij [ 09/Mar/11 ]

@balusc: in case you want to use 2.1.x and patching is not an option, you could try 2.1.0-b08. From that version up discovery of annotated components fails is known to be problematic for servlet containers other than glassfish.

Comment by balusc [ 10/Mar/11 ]

@vdweij: unfortunately, that is not good enough for us. JSF managed beans of WAR were correctly constructed, but the managed beans provided by JARs were not found due to a "java.util.zip.ZipException: error in opening zip file" on the JAR file (which, I think, is a JBoss specific issue). Also, the @EJB in local managed beans was not injected, resulting in NPEs on EJB calls.

I think I'll end up with patching 2.0.3-b05 myself to fix the unnecessary session creation and wait until a full stable 2.1 build is provided.

Comment by Ed Burns [ 10/Mar/11 ]

Committed on trunk

Sending common/ant/common.xml
Sending common/ant/test-app.xml
Adding common/ant/tomcat7
Adding common/ant/tomcat7/container.xml
Sending jsf-ri/src/main/java/com/sun/faces/vendor/WebContainerInjectionProvider.java
Sending jsf-ri/systest/build-tests.xml
Sending jsf-ri/systest/build.xml
Sending jsf-ri/systest/src/com/sun/faces/composite/CompositeComponentsTestCase.java
Sending jsf-ri/systest/src/com/sun/faces/facelets/UIRepeatTestCase.java
Sending jsf-ri/systest/src/com/sun/faces/jsptest/ForEachTestCase.java
Sending jsf-ri/systest/src/com/sun/faces/systest/composite/behavior/CompositeBehaviorTestCase.java
Sending jsf-ri/systest/src/com/sun/faces/systest/jsp/htmltaglib/HtmlTaglibTestCase.java
Sending jsf-test/build.xml
Transmitting file data ............
Committed revision 8913.

Comment by Ed Burns [ 10/Mar/11 ]

Committed on 2.1 branch.

Sending common/ant/common.xml
Sending common/ant/test-app.xml
Adding common/ant/tomcat7
Adding common/ant/tomcat7/container.xml
Sending jsf-ri/src/main/java/com/sun/faces/vendor/WebContainerInjectionProvider.java
Sending jsf-ri/systest/build-tests.xml
Sending jsf-ri/systest/build.xml
Sending jsf-ri/systest/src/com/sun/faces/composite/CompositeComponentsTestCase.java
Sending jsf-ri/systest/src/com/sun/faces/facelets/UIRepeatTestCase.java
Sending jsf-ri/systest/src/com/sun/faces/jsptest/ForEachTestCase.java
Sending jsf-ri/systest/src/com/sun/faces/systest/composite/behavior/CompositeBehaviorTestCase.java
Sending jsf-ri/systest/src/com/sun/faces/systest/jsp/htmltaglib/HtmlTaglibTestCase.java
Sending jsf-test/build.xml
Transmitting file data ...........
Committed revision 8914.

Comment by TheEliteGentleman [ 19/Mar/11 ]

Hi Ed Burns,

I have just downloaded the current stable Mojarra 2.1.0(03/02/2011) and I still get the same issue as logged by Holger Stenzhorn.

I deployed my application on Tomcat 7.0.0 and the same exception occurs. Please refer to my question on StackOverflow.com (http://stackoverflow.com/questions/5364377/jsf-2-setup-issue-in-tomcat-7-java-lang-instantiationexception-com-sun-faces-ap/5364453#5364453).

I guess there was no build to the 2.1 branch?

Comment by mgutwein [ 20/Mar/11 ]

This is still broken in Mojarra 2.1.0-FCS. Tried it on Tomcat 7.0.8 and 7.0.11 and get the same results.

Comment by Ed Burns [ 21/Mar/11 ]

Yes, it is not in 2.1.0-FCS. It is in 2.1.1-b02.

See http://hudson.glassfish.org/view/JSF%20Mojarra/job/JSF_TRUNK-TOMCAT7/ for proof.





[JAVASERVERFACES-1856] Jar-packaged composite components fail on WLS Created: 01/Nov/10  Updated: 17/Dec/13  Resolved: 20/Feb/12

Status: Closed
Project: javaserverfaces
Component/s: resources
Affects Version/s: 2.0.1
Fix Version/s: 2.0.next, 2.1.2, 2.2.0-m01

Type: Bug Priority: Major
Reporter: aschwart Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File 20110317-1537-i_jsf_1856.patch     Text File 20110325-1725-i_jsf_1856.patch     Java Source File ClasspathResourceHelper.java     Text File i_jsf_1856.patch    
Issue Links:
Related
is related to JAVASERVERFACES-3113 Migrate test for issue 1856 to test/a... Closed
Issuezilla Id: 1,856
Status Whiteboard:

size_medium importance_large jsf_2_1_1

Tags: adf

 Description   

Composite components that are packaged in jar files fail when deploying to WLS. The problem: when
testing for the existence of a composite component library, Mojarra calls ClassLoader.getResource() on the
path to the directory containing the composite component library. While GF's class loader honors calls to
getResource() for directory paths, WLS's class loader does not. As a result, the composite component
library is not found, and composite component references fail to resolve.

The failing code path starts around
com.sun.faces.facelets.tag.jsf.CompositeComponentTagLibrary.tagLibraryForNSExists(), which delegates to
the ResourceHandler/ResourceManager to check for the existence of the composite component resource
library.



 Comments   
Comment by Ed Burns [ 02/Nov/10 ]

Target 2.2

Comment by rogerk [ 10/Feb/11 ]

Set target version 2.1.1

Comment by Ed Burns [ 16/Feb/11 ]

I am unable to reproduce this issue on WLS10.3.4 with the latest Mojarra trunk.

Comment by aschwart [ 16/Feb/11 ]

Max is taking a look to see whether he can find a difference between the test cases that we have been using in ADF and the one that Ed has created for Mojarra.

Comment by Ed Burns [ 16/Feb/11 ]

Testcase that shows this is not a bug.

Comment by Ed Burns [ 16/Feb/11 ]

Sending common/ant/wls-10.3.4_no_cluster/container.xml
Sending common/ant/wls-10.3.4_no_cluster/wls-jsf
Sending jsf-ri/systest/build.xml
Adding jsf-ri/systest/src/com/sun/faces/systest/composite/JarPackagedCompositeComponentTestCase.java
Adding (bin) jsf-ri/systest/web/WEB-INF/lib/i_jsf_1856.jar
Adding jsf-ri/systest/web/composite/i_jsf_1856-using.xhtml
Transmitting file data .....
Committed revision 8853.

Comment by Ed Burns [ 17/Feb/11 ]

Feedback from Max Starets let me know that I can close this because the thinking of the moment is that the problem is in the way that JDev creates jars.

Comment by Ed Burns [ 17/Mar/11 ]

Ok. It turns out the implementation of ResourceHandler.libraryExists() relies on an implementation detail of the jar tool that is not in the zip file specification on which the jar is based. Basically, you can't count on directory entries being there.

I'm going to have to revise the implementation to fall back on another detection mechanism if the directory is not there.

I'll note that http://java.net/jira/browse/GLASSFISH-16058 fixes this problem, though looking at the bug I can't really say why.

In any case, Fusion Middleware relies on WLS 10.3.4 anyway so we have to affect the fix in Mojarra.

Comment by Ed Burns [ 18/Mar/11 ]

I was hoping I could leverage the code that already traverses the jars in order to discover the entries, but I found a problem in the spec.

The code that traverses the jars currently does so just so it can discover annotated classes. section 11.5.1 of the spec says that such jars must contain a faces-config.xml file, even if it is zero length, to cause the jar to even be seen by the annotation scanning system.

The resource library specification section 2.6.1.2 does not require the faces-config.xml file. Therefore, we can't rely on the jar traversing code without either broadening it to also include, say META-INF/resources.

This is what I will investigate next.

Comment by Ed Burns [ 18/Mar/11 ]

Sending jsf-ri/src/main/java/com/sun/faces/application/resource/ClasspathResourceHelper.java
Adding jsf-ri/src/main/java/com/sun/faces/application/resource/ZipDirectoryEntryScanner.java
Sending jsf-ri/src/main/java/com/sun/faces/config/JavaClassScanningAnnotationScanner.java
Deleting jsf-ri/systest/src/com/sun/faces/systest/composite/JarPackagedCompositeComponentTestCase.java
Deleting jsf-ri/systest/web/WEB-INF/lib/i_jsf_1856.jar
Deleting jsf-ri/systest/web/composite/i_jsf_1856-using.xhtml
Adding jsf-test/JAVASERVERFACES-1856
Adding jsf-test/JAVASERVERFACES-1856/build.xml
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/pom.xml
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main/webapp
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main/webapp/WEB-INF
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main/webapp/WEB-INF/faces-config.xml
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main/webapp/WEB-INF/lib
Adding (bin) jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main/webapp/WEB-INF/lib/i_jsf_1856.jar
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main/webapp/i_jsf_1856-using.xhtml
Sending jsf-test/build.xml
Transmitting file data ........
Committed revision 8933.

committed to trunk.

Comment by Ed Burns [ 19/Mar/11 ]

Committed to 2.1 branch

Sending jsf-ri/src/main/java/com/sun/faces/application/resource/ClasspathResourceHelper.java
Adding jsf-ri/src/main/java/com/sun/faces/application/resource/ZipDirectoryEntryScanner.java
Sending jsf-ri/src/main/java/com/sun/faces/config/JavaClassScanningAnnotationScanner.java
Deleting jsf-ri/systest/src/com/sun/faces/systest/composite/JarPackagedCompositeComponentTestCase.java
Deleting jsf-ri/systest/web/WEB-INF/lib/i_jsf_1856.jar
Deleting jsf-ri/systest/web/composite/i_jsf_1856-using.xhtml
Adding jsf-test/JAVASERVERFACES-1856
Adding jsf-test/JAVASERVERFACES-1856/build.xml
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/pom.xml
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main/webapp
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main/webapp/WEB-INF
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main/webapp/WEB-INF/faces-config.xml
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main/webapp/WEB-INF/lib
Adding (bin) jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main/webapp/WEB-INF/lib/i_jsf_1856.jar
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main/webapp/i_jsf_1856-using.xhtml
Sending jsf-test/build.xml
Transmitting file data ...
Committed revision 8934.

Comment by Ed Burns [ 21/Mar/11 ]

Another iteration to trunk.

Sending jsf-ri/src/main/java/com/sun/faces/application/resource/ClasspathResourceHelper.java
Sending jsf-ri/src/main/java/com/sun/faces/application/resource/ZipDirectoryEntryScanner.java
Sending jsf-ri/src/main/java/com/sun/faces/config/WebConfiguration.java
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main/webapp/WEB-INF/web.xml
Transmitting file data ....
Committed revision 8939.

Comment by Ed Burns [ 21/Mar/11 ]

Another iteration to 2.1 branch

Sending jsf-ri/src/main/java/com/sun/faces/application/resource/ClasspathResourceHelper.java
Sending jsf-ri/src/main/java/com/sun/faces/application/resource/ZipDirectoryEntryScanner.java
Sending jsf-ri/src/main/java/com/sun/faces/config/WebConfiguration.java
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main/webapp/WEB-INF/web.xml
Transmitting file data ...
Committed revision 8940.

Comment by Ed Burns [ 22/Mar/11 ]

Sending build.xml
Sending common/ant/common.xml
Sending common/ant/glassfishV3/container.xml
Adding common/ant/test-app.xml
Sending jsf-ri/build-tests.xml
Sending jsf-ri/src/main/java/com/sun/faces/application/resource/ClasspathResourceHelper.java
Adding jsf-ri/src/main/java/com/sun/faces/application/resource/ZipDirectoryEntryScanner.java
Sending jsf-ri/src/main/java/com/sun/faces/config/WebConfiguration.java
Sending jsf-ri/systest/build-tests.xml
Adding jsf-ri/systest/web/regexp
Adding jsf-ri/systest/web/regexp/converter02.txt
Adding jsf-ri/systest/web/regexp/converter06.txt
Adding jsf-ri/systest/web/regexp/escape_test.txt
Adding jsf-ri/systest/web/regexp/regression
Adding jsf-ri/systest/web/regexp/regression/AreaTextRowsAttrTest.txt
Adding jsf-ri/systest/web/regexp/regression/SelectOneManySizeAttrTest.txt
Adding jsf-ri/systest/web/regexp/standard
Adding jsf-ri/systest/web/regexp/standard/autocomplete.txt
Adding jsf-ri/systest/web/regexp/standard/component01.txt
Adding jsf-ri/systest/web/regexp/standard/dtablecolumnclasses.txt
Adding jsf-ri/systest/web/regexp/standard/messages01.txt
Adding jsf-ri/systest/web/regexp/standard/messages02.txt
Adding jsf-ri/systest/web/regexp/standard/pgridcolumnclasses.txt
Adding jsf-ri/systest/web/regexp/standard/selectmany02.txt
Adding jsf-ri/systest/web/regexp/verbatim_test.txt
Sending jsf-ri/systest-per-webapp/build-tests.xml
Adding jsf-test
Adding jsf-test/JAVASERVERFACES-1856
Adding jsf-test/JAVASERVERFACES-1856/build.xml
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/pom.xml
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main/webapp
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main/webapp/WEB-INF
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main/webapp/WEB-INF/faces-config.xml
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main/webapp/WEB-INF/lib
Adding (bin) jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main/webapp/WEB-INF/lib/i_jsf_1856.jar
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main/webapp/WEB-INF/web.xml
Adding jsf-test/JAVASERVERFACES-1856/i_jsf_1856/src/main/webapp/i_jsf_1856-using.xhtml
Adding jsf-test/build.xml
Sending lib/jsf-extensions-test-time.jar
Transmitting file data ...............................
Committed revision 8945.

Comment by Ed Burns [ 23/Mar/11 ]

Customer not yet satisfied with fix.

Comment by Ed Burns [ 23/Mar/11 ]

Another iteration, this on the trunk.

Sending jsf-ri/src/main/java/com/sun/faces/application/resource/ClasspathResourceHelper.java
Sending jsf-ri/src/main/java/com/sun/faces/facelets/tag/jsf/CompositeComponentTagLibrary.java
Sending jsf-ri/test/com/sun/faces/application/resource/TestResourceHandlerImpl.java
Transmitting file data ...
Committed revision 8947.

Comment by Ed Burns [ 23/Mar/11 ]

Committed to 2.0 branch

Sending jsf-ri/src/main/java/com/sun/faces/application/resource/ClasspathResourceHelper.java
Sending jsf-ri/src/main/java/com/sun/faces/facelets/tag/jsf/CompositeComponentTagLibrary.java
Sending jsf-ri/test/com/sun/faces/application/resource/TestResourceHandlerImpl.java
Transmitting file data ...
Committed revision 8949.

Comment by Ed Burns [ 24/Mar/11 ]

Committed to 2.1 branch.

Sending jsf-ri/src/main/java/com/sun/faces/application/resource/ClasspathResourceHelper.java
Sending jsf-ri/src/main/java/com/sun/faces/facelets/tag/jsf/CompositeComponentTagLibrary.java
Sending jsf-ri/test/com/sun/faces/application/resource/TestResourceHandlerImpl.java
Transmitting file data ...
Committed revision 8950.

Comment by Ed Burns [ 25/Mar/11 ]

Still doing directory scan.

Comment by Ed Burns [ 25/Mar/11 ]

Reviewed with Sheetal.

Comment by rogerk [ 27/May/11 ]

fix versions

Comment by rogerk [ 27/May/11 ]

re-closing





[JAVASERVERFACES-1792] FacesContext.setUIViewRoot Should Only Be Called During InvokeAppPhase Created: 25/Aug/10  Updated: 07/Dec/12  Resolved: 07/Dec/12

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.0.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: rogerk Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-878 FacesContext.setUIViewRoot Spec Incon... Closed
Issuezilla Id: 1,792
Status Whiteboard:

size_medium importance_large

Tags: ADF

 Description   

-------- Original Message --------
Subject: Re: Question about JSF issue
Date: Wed, 14 Jul 2010 09:40:30 -0600
From: David Schneider <david.schneider@oracle.com>
To: Ed Burns <edward.burns@oracle.com>, roger.kitain@oracle.com
CC: Andy Schwartz <andy.schwartz@oracle.com>, Sheetal Vartak
<sheetal.vartak@oracle.com>, barbara.louis@oracle.com

Thanks Ed.

Roger, my concern is this appears to be a big break in backward
compatibility between JSF v1.2 and v2.0 and one that can have a
significent negative impact on the Oracle ADF framework. If at all
possible I'd like to see this inconsistency resolved in favor of
preserving the JSF v1.2 restriction that FacesContext.setUIViewRoot()
can only be called during the INVOKE_APPLICATION phase, or at least
prohibiting it from being called during the RENDER_RESPONSE phase. ADF
relies on the JSF v.12 restriction and having the UIViewRoot change
during the RENDER_RESPONSE phase is something ADF can't support.

Dave

On 07/14/2010 08:45 AM, Ed Burns wrote:
> AS> On 7/13/10 2:08 PM, David Schneider wrote:
>
> DS> What ever happened with the issue about the new JSF 2.0
> DS> ConfigurableNavigationHandler allowing navigation during the
> DS> RENDER_RESPONSE phase while FacesContext.setViewRoot() is only allowed
> DS> to be called during the INVOKE_APPLICATION phase? Allowing the
> DS> UIViewRoot to change during the RENDER_RESPONSE phase is a potential
> DS> show-stopper for Oracle ADF.
>
>
>>>>>> On Tue, 13 Jul 2010 14:45:23 -0400, Andy
Schwartz<andy.schwartz@oracle.com> said:
>>>>>>
> AS> Hey Dave -
> AS> We've got two spec issues relating to this. I logged this one:
>
> AS> https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=757
>
> AS> To track the fact that there is inconsistency between what the spec says
> AS> about when setViewRoot() can be called vs. what the implementation does
> AS> (and what we are encouraging end users to do with PreRenderEvents).
>
> AS> Dan logged this one:
>
> AS> https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=758
>
> AS> To request the desired solution, ie. view actions that are invoked
> AS> during the invoke application phase.
>
> AS> I'll defer to Ed on time frame for when these might be addressed.
>
> Yes, I am passing the buck on this one, but you know how it is with
> respect to resources. Andy and Dave, Roger owns issue 757, and Sheetal
> owns issue 758. Roger, because you are the more senior of the two, I'll
> leave it to you to decide how best to handle this. Roger, I suggest you
> take ownership of 758 from Sheetal so that Andy and Dave only have to
> coordinate with you.
>
> AS> Note that, as we discussed previously, ADF will need to throw exceptions
> AS> in response to navigation attempts after invoke application.
>
> Andy, please let me know if this resolution is not satisfactory.
>
> Thanks,
>
> Ed
>
>



 Comments   
Comment by rogerk [ 25/Aug/10 ]

triage

Comment by Ed Burns [ 25/Aug/10 ]

This is not a terribly helpful comment, but I can say that the timing of setting
the view root is very complicated and has been impacted by several bug fixes
since the release of 2.0. I think it is unlikely we can craft a general purpose
solution for all cases to preserve 1.2 behavior. It might be possible to
preserve 1.2 behavior when running with PARTIAL_STATE_SAVINg == false, however.

Roger, please consult closely with Andy Schwartz on this one because he had some
work in this space in relation to issue 1600.

Comment by rogerk [ 27/Aug/10 ]

On 8/26/10 8:54 AM, Andy Schwartz wrote:
> Hey Dave -
>
> I can provide a little background on this:
>
>> I don't know what functionality JSF 2.0 was intending to support by allowing
the UIViewRoot to change after the render_response phase has started
>
> The overarching goal was to improve support for processing GET requests by
providing a simple way for views to define actions that would be invoked before
the rendering. Along those lines, the RH/JBoss/Seam folks (Dan and Pete)
proposed support for view parameters (which made it into the JSF 2.0 spec) and
view actions (which did not make it in). The original idea behind view actions
was that these would be invoked while performing lifecycle processing on the
view metadata, and that this would occur during invoke application, before
moving onto render response.
>
> Ed rejected the proposed view action solution for JSF 2.0 (I think mainly over
concerns regarding the schedule + stability), but recommended that as a stop-gap
measure, we could encourage the use of PreRenderViewEvent for the same purpose.
As a result, navigation logic which could/should have been executed during
invoke application ended up getting pushed out to render response.
>
> My take has always been that view actions offer a much better solution and I
am hopeful that these will find their way into the JSF specification. In the
meantime, I am somewhat concerned that if we remove our stopgap solution without
at least adding some alternative, we potentially risk making matters worse than
they are today.
>
> Andy
>
>
> On 8/26/10 1:27 AM, David Schneider wrote:
>>
>> Roger,
>>
>> From my point of view this issue represents a significant breakage of
backward compatibility that also happens to break Oracle's implementation of
JSR-227 data bindings. Currently the only option we've found is to make our
JSR-227 solution not 100% JSF 2.0 complaint by not allowing the UIViewRoot to
change during the render_response phase.
>>
>> It seems to come down to a question of how important it is to preserve
backward compatibility vs. the desire to support new features. I don't know
what functionality JSF 2.0 was intending to support by allowing the UIViewRoot
to change after the render_response phase has started but is it important enough
to justify breaking existing applications and frameworks? Is there any other
way to support the desired functionality without breaking backward compatibility?
>>
>> There may be no easy answer and it may end up being a question of picking the
lesser of several evils. Presently I see only two options to move forward:
>>
>> 1) provide another means of achieving JSF 2.0's goals and revert the
ability to change the UIViewRoot during the render_response phase, preserving
backward compatibility with JSF 1.x.
>> 2) leave the the ability to change the UIViewRoot during render_response in
the specification, break some existing applications and frameworks, and inform
the community JSF 2.0 is not fully backward compatible with JSF 1.x.
>>
>> As you've probably guessed my preference is option #1. Does anyone see any
other options?
>>
>> Dave

Comment by rogerk [ 27/Aug/10 ]

Given that the correct approach seems to be the View Action approach, and with
the limited amount of time for 2.1, I think we should do the right thing in 2.2.
However, there is a spec/impl inconsistency w/r/t FacesContext.setUIViewRoot
usage. I'm filing a new spec issue on that and will fix for 2.1.

Comment by rogerk [ 18/Nov/10 ]

triage

Comment by Manfred Riem [ 07/Dec/12 ]

Spec language was changed to reflect when and where it can be called also.





[JAVASERVERFACES-1757] Reentrant multiple event types can't be successfully processed Created: 03/Aug/10  Updated: 22/Mar/12  Resolved: 08/Oct/10

Status: Closed
Project: javaserverfaces
Component/s: event processing
Affects Version/s: 2.0.2
Fix Version/s: 2.1_gf31_m4

Type: Bug Priority: Major
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Cannot Reproduce Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Tomcat


Attachments: Zip Archive 1757-jsf-jars.zip     Text File 1757.txt     Text File 1757.txt     Text File changebundle.txt     Text File changebundle.txt     Text File EventTest-PreRenderViewEvent.zip     Text File EventTest-Reorder.zip     Text File jsf-systest.war     Zip Archive ramokarahasan.zip    
Issue Links:
Dependency
depends on JAVASERVERFACES-1497 Add a Tomcat Hudson job. Closed
Issuezilla Id: 1,757
Status Whiteboard:

size_medium importance_medium

Tags: adf

 Description   

If the system is processing events of type A and, during the publishing of an A event an event of type
B is published, the processing of the event of type B should proceed. Currently it does not.



 Comments   
Comment by Ed Burns [ 03/Aug/10 ]

I am moving my most recent patch on issue 1313 to here.

Comment by Ed Burns [ 03/Aug/10 ]

Created an attachment (id=1232)
Fix for this issue, 2nd iteration

Comment by Ed Burns [ 03/Aug/10 ]

Fix checked in.

Comment by Ed Burns [ 03/Aug/10 ]

Created an attachment (id=1233)
jsf-api.jar and jsf-impl.jar with the fix for this issue in place.

Comment by Ed Burns [ 04/Aug/10 ]

Fix committed to MOJARRA_2_0X_ROLLING

Comment by kennardconsulting [ 04/Aug/10 ]

Created an attachment (id=1236)
PreRenderViewEvent: dynamic component is serialized, but order is wrong

Comment by kennardconsulting [ 04/Aug/10 ]

Ed,

We are making progress, but the new jsf-api.jar and jsf-impl.jar don't quite
work.

THE GOOD NEWS:

Hooking in to PreRenderViewEvent and dynamically creating new components does
add them to the serialized view state. So they survive POSTback. Hurrah!

THE BAD NEWS:

They appear to survive POSTback in a different order to they were created.

THE TEST:

I have attached EventTest-PreRenderViewEvent.zip that demonstrates the problem.
You will need to manually add your jsf-api.jar and jsf-impl.jar to the WEB-
INF/lib (because of the 1MB java.net upload limit!)

You will note that when you run the app and click the 'POSTback' button the
children change their ordering. The code does an explicit check
for 'context.isPostback' and does nothing in this case, so it must be a view
serialization thing.

Comment by Ed Burns [ 05/Aug/10 ]

Your testcase does reproduce on my machine. Investigating.

Comment by Ed Burns [ 06/Aug/10 ]

I have discovered the cause of the problem. It happens regardless of the use or non-use of partial
state saving. The problem is that when the facelet tree is executed during render view, the ordering
gets reversed.

I'm trying to discover why. I suspect it has something to do with
ComponentTagHandlerDelegateImpl.findComponent().

Comment by Ed Burns [ 06/Aug/10 ]

As suspected, the problem is indeed in ComponentTagHandlerDelegateImpl, but in apply(), not
findChild(). The problem has to do with the mark and sweep deletion system, which is also at the
heart of issue 1757. In fact, both of these issues deal with dynamic children. In the case of issue
1757, the dynamism comes from using <c:if>. Perhaps I can close two issues with one fix? We'll see.

Comment by Ed Burns [ 06/Aug/10 ]

Created an attachment (id=1238)
Fix in progress. This one tries to re-add the marked and deleted component at the same index it had before the deletion

Comment by kennardconsulting [ 06/Aug/10 ]

Ed,

Awesome. Thank you so much for your perseverance with this issue: Metawidget is
nearly at v1.0 and I'd love to be able to release it with full JSF2 support!

Can I get this patch from the nightlies, or can you do a build of the JAR for
me?

Regards,

Richard.

Comment by kennardconsulting [ 07/Aug/10 ]

Created an attachment (id=1239)
With new JAR, dynamic add is good but dynamic reorder is not

Comment by kennardconsulting [ 07/Aug/10 ]

Ed,

Hurrah! The latest patch seems to fix the dynamic add issue. I can hook in to
PreRenderViewEvent and it seems to work really well.

However (and sorry to be such a gigantic pain in the ass) there is still a
problem. Specifically, I cannot reorder child components during
PreRenderViewEvent. I believe this scenario should be included as part of
being 'safe to manipulate the component tree'?

I attach a test case to demonstrate the issue. The test case reorders the child
components on the initial GET, but doesn't touch the tree upon POSTback.
However POSTback fails because the saveState/restoreState seems to get out-of-
sync.

But we're getting close!

Regards,

Richard.

Comment by Ed Burns [ 09/Aug/10 ]

Created an attachment (id=1240)
Fix for this bug, fourth iteration

Comment by Ed Burns [ 09/Aug/10 ]

Created an attachment (id=1242)
Fix for this bug. Fifth, and hopefully final, iteration

Comment by kennardconsulting [ 09/Aug/10 ]

Ed,

Awesome. Is this patch in the nightlies, or can I get a JAR?

Regards,

Richard.

Comment by Ed Burns [ 09/Aug/10 ]

Created an attachment (id=1243)
zip containing JSF jars for Richard Kennard

Comment by Jason Lee [ 09/Aug/10 ]

r=jdlee

Comment by Ed Burns [ 09/Aug/10 ]

Fix checked in r8543. Waiting for hudson to clear before committing to the 2.0.4 branch.

Comment by kennardconsulting [ 09/Aug/10 ]

Ed,

Sorry, the attached JARs come up as...

INFO: Initializing Mojarra 2.1.0 (SNAPSHOT 20100809-1609) for
context '/EventTest'

...but when I try them with EventTest-Reorder.zip I get the same error as
before?

Richard.

Comment by Ed Burns [ 10/Aug/10 ]

Committed to HEAD and MOJARRA_2_0X_ROLLING, r8545

Comment by kennardconsulting [ 11/Aug/10 ]

Sorry Ed,

I have tried the attachment, the Aug 10 nightly build and the Aug 11 nightly
build and the problem still seems the same? I drop the JARs into EventTest-
Reorder.zip and after POSTback I get:

java.lang.ClassCastException: com.sun.faces.application.view.StateHolderSaver
cannot be cast to [Ljava.lang.Object;

So this isn't fixed from my perspective. Should I open a new issue?

Richard.

Comment by Ed Burns [ 13/Aug/10 ]

Ok, here is the URL to try once you deploy the jsf-systest.war

http://localhost:8080/jsf-systest/faces/facelets/issue1757-dynamic-components.xhtml

I have attached the war to this issue. The glassfish runtime that has the
mojarra with the fix installed is at

https://javaserverfaces.dev.java.net/files/documents/1866/152201/glassfish-3.1-b13-mojarra-2.1-HEAD-20100813.zip

If you try this glassfish and it still doesn't work for you, then please re-open
the bug.

Comment by Ed Burns [ 13/Aug/10 ]

Created an attachment (id=1254)
War for richard to try.

Comment by kennardconsulting [ 13/Aug/10 ]

Ed,

Okay, here's what I did:

1. Downloaded the WAR and exploded it into Tomcat 6.0.20
2. Downloaded the Glassfish ZIP, extracted jsf-api.jar and jsf-impl.jar and put
them in jsf-systest/WEB-INF/lib
3. Hit http://localhost:8080/jsf-systest/faces/facelets/issue1727-facet-
conditional.xhtml (works okay)
4. Hit http://localhost:8080/jsf-systest/faces/facelets/issue1726.xhtml (works
okay)
5. Hit http://localhost:8080/jsf-systest/faces/facelets/issue1757-dynamic-
components.xhtml (just hangs and never returns a page)
6. Tried the same jsf-api.jar and jsf-impl.jar in my EventTest-Reorder.zip
(gets the same error)

Could you please try on Tomcat? Perhaps there is some other dependency going on
here?

Regards,

Richard.

Comment by Ed Burns [ 16/Aug/10 ]

RK> Ed,
RK>
RK> Okay, here's what I did:
RK>
RK> 1. Downloaded the WAR and exploded it into Tomcat 6.0.20
RK> 2. Downloaded the Glassfish ZIP, extracted jsf-api.jar and jsf-impl.jar and put
RK> them in jsf-systest/WEB-INF/lib

Richard, I sincerely appreciate your support on this and other issues,
but I have to say I'm a bit disappointed. Why do you think I went to
the time and trouble of uploading an entire glassfish dist for you, only
to have you essentially throw it aside unused.

I'll try to find a way to get our code, including the fix to this issue,
qualified on Tomcat. I don't want to give anyone any reasons for
switching to MyFaces from Mojarra.

However, I would like you to try it out using the glassfish I uploaded.

Thanks,

Ed

Comment by kennardconsulting [ 16/Aug/10 ]

Ed,

My deepest apologies for disappointing you. I am very grateful for all your
time and help, and I simply misunderstood your request. I test on a bunch of
different app servers (as I'm sure you do too) like Tomcat, Glassfish, JBoss
and Jetty, and (simply out of habit) I tend to try Tomcat first.

So I took the JARs out of the GlassFish you attached, and tried them on Tomcat,
and when they didn't work I didn't go any further and try them on anything
else. My mistake, sorry.

I just tried the Glassfish you attached and I'm afraid it doesn't even start up
for me? I can run the regular glassfish v3 fine. I get:

N:\glassfishv3>bin\asadmin start-domain domain1
Waiting for DAS to start ....
Started domain: domain1
Domain location: N:\glassfishv3\glassfish\domains\domain1
Log file: N:\glassfishv3\glassfish\domains\domain1\logs\server.log
Admin port for the domain: 4848
Command start-domain executed successfully.

N:\glassfishv3>bin\asadmin stop-domain domain1
Waiting for the domain to stop ....
Command stop-domain executed successfully.

But with your ZIP it just hangs:

C:\glassfishv3>bin\asadmin start-domain domain1
Waiting for the server to start ..................

I'm afraid I'm not very familiar with GlassFish v3 to debug it. The
domain1/logs/server.log seems to indicate it has started:

17/08/2010 12:20:26 PM com.sun.enterprise.admin.launcher.GFLauncherLogger info
INFO: JVM invocation command line:
N:\Program Files\Java\jdk1.6.0_20\bin\java.exe
-cp
C:/glassfishv3/glassfish/modules/glassfish.jar
-XX:+UnlockDiagnosticVMOptions
-XX:MaxPermSize=512m
-XX:NewRatio=2
-XX:+LogVMOutput
-XX:LogFile=C:\glassfishv3\glassfish\domains\domain1/logs/jvm.log
-Xmx512m
-client
javaagent:C:/glassfishv3/glassfish/lib/monitor/btrace
agent.jar=unsafe=true,noServer=true
-Dosgi.shell.telnet.maxconn=1
-Djdbc.drivers=org.apache.derby.jdbc.ClientDriver
-Dfelix.fileinstall.dir=C:\glassfishv3\glassfish/modules/autostart/
-Djavax.net.ssl.keyStore=C:\glassfishv3
\glassfish\domains\domain1/config/keystore.jks
-Dosgi.shell.telnet.port=6666
-Djava.security.policy=C:\glassfishv3
\glassfish\domains\domain1/config/server.policy
-Dfelix.fileinstall.log.level=3
-Dfelix.fileinstall.poll=5000
-Dcom.sun.aas.instanceRoot=C:\glassfishv3\glassfish\domains\domain1
-
Dcom.sun.enterprise.config.config_environment_factory_class=com.sun.enterprise.c
onfig.serverbeans.AppserverConfigEnvironmentFactory
-Dosgi.shell.telnet.ip=127.0.0.1
-Djava.endorsed.dirs=C:\glassfishv3\glassfish/modules/endorsed;C:\glassfishv3
\glassfish/lib/endorsed
-Dcom.sun.aas.installRoot=C:\glassfishv3\glassfish
-Djava.ext.dirs=N:\Program Files\Java\jdk1.6.0_20/lib/ext;N:\Program
Files\Java\jdk1.6.0_20/jre/lib/ext;C:\glassfishv3
\glassfish\domains\domain1/lib/ext
-Dfelix.fileinstall.bundles.new.start=true
-Djavax.net.ssl.trustStore=C:\glassfishv3
\glassfish\domains\domain1/config/cacerts.jks
-Dcom.sun.enterprise.security.httpsOutboundKeyAlias=s1as
-Djava.security.auth.login.config=C:\glassfishv3
\glassfish\domains\domain1/config/login.conf
-DANTLR_USE_DIRECT_CLASS_LOADING=true
-Dorg.glassfish.web.rfc2109_cookie_names_enforced=false
-
Djava.library.path=C:/glassfishv3/glassfish/lib;C:/Windows/System32;C:/glassfish
v3;C:/Windows/Sun/Java/bin;C:/Windows;C:/Program Files (x86)/NVIDIA
Corporation/PhysX/Common;C:/Windows/System32/wbem;C:/Windows/System32/WindowsPow
erShell/v1.0;N:/Program Files/Perforce;N:/Program
Files/Java/jdk1.6.0_20;C:/bin;N:/My Documents/Kennard
Consulting/Libraries/apache-ant-1.7.1/bin
com.sun.enterprise.glassfish.bootstrap.ASMain
-domainname
domain1
-asadmin-args
start-domain,,,domain1
-instancename
server
-verbose
false
-debug
false
-asadmin-classpath
C:/glassfishv3/glassfish/modules/admin-cli.jar
-asadmin-classname
com.sun.enterprise.admin.cli.AsadminMain
-upgrade
false
-type
DAS
-domaindir
C:/glassfishv3/glassfish/domains/domain1
-read-stdin
true
17/08/2010 12:20:26 PM com.sun.enterprise.admin.launcher.GFLauncherLogger info
INFO: Successfully launched in 3 msec.

But the command line never returns and my browser cannot see anything (not even
a GlassFish 404 page). This is before I tried dropping the WAR in. So I'm
afraid I cannot confirm if it works for me?

Regards,

Richard.

Comment by Ed Burns [ 18/Aug/10 ]

Hi Richard,

I don't know why the glassfish zip isn't working. In any case, I'm endeavoring
to get our hudson job for tomcat and jetty support working again.

I'll keep this open with the platform changed to tomcat and only close it when
it works there.

Comment by kennardconsulting [ 19/Aug/10 ]

Terrific. Thanks, Ed. Happy to test whatever you have, whenever it's ready, on
whatever platform you want me to

Richard.

Comment by kennardconsulting [ 14/Sep/10 ]

Hi Ed,

Is there any movement on this? I tried the latest nightly but it still didn't
work for me. I was really hoping to get this fix in ready for my final 1.0
release of Metawidget.

Regards,

Richard.

Comment by Ed Burns [ 14/Sep/10 ]

Actually, yes, there has been movement on this. A user has contributed content
to enable our automated tests to run on tomcat, under issue 1497. He said all
the tests run, including the one I added for you.

Once sheetalv gets 1497 committed, I'll investigate your claim that it still
doesn't work. Thanks for your patience.

Comment by kennardconsulting [ 14/Sep/10 ]

Terrific. Doubtless I am just using the wrong JAR or something, so it will be
great to get this one resolved!

Richard.

Comment by kennardconsulting [ 29/Sep/10 ]

Ed,

Can I beg you to divert some time to this issue? I am disturbed by the comments
on issue 1497 that suggest everything is fine, because they really aren't. The
EventTest-Reorder.zip I sent 2 months ago is still not working.

In desperation, I tried building various branches from SVN (dropping the JARs
in to EventTest-Reorder.zip running on Tomcat 6.0.20). Here is what I see:

  • MOJARRA_2_0_3_ROLLING works but has the same problem with reordering that I
    raised on 7 August.
  • trunk, MOJARRA_2_0X_ROLLING, and the JARs from your GlassFish all produce:
    java.lang.ClassCastException: com.sun.faces.application.view.StateHolderSaver
    cannot be cast to [Ljava.lang.Object;

I'm confident if you try this yourself you will see the same result. I would be
most grateful for your time.

Richard.

Comment by Ed Burns [ 30/Sep/10 ]

Hello Richard,

I know how important metawidget is. I want to see it work too. I haven't forgotten the issue, but I'm
trying to do it the right way. In this case, the lack of tomcat support in our automated testing system is
the root cause of the problem. Therefore, I've indicated that this issue is blocked by issue 1497.

If you want to get this issue fixed, please agitate for getting issue 1497 fixed. Voting, commenting, and
contacting the person to whom the bug is assigned helps.

Comment by kennardconsulting [ 30/Sep/10 ]

Sorry Ed, I'll go do that now.

I was under the impression issue 1497 was already 'fixed', or at least had
already concluded that 'everything is fine'. That being the case, you may need
to manually work against EventTest-Reorder.zip so that you can see what I'm
seeing?

Regards,

Richard.

P.S. Thanks for acknowledging Metawidget. I worry that ever since this issue
broke away from issue 1313 (which the 'big guns' cared about), I'm just the
little guy and will have had a hard time getting this resolved

Comment by kennardconsulting [ 04/Oct/10 ]

Outstanding issues now consolidated under issue 1826

Comment by Ed Burns [ 08/Oct/10 ]

Here is a youtube video I made with screenflow that shows the bug is fixed when running on tomcat
6.0.29.

http://www.youtube.com/watch?v=n-Cr1Gfb3Ko

I have a quicktime with higher resolution if you need it, but it's 263MB and would take a while to upload.

Comment by kennardconsulting [ 08/Oct/10 ]

Ed,

A YouTube video? Wow! Given the lengths you have gone to to demonstrate this
issue to me, I can tell you're annoyed. My apologies for being such a pain in
the ass.

From the video, however, it appears you are testing the wrong EventTest.zip. I
agree the one you tested works fine. It is also part of the Acid Test in 1826
where it works fine too.

But we have been through a couple iterations of EventTest since then. The
latest one in the attachment list, EventTest-Reorder.zip, is the one I am stuck
on. It gives an error for me, and for you guys too according to sheetalv's
comments under 1826.

So I believe you can reproduce this. But you can leave 1757 closed as I have
consolidated all my problems under 1826.

Thanks again for going to such great lengths!

Richard.

Comment by Manfred Riem [ 22/Mar/12 ]

Closing resolved issue out





[JAVASERVERFACES-1727] Miltiple components in <f:facet> are not marked&swept properly Created: 07/Jul/10  Updated: 22/Mar/12  Resolved: 10/Aug/10

Status: Closed
Project: javaserverfaces
Component/s: facelets
Affects Version/s: current
Fix Version/s: 2.1_gf31_m4

Type: Bug Priority: Major
Reporter: mst_70 Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File changebundle.txt     File jsf-systest.war    
Issuezilla Id: 1,727
Status Whiteboard:

size_medium importance_large

Tags: adf, adf_medium

 Description   

ComponentSupport.markForDeletion()/finalizeForDeletion() do not descend into the
UIPanel created to wrap multiple components inside of <f:facet>

If you place <c:if> inside of <f:facet> with multiple components to display one
of them conditionally, I expect that the no-longer-displayed component will not
be removed from the UIPanel.



 Comments   
Comment by Ed Burns [ 07/Jul/10 ]

Accept for GlassFish 3.1 M4.

Comment by Ed Burns [ 04/Aug/10 ]

Created an attachment (id=1235)
Visit http://localhost:8080/jsf-systest/faces/facelets/issue1727-facet-conditional.xhtml to test

Comment by Ed Burns [ 04/Aug/10 ]

Stevan, can you please deploy the attachment from today 16:49 and visit that URL and see if that
shows the problem.

Comment by mst_70 [ 04/Aug/10 ]

Hey Ed, it's actually Max, not Stevan

In order to see the issue, we would need to disable partial state saving
(otherwise, the viewScope value is getting modified after the tags are executed).

Comment by mst_70 [ 04/Aug/10 ]

Hey Ed,

Sorry - I did not realize that in the latest builds the tags are executed during
render_response with the partial state saving enabled. To reproduce the bug, you
have to replace both references to "viewScope" in your test page with
"sessionScope".

Here is what's going on with the current version of the test:
When you uncheck the checkbox, the tags are executed during the restore_view
phase. At this point, one would expect that tag execution should produce four
children (the previous request's state), but it produces two. It happens because
viewScope attributes are not there. Using sessionScope fixes tag execution
problem during restore_view, and the problem reproduces as expected.

By the way, do you think that viewScope attributes being unavailable during
restore_view is a bug? Should it be logged?

Thanks,
Max

Comment by Ed Burns [ 05/Aug/10 ]

This is a very tricky issue. Max, what do you think of the following approach.

I want to affect the fix as narrowly as possible. These are the conditions under which the bug
manifests.

1. Within a facet...
2. there are multiple children, but no explicit UIPanel.
3. Within the facet, there is also a <c:if>...
4. that evaluates to true at some point and then becomes false.

I would like to affect the fix by manually performing the mark for deletion on the implicit panel
from the IfHandler.apply(), but only if we detect conditions 1 and 2 to be true.

I tried your other approach and was unable to get it working that way.

What do you think of this approach?

Ed

Comment by Ed Burns [ 06/Aug/10 ]

I have discovered the cause of the problem. It happens regardless of the use or non-use of partial
state saving. The problem is that when the facelet tree is executed during render view, the ordering
gets reversed.

I'm trying to discover why. I suspect it has something to do with
ComponentTagHandlerDelegateImpl.findComponent().

Comment by Ed Burns [ 06/Aug/10 ]

As suspected, the problem is indeed in ComponentTagHandlerDelegateImpl, but in apply(), not
findChild(). The problem has to do with the mark and sweep deletion system, which is also at the
heart of issue 1757. In fact, both of these issues deal with dynamic children. In the case of issue
1757, the dynamism comes from using <c:if>. Perhaps I can close two issues with one fix? We'll see.

Comment by mst_70 [ 06/Aug/10 ]

Ed, I thought we agreed yesterday that the root cause was not descending into
the UIPanel in maekForDeletion() and finalizeForDeletion(). Did my proposed fix
not work?

Comment by Ed Burns [ 09/Aug/10 ]

Max, either I didn't understand your approach, or it didn't work. Both are
possible. Today, I can state that I understand the relationship between
Facelets' mark and sweep system, and dynamic components, thanks to issue 1757.
I have a fix for that one in place. Perhaps it will help me understand this one
better.

Ed

Comment by Ed Burns [ 09/Aug/10 ]

Max, now I understand your solution. Would you be so kind as to review the attachment I'm about to
submit?

Comment by Ed Burns [ 09/Aug/10 ]

Created an attachment (id=1244)
Fix for this bug, first iteration.

Comment by Jason Lee [ 09/Aug/10 ]

r=jdlee

Comment by Ed Burns [ 09/Aug/10 ]

Running automated tests now.

Comment by mst_70 [ 10/Aug/10 ]

Thanks, Ed. The change totally makes sense.
One very minor thing - I think you might have left a change in the code that was
done for debugging purposes only:

String id = null;
panelGroup.setId(id = getViewRoot(ctx.getFacesContext(), parent).createUniqueId());

The id variable is not used anywhere in the method.

Comment by Ed Burns [ 10/Aug/10 ]

Committed to HEAD and MOJARRA_2_0X_ROLLING, r8546

Comment by Manfred Riem [ 22/Mar/12 ]

Closing resolved issue out





[JAVASERVERFACES-1720] Review latest HEAD for 1.2_15 with fixes for 1628, 1630, 1631,1632, 1620, 1621, 1619 Created: 30/Jun/10  Updated: 26/Jun/12  Resolved: 13/Jul/10

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.0.2
Fix Version/s: 2.1_gf31_m3

Type: Task Priority: Major
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File 1720-diffs-working.txt     Zip Archive 1720-research.zip     Text File 1720.txt     Text File 1720.txt     Text File changebundle.txt     Zip Archive newfiles.zip    
Issuezilla Id: 1,720
Status Whiteboard:

size_large importance_large

Tags: adf, performance

 Description   

Just do an extra check to make sure nothing was left behind.



 Comments   
Comment by Ed Burns [ 30/Jun/10 ]

This is a TASK for GlassFIsh 3.1 M3

Comment by Ed Burns [ 30/Jun/10 ]

I used the following CVS commands to research this task.

Set the default branch to be JSF_1_2X_ROLLING

cvs admin -bJSF_1_2X_ROLLING

Collect the diffs on this branch between 2010-04-01 and today.

cvs log -d"2010-04-01<2010-06-30" > cvslog-20100401-20100630.txt

Collect the set of files claimed to be modified in the manually entered
CVS log messages.

grep "^M " cvslog-20100401-20100630.txt > cvslog-20100401-20100630-log-message-
modified-files.txt

sort cvslog-20100401-20100630-log-message-modified-files.txt | uniq

store this output back into
cvslog-20100401-20100630-log-message-modified-files.txt

Collect the set of files actually modified by looking for lines starting
with "RCS file:" that correspond to lines that start with "revision ".
I used an emacs keyboard macro for this. Collect this output into
cvslog-20100401-20100630-rcs-modified-files-filenames-only.txt Massage
this file to have the same format as log-message-modified-files.txt.

Diff the two files. By analyzing the diffs, I can see that the CVS
added files show up in the Attic in the RCS file: prefixed lines.
Therefore, I conclude that the RCS file: prefixed lines gives me the
complete set of changed, added, deleted files.

Here it is:

.cvsignore
common/ant/common.xml
jsf-api/src/javax/faces/webapp/UIComponentClassicTagBase.java
jsf-api/test/javax/faces/webapp/AttributeTagTestCase.java
jsf-ri/build-tests.xml
jsf-ri/build.xml
jsf-ri/src/com/sun/faces/application/ApplicationAssociate.java
jsf-ri/src/com/sun/faces/application/ApplicationImpl.java
jsf-ri/src/com/sun/faces/application/ViewHandlerImpl.java
jsf-ri/src/com/sun/faces/config/ConfigureListener.java
jsf-ri/src/com/sun/faces/config/InitFacesContext.java
jsf-ri/src/com/sun/faces/config/configprovider/WebResourceProvider.java
jsf-ri/src/com/sun/faces/el/Attic/ChainTypeCompositeELResolver.java
jsf-ri/src/com/sun/faces/el/Attic/DemuxCompositeELResolver.java
jsf-ri/src/com/sun/faces/el/ChainAwareVariableResolver.java
jsf-ri/src/com/sun/faces/el/ELUtils.java
jsf-ri/src/com/sun/faces/el/FacesCompositeELResolver.java
jsf-ri/src/com/sun/faces/el/ImplicitObjectELResolver.java
jsf-ri/src/com/sun/faces/el/ImplicitObjectELResolverForJsp.java
jsf-ri/src/com/sun/faces/el/ManagedBeanELResolver.java
jsf-ri/src/com/sun/faces/el/ScopedAttributeELResolver.java
jsf-ri/src/com/sun/faces/el/VariableResolverChainWrapper.java
jsf-ri/src/com/sun/faces/el/VariableResolverImpl.java
jsf-ri/src/com/sun/faces/lifecycle/ELResolverInitPhaseListener.java
jsf-ri/src/com/sun/faces/mgbean/BeanBuilder.java
jsf-ri/src/com/sun/faces/mgbean/BeanManager.java
jsf-ri/src/com/sun/faces/taglib/jsf_core/LoadBundleTag.java
jsf-ri/src/com/sun/faces/taglib/jsf_core/SubviewTag.java
jsf-ri/src/com/sun/faces/taglib/jsf_core/ViewTag.java
jsf-ri/src/com/sun/faces/util/RequestStateManager.java
jsf-ri/src/com/sun/faces/util/Util.java
jsf-ri/systest-per-webapp/add-elresolver-and-replace-variableresolver-
programmatically/src/java/com/sun/faces/systest/Attic/AddELResolverAndReplaceVariableresolverP
rogrammaticallyTestCase.java
jsf-ri/systest-per-webapp/add-elresolver-and-replace-variableresolver-
programmatically/src/java/com/sun/faces/systest/Attic/Bean.java
jsf-ri/systest-per-webapp/add-elresolver-and-replace-variableresolver-
programmatically/src/java/com/sun/faces/systest/Attic/NewELResolver.java
jsf-ri/systest-per-webapp/add-elresolver-and-replace-variableresolver-
programmatically/src/java/com/sun/faces/systest/Attic/NewVariableResolver.java
jsf-ri/systest-per-webapp/add-elresolver-and-replace-variableresolver-
programmatically/src/java/com/sun/faces/systest/Attic/ProgrammaticAddELResolverListenerAndSet
VariableResolver.java
jsf-ri/systest-per-webapp/add-elresolver-and-replace-variableresolver-
programmatically/web/Attic/test.jsp
jsf-ri/systest-per-webapp/add-elresolver-and-replace-variableresolver-
programmatically/web/Attic/test1.jsp
jsf-ri/systest-per-webapp/add-elresolver-and-replace-variableresolver-
programmatically/web/WEB-INF/Attic/faces-config.xml
jsf-ri/systest-per-webapp/add-elresolver-and-replace-variableresolver-
programmatically/web/WEB-INF/Attic/web.xml
jsf-ri/systest-per-webapp/build-tests.xml
jsf-ri/systest-per-webapp/build.xml
jsf-ri/systest-per-webapp/replace-variableresolver-and-add-elresolver-
programmatically/src/java/com/sun/faces/systest/Attic/Bean.java
jsf-ri/systest-per-webapp/replace-variableresolver-and-add-elresolver-
programmatically/src/java/com/sun/faces/systest/Attic/NewELResolver.java
jsf-ri/systest-per-webapp/replace-variableresolver-and-add-elresolver-
programmatically/src/java/com/sun/faces/systest/Attic/NewVariableResolver.java
jsf-ri/systest-per-webapp/replace-variableresolver-and-add-elresolver-
programmatically/src/java/com/sun/faces/systest/Attic/ProgrammaticSetVariableResolverAndAddEL
ResolverListenerFilter.java
jsf-ri/systest-per-webapp/replace-variableresolver-and-add-elresolver-
programmatically/src/java/com/sun/faces/systest/Attic/ReplaceVariableResolverAndAddELResolver
ProgrammaticallyTestCase.java
jsf-ri/systest-per-webapp/replace-variableresolver-and-add-elresolver-
programmatically/web/Attic/test.jsp
jsf-ri/systest-per-webapp/replace-variableresolver-and-add-elresolver-
programmatically/web/Attic/test1.jsp
jsf-ri/systest-per-webapp/replace-variableresolver-and-add-elresolver-
programmatically/web/WEB-INF/Attic/faces-config.xml
jsf-ri/systest-per-webapp/replace-variableresolver-and-add-elresolver-
programmatically/web/WEB-INF/Attic/web.xml
jsf-ri/systest-per-webapp/replace-variableresolver-
programmatically/src/java/com/sun/faces/systest/Attic/Bean.java
jsf-ri/systest-per-webapp/replace-variableresolver-
programmatically/src/java/com/sun/faces/systest/Attic/NewVariableResolver.java
jsf-ri/systest-per-webapp/replace-variableresolver-
programmatically/src/java/com/sun/faces/systest/Attic/ProgrammaticAddVariableResolverListener.j
ava
jsf-ri/systest-per-webapp/replace-variableresolver-
programmatically/src/java/com/sun/faces/systest/Attic/ReplaceVariableResolverTestCase.java
jsf-ri/systest-per-webapp/replace-variableresolver-programmatically/web/Attic/test.jsp
jsf-ri/systest-per-webapp/replace-variableresolver-programmatically/web/Attic/test1.jsp
jsf-ri/systest-per-webapp/replace-variableresolver-programmatically/web/WEB-INF/Attic/faces-
config.xml
jsf-ri/systest-per-webapp/replace-variableresolver-programmatically/web/WEB-INF/Attic/web.xml
jsf-ri/systest/build-tests.xml
jsf-ri/systest/build.xml
jsf-ri/systest/src/com/sun/faces/systest/lifecycle/ManagedBeanLifecycleAnnotationTestCase.java
jsf-ri/systest/src/com/sun/faces/systest/model/Attic/NoneScopeBean.java
jsf-ri/systest/src/com/sun/faces/systest/model/TestBean.java
jsf-ri/systest/src/com/sun/faces/systest/resources/Attic/ResourceBundleELResolverTestCase.java
jsf-ri/systest/web/Attic/noneScopeBean.jsp
jsf-ri/systest/web/Attic/resourceBundle05.jsp
jsf-ri/systest/web/WEB-INF/faces-config.xml
jsf-ri/test/com/sun/faces/config/ConfigureListenerTestCase.java
jsf-ri/test/com/sun/faces/el/Attic/TestNestedELResolver.java
nbproject/project.xml

Comment by Ed Burns [ 30/Jun/10 ]

Created an attachment (id=1189)
research for this task

Comment by Ed Burns [ 01/Jul/10 ]

When trying to estimate this task, the one class that's giving me trouble is jsf-
ri/src/com/sun/faces/config/configprovider/WebResourceProvider.java. This class is not in 2.0.

Comment by Ed Burns [ 01/Jul/10 ]

triage

Comment by Ed Burns [ 01/Jul/10 ]

I estimate that this task will take about 17 pomodori.

Comment by Ed Burns [ 01/Jul/10 ]

Target to m3

Comment by Ed Burns [ 02/Jul/10 ]

Created an attachment (id=1191)
Pruned down diffs. Only contains meaningful changes

Comment by Ed Burns [ 02/Jul/10 ]

There are 54 diff regions in the latest attachment. I think this equates to about a half day of work to
carefully apply them.

Comment by Ed Burns [ 02/Jul/10 ]

Created an attachment (id=1192)
fix in progress, changed files

Comment by Ed Burns [ 02/Jul/10 ]

Created an attachment (id=1193)
Fix in progress, new files

Comment by Ed Burns [ 13/Jul/10 ]

Created an attachment (id=1198)
Fix in progress

Comment by Ed Burns [ 13/Jul/10 ]

Created an attachment (id=1199)
Another snapshot, before my machine crashes.

Comment by Ed Burns [ 13/Jul/10 ]

FIx checked in. Hudson successful.

Comment by Manfred Riem [ 22/Mar/12 ]

Closing resolved issue out





[JAVASERVERFACES-1685] Reduce performance impact from syncSession Created: 24/May/10  Updated: 06/Jun/14  Resolved: 11/Oct/12

Status: Closed
Project: javaserverfaces
Component/s: lifecycle
Affects Version/s: 1.2_14
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Ed Burns Assignee: Manfred Riem
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All
URL: https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=789


Attachments: Text File i_jsf_1685_JSF_1_2X_ROLLING.patch     Text File i_jsf_1685_JSF_1_2X_ROLLING.patch    
Issue Links:
Related
is related to JAVASERVERFACES-3324 Review fix for JAVASERVERFACES-1685 f... Closed
Issuezilla Id: 1,685
Status Whiteboard:

size_large importance_medium

Tags: ADF, performance

 Description   

When com.sun.faces.application.WebappLifecycleListener.syncSessionScopedBeans is
called, it makes a setAttribute() call for all session beans it is managing.
This is potentially an expensive and needless operation – if the application is
being run in an HA configuration, the setAttribute() call marks the attribute as
one where the state has changed and needs to be replicated. However, in many
cases the attribute hasn't actually changed, and the time spent for replication
is wasted. We find in a typical JSF app that these calls can be avoided as much
as 66% of the time.

The setAttribute() call should be made only when the attribute in question has
actually changed.



 Comments   
Comment by Ed Burns [ 22/Jun/10 ]

triage

Comment by Ed Burns [ 28/Jun/10 ]

Change target milestone to 2.1

Comment by Ed Burns [ 01/Jul/10 ]

Target M4

Comment by Ed Burns [ 01/Jul/10 ]

Target to m3

Comment by Ed Burns [ 15/Jul/10 ]

Fix checked in.

Comment by Ed Burns [ 19/Jul/10 ]

Actually marked as fixed.

Comment by Ed Burns [ 19/Jul/10 ]
      • Issue 1597 has been marked as a duplicate of this issue. ***
Comment by Ed Burns [ 19/Apr/11 ]

We have a request to backport this to JSF 1.2.

Comment by Ed Burns [ 20/Apr/11 ]

Patch from JSF_1_2X_ROLLING branch.

Comment by Manfred Riem [ 11/Oct/12 ]

Since the "com.sun.faces.enableAgressiveSessionDirtying" flag is not enabled by default the runtime will not be impacted by the call to syncSession unless the flag is turned on. If any more work needs to be done, please file an issue that describes what needs to be done.





[JAVASERVERFACES-1682] System event listener registered on wrong component after postback Created: 20/May/10  Updated: 26/Jun/12  Resolved: 03/Aug/10

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.0.1
Fix Version/s: 2.1_gf31_m4

Type: Bug Priority: Major
Reporter: aschwart Assignee: Ed Burns
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 1,682
Status Whiteboard:

size_large importance_medium

Tags: adf, adf_medium

 Description   

I have a custom component with a system event listener:

@ListenerFor(systemEventClass=PostAddToViewEvent.class)
@FacesComponent("foo.PostAddTester")
public class PostAddTester extends UIComponentBase implements ComponentSystemEventListe
ner

{ ... }

On the initial view creation, PostAddToViewEvents are delivered to my component as expected.

However, after a postback with full state saving (partial state saving disabled), my listener is called back,
but on the parent component instance.

I believe that the issue is that when restoring the view, the component stack is not up to date - ie. the
parent is at the top of the stack instead of the actual component being restored.

The following spec issue is likely related:

https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=792



 Comments   
Comment by Ed Burns [ 01/Jun/10 ]

Add adf keyword.

Comment by Ed Burns [ 01/Jun/10 ]

add adf_medium

Comment by Ed Burns [ 03/Jun/10 ]

Add keywords

Comment by Ed Burns [ 11/Jun/10 ]

triage

Comment by Ed Burns [ 21/Jun/10 ]

edburns

Comment by Ed Burns [ 28/Jun/10 ]

Target for GlassFish 3.1 M4

Comment by Ed Burns [ 20/Jul/10 ]

adf_medium

Comment by Ed Burns [ 03/Aug/10 ]

I think the fix for issue 1313 may have fixed this.

In any case, I have committed an automated test to demonstrate that it works.

Comment by Manfred Riem [ 22/Mar/12 ]

Closing resolved issue out





[JAVASERVERFACES-1681] Unnecessary event delivery during tag re-execution Created: 20/May/10  Updated: 26/Jun/12  Resolved: 27/Feb/12

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.0.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: aschwart Assignee: rogerk
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 1,681
Status Whiteboard:

size_large importance_medium

Tags: adf, adf_medium

 Description   

Encountered while analyzing the following thread:

http://mail-archives.apache.org/mod_mbox/myfaces-
dev/201005.mbox/%3c4BF34C9E.3010108@oracle.com%3e

When executing tags against an existing component tree (during render response on postbacks),
Facelets temporarily removes and then immediately re-adds each component. This results in
PreRemove/PostAdd events being delivered.

Aside form being unnecessarily expensive, this is not the right abstraction. The fact that Facelets
happens to remove/re-add components during tag execution for its own purposes is incidental.
Component/page authors should not be exposed to this - it is an implementation detail of Facelets.



 Comments   
Comment by Ed Burns [ 01/Jun/10 ]

Add adf keyword.

Comment by Ed Burns [ 01/Jun/10 ]

Move to adf_medium

Comment by Ed Burns [ 11/Jun/10 ]

triage. This one seems like a hard one.

Comment by rogerk [ 25/Jun/10 ]

triage

Comment by rogerk [ 29/Jun/10 ]

target

Comment by rogerk [ 01/Jul/10 ]

re-target

Comment by rogerk [ 14/Sep/10 ]

ms6

Comment by rogerk [ 28/Sep/10 ]

Spoke with Andy Schwartz. This appears to be an impl only change.
If time permits we can attempt to get it in. Worst case is we can deliver
as first patch release for 2.1 (2.1_B01)

Comment by rogerk [ 30/Sep/10 ]

Andy and I agreed that as a last resort we could target this for first 2.1 patch
release.

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by rogerk [ 27/Feb/12 ]

This has been fixed since 2.0.3.
Look for the class/method:

com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.doOrphanedChildCleanup().





[JAVASERVERFACES-1680] Re-creation of composite component children/facets Created: 20/May/10  Updated: 22/Jul/13  Resolved: 25/Jun/12

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.0.1
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: aschwart Assignee: Manfred Riem
Resolution: Duplicate Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File 1680-in-progress.patch     Text File changebundle.txt    
Issue Links:
Duplicate
duplicates JAVASERVERFACES-2957 Tree creation is broken when using <c... Closed
duplicates JAVASERVERFACES-2053 Tree creation is broken when using <c... Closed
is duplicated by JAVASERVERFACES-1951 Restoring of dynamic component fails ... Closed
is duplicated by JAVASERVERFACES-2099 Composite component children Closed
Related
is related to JAVASERVERFACES-2040 Partial state saving broken for compo... Closed
is related to JAVASERVERFACES-1985 PostAddToViewEvent publishing conditi... Closed
is related to JAVASERVERFACES-2119 component not getting restored becaus... Closed
Issuezilla Id: 1,680
Status Whiteboard:

size_large importance_large

Tags: ADF, composite

 Description   

Encountered while analyzing the following thread:

http://mail-archives.apache.org/mod_mbox/myfaces-
dev/201005.mbox/%3c4BF34C9E.3010108@oracle.com%3e

The current implementations of <composite:insertFacet>/<composite:insertChildren> results in
components be removed from their original parents and inserted into the composite component
implementation in response to PostAddToViewEvents. As a result, when subsequently executing tags
against an existing component tree (on postback), the relocated components will no longer be found in
their original locations and will be re-created. This has two problems:

1. Re-creating these components/subtrees is unnecessarily expensive.
2. Re-creating these components/subtrees results in a loss of state - ie. components are reset to their
initial state.

#2 means that stateful components, such as Trinidad's <tr:showDetail>, cannot be used as composite
component children/facets.

A possible solution might be to follow the pattern used by the Facelets
<ui:composition>/<ui:define>/<ui:insert> - ie. use a TemplateClient to ensure that the components
are inserted in the desired target location during tag execution.



 Comments   
Comment by Ed Burns [ 01/Jun/10 ]

Add adf keyword.

Comment by Ed Burns [ 01/Jun/10 ]

Move to P2

Comment by Ed Burns [ 03/Jun/10 ]

Add keywords

Comment by Ed Burns [ 11/Jun/10 ]

Sheetal

Comment by Ed Burns [ 11/Jun/10 ]

triage

Comment by Ed Burns [ 28/Jun/10 ]

Target for GlassFish 3.1 M4

Comment by Ed Burns [ 05/Aug/10 ]

Created an attachment (id=1237)
Patch of in progress work for Sheetal to take and run with.

Comment by sheetalv [ 11/Aug/10 ]

Created an attachment (id=1249)
changes as part of the fix for this issue

Comment by Ed Burns [ 11/Aug/10 ]

Looks good. r=edburns.

Please make sure to include the issuetracker URL and the list of modified files in your svn commit
log message.

I prefer to just edit the changebundle.txt to remove the diffs, then do svn commit -F
changebundle.txt <filelist>

It's always good to explicitly list the files to be committed on the svn commit line so you don't
inadvertently commit something.

Commit it to HEAD. Then, when the http://rindge.sfbay.sun.com:7070/hudson/ shows clear on the
JSF_HEAD jobs, commit to MOJARRA_2_0X_ROLLING.

Comment by sheetalv [ 12/Aug/10 ]

fixed in r=8550 of the trunk.
and r=8552 of 2.0.4 branch.

Comment by sheetalv [ 08/Oct/10 ]

Though TemplateClient API is the way to go for this issue's solution, we have
decided that we will not fix it for now. We do have a solution in place that
works. It is'nt the best solution as far as performance is concerned. The
current solution works in a bunch of scenarios pointed out as being problematic
in the email thread in the above comments.
We will look into fixing this issue with the TemplateClient API in the next release.

Comment by Ed Burns [ 08/Jun/11 ]

We really need to fix this the right way.

Comment by Mathias Werlitz [ 17/Jun/11 ]

The problem description is very similar to what I found out goes wrong when analyzing JAVASERVERFACES-2040 and JAVASERVERFACES-2053. I also already created a patch for the re-creation issue.





[JAVASERVERFACES-1679] UIViewRoot.addComponentResources() assumes component ids are unique Created: 20/May/10  Updated: 17/Apr/13  Resolved: 17/Apr/13

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.0.1
Fix Version/s: None

Type: Bug Priority: Trivial
Reporter: aschwart Assignee: Unassigned
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 1,679
Status Whiteboard:

size_medium importance_medium

Tags: ADF

 Description   

Encountered while analyzing the following thread:

http://mail-archives.apache.org/mod_mbox/myfaces-
dev/201005.mbox/%3c4BF34C9E.3010108@oracle.com%3e

UIViewRoot.addComponentResources() checks to see whether a resource has already been added by
comparing ids:

List<UIComponent> facetChildren = getComponentResources(context,
target,
true);
String id = componentResource.getId();
if (id != null) {
for (UIComponent c : facetChildren) {
if (id.equals(c.getId()))

{ facetChildren.remove(c); }

}
}

This, however, assumes that component ids are unique across the page, whereas component ids only
need to be unique for each naming container. As a result, if the same id is used for different resources
coming from different naming containers, this code will result in non-obvious failures.



 Comments   
Comment by Ed Burns [ 01/Jun/10 ]

Add adf keyword.

Comment by Ed Burns [ 11/Jun/10 ]

triage

Comment by Ed Burns [ 06/Jun/11 ]

Bulk assign all impl issues to Roger.

Comment by Manfred Riem [ 19/Nov/12 ]

Can you please attach an example application (with sources) that demonstrates the problem?

Comment by Manfred Riem [ 18/Feb/13 ]

Lowering priority because of no response

Comment by Manfred Riem [ 18/Mar/13 ]

Lowering priority because of no response

Comment by Manfred Riem [ 17/Apr/13 ]

Closing because of inactivity





[JAVASERVERFACES-1678] ScriptStyleBaseRenderer passes getClientId() value to findComponent() Created: 20/May/10  Updated: 14/Oct/14  Resolved: 09/Apr/13

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.0.1
Fix Version/s: None

Type: Bug Priority: Trivial
Reporter: aschwart Assignee: Unassigned
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Related
is related to JAVASERVERFACES-3485 prependId="false" has incorrect inter... Closed
Issuezilla Id: 1,678
Status Whiteboard:

size_small importance_small

Tags: ADF

 Description   

Encountered while analyzing the following thread:

http://mail-archives.apache.org/mod_mbox/myfaces-
dev/201005.mbox/%3c4BF34C9E.3010108@oracle.com%3e

ScriptStyleBaseRenderer attempts to ensure that #

{cc}

EL context is set up for components that it
relocates to the UIViewRoot. This results in calls to findComponent() in order to locate the composite
component at render time.

The value passed into findComponent() is a client id:

UIComponent cc = UIComponent.getCurrentCompositeComponent(context);
if (cc != null) {
component.getAttributes().put(COMP_KEY, cc.getClientId(context))

The problem with this is that client ids can include context provided by ancestor naming containers.
Since findComponent() does not go through component implementations, it cannot cope with client ids
that include naming container-specific information.

Instead of calling getClientId(), this code would need to manually build up a findComponent()-friendly
id.



 Comments   
Comment by Ed Burns [ 01/Jun/10 ]

Add adf keyword.

Comment by Ed Burns [ 11/Jun/10 ]

triage

Comment by Ed Burns [ 06/Jun/11 ]

Bulk assign all impl issues to Roger.

Comment by Manfred Riem [ 08/Jan/13 ]

Can you verify if this is still a problem on the latest 2.1 release?

Comment by Manfred Riem [ 12/Feb/13 ]

Lowering priority because of no response

Comment by Manfred Riem [ 12/Mar/13 ]

Lowering priority because of no response

Comment by Manfred Riem [ 09/Apr/13 ]

Closing out because of inactivity





[JAVASERVERFACES-1677] ScriptStyleBaseRenderer calls findComponent() even when no comp to find Created: 20/May/10  Updated: 26/Jun/12  Resolved: 08/Mar/12

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.0.1
Fix Version/s: 2.1.8, 2.2.0-m01

Type: Bug Priority: Major
Reporter: aschwart Assignee: rogerk
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File changebundle-1677.txt    
Issuezilla Id: 1,677
Status Whiteboard:

size_small importance_medium

Tags: adf

 Description   

Encountered while analyzing the following thread:

http://mail-archives.apache.org/mod_mbox/myfaces-
dev/201005.mbox/%3c4BF34C9E.3010108@oracle.com%3e

ScriptStyleBaseRenderer attempts to ensure that #

{cc}

EL context is set up for components that it
relocates to the UIViewRoot. This results in calls to findComponent() in order to locate the composite
component at render time:

public void encodeBegin(FacesContext context, UIComponent component)
throws IOException {

String ccID = (String) component.getAttributes().get(COMP_KEY);
UIComponent cc = context.getViewRoot().findComponent(':' + ccID);

Note that findComponent() is called even if ccID is null.



 Comments   
Comment by Ed Burns [ 01/Jun/10 ]

Add adf keyword.

Comment by Ed Burns [ 11/Jun/10 ]

triage

Comment by Ed Burns [ 06/Jun/11 ]

Bulk assign all impl issues to Roger.

Comment by rogerk [ 12/Jul/11 ]

changes.

Comment by rogerk [ 12/Jul/11 ]

Reviewed and approved by Andy Schwartz (r=aschwart)
Committed to trunk:
Sending jsf-ri/src/main/java/com/sun/faces/renderkit/html_basic/ScriptStyleBaseRenderer.java
Transmitting file data .
Committed revision 9196.

Comment by rogerk [ 08/Mar/12 ]

reopen for fix version

Comment by rogerk [ 08/Mar/12 ]

fix version

Comment by rogerk [ 08/Mar/12 ]

Committed to MOJARRA_2_1X_ROLLING branch:
Sending jsf-ri/src/main/java/com/sun/faces/renderkit/html_basic/ScriptStyleBaseRenderer.java
Transmitting file data .
Committed revision 9751.





[JAVASERVERFACES-1676] ScriptStyleBaseRenderer uses potentially expensive findComponent() calls Created: 20/May/10  Updated: 14/Oct/14  Resolved: 29/Mar/13

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.0.1
Fix Version/s: None

Type: Bug Priority: Trivial
Reporter: aschwart Assignee: Unassigned
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Related
is related to JAVASERVERFACES-3485 prependId="false" has incorrect inter... Closed
Issuezilla Id: 1,676
Status Whiteboard:

size_small importance_small

Tags: ADF

 Description   

Encountered while analyzing the following thread:

http://mail-archives.apache.org/mod_mbox/myfaces-
dev/201005.mbox/%3c4BF34C9E.3010108@oracle.com%3e

ScriptStyleBaseRenderer attempts to ensure that #

{cc}

EL context is set up for components that it
relocates to the UIViewRoot. This results in calls to findComponent() in order to locate the composite
component at render time:

public void encodeBegin(FacesContext context, UIComponent component)
throws IOException {

String ccID = (String) component.getAttributes().get(COMP_KEY);
UIComponent cc = context.getViewRoot().findComponent(':' + ccID);

This can result in full component tree searches, which can be expensive for large component trees.



 Comments   
Comment by Ed Burns [ 01/Jun/10 ]

Add adf keyword.

Comment by Ed Burns [ 11/Jun/10 ]

triage

Comment by Ed Burns [ 06/Jun/11 ]

Bulk assign all impl issues to Roger.

Comment by Manfred Riem [ 04/Jan/13 ]

Can you verify if this is still an issue on the latest 2.1 release?

Comment by Manfred Riem [ 01/Feb/13 ]

Lowering priority because of no response

Comment by Manfred Riem [ 01/Mar/13 ]

Lowering priority because of no response

Comment by Manfred Riem [ 29/Mar/13 ]

Closing because of inactivity





[JAVASERVERFACES-1675] ScriptStyleBaseRenderer establishes #{cc} context, but only for one level Created: 20/May/10  Updated: 29/Mar/13  Resolved: 29/Mar/13

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.0.1
Fix Version/s: None

Type: Bug Priority: Trivial
Reporter: aschwart Assignee: Unassigned
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 1,675
Status Whiteboard:

size_medium importance_medium

Tags: ADF, composite

 Description   

Encountered while analyzing the following thread:

http://mail-archives.apache.org/mod_mbox/myfaces-
dev/201005.mbox/%3c4BF34C9E.3010108@oracle.com%3e

ScriptStyleBaseRenderer attempts to ensure that #

{cc}

EL context is set up for components that it
relocates to the UIViewRoot:

// We're checking for a composite component here as if the resource
// is relocated, it may still require it's composite component context
// in order to properly render. Store it for later use by
// encodeBegin() and encodeEnd().
UIComponent cc = UIComponent.getCurrentCompositeComponent(context);
if (cc != null)

{ component.getAttributes().put(COMP_KEY, cc.getClientId(context)); }

This code won't handle nested composite component cases where an inner composite component
depends on values provided by an outer composite component.



 Comments   
Comment by Ed Burns [ 01/Jun/10 ]

Add adf keyword.

Comment by Ed Burns [ 11/Jun/10 ]

triage

Comment by Ed Burns [ 06/Jun/11 ]

Bulk assign all impl issues to Roger.

Comment by Manfred Riem [ 04/Jan/13 ]

Can you verify if this is still an issue on the latest 2.1 release?

Comment by Manfred Riem [ 01/Feb/13 ]

Lowering priority because of no response

Comment by Manfred Riem [ 01/Mar/13 ]

Lowering priority because of no response

Comment by Manfred Riem [ 29/Mar/13 ]

Closing because of inactivity





[JAVASERVERFACES-1674] Complications from relocation of resource components Created: 20/May/10  Updated: 29/Mar/13  Resolved: 29/Mar/13

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.0.1
Fix Version/s: None

Type: Bug Priority: Trivial
Reporter: aschwart Assignee: Unassigned
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 1,674
Status Whiteboard:

size_medium importance_medium

Tags: ADF

 Description   

Encountered while analyzing the following thread:

http://mail-archives.apache.org/mod_mbox/myfaces-
dev/201005.mbox/%3c4BF34C9E.3010108@oracle.com%3e

ScriptStyleBaseRenderer registers itself as a PostAddToViewEvent listener on
<h:outputScript>/<h:outputStylesheet> components. When the components are added to the view,
ScriptStyleBaseRenderer calls UIViewRoot.addComponentResource() on these components. This has the
side effect of removing these components from their parent and re-adding them under a new parent:
the UIViewRoot.

This results in several complications:

1. These components are repeatedly re-created on each request.

When tags are re-executed on postbacks against an existing component tree (during render response),
these components are no longer found were they are expected to be. As a result, the tag will re-create
the component and re-add it to its original parent on every request.

This can result in a loss of state, though in the <h:outputScript>/<h:outputStylesheet> cases the
likelihood of any bonus state being associated with these components is low. Even so, this approach
seems wasteful - we should not need to continually re-create these components.

2. EL-based attributes of these components are evaluated in the wrong context.

EL expressions may reference objects/context set up by ancestor components. Since these components
are re-located to the UIViewRoot, EL expressions specified by page authors may not evaluate in the
expected manner - ie. EL expressions that rely on ancestor context will fail as the ancestor chain
changes during relocation.

3. Non-rendered resources are added.

Since PostAddToViewEvents are delivered to all components, not just components in rendered subtrees,
this means that non-rendered resources will be added/included in the response.

The above email thread discusses a possible way to avoid this - eg. we could add a post-tag
execution/pre-render tree visit that would allow resources for the rendered tree to be collected in
context.

This is going to require spec support/changes, so we'll likely need to log spec issues if this isn't already
covered by spec issues that Leonardo has filed.



 Comments   
Comment by Ed Burns [ 01/Jun/10 ]

Add adf keyword.

Comment by Ed Burns [ 11/Jun/10 ]

triage

Comment by rogerk [ 25/Jun/10 ]

triage

Comment by rogerk [ 29/Jun/10 ]

target

Comment by rogerk [ 01/Jul/10 ]

re-target

Comment by rogerk [ 14/Sep/10 ]

ms6

Comment by rogerk [ 24/Sep/10 ]

Evaluating

Comment by rogerk [ 28/Sep/10 ]

Retarget - spoke with Andy Schwartz and we agreed that we would need to specify
new Visit Hints.

Comment by Manfred Riem [ 04/Jan/13 ]

Can you verify if this is still an issue with the latest 2.1 release?

Comment by Manfred Riem [ 01/Feb/13 ]

Lowering priority because of no response

Comment by Manfred Riem [ 01/Mar/13 ]

Lowering priority because of no response

Comment by Manfred Riem [ 29/Mar/13 ]

Closing because of inactivity





[JAVASERVERFACES-1673] @ListenerFor + full state saving results in Renderer re-instantiation Created: 20/May/10  Updated: 20/Feb/13  Resolved: 20/Feb/13

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.0.1
Fix Version/s: None

Type: Bug Priority: Trivial
Reporter: aschwart Assignee: Unassigned
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 1,673
Status Whiteboard:

size_medium importance_medium

Tags: ADF

 Description   

Minor issue that I encountered while analyzing the following thread:

http://mail-archives.apache.org/mod_mbox/myfaces-
dev/201005.mbox/%3c4BF34C9E.3010108@oracle.com%3e

Mojarra's ScriptStyleBaseRenderer registers itself as a listener for the PostAddToViewEvent using the
@ListenerFor annotation:

@ListenerFor(systemEventClass=PostAddToViewEvent.class)
public abstract class ScriptStyleBaseRenderer extends Renderer implements
ComponentSystemEventListener {

This results in UIComponent.subscribeToEvent() being called with the Renderer passed in as the
listener.

When performing a full state save (partial state saving disabled), the system event listeners are included
in the saved state. In particular, the Renderer ends up being wrapped in a StateHolderSaver. Upon
restore, the StateHolderSaver instantiates a new instance of the Renderer.

Before the state save/restore, there is a single Renderer instance - the one that is registered with the
RenderKit. This instance is shared across all components. After state save/restore, each component
instantiates its own Renderer instance. We end up with multiple Renderers whereas before we only had
one. None of these new Renderer instances are actually registered with the RenderKit (or used for
rendering).

It's hard to say exactly how this might cause problems, but this behavior is certainly unexpected. A
possible way to avoid this would be to register a proxy system event listener object rather than the
Renderer itself.

Note: this behavior is only observed when partial state saving is disabled. With partial state saving
enabled the Renderer system event listeners do not appear in the saved state (not deltas).



 Comments   
Comment by Ed Burns [ 01/Jun/10 ]

Add adf keyword.

Comment by Ed Burns [ 11/Jun/10 ]

triage

Comment by Ed Burns [ 06/Jun/11 ]

Bulk assign all impl issues to Roger.

Comment by Manfred Riem [ 26/Nov/12 ]

Can you please attach an example application (with sources) that demonstrates the problem? Can you verify if it still exists on the latest 2.1 release?

Comment by Manfred Riem [ 24/Dec/12 ]

Lowering priority because of no response

Comment by Manfred Riem [ 22/Jan/13 ]

Lowering priority because of no response

Comment by Manfred Riem [ 20/Feb/13 ]

Closing because of inactivity





[JAVASERVERFACES-1632] doEndTag() Optimizations Created: 14/Apr/10  Updated: 21/Mar/12  Resolved: 13/Jul/10

Status: Closed
Project: javaserverfaces
Component/s: view handling
Affects Version/s: 1.2_14
Fix Version/s: 2.1_gf31_m3

Type: Bug Priority: Major
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Dependency
blocks JAVASERVERFACES-1598 Optimize tag execution Closed
Issuezilla Id: 1,632
Status Whiteboard:

size_medium importance_large

Tags: adf, performance

 Description   

SM> 6. doEndTag in pushUIComponentClassicTagBase. Same as with
SM> others. Calls to pop and get parnets are hammering requestScope on
SM> container



 Comments   
Comment by Ed Burns [ 14/Apr/10 ]

keywords

Comment by Ed Burns [ 21/Apr/10 ]

remove jsf_1_2_backport_candidate keyword

Comment by rogerk [ 22/Apr/10 ]

in doEndTag, the replacement was:

  • UIComponentClassicTagBase parentTag =
    _getParentUIComponentClassicTagBase(getFacesContext());
    + if (parentTag == null) { + parentTag = _getParentUIComponentClassicTagBase(getFacesContext()); + }

However, making the same change in doAfterBoday causes a unit test failure:

[tester] FAIL [GET /jsf-systest/faces/interweaving10.jsp HTTP/1.0] Expected
status=200, got status=500

[#|2010-04-22T11:43:12.213-0400|SEVERE|sun-appserver2.1|javax.enterprise.system.container.web|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-1;_RequestID=ca6380ee-23e2-4d19-8148-f585a4476481;|StandardWrapperValve[Faces
Servlet]: PWC1406: Servlet.service() for servlet Faces Servlet threw exception
java.lang.IllegalStateException: Component ID form:j_id_id12:j_id1 has already
been found in the view. See below for details.
+id: j_id_id6
type: javax.faces.component.UIViewRoot@1fefe2
+id: j_id0
type: javax.faces.component.html.HtmlOutputText@fe0a5d
+id: form
type: javax.faces.component.html.HtmlForm@5a8d50
+id: j_id_id12
type: javax.faces.component.html.HtmlDataTable@795880
+id: j_id_id14
type: javax.faces.component.UIColumn@f3868c
+id: j_id_id17
type: javax.faces.component.html.HtmlOutputText@67ffa
+id: j_id1
type: javax.faces.component.html.HtmlOutputText@bc0ba4
+id: j_id1
type: javax.faces.component.html.HtmlOutputText@a04491
+id: j_id2
type: javax.faces.component.html.HtmlOutputText@f5a0f0

at
com.sun.faces.application.StateManagerImpl.checkIdUniqueness(StateManagerImpl.java:395)
at
com.sun.faces.application.StateManagerImpl.checkIdUniqueness(StateManagerImpl.java:382)
at
com.sun.faces.application.StateManagerImpl.checkIdUniqueness(StateManagerImpl.java:382)
at
com.sun.faces.application.StateManagerImpl.checkIdUniqueness(StateManagerImpl.java:382)
at
com.sun.faces.application.StateManagerImpl.saveSerializedView(StateManagerImpl.java:255)
at javax.faces.application.StateManager.saveView(StateManager.java:166)
at
com.sun.faces.application.ViewHandlerImpl$WriteBehindStateWriter.flushToWriter(ViewHandlerImpl.java:930)
at com.sun.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:205)
at
com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:110)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
....

Haven't had a chance to debug it yet.
The changes to doEndTag have been checked in.

Comment by rogerk [ 22/Apr/10 ]

This failed test (jsp page) references a component binding that has a lifetime
longer than request.

Comment by smalesevic [ 22/Apr/10 ]

The idea here is to avoid _getParentUIComponentClassicTagBase from inside of
UIComponentClassictagBase. These are now in findComponent, doEndtag and doAfterBody

Comment by rogerk [ 24/Apr/10 ]

Replace calls to getParentUIComponentClassicTagBase in doStartTag, doAfterBody,
doEndTag, findComponent with access to requestMap instance (instead of hitting
ExternalContext every time to get requestMap).

Comment by Ed Burns [ 11/Jun/10 ]

add adf keyword

Comment by Ed Burns [ 11/Jun/10 ]

size_medium importance_large

Comment by rogerk [ 25/Jun/10 ]

triage

Comment by rogerk [ 29/Jun/10 ]

target

Comment by rogerk [ 29/Jun/10 ]

target

Comment by sheetalv [ 30/Jun/10 ]

the fix was ported from the 1.2.x branch into the 2.1 trunk.

Comment by Ed Burns [ 01/Jul/10 ]

Target M4

Comment by Ed Burns [ 01/Jul/10 ]

Target to m3

Comment by Ed Burns [ 13/Jul/10 ]

FIx checked in. Hudson successful.

Comment by Manfred Riem [ 21/Mar/12 ]

Closing out resolved issue





[JAVASERVERFACES-1631] pushUIComponentClassicTagBase optimization Created: 14/Apr/10  Updated: 21/Mar/12  Resolved: 13/Jul/10

Status: Closed
Project: javaserverfaces
Component/s: view handling
Affects Version/s: 1.2_14
Fix Version/s: 2.1_gf31_m3

Type: Improvement Priority: Major
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Dependency
blocks JAVASERVERFACES-1598 Optimize tag execution Closed
Issuezilla Id: 1,631
Status Whiteboard:

size_medium importance_large

Tags: adf, performance

 Description   

SM> 5. setJspId in pushUIComponentClassicTagBase . Do not go to
SM> requestMap before it is needed (pcId == null). In most cases it will
SM> not be needed



 Comments   
Comment by Ed Burns [ 14/Apr/10 ]

keywords

Comment by Ed Burns [ 21/Apr/10 ]

remove jsf_1_2_backport_candidate keyword.

Comment by Ed Burns [ 11/Jun/10 ]

add adf keyword

Comment by Ed Burns [ 11/Jun/10 ]

size_medium importance_large

Comment by Ed Burns [ 21/Jun/10 ]

Re-assign these JSF 1.2 forward ports to Sheetal Vartak

Comment by Ed Burns [ 28/Jun/10 ]

Change target milestone to 2.1

Comment by sheetalv [ 30/Jun/10 ]

the fix was ported from the 1.2.x branch into the 2.1 trunk.

Comment by Ed Burns [ 01/Jul/10 ]

Target M4

Comment by Ed Burns [ 01/Jul/10 ]

Target to m3

Comment by Ed Burns [ 13/Jul/10 ]

FIx checked in. Hudson successful.

Comment by Manfred Riem [ 21/Mar/12 ]

Closing out resolved issue





[JAVASERVERFACES-1630] doStartTag(): avoid calling getUIComponentClassicTagBase(). Created: 14/Apr/10  Updated: 21/Mar/12  Resolved: 13/Jul/10

Status: Closed
Project: javaserverfaces
Component/s: view handling
Affects Version/s: 1.2_14
Fix Version/s: 2.1_gf31_m3

Type: Improvement Priority: Major
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Dependency
blocks JAVASERVERFACES-1598 Optimize tag execution Closed
Issuezilla Id: 1,630
Status Whiteboard:

size_medium importance_large

Tags: adf, performance

 Description   

SM> 4. pushUIComponentClassicTagBase in
SM> getParentUIComponentClassictagBase. Called from doStart tag. We
SM> should change so that doStart tag gets the map instead of calling
SM> getParentUIComponentClassicTagBase. Then just get and put on this
SM> map. Saves on calls to container request scope. Actually doStartTag
SM> already gets request scope map so just use that one instead of calls
SM> to getParanet and push. We might even hold onto map for faster
SM> operations and null it in release()



 Comments&nb