[JBoss JIRA] Updated: (WELD-81) Add some smoke tests to core-test
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/WELD-81?page=com.atlassian.jira.plugin.sy... ]
Pete Muir updated WELD-81:
--------------------------
Description:
Weld is currently missing a set of smoke tests, a suite that exercises the key details of CDI (e.g. managed beans, session beans, observers, decorators, interceptors, servlet integration, jsf integration, the various contexts) but that doesn't delve into every specific of the spec. IOW a suite of say 50 tests that can run quickly, even in container.
These would be very useful to run with extensions such as Solder added to ensure that they don't alter the default behaviour accidentally or for testing non-spec-compliant containers such as Tomcat, Jetty or GAE.
was:
Weld is currently missing a set of smoke tests, a suite that exercises the key details of CDI (e.g. managed beans, session beans, observers, decorators, interceptors, servlet integration, jsf integration, the various contexts) but that doesn't delve into every specific of the spec. IOW a suite of say 50 tests that can run quickly, even in container.
These would be very useful to run with extensions such as Solder added to ensure that they don't alter the default behaviour accidentally.
> Add some smoke tests to core-test
> ---------------------------------
>
> Key: WELD-81
> URL: https://issues.jboss.org/browse/WELD-81
> Project: Weld
> Issue Type: Feature Request
> Components: Testing Infrastructure (Mocks and Harness Integration)
> Reporter: Pete Muir
> Priority: Optional
> Fix For: 1.2.0.Beta1
>
>
> Weld is currently missing a set of smoke tests, a suite that exercises the key details of CDI (e.g. managed beans, session beans, observers, decorators, interceptors, servlet integration, jsf integration, the various contexts) but that doesn't delve into every specific of the spec. IOW a suite of say 50 tests that can run quickly, even in container.
> These would be very useful to run with extensions such as Solder added to ensure that they don't alter the default behaviour accidentally or for testing non-spec-compliant containers such as Tomcat, Jetty or GAE.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] Updated: (WELD-81) Add some smoke tests to core-test
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/WELD-81?page=com.atlassian.jira.plugin.sy... ]
Pete Muir updated WELD-81:
--------------------------
Description:
Weld is currently missing a set of smoke tests, a suite that exercises the key details of CDI (e.g. managed beans, session beans, observers, decorators, interceptors, servlet integration, jsf integration, the various contexts) but that doesn't delve into every specific of the spec. IOW a suite of say 50 tests that can run quickly, even in container.
These would be very useful to run with extensions such as Solder added to ensure that they don't alter the default behaviour accidentally.
> Add some smoke tests to core-test
> ---------------------------------
>
> Key: WELD-81
> URL: https://issues.jboss.org/browse/WELD-81
> Project: Weld
> Issue Type: Feature Request
> Components: Testing Infrastructure (Mocks and Harness Integration)
> Reporter: Pete Muir
> Priority: Optional
> Fix For: 1.2.0.Beta1
>
>
> Weld is currently missing a set of smoke tests, a suite that exercises the key details of CDI (e.g. managed beans, session beans, observers, decorators, interceptors, servlet integration, jsf integration, the various contexts) but that doesn't delve into every specific of the spec. IOW a suite of say 50 tests that can run quickly, even in container.
> These would be very useful to run with extensions such as Solder added to ensure that they don't alter the default behaviour accidentally.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] Updated: (WELD-78) Review all code and comments for naming consistentcy with the spec
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/WELD-78?page=com.atlassian.jira.plugin.sy... ]
Pete Muir updated WELD-78:
--------------------------
Description: As Weld emerged from Web Beans, and the language of the spec changed overtime (e.g. bindings -> qualifiers) some members and/or classes are incorrectly named in Weld, referring to out of date names. I have updated as I came across the errors, but a full review would be appropriate to ensure we are up to date.
> Review all code and comments for naming consistentcy with the spec
> ------------------------------------------------------------------
>
> Key: WELD-78
> URL: https://issues.jboss.org/browse/WELD-78
> Project: Weld
> Issue Type: Feature Request
> Reporter: Pete Muir
> Assignee: Pete Muir
> Priority: Critical
> Labels: community_contributor_needed
> Fix For: 1.2.0.Beta1
>
>
> As Weld emerged from Web Beans, and the language of the spec changed overtime (e.g. bindings -> qualifiers) some members and/or classes are incorrectly named in Weld, referring to out of date names. I have updated as I came across the errors, but a full review would be appropriate to ensure we are up to date.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] Updated: (WELD-1) Add tests for multiple wars in an ear
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/WELD-1?page=com.atlassian.jira.plugin.sys... ]
Pete Muir updated WELD-1:
-------------------------
Description:
This is a typical area of weakness in Seam etc. due to misuse of singletons etc.
Write some tests to check that multiple wars in an ear work as expected. For example that beans are not resolvable between the two unless there is classloader visibility, and that the servlet context from one is not mixed to another, and that bean instances do not leak.
> Add tests for multiple wars in an ear
> -------------------------------------
>
> Key: WELD-1
> URL: https://issues.jboss.org/browse/WELD-1
> Project: Weld
> Issue Type: Feature Request
> Components: Bootstrap and Metamodel API, Scopes & Contexts
> Reporter: Pete Muir
> Fix For: 1.2.0.Beta1
>
>
> This is a typical area of weakness in Seam etc. due to misuse of singletons etc.
> Write some tests to check that multiple wars in an ear work as expected. For example that beans are not resolvable between the two unless there is classloader visibility, and that the servlet context from one is not mixed to another, and that bean instances do not leak.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] Updated: (WELD-53) Refactor reflection layer to be less of a memory hog
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/WELD-53?page=com.atlassian.jira.plugin.sy... ]
Pete Muir updated WELD-53:
--------------------------
Summary: Refactor reflection layer to be less of a memory hog (was: Full review of built in Reflection layer)
Priority: Blocker (was: Major)
Description:
Currently the reflection layer stores too much information, meaning we waste valuable heap space. This comes about because we build "extended metadata" for every deployed class; however we don't need this extended metadata for every class, and we also only need it at boot time. Therefore the proposed redesign looks like:
1) Create lightweight AnnotatedType implementations (work done, see https://github.com/pmuir/weld-core/tree/WELD-13_initial_slim)
2) Use these to fire the ProcessAnnotatedType events as needed (using the "backed" annotated impls)
2a) If the annotated type is unchanged, keep the backed annotated impl. This is the annotated impl that will be kept around at runtime, and is designed to be as slimline as possible for mem usage, delegating everything possible to existing objects
2b) If the annotated type is changed, wrap it in an "unbacked" annotated type. This may seem unecessary, however it does mean we are providing a consistent view for debugging, error reporting etc.
3) If a bean is required for the AnnotatedType, load extended metadata for it.
3a) This should be pluggable by the container, allowing something like jandex to be used if desired
3b) I would propose we use a Map like structure on load, so that the api looks like:
ExtendedAnnotatedType ExtendedMetadataLoader.load(AnnotatedType type);
3c) This extended metadata should include all the rich information available today on WeldClass and co, including stuff like being able to load methods by parameter annotations, meta-annotation support etc.
3d) Beans are created, using the extended metadata
3e) this extended metadata should have no references to it after bootstrap, allowing it to be removed at next gc run
Notes:
* Creating a parallel hierarchy of classes is not possible whilst preserving immutability, so extended metadata objects are not linked to each other, you traverse the graph using annotated type impls
was:
A few things:
* should we use javassist?
* need a full review of how we deal with Annotated*
> Refactor reflection layer to be less of a memory hog
> ----------------------------------------------------
>
> Key: WELD-53
> URL: https://issues.jboss.org/browse/WELD-53
> Project: Weld
> Issue Type: Feature Request
> Components: Resolution (Typesafe and by Name)
> Reporter: Pete Muir
> Priority: Blocker
> Fix For: 1.2.0.Beta1
>
>
> Currently the reflection layer stores too much information, meaning we waste valuable heap space. This comes about because we build "extended metadata" for every deployed class; however we don't need this extended metadata for every class, and we also only need it at boot time. Therefore the proposed redesign looks like:
> 1) Create lightweight AnnotatedType implementations (work done, see https://github.com/pmuir/weld-core/tree/WELD-13_initial_slim)
> 2) Use these to fire the ProcessAnnotatedType events as needed (using the "backed" annotated impls)
> 2a) If the annotated type is unchanged, keep the backed annotated impl. This is the annotated impl that will be kept around at runtime, and is designed to be as slimline as possible for mem usage, delegating everything possible to existing objects
> 2b) If the annotated type is changed, wrap it in an "unbacked" annotated type. This may seem unecessary, however it does mean we are providing a consistent view for debugging, error reporting etc.
> 3) If a bean is required for the AnnotatedType, load extended metadata for it.
> 3a) This should be pluggable by the container, allowing something like jandex to be used if desired
> 3b) I would propose we use a Map like structure on load, so that the api looks like:
> ExtendedAnnotatedType ExtendedMetadataLoader.load(AnnotatedType type);
> 3c) This extended metadata should include all the rich information available today on WeldClass and co, including stuff like being able to load methods by parameter annotations, meta-annotation support etc.
> 3d) Beans are created, using the extended metadata
> 3e) this extended metadata should have no references to it after bootstrap, allowing it to be removed at next gc run
> Notes:
> * Creating a parallel hierarchy of classes is not possible whilst preserving immutability, so extended metadata objects are not linked to each other, you traverse the graph using annotated type impls
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] Updated: (WELD-13) Use the builder pattern to create Bean objects
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/WELD-13?page=com.atlassian.jira.plugin.sy... ]
Pete Muir updated WELD-13:
--------------------------
Summary: Use the builder pattern to create Bean objects (was: Switch to using a builder to make immutable bean objects)
Priority: Critical (was: Major)
Description:
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
was:
Currently we do a lot of init in the *Bean which, to be flexible, isn't in the constructor, which stops the Bean objects being truly immutable. It's also not nice to read.
A challenge will be the two phase bootstrap.
I would recommend doing this refactor early on as it will make the code base much more manageable.
> 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
> 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, 5 months