[VOTE] release Apache OpenWebBeans 1.0.0
Hi! I'd like to call a VOTE on releasing Apache OpenWebBeans-1.0.0 . Maven staging repo: https://repository.apache.org/content/repositories/orgapacheopenwebbeans-001/ SVN source tag (1003328): https://svn.apache.org/repos/asf/openwebbeans/tags/openwebbeans-1.0.0/ Source release: https://repository.apache.org/content/repositories/orgapacheopenwebbeans-001/org/apache/openwebbeans/openwebbeans/1.0.0/openwebbeans-1.0.0-source-release.zip Binary release: https://repository.apache.org/content/repositories/orgapacheopenwebbeans-001/org/apache/openwebbeans/openwebbeans-distribution/1.0.0/openwebbeans-distribution-1.0.0-binary.tar.gz PGP release key 2FDB81B1 http://svn.apache.org/repos/asf/openwebbeans/trunk/KEYS Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 veto (and reason why) A small note: I've created a owb_1.0.x branch which will contain the maintenance work on OWB-1.0.x. Feature development will be performed in trunk which now has a version of 1.1.0-SNAPSHOT txs and LieGrue, strub
[jira] Resolved: (OWB-177) Handling of InterceptionType#POST_ACTIVATE, PRE_PASSIVATE and AROUND_TIMEOUT is missing
[ https://issues.apache.org/jira/browse/OWB-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved OWB-177. --- Resolution: Fixed fixed. see OWB-422 > Handling of InterceptionType#POST_ACTIVATE, PRE_PASSIVATE and AROUND_TIMEOUT > is missing > --- > > Key: OWB-177 > URL: https://issues.apache.org/jira/browse/OWB-177 > Project: OpenWebBeans > Issue Type: Improvement > Components: Interceptor and Decorators >Affects Versions: 1.0.0-alpha-1 >Reporter: Mark Struberg >Assignee: Gurkan Erdogdu > Fix For: 1.0.0-GA > > > those interceptor types allow handling of the new ones defined in EJB-3.1. > Where do we handle them? > This turns out to be a very basic decision whether to pull in the EE api or > not. > If we handle them in the in openwebbeans-geronimo or openwebbeans-ejb only, > then we'd loose this functionality if we are running in e.g. a pure > ServletContainer. But although it's defined in the EJB spec, I personally > think this functionality might be interesting for SE applications too. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OWB-384) OWB needs to call 299-defined PrePassivate, PostActivate, and AroundTimeout interceptors for EJBs
[ https://issues.apache.org/jira/browse/OWB-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved OWB-384. --- Resolution: Fixed fixed. see OWB-422 > OWB needs to call 299-defined PrePassivate, PostActivate, and AroundTimeout > interceptors for EJBs > - > > Key: OWB-384 > URL: https://issues.apache.org/jira/browse/OWB-384 > Project: OpenWebBeans > Issue Type: Bug > Components: Java EE Integration >Affects Versions: 1.0.0-alpha-1 >Reporter: Eric Covener >Assignee: Eric Covener > Fix For: 1.0.0-GA > > Original Estimate: 16h > Remaining Estimate: 16h > > ignoring OWB's internal passivation needs, 299 interceptors might hook into > these lifecycle events. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OWB-428) implementation of equals and hashCode for AbstractOwbBean
[ https://issues.apache.org/jira/browse/OWB-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg updated OWB-428: -- Fix Version/s: 1.1.0 (was: 1.0.0-GA) Description: not sure if we really need it, because there is always only exactly one bean of a given kind. So instance comparison is save and also fast. > implementation of equals and hashCode for AbstractOwbBean > - > > Key: OWB-428 > URL: https://issues.apache.org/jira/browse/OWB-428 > Project: OpenWebBeans > Issue Type: Task > Components: Core >Affects Versions: 1.0.0-alpha-1 >Reporter: Gerhard Petracek >Assignee: Gurkan Erdogdu > Fix For: 1.1.0 > > Attachments: OWB-428.patch, OWB-428.patch > > > not sure if we really need it, because there is always only exactly one bean > of a given kind. So instance comparison is save and also fast. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OWB-407) detailed information about exceptions
[ https://issues.apache.org/jira/browse/OWB-407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved OWB-407. --- Fix Version/s: 1.0.0-GA Resolution: Fixed seems to be resolved as far as I've seen. txs 4 applying! > 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: Mark Struberg > Fix For: 1.0.0-GA > > Attachments: OWB-407_first_draft.patch, > OWB-407_first_draft_(style_2).patch, OWB-407_style_1.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] Resolved: (OWB-445) we must not use javassist ProxyFactory#setHandler(MethodHandler)
[ https://issues.apache.org/jira/browse/OWB-445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved OWB-445. --- Fix Version/s: 1.0.0-GA (was: 1.0.0-alpha-3) Resolution: Fixed > we must not use javassist ProxyFactory#setHandler(MethodHandler) > > > Key: OWB-445 > URL: https://issues.apache.org/jira/browse/OWB-445 > Project: OpenWebBeans > Issue Type: Bug > Components: Core >Affects Versions: 1.0.0-alpha-2 >Reporter: Mark Struberg >Assignee: Mark Struberg > Fix For: 1.0.0-GA > > > ProxyFactory.setHandler is deprecated and if used creates memory leaks! > We must create the ProxyClass without a default method handler and set it > after we create a proxy instance of that very class: > Object proxyInstance = proxyClass.newInstance(); > ((ProxyObject) proxyInstance ).setHandler( ... ) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OWB-448) More changes for decorator and interceptor passivation support
[ https://issues.apache.org/jira/browse/OWB-448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg updated OWB-448: -- Fix Version/s: 1.1.0 (was: 1.0.0-alpha-3) > More changes for decorator and interceptor passivation support > -- > > Key: OWB-448 > URL: https://issues.apache.org/jira/browse/OWB-448 > Project: OpenWebBeans > Issue Type: Improvement > Components: Interceptor and Decorators >Affects Versions: 1.0.0-alpha-2 >Reporter: YING WANG >Assignee: YING WANG >Priority: Minor > Fix For: 1.1.0 > > > add some serialization/deserialization code for interceptor, decorator, and > @EJB and some of their handlers. Note: due to the nature of abstract > decorator and javassist (we use a proxy object to instanciate the abstract > decorator class. ), passivation of abstract decorator is not working right > now since the fields in the decorator((proxy object) could not be serialzed > by javassist. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: I'm now starting of release process
reply heh yes, we can We just need to copy it onto our web server LieGrue, strub --- On Thu, 9/30/10, Rohit Kelapure wrote: > From: Rohit Kelapure > Subject: Re: I'm now starting of release process > To: dev@openwebbeans.apache.org > Date: Thursday, September 30, 2010, 7:01 PM > sorry meant logo file . > > On Thu, Sep 30, 2010 at 3:01 PM, Rohit Kelapure > wrote: > > Can we update our log file after the first release ? > > > > --Thanks, > > Rohit > > > > On Thu, Sep 30, 2010 at 2:57 PM, Mark Struberg > wrote: > >> Hi folks! > >> > >> I'm starting the preparation for the 1.0.0 release > in about 15 minutes. > >> > >> So please abstain from checking in until I'll ping > you again. > >> > >> Txs and LieGrue, > >> strub > >> > >> > >> > >> > > >
Re: I'm now starting of release process
sorry meant logo file . On Thu, Sep 30, 2010 at 3:01 PM, Rohit Kelapure wrote: > Can we update our log file after the first release ? > > --Thanks, > Rohit > > On Thu, Sep 30, 2010 at 2:57 PM, Mark Struberg wrote: >> Hi folks! >> >> I'm starting the preparation for the 1.0.0 release in about 15 minutes. >> >> So please abstain from checking in until I'll ping you again. >> >> Txs and LieGrue, >> strub >> >> >> >> >
Re: I'm now starting of release process
Can we update our log file after the first release ? --Thanks, Rohit On Thu, Sep 30, 2010 at 2:57 PM, Mark Struberg wrote: > Hi folks! > > I'm starting the preparation for the 1.0.0 release in about 15 minutes. > > So please abstain from checking in until I'll ping you again. > > Txs and LieGrue, > strub > > > >
I'm now starting of release process
Hi folks! I'm starting the preparation for the 1.0.0 release in about 15 minutes. So please abstain from checking in until I'll ping you again. Txs and LieGrue, strub
[jira] Resolved: (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 ] Mark Struberg resolved OWB-466. --- Fix Version/s: 1.0.0-GA Resolution: Fixed patch applied, thanks Jakob! > 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: Mark Struberg > Fix For: 1.0.0-GA > > 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.
Re: last TCK run
I've added a CDI-TCK [1] since pete also confirmed that this seems broken. LieGrue, strub [1] https://jira.jboss.org/browse/CDITCK-183 --- On Thu, 9/30/10, Eric Covener wrote: > From: Eric Covener > Subject: Re: last TCK run > To: dev@openwebbeans.apache.org > Date: Thursday, September 30, 2010, 1:50 PM > On Thu, Sep 30, 2010 at 9:20 AM, Mark > Struberg > wrote: > > and the others? > > > > Failed tests: > > testDestroyedInstanceMustNotBeReturnedByGet(org.jboss.jsr299.tck.tests.context.DestroyedInstanceReturnedByGetTest) > > testBindingTypesAppliedToDisposalMethodParameters(org.jboss.jsr299.tck.tests.implementation.disposal.method.definition.DisposalMethodDefinitionTest) > > testContextCreatesNewInstanceForInjection(org.jboss.jsr299.tck.tests.implementation.simple.lifecycle.SimpleBeanLifecycleTest) > > Tests run: 574, Failures: 3, Errors: 0, Skipped: 0 >
[jira] Assigned: (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 ] Mark Struberg reassigned OWB-466: - Assignee: Mark Struberg (was: Gurkan Erdogdu) > 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: Mark Struberg > 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.
Re: svn commit: r1003072 - in /openwebbeans/trunk/webbeans-ejb/src/main/java/org/apache/webbeans/ejb/common/component: BaseEjbBean.java EjbBeanCreatorImpl.java
no problem, just trying to fix this one broken TCK test yet. I'll call another round for TCK checks in 3 hours or so and if all runs well I'll call for a checkin freeze. LieGrue, strub --- On Thu, 9/30/10, Eric Covener wrote: > From: Eric Covener > Subject: Re: svn commit: r1003072 - in > /openwebbeans/trunk/webbeans-ejb/src/main/java/org/apache/webbeans/ejb/common/component: > BaseEjbBean.java EjbBeanCreatorImpl.java > To: dev@openwebbeans.apache.org > Date: Thursday, September 30, 2010, 2:20 PM > On Thu, Sep 30, 2010 at 10:18 > AM, > wrote: > > Author: covener > > Date: Thu Sep 30 14:18:17 2010 > > New Revision: 1003072 > > sorry Mark -- I know we are pseudo-frozen but need this > [safe] hook > for container integration. >
[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] Resolved: (OWB-465) enhance EJB common code for crude @LocalBean support
[ https://issues.apache.org/jira/browse/OWB-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Covener resolved OWB-465. -- Resolution: Fixed > enhance EJB common code for crude @LocalBean support > > > Key: OWB-465 > URL: https://issues.apache.org/jira/browse/OWB-465 > Project: OpenWebBeans > Issue Type: Improvement > Components: Java EE Integration >Affects Versions: 1.0.0-alpha-2 >Reporter: Eric Covener >Assignee: Eric Covener >Priority: Minor > Fix For: 1.0.0-GA > > Original Estimate: 1h > Remaining Estimate: 1h > > I need a small enhancement to expose no-interface local views for EJB to the > 299 Api Types. > I am not sure if this is necessary for openejb, but in my containr the > bean-class is not returned among the local business itnterfaces. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r1003072 - in /openwebbeans/trunk/webbeans-ejb/src/main/java/org/apache/webbeans/ejb/common/component: BaseEjbBean.java EjbBeanCreatorImpl.java
On Thu, Sep 30, 2010 at 10:18 AM, wrote: > Author: covener > Date: Thu Sep 30 14:18:17 2010 > New Revision: 1003072 sorry Mark -- I know we are pseudo-frozen but need this [safe] hook for container integration.
[jira] Created: (OWB-465) enhance EJB common code for crude @LocalBean support
enhance EJB common code for crude @LocalBean support Key: OWB-465 URL: https://issues.apache.org/jira/browse/OWB-465 Project: OpenWebBeans Issue Type: Improvement Components: Java EE Integration Affects Versions: 1.0.0-alpha-2 Reporter: Eric Covener Assignee: Eric Covener Priority: Minor Fix For: 1.0.0-GA I need a small enhancement to expose no-interface local views for EJB to the 299 Api Types. I am not sure if this is necessary for openejb, but in my containr the bean-class is not returned among the local business itnterfaces. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: last TCK run
On Thu, Sep 30, 2010 at 9:20 AM, Mark Struberg wrote: > and the others? > Failed tests: testDestroyedInstanceMustNotBeReturnedByGet(org.jboss.jsr299.tck.tests.context.DestroyedInstanceReturnedByGetTest) testBindingTypesAppliedToDisposalMethodParameters(org.jboss.jsr299.tck.tests.implementation.disposal.method.definition.DisposalMethodDefinitionTest) testContextCreatesNewInstanceForInjection(org.jboss.jsr299.tck.tests.implementation.simple.lifecycle.SimpleBeanLifecycleTest) Tests run: 574, Failures: 3, Errors: 0, Skipped: 0
Re: last TCK run
and the others? LieGrue, strub --- On Thu, 9/30/10, Eric Covener wrote: > From: Eric Covener > Subject: Re: last TCK run > To: dev@openwebbeans.apache.org > Date: Thursday, September 30, 2010, 1:12 PM > On Thu, Sep 30, 2010 at 8:57 AM, Mark > Struberg > wrote: > > Hi! > > > > Before doing a release this afternoon, I'm currently > running the TCK again. > > > > For standalone, I have one test which fails: > > DestroyedInstanceReturnedByGetTest > > > > Anyone knows anything about it? > > > > That's one of three I am used to seeing in my sandbox. >
Re: last TCK run
On Thu, Sep 30, 2010 at 8:57 AM, Mark Struberg wrote: > Hi! > > Before doing a release this afternoon, I'm currently running the TCK again. > > For standalone, I have one test which fails: > DestroyedInstanceReturnedByGetTest > > Anyone knows anything about it? > That's one of three I am used to seeing in my sandbox.
last TCK run
Hi! Before doing a release this afternoon, I'm currently running the TCK again. For standalone, I have one test which fails: DestroyedInstanceReturnedByGetTest Anyone knows anything about it? txs and LieGrue, strub
Re: ambiguous dependencies when using multiple qualifiers
OK, thanks for the clarification!
Regards,
Jakob
2010/9/29 Joseph Bergmark :
> I think you hit the nail on the head with your last paragraph.
> Basically it only matters that the bean (or producer in this case)
> matches all of the qualifiers on the injection point. From the
> perspective of the specification it doesn't matter if the bean has
> extra qualifiers beyond those on the injection point. Section 5.3 is
> another key section here.
>
> Sincerely,
>
> Joe
>
> On Wed, Sep 29, 2010 at 12:30 PM, Jakob Korherr
> wrote:
>> Hi,
>>
>> I tested some scenarios when using multiple qualifiers for test-cases
>> in MyFaces CODI and stumbled upon the following scenario, which is not
>> totally clear to me.
>>
>> Image you have the following producer methods:
>>
>> �...@produces
>> �...@qualifier2
>> �...@applicationscoped
>> public ProducerBean createWithQualifier2()
>> {
>> return new ProducerBean();
>> }
>>
>> �...@produces
>> �...@qualifier1
>> �...@qualifier2
>> �...@applicationscoped
>> public ProducerBean createWithQualifier1And2()
>> {
>> return new ProducerBean();
>> }
>>
>>
>> and you want to inject the instances produced by these producers. Now
>> you can use @Inject @Qualifier1 or @Inject @Qualifier1 @Qualifier2,
>> but when using @Inject @Qualifier2 you will get an exception, because
>> the injection point is ambiguous (both producers provide @Qualifier2).
>>
>> However I was wondering if this is really unresolvable ambiguous,
>> because if you think about it, it would make sence to take the
>> producer createWithQualifier2() in this scenario (because the other
>> one provides additional qualifiers).
>>
>> I also took a look in the CDI spec about this, but could only find the
>> following from section 2.3.4: "A bean may only be injected to an
>> injection point if it has all the qualifiers of the injection point."
>> Of course this applies to both producers and thus, yes, it's kinda
>> ambiguous.
>>
>> WDYT?
>>
>> Regards,
>> Jakob
>>
>> --
>> Jakob Korherr
>>
>> blog: http://www.jakobk.com
>> twitter: http://twitter.com/jakobkorherr
>> work: http://www.irian.at
>>
>
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
