[jira] Commented: (OWB-434) ThreadLocalSingletonContext doen't get cleaned up
[ https://issues.apache.org/jira/browse/OWB-434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12896471#action_12896471 ] Mark Struberg commented on OWB-434: --- latest tomcat6 sometimes shows the following in the log: SCHWERWIEGEND: A web application created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.threadlo...@17525fa]) and a value of type [org.apache.webbeans.context.SingletonContext] (value [org.apache.webbeans.context.singletoncont...@1041dc]) but failed to r emove it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed. ThreadLocalSingletonContext doen't get cleaned up --- Key: OWB-434 URL: https://issues.apache.org/jira/browse/OWB-434 Project: OpenWebBeans Issue Type: Bug Components: Context and Scopes Affects Versions: 1.0.0-alpha-1 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 1.0.0-alpha-2 We currently store the active SingletonContext for each thread in a ThreadLocal. We must cleanup this ThreadLocal at the end of each request! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OWB-434) ThreadLocalSingletonContext doen't get cleaned up
[ https://issues.apache.org/jira/browse/OWB-434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved OWB-434. --- Resolution: Fixed resolved by moving the ThreadLocal cleanup at the very end of all operations. ThreadLocalSingletonContext doen't get cleaned up --- Key: OWB-434 URL: https://issues.apache.org/jira/browse/OWB-434 Project: OpenWebBeans Issue Type: Bug Components: Context and Scopes Affects Versions: 1.0.0-alpha-1 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 1.0.0-alpha-2 We currently store the active SingletonContext for each thread in a ThreadLocal. We must cleanup this ThreadLocal at the end of each request! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
299 q: AfterBeanDiscovery.addBean()
In 299, If a portable extension used AfterBeanDiscovery.addBean() to add a managed bean to an application: 1) If that bean was already in a BDA we knew about, why bother adding it this way? 2) If that bean was not already in a BDA, is it now uninterceptable and undecoratable because there's no ways to enable anything for it? I couldn't find an alternative mechanism for enablement. -- Eric Covener cove...@gmail.com
Re: 299 q: AfterBeanDiscovery.addBean()
All bean modification mechanisms should still be available. A usecase for this SPI is e.g. configuration via XML. This way you could add a bean without even being in a BDA. Otoh if it's defined in a BDA it will get picked up as @Dependent automatically (and I really hate this behaviour defined in the spec...) So you first would need to drop the @Dependent bean and add a new one. LieGrue, strub - Original Message From: Eric Covener cove...@gmail.com To: dev@openwebbeans.apache.org Sent: Mon, August 9, 2010 3:14:14 PM Subject: 299 q: AfterBeanDiscovery.addBean() In 299, If a portable extension used AfterBeanDiscovery.addBean() to add a managed bean to an application: 1) If that bean was already in a BDA we knew about, why bother adding it this way? 2) If that bean was not already in a BDA, is it now uninterceptable and undecoratable because there's no ways to enable anything for it? I couldn't find an alternative mechanism for enablement. -- Eric Covener cove...@gmail.com
