[jira] [Commented] (MYFACES-3130) [PERF] Avoid unnecessary AbstractList$Itr instances
[ https://issues.apache.org/jira/browse/MYFACES-3130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13032347#comment-13032347 ] Jan-Kees van Andel commented on MYFACES-3130: - One comment. Since we know some of the collections where the performance gain is substantial, I suggest to put some "instanceof ArrayList" checks in the code and log a warning that an ArrayList is more suitable. I know it's not strictly necessary, but at least it warns users for bad performance. About the concurrentmodificationexception, why not just do a list.toArray() and then loop over that array? It might even improve performance (not tested)... > [PERF] Avoid unnecessary AbstractList$Itr instances > --- > > Key: MYFACES-3130 > URL: https://issues.apache.org/jira/browse/MYFACES-3130 > Project: MyFaces Core > Issue Type: Improvement > Components: JSR-314 > Environment: myfaces core trunk >Reporter: Martin Kočí > Attachments: MYFACES-3130-example.patch > > > Similar issue: MYFACES-3129 > loop from java 5: > for (Object object: objects) > creates new instance of AbstractList$Itr, if objects are instance of > ArrayList. > Similar situation is with explicit .iterator() call. > In my testcases, it is about ~ 100 000 instances per request/response. > Creation itself is cheap, but triggers GC lately. > I suggest to use old index-style for (i = 0; i < childCount; i++) if > possible. Are there any rawbacks of index-based iteration? > Children is List and as implementation detail we know that it is instance of > ArrayList. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (MYFACES-3049) Bean Validation doesn't work with Glassfish el-impl-2.2
[
https://issues.apache.org/jira/browse/MYFACES-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan-Kees van Andel resolved MYFACES-3049.
-
Resolution: Fixed
Fix Version/s: 2.0.5-SNAPSHOT
Fixed. Added the check, fallback and warning as discussed with Jakob.
> Bean Validation doesn't work with Glassfish el-impl-2.2
> ---
>
> Key: MYFACES-3049
> URL: https://issues.apache.org/jira/browse/MYFACES-3049
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
>Affects Versions: 2.0.4
> Environment: Tomcat 2.0.29
>Reporter: Jan-Kees van Andel
>Assignee: Jan-Kees van Andel
> Fix For: 2.0.5-SNAPSHOT
>
>
> I have this expression in my Facelet: #{newPaymentBean.payment.toAccount}
> "payment" resolves to the following:
> @Entity
> public class Payment implements Serializable {
> // More stuff...
> @NotNull @AccountNumber private String toAccount;
> // More stuff...
> }
> When debugging in javax.faces.validator._BeanValidatorUELUtils, I noticed the
> following on line 47 "ValueReference valueReference =
> valueExpression.getValueReference(elCtx);":
> * With Glassfish EL, "valueReference.property" is null. This causes the
> BeanValidator to return at line 161, and to skip validation.
> "valueReference.base" points to the Payment object btw.
> * With JUEL 2.2.3, "valueReference.property" is "toAccount", which is correct
> AFAIK.
> I'm not sure whether this is a MyFaces or EL issue. I remember that when I
> wrote the BeanValidator, that the spec literally said what to do. See:
> http://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/validator/BeanValidator.html#validate(javax.faces.context.FacesContext,
> javax.faces.component.UIComponent, java.lang.Object)
> So I guess this is an EL implementation issue, but I filed it nevertheless,
> at least for archiving purposes...
> WDYT?
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-3049) Bean Validation doesn't work with Glassfish el-impl-2.2
[
https://issues.apache.org/jira/browse/MYFACES-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997359#comment-12997359
]
Jan-Kees van Andel commented on MYFACES-3049:
-
Yep, you're right. And I guess we should log a warning (maybe once, to prevent
trashing the log) to show the user that something is wrong with the
configuration (b/c it also hurts performance).
> Bean Validation doesn't work with Glassfish el-impl-2.2
> ---
>
> Key: MYFACES-3049
> URL: https://issues.apache.org/jira/browse/MYFACES-3049
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
>Affects Versions: 2.0.4
> Environment: Tomcat 2.0.29
>Reporter: Jan-Kees van Andel
>
> I have this expression in my Facelet: #{newPaymentBean.payment.toAccount}
> "payment" resolves to the following:
> @Entity
> public class Payment implements Serializable {
> // More stuff...
> @NotNull @AccountNumber private String toAccount;
> // More stuff...
> }
> When debugging in javax.faces.validator._BeanValidatorUELUtils, I noticed the
> following on line 47 "ValueReference valueReference =
> valueExpression.getValueReference(elCtx);":
> * With Glassfish EL, "valueReference.property" is null. This causes the
> BeanValidator to return at line 161, and to skip validation.
> "valueReference.base" points to the Payment object btw.
> * With JUEL 2.2.3, "valueReference.property" is "toAccount", which is correct
> AFAIK.
> I'm not sure whether this is a MyFaces or EL issue. I remember that when I
> wrote the BeanValidator, that the spec literally said what to do. See:
> http://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/validator/BeanValidator.html#validate(javax.faces.context.FacesContext,
> javax.faces.component.UIComponent, java.lang.Object)
> So I guess this is an EL implementation issue, but I filed it nevertheless,
> at least for archiving purposes...
> WDYT?
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-3049) Bean Validation doesn't work with Glassfish el-impl-2.2
[
https://issues.apache.org/jira/browse/MYFACES-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997347#comment-12997347
]
Jan-Kees van Andel commented on MYFACES-3049:
-
Not sure if we can do this. You added a null-check already to prevent BV to
validate for example Collections. So adding this fallback will probably break
this, right?
> Bean Validation doesn't work with Glassfish el-impl-2.2
> ---
>
> Key: MYFACES-3049
> URL: https://issues.apache.org/jira/browse/MYFACES-3049
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
>Affects Versions: 2.0.4
> Environment: Tomcat 2.0.29
>Reporter: Jan-Kees van Andel
>
> I have this expression in my Facelet: #{newPaymentBean.payment.toAccount}
> "payment" resolves to the following:
> @Entity
> public class Payment implements Serializable {
> // More stuff...
> @NotNull @AccountNumber private String toAccount;
> // More stuff...
> }
> When debugging in javax.faces.validator._BeanValidatorUELUtils, I noticed the
> following on line 47 "ValueReference valueReference =
> valueExpression.getValueReference(elCtx);":
> * With Glassfish EL, "valueReference.property" is null. This causes the
> BeanValidator to return at line 161, and to skip validation.
> "valueReference.base" points to the Payment object btw.
> * With JUEL 2.2.3, "valueReference.property" is "toAccount", which is correct
> AFAIK.
> I'm not sure whether this is a MyFaces or EL issue. I remember that when I
> wrote the BeanValidator, that the spec literally said what to do. See:
> http://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/validator/BeanValidator.html#validate(javax.faces.context.FacesContext,
> javax.faces.component.UIComponent, java.lang.Object)
> So I guess this is an EL implementation issue, but I filed it nevertheless,
> at least for archiving purposes...
> WDYT?
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MYFACES-3049) Bean Validation doesn't work with Glassfish el-impl-2.2
Bean Validation doesn't work with Glassfish el-impl-2.2
---
Key: MYFACES-3049
URL: https://issues.apache.org/jira/browse/MYFACES-3049
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.4
Environment: Tomcat 2.0.29
Reporter: Jan-Kees van Andel
I have this expression in my Facelet: #{newPaymentBean.payment.toAccount}
"payment" resolves to the following:
@Entity
public class Payment implements Serializable {
// More stuff...
@NotNull @AccountNumber private String toAccount;
// More stuff...
}
When debugging in javax.faces.validator._BeanValidatorUELUtils, I noticed the
following on line 47 "ValueReference valueReference =
valueExpression.getValueReference(elCtx);":
* With Glassfish EL, "valueReference.property" is null. This causes the
BeanValidator to return at line 161, and to skip validation.
"valueReference.base" points to the Payment object btw.
* With JUEL 2.2.3, "valueReference.property" is "toAccount", which is correct
AFAIK.
I'm not sure whether this is a MyFaces or EL issue. I remember that when I
wrote the BeanValidator, that the spec literally said what to do. See:
http://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/validator/BeanValidator.html#validate(javax.faces.context.FacesContext,
javax.faces.component.UIComponent, java.lang.Object)
So I guess this is an EL implementation issue, but I filed it nevertheless, at
least for archiving purposes...
WDYT?
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (EXTCDI-92) ConversationUtils.cacheWindowId() ignores session invalidation
[ https://issues.apache.org/jira/browse/EXTCDI-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12974363#action_12974363 ] Jan-Kees van Andel commented on EXTCDI-92: -- Just ran the test again, but now I get the following stack trace when I invalidate the session: javax.enterprise.context.ContextNotActiveException: WebBeans context with scope type annotation @SessionScoped does not exist within current thread org.apache.webbeans.container.BeanManagerImpl.getContext(BeanManagerImpl.java:309) org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.getContextualInstance(NormalScopedBeanInterceptorHandler.java:124) org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:95) org.javassist.tmp.java.lang.Object_$$_javassist_16.getCurrentWindowContext(Object_$$_javassist_16.java) org.apache.myfaces.extensions.cdi.jsf.impl.util.ConversationUtils.storeCurrentViewIdAsOldViewId(ConversationUtils.java:222) org.apache.myfaces.extensions.cdi.jsf.impl.util.ConversationUtils.storeCurrentViewIdAsOldViewId(ConversationUtils.java:215) org.apache.myfaces.extensions.cdi.jsf.impl.navigation.AccessScopeAwareNavigationHandler.handleNavigation(AccessScopeAwareNavigationHandler.java:49) org.apache.myfaces.extensions.cdi.jsf2.impl.navigation.CodiNavigationHandler.handleNavigation(CodiNavigationHandler.java:78) org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:125) org.apache.myfaces.extensions.cdi.jsf.impl.security.SecurityViolationAwareActionListener.processAction(SecurityViolationAwareActionListener.java:49) org.apache.myfaces.extensions.cdi.jsf.impl.config.view.ViewControllerActionListener.processAction(ViewControllerActionListener.java:60) org.apache.myfaces.extensions.cdi.jsf.impl.listener.action.CodiActionListener.processAction(CodiActionListener.java:52) javax.faces.component.UICommand.broadcast(UICommand.java:120) javax.faces.component.UIViewRoot._broadcastAll(UIViewRoot.java:969) javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:275) javax.faces.component.UIViewRoot._process(UIViewRoot.java:1281) javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:707) org.apache.myfaces.lifecycle.InvokeApplicationExecutor.execute(InvokeApplicationExecutor.java:34) org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:171) org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) org.apache.myfaces.extensions.cdi.jsf2.impl.listener.phase.CodiLifecycleWrapper.execute(CodiLifecycleWrapper.java:71) javax.faces.webapp.FacesServlet.service(FacesServlet.java:189) > ConversationUtils.cacheWindowId() ignores session invalidation > -- > > Key: EXTCDI-92 > URL: https://issues.apache.org/jira/browse/EXTCDI-92 > Project: MyFaces CODI > Issue Type: Bug > Components: JEE-JSF20-Module >Affects Versions: 0.9.0 > Environment: MyFaces Core 2.0.3 trunk, OWB 1.0.0, Tomcat 6.0.29 with > Glassfish EL libs >Reporter: Jan-Kees van Andel > Attachments: EXTCDI-92.patch > > > A while ago, I raised issue MYFACES-2979. I now wanted to fix and commit it, > but I don't get this exception anymore, because I added CODI to my > application a while ago. > Reason: After invalidating, CODI re-initializes the Session, so it's not null > anymore and the DebugPhaseListener stuff doesn't throw an exception anymore. > However, I don't think this behavior is desirable. After all, I've > invalidated the session in my application code, so I don't want any framework > to re-initialize it without questioning. > I can't come up with an example of anything that really breaks because of > this, but it's not very nice and efficient. > It happens in the following method: > org.apache.myfaces.extensions.cdi.jsf.impl.util.ConversationUtils#cacheWindowId() > on line 191. > Wdyt? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (EXTCDI-92) ConversationUtils.cacheWindowId() ignores session invalidation
ConversationUtils.cacheWindowId() ignores session invalidation -- Key: EXTCDI-92 URL: https://issues.apache.org/jira/browse/EXTCDI-92 Project: MyFaces CODI Issue Type: Bug Components: JEE-JSF20-Module Affects Versions: 0.9.0 Environment: MyFaces Core 2.0.3 trunk, OWB 1.0.0, Tomcat 6.0.29 with Glassfish EL libs Reporter: Jan-Kees van Andel A while ago, I raised issue MYFACES-2979. I now wanted to fix and commit it, but I don't get this exception anymore, because I added CODI to my application a while ago. Reason: After invalidating, CODI re-initializes the Session, so it's not null anymore and the DebugPhaseListener stuff doesn't throw an exception anymore. However, I don't think this behavior is desirable. After all, I've invalidated the session in my application code, so I don't want any framework to re-initialize it without questioning. I can't come up with an example of anything that really breaks because of this, but it's not very nice and efficient. It happens in the following method: org.apache.myfaces.extensions.cdi.jsf.impl.util.ConversationUtils#cacheWindowId() on line 191. Wdyt? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2979) Session invalidation in Development Stage causes error in OpenWebBeans
[
https://issues.apache.org/jira/browse/MYFACES-2979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12934293#action_12934293
]
Jan-Kees van Andel commented on MYFACES-2979:
-
IMHO, that would be an unwanted side effect of the PhaseListener.
I'm not sure what the spec says about this (I guess nothing), but recreating a
session within the same request that invalidated it, would be pretty bad
behavior if you ask me...
The annoying bit is, if we choose to add a check in the PhaseListener, there
might be other checks we need to add there.
I suggest to fix it in the PhaseListener, to keep it as much side-effect-free
as possible.
> Session invalidation in Development Stage causes error in OpenWebBeans
> --
>
> Key: MYFACES-2979
> URL: https://issues.apache.org/jira/browse/MYFACES-2979
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
>Affects Versions: 2.0.3-SNAPSHOT
> Environment: MyFaces 2.0.3-SNAPSHOT in Dev mode, OpenWebBeans 1.0.0,
> Tomcat 6.0.29 (with Glassfish EL 2.2)
>Reporter: Jan-Kees van Andel
>
> I have a logout method, shown below:
> public String logout() {
> final FacesContext fc = FacesContext.getCurrentInstance();
> final ExternalContext externalContext = fc.getExternalContext();
> try {
> externalContext.invalidateSession();
> externalContext.redirect("http://www.google.nl";);
> } catch (IOException e) {
> log.error("Error redirecting after logout", e);
> } finally {
> fc.responseComplete();
> }
> return null;
> }
> When I invoke this method, I get the following Exception from OpenWebBeans:
> javax.enterprise.context.ContextNotActiveException: WebBeans context with
> scope type annotation @SessionScoped does not exist within current thread
> at
> org.apache.webbeans.container.BeanManagerImpl.getContext(BeanManagerImpl.java:309)
> at
> org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.getContextualInstance(NormalScopedBeanInterceptorHandler.java:124)
> at
> org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:95)
> at
> org.apache.myfaces.examples.ebanking.web.bean.SessionBean_$$_javassist_2.getCustomer(SessionBean_$$_javassist_2.java)
> at sun.reflect.GeneratedMethodAccessor37.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at javax.el.BeanELResolver.getValue(BeanELResolver.java:302)
> at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:175)
> at
> org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:142)
> at org.apache.el.parser.AstValue.getValue(AstValue.java:123)
> at org.apache.el.parser.AstEmpty.getValue(AstEmpty.java:45)
> at org.apache.el.parser.AstNot.getValue(AstNot.java:42)
> at
> org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186)
> at
> org.apache.webbeans.el.WrappedValueExpression.getValue(WrappedValueExpression.java:68)
> at
> org.apache.myfaces.view.facelets.el.TagValueExpression.getValue(TagValueExpression.java:85)
> at
> javax.faces.component._DeltaStateHelper.eval(_DeltaStateHelper.java:260)
> at
> javax.faces.component.UIComponentBase.isRendered(UIComponentBase.java:1007)
> at javax.faces.component.UIComponent.isVisitable(UIComponent.java:289)
> at javax.faces.component.UIComponent.visitTree(UIComponent.java:752)
> at
> javax.faces.component.UIComponentBase.visitTree(UIComponentBase.java:991)
> at javax.faces.component.UIComponent.visitTree(UIComponent.java:778)
> at
> javax.faces.component.UIComponentBase.visitTree(UIComponentBase.java:991)
> at
> org.apache.myfaces.view.facelets.tag.ui.DebugPhaseListener._doTreeVisit(DebugPhaseListener.java:310)
> at
> org.apache.myfaces.view.facelets.tag.ui.DebugPhaseListener.afterPhase(DebugPhaseListener.java:286)
> at
> org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersAfter(PhaseListenerManager.java:111)
> at
> org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:185)
> at
> org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:189)
> This happens because the DebugPhaseListener starts visiting the tree and, in
> the process, needs to resolve a value expression, which points to an OWB
> session bean.
> It only happens when the DebugPhaseListener is installed. In produc
[jira] Created: (MYFACES-2979) Session invalidation in Development Stage causes error in OpenWebBeans
Session invalidation in Development Stage causes error in OpenWebBeans
--
Key: MYFACES-2979
URL: https://issues.apache.org/jira/browse/MYFACES-2979
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.3-SNAPSHOT
Environment: MyFaces 2.0.3-SNAPSHOT in Dev mode, OpenWebBeans 1.0.0,
Tomcat 6.0.29 (with Glassfish EL 2.2)
Reporter: Jan-Kees van Andel
I have a logout method, shown below:
public String logout() {
final FacesContext fc = FacesContext.getCurrentInstance();
final ExternalContext externalContext = fc.getExternalContext();
try {
externalContext.invalidateSession();
externalContext.redirect("http://www.google.nl";);
} catch (IOException e) {
log.error("Error redirecting after logout", e);
} finally {
fc.responseComplete();
}
return null;
}
When I invoke this method, I get the following Exception from OpenWebBeans:
javax.enterprise.context.ContextNotActiveException: WebBeans context with scope
type annotation @SessionScoped does not exist within current thread
at
org.apache.webbeans.container.BeanManagerImpl.getContext(BeanManagerImpl.java:309)
at
org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.getContextualInstance(NormalScopedBeanInterceptorHandler.java:124)
at
org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:95)
at
org.apache.myfaces.examples.ebanking.web.bean.SessionBean_$$_javassist_2.getCustomer(SessionBean_$$_javassist_2.java)
at sun.reflect.GeneratedMethodAccessor37.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at javax.el.BeanELResolver.getValue(BeanELResolver.java:302)
at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:175)
at
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:142)
at org.apache.el.parser.AstValue.getValue(AstValue.java:123)
at org.apache.el.parser.AstEmpty.getValue(AstEmpty.java:45)
at org.apache.el.parser.AstNot.getValue(AstNot.java:42)
at
org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186)
at
org.apache.webbeans.el.WrappedValueExpression.getValue(WrappedValueExpression.java:68)
at
org.apache.myfaces.view.facelets.el.TagValueExpression.getValue(TagValueExpression.java:85)
at
javax.faces.component._DeltaStateHelper.eval(_DeltaStateHelper.java:260)
at
javax.faces.component.UIComponentBase.isRendered(UIComponentBase.java:1007)
at javax.faces.component.UIComponent.isVisitable(UIComponent.java:289)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:752)
at
javax.faces.component.UIComponentBase.visitTree(UIComponentBase.java:991)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:778)
at
javax.faces.component.UIComponentBase.visitTree(UIComponentBase.java:991)
at
org.apache.myfaces.view.facelets.tag.ui.DebugPhaseListener._doTreeVisit(DebugPhaseListener.java:310)
at
org.apache.myfaces.view.facelets.tag.ui.DebugPhaseListener.afterPhase(DebugPhaseListener.java:286)
at
org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersAfter(PhaseListenerManager.java:111)
at
org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:185)
at
org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:189)
This happens because the DebugPhaseListener starts visiting the tree and, in
the process, needs to resolve a value expression, which points to an OWB
session bean.
It only happens when the DebugPhaseListener is installed. In production mode
everything is fine.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2965) MyFaces 2.0.2 AJAX crashes Safari on iPad
[ https://issues.apache.org/jira/browse/MYFACES-2965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12929360#action_12929360 ] Jan-Kees van Andel commented on MYFACES-2965: - Werner has been debugging his AJAX code. This is the result: ah main difference between android and apple both of them run their own javascript engine they are not the same it is the exists check for send as binary it runs now gotta send that bug to apple all i do is 'undefined' == typeof xhr.sendAsBinary || null == xhr.sendAsBinary apparently that is enough to crash the xhr object of safari as soon as send is called this is a stupid bug on apples side either way I will add mobile safari detection and remove that code for mobile safari mobile safari should be sendAsBinary enabled anyway > MyFaces 2.0.2 AJAX crashes Safari on iPad > - > > Key: MYFACES-2965 > URL: https://issues.apache.org/jira/browse/MYFACES-2965 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314 >Affects Versions: 2.0.2 > Environment: iPad Safari >Reporter: Jan-Kees van Andel >Assignee: Werner Punz > > If you go to http://ipad.parleys.com/parleys-frontend-ipad-1.0/ on your iPad, > and then click on the button "Latest", "Top Rated" or some other button that > invokes an AJAX request, the browser crashes and goes back to the desktop. > A simple debugging session pointed me to the jsf.ajax.request() invocation, > but that's still pretty broad. Reverting to 2.0.1 solved the issue. > The code can be viewed online at: > http://code.google.com/p/parleys-html5/source/browse/#svn/trunk/web-ipad/src/main/webapp > Talked offline with Werner about the issue and we think it's somewhere in the > 2.0.2 optimizations. > Werner's first guess: "If you want to check yourself you can set an alert in > replacenode in Dom.js and see if the code is reached > And see if it finishes. > I am 100 percent sure the problem is there. > But it is just sixth sense on my part. > So just a guessing." -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2965) MyFaces 2.0.2 AJAX crashes Safari on iPad
MyFaces 2.0.2 AJAX crashes Safari on iPad - Key: MYFACES-2965 URL: https://issues.apache.org/jira/browse/MYFACES-2965 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.2 Environment: iPad Safari Reporter: Jan-Kees van Andel Assignee: Werner Punz If you go to http://ipad.parleys.com/parleys-frontend-ipad-1.0/ on your iPad, and then click on the button "Latest", "Top Rated" or some other button that invokes an AJAX request, the browser crashes and goes back to the desktop. A simple debugging session pointed me to the jsf.ajax.request() invocation, but that's still pretty broad. Reverting to 2.0.1 solved the issue. The code can be viewed online at: http://code.google.com/p/parleys-html5/source/browse/#svn/trunk/web-ipad/src/main/webapp Talked offline with Werner about the issue and we think it's somewhere in the 2.0.2 optimizations. Werner's first guess: "If you want to check yourself you can set an alert in replacenode in Dom.js and see if the code is reached And see if it finishes. I am 100 percent sure the problem is there. But it is just sixth sense on my part. So just a guessing." -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2932) More error logging when Bean Validation throws an exception at startup
More error logging when Bean Validation throws an exception at startup -- Key: MYFACES-2932 URL: https://issues.apache.org/jira/browse/MYFACES-2932 Project: MyFaces Core Issue Type: Improvement Components: JSR-314 Affects Versions: 2.0.2 Environment: Any Reporter: Jan-Kees van Andel When the Bean Validation implementation fails to startup, for example because it is misconfigured by the developer, or because of some dependency issue (missing slf4j jar or something), the Bean Validator automatically turns itself off. The error is logged as "fine", because in many cases the developer doesn't care about this behavior. For example, if bean validation api is provided, but impl is not. In these cases, logging an error is not desirable. But maybe this should be increased to "info", to ease debugging in the cases where the developer is interested in why bean validation fails to startup. I guess we change the logging to "info", especially because the block of code is guarded by a Class.forName() check, which takes care of the obvious case that Bean Validation is unavailable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2889) [PERF] Remove String.intern() calls in FlashELResolver and ImplicitObjectResolver
[ https://issues.apache.org/jira/browse/MYFACES-2889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12901152#action_12901152 ] Jan-Kees van Andel commented on MYFACES-2889: - True, but in these two cases, the (interned) Strings are only used for Map lookups. And AFAIK, interning has no effect on the performance of the hashcode method... > [PERF] Remove String.intern() calls in FlashELResolver and > ImplicitObjectResolver > - > > Key: MYFACES-2889 > URL: https://issues.apache.org/jira/browse/MYFACES-2889 > Project: MyFaces Core > Issue Type: Improvement > Components: JSR-314 >Affects Versions: 2.0.2-SNAPSHOT > Environment: JBoss AS 6 M4, Parleys.com JSF2 app >Reporter: Jan-Kees van Andel > > I've been doing some profiling and I see pretty much activity in > FlashELResolver.castAndIntern() and ImplicitObjectResolver.castAndIntern(). > When I replace the "return s.intern()" lines by "return s", both methods > have (of course) much better performance. > But I'm pretty sure someone put them there with a reason, like memory > footprint. > However, I don't see any difference in memory footprint. > Any ideas? Do we want to keep the intern() calls? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2889) [PERF] Remove String.intern() calls in FlashELResolver and ImplicitObjectResolver
[PERF] Remove String.intern() calls in FlashELResolver and ImplicitObjectResolver - Key: MYFACES-2889 URL: https://issues.apache.org/jira/browse/MYFACES-2889 Project: MyFaces Core Issue Type: Improvement Components: JSR-314 Affects Versions: 2.0.2-SNAPSHOT Environment: JBoss AS 6 M4, Parleys.com JSF2 app Reporter: Jan-Kees van Andel I've been doing some profiling and I see pretty much activity in FlashELResolver.castAndIntern() and ImplicitObjectResolver.castAndIntern(). When I replace the "return s.intern()" lines by "return s", both methods have (of course) much better performance. But I'm pretty sure someone put them there with a reason, like memory footprint. However, I don't see any difference in memory footprint. Any ideas? Do we want to keep the intern() calls? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2871) Remove redundant SVN keywords from class JavaDocs
Remove redundant SVN keywords from class JavaDocs - Key: MYFACES-2871 URL: https://issues.apache.org/jira/browse/MYFACES-2871 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.1 Reporter: Jan-Kees van Andel Assignee: Jan-Kees van Andel Priority: Minor Almost all class file JavaDocs now contain SVN keywords. These are redundant and after a simple poll on the mailinglist, the conclusion is to remove them from the files. Reference back to the original thread: http://markmail.org/thread/tfwvqms4xko3uq2k Still need to decide how to get rid of this stuff. I think a massive find-replace works fine, but there is always a slight risk of big merge conflicts. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2861) Remove commons-discovery dependency
[ https://issues.apache.org/jira/browse/MYFACES-2861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12896781#action_12896781 ] Jan-Kees van Andel commented on MYFACES-2861: - Hi Martin, I don't think that will work, since logging is something you can't exclude easily. Most classes initialize a logger during (class/object) initialization, so you'll end up with a NoClassDef at runtime. I think we're gonna need the transitive dependency... /JK > Remove commons-discovery dependency > --- > > Key: MYFACES-2861 > URL: https://issues.apache.org/jira/browse/MYFACES-2861 > Project: MyFaces Core > Issue Type: Improvement > Components: JSR-314 >Affects Versions: 2.0.1 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Fix For: 2.0.2-SNAPSHOT > > > Commons-discovery has a dependency to commons-logging. That cause a > transitive dependency to myfaces-impl. To prevent this dependency, we need to > move that code into our codebase and refactor it so it uses jul instead. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2861) Remove commons-discovery dependency
[ https://issues.apache.org/jira/browse/MYFACES-2861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12896779#action_12896779 ] Jan-Kees van Andel commented on MYFACES-2861: - Hey Leo, >From my understanding, the added value of commons-discovery and >commons-beanutils is pretty limited. It might be an idea to think about >selectively copying some files from both projects into MyFaces? AFAIK, Discovery is only used to find the LifecycleFactory. We might be able to replace this with the Service Provider mechanism. I'm not sure about all usages of Beanutils though... /JK > Remove commons-discovery dependency > --- > > Key: MYFACES-2861 > URL: https://issues.apache.org/jira/browse/MYFACES-2861 > Project: MyFaces Core > Issue Type: Improvement > Components: JSR-314 >Affects Versions: 2.0.1 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Fix For: 2.0.2-SNAPSHOT > > > Commons-discovery has a dependency to commons-logging. That cause a > transitive dependency to myfaces-impl. To prevent this dependency, we need to > move that code into our codebase and refactor it so it uses jul instead. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2858) pointless oamsubmit inline rendering
[ https://issues.apache.org/jira/browse/MYFACES-2858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12895258#action_12895258 ] Jan-Kees van Andel commented on MYFACES-2858: - Never mind. I'll report my thingy in a separate issue. It's not related to your externalization. Sorry for the unclear comment. :-) > pointless oamsubmit inline rendering > > > Key: MYFACES-2858 > URL: https://issues.apache.org/jira/browse/MYFACES-2858 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.0.2-SNAPSHOT >Reporter: Werner Punz > > We have had several functions rendered inline for ages, namely > appendHiddenInput oamSubmit, the autoscroll stuff etc... > I personally think the rendering of those functions as inline scripts is > pointless, blows up the browsers tremendously and > prevents that the affected scripts can be browser cached. > A quick look at the code revealed that there is basically nothing which would > prevent to externalize the scripts. My main problem is where to we handle the > auto append code. > My personal guess is we probably simply should add it as a resource > definitions to the commandLink, Button etc.. renderers, any ideas regarding > this? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2858) pointless oamsubmit inline rendering
[ https://issues.apache.org/jira/browse/MYFACES-2858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12895224#action_12895224 ] Jan-Kees van Andel commented on MYFACES-2858: - No opinion regarding externalizing the scripts. I think it's a good idea. What I did notice a while ago, was that those scripts are very annoying when doing AJAX. I didn't look at it in detail, but it looked like they messed up the event handling. > pointless oamsubmit inline rendering > > > Key: MYFACES-2858 > URL: https://issues.apache.org/jira/browse/MYFACES-2858 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.0.2-SNAPSHOT >Reporter: Werner Punz > > We have had several functions rendered inline for ages, namely > appendHiddenInput oamSubmit, the autoscroll stuff etc... > I personally think the rendering of those functions as inline scripts is > pointless, blows up the browsers tremendously and > prevents that the affected scripts can be browser cached. > A quick look at the code revealed that there is basically nothing which would > prevent to externalize the scripts. My main problem is where to we handle the > auto append code. > My personal guess is we probably simply should add it as a resource > definitions to the commandLink, Button etc.. renderers, any ideas regarding > this? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-1529) ConcurrentModificationException when using t:selectManyPickList and h:selectOneMenu
[
https://issues.apache.org/jira/browse/TOMAHAWK-1529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12891983#action_12891983
]
Jan-Kees van Andel commented on TOMAHAWK-1529:
--
I'm pretty sure it has nothing to do with MyFaces...
I've seen issues like this one very often in the field. Most of the time the
cause was a direct remove action on the collection (not remove() on the
iterator) while iterating it.
You're passing in a Transformer into CollectionUtils.collect(), somewhere in
"com.utmb.web.beans.searchController.getsrch1revvals". I can't see the line
number in the stack trace, but it should be there.
I'm very curious what this Transformer looks like.
> ConcurrentModificationException when using t:selectManyPickList and
> h:selectOneMenu
> ---
>
> Key: TOMAHAWK-1529
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-1529
> Project: MyFaces Tomahawk
> Issue Type: Bug
>Affects Versions: 1.1.10-SNAPSHOT
> Environment: Solaris 5.8, Java HotSpot(TM) Server VM (build
> 1.5.0_05-b05, mixed mode)
> Tomcat 6.0.26 running with Security Manager
> MyFaces 1.1.7
>Reporter: suresh t
>
> I have a backend bean supporting jsf page. It has many components similar to
> one shown below. where srch1vals is a ArrayList of SelectItem s
>immediate="true" value="#{searchController.vSrch1}"
> styleClass="selectOneMenu">
>value="#{searchController.srch1vals}" />
>
> There is one other components selectManyPickList that has value
> set to srch1revvals. srch1revvals clones srch1vals in the Get accesor using
> CollectionUtils.collect() method.
>size="5" value="#{searchController.selectedPicks}"
> valueChangeListener="#{searchController.selectionChanged}"
> rendered="#{searchController.searchvalsResults}">
>value="#{searchController.srch1revvals}" />
>
> I am getting occasional ConcurrentModificationException as follows.
> Jul 6, 2010 4:35:38 PM org.apache.catalina.core.ApplicationDispatcher invoke
> SEVERE: Servlet.service() for servlet jsp threw exception
> java.util.ConcurrentModificationException
> at
> java.util.AbstractList$Itr.checkForComodification(AbstractList.java:4
> 49)
> at java.util.AbstractList$Itr.next(AbstractList.java:420)
> at
> org.apache.commons.collections.CollectionUtils.collect(CollectionUtil
> s.java:631)
> at
> org.apache.commons.collections.CollectionUtils.collect(CollectionUtil
> s.java:610)
> at
> org.apache.commons.collections.CollectionUtils.collect(CollectionUtil
> s.java:575)
> at com.utmb.web.beans.searchController.getsrch1revvals(Unknown Source)
> at sun.reflect.GeneratedMethodAccessor780.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> org.apache.myfaces.el.PropertyResolverImpl.getProperty(PropertyResolv
> erImpl.java:459)
> at
> org.apache.myfaces.el.PropertyResolverImpl.getValue(PropertyResolverI
> mpl.java:85)
> at
> org.apache.myfaces.el.ELParserHelper$MyPropertySuffix.evaluate(ELPars
> erHelper.java:539)
> at org.apache.commons.el.ComplexValue.evaluate(ComplexValue.java:145)
> at
> org.apache.myfaces.el.ValueBindingImpl.getValue(ValueBindingImpl.java
> :386)
> at
> javax.faces.component.UISelectItems.getValue(UISelectItems.java:108)
> at
> org.apache.myfaces.shared_tomahawk.util.SelectItemsIterator.hasNext(S
> electItemsIterator.java:127)
> at
> org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.internalGe
> tSelectItemList(RendererUtils.java:462)
> at
> org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.getSelectI
> temList(RendererUtils.java:448)
> at
> org.apache.myfaces.custom.picklist.HtmlPicklistRenderer.encodeEnd(Htm
> lPicklistRenderer.java:161)
> at
> javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:
> 775)
> at
> org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.renderChil
> d(RendererUtils.java:431)
> at
> org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlGridRendererBas
> e.renderChildren(HtmlGridRendererBase.java:229)
> at
> org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlGridRendererBas
> e.encodeEnd(HtmlGridRendererBase.java:101)
> at
> javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:
> 775)
> at
> org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.renderChil
> d
[jira] Issue Comment Edited: (TOMAHAWK-1529) ConcurrentModificationException when using t:selectManyPickList and h:selectOneMenu
[
https://issues.apache.org/jira/browse/TOMAHAWK-1529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12891983#action_12891983
]
Jan-Kees van Andel edited comment on TOMAHAWK-1529 at 7/24/10 10:12 AM:
I'm pretty sure it has nothing to do with MyFaces...
I've seen issues like this one very often in the field. Most of the time the
cause was a direct remove action on the collection (not remove() on the
iterator) while iterating it.
You're passing in a Transformer into CollectionUtils.collect(), somewhere in
"com.utmb.web.beans.searchController.getsrch1revvals". I can't see the line
number in the stack trace, but it should be there.
I'm very curious what this Transformer looks like. And of course a bit of
context, like the "getsrch1revvals" method...
was (Author: jankeesvanandel):
I'm pretty sure it has nothing to do with MyFaces...
I've seen issues like this one very often in the field. Most of the time the
cause was a direct remove action on the collection (not remove() on the
iterator) while iterating it.
You're passing in a Transformer into CollectionUtils.collect(), somewhere in
"com.utmb.web.beans.searchController.getsrch1revvals". I can't see the line
number in the stack trace, but it should be there.
I'm very curious what this Transformer looks like.
> ConcurrentModificationException when using t:selectManyPickList and
> h:selectOneMenu
> ---
>
> Key: TOMAHAWK-1529
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-1529
> Project: MyFaces Tomahawk
> Issue Type: Bug
>Affects Versions: 1.1.10-SNAPSHOT
> Environment: Solaris 5.8, Java HotSpot(TM) Server VM (build
> 1.5.0_05-b05, mixed mode)
> Tomcat 6.0.26 running with Security Manager
> MyFaces 1.1.7
>Reporter: suresh t
>
> I have a backend bean supporting jsf page. It has many components similar to
> one shown below. where srch1vals is a ArrayList of SelectItem s
>immediate="true" value="#{searchController.vSrch1}"
> styleClass="selectOneMenu">
>value="#{searchController.srch1vals}" />
>
> There is one other components selectManyPickList that has value
> set to srch1revvals. srch1revvals clones srch1vals in the Get accesor using
> CollectionUtils.collect() method.
>size="5" value="#{searchController.selectedPicks}"
> valueChangeListener="#{searchController.selectionChanged}"
> rendered="#{searchController.searchvalsResults}">
>value="#{searchController.srch1revvals}" />
>
> I am getting occasional ConcurrentModificationException as follows.
> Jul 6, 2010 4:35:38 PM org.apache.catalina.core.ApplicationDispatcher invoke
> SEVERE: Servlet.service() for servlet jsp threw exception
> java.util.ConcurrentModificationException
> at
> java.util.AbstractList$Itr.checkForComodification(AbstractList.java:4
> 49)
> at java.util.AbstractList$Itr.next(AbstractList.java:420)
> at
> org.apache.commons.collections.CollectionUtils.collect(CollectionUtil
> s.java:631)
> at
> org.apache.commons.collections.CollectionUtils.collect(CollectionUtil
> s.java:610)
> at
> org.apache.commons.collections.CollectionUtils.collect(CollectionUtil
> s.java:575)
> at com.utmb.web.beans.searchController.getsrch1revvals(Unknown Source)
> at sun.reflect.GeneratedMethodAccessor780.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> org.apache.myfaces.el.PropertyResolverImpl.getProperty(PropertyResolv
> erImpl.java:459)
> at
> org.apache.myfaces.el.PropertyResolverImpl.getValue(PropertyResolverI
> mpl.java:85)
> at
> org.apache.myfaces.el.ELParserHelper$MyPropertySuffix.evaluate(ELPars
> erHelper.java:539)
> at org.apache.commons.el.ComplexValue.evaluate(ComplexValue.java:145)
> at
> org.apache.myfaces.el.ValueBindingImpl.getValue(ValueBindingImpl.java
> :386)
> at
> javax.faces.component.UISelectItems.getValue(UISelectItems.java:108)
> at
> org.apache.myfaces.shared_tomahawk.util.SelectItemsIterator.hasNext(S
> electItemsIterator.java:127)
> at
> org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.internalGe
> tSelectItemList(RendererUtils.java:462)
> at
> org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.getSelectI
> temList(RendererUtils.java:448)
> at
> org.apache.myfaces.custom.picklist.HtmlPicklistRenderer.encodeEnd(Htm
> lPicklistRenderer.java:161)
[jira] Commented: (MYFACES-2827) CCE if component values are not of type String
[ https://issues.apache.org/jira/browse/MYFACES-2827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12889870#action_12889870 ] Jan-Kees van Andel commented on MYFACES-2827: - I see I made a mistake. I guess that's what you get when looking at code through a web interface instead of an IDE... ;-) valueProperty must be a String because we need to pass it to the validateValue() method as a String. This is the JSR303 API, so we can't change this. For reference: http://download.oracle.com/docs/cd/E17410_01/javaee/6/api/javax/validation/Validator.html#validateValue(java.lang.Class, java.lang.String, java.lang.Object, java.lang.Class...) With regards ot Jakob's comment: "check if reference.getProperty() is a String before doing the whole initialisation" We can do this, but what do we do in this case? Just skip the call to validateValue()? I must say, it sounds reasonable on first thought, because we can't validate it anyway. Also, this situation should never occur in the case of a Bean, since the property name in a Bean is always a String. If it's not a String ==> it's not a Bean ==> we don't have to "Bean-validate" it... So +1, but I'm probably not seeing all consequences right now. I guess we should just fix it this way and see how it turns out in practice. Mark can do the regression testing. ;-) > CCE if component values are not of type String > -- > > Key: MYFACES-2827 > URL: https://issues.apache.org/jira/browse/MYFACES-2827 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.0.1 >Reporter: Mark Struberg >Assignee: Jakob Korherr > Attachments: MYFACES-2827.patch > > > Somehow I did get a Long into my component. This leads to the following > Exception: > java.lang.ClassCastException: java.lang.Long cannot be cast to > java.lang.String > at javax.faces.validator.BeanValidator.validate(BeanValidator.java:145) > at > javax.faces.component._ComponentUtils.callValidators(_ComponentUtils.java:173) > at javax.faces.component.UIInput.validateValue(UIInput.java:425) > at javax.faces.component.UIInput.validate(UIInput.java:537) > at javax.faces.component.UIInput.processValidators(UIInput.java:240) > at javax.faces.component.UIData.process(UIData.java:1043) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2827) CCE if component values are not of type String
[
https://issues.apache.org/jira/browse/MYFACES-2827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12889863#action_12889863
]
Jan-Kees van Andel commented on MYFACES-2827:
-
So, I guess the fix for this issue is to add some extra code to BeanValidator
to check if the targeted object is a constrained object.
The current code is:
final Class valueBaseClass = base.getClass();
final String valueProperty = (String) reference.getProperty();
if (valueBaseClass == null || valueProperty == null)
{
return;
}
// Initialize Bean Validation.
final ValidatorFactory validatorFactory =
createValidatorFactory(context);
final javax.validation.Validator validator =
createValidator(validatorFactory);
final BeanDescriptor beanDescriptor =
validator.getConstraintsForClass(valueBaseClass);
if (!beanDescriptor.isBeanConstrained())
{
return;
}
But we might be able to rewrite it to:
final Class valueBaseClass = base.getClass();
if (valueBaseClass == null)
{
return;
}
// Initialize Bean Validation.
final ValidatorFactory validatorFactory =
createValidatorFactory(context);
final javax.validation.Validator validator =
createValidator(validatorFactory);
final BeanDescriptor beanDescriptor =
validator.getConstraintsForClass(valueBaseClass);
if (!beanDescriptor.isBeanConstrained())
{
return;
}
final String valueProperty = (String) reference.getProperty();
According to the spec, we should be able to remove the null-check on
valueProperty.
> CCE if component values are not of type String
> --
>
> Key: MYFACES-2827
> URL: https://issues.apache.org/jira/browse/MYFACES-2827
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.0.1
>Reporter: Mark Struberg
>Assignee: Jakob Korherr
>
> Somehow I did get a Long into my component. This leads to the following
> Exception:
> java.lang.ClassCastException: java.lang.Long cannot be cast to
> java.lang.String
> at javax.faces.validator.BeanValidator.validate(BeanValidator.java:145)
> at
> javax.faces.component._ComponentUtils.callValidators(_ComponentUtils.java:173)
> at javax.faces.component.UIInput.validateValue(UIInput.java:425)
> at javax.faces.component.UIInput.validate(UIInput.java:537)
> at javax.faces.component.UIInput.processValidators(UIInput.java:240)
> at javax.faces.component.UIData.process(UIData.java:1043)
--
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-2827) CCE if component values are not of type String
[
https://issues.apache.org/jira/browse/MYFACES-2827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12889863#action_12889863
]
Jan-Kees van Andel edited comment on MYFACES-2827 at 7/19/10 9:52 AM:
--
So, I guess the fix for this issue is to remove some code from BeanValidator.
The current code is:
final Class valueBaseClass = base.getClass();
final String valueProperty = (String) reference.getProperty();
if (valueBaseClass == null || valueProperty == null)
{
return;
}
// Initialize Bean Validation.
final ValidatorFactory validatorFactory =
createValidatorFactory(context);
final javax.validation.Validator validator =
createValidator(validatorFactory);
final BeanDescriptor beanDescriptor =
validator.getConstraintsForClass(valueBaseClass);
if (!beanDescriptor.isBeanConstrained())
{
return;
}
But we can rewrite it to:
final Class valueBaseClass = base.getClass();
if (valueBaseClass == null)
{
return;
}
// Initialize Bean Validation.
final ValidatorFactory validatorFactory =
createValidatorFactory(context);
final javax.validation.Validator validator =
createValidator(validatorFactory);
final BeanDescriptor beanDescriptor =
validator.getConstraintsForClass(valueBaseClass);
if (!beanDescriptor.isBeanConstrained())
{
return;
}
final String valueProperty = (String) reference.getProperty();
According to the spec, we should be able to remove the null-check on
valueProperty.
was (Author: jankeesvanandel):
So, I guess the fix for this issue is to add some extra code to
BeanValidator to check if the targeted object is a constrained object.
The current code is:
final Class valueBaseClass = base.getClass();
final String valueProperty = (String) reference.getProperty();
if (valueBaseClass == null || valueProperty == null)
{
return;
}
// Initialize Bean Validation.
final ValidatorFactory validatorFactory =
createValidatorFactory(context);
final javax.validation.Validator validator =
createValidator(validatorFactory);
final BeanDescriptor beanDescriptor =
validator.getConstraintsForClass(valueBaseClass);
if (!beanDescriptor.isBeanConstrained())
{
return;
}
But we might be able to rewrite it to:
final Class valueBaseClass = base.getClass();
if (valueBaseClass == null)
{
return;
}
// Initialize Bean Validation.
final ValidatorFactory validatorFactory =
createValidatorFactory(context);
final javax.validation.Validator validator =
createValidator(validatorFactory);
final BeanDescriptor beanDescriptor =
validator.getConstraintsForClass(valueBaseClass);
if (!beanDescriptor.isBeanConstrained())
{
return;
}
final String valueProperty = (String) reference.getProperty();
According to the spec, we should be able to remove the null-check on
valueProperty.
> CCE if component values are not of type String
> --
>
> Key: MYFACES-2827
> URL: https://issues.apache.org/jira/browse/MYFACES-2827
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.0.1
>Reporter: Mark Struberg
>Assignee: Jakob Korherr
>
> Somehow I did get a Long into my component. This leads to the following
> Exception:
> java.lang.ClassCastException: java.lang.Long cannot be cast to
> java.lang.String
> at javax.faces.validator.BeanValidator.validate(BeanValidator.java:145)
> at
> javax.faces.component._ComponentUtils.callValidators(_ComponentUtils.java:173)
> at javax.faces.component.UIInput.validateValue(UIInput.java:425)
> at javax.faces.component.UIInput.validate(UIInput.java:537)
> at javax.faces.component.UIInput.processValidators(UIInput.java:240)
> at javax.faces.component.UIData.process(UIData.java:1043)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2827) CCE if component values are not of type String
[ https://issues.apache.org/jira/browse/MYFACES-2827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12889834#action_12889834 ] Jan-Kees van Andel commented on MYFACES-2827: - I can't imagine the String assumption being wrong, so can you please add some info regarding how you got that Long into your component? Like: - Are you in a JEE6 container (with the new Unified EL)? - Are you using bean validation inside a composite component? - Do you have some code to show what you're doing? > CCE if component values are not of type String > -- > > Key: MYFACES-2827 > URL: https://issues.apache.org/jira/browse/MYFACES-2827 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.0.1 >Reporter: Mark Struberg > > Somehow I did get a Long into my component. This leads to the following > Exception: > java.lang.ClassCastException: java.lang.Long cannot be cast to > java.lang.String > at javax.faces.validator.BeanValidator.validate(BeanValidator.java:145) > at > javax.faces.component._ComponentUtils.callValidators(_ComponentUtils.java:173) > at javax.faces.component.UIInput.validateValue(UIInput.java:425) > at javax.faces.component.UIInput.validate(UIInput.java:537) > at javax.faces.component.UIInput.processValidators(UIInput.java:240) > at javax.faces.component.UIData.process(UIData.java:1043) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2826) NPE when using the new UEL inside a composite component in Glassfish 3.0.1
NPE when using the new UEL inside a composite component in Glassfish 3.0.1 -- Key: MYFACES-2826 URL: https://issues.apache.org/jira/browse/MYFACES-2826 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.1 Environment: glassfish3.0.1 Reporter: Jan-Kees van Andel When I write a composite component like this one: http://www.w3.org/1999/xhtml"; xmlns:f="http://java.sun.com/jsf/core"; xmlns:h="http://java.sun.com/jsf/html"; xmlns:p="http://www.parleys.com/jsf/taglib"; xmlns:composite="http://java.sun.com/jsf/composite";> And I use it in my page like this: I get the following NPE: [#|2010-07-18T15:27:08.227+0200|SEVERE|glassfish3.0.1|org.apache.myfaces.renderkit.ErrorPageWriter|_ThreadID=27;_ThreadName=Thread-1;|An exception occurred javax.faces.FacesException: java.lang.NullPointerException at org.apache.myfaces.shared_impl.context.ExceptionHandlerImpl.wrap(ExceptionHandlerImpl.java:241) at org.apache.myfaces.shared_impl.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:156) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:191) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:189) at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1523) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:188) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:641) at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97) at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:85) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:185) at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:325) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:226) at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:165) at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:791) at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:693) at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:954) at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:170) at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88) at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76) at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53) at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57) at com.sun.grizzly.ContextTask.run(ContextTask.java:69) at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:330) at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:309) at java.lang.Thread.run(Thread.java:619) Caused by: java.lang.NullPointerException at org.apache.myfaces.view.facelets.el.ValueExpressionMethodExpression.getExpressionString(ValueExpressionMethodExpression.java:70) at org.apache.myfaces.view.facelets.el.TagMethodExpression.getExpressionString(TagMethodExpression.java:101) at javax.faces.component._MethodExpressionToMethodBinding.getExpressionString(_MethodExpressionToMethodBinding.java:60) at org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:97) at javax.faces.component.UICommand.broadcast(UICommand.java:120) at javax.faces.component.UIViewRoot._broadcastAll(UIViewRoot.java:889) at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:238) at javax.faces.component.UIViewRoot._process(UIViewRoot.java:1201) at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:627) at org.apache.myfaces.lifecycle.InvokeApplicationExecutor.execute(InvokeApplicationExecutor.java:34) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:171) ... 26 more I am using Glassfish 3.0.1, with the Sun UEL implementation. It works when I disable MyFaces and use Mojarra. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to th
[jira] Commented: (MYFACES-2798) javax.faces.VALIDATE_EMPTY_FIELDS default should be 'true'
[ https://issues.apache.org/jira/browse/MYFACES-2798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12886320#action_12886320 ] Jan-Kees van Andel commented on MYFACES-2798: - The corresponding section from the JSF spec (chapter 11.1.3 Application Configuration Parameters): "... If the param is not set, the system must behave as if the param was set with the value "auto". ..." > javax.faces.VALIDATE_EMPTY_FIELDS default should be 'true' > -- > > Key: MYFACES-2798 > URL: https://issues.apache.org/jira/browse/MYFACES-2798 > Project: MyFaces Core > Issue Type: Improvement > Components: General >Affects Versions: 2.0.2-SNAPSHOT > Environment: Win XP, JDK 1.6.0.20, Maven 2.2.1, MyFaces trunk >Reporter: Oliver Bayer > > First I thought the validation tags like e.g. or > aren't working. But during debugging I found out that > the respective validation classes are called if at least one char is inserted. > At the myfaces homepage > (http://myfaces.apache.org/core20/myfaces-impl/webconfig.html) I've found > that the default is "auto". > I think it would be better to set the default to "true" because one would > expect to get an exception if he leaves a required field blank which isn't > the case if it's set to "auto". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2780) MyFaces performance improvements for production
[ https://issues.apache.org/jira/browse/MYFACES-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12885873#action_12885873 ] Jan-Kees van Andel commented on MYFACES-2780: - Lazy loading in itself is not a bad idea. Loading objects you're not using anyway is a waste of space and CPU, also at runtime, because the framework must look at more objects when, for example, doing a Converter lookup. I'm just curious about how you're planning to implement this feature, because lazy loading requires some kind of coordination, which might become a bottleneck... > MyFaces performance improvements for production > > > Key: MYFACES-2780 > URL: https://issues.apache.org/jira/browse/MYFACES-2780 > Project: MyFaces Core > Issue Type: Improvement > Components: General >Affects Versions: 2.0.0 >Reporter: Michael Concini >Assignee: Michael Concini >Priority: Minor > Fix For: 2.0.1 > > > Several fixes to enhance startup memory footprint and runtime performance > taking advantage of ProjectStage. > -lazy loading of validators, converters, behaviors,components - can have a > substantial impact on startup footprint in applications with multiple or very > large widget libraries. > Turn off some updating of resources for ProjectStage=Production by default > (can always override using javax.faces.FACELETS_REFRESH_PERIOD) > -change default facelets refresh interval to -1 when projectStage is > production. This by itself gains a 60% improvement in throughput. > -disable reloading of web.xml and faces-config after the first load. > -store a map to cache Class to listenerFor and resourceDependency annotations > when in production. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2784) NPE when I forget to add an interface to a composite component
NPE when I forget to add an interface to a composite component -- Key: MYFACES-2784 URL: https://issues.apache.org/jira/browse/MYFACES-2784 Project: MyFaces Core Issue Type: Bug Reporter: Jan-Kees van Andel When I write a composite component like the following: Spaces I get a NPE on line 1101 in ApplicationImpl, because there is no component metadata. Of course I made a mistake here, but a NPE isn't very helpful. :) There is a "SEVERE: Cannot found composite bean descriptor UIComponent.BEANINFO_KEY" in the logs, but it's swallowed by a huge stack trace. I suggest to throw a descriptive exception instead of logging the message. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2737) Cache FacesContext on UIComponentBase instances
[
https://issues.apache.org/jira/browse/MYFACES-2737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12872100#action_12872100
]
Jan-Kees van Andel commented on MYFACES-2737:
-
I agree with Martin. It looks good.
Normally I'm quite keen on concurrency bugs (like putting non-threadsafe
classes in the session), but this approach where you manually keep the
FacesContext instance request scoped, looks safe.
How many FacesContext.getCurrentInstance calls do you expect to save by this
approach?
> Cache FacesContext on UIComponentBase instances
> ---
>
> Key: MYFACES-2737
> URL: https://issues.apache.org/jira/browse/MYFACES-2737
> Project: MyFaces Core
> Issue Type: Improvement
> Components: JSR-314
>Affects Versions: 2.0.0
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
> Attachments: MYFACES-2737-1.patch
>
>
> Right now, the implementation of UIComponentBase.getFacesContext() is this:
> @Override
> protected FacesContext getFacesContext()
> {
> return FacesContext.getCurrentInstance();
> }
> I think it is possible to create a variable like this:
> private transient FacesContext _facesContext;
> and change the current implementation to:
> void setCachedFacesContext(FacesContext facesContext)
> {
> _facesContext = facesContext;
> }
> @Override
> protected FacesContext getFacesContext()
> {
> if (_facesContext == null)
> {
> return FacesContext.getCurrentInstance();
> }
> else
> {
> return _facesContext;
> }
> }
> Then we do this on methods like processXXX, encodeXXX (not on encodeAll),
> visitTree and invokeOnComponent:
> @Override
> public void processDecodes(FacesContext context)
> {
> try
> {
> setCachedFacesContext(context);
>
> /*.. do what is required */
> }
> finally
> {
> popComponentFromEL(context);
>
> setCachedFacesContext(null);
> }
> In few words, set and release temporally the variable while those operations
> are executed. This change will reduce the amount of calls to
> FacesContext.getCurrentInstance() without side effects, because we are
> caching only on safe places and enclosing everything in a try finally block.
> If no objections I'll commit this code soon.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2714) Include uncompressed jsf.js file and use it when development mode is used
[
https://issues.apache.org/jira/browse/MYFACES-2714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12868108#action_12868108
]
Jan-Kees van Andel commented on MYFACES-2714:
-
Hi Leonardo,
I don't see any issues, except two small ones:
1 The SNAPSHOT dependency for the JS plugin
2 The line: log.fine("Cannot evaluate EL expression
"+convertToExpression(expressionList)+ " in resource " +
getLibraryName()+":"+getResourceName());
looks like it "swallows" EL errors. I see that an event is published, but it
looks like some information is lost in the event.
Log.error might be more appropriate.
But, I must admit, I have only looked at the code, I haven't tested it in a
running application.
I'm +1 on committing this patch.
> Include uncompressed jsf.js file and use it when development mode is used
> -
>
> Key: MYFACES-2714
> URL: https://issues.apache.org/jira/browse/MYFACES-2714
> Project: MyFaces Core
> Issue Type: Improvement
> Components: JSR-314
>Affects Versions: 2.0.0
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
> Attachments: MYFACES-2714-2.patch, MYFACES-2714-3.patch
>
>
> Reading some blogs about jsf 2.0, I notice mojarra include an uncompressed
> jsf.js file and use it when development mode is used. It is difficult to
> debug myfaces javascript for users and I think it is worth to do it too.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2714) Include uncompressed jsf.js file and use it when development mode is used
[ https://issues.apache.org/jira/browse/MYFACES-2714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12868098#action_12868098 ] Jan-Kees van Andel commented on MYFACES-2714: - For archiving, this is the email conversation: -- Jan-Kees van Andel aan MyFaces details weergeven 15 mei (2 dagen geleden) The plan sounds good, but let's not forget the performance penalty of loading multiple javascript files when in production mode. No objections for loading multiple files in development mode. Maybe, we should even (from a security perspective) completely deny access to the debug versions of the scripts when in production mode. My 2 cents... Regards, Jan-Kees -- Michael Concini aan MyFaces details weergeven 15 mei (2 dagen geleden) I think Jan-Kees has a good point on denying access to the debug versions when in production mode. At least by default it might be good to deny access. -- Definitely +1 from my side regarding this, debug versions should definitely be for development mode only. Werner -- Hi I have attached a patch (MYFACES-2714-3.patch) that do what was suggested by Werner, including do not allow retrieve the javascript sources on production. Please, take a look at this one and if no objections, I'll commit the code. regards, Leonardo Uribe > Include uncompressed jsf.js file and use it when development mode is used > - > > Key: MYFACES-2714 > URL: https://issues.apache.org/jira/browse/MYFACES-2714 > Project: MyFaces Core > Issue Type: Improvement > Components: JSR-314 >Affects Versions: 2.0.0 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Attachments: MYFACES-2714-2.patch, MYFACES-2714-3.patch > > > Reading some blogs about jsf 2.0, I notice mojarra include an uncompressed > jsf.js file and use it when development mode is used. It is difficult to > debug myfaces javascript for users and I think it is worth to do it too. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (EXTSCRIPT-130) JSF 2.0 composite components are not picked up
JSF 2.0 composite components are not picked up -- Key: EXTSCRIPT-130 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-130 Project: MyFaces Extensions Scripting Issue Type: Bug Components: MyFaces 2.0 Extension Affects Versions: Beta-1 Environment: Windows Vista x64, Java 1.6.0_14, Maven Jetty Plugin Reporter: Jan-Kees van Andel Assignee: Werner Punz When I change (or add) a composite component, the change is not picked up. After a server restart the file is loaded. Normal Facelet files are picked up correctly, also included files, like the page template. I have configured all entries in web.xml and both JSF and Facelets are in development mode. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (EXTSCRIPT-116) NPE during reload in Maven Jetty Plugin
[
https://issues.apache.org/jira/browse/EXTSCRIPT-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12858484#action_12858484
]
Jan-Kees van Andel commented on EXTSCRIPT-116:
--
I might do that. Also a good way to start learning the internals of ExtScript.
But, for now, I'm very happy.
Good enough for an 1.0 release IMHO.
> NPE during reload in Maven Jetty Plugin
> ---
>
> Key: EXTSCRIPT-116
> URL: https://issues.apache.org/jira/browse/EXTSCRIPT-116
> Project: MyFaces Extensions Scripting
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.0-Beta-2
>Reporter: Jan-Kees van Andel
>Assignee: Werner Punz
> Fix For: 1.0-Beta-2
>
>
> I'm still trying to find out the best way to use the Maven Jetty Plugin, so I
> might be doing something wrong on this side here.
> Nevertheless, when I run mvn package on my project while the server is
> running (to update dependent libraries to the server), I get the following
> error:
> [INFO] Restarting webapp
> 18-apr-2010 21:24:02 org.apache.myfaces.webapp.StartupServletContextListener
> dispatchInitializationEvent
> INFO: Processing
> plugin:org.apache.myfaces.extensions.scripting.servlet.StartupServletContextPluginChainLoader
> 18-apr-2010 21:24:02 org.apache.myfaces.webapp.StartupServletContextListener
> dispatchInitializationEvent
> INFO: Processing MyFaces plugins done
> 18-apr-2010 21:24:02
> org.apache.myfaces.extensions.scripting.core.util.WeavingContext getWeaver
> WARNING: [EXT-SCRIPTING] Scripting Weaver is not set. Disabling script
> reloading subsystem. Make sure you have the scripting servlet filter enabled
> in your web.xml
> 2010-04-18 21:24:02.920::WARN: failed
> org.mortbay.jetty.plugin.jetty6pluginwebappcont...@63f5af{/html5parleys,D:\dev\work\idea9\parleys\web-html5\target\parleys-frontend-html5-0.1-SNAPSHOT}
> java.lang.NullPointerException
> at
> org.apache.myfaces.extensions.scripting.jsf.dynamicdecorators.implemetations.FacesContextProxy.weaveDelegate(FacesContextProxy.java:54)
> at
> org.apache.myfaces.extensions.scripting.jsf.dynamicdecorators.implemetations.FacesContextProxy.(FacesContextProxy.java:140)
> at
> org.apache.myfaces.extensions.scripting.jsf.dynamicdecorators.factories.ScriptingFacesContextFactory.getFacesContext(ScriptingFacesContextFactory.java:52)
> at
> org.apache.myfaces.webapp.AbstractFacesInitializer.dispatchInitDestroyEvent(AbstractFacesInitializer.java:195)
> at
> org.apache.myfaces.webapp.AbstractFacesInitializer.destroyFaces(AbstractFacesInitializer.java:204)
> at
> org.apache.myfaces.webapp.StartupServletContextListener.contextDestroyed(StartupServletContextListener.java:215)
> at
> org.mortbay.jetty.handler.ContextHandler.doStop(ContextHandler.java:599)
> at org.mortbay.jetty.webapp.WebAppContext.doStop(WebAppContext.java:498)
> at
> org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStop(Jetty6PluginWebAppContext.java:132)
> at
> org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:78)
> at
> org.mortbay.jetty.plugin.Jetty6RunWarExploded.restartWebApp(Jetty6RunWarExploded.java:118)
> at
> org.mortbay.jetty.plugin.Jetty6RunWarExploded$1.filesChanged(Jetty6RunWarExploded.java:100)
> at org.mortbay.util.Scanner.reportBulkChanges(Scanner.java:486)
> at org.mortbay.util.Scanner.reportDifferences(Scanner.java:352)
> at org.mortbay.util.Scanner.scan(Scanner.java:280)
> at org.mortbay.util.Scanner$1.run(Scanner.java:232)
> at java.util.TimerThread.mainLoop(Timer.java:512)
> at java.util.TimerThread.run(Timer.java:462)
> [ERROR] Error reconfiguring/restarting webapp after change in watched files
> java.lang.NullPointerException
> at
> org.apache.myfaces.extensions.scripting.jsf.dynamicdecorators.implemetations.FacesContextProxy.weaveDelegate(FacesContextProxy.java:54)
> at
> org.apache.myfaces.extensions.scripting.jsf.dynamicdecorators.implemetations.FacesContextProxy.(FacesContextProxy.java:140)
> at
> org.apache.myfaces.extensions.scripting.jsf.dynamicdecorators.factories.ScriptingFacesContextFactory.getFacesContext(ScriptingFacesContextFactory.java:52)
> at
> org.apache.myfaces.webapp.AbstractFacesInitializer.dispatchInitDestroyEvent(AbstractFacesInitializer.java:195)
> at
> org.apache.myfaces.webapp.AbstractFacesInitializer.destroyFaces(AbstractFacesInitializer.java:204)
> at
> org.apache.myfaces.webapp.StartupServletContextListener.contextDestroyed(StartupServletContextListener.java:215)
> at
> org.mortbay.jetty.handler.ContextHandler.doStop(ContextHandler.java:599)
> at org.mortbay.jetty.webapp.WebAppContext.doStop(WebAppContext.java:498)
> at
> org.mortbay.jetty.plugin.Jetty6PluginWebA
[jira] Created: (EXTSCRIPT-116) NPE during reload in Maven Jetty Plugin
NPE during reload in Maven Jetty Plugin
---
Key: EXTSCRIPT-116
URL: https://issues.apache.org/jira/browse/EXTSCRIPT-116
Project: MyFaces Extensions Scripting
Issue Type: Bug
Components: Core
Affects Versions: 1.0-Beta-2
Reporter: Jan-Kees van Andel
Assignee: Werner Punz
I'm still trying to find out the best way to use the Maven Jetty Plugin, so I
might be doing something wrong on this side here.
Nevertheless, when I run mvn package on my project while the server is running
(to update dependent libraries to the server), I get the following error:
[INFO] Restarting webapp
18-apr-2010 21:24:02 org.apache.myfaces.webapp.StartupServletContextListener
dispatchInitializationEvent
INFO: Processing
plugin:org.apache.myfaces.extensions.scripting.servlet.StartupServletContextPluginChainLoader
18-apr-2010 21:24:02 org.apache.myfaces.webapp.StartupServletContextListener
dispatchInitializationEvent
INFO: Processing MyFaces plugins done
18-apr-2010 21:24:02
org.apache.myfaces.extensions.scripting.core.util.WeavingContext getWeaver
WARNING: [EXT-SCRIPTING] Scripting Weaver is not set. Disabling script
reloading subsystem. Make sure you have the scripting servlet filter enabled in
your web.xml
2010-04-18 21:24:02.920::WARN: failed
org.mortbay.jetty.plugin.jetty6pluginwebappcont...@63f5af{/html5parleys,D:\dev\work\idea9\parleys\web-html5\target\parleys-frontend-html5-0.1-SNAPSHOT}
java.lang.NullPointerException
at
org.apache.myfaces.extensions.scripting.jsf.dynamicdecorators.implemetations.FacesContextProxy.weaveDelegate(FacesContextProxy.java:54)
at
org.apache.myfaces.extensions.scripting.jsf.dynamicdecorators.implemetations.FacesContextProxy.(FacesContextProxy.java:140)
at
org.apache.myfaces.extensions.scripting.jsf.dynamicdecorators.factories.ScriptingFacesContextFactory.getFacesContext(ScriptingFacesContextFactory.java:52)
at
org.apache.myfaces.webapp.AbstractFacesInitializer.dispatchInitDestroyEvent(AbstractFacesInitializer.java:195)
at
org.apache.myfaces.webapp.AbstractFacesInitializer.destroyFaces(AbstractFacesInitializer.java:204)
at
org.apache.myfaces.webapp.StartupServletContextListener.contextDestroyed(StartupServletContextListener.java:215)
at
org.mortbay.jetty.handler.ContextHandler.doStop(ContextHandler.java:599)
at org.mortbay.jetty.webapp.WebAppContext.doStop(WebAppContext.java:498)
at
org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStop(Jetty6PluginWebAppContext.java:132)
at
org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:78)
at
org.mortbay.jetty.plugin.Jetty6RunWarExploded.restartWebApp(Jetty6RunWarExploded.java:118)
at
org.mortbay.jetty.plugin.Jetty6RunWarExploded$1.filesChanged(Jetty6RunWarExploded.java:100)
at org.mortbay.util.Scanner.reportBulkChanges(Scanner.java:486)
at org.mortbay.util.Scanner.reportDifferences(Scanner.java:352)
at org.mortbay.util.Scanner.scan(Scanner.java:280)
at org.mortbay.util.Scanner$1.run(Scanner.java:232)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
[ERROR] Error reconfiguring/restarting webapp after change in watched files
java.lang.NullPointerException
at
org.apache.myfaces.extensions.scripting.jsf.dynamicdecorators.implemetations.FacesContextProxy.weaveDelegate(FacesContextProxy.java:54)
at
org.apache.myfaces.extensions.scripting.jsf.dynamicdecorators.implemetations.FacesContextProxy.(FacesContextProxy.java:140)
at
org.apache.myfaces.extensions.scripting.jsf.dynamicdecorators.factories.ScriptingFacesContextFactory.getFacesContext(ScriptingFacesContextFactory.java:52)
at
org.apache.myfaces.webapp.AbstractFacesInitializer.dispatchInitDestroyEvent(AbstractFacesInitializer.java:195)
at
org.apache.myfaces.webapp.AbstractFacesInitializer.destroyFaces(AbstractFacesInitializer.java:204)
at
org.apache.myfaces.webapp.StartupServletContextListener.contextDestroyed(StartupServletContextListener.java:215)
at
org.mortbay.jetty.handler.ContextHandler.doStop(ContextHandler.java:599)
at org.mortbay.jetty.webapp.WebAppContext.doStop(WebAppContext.java:498)
at
org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStop(Jetty6PluginWebAppContext.java:132)
at
org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:78)
at
org.mortbay.jetty.plugin.Jetty6RunWarExploded.restartWebApp(Jetty6RunWarExploded.java:118)
at
org.mortbay.jetty.plugin.Jetty6RunWarExploded$1.filesChanged(Jetty6RunWarExploded.java:100)
at org.mortbay.util.Scanner.reportBulkChanges(Scanner.java:486)
at org.mortbay.util.Scanner.reportDifferences(Scanner.java:352)
at org.mortbay.util.Scanner.scan(Scanner.java:280)
[jira] Created: (EXTSCRIPT-115) Better logging when developer specifies a non existent source directory
Better logging when developer specifies a non existent source directory --- Key: EXTSCRIPT-115 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-115 Project: MyFaces Extensions Scripting Issue Type: Bug Components: Core Affects Versions: 1.0-Beta-2 Reporter: Jan-Kees van Andel Assignee: Werner Punz When I make a typo in a source directory, like: D:/dev/work/idea9/parleys/web-html5/src/main/jav (notice the missing 'a' at the end) I don't get a message suggesting I made an error, but ExtScript fails silently by not reloading the classes in this directory. There is a javac message in the log: INFO: [EXT-SCRITPING] starting class dependency scan 18-apr-2010 16:53:24 org.apache.myfaces.extensions.scripting.loaders.java.jsr199.JSR199Compiler compile INFO: [EXT-SCRIPTING] Doing a full recompile javacTask: no source files Usage: javacTask use -help for a list of possible options But it's easy to miss it because MyFaces and other frameworks also emit a lot of logging. Something heavier (ERROR level or maybe an initializer exception) might be better, so the user won't get confused/angry. I think such a check is even more appropriate because file paths in Java are always error-prone (I always make mistakes with paths)... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MYFACES-2663) NPE in UIParameter when value resolves to null
NPE in UIParameter when value resolves to null -- Key: MYFACES-2663 URL: https://issues.apache.org/jira/browse/MYFACES-2663 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.1-SNAPSHOT Reporter: Jan-Kees van Andel When I have a null value in an tag, I get the following NPE when rendering: java.lang.NullPointerException at org.apache.myfaces.shared_impl.renderkit.html.HtmlRendererUtils.getOutcomeTargetLinkHref(HtmlRendererUtils.java:1883) at org.apache.myfaces.shared_impl.renderkit.html.HtmlLinkRendererBase.renderOutcomeLinkStart(HtmlLinkRendererBase.java:742) at org.apache.myfaces.shared_impl.renderkit.html.HtmlLinkRendererBase.encodeBegin(HtmlLinkRendererBase.java:123) at javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:430) at javax.faces.component.UIComponent.encodeAll(UIComponent.java:605) at javax.faces.component.UIComponent.encodeAll(UIComponent.java:614) at javax.faces.component.UIComponent.encodeAll(UIComponent.java:614) at org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:1117) at org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:231) at org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:122) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:207) at org.apache.myfaces.extensions.scripting.jsf.dynamicdecorators.implemetations.LifefcycleProxy.render(LifefcycleProxy.java:74) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:191) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:502) I don't know what the spec says or what Mojarra does, but I think we should at least do better than a NPE, for example appending an empty string to the parameter list... Any ideas? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (EXTSCRIPT-114) ExtScript fails to start when Groovy is not available
ExtScript fails to start when Groovy is not available - Key: EXTSCRIPT-114 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-114 Project: MyFaces Extensions Scripting Issue Type: Bug Components: Core Affects Versions: 1.0-Beta-2 Environment: Vista x64, Java 6, jetty-6.1.14 Reporter: Jan-Kees van Andel Assignee: Werner Punz When I don't add the groovy binaries to my Maven dependencies, and I run my app with maven-jetty-plugin, I get the following exception: 2010-04-18 14:46:55.710::WARN: Error starting handlers java.lang.NoClassDefFoundError: groovy/lang/GroovyObject at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:616) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) ... I don't want to use Groovy, but I do need the Groovy binaries for ExtScript to start. Maybe this Exception should be used to automatically disable Groovy support? Anyway, I personally don't mind to add Groovy, but I think it should be fixed before the 1.0 release b/c I think other users do mind. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-2621) BeanValidation does not work with Unified EL 2.2
[ https://issues.apache.org/jira/browse/MYFACES-2621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851358#action_12851358 ] Jan-Kees van Andel commented on MYFACES-2621: - Looks good, you only need to declare the fields volatile, to ensure safe publication of the values. Performance impact of a volatile read is no issue. > BeanValidation does not work with Unified EL 2.2 > > > Key: MYFACES-2621 > URL: https://issues.apache.org/jira/browse/MYFACES-2621 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314 >Affects Versions: 2.0.0-beta-3 > Environment: bean validation 1.0.0.GA, unified el 2.2 >Reporter: Jakob Korherr >Assignee: Jakob Korherr > Fix For: 2.0.0-beta-4 > > > When using the new Unified EL 2.2, BeanValidation does not work, because > _BeanValidatorUELUtils.getUELValueReferenceWrapper() always returns null. > See also the related thread on the mailing list: > http://www.mail-archive.com/us...@myfaces.apache.org/msg55250.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACESTEST-6) Module for automated webapp tests for MyFaces core + extensions
[ https://issues.apache.org/jira/browse/MYFACESTEST-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12850534#action_12850534 ] Jan-Kees van Andel commented on MYFACESTEST-6: -- For archiving purposes, here's a link to the original discussion: http://markmail.org/thread/mx5pvpug3woazhzc > Module for automated webapp tests for MyFaces core + extensions > --- > > Key: MYFACESTEST-6 > URL: https://issues.apache.org/jira/browse/MYFACESTEST-6 > Project: MyFaces Test > Issue Type: New Feature >Reporter: Jakob Korherr >Assignee: Jakob Korherr > > As we currently only have normal JUnit tests for automated testing in MyFaces > Core, it would be really great to have a way to test MyFaces Core > automatically in a real webapp at build time with maven. Of course, we > currently have the test-webapp, but we still have to check each page manually > here, if we want to test everything, which is long-winded. In addition, it > would be cool if we could use this also for testing of MyFaces extensions > against MyFaces Core and Mojarra. > To accomplish something like that we could use test frameworks like e.g. > Canoo WebTest or HttpUnit + Jetty or something similar. Basically anything > that works with jetty in maven, but can also be used with other servers like > tomcat or glassfish, would be ok here. I also want to mention JSFUnit here, > although we won't be able to use it since it is LGPL licensed. > The two most important things about this module would be 1) that everything > has to work totally automated within maven and without a browser (so I > wouldn't consider selenium as an option) and 2) a fluent and easy API to > write those tests (otherwise no one would use it). > This would help us enormously in ensuring and improving the quality of > MyFaces Core and its extensions by getting a far bigger test coverage and > more possibilities to test. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2621) BeanValidation does not work with Unified EL 2.2
[ https://issues.apache.org/jira/browse/MYFACES-2621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12848895#action_12848895 ] Jan-Kees van Andel commented on MYFACES-2621: - My first implementation of ExternalSpecifications was purely designed for performance, relying on the ClassLoader to safely publish the variables. Testability was the reason to refactor it into synchronized methods. If you guys don't mind about less testability, we can always revert it to the original implementation which is probably the fastest possible implementation (no volatile/synchronized needed). A Double Checked Locking (DCL) implementation would also be a valid choice, since we depend on Java 5+ and the Java 5 JMM guarantees DCL correctness. That way, the first access requires an exclusive lock and consecutive calls only do volatile reads. This is still pretty fast without compromising testability. I would say, revert ExternalSpecifications to its original form and then look at Leonardo's suggestion. > BeanValidation does not work with Unified EL 2.2 > > > Key: MYFACES-2621 > URL: https://issues.apache.org/jira/browse/MYFACES-2621 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314 >Affects Versions: 2.0.0-beta-3 > Environment: bean validation 1.0.0.GA, unified el 2.2 >Reporter: Jakob Korherr >Assignee: Jakob Korherr > > When using the new Unified EL 2.2, BeanValidation does not work, because > _BeanValidatorUELUtils.getUELValueReferenceWrapper() always returns null. > See also the related thread on the mailing list: > http://www.mail-archive.com/us...@myfaces.apache.org/msg55250.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOMAHAWK-1497) New component: ValidateBeanBehavior
New component: ValidateBeanBehavior --- Key: TOMAHAWK-1497 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1497 Project: MyFaces Tomahawk Issue Type: New Feature Environment: * Reporter: Jan-Kees van Andel Assignee: Jan-Kees van Andel I've been playing with Bean Validation and JSF2 ClientBehavior. I've written a simple ClientBehavior which renders JavaScript validations, based on the Bean Validation constraints. The developer only needs to nest a into a UICommand component and the Behavior renders the necessary JavaScript. As I said, it's a start. It currently only supports some validations: - JSF required attribute. - Numeric and date formats, based on how the converter is configured (i.e. a pattern like: "dd-MM-"). - Bean Validation @NotNull, @Min, @Max and @Future. It should be usable in Mojarra, since I simply copied the MyFaces dependencies to the component (ExternalSpecifications.java, FacesMessageInterpolator.java and the other Bean Validation related classes). It still needs some work (like supporting other annotations, and more datestyle patterns), but it's a start. So I was thinking about committing it into the Sandbox, under: http://svn.apache.org/repos/asf/myfaces/tomahawk/trunk/core20/ I think this concept (when the implementation is ready) is really powerful and a nice addition to the project. I've written two blog articles where I give a little overview: http://blog.smart-java.nl/blog/index.php/2010/03/17/jsf-2-0-clientbehavior-bean-validation-in-javascript/ http://blog.smart-java.nl/blog/index.php/2010/03/19/jsf-2-0-clientbehavior-first-impressions/ When done Mavenizing, I'll add an attachment with all source code. What do you guys think? Should we add it to the project? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2509) @ListenerFor not processed for global system events
[ https://issues.apache.org/jira/browse/MYFACES-2509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12844406#action_12844406 ] Jan-Kees van Andel commented on MYFACES-2509: - I think you're right. I initially only considered it to be used for startup listeners, and I don't think those classes should contain state, but on the other hand, we shouldn't have such a silend, undocumented requirement. This will indeed cause weird bugs. > @ListenerFor not processed for global system events > --- > > Key: MYFACES-2509 > URL: https://issues.apache.org/jira/browse/MYFACES-2509 > Project: MyFaces Core > Issue Type: New Feature > Components: JSR-314 >Affects Versions: 2.0.0-alpha >Reporter: Jan-Kees van Andel >Assignee: Jan-Kees van Andel > Attachments: ListenerFor_support.patch > > > We currently don't process @ListenerFor and @ListenerFor annotations on > non-component types. > This is specified in the spec for global system events, see: > http://java.sun.com/javaee/javaserverfaces/2.0/docs/api/index.html?javax/faces/event/ListenerFor.html > It would be nice to have it in the beta. -- 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-2509) @ListenerFor not processed for global system events
[ https://issues.apache.org/jira/browse/MYFACES-2509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12844406#action_12844406 ] Jan-Kees van Andel edited comment on MYFACES-2509 at 3/12/10 7:57 AM: -- I think you're right. I initially only considered it to be used for startup listeners, and I don't think those classes should contain state, but on the other hand, we shouldn't have such a silent, undocumented requirement. This will indeed cause weird bugs. was (Author: jankeesvanandel): I think you're right. I initially only considered it to be used for startup listeners, and I don't think those classes should contain state, but on the other hand, we shouldn't have such a silend, undocumented requirement. This will indeed cause weird bugs. > @ListenerFor not processed for global system events > --- > > Key: MYFACES-2509 > URL: https://issues.apache.org/jira/browse/MYFACES-2509 > Project: MyFaces Core > Issue Type: New Feature > Components: JSR-314 >Affects Versions: 2.0.0-alpha >Reporter: Jan-Kees van Andel >Assignee: Jan-Kees van Andel > Attachments: ListenerFor_support.patch > > > We currently don't process @ListenerFor and @ListenerFor annotations on > non-component types. > This is specified in the spec for global system events, see: > http://java.sun.com/javaee/javaserverfaces/2.0/docs/api/index.html?javax/faces/event/ListenerFor.html > It would be nice to have it in the beta. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2585) ajax doesn't work if target contains script with CDATA
[
https://issues.apache.org/jira/browse/MYFACES-2585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12842440#action_12842440
]
Jan-Kees van Andel commented on MYFACES-2585:
-
I'm just looking at it from the side, but isn't the issue that there is some
fixed CDATA block (the outermost one), which may contain arbitrary HTML
(possibly containing CDATA blocks)?
There's nothing wrong with the CDATA on itself. It goes wrong when it's being
marshalled another CDATA block. So that's where I would put (the first part of)
the fix.
For example, by overriding (if allowed by the TCK) the write() method in
PartialResponseWriter to encode the CDATA end tag in some way.
When encoded, the JavaScript only needs to decode all content in the CDATA
blocks.
If conform spec, it should be compatible with Mojarra and frameworks should not
see any difference.
Any nesting deeper than one level is an error of the developer/component-author
and I don't think we should anticipate on this.
So actually I'm saying we need to do any encoding exactly at the point where
the content is being written to the response. Before is impossible, after is
cumbersome.
The write() method could also be put into the impl, but I think it then needs
to become smarter, containing some state whether or not the content needs to be
encoded. Overriding write() in PartialResponseWriter is possibly the easiest
approach since you can assume all content needs to be encoded.
But again, I'm just looking at it from the sideline and I might not see all
details here. Just trying to look at it from a fresh angle. ;-)
> ajax doesn't work if target contains script with CDATA
> --
>
> Key: MYFACES-2585
> URL: https://issues.apache.org/jira/browse/MYFACES-2585
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
>Affects Versions: 2.0.0-beta-2
> Environment: Javascript, API, IMPL...
>Reporter: Ganesh Jung
>Priority: Critical
>
> This doesn't work:
>
>
>
>
>
> // alert("running");
> //]]>
>
>
>
> But this works fine:
>
>
>
>
>
> alert("running");
>
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2565) BeanValidator throws Exception if external ExpressionLanguageFactory is being used
[
https://issues.apache.org/jira/browse/MYFACES-2565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839297#action_12839297
]
Jan-Kees van Andel commented on MYFACES-2565:
-
Separate issue created, see: MYFACES-2582
> BeanValidator throws Exception if external ExpressionLanguageFactory is being
> used
> --
>
> Key: MYFACES-2565
> URL: https://issues.apache.org/jira/browse/MYFACES-2565
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.0.0-beta
>Reporter: Mark Struberg
>Assignee: Jan-Kees van Andel
> Fix For: 2.0.0-beta-3
>
>
> Currently the BeanValidator has the following code:
> if (_ExternalSpecifications.isUnifiedELAvailable())
> {
>//TODO: Implement when Unified EL for Java EE6 is available.
>throw new FacesException("Unified EL for Java EE6 support is not yet
> implemented");
> }
> I'm using EL-2.2 in MyFaces-2.0.0-SNAPSHOT and now switched from using
> facelets-1.1.15.B1 to the built-in facelets-2.
> After that I get this rather unfunny Exception in the code above.
> I tried to remove this condition in BeanValidator and so far all works well.
> Afaik the new EL-2.1 interface should be backward compatible to the EL of
> JSF-2.1, isn't?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2582) Publish useful container capability flags into ServletContext
Publish useful container capability flags into ServletContext - Key: MYFACES-2582 URL: https://issues.apache.org/jira/browse/MYFACES-2582 Project: MyFaces Core Issue Type: Improvement Components: JSR-314 Affects Versions: 2.0.0-beta-2 Reporter: Jan-Kees van Andel Assignee: Jan-Kees van Andel Priority: Minor Currently, we have 3 identical "ExternalSpecifications" classes, in 3 separate packages. They are getting more complex and the duplication becomes cumbersome. A solution might be to enhance the StartupServletContextListener class to let it publish those container flags into the ServletContext, so the other classes can easily reuse them. See Jakob's comment on MYFACES-2565 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2565) BeanValidator throws Exception if external ExpressionLanguageFactory is being used
[
https://issues.apache.org/jira/browse/MYFACES-2565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839290#action_12839290
]
Jan-Kees van Andel commented on MYFACES-2565:
-
Okay, but it's getting a bit nasty this way (copy-pasting this class 3 times,
especially since it is getting more complex).
I assume we also need to work with Java access permissions turned on?
Otherwise, we can do some reflection stuff, like:
- Putting all logic inside one class, let's say:
javax.faces.validate._ExternalSpecifications
- Putting some kind of bridge classes in other packages, like:
package javax.faces.component;
class _ExternalSpecificationsBridge {
public boolean isUnifiedELAvailable() {
try {
Class c = Class.forName("javax.faces.validate._ExternalSpecifications");
Method m = c.getMethod("isUnifiedELAvailable");
m.setAccessible(true);
return Boolean.TRUE.equals(m.invoke());
} catch () { return false; }
}
}
> BeanValidator throws Exception if external ExpressionLanguageFactory is being
> used
> --
>
> Key: MYFACES-2565
> URL: https://issues.apache.org/jira/browse/MYFACES-2565
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.0.0-beta
>Reporter: Mark Struberg
>Assignee: Jan-Kees van Andel
> Fix For: 2.0.0-beta-3
>
>
> Currently the BeanValidator has the following code:
> if (_ExternalSpecifications.isUnifiedELAvailable())
> {
>//TODO: Implement when Unified EL for Java EE6 is available.
>throw new FacesException("Unified EL for Java EE6 support is not yet
> implemented");
> }
> I'm using EL-2.2 in MyFaces-2.0.0-SNAPSHOT and now switched from using
> facelets-1.1.15.B1 to the built-in facelets-2.
> After that I get this rather unfunny Exception in the code above.
> I tried to remove this condition in BeanValidator and so far all works well.
> Afaik the new EL-2.1 interface should be backward compatible to the EL of
> JSF-2.1, isn't?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2509) @ListenerFor not processed for global system events
[ https://issues.apache.org/jira/browse/MYFACES-2509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan-Kees van Andel resolved MYFACES-2509. - Resolution: Fixed Fix Version/s: 2.0.0-beta-3 Patch committed > @ListenerFor not processed for global system events > --- > > Key: MYFACES-2509 > URL: https://issues.apache.org/jira/browse/MYFACES-2509 > Project: MyFaces Core > Issue Type: New Feature > Components: JSR-314 >Affects Versions: 2.0.0-alpha >Reporter: Jan-Kees van Andel >Assignee: Jan-Kees van Andel > Fix For: 2.0.0-beta-3 > > Attachments: ListenerFor_support.patch > > > We currently don't process @ListenerFor and @ListenerFor annotations on > non-component types. > This is specified in the spec for global system events, see: > http://java.sun.com/javaee/javaserverfaces/2.0/docs/api/index.html?javax/faces/event/ListenerFor.html > It would be nice to have it in the beta. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2565) BeanValidator throws Exception if external ExpressionLanguageFactory is being used
[
https://issues.apache.org/jira/browse/MYFACES-2565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan-Kees van Andel resolved MYFACES-2565.
-
Resolution: Fixed
Fix Version/s: 2.0.0-beta-3
It should work now, however I don't like the implementation. I need to resort
to reflection if I want to use the ValueExpression.getValueReference() method,
because the compile classpath contains two entries for ValueExpression: One in
jsp-api-2.1 and one in el-api-2.2.
Someone please review the implementation...
> BeanValidator throws Exception if external ExpressionLanguageFactory is being
> used
> --
>
> Key: MYFACES-2565
> URL: https://issues.apache.org/jira/browse/MYFACES-2565
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.0.0-beta
>Reporter: Mark Struberg
>Assignee: Jan-Kees van Andel
> Fix For: 2.0.0-beta-3
>
>
> Currently the BeanValidator has the following code:
> if (_ExternalSpecifications.isUnifiedELAvailable())
> {
>//TODO: Implement when Unified EL for Java EE6 is available.
>throw new FacesException("Unified EL for Java EE6 support is not yet
> implemented");
> }
> I'm using EL-2.2 in MyFaces-2.0.0-SNAPSHOT and now switched from using
> facelets-1.1.15.B1 to the built-in facelets-2.
> After that I get this rather unfunny Exception in the code above.
> I tried to remove this condition in BeanValidator and so far all works well.
> Afaik the new EL-2.1 interface should be backward compatible to the EL of
> JSF-2.1, isn't?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2565) BeanValidator throws Exception if external ExpressionLanguageFactory is being used
[
https://issues.apache.org/jira/browse/MYFACES-2565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12838802#action_12838802
]
Jan-Kees van Andel commented on MYFACES-2565:
-
Just looking at the JavaDocs of BeanValidator#validate(), it looks like a
null-check is missing.
"If ValueReference.getBase() return null, take no action and return."
I'll try to fix this issue (as well as the other BeanValidator related issues)
this weekend, but it depends, since I'm a bit behind schedule after JSFDays...
> BeanValidator throws Exception if external ExpressionLanguageFactory is being
> used
> --
>
> Key: MYFACES-2565
> URL: https://issues.apache.org/jira/browse/MYFACES-2565
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.0.0-beta
>Reporter: Mark Struberg
>
> Currently the BeanValidator has the following code:
> if (_ExternalSpecifications.isUnifiedELAvailable())
> {
>//TODO: Implement when Unified EL for Java EE6 is available.
>throw new FacesException("Unified EL for Java EE6 support is not yet
> implemented");
> }
> I'm using EL-2.2 in MyFaces-2.0.0-SNAPSHOT and now switched from using
> facelets-1.1.15.B1 to the built-in facelets-2.
> After that I get this rather unfunny Exception in the code above.
> I tried to remove this condition in BeanValidator and so far all works well.
> Afaik the new EL-2.1 interface should be backward compatible to the EL of
> JSF-2.1, isn't?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2576) Race condition in _ExternalSpecifications methods
[ https://issues.apache.org/jira/browse/MYFACES-2576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12837915#action_12837915 ] Jan-Kees van Andel commented on MYFACES-2576: - It has to do with safe publication of the variable on multicore systems. Synchronizing is more than just locking, it's also about visibility of variables over multiple processor caches. Synchronizing also doesn't hurt performance in practice. I'm sure of that, because the expensive part is only executed once while holding the lock. If there happens to be a performance issue, we can always switch to some kind of other implementation, like Double Checked Locking, which is safe since Java 5. The only issue I currently see is the risk of deadlock, because we're effectively invoking alien code within the initialization code (we can't know the). > Race condition in _ExternalSpecifications methods > - > > Key: MYFACES-2576 > URL: https://issues.apache.org/jira/browse/MYFACES-2576 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314 >Affects Versions: 2.0.0-beta-2 > Environment: * >Reporter: Jan-Kees van Andel > > The static final fields in the _ExternalSpecifications have recently been > refactored into methods. But unfortunately, this has broken thread safety, > possibly leading to strange errors (like NPE). > I think the only solution with the current implementation is to make the > methods synchronized. Volatile is not enough AFAICS... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2576) Race condition in _ExternalSpecifications methods
Race condition in _ExternalSpecifications methods - Key: MYFACES-2576 URL: https://issues.apache.org/jira/browse/MYFACES-2576 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-2 Environment: * Reporter: Jan-Kees van Andel The static final fields in the _ExternalSpecifications have recently been refactored into methods. But unfortunately, this has broken thread safety, possibly leading to strange errors (like NPE). I think the only solution with the current implementation is to make the methods synchronized. Volatile is not enough AFAICS... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2565) BeanValidator throws Exception if external ExpressionLanguageFactory is being used
[
https://issues.apache.org/jira/browse/MYFACES-2565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12835895#action_12835895
]
Jan-Kees van Andel commented on MYFACES-2565:
-
I put it there when implementing the first version of BeanValidator. The spec
says the following:
http://java.sun.com/javaee/javaserverfaces/2.0/docs/api/javax/faces/validator/BeanValidator.html#validate%28javax.faces.context.FacesContext,%20javax.faces.component.UIComponent,%20java.lang.Object%29
Let valueExpression be the return from calling
UIComponent.getValueExpression(java.lang.String) on the argument component,
passing the literal string "value" (without the quotes) as an argument. If this
application is running in an environment with a Unified EL Implementation for
Java EE6 or later, obtain the ValueReference from valueExpression and let
valueBaseClase be the return from calling ValueReference.getBase() and
valueProperty be the return from calling ValueReference.getProperty(). If an
earlier version of the Unified EL is present, use the appropriate methods to
inspect valueExpression and derive values for valueBaseClass and valueProperty.
Back then, it was not possible to completely implement this method, because
Unified EL was not available, so I put the TODO and Exception in. I assume we
can now safely implement the remaining part.
> BeanValidator throws Exception if external ExpressionLanguageFactory is being
> used
> --
>
> Key: MYFACES-2565
> URL: https://issues.apache.org/jira/browse/MYFACES-2565
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.0.0-beta
>Reporter: Mark Struberg
>
> Currently the BeanValidator has the following code:
> if (_ExternalSpecifications.isUnifiedELAvailable())
> {
>//TODO: Implement when Unified EL for Java EE6 is available.
>throw new FacesException("Unified EL for Java EE6 support is not yet
> implemented");
> }
> I'm using EL-2.2 in MyFaces-2.0.0-SNAPSHOT and now switched from using
> facelets-1.1.15.B1 to the built-in facelets-2.
> After that I get this rather unfunny Exception in the code above.
> I tried to remove this condition in BeanValidator and so far all works well.
> Afaik the new EL-2.1 interface should be backward compatible to the EL of
> JSF-2.1, isn't?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2509) @ListenerFor not processed for global system events
[ https://issues.apache.org/jira/browse/MYFACES-2509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12829819#action_12829819 ] Jan-Kees van Andel commented on MYFACES-2509: - I don't mind to commit it, but I currently don't have a proper local build so I can't do a proper pre-commit test with the latest updates... If you would like to commit it Mike, that would be great. Also, Leonardo had a good point. And this might impact the TCK, so we might put it on the (short) TODO list or ask it on the EG list > @ListenerFor not processed for global system events > --- > > Key: MYFACES-2509 > URL: https://issues.apache.org/jira/browse/MYFACES-2509 > Project: MyFaces Core > Issue Type: New Feature > Components: JSR-314 >Affects Versions: 2.0.0-alpha >Reporter: Jan-Kees van Andel >Assignee: Jan-Kees van Andel > Attachments: ListenerFor_support.patch > > > We currently don't process @ListenerFor and @ListenerFor annotations on > non-component types. > This is specified in the spec for global system events, see: > http://java.sun.com/javaee/javaserverfaces/2.0/docs/api/index.html?javax/faces/event/ListenerFor.html > It would be nice to have it in the beta. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2524) Change ExternalSpecifications to enable using it in automated tests
[ https://issues.apache.org/jira/browse/MYFACES-2524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806489#action_12806489 ] Jan-Kees van Andel commented on MYFACES-2524: - The only reason for this approach was performance, since final fields are automatically thread safe. The classloader makes sure it is. Most of the code should be quite performant, only: "Validation.buildDefaultValidatorFactory().getValidator();" is an issue. You don't want to invoke this beast on every request, since it bootstraps Bean Validation. I added it because of an issue raised by (I think) Mike Concini. I think a lazy initializing singleton is a good replacement. This way, you can change some settings before initialization happens. > Change ExternalSpecifications to enable using it in automated tests > --- > > Key: MYFACES-2524 > URL: https://issues.apache.org/jira/browse/MYFACES-2524 > Project: MyFaces Core > Issue Type: Task >Affects Versions: 2.0.0-beta >Reporter: Jakob Korherr >Assignee: Jakob Korherr > > Currently ExternalSpecifications is using public static final fields to hold > the information if something is available or not (e.g. bean validation). > However, this is problematic for automated testing, because the value can not > be adapted for the test case (not even with reflection). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2509) @ListenerFor not processed for global system events
[ https://issues.apache.org/jira/browse/MYFACES-2509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804952#action_12804952 ] Jan-Kees van Andel commented on MYFACES-2509: - Hrm, it looks like the JavaDoc can be interpreted in multiple ways. What I read, is that it should be possible for classes that implement SystemEventListener, to listen to SystemEvents. For example: http://java.sun.com/javaee/javaserverfaces/2.0/docs/api/javax/faces/event/PostConstructApplicationEvent.html The current implementation cannot deal with this event, because it occurs before the ApplicationImpl code is invoked (there is no component tree at that time). For this reason, we need to check it @startup. But because its so ambiguous, I suggest to leave it out of the beta release. > @ListenerFor not processed for global system events > --- > > Key: MYFACES-2509 > URL: https://issues.apache.org/jira/browse/MYFACES-2509 > Project: MyFaces Core > Issue Type: New Feature > Components: JSR-314 >Affects Versions: 2.0.0-alpha >Reporter: Jan-Kees van Andel >Assignee: Jan-Kees van Andel > Attachments: ListenerFor_support.patch > > > We currently don't process @ListenerFor and @ListenerFor annotations on > non-component types. > This is specified in the spec for global system events, see: > http://java.sun.com/javaee/javaserverfaces/2.0/docs/api/index.html?javax/faces/event/ListenerFor.html > It would be nice to have it in the beta. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2509) @ListenerFor not processed for global system events
@ListenerFor not processed for global system events --- Key: MYFACES-2509 URL: https://issues.apache.org/jira/browse/MYFACES-2509 Project: MyFaces Core Issue Type: New Feature Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Jan-Kees van Andel Assignee: Jan-Kees van Andel We currently don't process @ListenerFor and @ListenerFor annotations on non-component types. This is specified in the spec for global system events, see: http://java.sun.com/javaee/javaserverfaces/2.0/docs/api/index.html?javax/faces/event/ListenerFor.html It would be nice to have it in the beta. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2490) Missing no-args constructor in EventHandler.Listener causes Exception during postback
Missing no-args constructor in EventHandler.Listener causes Exception during postback - Key: MYFACES-2490 URL: https://issues.apache.org/jira/browse/MYFACES-2490 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Jan-Kees van Andel Assignee: Jan-Kees van Andel This is a snippet of the erroneous Facelet: ... ... The problem occurs during postback, when the following Exception is thrown: javax.servlet.ServletException: Could not restore StateHolder of type org.apache.myfaces.view.facelets.tag.jsf.core.EventHandler$Listener (missing no-args constructor?) at javax.faces.webapp.FacesServlet._handleStandardRequest(FacesServlet.java:483) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:209) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:619) Caused by: java.lang.RuntimeException: Could not restore StateHolder of type org.apache.myfaces.view.facelets.tag.jsf.core.EventHandler$Listener (missing no-args constructor?) at javax.faces.component.UIComponentBase.restoreAttachedState(UIComponentBase.java:1479) at javax.faces.component.UIComponent$EventListenerWrapper.restoreState(UIComponent.java:1120) at javax.faces.component._DeltaList.restoreState(_DeltaList.java:300) at javax.faces.component.UIComponentBase.restoreDeltaSystemEventListenerClassMap(UIComponentBase.java:1770) at javax.faces.component.UIComponentBase.restoreState(UIComponentBase.java:1611) at javax.faces.component.UIOutput.restoreState(UIOutput.java:213) at org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.restoreStateFromMap(DefaultFaceletsStateManagementStrategy.java:379) at org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.restoreStateFromMap(DefaultFaceletsStateManagementStrategy.java:393) at org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.restoreStateFromMap(DefaultFaceletsStateManagementStrategy.java:393) 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:927) at org.apache.myfaces.application.ViewHandlerImpl.restoreView(ViewHandlerImpl.java:231) at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:80) 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 Caused by: java.lang.InstantiationException: org.apache.myfaces.view.facelets.tag.jsf.core.EventHandler$Listener at java.lang.Class.newInstance0(Class.java:340) at java.lang.Class.newInstance(Class.java:308) at javax.faces.component.UIComponentBase.restoreAttachedState(UIComponentBase.java:1475) ... 31 more According to the FacesListener spec, every implementation must provide a no-args constructor: https://javaserverfaces.dev.java.net/nonav/docs/2.0/
[jira] Created: (EXTSCRIPT-38) NPE after reloading NavigationHandler
NPE after reloading NavigationHandler - Key: EXTSCRIPT-38 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-38 Project: MyFaces Extensions Scripting Issue Type: Bug Reporter: Jan-Kees van Andel Assignee: Werner Punz I see the explanation in the createMethodReloadingProxyFromObject JavaDocs, but since the example crashes, I thought, let's file this issue anyway. When a new NavigationHandler is loaded and I click on a button in the example page, I get the following NPE (because _delegate is null): java.lang.NullPointerException at org.apache.myfaces.scripting.core.reloading.SimpleReloadingStrategy.reload(SimpleReloadingStrategy.java:70) at org.apache.myfaces.scripting.core.reloading.GlobalReloadingStrategy.reload(GlobalReloadingStrategy.java:79) at org.apache.myfaces.scripting.api.BaseWeaver.reloadScriptingInstance(BaseWeaver.java:98) at org.apache.myfaces.scripting.core.CoreWeaver.reloadScriptingInstance(CoreWeaver.java:62) at org.apache.myfaces.scripting.jsf.dynamicdecorators.implemetations.NavigationHandlerProxy.weaveDelegate(NavigationHandlerProxy.java:36) at org.apache.myfaces.scripting.jsf.dynamicdecorators.implemetations.NavigationHandlerProxy.handleNavigation(NavigationHandlerProxy.java:45) at org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:82) at javax.faces.component.UICommand.broadcast(UICommand.java:127) at javax.faces.component.UIViewRoot._broadcastForPhase(UIViewRoot.java:369) at javax.faces.component.UIViewRoot.process(UIViewRoot.java:264) at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:153) at org.apache.myfaces.lifecycle.InvokeApplicationExecutor.execute(InvokeApplicationExecutor.java:32) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76) at org.apache.myfaces.scripting.jsf.dynamicdecorators.implemetations.LifefcycleProxy.execute(LifefcycleProxy.java:60) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:178) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1074) at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:147) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065) at org.apache.myfaces.scripting.servlet.ScriptingServletFilter.doFilter(ScriptingServletFilter.java:50) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:146) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) at org.mortbay.jetty.Server.handle(Server.java:285) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:457) at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:765) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:628) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:357) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:329) at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (EXTSCRIPT-27) myfaces 1.2. example doesn't run on Windoze...
[ https://issues.apache.org/jira/browse/EXTSCRIPT-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan-Kees van Andel resolved EXTSCRIPT-27. - Resolution: Fixed Assignee: Jan-Kees van Andel (was: Werner Punz) All three examples should work now. (except for the NPE listed in EXTSCRIPT-36) > myfaces 1.2. example doesn't run on Windoze... > -- > > Key: EXTSCRIPT-27 > URL: https://issues.apache.org/jira/browse/EXTSCRIPT-27 > Project: MyFaces Extensions Scripting > Issue Type: Bug >Reporter: Matthias Weßendorf >Assignee: Jan-Kees van Andel > Attachments: Extscript_examples > > > 2009-12-05 13:46:20.312::WARN: Error starting handlers > java.lang.ExceptionInInitializerError > at > org.apache.myfaces.shared_impl.webapp.webxml.WebXml.init(WebXml.java:243) > at > org.apache.myfaces.shared_impl.webapp.webxml.WebXml.getWebXml(WebXml.java:228) > at > org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:74) > at > org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:139) > at > org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:511) > at org.mortbay.jetty.servlet.Context.startContext(Context.java:135) > at > org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1191) > at > org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:481) > at > org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:434) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) > at > org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147) > at > org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:120) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) > at > org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) > at > org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:117) > at org.mortbay.jetty.Server.doStart(Server.java:210) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) > at > org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:134) > at > org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:332) > at > org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:277) > at > org.mortbay.jetty.plugin.AbstractJettyRunMojo.execute(AbstractJettyRunMojo.java:195) > at > org.mortbay.jetty.plugin.Jetty6RunMojo.execute(Jetty6RunMojo.java:183) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:453) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:513) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:483) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:301) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: java.lang.StringIndexOutOfBoundsException: String index out of > range: 1 > at java.lang.String.charAt(String.java:687) > at java.util.regex.Matcher.appendReplacement(Matcher.java:703) > at java.util.regex.Matcher.replaceAll(Mat
[jira] Commented: (EXTSCRIPT-36) NPE in when clicking button in myfaces 1.2 example
[
https://issues.apache.org/jira/browse/EXTSCRIPT-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790105#action_12790105
]
Jan-Kees van Andel commented on EXTSCRIPT-36:
-
I also tried a quick fix (some null checks), but unfortunately this didn't
solve anything. If I have some spare time tonight, I'll also take a look at the
cause. For one, I saw two strange (copy-paste) methods in WeavingContext.java:
public static Object createMethodReloadingProxyFromObject(Object o, Class
theInterface, int artefactType) {
return Proxy.newProxyInstance(o.getClass().getClassLoader(),
new Class[]{theInterface},
new MethodLevelReloadingHandler(o,
artefactType));
}
public static Object createConstructorReloadingProxyFromObject(Object o,
Class theInterface, int artefactType) {
return Proxy.newProxyInstance(o.getClass().getClassLoader(),
new Class[]{theInterface},
new MethodLevelReloadingHandler(o,
artefactType));
}
Both return a MethodLevelReloadingHandler.
However, changing the second method to return a
ConstructorLevelReloadingHandler, doesn't make a difference. The same exception
occurs.
> NPE in when clicking button in myfaces 1.2 example
> --
>
> Key: EXTSCRIPT-36
> URL: https://issues.apache.org/jira/browse/EXTSCRIPT-36
> Project: MyFaces Extensions Scripting
> Issue Type: Bug
>Reporter: Jan-Kees van Andel
>Assignee: Werner Punz
>
> When I enter some data in the upper input field in the MF 1.2 example, I get
> the following NPE:
> javax.faces.FacesException: Exception while validating component with path :
> {Component-Path : [Class: javax.faces.component.UIViewRoot,ViewId:
> /helloWorld.xhtml][Class: javax.faces.component.html.HtmlForm,Id:
> form][Class: javax.faces.component.html.HtmlPanelGrid,Id: grid][Class:
> javax.faces.component.html.HtmlInputText,Id: input1]}
> at javax.faces.component.UIInput.validate(UIInput.java:421)
> at javax.faces.component.UIInput.processValidators(UIInput.java:186)
> at
> javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:726)
> at javax.faces.component.UIForm.processValidators(UIForm.java:82)
> at
> javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:726)
> at javax.faces.component.UIViewRoot.access$101(UIViewRoot.java:62)
> at javax.faces.component.UIViewRoot$2.process(UIViewRoot.java:133)
> at javax.faces.component.UIViewRoot.process(UIViewRoot.java:260)
> at
> javax.faces.component.UIViewRoot.processValidators(UIViewRoot.java:129)
> at
> org.apache.myfaces.lifecycle.ProcessValidationsExecutor.execute(ProcessValidationsExecutor.java:32)
> at
> org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103)
> at
> org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76)
> at
> org.apache.myfaces.scripting.jsf.dynamicdecorators.implemetations.LifefcycleProxy.execute(LifefcycleProxy.java:60)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:178)
> at
> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1074)
> at
> org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:147)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065)
> at
> org.apache.myfaces.scripting.servlet.ScriptingServletFilter.doFilter(ScriptingServletFilter.java:48)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065)
> at
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
> at
> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185)
> at
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
> at
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689)
> at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391)
> at
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:146)
> at
> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
> at
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
> at org.mortbay.jetty.Server.handle(Server.java:285)
> at
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:457)
> at
> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:765)
>
[jira] Created: (EXTSCRIPT-36) NPE in when clicking button in myfaces 1.2 example
NPE in when clicking button in myfaces 1.2 example
--
Key: EXTSCRIPT-36
URL: https://issues.apache.org/jira/browse/EXTSCRIPT-36
Project: MyFaces Extensions Scripting
Issue Type: Bug
Reporter: Jan-Kees van Andel
Assignee: Werner Punz
When I enter some data in the upper input field in the MF 1.2 example, I get
the following NPE:
javax.faces.FacesException: Exception while validating component with path :
{Component-Path : [Class: javax.faces.component.UIViewRoot,ViewId:
/helloWorld.xhtml][Class: javax.faces.component.html.HtmlForm,Id: form][Class:
javax.faces.component.html.HtmlPanelGrid,Id: grid][Class:
javax.faces.component.html.HtmlInputText,Id: input1]}
at javax.faces.component.UIInput.validate(UIInput.java:421)
at javax.faces.component.UIInput.processValidators(UIInput.java:186)
at
javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:726)
at javax.faces.component.UIForm.processValidators(UIForm.java:82)
at
javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:726)
at javax.faces.component.UIViewRoot.access$101(UIViewRoot.java:62)
at javax.faces.component.UIViewRoot$2.process(UIViewRoot.java:133)
at javax.faces.component.UIViewRoot.process(UIViewRoot.java:260)
at
javax.faces.component.UIViewRoot.processValidators(UIViewRoot.java:129)
at
org.apache.myfaces.lifecycle.ProcessValidationsExecutor.execute(ProcessValidationsExecutor.java:32)
at
org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103)
at
org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76)
at
org.apache.myfaces.scripting.jsf.dynamicdecorators.implemetations.LifefcycleProxy.execute(LifefcycleProxy.java:60)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:178)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1074)
at
org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:147)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065)
at
org.apache.myfaces.scripting.servlet.ScriptingServletFilter.doFilter(ScriptingServletFilter.java:48)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:146)
at
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:285)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:457)
at
org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:765)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:628)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:357)
at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:329)
at
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)
Caused by: java.lang.NullPointerException
at
org.apache.myfaces.scripting.core.CoreWeaver.reloadScriptingClass(CoreWeaver.java:70)
at
org.apache.myfaces.scripting.core.MethodLevelReloadingHandler.reloadInvoke(MethodLevelReloadingHandler.java:87)
at
org.apache.myfaces.scripting.core.MethodLevelReloadingHandler.invoke(MethodLevelReloadingHandler.java:65)
at $Proxy6.validate(Unknown Source)
at
javax.faces.component._ComponentUtils.callValidators(_ComponentUtils.java:159)
at javax.faces.component.UIInput.validateValue(UIInput.java:357)
at javax.faces.component.UIInput.validate(UIInput.java:405)
... 35 more
The debugger says that aclass is null.
Since this statement is only for debugging, I assume the quick fix is simple.
Don't know the impact on the rest of the codebase...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (EXTSCRIPT-27) myfaces 1.2. example doesn't run on Windoze...
[ https://issues.apache.org/jira/browse/EXTSCRIPT-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789942#action_12789942 ] Jan-Kees van Andel commented on EXTSCRIPT-27: - I think I found the problem. On line 139 in GroovyWeaver.groovy, I see the following line: WeavingContext.getRefreshContext().setRecompileRecommended(ScriptingConst.ENGINE_TYPE_JAVA, Boolean.FALSE); If I change it into: WeavingContext.getRefreshContext().setRecompileRecommended(ScriptingConst.ENGINE_TYPE_GROOVY, Boolean.FALSE); ...the MyFaces 1.2 example works. I can commit it, as well as the other fix for EXTSCRIPT-27, but since I don't completely oversee the ext-scripting architecture, I thought I'll ask before doing anything. ;-) It looks like a bug. The MyFaces 2.0 example already works, because of the IntialScanAnnotationListener that's being invoked by MyFaces 2.0. The Spring example also didn't work, but I've changed the dependencies in the pom to be the same as in the MyFaces 1.2 pom. I didn't put much effort into it, but this is what I did: - add core-java6 - add myfaces12-extensions - remove the SNAPSHOT from the myfaces dependencies > myfaces 1.2. example doesn't run on Windoze... > -- > > Key: EXTSCRIPT-27 > URL: https://issues.apache.org/jira/browse/EXTSCRIPT-27 > Project: MyFaces Extensions Scripting > Issue Type: Bug >Reporter: Matthias Weßendorf >Assignee: Werner Punz > > 2009-12-05 13:46:20.312::WARN: Error starting handlers > java.lang.ExceptionInInitializerError > at > org.apache.myfaces.shared_impl.webapp.webxml.WebXml.init(WebXml.java:243) > at > org.apache.myfaces.shared_impl.webapp.webxml.WebXml.getWebXml(WebXml.java:228) > at > org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:74) > at > org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:139) > at > org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:511) > at org.mortbay.jetty.servlet.Context.startContext(Context.java:135) > at > org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1191) > at > org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:481) > at > org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:434) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) > at > org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147) > at > org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:120) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) > at > org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) > at > org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:117) > at org.mortbay.jetty.Server.doStart(Server.java:210) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) > at > org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:134) > at > org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:332) > at > org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:277) > at > org.mortbay.jetty.plugin.AbstractJettyRunMojo.execute(AbstractJettyRunMojo.java:195) > at > org.mortbay.jetty.plugin.Jetty6RunMojo.execute(Jetty6RunMojo.java:183) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:453) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:513) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:483) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:301) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > su
[jira] Resolved: (MYFACES-2386) Refactor Bean Validation "constants" to package-private class
[ https://issues.apache.org/jira/browse/MYFACES-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan-Kees van Andel resolved MYFACES-2386. - Resolution: Fixed Fix Version/s: 2.0.0-alpha Fixed, but not with an implementation I'm very proud of. I think the specification needs to standardize this class, so we can make it public and avoid code duplication. > Refactor Bean Validation "constants" to package-private class > - > > Key: MYFACES-2386 > URL: https://issues.apache.org/jira/browse/MYFACES-2386 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314 >Affects Versions: 2.0.0-alpha >Reporter: Jan-Kees van Andel >Assignee: Jan-Kees van Andel > Fix For: 2.0.0-alpha > > > Matthias pointed me to a TCK issue in the Bean Validation related classes > (BeanValidator, UIInput). > I've created some public static final booleans, used to determine @startup > whether Bean Validation and Unified EL are available. > The reason to declare them as public was because they are shared between the > "javax.faces.component" and "javax.faces.bean" packages, but it will probably > cause TCK failures. > Solution: Refactor the environment related "constants" to a package-private > class that exists in all necessary packages. This class might delegate the > plumbing to the IMPL to prevent code duplication. > See the issue on the mailing list: > http://www.nabble.com/-JSF-2.0--JSR-303-support-in-MyFaces-2.0-td25969477.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2386) Refactor Bean Validation "constants" to package-private class
Refactor Bean Validation "constants" to package-private class - Key: MYFACES-2386 URL: https://issues.apache.org/jira/browse/MYFACES-2386 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Jan-Kees van Andel Matthias pointed me to a TCK issue in the Bean Validation related classes (BeanValidator, UIInput). I've created some public static final booleans, used to determine @startup whether Bean Validation and Unified EL are available. The reason to declare them as public was because they are shared between the "javax.faces.component" and "javax.faces.bean" packages, but it will probably cause TCK failures. Solution: Refactor the environment related "constants" to a package-private class that exists in all necessary packages. This class might delegate the plumbing to the IMPL to prevent code duplication. See the issue on the mailing list: http://www.nabble.com/-JSF-2.0--JSR-303-support-in-MyFaces-2.0-td25969477.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2378) Use java util logging on 2.0.x branch
[ https://issues.apache.org/jira/browse/MYFACES-2378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12764146#action_12764146 ] Jan-Kees van Andel commented on MYFACES-2378: - I agree with Leonardo. I think this is also the least surprising thing to do from a user's perspective, since most loggers use the FQCN as key. > Use java util logging on 2.0.x branch > - > > Key: MYFACES-2378 > URL: https://issues.apache.org/jira/browse/MYFACES-2378 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Attachments: MYFACES-2378-core.patch, MYFACES-2378-shared-core.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-1951) Update UIInput.validate()
[ https://issues.apache.org/jira/browse/MYFACES-1951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan-Kees van Andel resolved MYFACES-1951. - Resolution: Fixed Fix Version/s: 2.0.0-alpha Fixed > Update UIInput.validate() > - > > Key: MYFACES-1951 > URL: https://issues.apache.org/jira/browse/MYFACES-1951 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Affects Versions: 2.0.0-alpha >Reporter: Matthias Weßendorf >Assignee: Jan-Kees van Andel > Fix For: 2.0.0-alpha > > > The algorithm for UIInput.validate() was changed, due to this spec issue: > https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=323 > See JavaDoc on validate() for details on the change: > https://javaserverfaces-spec-public.dev.java.net/nonav/issues/showattachment.cgi/133/UIInput.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2272) Apply changes related to UIInput.validateValue and UIInput.VALIDATE_EMPTY_FIELDS_PARAM_NAME
[ https://issues.apache.org/jira/browse/MYFACES-2272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan-Kees van Andel resolved MYFACES-2272. - Resolution: Fixed Fix Version/s: 2.0.0-alpha I think I've implemented it completely. I've added the code to check for the init-param and the code to check for the existence of Bean Validation. That should be it... > Apply changes related to UIInput.validateValue and > UIInput.VALIDATE_EMPTY_FIELDS_PARAM_NAME > --- > > Key: MYFACES-2272 > URL: https://issues.apache.org/jira/browse/MYFACES-2272 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Reporter: Leonardo Uribe >Assignee: Jan-Kees van Andel > Fix For: 2.0.0-alpha > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2302) Get simple 2.0 app working
[ https://issues.apache.org/jira/browse/MYFACES-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12738324#action_12738324 ] Jan-Kees van Andel commented on MYFACES-2302: - Can you also test the annotations (like: @ManagedBean)? I've committed some bugfixes last weekend to get the annotations working, but it's possible that I wasn't complete (I encountered these bugs while I was working on something else). > Get simple 2.0 app working > -- > > Key: MYFACES-2302 > URL: https://issues.apache.org/jira/browse/MYFACES-2302 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Affects Versions: 2.0.0-alpha >Reporter: Curtiss Howard > > As a first attempt in getting the Facelets code work, I will try to get the > "Guess number 2.0" app working. This app tests resources and custom Facelets > taglibs, so this should be a good way to tie together and fix all the code > that's gone in so far. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2301) Support for default Validators in Builder Plugin
Support for default Validators in Builder Plugin Key: MYFACES-2301 URL: https://issues.apache.org/jira/browse/MYFACES-2301 Project: MyFaces Core Issue Type: New Feature Components: build process Reporter: Jan-Kees van Andel The javax.faces.Bean Validator is a "default" Validator. The concept of default Validators, however, is not supported in the MyFaces Builder Plugin. I think it will be useful to add support for default Validators to the builder plugin. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2280) ValidatorException should support collections of messages.
[ https://issues.apache.org/jira/browse/MYFACES-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan-Kees van Andel resolved MYFACES-2280. - Resolution: Fixed Fix Version/s: 2.0.0-alpha Mike Concini already did the heavy plumbing in MYFACES-2294, so we can close this issue. > ValidatorException should support collections of messages. > -- > > Key: MYFACES-2280 > URL: https://issues.apache.org/jira/browse/MYFACES-2280 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Reporter: Leonardo Uribe >Assignee: Jan-Kees van Andel > Fix For: 2.0.0-alpha > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2296) Annotation scanning bugs
[ https://issues.apache.org/jira/browse/MYFACES-2296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan-Kees van Andel resolved MYFACES-2296. - Resolution: Fixed Fix Version/s: 2.0.0-alpha This fix works with my test webapp. I've checked the ClassFile Specification. It should now work for others too. > Annotation scanning bugs > > > Key: MYFACES-2296 > URL: https://issues.apache.org/jira/browse/MYFACES-2296 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314 >Reporter: Jan-Kees van Andel >Assignee: Jan-Kees van Andel > Fix For: 2.0.0-alpha > > > Some bugs in the annotation code causes my test program to fail. > - Some bytecode scanning bugs > - Annotations not retention = RUNTIME > - Annotations to scan are org/myfaces, not javax/faces > Already created a fix for the listed issues. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2296) Annotation scanning bugs
Annotation scanning bugs Key: MYFACES-2296 URL: https://issues.apache.org/jira/browse/MYFACES-2296 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Reporter: Jan-Kees van Andel Assignee: Jan-Kees van Andel Some bugs in the annotation code causes my test program to fail. - Some bytecode scanning bugs - Annotations not retention = RUNTIME - Annotations to scan are org/myfaces, not javax/faces Already created a fix for the listed issues. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2280) ValidatorException should support collections of messages.
[ https://issues.apache.org/jira/browse/MYFACES-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12731060#action_12731060 ] Jan-Kees van Andel commented on MYFACES-2280: - I can pick this up as part of implementing Bean Validation. > ValidatorException should support collections of messages. > -- > > Key: MYFACES-2280 > URL: https://issues.apache.org/jira/browse/MYFACES-2280 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Reporter: Leonardo Uribe >Assignee: Jan-Kees van Andel > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2288) Implement Bean Validation
Implement Bean Validation - Key: MYFACES-2288 URL: https://issues.apache.org/jira/browse/MYFACES-2288 Project: MyFaces Core Issue Type: New Feature Components: JSR-314 Reporter: Jan-Kees van Andel Assignee: Jan-Kees van Andel Implement BeanValidator class, corresponding tags/configs and logic related to Bean Validation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2272) Apply changes related to UIInput.validateValue and UIInput.VALIDATE_EMPTY_FIELDS_PARAM_NAME
[ https://issues.apache.org/jira/browse/MYFACES-2272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12730984#action_12730984 ] Jan-Kees van Andel commented on MYFACES-2272: - Already working on it as part of MYFACES-1951. > Apply changes related to UIInput.validateValue and > UIInput.VALIDATE_EMPTY_FIELDS_PARAM_NAME > --- > > Key: MYFACES-2272 > URL: https://issues.apache.org/jira/browse/MYFACES-2272 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Reporter: Leonardo Uribe >Assignee: Jan-Kees van Andel > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2098) Add RegexValidator class
[ https://issues.apache.org/jira/browse/MYFACES-2098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan-Kees van Andel updated MYFACES-2098: Resolution: Fixed Fix Version/s: 2.0.0-alpha Status: Resolved (was: Patch Available) This one should be completely implemented > Add RegexValidator class > > > Key: MYFACES-2098 > URL: https://issues.apache.org/jira/browse/MYFACES-2098 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Affects Versions: 2.0.0-alpha >Reporter: Jan-Kees van Andel >Assignee: Jan-Kees van Andel >Priority: Minor > Fix For: 2.0.0-alpha > > Attachments: RegexValidator.patch, RegexValidator_2.patch > > > The JSF 2.0 spec specifies one new Validator: the RegexValidator which > validates a string value against a java.util.regex Regular Expression. > A.t.m. it doesn't exist yet. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2140) Add annotation processing logic
[ https://issues.apache.org/jira/browse/MYFACES-2140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12688010#action_12688010 ] Jan-Kees van Andel commented on MYFACES-2140: - +1 It sounds like a good plan Leonardo. This change was a first attempt to split up the FacesConfigurator class into some smaller and more manageable bits, but you're right that the structure doesn't support everything it should support. I also noticed the problem, but I was (and I am now) unable to fix it because I'm lacking the free time. It's extremely busy at work (working long hours to reach an impossible deadline). So yeah, I'm very happy if you can help out on this one. Thanks. > Add annotation processing logic > --- > > Key: MYFACES-2140 > URL: https://issues.apache.org/jira/browse/MYFACES-2140 > Project: MyFaces Core > Issue Type: New Feature > Components: JSR-314 >Reporter: Jan-Kees van Andel > Attachments: ManagedBean.patch, ManagedBeanAnnotationProcessor.patch > > > JSF 2.0 specifies the use of the following annotations for Managed Bean > configuration: > - ManagedBean > - ManagedBeans > - ManagedProperty > - RequestScoped > - SessionScoped > - ViewScoped > - ApplicationScoped > - NoneScoped > The annotations are already there, it now needs processing logic. > I'm on it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2162) Default RenderKitId should be HTML_BASIC when using annotations
Default RenderKitId should be HTML_BASIC when using annotations --- Key: MYFACES-2162 URL: https://issues.apache.org/jira/browse/MYFACES-2162 Project: MyFaces Core Issue Type: New Feature Components: JSR-314 Reporter: Jan-Kees van Andel Priority: Minor A.t.m. the default RenderKit is "", but it should be "HTML_BASIC". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2140) Add annotation processing logic
[ https://issues.apache.org/jira/browse/MYFACES-2140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan-Kees van Andel updated MYFACES-2140: Status: Patch Available (was: Open) > Add annotation processing logic > --- > > Key: MYFACES-2140 > URL: https://issues.apache.org/jira/browse/MYFACES-2140 > Project: MyFaces Core > Issue Type: New Feature > Components: JSR-314 >Reporter: Jan-Kees van Andel > > JSF 2.0 specifies the use of the following annotations for Managed Bean > configuration: > - ManagedBean > - ManagedBeans > - ManagedProperty > - RequestScoped > - SessionScoped > - ViewScoped > - ApplicationScoped > - NoneScoped > The annotations are already there, it now needs processing logic. > I'm on 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-2147) NoSuchMethodException when instantiating SystemEvent objects
[ https://issues.apache.org/jira/browse/MYFACES-2147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan-Kees van Andel updated MYFACES-2147: Status: Patch Available (was: Open) > NoSuchMethodException when instantiating SystemEvent objects > > > Key: MYFACES-2147 > URL: https://issues.apache.org/jira/browse/MYFACES-2147 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314 >Affects Versions: 2.0.0-alpha >Reporter: Jan-Kees van Andel > > This error occurs when rendering an arbitrary page. > It is caused by the Class.getConstructor(Class) not being aware of subclasses. > SystemEvent has a constructor with one parameter of type Object, but > different subclasses have different constructors. > Caused by: java.lang.NoSuchMethodException: > javax.faces.event.AfterAddToParentEvent.(java.lang.Object) > at java.lang.Class.getConstructor0(Class.java:2706) > at java.lang.Class.getConstructor(Class.java:1657) > at > org.apache.myfaces.application.ApplicationImpl._createEvent(ApplicationImpl.java:1292) > at > org.apache.myfaces.application.ApplicationImpl._traverseListenerList(ApplicationImpl.java:1484) > at > org.apache.myfaces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:437) > at > org.apache.myfaces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:459) > at > org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:118) > at > org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:121) > at > org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:80) > at > javax.faces.webapp.FacesServlet._handleStandardRequest(FacesServlet.java:423) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2147) NoSuchMethodException when instantiating SystemEvent objects
NoSuchMethodException when instantiating SystemEvent objects Key: MYFACES-2147 URL: https://issues.apache.org/jira/browse/MYFACES-2147 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Jan-Kees van Andel This error occurs when rendering an arbitrary page. It is caused by the Class.getConstructor(Class) not being aware of subclasses. SystemEvent has a constructor with one parameter of type Object, but different subclasses have different constructors. Caused by: java.lang.NoSuchMethodException: javax.faces.event.AfterAddToParentEvent.(java.lang.Object) at java.lang.Class.getConstructor0(Class.java:2706) at java.lang.Class.getConstructor(Class.java:1657) at org.apache.myfaces.application.ApplicationImpl._createEvent(ApplicationImpl.java:1292) at org.apache.myfaces.application.ApplicationImpl._traverseListenerList(ApplicationImpl.java:1484) at org.apache.myfaces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:437) at org.apache.myfaces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:459) at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:118) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:121) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:80) at javax.faces.webapp.FacesServlet._handleStandardRequest(FacesServlet.java:423) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2146) Bug in UIViewRoot causes Exception in popComponentFromEL()
Bug in UIViewRoot causes Exception in popComponentFromEL() -- Key: MYFACES-2146 URL: https://issues.apache.org/jira/browse/MYFACES-2146 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Jan-Kees van Andel UIViewRoot.encodeBegin() is missing a code path. Because of this, the UIViewRoot instance is not added to the current component stack. This causes an exception in UIComponent.popComponentFromEL(), because pop is being called on an empty stack. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2146) Bug in UIViewRoot causes Exception in popComponentFromEL()
[ https://issues.apache.org/jira/browse/MYFACES-2146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan-Kees van Andel updated MYFACES-2146: Status: Patch Available (was: Open) > Bug in UIViewRoot causes Exception in popComponentFromEL() > -- > > Key: MYFACES-2146 > URL: https://issues.apache.org/jira/browse/MYFACES-2146 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314 >Affects Versions: 2.0.0-alpha >Reporter: Jan-Kees van Andel > > UIViewRoot.encodeBegin() is missing a code path. > Because of this, the UIViewRoot instance is not added to the current > component stack. > This causes an exception in UIComponent.popComponentFromEL(), because pop is > being called on an empty stack. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2142) ClassCastException in JspViewHandlerImpl: ResponseSwitch != HttpServletResponse
ClassCastException in JspViewHandlerImpl: ResponseSwitch != HttpServletResponse --- Key: MYFACES-2142 URL: https://issues.apache.org/jira/browse/MYFACES-2142 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Reporter: Jan-Kees van Andel While running the latest myfaces2 source code with a test JSP page, I've encountered the following error. java.lang.ClassCastException: org.apache.myfaces.context.servlet.ResponseSwitch cannot be cast to javax.servlet.http.HttpServletResponse at org.apache.myfaces.application.jsp.JspViewHandlerImpl.buildView(JspViewHandlerImpl.java:487) at org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:343) at org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:45) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:167) at javax.faces.webapp.FacesServlet._handleStandardRequest(FacesServlet.java:428) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:182) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) etc.. As far as I can see, this is a bug, since there is an explicit cast to HttpServletResponse and the given parameter is of type ResponseSwitch, which is not a HttpServletResponse. It looks like a recent change... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2140) Add annotation processing logic
[ https://issues.apache.org/jira/browse/MYFACES-2140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12667360#action_12667360 ] Jan-Kees van Andel commented on MYFACES-2140: - My first implementation will use x-finder, along with it's ASM dependencies, just to get the feature in quite fast. Improvements can be made later (optimizations in the classpath scanning algorithm or a cleaner, more OO, implementation). See: http://www.nabble.com/Scanning-for-annotated-classes-in-MyFaces-2-to21318418.html#a21318418 > Add annotation processing logic > --- > > Key: MYFACES-2140 > URL: https://issues.apache.org/jira/browse/MYFACES-2140 > Project: MyFaces Core > Issue Type: New Feature > Components: JSR-314 >Reporter: Jan-Kees van Andel > > JSF 2.0 specifies the use of the following annotations for Managed Bean > configuration: > - ManagedBean > - ManagedBeans > - ManagedProperty > - RequestScoped > - SessionScoped > - ViewScoped > - ApplicationScoped > - NoneScoped > The annotations are already there, it now needs processing logic. > I'm on it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2140) Add annotation processing logic
Add annotation processing logic --- Key: MYFACES-2140 URL: https://issues.apache.org/jira/browse/MYFACES-2140 Project: MyFaces Core Issue Type: New Feature Components: JSR-314 Reporter: Jan-Kees van Andel JSF 2.0 specifies the use of the following annotations for Managed Bean configuration: - ManagedBean - ManagedBeans - ManagedProperty - RequestScoped - SessionScoped - ViewScoped - ApplicationScoped - NoneScoped The annotations are already there, it now needs processing logic. I'm on 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-2131) Import to internal Sun class
[ https://issues.apache.org/jira/browse/MYFACES-2131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan-Kees van Andel updated MYFACES-2131: Status: Patch Available (was: Open) > Import to internal Sun class > > > Key: MYFACES-2131 > URL: https://issues.apache.org/jira/browse/MYFACES-2131 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314 >Affects Versions: 2.0.0-alpha >Reporter: Jan-Kees van Andel >Priority: Minor > > In org.apache.myfaces.context.servlet.FacesContextImpl, there is an import to > import sun.misc.Regexp. > The error in my IDE: > Access restriction: The type Regexp is not accessible due to restriction on > required library D:\dev\Java\jdk1.6.0_10\jre\lib\rt.jar > It is not used, however, so removing it should be no problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2131) Import to internal Sun class
Import to internal Sun class Key: MYFACES-2131 URL: https://issues.apache.org/jira/browse/MYFACES-2131 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Jan-Kees van Andel Priority: Minor In org.apache.myfaces.context.servlet.FacesContextImpl, there is an import to import sun.misc.Regexp. The error in my IDE: Access restriction: The type Regexp is not accessible due to restriction on required library D:\dev\Java\jdk1.6.0_10\jre\lib\rt.jar It is not used, however, so removing it should be no problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2088) Add ExceptionHandler class
[ https://issues.apache.org/jira/browse/MYFACES-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12656282#action_12656282 ] Jan-Kees van Andel commented on MYFACES-2088: - Deleted patch, because of possible license issues. @Leonardo: Check http://www.nabble.com/JSF-2---ExceptionHandlerWrapper-seems-to-be-missing-a-method-td20747896.html > Add ExceptionHandler class > -- > > Key: MYFACES-2088 > URL: https://issues.apache.org/jira/browse/MYFACES-2088 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Affects Versions: 2.0.0-alpha >Reporter: Jan-Kees van Andel >Assignee: Leonardo Uribe >Priority: Minor > Fix For: 2.0.0-alpha > > > The spec specifies the ExceptionHandler class, which is the central point of > error handling in a JSF implementation. > It also specifies two accompanying files: ExceptionHandlerFactory and > ExceptionHandlerWrapper. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2097) Add RenderKitWrapper class
[ https://issues.apache.org/jira/browse/MYFACES-2097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12656281#action_12656281 ] Jan-Kees van Andel commented on MYFACES-2097: - Deleted patch, because of possible license issues. > Add RenderKitWrapper class > -- > > Key: MYFACES-2097 > URL: https://issues.apache.org/jira/browse/MYFACES-2097 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Affects Versions: 2.0.0-alpha >Reporter: Jan-Kees van Andel >Priority: Minor > > The spec specifies a class RenderKitWrapper, a wrapper for RenderKit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2095) Add managed bean scope annotations
[ https://issues.apache.org/jira/browse/MYFACES-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12656279#action_12656279 ] Jan-Kees van Andel commented on MYFACES-2095: - Deleted patch, because of possible license issues > Add managed bean scope annotations > -- > > Key: MYFACES-2095 > URL: https://issues.apache.org/jira/browse/MYFACES-2095 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Affects Versions: 2.0.0-alpha >Reporter: Jan-Kees van Andel >Priority: Minor > > JSF 2.0 specifies 5 annotations that can be used to configure a managed bean > scope: > - ApplicationScoped > - SessionScoped > - ViewScoped > - RequestScoped > - NoneScoped > A.t.m. those annotations are missing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2094) Add InitialStateEvent class
[ https://issues.apache.org/jira/browse/MYFACES-2094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12656280#action_12656280 ] Jan-Kees van Andel commented on MYFACES-2094: - Deleted patch, because of possible license issues. > Add InitialStateEvent class > --- > > Key: MYFACES-2094 > URL: https://issues.apache.org/jira/browse/MYFACES-2094 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Affects Versions: 2.0.0-alpha >Reporter: Jan-Kees van Andel >Priority: Minor > > JSF 2.0 EDR2 specifies some new event types, like InitialStateEvent. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2098) Add RegexValidator class
[ https://issues.apache.org/jira/browse/MYFACES-2098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12656273#action_12656273 ] Jan-Kees van Andel commented on MYFACES-2098: - I'm gonna look at the Trinidad Validator and try to create a best of both world thing. > Add RegexValidator class > > > Key: MYFACES-2098 > URL: https://issues.apache.org/jira/browse/MYFACES-2098 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Affects Versions: 2.0.0-alpha >Reporter: Jan-Kees van Andel >Priority: Minor > Attachments: RegexValidator.patch > > > The JSF 2.0 spec specifies one new Validator: the RegexValidator which > validates a string value against a java.util.regex Regular Expression. > A.t.m. it doesn't exist yet. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2096) Make DataModel types generic
[ https://issues.apache.org/jira/browse/MYFACES-2096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12656272#action_12656272 ] Jan-Kees van Andel commented on MYFACES-2096: - That's okay. I'll look at it this weekend. > Make DataModel types generic > > > Key: MYFACES-2096 > URL: https://issues.apache.org/jira/browse/MYFACES-2096 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Affects Versions: 2.0.0-alpha >Reporter: Jan-Kees van Andel >Priority: Minor > Attachments: GenericDataModels.patch > > > According to the spec, DataModel and its subclasses must be generic. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2083) FacesContext contains several unnecessary methods
[ https://issues.apache.org/jira/browse/MYFACES-2083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652313#action_12652313 ] Jan-Kees van Andel commented on MYFACES-2083: - I think it was added in EDR 2, since I downloaded the latest JavaDocs from the JSR 314 site. The JavaDocs specified a PartialViewContext class, which is accessible from FacesContext#getPartialViewContext(). This method (creates and) returns the PartialViewContext for this request. > FacesContext contains several unnecessary methods > - > > Key: MYFACES-2083 > URL: https://issues.apache.org/jira/browse/MYFACES-2083 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314 >Affects Versions: 2.0.0-alpha >Reporter: Jan-Kees van Andel > Attachments: FacesContext20.patch > > > Several fields and methods are currently put in FacesContext, but should > (according to the JSF 2.0 spec) be placed inside another class: > PartialViewContext. > They are: > public static final String NO_PARTIAL_PHASE_CLIENT_IDS = "none"; > public static final String PARTIAL_EXECUTE_PARAM_NAME = > "javax.faces.partial.execute"; > public static final String PARTIAL_RENDER_PARAM_NAME = > "javax.faces.partial.render"; > public List getExecutePhaseClientIds() > public ResponseWriter getPartialResponseWriter() > public List getRenderPhaseClientIds() > public void setExecutePhaseClientIds(List executePhaseClientIds) > public void setRenderAll(boolean renderAll) > public void setRenderPhaseClientIds(List renderPhaseClientIds) > public boolean isAjaxRequest() > public boolean isExecuteNone() > public boolean isPostback() > public boolean isRenderAll() > public boolean isRenderNone() -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2098) Add RegexValidator class
[ https://issues.apache.org/jira/browse/MYFACES-2098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652003#action_12652003 ] Jan-Kees van Andel commented on MYFACES-2098: - I didn't know about a Trinidad regex Validator. I've created it from scratch. Didn't look for any Validator code on the internet, because I wanted to make sure it was JSF 2.0 compliant. > Add RegexValidator class > > > Key: MYFACES-2098 > URL: https://issues.apache.org/jira/browse/MYFACES-2098 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Affects Versions: 2.0.0-alpha >Reporter: Jan-Kees van Andel >Priority: Minor > Attachments: RegexValidator.patch > > > The JSF 2.0 spec specifies one new Validator: the RegexValidator which > validates a string value against a java.util.regex Regular Expression. > A.t.m. it doesn't exist yet. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2098) Add RegexValidator class
[ https://issues.apache.org/jira/browse/MYFACES-2098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan-Kees van Andel updated MYFACES-2098: Status: Patch Available (was: Open) > Add RegexValidator class > > > Key: MYFACES-2098 > URL: https://issues.apache.org/jira/browse/MYFACES-2098 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Affects Versions: 2.0.0-alpha >Reporter: Jan-Kees van Andel >Priority: Minor > > The JSF 2.0 spec specifies one new Validator: the RegexValidator which > validates a string value against a java.util.regex Regular Expression. > A.t.m. it doesn't exist yet. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2098) Add RegexValidator class
Add RegexValidator class Key: MYFACES-2098 URL: https://issues.apache.org/jira/browse/MYFACES-2098 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Jan-Kees van Andel Priority: Minor The JSF 2.0 spec specifies one new Validator: the RegexValidator which validates a string value against a java.util.regex Regular Expression. A.t.m. it doesn't exist yet. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
