[JBoss JIRA] Commented: (WELD-13) Use the builder pattern to create Bean objects
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WELD-13?page=com.atlassian.jira.plugin.sy... ]
Stuart Douglas commented on WELD-13:
------------------------------------
I don't think it is possible to have fully immutable beans, as interceptors and decorators can be added in the AfterBeanDiscovery phase.
> Use the builder pattern to create Bean objects
> ----------------------------------------------
>
> Key: WELD-13
> URL: https://issues.jboss.org/browse/WELD-13
> Project: Weld
> Issue Type: Feature Request
> Components: Class Beans (Managed and Session)
> Reporter: Pete Muir
> Assignee: Stuart Douglas
> Priority: Critical
> Fix For: 1.2.0.Beta1
>
>
> Currently we create the Bean objects using a two phase initialization, partly via the constructor, and partly via an initialize() method, this allows us to create the beans, attach them to the bean manager and then do further work once all bean objects exist. This has a number of problems:
> 1) objects are not fully immutable which means we rely on developers ability to keep them effectively immutable
> 2) the objects are a mess of init methods and getters
> 3) creation logic is convoluted
> It would be far better to create builders (or factories) that can create the beans as needed, this will cleanly split out the creation logic from the bean object, and allow us to create fully immutable objects, thus making it easier to verify the thread-safety of the code.
> A side effect of this will be that we can't use two-phase initialization two set up certain stuff after all beans are present. To overcome this we will need to order the bean creation so that beans required by other beans are created first and thus can be attached as needed.
> The rules I am aware of:
> * producer methods and fields should be created after the class bean that declares them as they need to know that bean in order to be instantiated
> * specialized beans need to be created in the order least specialized to most specialized as a more specialized bean needs to read the metadata of the less specialized bean
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[JBoss JIRA] Assigned: (WELD-13) Use the builder pattern to create Bean objects
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WELD-13?page=com.atlassian.jira.plugin.sy... ]
Stuart Douglas reassigned WELD-13:
----------------------------------
Assignee: Stuart Douglas
> Use the builder pattern to create Bean objects
> ----------------------------------------------
>
> Key: WELD-13
> URL: https://issues.jboss.org/browse/WELD-13
> Project: Weld
> Issue Type: Feature Request
> Components: Class Beans (Managed and Session)
> Reporter: Pete Muir
> Assignee: Stuart Douglas
> Priority: Critical
> Fix For: 1.2.0.Beta1
>
>
> Currently we create the Bean objects using a two phase initialization, partly via the constructor, and partly via an initialize() method, this allows us to create the beans, attach them to the bean manager and then do further work once all bean objects exist. This has a number of problems:
> 1) objects are not fully immutable which means we rely on developers ability to keep them effectively immutable
> 2) the objects are a mess of init methods and getters
> 3) creation logic is convoluted
> It would be far better to create builders (or factories) that can create the beans as needed, this will cleanly split out the creation logic from the bean object, and allow us to create fully immutable objects, thus making it easier to verify the thread-safety of the code.
> A side effect of this will be that we can't use two-phase initialization two set up certain stuff after all beans are present. To overcome this we will need to order the bean creation so that beans required by other beans are created first and thus can be attached as needed.
> The rules I am aware of:
> * producer methods and fields should be created after the class bean that declares them as they need to know that bean in order to be instantiated
> * specialized beans need to be created in the order least specialized to most specialized as a more specialized bean needs to read the metadata of the less specialized bean
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[JBoss JIRA] Created: (WELD-787) CurrentInjectionPoint ThreadLocal leak with Weld Servlet
by Aslak Knutsen (JIRA)
CurrentInjectionPoint ThreadLocal leak with Weld Servlet
--------------------------------------------------------
Key: WELD-787
URL: https://issues.jboss.org/browse/WELD-787
Project: Weld
Issue Type: Bug
Components: Servlet Container Support
Affects Versions: 1.1.0.Beta2
Environment: Weld Servlet 1.1.0-SNAPSHOT / Beta2 / Beta1 on Tomcat 6
Reporter: Aslak Knutsen
Nov 22, 2010 7:13:40 PM org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap
SEVERE: The web application [/active1] created a ThreadLocal with key of type [null] (value [org.jboss.weld.injection.CurrentInjectionPoint$1@30b95f2]) and a value of type [java.util.Stack] (value [[]]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak.
The CurrentInjectionPoint push/pop works, since the Stack object on the Thread is Empty when undeploy.
CurrentInjectionPoint.cleanup is called during the contextDestroyed lifecycle, but the event is executed on the main Thread, not the HTTP thread. This results in the Empty Stack leak.
ThreadLocals active during a HTTP request has to be cleaned up at the end of the Request. There are no guarantees that you will ever see that Thread again. CurrentInjectionPoint.cleanup should probably be moved to the requestDestroyed lifecycle.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months