[jira] Commented: (OWB-408) NPE in WebBeansELResolver
[ https://issues.apache.org/jira/browse/OWB-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12890566#action_12890566 ] Gurkan Erdogdu commented on OWB-408: What others think about? Joe Bergmark WDYT? > NPE in WebBeansELResolver > - > > Key: OWB-408 > URL: https://issues.apache.org/jira/browse/OWB-408 > Project: OpenWebBeans > Issue Type: Bug >Reporter: Gerhard Petracek >Assignee: Gurkan Erdogdu > Attachments: OWB-408.patch > > > OwbElContextListener gets called in combination with myfaces-core but it's > ignored in combination with mojarra (tested with mojarra 2). > that leads to a NPE in WebBeansELResolver (there is no instance of > ELContextStore) > even though it looks like an issue of mojarra it would be nice to have a > fallback or a completely different solution for it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OWB-408) NPE in WebBeansELResolver
[ https://issues.apache.org/jira/browse/OWB-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12890565#action_12890565 ] Gurkan Erdogdu commented on OWB-408: Actually, JSF implementation must set ELContextStrore#ThreadLocal instance using OwbElContextListener. JSF specification says that after creating of ELContext, it must call all ELContext listeners. I think that this is not OWB fault! But your patch prevent NullPointerException with guarding condition on destroy. Altough it prevents the exception, causes are still there, because dependent beans must be destroyed at the end of EL evaulation! Therefore I will mark this issue as INVALID > NPE in WebBeansELResolver > - > > Key: OWB-408 > URL: https://issues.apache.org/jira/browse/OWB-408 > Project: OpenWebBeans > Issue Type: Bug >Reporter: Gerhard Petracek >Assignee: Gurkan Erdogdu > Attachments: OWB-408.patch > > > OwbElContextListener gets called in combination with myfaces-core but it's > ignored in combination with mojarra (tested with mojarra 2). > that leads to a NPE in WebBeansELResolver (there is no instance of > ELContextStore) > even though it looks like an issue of mojarra it would be nice to have a > fallback or a completely different solution for it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OWB-407) detailed information about exceptions
[ https://issues.apache.org/jira/browse/OWB-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12890564#action_12890564 ] Gurkan Erdogdu commented on OWB-407: Patches look good, I will try to commit evening. > detailed information about exceptions > - > > Key: OWB-407 > URL: https://issues.apache.org/jira/browse/OWB-407 > Project: OpenWebBeans > Issue Type: Improvement >Reporter: Gerhard Petracek >Assignee: Gurkan Erdogdu > Attachments: OWB-407_first_draft.patch, > OWB-407_first_draft_(style_2).patch > > > owb should provide more information in case of invalid constellations. > e.g. UnproxyableResolutionException shows way to few information about the > real problem. all required information would be available (in this case in > WebBeansUtil#checkUnproxiableApiType). > detailed information about exceptions would help a lot during dev.-time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OWB-407) detailed information about exceptions
[ https://issues.apache.org/jira/browse/OWB-407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated OWB-407: - Attachment: OWB-407_first_draft_(style_2).patch > detailed information about exceptions > - > > Key: OWB-407 > URL: https://issues.apache.org/jira/browse/OWB-407 > Project: OpenWebBeans > Issue Type: Improvement >Reporter: Gerhard Petracek >Assignee: Gurkan Erdogdu > Attachments: OWB-407_first_draft.patch, > OWB-407_first_draft_(style_2).patch > > > owb should provide more information in case of invalid constellations. > e.g. UnproxyableResolutionException shows way to few information about the > real problem. all required information would be available (in this case in > WebBeansUtil#checkUnproxiableApiType). > detailed information about exceptions would help a lot during dev.-time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OWB-407) detailed information about exceptions
[ https://issues.apache.org/jira/browse/OWB-407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated OWB-407: - Attachment: OWB-407_first_draft.patch here is the first part as draft. if this version is ok for you, i'll continue > detailed information about exceptions > - > > Key: OWB-407 > URL: https://issues.apache.org/jira/browse/OWB-407 > Project: OpenWebBeans > Issue Type: Improvement >Reporter: Gerhard Petracek >Assignee: Gurkan Erdogdu > Attachments: OWB-407_first_draft.patch > > > owb should provide more information in case of invalid constellations. > e.g. UnproxyableResolutionException shows way to few information about the > real problem. all required information would be available (in this case in > WebBeansUtil#checkUnproxiableApiType). > detailed information about exceptions would help a lot during dev.-time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OWB-408) NPE in WebBeansELResolver
[ https://issues.apache.org/jira/browse/OWB-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated OWB-408: - Attachment: OWB-408.patch this patch would solve the issue. if there was a reason for the public field, we have to check all the details. > NPE in WebBeansELResolver > - > > Key: OWB-408 > URL: https://issues.apache.org/jira/browse/OWB-408 > Project: OpenWebBeans > Issue Type: Bug >Reporter: Gerhard Petracek >Assignee: Gurkan Erdogdu > Attachments: OWB-408.patch > > > OwbElContextListener gets called in combination with myfaces-core but it's > ignored in combination with mojarra (tested with mojarra 2). > that leads to a NPE in WebBeansELResolver (there is no instance of > ELContextStore) > even though it looks like an issue of mojarra it would be nice to have a > fallback or a completely different solution for it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (OWB-406) BaseEjbBean.removedStatefulInstance used by multiple instances/EjbBeanProxyHandlers
[ https://issues.apache.org/jira/browse/OWB-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Covener reassigned OWB-406: Assignee: Eric Covener (was: Gurkan Erdogdu) self-assigning, this ended up dovetailing into some related work > BaseEjbBean.removedStatefulInstance used by multiple > instances/EjbBeanProxyHandlers > --- > > Key: OWB-406 > URL: https://issues.apache.org/jira/browse/OWB-406 > Project: OpenWebBeans > Issue Type: Bug > Components: Enterprise Web Beans >Affects Versions: 1.0.0-alpha-1 > Environment: OWB + tomcat EJB integration >Reporter: Eric Covener >Assignee: Eric Covener > Original Estimate: 4h > Remaining Estimate: 4h > > BaseEjbBean.removedStatefulInstance is used by MethodHandlers to track when a > remove method on a session bean has been called, but there is only one one of > these Contextuals per bean class not per instance. > BaseEjbBean needs to manitain a map or the tracking needs to move into the > Method Handler (EjbBeanProxyHandler) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Fw: [ANNOUNCE] MyFaces Core v2.0.1 Release
Time to update and test our samples ;) LieGrue, strub - Forwarded Message > From: Leonardo Uribe > To: annou...@apache.org; annou...@myfaces.apache.org > Cc: d...@myfaces.apache.org; us...@myfaces.apache.org > Sent: Tue, July 20, 2010 4:19:19 AM > Subject: [ANNOUNCE] MyFaces Core v2.0.1 Release > > The Apache MyFaces team is pleased to announce the release of MyFaces Core >2.0.1. > > MyFaces Core is a JavaServer(tm) Faces 2.0 implementation as specified by >JSR-314. MyFaces Core has passed Sun's JSR-314 TCK and is 100% compliant with >the JSR-314 specification. > > MyFaces Core 2.0.1 is available in both binary and source distributions. > >* http://myfaces.apache.org/download.html > > MyFaces Core is also available in the central Maven repository under Group > ID >"org.apache.myfaces.core". > > Release Notes - MyFaces Core - Version 2.0.1 > Bug > >* [MYFACES-2463] - CLONE - violates the JSF spec >* [MYFACES-2569] - setResourceHandler, setViewHandler and setStateManager >must throw illegalStateException if called after at least one request has >been >processed by the Lifecycle instance >* [MYFACES-2640] - (JSF.js) Ajax Render component problem, replace with >whole fragment not one element. >* [MYFACES-2647] - MyFacesContainerInitializer doesn't check for null > class >name >* [MYFACES-2662] - setViewHandler(...) called from RESTORE_VIEW phase >listener throws illegalStateException >* [MYFACES-2663] - NPE in UIParameter when value resolves to null >* [MYFACES-2664] - need to attach a UIViewRoot to FacesContext during >startup/shutdown >* [MYFACES-2665] - Legacy ViewHandler doesn't work in back compatibility >mode for JSP pages >* [MYFACES-2666] - Getting a full-page-refresh when running JSF's Ajax on >the Trinidad 2 (trunk) >* [MYFACES-2667] - var values cause problems with ui:debug when creating >the debug component tree >* [MYFACES-2668] - Rendering HTML elements inside a script section > confuses >HtmlResponseWriterImpl >* [MYFACES-2669] - UIData.invokeOnComponent does not use >UINamingContainer.getSeparatorChar >* [MYFACES-2670] - Components on facets are not removed programatically > by >PSS algorithm > * [MYFACES-2671] - MYFACES-2633 regresses the ezcomp spinner example > * [MYFACES-2673] - Problems running with Java2 security on 2.0.0 >* [MYFACES-2675] - BeanValidation does not work with composite components >* [MYFACES-2678] - Problems with navigation case ordering >* [MYFACES-2681] - Duplicate ResourceHandler register on >DigesterFacesConfigUnmarshallerImpl >* [MYFACES-2682] - ResourceHandlerImpl.handleResourceRequest should call >createResource getting the top ResourceHandler >* [MYFACES-2683] - Event processing should be enabled when bindings are > set >with pss enabled >* [MYFACES-2684] - UIComponentBase.saveAttachedState save transient >elements as null values on List case >* [MYFACES-2685] - Cannot call invokeOnComponent on UIColumn without >rowIndex >* [MYFACES-2686] - javax.faces.FacesException: >java.lang.NumberFormatException while initializing if MANIFEST.MF version >exceeds int value >* [MYFACES-2692] - Hidden field "javax.faces.encodedURL" should be > rendered >at begin of h:form >* [MYFACES-2695] - Save and restore scope values and current count when >temporarily changing the current index of UIRepeat >* [MYFACES-2697] - BeanValidation class is annotated with @FacesValidator >tag >* [MYFACES-2699] - UIComponent.broadcast should propagate events to all >Behavior instances, not only to ClientBehavior >* [MYFACES-2700] - ajax usecase fails >* [MYFACES-2701] - jsf.getViewState(formElement) fails if it is called >outside of jsf.request >* [MYFACES-2704] - in not rendered properly >* [MYFACES-2705] - ClassCastException in HtmlAjaxBehaviorRenderer >* [MYFACES-2706] - Webkit auto eval issued one request too late >* [MYFACES-2707] - PPR auto eval fails on certain ie/dom structure >combinations >* [MYFACES-2708] - setAttributes body broken >* [MYFACES-2710] - Cannot call UIComponent.getCurrentComponent() from >UIComponent.restoreState() or UIComponent.saveState() >* [MYFACES-2711] - Application.createComponent(FacesContext,Resource) >register listeners twice and call createComponent(String) directly >* [MYFACES-2717] - c:if and c:forEach cause jsf.js not beeing rendered > when >navigating to another view >* [MYFACES-2718] - h:commandButton does not take into account params when >type="button" >* [MYFACES-2719] - faces-redirect=true lost the url parameters >* [MYFACES-2722] - can get class not found from BeanValidator >* [MYFACES-2724] - OutcomeTarget button and link should always add >navigation case parameters >* [MYFACES-2725] - OutcomeTarget button and link do not render fragment >* [MYFACES-2726
Re: Fwd: JCDI and Bean Validation TCKs
Having those parts public is for sure a save bet. Especially since I hope that Sun/Oracle now further follows this road ;) LieGrue, strub PS: the TCK NDA is on my stack, but this stack is atm flooded with daywork ;) - Original Message > From: David Blevins > To: dev@openwebbeans.apache.org > Sent: Tue, July 20, 2010 7:39:23 AM > Subject: Fwd: JCDI and Bean Validation TCKs > > If you have any thoughts, post 'em! :) > > Begin forwarded message: > > > Resent-From: > > From: David Blevins > > Date: July 19, 2010 9:44:53 PM PDT > > To: d...@geronimo.apache.org > > Subject: JCDI and Bean Validation TCKs > > Reply-To: d...@geronimo.apache.org > > > > Currently we have these setup in the private svn where the Java EE TCK >porting modules live. The JCDI and Bean Validation TCKs are public Apache >licensed, so we could move the porting modules for those two TCKs into our >public svn. > > > > The part of my brain that finds esthetic pleasure in filling cabinets > > likes >everything all organized in the one VM, but the part of me that likes to be >more public than private thinks it's unnecessarily restrictive to make people >sign the Sun/Apache NDA to get access to things not under that restriction. >Specifically, everyone in the related communities (OpenWebBeans, OpenEJB) >could >easily access the public TCKs. Mark and Gurkan fall into that category now. >Both are in the process of getting NDAs filled, but we could definitely speed >that up by opening the porting code to the public. > > > > We might even be able to work the JCDI and Bean Validation into our larger >test suite right in the main build as they only take a moments to run. > > > > Thoughts? > > > > -David > > > > > >
