[jira] Commented: (OWB-481) WebBeansConfigurationListener implementing ServletContextListener is not likely to work
[ https://issues.apache.org/jira/browse/OWB-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12923803#action_12923803 ] Jakob Korherr commented on OWB-481: --- Note that the ServletContainerInitializer is only available for Servlet 3.0 environments, there is no such thing for Servlet 2.5. In addition you're just moving this problem from the ServletContextListener to the ServletContainerInitializer. Furthermore I think this is not an OWB problem, but rather a user problem. If the user wants to use OWB in his ServletContextListener(s), he has to make sure that OWB will be initialized at this point of time. We do the same in MyFaces for this problem. For the Geronimo integration I think it should be possible to call the OWB-initialization code from the Geronimo deployer before any ServletContainerInitializer or ServletContextListener is called in order to circumvent this problem. > WebBeansConfigurationListener implementing ServletContextListener is not > likely to work > --- > > Key: OWB-481 > URL: https://issues.apache.org/jira/browse/OWB-481 > Project: OpenWebBeans > Issue Type: Bug >Reporter: David Jencks >Assignee: Gurkan Erdogdu > > Currently WebBeansConfigurationListener implements ServletContextListener and > uses the contextInitialized method to initialize OWB for the web app. Given > an application containing a ServletContextListener that is a web bean, this > requires that > 1. the OWB WebBeansConfigurationListener ServletContextListener get > installed before the app's ServletContextListeners > 2. the OWB WebBeansConfigurationListener have it's contextInitialized called > before the servlet container instantiates the apps ServletContextListeners > that are web beans. > There's no way to guarantee this will happen in a compliant servlet > container. (Neither happens in the geronimo tomcat integration; we could > force the first to happen, but not the second). > It might be possible to do the initialization in a > ServletContainerInitializer since I think these get called before any > application classes start getting instantiated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OWB-466) Ensure removal of all ThreadLocal values
[ https://issues.apache.org/jira/browse/OWB-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr updated OWB-466: -- Attachment: OWB-466.patch > Ensure removal of all ThreadLocal values > > > Key: OWB-466 > URL: https://issues.apache.org/jira/browse/OWB-466 > Project: OpenWebBeans > Issue Type: Bug >Affects Versions: 1.0.0-alpha-2 >Reporter: Jakob Korherr >Assignee: Gurkan Erdogdu > Attachments: OWB-466.patch > > > While running our automated webapp tests with MyFaces CODI and OWB, I always > got the following log entries: > 30.09.2010 16:14:14 org.apache.catalina.loader.WebappClassLoader > clearThreadLocalMap > SCHWERWIEGEND: A web application created a ThreadLocal with key of type > [java.lang.ThreadLocal] (value [java.lang.threadlo...@543c944f]) and a value > of type [org.apache.webbeans.inject.impl.InjectionPointImpl] (value [Field > Injection Point, field name : postConstructApplicationEvent, Bean Owner : > [Name:systemEventBroadcaster,WebBeans Type:MANAGED,API > Types:[java.lang.Object,org.apache.myfaces.extensions.cdi.jsf2.impl.listener.system.SystemEventBroadcaster],Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default,javax.inject.Named]]]) > but failed to remove it when the web application was stopped. To prevent a > memory leak, the ThreadLocal has been forcibly removed. > 30.09.2010 16:14:14 org.apache.catalina.loader.WebappClassLoader > clearThreadLocalMap > SCHWERWIEGEND: A web application created a ThreadLocal with key of type > [java.lang.ThreadLocal] (value [java.lang.threadlo...@552cf9bd]) and a value > of type [org.apache.webbeans.context.SessionContext] (value > [org.apache.webbeans.context.sessioncont...@7bc012fa]) but failed to remove > it when the web application was stopped. To prevent a memory leak, the > ThreadLocal has been forcibly removed. > 30.09.2010 16:14:14 org.apache.catalina.loader.WebappClassLoader > clearThreadLocalMap > SCHWERWIEGEND: A web application created a ThreadLocal with key of type > [java.lang.ThreadLocal] (value [java.lang.threadlo...@552cf9bd]) and a value > of type [org.apache.webbeans.context.SessionContext] (value > [org.apache.webbeans.context.sessioncont...@7f1e1a8e]) but failed to remove > it when the web application was stopped. To prevent a memory leak, the > ThreadLocal has been forcibly removed. > 30.09.2010 16:14:14 org.apache.coyote.http11.Http11Protocol destroy > ..saying that Tomcat's webappclassloader had to remove some ThreadLocal > values from the ThreadMap. > I was able to track the affected ThreadLocal instances down: > InstanceBean.local and WebContextsService.sessionContext. > After digging into the code, I found out that there are many remove() > operations on various ThreadLocal instances, but it was not thought that > remove() only works for the current Thread. Thus when a ThreadLocal is set > during a request it won't be removed when the container stops, because the > shutdown-thread is clearly not the same as the request-thread. > This means the request-ThreadLocal instances have to be removed after every > request has ended - in requestDestroyed(ServletRequestEvent event). > The provided patch adds some remove() calls in requestDestroyed() and also in > afterStopApplication(). With this patch none of the above error-logs are > shown in any of my test cases. However there might be some other ThreadLocals > which should be cleaned up at every request, but this solution currently > works for me! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OWB-466) Ensure removal of all ThreadLocal values
Ensure removal of all ThreadLocal values Key: OWB-466 URL: https://issues.apache.org/jira/browse/OWB-466 Project: OpenWebBeans Issue Type: Bug Affects Versions: 1.0.0-alpha-2 Reporter: Jakob Korherr Assignee: Gurkan Erdogdu While running our automated webapp tests with MyFaces CODI and OWB, I always got the following log entries: 30.09.2010 16:14:14 org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap SCHWERWIEGEND: A web application created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.threadlo...@543c944f]) and a value of type [org.apache.webbeans.inject.impl.InjectionPointImpl] (value [Field Injection Point, field name : postConstructApplicationEvent, Bean Owner : [Name:systemEventBroadcaster,WebBeans Type:MANAGED,API Types:[java.lang.Object,org.apache.myfaces.extensions.cdi.jsf2.impl.listener.system.SystemEventBroadcaster],Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default,javax.inject.Named]]]) but failed to remove it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed. 30.09.2010 16:14:14 org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap SCHWERWIEGEND: A web application created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.threadlo...@552cf9bd]) and a value of type [org.apache.webbeans.context.SessionContext] (value [org.apache.webbeans.context.sessioncont...@7bc012fa]) but failed to remove it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed. 30.09.2010 16:14:14 org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap SCHWERWIEGEND: A web application created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.threadlo...@552cf9bd]) and a value of type [org.apache.webbeans.context.SessionContext] (value [org.apache.webbeans.context.sessioncont...@7f1e1a8e]) but failed to remove it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed. 30.09.2010 16:14:14 org.apache.coyote.http11.Http11Protocol destroy ..saying that Tomcat's webappclassloader had to remove some ThreadLocal values from the ThreadMap. I was able to track the affected ThreadLocal instances down: InstanceBean.local and WebContextsService.sessionContext. After digging into the code, I found out that there are many remove() operations on various ThreadLocal instances, but it was not thought that remove() only works for the current Thread. Thus when a ThreadLocal is set during a request it won't be removed when the container stops, because the shutdown-thread is clearly not the same as the request-thread. This means the request-ThreadLocal instances have to be removed after every request has ended - in requestDestroyed(ServletRequestEvent event). The provided patch adds some remove() calls in requestDestroyed() and also in afterStopApplication(). With this patch none of the above error-logs are shown in any of my test cases. However there might be some other ThreadLocals which should be cleaned up at every request, but this solution currently works for me! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OWB-462) Refactor AnnotationUtil.hasAnnotationMember()
[ https://issues.apache.org/jira/browse/OWB-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr updated OWB-462: -- Attachment: OWB-462.patch The patch contains the refactored code and some test cases. > Refactor AnnotationUtil.hasAnnotationMember() > - > > Key: OWB-462 > URL: https://issues.apache.org/jira/browse/OWB-462 > Project: OpenWebBeans > Issue Type: Task > Components: Core >Affects Versions: 1.0.0-alpha-2 >Reporter: Jakob Korherr >Assignee: Gurkan Erdogdu > Attachments: OWB-462.patch > > > We needed a method to compare qualifiers for MyFaces CODI and stumbled upon > AnnotationUtil.hasAnnotationMember(). > However this method is really messy, because it uses the String > representation of an annotation to compare it and thus fails in various cases > (e.g. when using annotation instances which implement toString() differently > or by using array values in the qualifier). Furthermore it does not detect > @Nonbinding fields correctly, if there is more than one annotation on the > annotation-method. > Also it's kinda weird that the method takes the Annotation-Class as an extra > parameter, but it could just get it from one of the Annotation instances. I > checked all usages and found out that this argument can be dropped. In > addition I think it's better to rename the method to isQualifierEqual() - the > usage is just a lot clearer. > I implemented a custom solution for MyFaces CODI and I think it should also > be applied here. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OWB-462) Refactor AnnotationUtil.hasAnnotationMember()
Refactor AnnotationUtil.hasAnnotationMember() - Key: OWB-462 URL: https://issues.apache.org/jira/browse/OWB-462 Project: OpenWebBeans Issue Type: Task Components: Core Affects Versions: 1.0.0-alpha-2 Reporter: Jakob Korherr Assignee: Gurkan Erdogdu We needed a method to compare qualifiers for MyFaces CODI and stumbled upon AnnotationUtil.hasAnnotationMember(). However this method is really messy, because it uses the String representation of an annotation to compare it and thus fails in various cases (e.g. when using annotation instances which implement toString() differently or by using array values in the qualifier). Furthermore it does not detect @Nonbinding fields correctly, if there is more than one annotation on the annotation-method. Also it's kinda weird that the method takes the Annotation-Class as an extra parameter, but it could just get it from one of the Annotation instances. I checked all usages and found out that this argument can be dropped. In addition I think it's better to rename the method to isQualifierEqual() - the usage is just a lot clearer. I implemented a custom solution for MyFaces CODI and I think it should also be applied here. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
