[jira] Commented: (MYFACES-2374) UIViewRoot.getBeforePhaseListener() and UIViewRoot.getAfterPhaseListener() could be called on PhaseId.RESTORE_VIEW
[ https://issues.apache.org/jira/browse/MYFACES-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12770633#action_12770633 ] Jakob Korherr commented on MYFACES-2374: The RI 2.0.1 does not call afterPhase on RESTORE_VIEW, but its javadocs says it does. I will write a comment to the EG and ask about this. > UIViewRoot.getBeforePhaseListener() and UIViewRoot.getAfterPhaseListener() > could be called on PhaseId.RESTORE_VIEW > -- > > Key: MYFACES-2374 > URL: https://issues.apache.org/jira/browse/MYFACES-2374 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Reporter: Leonardo Uribe > Attachments: restore_view_phaselistener.patch > > > Note that on jsf 1.2 this is not true. The problem with this one is how call > UIViewRoot beforePhaseListener before PhaseId.RESTORE_VIEW, because in theory > we need to "restore it" before call it. Maybe the solution is call it from > the place where the state is restored (JspStateManagerImpl). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2309) Add new attributes to f:selectItems
[ https://issues.apache.org/jira/browse/MYFACES-2309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr updated MYFACES-2309: --- Status: Patch Available (was: Reopened) > Add new attributes to f:selectItems > --- > > Key: MYFACES-2309 > URL: https://issues.apache.org/jira/browse/MYFACES-2309 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Fix For: 2.0.0-alpha > > Attachments: select_items_newest.patch, > selectitems_new_attributes.patch > > > New attributes where added to f:selectItems tag. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2374) UIViewRoot.getBeforePhaseListener() and UIViewRoot.getAfterPhaseListener() could be called on PhaseId.RESTORE_VIEW
[ https://issues.apache.org/jira/browse/MYFACES-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12772086#action_12772086 ] Jakob Korherr commented on MYFACES-2374: posted mojarra issue: https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1391 > UIViewRoot.getBeforePhaseListener() and UIViewRoot.getAfterPhaseListener() > could be called on PhaseId.RESTORE_VIEW > -- > > Key: MYFACES-2374 > URL: https://issues.apache.org/jira/browse/MYFACES-2374 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Reporter: Leonardo Uribe > Attachments: restore_view_phaselistener.patch > > > Note that on jsf 1.2 this is not true. The problem with this one is how call > UIViewRoot beforePhaseListener before PhaseId.RESTORE_VIEW, because in theory > we need to "restore it" before call it. Maybe the solution is call it from > the place where the state is restored (JspStateManagerImpl). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2374) UIViewRoot.getBeforePhaseListener() and UIViewRoot.getAfterPhaseListener() could be called on PhaseId.RESTORE_VIEW
[ https://issues.apache.org/jira/browse/MYFACES-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr updated MYFACES-2374: --- Status: Patch Available (was: Open) > UIViewRoot.getBeforePhaseListener() and UIViewRoot.getAfterPhaseListener() > could be called on PhaseId.RESTORE_VIEW > -- > > Key: MYFACES-2374 > URL: https://issues.apache.org/jira/browse/MYFACES-2374 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Reporter: Leonardo Uribe > Attachments: restore_view_phaselistener.patch, > restore_view_phaselistener_newest.patch > > > Note that on jsf 1.2 this is not true. The problem with this one is how call > UIViewRoot beforePhaseListener before PhaseId.RESTORE_VIEW, because in theory > we need to "restore it" before call it. Maybe the solution is call it from > the place where the state is restored (JspStateManagerImpl). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2323) Implement tag handler
[ https://issues.apache.org/jira/browse/MYFACES-2323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12773140#action_12773140 ] Jakob Korherr commented on MYFACES-2323: I tried to run f:ajax yesterday and I found out that the following still does not work: 2. if f:ajax is on a page, it should be created automatically a component that register and render jsf.js javascript with target head. I tried some different versions, but the jsf.js was never included in the rendered html, however every version worked well in mojarra. > Implement tag handler > -- > > Key: MYFACES-2323 > URL: https://issues.apache.org/jira/browse/MYFACES-2323 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Reporter: Leonardo Uribe > Attachments: clientBehaviorHolderRendersIdAndName.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2374) UIViewRoot.getBeforePhaseListener() and UIViewRoot.getAfterPhaseListener() could be called on PhaseId.RESTORE_VIEW
[ https://issues.apache.org/jira/browse/MYFACES-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12773628#action_12773628 ] Jakob Korherr commented on MYFACES-2374: ad 1. Thanks - I did not know that ad 2. It removes invalid code, because the PhaseListeners from getPhaseListeners() don't need to be called any more. They changed this behavior, see javadoc of UIViewRoot: The default implementation must call UIComponentBase.processRestoreState(javax.faces.context.FacesContext, java.lang.Object) from within a try block. The try block must have a finally block that ensures that no FacesEvents remain in the event queue, and that the this.UIComponent.visitTree(javax.faces.component.visit.VisitContext, javax.faces.component.visit.VisitCallback) is called, passing a ContextCallback that takes the following action: call the UIComponent.processEvent(javax.faces.event.ComponentSystemEvent) method of the current component. The argument event must be an instance of PostRestoreStateEvent whose component property is the current component in the traversal. --> They deleted the following: "that any PhaseListeners in getPhaseListeners() are invoked as appropriate" Besides that, this implementation does not check, if the PhaseListener is registered for PhaseId.RESTORE_VIEW or PhaseId.ANY_PHASE. > UIViewRoot.getBeforePhaseListener() and UIViewRoot.getAfterPhaseListener() > could be called on PhaseId.RESTORE_VIEW > -- > > Key: MYFACES-2374 > URL: https://issues.apache.org/jira/browse/MYFACES-2374 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Reporter: Leonardo Uribe > Attachments: restore_view_phaselistener.patch, > restore_view_phaselistener_newest.patch > > > Note that on jsf 1.2 this is not true. The problem with this one is how call > UIViewRoot beforePhaseListener before PhaseId.RESTORE_VIEW, because in theory > we need to "restore it" before call it. Maybe the solution is call it from > the place where the state is restored (JspStateManagerImpl). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2396) @PreDestroy method of Bean in CustomScope not invoked
@PreDestroy method of Bean in CustomScope not invoked
-
Key: MYFACES-2396
URL: https://issues.apache.org/jira/browse/MYFACES-2396
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.0-alpha
Reporter: Jakob Korherr
Testing the mojarra 2.0.1 sample "custom-bean-scope", MyFaces does NOT behave
like Mojarra.
The problem is that MyFaces does not propagate a PreDestroyCustomScopeEvent
correctly. The following code is from the mojarra sample and shows how the
event is published:
public void notifyDestroy() {
// notify interested parties that this scope is being
// destroyed
ScopeContext scopeContext = new ScopeContext(SCOPE_NAME, this);
application.publishEvent(FacesContext.getCurrentInstance(),
PreDestroyCustomScopeEvent.class, scopeContext);
}
However, the @PreDestroy method of the Bean, which is stored in the scope, is
not invoked.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2397) f:ajax attributes execute and render should take space delimited clientIds
f:ajax attributes execute and render should take space delimited clientIds -- Key: MYFACES-2397 URL: https://issues.apache.org/jira/browse/MYFACES-2397 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Jakob Korherr Testing the mojarra 2.0.1 sample "custom-tag", I got the following Exception: javax.faces.FacesException: Component with id:out count eventcount not found The problem is, that the example uses f:ajax to render 3 components in the following way: MyFaces does not check, if the value of render is a space delimited list of clientIds and so it wants to find the component with clientId: "out count eventcount", which, of course, does not exist. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2399) ManagedBeanResolver does not handle view scope
[ https://issues.apache.org/jira/browse/MYFACES-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12775122#action_12775122 ] Jakob Korherr commented on MYFACES-2399: I just realized that we also have to implement the reference checking mechanism (a bean cannot reference an object with a potentially shorter lifetime) for the view scope. I will provide a patch for that soon. > ManagedBeanResolver does not handle view scope > -- > > Key: MYFACES-2399 > URL: https://issues.apache.org/jira/browse/MYFACES-2399 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Affects Versions: 2.0.0-alpha >Reporter: Jakob Korherr > Attachments: view_scope.patch > > > Testing the mojarra-example "custom-tag", I ran into the following Exception: > 06.11.2009 12:29:18 > org.apache.myfaces.el.unified.resolver.ManagedBeanResolver putInScope > SCHWERWIEGEND: Managed bean 'data' has illegal scope: view > The managed bean "data" is annotated with @ViewScoped, but the > ManagedBeanResolver does not know this scope. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2399) ManagedBeanResolver does not handle view scope
[ https://issues.apache.org/jira/browse/MYFACES-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr updated MYFACES-2399: --- Status: Open (was: Patch Available) > ManagedBeanResolver does not handle view scope > -- > > Key: MYFACES-2399 > URL: https://issues.apache.org/jira/browse/MYFACES-2399 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Affects Versions: 2.0.0-alpha >Reporter: Jakob Korherr > Attachments: view_scope.patch > > > Testing the mojarra-example "custom-tag", I ran into the following Exception: > 06.11.2009 12:29:18 > org.apache.myfaces.el.unified.resolver.ManagedBeanResolver putInScope > SCHWERWIEGEND: Managed bean 'data' has illegal scope: view > The managed bean "data" is annotated with @ViewScoped, but the > ManagedBeanResolver does not know this scope. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2399) ManagedBeanResolver does not handle view scope
[ https://issues.apache.org/jira/browse/MYFACES-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12776712#action_12776712 ] Jakob Korherr commented on MYFACES-2399: I just finished implementing the view scope and I ran into an interesting NotSerializableException while testing: Caused by: java.lang.NullPointerException at org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.restoreView(DefaultFaceletsStateManagementStrategy.java:174) at org.apache.myfaces.application.jsp.JspStateManagerImpl.restoreView(JspStateManagerImpl.java:388) at org.apache.myfaces.view.ViewDeclarationLanguageBase.restoreView(ViewDeclarationLanguageBase.java:106) at org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.restoreView(FaceletViewDeclarationLanguage.java:927) at org.apache.myfaces.application.ViewHandlerImpl.restoreView(ViewHandlerImpl.java:231) at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:106) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:129) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:85) at javax.faces.webapp.FacesServlet._handleStandardRequest(FacesServlet.java:448) ... 13 more And here's why: UIViewRoot uses a inner class ViewScope which extends HashMap to publish the PreDestroyViewMapEvent, when clear is called. The problem is, if you want to serialize an object of an inner class, the enclosing class also needs to be serialized. The enclosing class is UIViewRoot, which is not serializable and we don't want it to be serializable, I think. So I'll change it to a static nested class. > ManagedBeanResolver does not handle view scope > -- > > Key: MYFACES-2399 > URL: https://issues.apache.org/jira/browse/MYFACES-2399 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Affects Versions: 2.0.0-alpha >Reporter: Jakob Korherr > Attachments: view_scope.patch > > > Testing the mojarra-example "custom-tag", I ran into the following Exception: > 06.11.2009 12:29:18 > org.apache.myfaces.el.unified.resolver.ManagedBeanResolver putInScope > SCHWERWIEGEND: Managed bean 'data' has illegal scope: view > The managed bean "data" is annotated with @ViewScoped, but the > ManagedBeanResolver does not know this scope. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2399) ManagedBeanResolver does not handle view scope
[ https://issues.apache.org/jira/browse/MYFACES-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr updated MYFACES-2399: --- Status: Patch Available (was: Open) > ManagedBeanResolver does not handle view scope > -- > > Key: MYFACES-2399 > URL: https://issues.apache.org/jira/browse/MYFACES-2399 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Affects Versions: 2.0.0-alpha >Reporter: Jakob Korherr > Attachments: view_scope.patch, view_scope_newest.patch > > > Testing the mojarra-example "custom-tag", I ran into the following Exception: > 06.11.2009 12:29:18 > org.apache.myfaces.el.unified.resolver.ManagedBeanResolver putInScope > SCHWERWIEGEND: Managed bean 'data' has illegal scope: view > The managed bean "data" is annotated with @ViewScoped, but the > ManagedBeanResolver does not know this scope. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2396) @PreDestroy method of Bean in CustomScope not invoked
[
https://issues.apache.org/jira/browse/MYFACES-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12777110#action_12777110
]
Jakob Korherr commented on MYFACES-2396:
It seems like the origin of this issue is that all MyFacesXXXListeners in
org.apache.myfaces.webapp created by Dennis Byrne are not registered in webxml.
For example: If you manually register
org.apache.myfaces.webapp.MyFacesHttpSessionAttributeListener, @PreDestroy is
invoked correctly on all SessionScoped managed beans.
> @PreDestroy method of Bean in CustomScope not invoked
> -
>
> Key: MYFACES-2396
> URL: https://issues.apache.org/jira/browse/MYFACES-2396
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
>Affects Versions: 2.0.0-alpha
>Reporter: Jakob Korherr
>
> Testing the mojarra 2.0.1 sample "custom-bean-scope", MyFaces does NOT behave
> like Mojarra.
> The problem is that MyFaces does not propagate a PreDestroyCustomScopeEvent
> correctly. The following code is from the mojarra sample and shows how the
> event is published:
> public void notifyDestroy() {
> // notify interested parties that this scope is being
> // destroyed
> ScopeContext scopeContext = new ScopeContext(SCOPE_NAME, this);
> application.publishEvent(FacesContext.getCurrentInstance(),
> PreDestroyCustomScopeEvent.class, scopeContext);
> }
> However, the @PreDestroy method of the Bean, which is stored in the scope, is
> not invoked.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2399) ManagedBeanResolver does not handle view scope
[ https://issues.apache.org/jira/browse/MYFACES-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12777191#action_12777191 ] Jakob Korherr commented on MYFACES-2399: But can we be sure that we get the right UIViewRoot instance with this way? What if someone stored a reference to another UIViewRoot in a managed bean and than calls getViewMap().clear()? In such a scenario we would provide a wrong instance of UIViewRoot, ain't we? However, FacesContext.getCurrentInstance() can/could be used. > ManagedBeanResolver does not handle view scope > -- > > Key: MYFACES-2399 > URL: https://issues.apache.org/jira/browse/MYFACES-2399 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Affects Versions: 2.0.0-alpha >Reporter: Jakob Korherr > Attachments: view_scope.patch, view_scope_newest.patch > > > Testing the mojarra-example "custom-tag", I ran into the following Exception: > 06.11.2009 12:29:18 > org.apache.myfaces.el.unified.resolver.ManagedBeanResolver putInScope > SCHWERWIEGEND: Managed bean 'data' has illegal scope: view > The managed bean "data" is annotated with @ViewScoped, but the > ManagedBeanResolver does not know this scope. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2399) ManagedBeanResolver does not handle view scope
[ https://issues.apache.org/jira/browse/MYFACES-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12777235#action_12777235 ] Jakob Korherr commented on MYFACES-2399: I also don't see a valid case for that, but maybe there is one. Besides that: Shouldn't we also check the remove() method of the HashMap in ViewScope to invoke the @PreDestroy method of a managed bean that is removed by this method, but not with clear()? Then we would also need FacesContext and UIViewRoot. Every other scope listenes on removing of specified objects as well as destroying the whole scope (look at MyFacesSessonAttributeListener for example). > ManagedBeanResolver does not handle view scope > -- > > Key: MYFACES-2399 > URL: https://issues.apache.org/jira/browse/MYFACES-2399 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Affects Versions: 2.0.0-alpha >Reporter: Jakob Korherr > Attachments: view_scope.patch, view_scope_newest.patch > > > Testing the mojarra-example "custom-tag", I ran into the following Exception: > 06.11.2009 12:29:18 > org.apache.myfaces.el.unified.resolver.ManagedBeanResolver putInScope > SCHWERWIEGEND: Managed bean 'data' has illegal scope: view > The managed bean "data" is annotated with @ViewScoped, but the > ManagedBeanResolver does not know this scope. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2399) ManagedBeanResolver does not handle view scope
[ https://issues.apache.org/jira/browse/MYFACES-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12777450#action_12777450 ] Jakob Korherr commented on MYFACES-2399: That's clear, but when we create a ViewScoped managed bean, its @PostConstruct method will be called. If we remove it from the viewmap afterwards, its @PreDestroy method will never be called, because PreDestroyViewMapEvent invokes @PreDestroy only on managed beans, which still exist in the viewmap. Isn't this a problem? > ManagedBeanResolver does not handle view scope > -- > > Key: MYFACES-2399 > URL: https://issues.apache.org/jira/browse/MYFACES-2399 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Affects Versions: 2.0.0-alpha >Reporter: Jakob Korherr > Attachments: view_scope.patch, view_scope_newest.patch > > > Testing the mojarra-example "custom-tag", I ran into the following Exception: > 06.11.2009 12:29:18 > org.apache.myfaces.el.unified.resolver.ManagedBeanResolver putInScope > SCHWERWIEGEND: Managed bean 'data' has illegal scope: view > The managed bean "data" is annotated with @ViewScoped, but the > ManagedBeanResolver does not know this scope. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2399) ManagedBeanResolver does not handle view scope
[ https://issues.apache.org/jira/browse/MYFACES-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12777459#action_12777459 ] Jakob Korherr commented on MYFACES-2399: I looked it up in the spec and it says: @PreDestroy must only be called, when the view scope is destroyed. So you're right, Leonardo! I'll alter the patch to use FacesContext.getCurrentInstance() and facesContext.getViewRoot(). Thanks for the discussion. > ManagedBeanResolver does not handle view scope > -- > > Key: MYFACES-2399 > URL: https://issues.apache.org/jira/browse/MYFACES-2399 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Affects Versions: 2.0.0-alpha >Reporter: Jakob Korherr > Attachments: view_scope.patch, view_scope_newest.patch > > > Testing the mojarra-example "custom-tag", I ran into the following Exception: > 06.11.2009 12:29:18 > org.apache.myfaces.el.unified.resolver.ManagedBeanResolver putInScope > SCHWERWIEGEND: Managed bean 'data' has illegal scope: view > The managed bean "data" is annotated with @ViewScoped, but the > ManagedBeanResolver does not know this scope. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2362) Move default validator registration from UIInput.validateValue to ComponentTagHandlerDelegate
[ https://issues.apache.org/jira/browse/MYFACES-2362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr updated MYFACES-2362: --- Status: Patch Available (was: Open) > Move default validator registration from UIInput.validateValue to > ComponentTagHandlerDelegate > - > > Key: MYFACES-2362 > URL: https://issues.apache.org/jira/browse/MYFACES-2362 > Project: MyFaces Core > Issue Type: Sub-task > Components: JSR-314 >Reporter: Leonardo Uribe > Attachments: myfaces-2362.patch > > > The code that register default validators on UIInput is invalid and should be > moved to other place. Since f:validateBean is a facelet specific tag, we can > move safely this code to ComponentTagHandlerDelegate > See discussion here: > http://markmail.org/message/ykjmdu6ehdqpxyq7?q=[jsf+2.0]+bean+validation+api+will+not+be+available+on+jsp+apps%3F -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2396) @PreDestroy method of Bean in CustomScope not invoked
[
https://issues.apache.org/jira/browse/MYFACES-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12779553#action_12779553
]
Jakob Korherr commented on MYFACES-2396:
I also thought about that. The only thing, which I did not like about it, is
that the StartupServletContextListener would also be a HttpSessionListener,
RequestListener, and so he does more than his name
"StartupServletContextListener" tells us. But I suppose this is better than the
registration of a second Listener. I'll change the patch!
> @PreDestroy method of Bean in CustomScope not invoked
> -
>
> Key: MYFACES-2396
> URL: https://issues.apache.org/jira/browse/MYFACES-2396
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
>Affects Versions: 2.0.0-alpha
>Reporter: Jakob Korherr
> Attachments: myfaces_2396_proposal.patch
>
>
> Testing the mojarra 2.0.1 sample "custom-bean-scope", MyFaces does NOT behave
> like Mojarra.
> The problem is that MyFaces does not propagate a PreDestroyCustomScopeEvent
> correctly. The following code is from the mojarra sample and shows how the
> event is published:
> public void notifyDestroy() {
> // notify interested parties that this scope is being
> // destroyed
> ScopeContext scopeContext = new ScopeContext(SCOPE_NAME, this);
> application.publishEvent(FacesContext.getCurrentInstance(),
> PreDestroyCustomScopeEvent.class, scopeContext);
> }
> However, the @PreDestroy method of the Bean, which is stored in the scope, is
> not invoked.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2409) c:choose renders every option
c:choose renders every option - Key: MYFACES-2409 URL: https://issues.apache.org/jira/browse/MYFACES-2409 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Jakob Korherr Testing the mojarra bean-validation sample, I found out that c:choose does not work correctly, because it renders every possible option. For example: The following facelet code will result in "when_false when_true otherwise", but should result in "when_true". when_false when_true otherwise -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2410) f:validateBean does not work as container for EditableValueHolders
f:validateBean does not work as container for EditableValueHolders -- Key: MYFACES-2410 URL: https://issues.apache.org/jira/browse/MYFACES-2410 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-alpha Environment: Glassfish v3 prelude and JBoss 6.0.0.M1 Reporter: Jakob Korherr Testing the mojarra bean-validation sample on Glassfish v3 prelude and JBoss 6.0.0.M1, I ran into the following exception: javax.servlet.ServletException: /placeOrder.xhtmlat line 49 and column 109 Parent not composite component or an instance of EditableValueHolder: javax.faces.component.html.htmlf...@494c491b f:validateBean is used as a container of EditableValueHolders in the sample, the following code shoes where the error occurs: where includes a form of some (--> EditableValueHolder) components. However, f:validateBean is also used inside of some of the components and works well at this point. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2396) @PreDestroy method of Bean in CustomScope not invoked
[
https://issues.apache.org/jira/browse/MYFACES-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakob Korherr updated MYFACES-2396:
---
Status: Patch Available (was: Open)
> @PreDestroy method of Bean in CustomScope not invoked
> -
>
> Key: MYFACES-2396
> URL: https://issues.apache.org/jira/browse/MYFACES-2396
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
>Affects Versions: 2.0.0-alpha
>Reporter: Jakob Korherr
> Attachments: myfaces-2396-final.patch, myfaces_2396_proposal.patch
>
>
> Testing the mojarra 2.0.1 sample "custom-bean-scope", MyFaces does NOT behave
> like Mojarra.
> The problem is that MyFaces does not propagate a PreDestroyCustomScopeEvent
> correctly. The following code is from the mojarra sample and shows how the
> event is published:
> public void notifyDestroy() {
> // notify interested parties that this scope is being
> // destroyed
> ScopeContext scopeContext = new ScopeContext(SCOPE_NAME, this);
> application.publishEvent(FacesContext.getCurrentInstance(),
> PreDestroyCustomScopeEvent.class, scopeContext);
> }
> However, the @PreDestroy method of the Bean, which is stored in the scope, is
> not invoked.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2412) ResourceHandler cannot find jsf.js
ResourceHandler cannot find jsf.js -- Key: MYFACES-2412 URL: https://issues.apache.org/jira/browse/MYFACES-2412 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.0-alpha Reporter: Jakob Korherr Testing f:ajax I ran into the following warning: WARNUNG: Resource referenced by resourceName jsf.js and libraryName javax.faces not found in call to ResourceHandler.createResource. It will be silenty ignored. So there is no javascript for f:ajax and thus it does not work. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2412) ResourceHandler cannot find jsf.js
[ https://issues.apache.org/jira/browse/MYFACES-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781015#action_12781015 ] Jakob Korherr commented on MYFACES-2412: I just found out that finding jsf.js is not the problem. The problem is that maven generates the jsf.js in target/classes/META-INF/resources/javax.faces, but just a little bit after the generation my eclipse IDE copies the META-INF directory from src/main/resources and overwrites it. So the generated jsf.js gets lost and the ResourceHandler cannot find it. So it is not a major problem - I just copied jsf.js to the right directory per hand (on my local copy, of course). Does anyone have an idea to solve this in a better way? > ResourceHandler cannot find jsf.js > -- > > Key: MYFACES-2412 > URL: https://issues.apache.org/jira/browse/MYFACES-2412 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.0.0-alpha >Reporter: Jakob Korherr > > Testing f:ajax I ran into the following warning: > WARNUNG: Resource referenced by resourceName jsf.js and libraryName > javax.faces not found in call to ResourceHandler.createResource. It will be > silenty ignored. > So there is no javascript for f:ajax and thus it does not work. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2418) Implement h:selectManyXXX collectionType and hideNoSelectionOption
[ https://issues.apache.org/jira/browse/MYFACES-2418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr updated MYFACES-2418: --- Status: Patch Available (was: Open) > Implement h:selectManyXXX collectionType and hideNoSelectionOption > -- > > Key: MYFACES-2418 > URL: https://issues.apache.org/jira/browse/MYFACES-2418 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Reporter: Leonardo Uribe > Attachments: myfaces-2418.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2417) h:commandButton and h:commandLink now can be rendered outside a form
[ https://issues.apache.org/jira/browse/MYFACES-2417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782224#action_12782224 ] Jakob Korherr commented on MYFACES-2417: Where did you find this information? Testing mojarra, h:commandButton can be rendered outside a form, but h:commandLink cannot. Some details would be great (for example how h:commandLink should behave outside a form). > h:commandButton and h:commandLink now can be rendered outside a form > > > Key: MYFACES-2417 > URL: https://issues.apache.org/jira/browse/MYFACES-2417 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Reporter: Leonardo Uribe > > In jsf 1.2 this is not possible, but now it is. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2417) h:commandButton and h:commandLink now can be rendered outside a form
[ https://issues.apache.org/jira/browse/MYFACES-2417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782227#action_12782227 ] Jakob Korherr commented on MYFACES-2417: OK, sorry - you got it from the TCK. I just took a closer look at the result. But do you know, how h:commandLink should behave outside a form? just not render any javascript for submitting in onclick? mojarra prints a warning to the ResponseWriter that the related h:commandLink is not embedded in a form.. > h:commandButton and h:commandLink now can be rendered outside a form > > > Key: MYFACES-2417 > URL: https://issues.apache.org/jira/browse/MYFACES-2417 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Reporter: Leonardo Uribe > > In jsf 1.2 this is not possible, but now it is. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2417) h:commandButton and h:commandLink now can be rendered outside a form
[ https://issues.apache.org/jira/browse/MYFACES-2417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr updated MYFACES-2417: --- Status: Patch Available (was: Open) > h:commandButton and h:commandLink now can be rendered outside a form > > > Key: MYFACES-2417 > URL: https://issues.apache.org/jira/browse/MYFACES-2417 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Reporter: Leonardo Uribe > Attachments: myfaces-2417.patch > > > In jsf 1.2 this is not possible, but now it is. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2418) Implement h:selectManyXXX collectionType and hideNoSelectionOption
[
https://issues.apache.org/jira/browse/MYFACES-2418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782676#action_12782676
]
Jakob Korherr commented on MYFACES-2418:
I tested these two scenarios an mojarra and I already have a solution for the
first problem.
The second problem is a bit strange. If you use something like this
public List getSomeFieldValue()
{
.
}
on mojarra and you also have SelectItems containing Integers, mojarra renders
the SelectItems, while MyFaces already fails here, because it cannot get a
Converter to convert the Integers to Strings for rendering. This is, of course,
easy to solve (we just have to take a look at the value type of the
SelectItems).
However, if you submit your selections on mojarra it adds the submitted values,
which are of type String, without any conversion to the ArrayList, which will
be set in setSomeFieldValue(List value). This works, because java does
not check the type at runtime.
But now we have the problem that when we want to access the values, we will get
Strings instead of the expected Integers, which may cause «strange looking»
ClassCastExceptions in the user code.
Should we behave exactly like mojarra at this point, which on my opinion is
stupid and may confuse a lot of developers, or should we try to obtain a
Converter some other way?
I think looking at the type of the SelectItems will provide us a valid
converter and would be a better way.
The spec, of course, does not mention anything about this.
> Implement h:selectManyXXX collectionType and hideNoSelectionOption
> --
>
> Key: MYFACES-2418
> URL: https://issues.apache.org/jira/browse/MYFACES-2418
> Project: MyFaces Core
> Issue Type: Task
> Components: JSR-314
>Reporter: Leonardo Uribe
> Attachments: myfaces-2418.patch
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2409) c:choose renders every option
[ https://issues.apache.org/jira/browse/MYFACES-2409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12783088#action_12783088 ] Jakob Korherr commented on MYFACES-2409: Today I tested the sample again and now it works correctly. I don't know what changed, but now it works! > c:choose renders every option > - > > Key: MYFACES-2409 > URL: https://issues.apache.org/jira/browse/MYFACES-2409 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314 >Affects Versions: 2.0.0-alpha >Reporter: Jakob Korherr > > Testing the mojarra bean-validation sample, I found out that c:choose does > not work correctly, because it renders every possible option. > For example: The following facelet code will result in "when_false when_true > otherwise", but should result in "when_true". > > > when_false > > > when_true > > > otherwise > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2396) @PreDestroy method of Bean in CustomScope not invoked
[
https://issues.apache.org/jira/browse/MYFACES-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12783115#action_12783115
]
Jakob Korherr commented on MYFACES-2396:
How did you accomplish this scenario?
I found out that javax.faces.application.Application causes this infinite loop,
when you use a custom implementation for Application, which does not override
subscribeToEvent. Were you using a custom implemention to get the
StackOverflowException?
> @PreDestroy method of Bean in CustomScope not invoked
> -
>
> Key: MYFACES-2396
> URL: https://issues.apache.org/jira/browse/MYFACES-2396
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
>Reporter: Jakob Korherr
>Assignee: Leonardo Uribe
> Attachments: myfaces-2396-final.patch, myfaces_2396_proposal.patch
>
>
> Testing the mojarra 2.0.1 sample "custom-bean-scope", MyFaces does NOT behave
> like Mojarra.
> The problem is that MyFaces does not propagate a PreDestroyCustomScopeEvent
> correctly. The following code is from the mojarra sample and shows how the
> event is published:
> public void notifyDestroy() {
> // notify interested parties that this scope is being
> // destroyed
> ScopeContext scopeContext = new ScopeContext(SCOPE_NAME, this);
> application.publishEvent(FacesContext.getCurrentInstance(),
> PreDestroyCustomScopeEvent.class, scopeContext);
> }
> However, the @PreDestroy method of the Bean, which is stored in the scope, is
> not invoked.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2435) f:facet can have more than one child
f:facet can have more than one child Key: MYFACES-2435 URL: https://issues.apache.org/jira/browse/MYFACES-2435 Project: MyFaces Core Issue Type: Improvement Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Jakob Korherr MIchael Kurz tested Mojarra and found out that now can have more than one child. If so, the children will automaticall be put in a UIPanel to serve facet requirements. However, this improvement is not mentioned in the spec, filed spec issue: https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=677 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2423) h:dataTable renderer does not support colgroups facet
[ https://issues.apache.org/jira/browse/MYFACES-2423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr updated MYFACES-2423: --- Status: Patch Available (was: Open) > h:dataTable renderer does not support colgroups facet > - > > Key: MYFACES-2423 > URL: https://issues.apache.org/jira/browse/MYFACES-2423 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Reporter: Leonardo Uribe > Attachments: myfaces-2423.patch > > > On the javadoc of h:dataTable, it says: > "Column Groups > If the UIData component has a "colgroups" facet, render its contents. > Consistent with the rules of facets in general, this facet must have only one > child. In general, this will be a panel group component that will contain > colgroup and col elements per the HTML Table specification. Use of column > grouping can improve accessibility. This facet must be rendered before the > table header and footer.." > Since it is not marked with green or orange, we just skip it, but it is a new > feature. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2441) Make _ErrorPageWriter public to allow re-use of default functionality
[
https://issues.apache.org/jira/browse/MYFACES-2441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12784731#action_12784731
]
Jakob Korherr commented on MYFACES-2441:
I'm afraid the _ErrorPageWriter cannot be exposed, because the class is in
package javax.faces.webapp and it is not part of the JSF spec and thus MyFaces
would not pass the TCK, if it was public.
We could copy it to org.apache.myfaces.webapp and rename it to
DefaultErrorPageWriter, but that would lead to code duplication.
> Make _ErrorPageWriter public to allow re-use of default functionality
> -
>
> Key: MYFACES-2441
> URL: https://issues.apache.org/jira/browse/MYFACES-2441
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 1.2.8
>Reporter: Caius Gran
> Original Estimate: 0.25h
> Remaining Estimate: 0.25h
>
> Using context parameter "org.apache.myfaces.ERROR_HANDLER", you can override
> default
> error handling functionality. In my case, handling ViewExpiredException's is
> particularly useful,
> but otherwise the default is fine.
> I couldn't do the obvious, because the default error handler is hidden:
> public void handleException(FacesContext fc, Exception ex) throws
> ServletException, IOException
> {
> if (ex instanceof ViewExpiredException)
> {
> // redirect
> }
> else
> {
> _ErrorPageWriter.handleException(fc, ex);
> }
> }
> Could the default error handler be exposed and perhaps renamed to something
> like "DefaultErrorPageWriter"?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2396) @PreDestroy method of Bean in CustomScope not invoked
[
https://issues.apache.org/jira/browse/MYFACES-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785283#action_12785283
]
Jakob Korherr commented on MYFACES-2396:
This issue is _REALLY_ weird. I spent a lot of time investigating this
Exception and now (I think), I finally found it.
The problem comes from the following method of Application.java
public void subscribeToEvent(Class systemEventClass,
SystemEventListener listener)
{
Application application = getMyfacesApplicationInstance();
if (application != null)
{
application.subscribeToEvent(systemEventClass, listener);
return;
}
subscribeToEvent(systemEventClass, null, listener);
}
It tries to get the actual MyFacesApplicationInstance (ApplicationImpl) from
the ApplicationMap. This method returns null, if either FacesContext is null,
ExternalContext is null or ApplicationFactoryImpl did not put it in the
ApplicationMap yet.
If the call to getMyfacesApplicationInstance() returns NULL (!!!), everything
functions properly and we can never get an infinite loop. Otherwise it calls
subscribeToEvent(Class systemEventClass,
SystemEventListener listener) on ApplicationImpl, which is not overrided and
thus it calls itself again and again.
Normally this functions properly, because at startup FacesContext and
ExternalContext are null. I don't really know how, but if you (or the Tomcat)
managed to initialise the FacesContext and the ExternalContext before
subscribeToEvent is invoked, we ran into the infinte loop.
The solution is, of course, really easy, but it was a long way to get there
> @PreDestroy method of Bean in CustomScope not invoked
> -
>
> Key: MYFACES-2396
> URL: https://issues.apache.org/jira/browse/MYFACES-2396
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
>Reporter: Jakob Korherr
>Assignee: Leonardo Uribe
> Attachments: myfaces-2396-final.patch, myfaces_2396_proposal.patch
>
>
> Testing the mojarra 2.0.1 sample "custom-bean-scope", MyFaces does NOT behave
> like Mojarra.
> The problem is that MyFaces does not propagate a PreDestroyCustomScopeEvent
> correctly. The following code is from the mojarra sample and shows how the
> event is published:
> public void notifyDestroy() {
> // notify interested parties that this scope is being
> // destroyed
> ScopeContext scopeContext = new ScopeContext(SCOPE_NAME, this);
> application.publishEvent(FacesContext.getCurrentInstance(),
> PreDestroyCustomScopeEvent.class, scopeContext);
> }
> However, the @PreDestroy method of the Bean, which is stored in the scope, is
> not invoked.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2396) @PreDestroy method of Bean in CustomScope not invoked
[
https://issues.apache.org/jira/browse/MYFACES-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakob Korherr updated MYFACES-2396:
---
Status: Patch Available (was: Reopened)
> @PreDestroy method of Bean in CustomScope not invoked
> -
>
> Key: MYFACES-2396
> URL: https://issues.apache.org/jira/browse/MYFACES-2396
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
>Reporter: Jakob Korherr
>Assignee: Leonardo Uribe
> Attachments: myfaces-2396-final.patch, myfaces-2396-no-loop.patch,
> myfaces_2396_proposal.patch
>
>
> Testing the mojarra 2.0.1 sample "custom-bean-scope", MyFaces does NOT behave
> like Mojarra.
> The problem is that MyFaces does not propagate a PreDestroyCustomScopeEvent
> correctly. The following code is from the mojarra sample and shows how the
> event is published:
> public void notifyDestroy() {
> // notify interested parties that this scope is being
> // destroyed
> ScopeContext scopeContext = new ScopeContext(SCOPE_NAME, this);
> application.publishEvent(FacesContext.getCurrentInstance(),
> PreDestroyCustomScopeEvent.class, scopeContext);
> }
> However, the @PreDestroy method of the Bean, which is stored in the scope, is
> not invoked.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2446) ExceptionHandlerImpl is not correct
ExceptionHandlerImpl is not correct --- Key: MYFACES-2446 URL: https://issues.apache.org/jira/browse/MYFACES-2446 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha-2 Reporter: Jakob Korherr While performing a lot of ExceptionHandler related tests on mojarra, I found out that MyFaces' ExceptionHandlerImpl behaves differently in some cases. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2446) ExceptionHandlerImpl is not correct
[ https://issues.apache.org/jira/browse/MYFACES-2446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr updated MYFACES-2446: --- Status: Patch Available (was: Open) > ExceptionHandlerImpl is not correct > --- > > Key: MYFACES-2446 > URL: https://issues.apache.org/jira/browse/MYFACES-2446 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Affects Versions: 2.0.0-alpha-2 >Reporter: Jakob Korherr > Attachments: myfaces-2446.patch > > > While performing a lot of ExceptionHandler related tests on mojarra, I found > out that MyFaces' ExceptionHandlerImpl behaves differently in some cases. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2447) PhaseListeners not invoked correctly
PhaseListeners not invoked correctly Key: MYFACES-2447 URL: https://issues.apache.org/jira/browse/MYFACES-2447 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.0-alpha-2 Reporter: Jakob Korherr See spec 12.3 PhaseListener for details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2453) f:view is ignored by facelets
f:view is ignored by facelets - Key: MYFACES-2453 URL: https://issues.apache.org/jira/browse/MYFACES-2453 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-alpha-2 Reporter: Jakob Korherr On facelets f:view is no longer needed, but it still can be used to set the locale or to register the beforePhase and the afterPhase MethodExpressions on UIViewRoot. So the following code has to work on facelets: At the moment, is just ignored by facelets. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2374) UIViewRoot.getBeforePhaseListener() and UIViewRoot.getAfterPhaseListener() could be called on PhaseId.RESTORE_VIEW
[ https://issues.apache.org/jira/browse/MYFACES-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787615#action_12787615 ] Jakob Korherr commented on MYFACES-2374: I finally (and incidentally) found a section in the spec where this problem is described, section 4.1.19.4 Events. »UIViewRoot must listen to the top level PostAddToViewEvent sent by the Restore View phase. [...] Upon receiving this event, UIViewRoot must cause any "after" Restore View phase listeners to be called«. > UIViewRoot.getBeforePhaseListener() and UIViewRoot.getAfterPhaseListener() > could be called on PhaseId.RESTORE_VIEW > -- > > Key: MYFACES-2374 > URL: https://issues.apache.org/jira/browse/MYFACES-2374 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Reporter: Leonardo Uribe > Attachments: restore_view_phaselistener.patch, > restore_view_phaselistener_newest.patch > > > Note that on jsf 1.2 this is not true. The problem with this one is how call > UIViewRoot beforePhaseListener before PhaseId.RESTORE_VIEW, because in theory > we need to "restore it" before call it. Maybe the solution is call it from > the place where the state is restored (JspStateManagerImpl). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2447) PhaseListeners not invoked correctly
[ https://issues.apache.org/jira/browse/MYFACES-2447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr updated MYFACES-2447: --- Status: Patch Available (was: Open) > PhaseListeners not invoked correctly > > > Key: MYFACES-2447 > URL: https://issues.apache.org/jira/browse/MYFACES-2447 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.0.0-alpha-2 >Reporter: Jakob Korherr > Attachments: myfaces-2447.patch > > > See spec 12.3 PhaseListener for details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2454) facelet error-pages should be supported
facelet error-pages should be supported --- Key: MYFACES-2454 URL: https://issues.apache.org/jira/browse/MYFACES-2454 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha-2 Reporter: Jakob Korherr see spec section »6.2.3 Default Error Page« for details. This includes the following tasks: - should include the standard error page (created by _ErrorPageWriter in MyFaces) in any facelet error page defined in web.xml - entries in web.xml should take priority over MyFaces' default error page (currently you have to disable it via org.apache.myfaces.ERROR_HANDLING first) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2459) PreJsf2ExceptionHandlerImpl not correct
PreJsf2ExceptionHandlerImpl not correct --- Key: MYFACES-2459 URL: https://issues.apache.org/jira/browse/MYFACES-2459 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha-2 Reporter: Jakob Korherr Since ExceptionHandlerImpl changed, this class also has to be changed. Furthermore, the features described in spec section 6.2.2 and the spec javadoc of PreJsf2ExceptionHandlerFactory are not implemented so far. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2459) PreJsf2ExceptionHandlerImpl not correct
[ https://issues.apache.org/jira/browse/MYFACES-2459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr updated MYFACES-2459: --- Status: Patch Available (was: Open) > PreJsf2ExceptionHandlerImpl not correct > --- > > Key: MYFACES-2459 > URL: https://issues.apache.org/jira/browse/MYFACES-2459 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Affects Versions: 2.0.0-alpha-2 >Reporter: Jakob Korherr > Attachments: myfaces-2459.patch > > > Since ExceptionHandlerImpl changed, this class also has to be changed. > Furthermore, the features described in spec section 6.2.2 and the spec > javadoc of PreJsf2ExceptionHandlerFactory are not implemented so far. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2458) Miscellaneous AJAX bugs
[
https://issues.apache.org/jira/browse/MYFACES-2458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12788941#action_12788941
]
Jakob Korherr commented on MYFACES-2458:
Actually, I think there are a LOT more at the moment. This is my list of
problems (the problems you mentioned already excluded):
* h:commandButton with does not work outside h:form (on mojarra it
does)
* h:commandLink needs to add a backslash (\) before every apostrophe (')
on oamSubmitForm, because this is already inside of apostrophes; an example:
[...] 'return
oamSubmitForm('j_id905601284_35fa614a','j_id905601284_35fa614a:j_id905601284_35fa6171');'
[...]
causing the following javascript error:
Fehler: missing ) after argument list
Quelldatei: http://localhost:8080/myfaces-test/facelet.xhtml
Zeile: 1, Spalte: 2
Quelltext:
('j_id905601284_35fa614a','j_id905601284_35fa614a:j_id905601284_35fa6171');');
And I am sure that there are a lot more. :(
> Miscellaneous AJAX bugs
> ---
>
> Key: MYFACES-2458
> URL: https://issues.apache.org/jira/browse/MYFACES-2458
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
>Affects Versions: 2.0.0-alpha-2
>Reporter: Curtiss Howard
>Priority: Minor
>
> There are a couple minor AJAX-related bugs:
> * h:commandButton needs to append "return false;" for onclick when a behavior
> chain is present.
> * if disabled=true, the AJAX call is still emitted.
> * Possible issue with execute="multiple ids". Seems the
> javax.faces.partial.execute request param may differ from Sun RI.
> * Unable to restore StateHolder when listener is specified for .
> * onevent not being handled.
> * onerror not being handled.
> * render="@all" not working correctly.
> * render="@form" not working correctly.
> * render="@this" not working correctly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2454) facelet error-pages should be supported
[
https://issues.apache.org/jira/browse/MYFACES-2454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789737#action_12789737
]
Jakob Korherr commented on MYFACES-2454:
I am stuck at the first task, input would be appreciated!!
Spec section 6.2.3 explains the Default Error Page, which is generated in
MyFaces via the package private class javax.faces.webapp._ErrorPageWriter. The
spec says, if we have an definition in web.xml that points to a
facelet page, this facelet page must be able to include the information
produced by (in case of MyFaces) _ErrorPageWriter via .
is handled by
org.apache.myfaces.view.facelets.tag.ui.IncludeHandler, thus it is part of
myfaces-impl and it cannot access _ErrorPageWriter.
So there a few ways to solve this problem:
1) Duplicate _ErrorPageWriter to myfaces-impl, which is just ugly
2) Move _ErrorPageWriter to myfaces-impl and make it public. This would also
allow custom error handlers (org.apache.myfaces.ERROR_HANDLER) to fall back to
the default behaviour (there was a request for that in the myfaces-user-list
recently).
However, we would not be able to invoke the ErrorPageWriter in FacesServlet's
service method any more. So we would have to invoke it either from
LifecycleImpl or from ResourceHandlerImpl, if the current request is a resource
request. Looking at the code in FacesServlet maybe makes things clearer:
...
try
{
ResourceHandler resourceHandler =
facesContext.getApplication().getResourceHandler();
if (resourceHandler.isResourceRequest(facesContext))
{
resourceHandler.handleResourceRequest(facesContext);
}
else
{
_handleStandardRequest(facesContext);
}
}
catch (Exception e)
{
handleLifecycleException(facesContext, e);
}
...
This solution would also allow us to generate different error pages for
resource requests, because currently we always a text/html error page, also if
the request was for example image/jpg.
3) Invoke the _ErrorPageWriter in FacesServlet in either way, but if there is
an in web.xml, save the output in a request-scoped variable, which
can be accessed by IncludeHandler, instead of writing it directly to the
request writer.
Input would be highly appreciated!
> facelet error-pages should be supported
> ---
>
> Key: MYFACES-2454
> URL: https://issues.apache.org/jira/browse/MYFACES-2454
> Project: MyFaces Core
> Issue Type: Task
> Components: JSR-314
>Affects Versions: 2.0.0-alpha-2
>Reporter: Jakob Korherr
>
> see spec section »6.2.3 Default Error Page« for details.
> This includes the following tasks:
> - should include the standard
> error page (created by _ErrorPageWriter in MyFaces) in any facelet error page
> defined in web.xml
> - entries in web.xml should take priority over MyFaces' default
> error page (currently you have to disable it via
> org.apache.myfaces.ERROR_HANDLING first)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2461) MissingResourceException while processing of must not be handled by the ExceptionHandler
MissingResourceException while processing of must not be handled by the ExceptionHandler - Key: MYFACES-2461 URL: https://issues.apache.org/jira/browse/MYFACES-2461 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha-2 Reporter: Jakob Korherr Spec section »6.2 ExceptionHandler« describes some cases which must not be handled by the ExceptionHandler. One of them is: - The case when a MissingResourceException is thrown during the processing of the tag. However, mojarra currently does handle this Exception with its ExceptionHandler and the spec does not describe what to do with the MissingResourceException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2462) is not working
is not working --- Key: MYFACES-2462 URL: https://issues.apache.org/jira/browse/MYFACES-2462 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-alpha-2 Reporter: Jakob Korherr While implementing the new ErrorPageWriter on myfaces-impl, I checked all cases in which error or debug output is generated. Testing I found out that no debug information is displayed. The debug window just displays the current view. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2462) is not working
[ https://issues.apache.org/jira/browse/MYFACES-2462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr updated MYFACES-2462: --- Status: Patch Available (was: Open) > is not working > --- > > Key: MYFACES-2462 > URL: https://issues.apache.org/jira/browse/MYFACES-2462 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314 >Affects Versions: 2.0.0-alpha-2 >Reporter: Jakob Korherr > Attachments: myfaces-2462.patch > > > While implementing the new ErrorPageWriter on myfaces-impl, I checked all > cases in which error or debug output is generated. > Testing I found out that no debug information is displayed. The > debug window just displays the current view. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2454) Adapt default error page generation to new spec
[ https://issues.apache.org/jira/browse/MYFACES-2454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12792192#action_12792192 ] Jakob Korherr commented on MYFACES-2454: I came up with the following solution for the backwards compatibility: - org.apache.myfaces.ERROR_HANDLING will be dismissed by MyFaces 2.0, because we will always handle the Exception with the ExceptionHandler (the spec tells us to). - org.apache.myfaces.ERROR_HANDLER can still be used, but only in conjunction with javax.faces.webapp.PreJsf2ExceptionHandlerFactory. However, only the method handleException(FacesContext context, Exception e) has to be provided. > Adapt default error page generation to new spec > --- > > Key: MYFACES-2454 > URL: https://issues.apache.org/jira/browse/MYFACES-2454 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Affects Versions: 2.0.0-alpha-2 >Reporter: Jakob Korherr > > see spec section »6.2.3 Default Error Page« for details. > This includes the following tasks: > - should include the standard > error page (created by _ErrorPageWriter in MyFaces) in any facelet error page > defined in web.xml > - entries in web.xml should take priority over MyFaces' default > error page (currently you have to disable it via > org.apache.myfaces.ERROR_HANDLING first) > - UIInput should create an UpdateModelException and publish it, if an > exception occurs in updateModel() -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2464) Find a way to do not use ELExpressions on jsf.js for getProjectStage
[ https://issues.apache.org/jira/browse/MYFACES-2464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12792229#action_12792229 ] Jakob Korherr commented on MYFACES-2464: what if we store two implementations of jsf.js on the server. one with a hardcoded "Development" and the other with a hardcoded "Production" return value in getProjectStage() and we decide on the server which implementation is streamed to the client. > Find a way to do not use ELExpressions on jsf.js for getProjectStage > > > Key: MYFACES-2464 > URL: https://issues.apache.org/jira/browse/MYFACES-2464 > Project: MyFaces Core > Issue Type: Improvement > Components: JSR-314 >Affects Versions: 2.0.0-alpha >Reporter: Leonardo Uribe > > After do some tests, it was detected RI 2.0.1 uses other strategy to do that. > Instead using an ELExpression to retrieve the project stage when jsf.js is > send, uses a combination of javascript and rewrite request path to send this > value. If the application is not on Production stage the url written by the > script looks like this: >
[jira] Commented: (MYFACES-2464) Find a way to do not use ELExpressions on jsf.js for getProjectStage
[ https://issues.apache.org/jira/browse/MYFACES-2464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12792243#action_12792243 ] Jakob Korherr commented on MYFACES-2464: Actually, I was also thinking of that. We could just run through all script elements of the document and look for stage=XXX. > Find a way to do not use ELExpressions on jsf.js for getProjectStage > > > Key: MYFACES-2464 > URL: https://issues.apache.org/jira/browse/MYFACES-2464 > Project: MyFaces Core > Issue Type: Improvement > Components: JSR-314 >Affects Versions: 2.0.0-alpha >Reporter: Leonardo Uribe > > After do some tests, it was detected RI 2.0.1 uses other strategy to do that. > Instead using an ELExpression to retrieve the project stage when jsf.js is > send, uses a combination of javascript and rewrite request path to send this > value. If the application is not on Production stage the url written by the > script looks like this: >
[jira] Updated: (MYFACES-2454) Adapt default error page generation to new spec
[ https://issues.apache.org/jira/browse/MYFACES-2454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr updated MYFACES-2454: --- Status: Patch Available (was: Open) > Adapt default error page generation to new spec > --- > > Key: MYFACES-2454 > URL: https://issues.apache.org/jira/browse/MYFACES-2454 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Affects Versions: 2.0.0-alpha-2 >Reporter: Jakob Korherr > Attachments: myfaces-2454.patch > > > see spec section »6.2.3 Default Error Page« for details. > This includes the following tasks: > - should include the standard > error page (created by _ErrorPageWriter in MyFaces) in any facelet error page > defined in web.xml > - entries in web.xml should take priority over MyFaces' default > error page (currently you have to disable it via > org.apache.myfaces.ERROR_HANDLING first) > - UIInput should create an UpdateModelException and publish it, if an > exception occurs in updateModel() > - The error page should also include the view and the flash scope attributes -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2465) PreJsf2ExceptionHandlerFactory should create new instances of PreJsf2ExceptionHandlerImpl for each call to getExceptionHandler()
PreJsf2ExceptionHandlerFactory should create new instances of PreJsf2ExceptionHandlerImpl for each call to getExceptionHandler() Key: MYFACES-2465 URL: https://issues.apache.org/jira/browse/MYFACES-2465 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha-2 Reporter: Jakob Korherr ...otherwise the properties of PreJsf2ExceptionHandlerImpl (handled, unhandled, handledAndThrown) will be shared by all requests of all users. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2465) PreJsf2ExceptionHandlerFactory should create new instances of PreJsf2ExceptionHandlerImpl for each call to getExceptionHandler()
[ https://issues.apache.org/jira/browse/MYFACES-2465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr updated MYFACES-2465: --- Status: Patch Available (was: Open) > PreJsf2ExceptionHandlerFactory should create new instances of > PreJsf2ExceptionHandlerImpl for each call to getExceptionHandler() > > > Key: MYFACES-2465 > URL: https://issues.apache.org/jira/browse/MYFACES-2465 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Affects Versions: 2.0.0-alpha-2 >Reporter: Jakob Korherr > Attachments: myfaces-2465.patch > > > ...otherwise the properties of PreJsf2ExceptionHandlerImpl (handled, > unhandled, handledAndThrown) will be shared by all requests of all users. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2461) MissingResourceException while processing of must not be handled by the ExceptionHandler
[ https://issues.apache.org/jira/browse/MYFACES-2461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12793223#action_12793223 ] Jakob Korherr commented on MYFACES-2461: Maybe this is meant by the statement in the spec (copied from the description of f:loadBundle): The Map must behave such that if a get() call is made for a key that does not exist in the Map, the literal string ???KEY??? is returned from the Map, where KEY is the key being looked up in the Map, instead of a MissingResourceException being thrown. Any other ideas? > MissingResourceException while processing of must not be > handled by the ExceptionHandler > - > > Key: MYFACES-2461 > URL: https://issues.apache.org/jira/browse/MYFACES-2461 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Affects Versions: 2.0.0-alpha-2 >Reporter: Jakob Korherr > > Spec section »6.2 ExceptionHandler« describes some cases which must not be > handled by the ExceptionHandler. One of them is: > - The case when a MissingResourceException is thrown during the processing of > the tag. > However, mojarra currently does handle this Exception with its > ExceptionHandler and the spec does not describe what to do with the > MissingResourceException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2453) f:view is ignored by facelets
[ https://issues.apache.org/jira/browse/MYFACES-2453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr updated MYFACES-2453: --- Status: Patch Available (was: Open) > f:view is ignored by facelets > - > > Key: MYFACES-2453 > URL: https://issues.apache.org/jira/browse/MYFACES-2453 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314 >Affects Versions: 2.0.0-alpha-2 >Reporter: Jakob Korherr > Attachments: myfaces-2453.patch > > > On facelets f:view is no longer needed, but it still can be used to set the > locale or to register the beforePhase and the afterPhase MethodExpressions on > UIViewRoot. > So the following code has to work on facelets: > /> > At the moment, is just ignored by facelets. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2466) NullPointerException in UIComponentBase.restoreDeltaSystemEventListenerClassMap() when UIViewRoot subscribed to PostAddToViewEvent
NullPointerException in UIComponentBase.restoreDeltaSystemEventListenerClassMap() when UIViewRoot subscribed to PostAddToViewEvent -- Key: MYFACES-2466 URL: https://issues.apache.org/jira/browse/MYFACES-2466 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-alpha-2 Reporter: Jakob Korherr java.lang.NullPointerException at javax.faces.component.UIComponentBase.restoreDeltaSystemEventListenerClassMap(UIComponentBase.java:1770) at javax.faces.component.UIComponentBase.restoreState(UIComponentBase.java:1611) at javax.faces.component.UIViewRoot.restoreState(UIViewRoot.java:1161) at org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.restoreStateFromMap(DefaultFaceletsStateManagementStrategy.java:379) at org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.restoreView(DefaultFaceletsStateManagementStrategy.java:181) at org.apache.myfaces.application.jsp.JspStateManagerImpl.restoreView(JspStateManagerImpl.java:388) at org.apache.myfaces.view.ViewDeclarationLanguageBase.restoreView(ViewDeclarationLanguageBase.java:106) at org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.restoreView(FaceletViewDeclarationLanguage.java:972) at org.apache.myfaces.application.ViewHandlerImpl.restoreView(ViewHandlerImpl.java:231) at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:106) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:129) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:85) at javax.faces.webapp.FacesServlet._handleStandardRequest(FacesServlet.java:453) ... 13 more In this scenario savedObject is an instance of _AttachedDeltaWrapper, but _systemEventListenerClassMap is empty and so it returns null for get(entry.getKey()). Thus a NullPointerException is thrown in the following line (UIComponentBase.java:1770). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2435) f:facet can have more than one child
[ https://issues.apache.org/jira/browse/MYFACES-2435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12793614#action_12793614 ] Jakob Korherr commented on MYFACES-2435: spec describes this behaviour in section 10.4.1.3 : " [...] The implementation must ensure that the direct child of the facet is a UIPanel, even if there is only one child of the facet. [...]" > f:facet can have more than one child > > > Key: MYFACES-2435 > URL: https://issues.apache.org/jira/browse/MYFACES-2435 > Project: MyFaces Core > Issue Type: Improvement > Components: JSR-314 >Affects Versions: 2.0.0-alpha >Reporter: Jakob Korherr > > MIchael Kurz tested Mojarra and found out that now can have more > than one child. If so, the children will automaticall be put in a UIPanel to > serve facet requirements. > However, this improvement is not mentioned in the spec, filed spec issue: > https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=677 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2468) MyFaces needs to support adding a in faces-config.xml
[ https://issues.apache.org/jira/browse/MYFACES-2468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794798#action_12794798 ] Jakob Korherr commented on MYFACES-2468: are you planning to submit a patch for this issue, mark? if no, I'll take a look at it today or tomorrow. > MyFaces needs to support adding a in faces-config.xml > > > Key: MYFACES-2468 > URL: https://issues.apache.org/jira/browse/MYFACES-2468 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.0.0-alpha >Reporter: Mark Struberg >Priority: Critical > > The JSF-2 spec defines the tag to enable alternate VDLs via > faces-config.xml. > Since there is almost no component library out there which works with the > built-in facelets-2 VDL, this is a showstopper for a lot scenarios: > The way I need to use it (tried running RichFaces-3.3.3, Trinidad and > PrimeFaces-2.0.CR1) : > in web.xml: > >javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER >true > > and in faces-config.xml: > >com.sun.facelets.FaceletViewHandler > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2435) f:facet can have more than one child
[ https://issues.apache.org/jira/browse/MYFACES-2435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr updated MYFACES-2435: --- Status: Patch Available (was: Open) > f:facet can have more than one child > > > Key: MYFACES-2435 > URL: https://issues.apache.org/jira/browse/MYFACES-2435 > Project: MyFaces Core > Issue Type: Improvement > Components: JSR-314 >Affects Versions: 2.0.0-alpha >Reporter: Jakob Korherr > Attachments: myfaces-2435.patch > > > MIchael Kurz tested Mojarra and found out that now can have more > than one child. If so, the children will automaticall be put in a UIPanel to > serve facet requirements. > However, this improvement is not mentioned in the spec, filed spec issue: > https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=677 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2468) MyFaces needs to support adding a in faces-config.xml
[ https://issues.apache.org/jira/browse/MYFACES-2468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794816#action_12794816 ] Jakob Korherr commented on MYFACES-2468: OK - I'll take a look at it and provide a patch soon! ...and it would be really great, if you could test it :) I'm afraid there is no other way. I think the idea is that facelets-2 is an improvement of facelets-1 and it should be somehow backwards compatible, but I don't know exactly. > MyFaces needs to support adding a in faces-config.xml > > > Key: MYFACES-2468 > URL: https://issues.apache.org/jira/browse/MYFACES-2468 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.0.0-alpha >Reporter: Mark Struberg >Priority: Critical > > The JSF-2 spec defines the tag to enable alternate VDLs via > faces-config.xml. > Since there is almost no component library out there which works with the > built-in facelets-2 VDL, this is a showstopper for a lot scenarios: > The way I need to use it (tried running RichFaces-3.3.3, Trinidad and > PrimeFaces-2.0.CR1) : > in web.xml: > >javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER >true > > and in faces-config.xml: > >com.sun.facelets.FaceletViewHandler > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2454) Adapt default error page generation to new spec
[ https://issues.apache.org/jira/browse/MYFACES-2454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794965#action_12794965 ] Jakob Korherr commented on MYFACES-2454: OK, I'll provide a patch which handles org.apache.myfaces.ERROR_HANDLING. It may simplify the development of a jsf application. I will change it to this behaviour: If org.apache.myfaces.ERROR_HANDLING is true, a custom ExceptionHandler will be automatically installed, which rethrows every exception. Furthermore no error page will be created. > Adapt default error page generation to new spec > --- > > Key: MYFACES-2454 > URL: https://issues.apache.org/jira/browse/MYFACES-2454 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Affects Versions: 2.0.0-alpha-2 >Reporter: Jakob Korherr > Attachments: myfaces-2454.patch > > > see spec section »6.2.3 Default Error Page« for details. > This includes the following tasks: > - should include the standard > error page (created by _ErrorPageWriter in MyFaces) in any facelet error page > defined in web.xml > - entries in web.xml should take priority over MyFaces' default > error page (currently you have to disable it via > org.apache.myfaces.ERROR_HANDLING first) > - UIInput should create an UpdateModelException and publish it, if an > exception occurs in updateModel() > - The error page should also include the view and the flash scope attributes -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (MYFACES-2454) Adapt default error page generation to new spec
[ https://issues.apache.org/jira/browse/MYFACES-2454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794965#action_12794965 ] Jakob Korherr edited comment on MYFACES-2454 at 12/29/09 2:12 PM: -- OK, I'll provide a patch which handles org.apache.myfaces.ERROR_HANDLING. It may simplify the development of a jsf application. I will change it to this behaviour: If org.apache.myfaces.ERROR_HANDLING is false, a custom ExceptionHandler will be automatically installed, which rethrows every exception. Furthermore no error page will be created. was (Author: jakobkorherr): OK, I'll provide a patch which handles org.apache.myfaces.ERROR_HANDLING. It may simplify the development of a jsf application. I will change it to this behaviour: If org.apache.myfaces.ERROR_HANDLING is true, a custom ExceptionHandler will be automatically installed, which rethrows every exception. Furthermore no error page will be created. > Adapt default error page generation to new spec > --- > > Key: MYFACES-2454 > URL: https://issues.apache.org/jira/browse/MYFACES-2454 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Affects Versions: 2.0.0-alpha-2 >Reporter: Jakob Korherr > Attachments: myfaces-2454.patch > > > see spec section »6.2.3 Default Error Page« for details. > This includes the following tasks: > - should include the standard > error page (created by _ErrorPageWriter in MyFaces) in any facelet error page > defined in web.xml > - entries in web.xml should take priority over MyFaces' default > error page (currently you have to disable it via > org.apache.myfaces.ERROR_HANDLING first) > - UIInput should create an UpdateModelException and publish it, if an > exception occurs in updateModel() > - The error page should also include the view and the flash scope attributes -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2468) MyFaces needs to support adding a in faces-config.xml
[ https://issues.apache.org/jira/browse/MYFACES-2468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795078#action_12795078 ] Jakob Korherr commented on MYFACES-2468: Hi Mark! I did a lot of tests and I found out that adding a in faces-config.xml is not the problem. MyFaces does register the view handler com.sun.facelets.FaceletViewHandler if you tell it to!! The problem is that com.sun.facelets.FaceletViewHandler uses its parent ViewHandler in many cases. On JSF 1.2 the parent handler is JspViewHandlerImpl and on JSF 2.0 it is ViewHandlerImpl, which behaves differently in many cases. Besides that JSF 2.0 uses the class ViewDeclarationLanguage to process the view and com.sun.facelets.FaceletViewHandler, of course, does not provide an implementation of ViewDeclarationLanguage. So com.sun.facelets.FaceletViewHandler uses the VDL of his parent (ViewHandlerImpl), which is in our case JspViewDeclarationLanguage, because we set javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER to true. This leads to an infinite loop when trying to render a facelet view. So we have to provide a ViewDeclarationLanguage for facelets-1. I created a very simple one, wrote a factory for it and registered it in faces-config.xml with at.jakobkorherr.myfaces.test.Facelets1ViewDeclarationLanguageFactory I'll attach both files to this issue, but keep in mind that they were developed quick and dirty and just to get facelets-1 running. Then there was only one problem left: MyFaces used .jsp to find my facelets in the file system. This problem can be solved by adding javax.faces.DEFAULT_SUFFIX .xhtml in web.xml. With these »workarounds« you can run facelets-1 on MyFaces 2.0. However, a lot of new features will not function properly. On my opinion it should not be anyone's target to get facelets-1 code running on JSF 2.0, because then you are not able to use most of the new JSF 2.0 features. This means you could also use JSF 1.2. Besides that most features of facelets-1 should be easy to migrate to facelets-2, I think. Furthermore I think that all those taglibs will soon be available for JSF 2.0 also, for example RichFaces 4.0.0. It is just a matter of time, I guess. > MyFaces needs to support adding a in faces-config.xml > > > Key: MYFACES-2468 > URL: https://issues.apache.org/jira/browse/MYFACES-2468 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.0.0-alpha >Reporter: Mark Struberg >Priority: Critical > Attachments: Facelets1ViewDeclarationLanguage.java, > Facelets1ViewDeclarationLanguageFactory.java > > > The JSF-2 spec defines the tag to enable alternate VDLs via > faces-config.xml. > Since there is almost no component library out there which works with the > built-in facelets-2 VDL, this is a showstopper for a lot scenarios: > The way I need to use it (tried running RichFaces-3.3.3, Trinidad and > PrimeFaces-2.0.CR1) : > in web.xml: > >javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER >true > > and in faces-config.xml: > >com.sun.facelets.FaceletViewHandler > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2363) ExceptionHandler implementation requires deal with ajax responses
[ https://issues.apache.org/jira/browse/MYFACES-2363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795318#action_12795318 ] Jakob Korherr commented on MYFACES-2363: FYI: I already have a solution for this issue, but I need my latest patch for MYFACES-2454 to be committed first. > ExceptionHandler implementation requires deal with ajax responses > - > > Key: MYFACES-2363 > URL: https://issues.apache.org/jira/browse/MYFACES-2363 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Reporter: Leonardo Uribe > > See jsf 2.0 spec section 13.3.7 > "Implementations must ensure that an ExceptionHandler suitable for > writing exceptions to the partial response is installed if the current > request required an Ajax response (PartialViewContext.isAjaxRequest() returns > true)..." > " Implementations may choose to include a specialized ExceptionHandler > for Ajax that extends from javax.faces.context.ExceptionHandlerWrapper, and > have the javax.faces.context.ExceptionHandlerFactory implementation install > it if the environment requires it ." -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2464) Find a way to do not use ELExpressions on jsf.js for getProjectStage
[ https://issues.apache.org/jira/browse/MYFACES-2464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr updated MYFACES-2464: --- Status: Patch Available (was: Open) > Find a way to do not use ELExpressions on jsf.js for getProjectStage > > > Key: MYFACES-2464 > URL: https://issues.apache.org/jira/browse/MYFACES-2464 > Project: MyFaces Core > Issue Type: Improvement > Components: JSR-314 >Affects Versions: 2.0.0-alpha >Reporter: Leonardo Uribe > Attachments: myfaces-2464.patch > > > After do some tests, it was detected RI 2.0.1 uses other strategy to do that. > Instead using an ELExpression to retrieve the project stage when jsf.js is > send, uses a combination of javascript and rewrite request path to send this > value. If the application is not on Production stage the url written by the > script looks like this: >
[jira] Commented: (MYFACES-2468) MyFaces needs to support adding a in faces-config.xml
[ https://issues.apache.org/jira/browse/MYFACES-2468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12796759#action_12796759 ] Jakob Korherr commented on MYFACES-2468: checking this again in the spec (section 11.1.3) and with blackbox tests of mojarra, we do have to support facelets-1.x without any custom ViewDeclarationLanguage. I'll provide a patch soon. > MyFaces needs to support adding a in faces-config.xml > > > Key: MYFACES-2468 > URL: https://issues.apache.org/jira/browse/MYFACES-2468 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.0.0-alpha >Reporter: Mark Struberg >Priority: Critical > Attachments: Facelets1ViewDeclarationLanguage.java, > Facelets1ViewDeclarationLanguageFactory.java > > > The JSF-2 spec defines the tag to enable alternate VDLs via > faces-config.xml. > Since there is almost no component library out there which works with the > built-in facelets-2 VDL, this is a showstopper for a lot scenarios: > The way I need to use it (tried running RichFaces-3.3.3, Trinidad and > PrimeFaces-2.0.CR1) : > in web.xml: > >javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER >true > > and in faces-config.xml: > >com.sun.facelets.FaceletViewHandler > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2374) UIViewRoot.getBeforePhaseListener() and UIViewRoot.getAfterPhaseListener() could be called on PhaseId.RESTORE_VIEW
[ https://issues.apache.org/jira/browse/MYFACES-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12797643#action_12797643 ] Jakob Korherr commented on MYFACES-2374: Looks like we will be getting some answers for this in Mojarra 2.0.3 (https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1391) > UIViewRoot.getBeforePhaseListener() and UIViewRoot.getAfterPhaseListener() > could be called on PhaseId.RESTORE_VIEW > -- > > Key: MYFACES-2374 > URL: https://issues.apache.org/jira/browse/MYFACES-2374 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Reporter: Leonardo Uribe > Attachments: myfaces-2374-ideas.patch, > restore_view_phaselistener.patch, restore_view_phaselistener_newest.patch > > > Note that on jsf 1.2 this is not true. The problem with this one is how call > UIViewRoot beforePhaseListener before PhaseId.RESTORE_VIEW, because in theory > we need to "restore it" before call it. Maybe the solution is call it from > the place where the state is restored (JspStateManagerImpl). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2475) Visit facets in UIComponent.visitTree()
[ https://issues.apache.org/jira/browse/MYFACES-2475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12797658#action_12797658 ] Jakob Korherr commented on MYFACES-2475: maybe this is a spec error in the description of UIData.visitTree(). should we notify EG about this? > Visit facets in UIComponent.visitTree() > --- > > Key: MYFACES-2475 > URL: https://issues.apache.org/jira/browse/MYFACES-2475 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314 >Affects Versions: 2.0.0-alpha >Reporter: Michael Kurz > Attachments: MYFACES-2475.patch > > > I am currently trying to get f:ajax running inside a composite component. So > I would say it is necessary to include the facets (use > getFacetsAndChildren() instead of getChildren()) in UIComponent.visitTree(). > The problem with this solution is, that there is a potential conflict with > UIData.visitTree() (also see MYFACES-2137). The result is that facets of > columns are visited twice. I noticed this because UIDataTest.testVisitTree() > fails unless the line expecting the column facet is in the code twice. > I tried the same example with Mojarra anwith the same result: the column > facet is visited twice. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2475) Visit facets in UIComponent.visitTree()
[ https://issues.apache.org/jira/browse/MYFACES-2475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12797670#action_12797670 ] Jakob Korherr commented on MYFACES-2475: I think when applying this patch, we should also change UIData.visitTree() to not visit children's facets directly in order to visit them only once. Although it is not explained in the spec, it is just logical to visit the component's facets in UIComponent.visitTree(). Furthermore I don't think the EG intended that UIData's children's facets are visited twice. > Visit facets in UIComponent.visitTree() > --- > > Key: MYFACES-2475 > URL: https://issues.apache.org/jira/browse/MYFACES-2475 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314 >Affects Versions: 2.0.0-alpha >Reporter: Michael Kurz > Attachments: MYFACES-2475.patch > > > I am currently trying to get f:ajax running inside a composite component. So > I would say it is necessary to include the facets (use > getFacetsAndChildren() instead of getChildren()) in UIComponent.visitTree(). > The problem with this solution is, that there is a potential conflict with > UIData.visitTree() (also see MYFACES-2137). The result is that facets of > columns are visited twice. I noticed this because UIDataTest.testVisitTree() > fails unless the line expecting the column facet is in the code twice. > I tried the same example with Mojarra anwith the same result: the column > facet is visited twice. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2475) Visit facets in UIComponent.visitTree()
[ https://issues.apache.org/jira/browse/MYFACES-2475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12797674#action_12797674 ] Jakob Korherr commented on MYFACES-2475: Not really. Does it make sence to use children in UIData that are not an instance of UIColumn anyway?? > Visit facets in UIComponent.visitTree() > --- > > Key: MYFACES-2475 > URL: https://issues.apache.org/jira/browse/MYFACES-2475 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314 >Affects Versions: 2.0.0-alpha >Reporter: Michael Kurz > Attachments: MYFACES-2475.patch > > > I am currently trying to get f:ajax running inside a composite component. So > I would say it is necessary to include the facets (use > getFacetsAndChildren() instead of getChildren()) in UIComponent.visitTree(). > The problem with this solution is, that there is a potential conflict with > UIData.visitTree() (also see MYFACES-2137). The result is that facets of > columns are visited twice. I noticed this because UIDataTest.testVisitTree() > fails unless the line expecting the column facet is in the code twice. > I tried the same example with Mojarra anwith the same result: the column > facet is visited twice. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2468) MyFaces needs to support adding a in faces-config.xml
[ https://issues.apache.org/jira/browse/MYFACES-2468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr updated MYFACES-2468: --- Status: Patch Available (was: Open) > MyFaces needs to support adding a in faces-config.xml > > > Key: MYFACES-2468 > URL: https://issues.apache.org/jira/browse/MYFACES-2468 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.0.0-alpha >Reporter: Mark Struberg >Priority: Critical > Attachments: Facelets1ViewDeclarationLanguage.java, > Facelets1ViewDeclarationLanguageFactory.java, myfaces-2468.patch > > > The JSF-2 spec defines the tag to enable alternate VDLs via > faces-config.xml. > Since there is almost no component library out there which works with the > built-in facelets-2 VDL, this is a showstopper for a lot scenarios: > The way I need to use it (tried running RichFaces-3.3.3, Trinidad and > PrimeFaces-2.0.CR1) : > in web.xml: > >javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER >true > > and in faces-config.xml: > >com.sun.facelets.FaceletViewHandler > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2468) MyFaces needs to support adding a in faces-config.xml
[ https://issues.apache.org/jira/browse/MYFACES-2468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12797712#action_12797712 ] Jakob Korherr commented on MYFACES-2468: Scott, Yes, the submitted patch is from the newest revision and includes your changes. > MyFaces needs to support adding a in faces-config.xml > > > Key: MYFACES-2468 > URL: https://issues.apache.org/jira/browse/MYFACES-2468 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.0.0-alpha >Reporter: Mark Struberg >Priority: Critical > Attachments: Facelets1ViewDeclarationLanguage.java, > Facelets1ViewDeclarationLanguageFactory.java, myfaces-2468.patch > > > The JSF-2 spec defines the tag to enable alternate VDLs via > faces-config.xml. > Since there is almost no component library out there which works with the > built-in facelets-2 VDL, this is a showstopper for a lot scenarios: > The way I need to use it (tried running RichFaces-3.3.3, Trinidad and > PrimeFaces-2.0.CR1) : > in web.xml: > >javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER >true > > and in faces-config.xml: > >com.sun.facelets.FaceletViewHandler > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2368) Update Render Response Phase to new spec
[ https://issues.apache.org/jira/browse/MYFACES-2368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr updated MYFACES-2368: --- Status: Patch Available (was: Open) > Update Render Response Phase to new spec > > > Key: MYFACES-2368 > URL: https://issues.apache.org/jira/browse/MYFACES-2368 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Reporter: Leonardo Uribe > Attachments: myfaces-2368.patch > > > In few words, the new render response phase requires: > - Publish PreRenderViewEvent > - call vdl.buildView() (and remove this call from > FaceletsViewDeclarationLanguage.renderResponse) > - deal with org.apache.myfaces.context.servlet.ResponseSwitch (on/off when > f:view) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2368) Update Render Response Phase to new spec
[ https://issues.apache.org/jira/browse/MYFACES-2368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12798072#action_12798072 ] Jakob Korherr commented on MYFACES-2368: And to your comment, Leonardo: It's true that f:ajax only works on facelets, but isn't it possible to use the javascript api also on JSPs? > Update Render Response Phase to new spec > > > Key: MYFACES-2368 > URL: https://issues.apache.org/jira/browse/MYFACES-2368 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Reporter: Leonardo Uribe > Attachments: myfaces-2368.patch > > > In few words, the new render response phase requires: > - Publish PreRenderViewEvent > - call vdl.buildView() (and remove this call from > FaceletsViewDeclarationLanguage.renderResponse) > - deal with org.apache.myfaces.context.servlet.ResponseSwitch (on/off when > f:view) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2478) BadPaddingException: Given final block not properly padded
[ https://issues.apache.org/jira/browse/MYFACES-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12798219#action_12798219 ] Jakob Korherr commented on MYFACES-2478: Hi Mark, I always run into this Exception when I have a JSF-page open in the browser, then restart the server and afterwards refresh the JSF-page in the browser or click on some commandButtons or -Links, because the state from "before-restart" is sent back to the server and somehow the server can't encrypt it after the restart. Are you restarting your application to cause this Exception? > BadPaddingException: Given final block not properly padded > -- > > Key: MYFACES-2478 > URL: https://issues.apache.org/jira/browse/MYFACES-2478 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314 >Affects Versions: 2.0.0-alpha >Reporter: Mark Struberg > > Hi running Myfaces Revision 897280 sometimes swallows the following exception > please note that I'm running with facelets-1.1.15B1 on jetty-6.1.22 and have > server side state saving turned on. > javax.faces.FacesException: javax.crypto.BadPaddingException: Given final > block not properly padded > at > org.apache.myfaces.context.ExceptionHandlerImpl.wrap(ExceptionHandlerImpl.java:241) > at > org.apache.myfaces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:156) > at > org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:157) > at > org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:88) > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:189) > at > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1166) > at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178) > at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290) > at > org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:388) > at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:515) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388) > at > org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) > at > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765) > at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418) > at > org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) > at > org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) > at > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) > at org.mortbay.jetty.Server.handle(Server.java:326) > at > org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542) > at > org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:938) > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:755) > at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218) > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) > at > org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409) > at > org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582) > Caused by: javax.crypto.BadPaddingException: Given final block not properly > padded > at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..) > at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..) > at com.sun.crypto.provider.DESCipher.engineDoFinal(DashoA13*..) > at javax.crypto.Cipher.doFinal(DashoA13*..) > at > org.apache.myfaces.shared_impl.util.StateUtils.symmetric(StateUtils.java:471) > at > org.apache.myfaces.shared_impl.util.StateUtils.symmetric(StateUtils.java:513) > at > org.apache.myfaces.shared_impl.util.StateUtils.decrypt(StateUtils.java:313) > at > org.apache.myfaces.shared_impl.util.StateUtils.reconstruct(StateUtils.java:262) > at > org.apache.myfaces.renderkit.html.HtmlResponseStateManager.getSavedState(HtmlResponseStateManager.java:213) > at > org.apache.myfaces.renderkit.html.HtmlResponseStateManager.getState(HtmlResponseStateManager.java:160) > at > org.apache.myfaces.application.jsp.JspStateManagerImpl.restoreView(JspStateManagerImpl.java:406) > at > javax.faces.application.StateManagerWrapper.restoreView(StateManagerWrapper.java:86) > at > org.apache.myfaces.shared_impl.view.ViewD
[jira] Commented: (MYFACES-2479) custom behavior makes form not to be submitted
[
https://issues.apache.org/jira/browse/MYFACES-2479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12798342#action_12798342
]
Jakob Korherr commented on MYFACES-2479:
>From my point of view return false should only be appended if
>ClientBehaviorHint.SUBMITTING is included in ClientBehavior.getHints()
> custom behavior makes form not to be submitted
> --
>
> Key: MYFACES-2479
> URL: https://issues.apache.org/jira/browse/MYFACES-2479
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.0.0-alpha
>Reporter: Matthias Weßendorf
>
> Attaching a simple behavior to a h:commandbutton makes the form to no longer
> submit it.
> Java:
> package net.wessendorf;
> import javax.faces.component.behavior.ClientBehaviorBase;
> import javax.faces.component.behavior.ClientBehaviorContext;
> import javax.faces.component.behavior.FacesBehavior;
> @FacesBehavior("net.wessendorf.Confirm")
> public class ConfirmBehavior extends ClientBehaviorBase
> {
> @Override
> public String getScript(ClientBehaviorContext behaviorContext)
> {
> return "return confirm('Really')";
> }
> }
> taglib.xml:
> http://java.sun.com/xml/ns/javaee";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> http://java.sun.com/xml/ns/javaee/web-facelettaglibrary_2_0.xsd";
>version="2.0">
> http://wessendorf.net/behavior
>
> confirm
>
> net.wessendorf.Confirm
>
>
>
> XHTML file:
>
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2479) custom behavior makes form not to be submitted
[
https://issues.apache.org/jira/browse/MYFACES-2479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12798361#action_12798361
]
Jakob Korherr commented on MYFACES-2479:
to accomplish what you want, jsf.util.chain(...) would have to return the value
from the last function, which it (per specification) does not.
> custom behavior makes form not to be submitted
> --
>
> Key: MYFACES-2479
> URL: https://issues.apache.org/jira/browse/MYFACES-2479
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.0.0-alpha
>Reporter: Matthias Weßendorf
>
> Attaching a simple behavior to a h:commandbutton makes the form to no longer
> submit it.
> Java:
> package net.wessendorf;
> import javax.faces.component.behavior.ClientBehaviorBase;
> import javax.faces.component.behavior.ClientBehaviorContext;
> import javax.faces.component.behavior.FacesBehavior;
> @FacesBehavior("net.wessendorf.Confirm")
> public class ConfirmBehavior extends ClientBehaviorBase
> {
> @Override
> public String getScript(ClientBehaviorContext behaviorContext)
> {
> return "return confirm('Really')";
> }
> }
> taglib.xml:
> http://java.sun.com/xml/ns/javaee";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> http://java.sun.com/xml/ns/javaee/web-facelettaglibrary_2_0.xsd";
>version="2.0">
> http://wessendorf.net/behavior
>
> confirm
>
> net.wessendorf.Confirm
>
>
>
> XHTML file:
>
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2479) custom behavior makes form not to be submitted
[
https://issues.apache.org/jira/browse/MYFACES-2479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12798363#action_12798363
]
Jakob Korherr commented on MYFACES-2479:
How funny, I just tested the same thing!
On my opinion, jsf.util.chain() should be changed to return the return value of
the last executed function.
> custom behavior makes form not to be submitted
> --
>
> Key: MYFACES-2479
> URL: https://issues.apache.org/jira/browse/MYFACES-2479
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.0.0-alpha
>Reporter: Matthias Weßendorf
>
> Attaching a simple behavior to a h:commandbutton makes the form to no longer
> submit it.
> Java:
> package net.wessendorf;
> import javax.faces.component.behavior.ClientBehaviorBase;
> import javax.faces.component.behavior.ClientBehaviorContext;
> import javax.faces.component.behavior.FacesBehavior;
> @FacesBehavior("net.wessendorf.Confirm")
> public class ConfirmBehavior extends ClientBehaviorBase
> {
> @Override
> public String getScript(ClientBehaviorContext behaviorContext)
> {
> return "return confirm('Really')";
> }
> }
> taglib.xml:
> http://java.sun.com/xml/ns/javaee";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> http://java.sun.com/xml/ns/javaee/web-facelettaglibrary_2_0.xsd";
>version="2.0">
> http://wessendorf.net/behavior
>
> confirm
>
> net.wessendorf.Confirm
>
>
>
> XHTML file:
>
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2435) f:facet can have more than one child
[ https://issues.apache.org/jira/browse/MYFACES-2435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12799116#action_12799116 ] Jakob Korherr commented on MYFACES-2435: I know, but spec says that every child of the facet has to be an UIPanel: " [...] The implementation must ensure that the direct child of the facet is a UIPanel, even if there is only one child of the facet. [...]" > f:facet can have more than one child > > > Key: MYFACES-2435 > URL: https://issues.apache.org/jira/browse/MYFACES-2435 > Project: MyFaces Core > Issue Type: Improvement > Components: JSR-314 >Affects Versions: 2.0.0-alpha >Reporter: Jakob Korherr > Attachments: myfaces-2435.patch > > > MIchael Kurz tested Mojarra and found out that now can have more > than one child. If so, the children will automaticall be put in a UIPanel to > serve facet requirements. > However, this improvement is not mentioned in the spec, filed spec issue: > https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=677 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2435) f:facet can have more than one child
[ https://issues.apache.org/jira/browse/MYFACES-2435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12799404#action_12799404 ] Jakob Korherr commented on MYFACES-2435: OK. good solution. > f:facet can have more than one child > > > Key: MYFACES-2435 > URL: https://issues.apache.org/jira/browse/MYFACES-2435 > Project: MyFaces Core > Issue Type: Improvement > Components: JSR-314 >Affects Versions: 2.0.0-alpha >Reporter: Jakob Korherr >Assignee: Leonardo Uribe > Fix For: 2.0.0-alpha-2 > > Attachments: myfaces-2435.patch > > > MIchael Kurz tested Mojarra and found out that now can have more > than one child. If so, the children will automaticall be put in a UIPanel to > serve facet requirements. > However, this improvement is not mentioned in the spec, filed spec issue: > https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=677 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2363) ExceptionHandler implementation requires deal with ajax responses
[ https://issues.apache.org/jira/browse/MYFACES-2363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr updated MYFACES-2363: --- Status: Patch Available (was: Open) > ExceptionHandler implementation requires deal with ajax responses > - > > Key: MYFACES-2363 > URL: https://issues.apache.org/jira/browse/MYFACES-2363 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Reporter: Leonardo Uribe > Attachments: myfaces-2363.patch > > > See jsf 2.0 spec section 13.3.7 > "Implementations must ensure that an ExceptionHandler suitable for > writing exceptions to the partial response is installed if the current > request required an Ajax response (PartialViewContext.isAjaxRequest() returns > true)..." > " Implementations may choose to include a specialized ExceptionHandler > for Ajax that extends from javax.faces.context.ExceptionHandlerWrapper, and > have the javax.faces.context.ExceptionHandlerFactory implementation install > it if the environment requires it ." -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2479) custom behavior makes form not to be submitted
[
https://issues.apache.org/jira/browse/MYFACES-2479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12800158#action_12800158
]
Jakob Korherr commented on MYFACES-2479:
posted in jsr-314-public forum:
http://wiki.jcp.org/boards/index.php?t=3206
> custom behavior makes form not to be submitted
> --
>
> Key: MYFACES-2479
> URL: https://issues.apache.org/jira/browse/MYFACES-2479
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.0.0-alpha
>Reporter: Matthias Weßendorf
>
> Attaching a simple behavior to a h:commandbutton makes the form to no longer
> submit it.
> Java:
> package net.wessendorf;
> import javax.faces.component.behavior.ClientBehaviorBase;
> import javax.faces.component.behavior.ClientBehaviorContext;
> import javax.faces.component.behavior.FacesBehavior;
> @FacesBehavior("net.wessendorf.Confirm")
> public class ConfirmBehavior extends ClientBehaviorBase
> {
> @Override
> public String getScript(ClientBehaviorContext behaviorContext)
> {
> return "return confirm('Really')";
> }
> }
> taglib.xml:
> http://java.sun.com/xml/ns/javaee";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> http://java.sun.com/xml/ns/javaee/web-facelettaglibrary_2_0.xsd";
>version="2.0">
> http://wessendorf.net/behavior
>
> confirm
>
> net.wessendorf.Confirm
>
>
>
> XHTML file:
>
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2485) Ensure invocation of @PreDestroy methods on container shutdown/restart
Ensure invocation of @PreDestroy methods on container shutdown/restart -- Key: MYFACES-2485 URL: https://issues.apache.org/jira/browse/MYFACES-2485 Project: MyFaces Core Issue Type: Improvement Affects Versions: 2.0.0-alpha Reporter: Jakob Korherr Because of the fact that only ServletContextListener.contextDestroyed() is invoked on a container shutdown/restart, the correct destruction of ManagedBeans in session, view and request scope is not ensured. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2485) Ensure invocation of @PreDestroy methods on container shutdown/restart
[ https://issues.apache.org/jira/browse/MYFACES-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12800190#action_12800190 ] Jakob Korherr commented on MYFACES-2485: So you're saying it would be better not to destroy all session beans on a container shutdown, because they are maybe serialized? Then what about a config parameter to turn this feature on or off? And what about view and request beans? > Ensure invocation of @PreDestroy methods on container shutdown/restart > -- > > Key: MYFACES-2485 > URL: https://issues.apache.org/jira/browse/MYFACES-2485 > Project: MyFaces Core > Issue Type: Improvement >Affects Versions: 2.0.0-alpha >Reporter: Jakob Korherr > > Because of the fact that only ServletContextListener.contextDestroyed() is > invoked on a container shutdown/restart, the correct destruction of > ManagedBeans in session, view and request scope is not ensured. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2485) Ensure invocation of @PreDestroy methods on container shutdown/restart
[ https://issues.apache.org/jira/browse/MYFACES-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12800205#action_12800205 ] Jakob Korherr commented on MYFACES-2485: The reason I opened this issue was because I wanted to ensure a very clean container shutdown. I can now see that it is not good destroy the session beans on a container shutdown. However, there are maybe lots of active requests on a productive environment and I think those should definitely be destroyed correctly. The view-scoped beans are stored in the current view and thus in the view state. If we have server-side state saving this is the session and if we have client-side state saving this is the hidden input field. So when using server-side state saving they probably should not be destroyed. However, when using client-side state saving there are problems when restoring the view after a container restart, so these should be destroyed I think. > Ensure invocation of @PreDestroy methods on container shutdown/restart > -- > > Key: MYFACES-2485 > URL: https://issues.apache.org/jira/browse/MYFACES-2485 > Project: MyFaces Core > Issue Type: Improvement >Affects Versions: 2.0.0-alpha >Reporter: Jakob Korherr > > Because of the fact that only ServletContextListener.contextDestroyed() is > invoked on a container shutdown/restart, the correct destruction of > ManagedBeans in session, view and request scope is not ensured. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2485) Ensure invocation of @PreDestroy methods on container shutdown/restart
[ https://issues.apache.org/jira/browse/MYFACES-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12800231#action_12800231 ] Jakob Korherr commented on MYFACES-2485: Well, I did not think that far... So you propose to leave it the way it is, am I right? > Ensure invocation of @PreDestroy methods on container shutdown/restart > -- > > Key: MYFACES-2485 > URL: https://issues.apache.org/jira/browse/MYFACES-2485 > Project: MyFaces Core > Issue Type: Improvement >Affects Versions: 2.0.0-alpha >Reporter: Jakob Korherr > > Because of the fact that only ServletContextListener.contextDestroyed() is > invoked on a container shutdown/restart, the correct destruction of > ManagedBeans in session, view and request scope is not ensured. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2485) Ensure invocation of @PreDestroy methods on container shutdown/restart
[ https://issues.apache.org/jira/browse/MYFACES-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr updated MYFACES-2485: --- Status: Patch Available (was: Open) > Ensure invocation of @PreDestroy methods on container shutdown/restart > -- > > Key: MYFACES-2485 > URL: https://issues.apache.org/jira/browse/MYFACES-2485 > Project: MyFaces Core > Issue Type: Improvement >Affects Versions: 2.0.0-alpha >Reporter: Jakob Korherr > > Because of the fact that only ServletContextListener.contextDestroyed() is > invoked on a container shutdown/restart, the correct destruction of > ManagedBeans in session, view and request scope is not ensured. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2485) Ensure invocation of @PreDestroy methods on container shutdown/restart
[ https://issues.apache.org/jira/browse/MYFACES-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr updated MYFACES-2485: --- Status: Open (was: Patch Available) > Ensure invocation of @PreDestroy methods on container shutdown/restart > -- > > Key: MYFACES-2485 > URL: https://issues.apache.org/jira/browse/MYFACES-2485 > Project: MyFaces Core > Issue Type: Improvement >Affects Versions: 2.0.0-alpha >Reporter: Jakob Korherr > Attachments: myfaces-2485.patch > > > Because of the fact that only ServletContextListener.contextDestroyed() is > invoked on a container shutdown/restart, the correct destruction of > ManagedBeans in session, view and request scope is not ensured. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2488) PreRenderViewEvent-listeners could change UIViewRoot or set responseComplete
PreRenderViewEvent-listeners could change UIViewRoot or set responseComplete Key: MYFACES-2488 URL: https://issues.apache.org/jira/browse/MYFACES-2488 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-alpha-2 Reporter: Jakob Korherr If a SystemEventHandler, which is subscribed to PreRenderViewEvent, changes the current UIViewRoot, the algorithm (vdl.buildView() and publish PreRenderViewEvent) has to be performed again (for the new view) before rendering. Furthermore, such a listener could set responseComplete to true. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2488) PreRenderViewEvent-listeners could change UIViewRoot or set responseComplete
[ https://issues.apache.org/jira/browse/MYFACES-2488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr updated MYFACES-2488: --- Status: Patch Available (was: Open) > PreRenderViewEvent-listeners could change UIViewRoot or set responseComplete > > > Key: MYFACES-2488 > URL: https://issues.apache.org/jira/browse/MYFACES-2488 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314 >Affects Versions: 2.0.0-alpha-2 >Reporter: Jakob Korherr > Attachments: myfaces-2488.patch > > > If a SystemEventHandler, which is subscribed to PreRenderViewEvent, changes > the current UIViewRoot, the algorithm (vdl.buildView() and publish > PreRenderViewEvent) has to be performed again (for the new view) before > rendering. Furthermore, such a listener could set responseComplete to true. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2466) NullPointerException in UIComponentBase.restoreDeltaSystemEventListenerClassMap() when UIViewRoot subscribed to PostAddToViewEvent
[ https://issues.apache.org/jira/browse/MYFACES-2466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12801274#action_12801274 ] Jakob Korherr commented on MYFACES-2466: So, I finally found the problem: The problem is that _systemEventListenerClassMap is saved and restored in the same way as _behaviorsMap, but _systemEventListenerClassMap is not recreated via the view declaration language like _behaviorsMap, because the listeners were added programatically via UIComponent.subscribeToEvent(). So there is no Map instance and there are no _DeltaList instances to which the delta state could be applied. However, I do not know if this already is the right behavior? Are SystemEventListeners on UIComponents only allowed to be applied via the VDL? This would change things... > NullPointerException in > UIComponentBase.restoreDeltaSystemEventListenerClassMap() when UIViewRoot > subscribed to PostAddToViewEvent > -- > > Key: MYFACES-2466 > URL: https://issues.apache.org/jira/browse/MYFACES-2466 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314 >Affects Versions: 2.0.0-alpha-2 >Reporter: Jakob Korherr > Attachments: exception-trigger.patch > > > java.lang.NullPointerException > at > javax.faces.component.UIComponentBase.restoreDeltaSystemEventListenerClassMap(UIComponentBase.java:1770) > at > javax.faces.component.UIComponentBase.restoreState(UIComponentBase.java:1611) > at javax.faces.component.UIViewRoot.restoreState(UIViewRoot.java:1161) > at > org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.restoreStateFromMap(DefaultFaceletsStateManagementStrategy.java:379) > at > org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.restoreView(DefaultFaceletsStateManagementStrategy.java:181) > at > org.apache.myfaces.application.jsp.JspStateManagerImpl.restoreView(JspStateManagerImpl.java:388) > at > org.apache.myfaces.view.ViewDeclarationLanguageBase.restoreView(ViewDeclarationLanguageBase.java:106) > at > org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.restoreView(FaceletViewDeclarationLanguage.java:972) > at > org.apache.myfaces.application.ViewHandlerImpl.restoreView(ViewHandlerImpl.java:231) > at > org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:106) > at > org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:129) > at > org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:85) > at > javax.faces.webapp.FacesServlet._handleStandardRequest(FacesServlet.java:453) > ... 13 more > In this scenario savedObject is an instance of _AttachedDeltaWrapper, but > _systemEventListenerClassMap is empty and so it returns null for > get(entry.getKey()). Thus a NullPointerException is thrown in the following > line (UIComponentBase.java:1770). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2489) Clean up the viewId calculation algorithm
Clean up the viewId calculation algorithm - Key: MYFACES-2489 URL: https://issues.apache.org/jira/browse/MYFACES-2489 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha-2 Reporter: Jakob Korherr The whole viewId calculation process is a big mess. There is DefaultRestoreViewSupport with calculateViewId and deriveViewId and there is DefaultViewHandlerSupport with calculateViewId and calculateAndCheckViewId. Furthermore each viewId gets calculated twice (e.g. first from test.jsf to test.xhtml and then from test.xhtml to test.xhtml, which is not necessary). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2489) Clean up the viewId calculation algorithm
[ https://issues.apache.org/jira/browse/MYFACES-2489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr updated MYFACES-2489: --- Status: Patch Available (was: Open) > Clean up the viewId calculation algorithm > - > > Key: MYFACES-2489 > URL: https://issues.apache.org/jira/browse/MYFACES-2489 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Affects Versions: 2.0.0-alpha-2 >Reporter: Jakob Korherr > Attachments: myfaces-2489.patch > > > The whole viewId calculation process is a big mess. There is > DefaultRestoreViewSupport with calculateViewId and deriveViewId and there is > DefaultViewHandlerSupport with calculateViewId and calculateAndCheckViewId. > Furthermore each viewId gets calculated twice (e.g. first from test.jsf to > test.xhtml and then from test.xhtml to test.xhtml, which is not necessary). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2496) Provide a method to find out if a facelets TagHandler has children or not
Provide a method to find out if a facelets TagHandler has children or not - Key: MYFACES-2496 URL: https://issues.apache.org/jira/browse/MYFACES-2496 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha-2 Reporter: Jakob Korherr Sometimes a TagHandler needs to know if it has children or not (e.g. f:validateBean), but there is no standardized way to determine it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2496) Provide a method to find out if a facelets TagHandler has children or not
[ https://issues.apache.org/jira/browse/MYFACES-2496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr resolved MYFACES-2496. Resolution: Fixed Fix Version/s: 2.0.0-alpha-2 > Provide a method to find out if a facelets TagHandler has children or not > - > > Key: MYFACES-2496 > URL: https://issues.apache.org/jira/browse/MYFACES-2496 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Affects Versions: 2.0.0-alpha-2 >Reporter: Jakob Korherr > Fix For: 2.0.0-alpha-2 > > > Sometimes a TagHandler needs to know if it has children or not (e.g. > f:validateBean), but there is no standardized way to determine it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2410) f:validateBean does not work as container for EditableValueHolders
[ https://issues.apache.org/jira/browse/MYFACES-2410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr resolved MYFACES-2410. Resolution: Fixed Fix Version/s: 2.0.0-alpha-2 Fixed this issue. However, there are some other issues with bean validation. > f:validateBean does not work as container for EditableValueHolders > -- > > Key: MYFACES-2410 > URL: https://issues.apache.org/jira/browse/MYFACES-2410 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314 >Affects Versions: 2.0.0-alpha > Environment: Glassfish v3 prelude and JBoss 6.0.0.M1 >Reporter: Jakob Korherr > Fix For: 2.0.0-alpha-2 > > > Testing the mojarra bean-validation sample on Glassfish v3 prelude and JBoss > 6.0.0.M1, I ran into the following exception: > javax.servlet.ServletException: /placeOrder.xhtmlat line 49 and column 109 > Parent not composite component or an instance of > EditableValueHolder: javax.faces.component.html.htmlf...@494c491b > f:validateBean is used as a container of EditableValueHolders in the sample, > the following code shoes where the error occurs: > > > > > > where includes a form of > some (--> EditableValueHolder) components. > However, f:validateBean is also used inside of some of the > components and works well at this point. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2499) f:validateBean disabled="true" not processed correctly
f:validateBean disabled="true" not processed correctly -- Key: MYFACES-2499 URL: https://issues.apache.org/jira/browse/MYFACES-2499 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-alpha-2 Reporter: Jakob Korherr In the following scenario the bean validator should not be applied for the h:inputText. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
