You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwebbeans.apache.org by Mark Struberg <st...@yahoo.de> on 2009/10/28 23:29:43 UTC
divergence between ManagedBeanConfigurator#define and BeansDeployer#defineManagedBean
Hi!
Somehow those 2 functions cover pretty much of the same functionality, isn't?
Gurkan, do you think we can merge the functionalities somehow?
E.g. for the tests we could use BeansDeployer#deploy with a special MetaDataDiscoveryService which only returns the one bean class under test.
something like:
TestContext#defineSimpleWebBean(Class<T> clazz) {
BeansDeployer bd = getBeansDeployer();
MetaDataDiscoveryService mockMdd = new MockMetaDataDiscoveryService(clazz);
bd.deploy(mockMdd);
}
similar stuff for XML, etc. got me?
This way we could test all the lifecycle events and stuff. For my gut feeling the test container code is way too far from the 'real' lifecycle code currently.
Should I try it, or do you see any problem which will be a show stopper?
LieGrue,
strub
Re: AW: divergence between ManagedBeanConfigurator#define and BeansDeployer#defineManagedBean
Posted by Gurkan Erdogdu <gu...@yahoo.com>.
Hi Mark!
If it is not necessary, we can absolutely remove it.
=== Couple of points ===
----------------------------------------
1* Last time I tried to implement "BeanManagerImpl#createInjectionTarget(AnnotatedType type)" so I added new method to ManagedBeanConfigurator#defineFromAnnotatedType but it has not been completed.
Motivation for this method
------------------------------------------
This method main task was creating a bean instance using artifacts(fields, methods, annotations etc.) on the "AnnotationType" parameter instead of using bean class itself. After creating a bean instance using "AnnotatedType" parameter, BeanManagerImpl#createInjectionTarget(AnnotatedType type) will work correctly.
Indeed, BeanManagerImpl#createInjectionTarget does not return correct value. Currently, it creates a "Bean" instance using class, method and field level annotations on the bean class itself that is wrong becuase it has to use "AnnotatedType" parameter to get those annotations (Portable extensions scenario).
This is an one area that can be contributed!
2* Moreover it contains some utility methods, "checkSimpleWebBeanCondition, isManagedBean". We can drop those methods into WebBeansUtil.
Thanks;
--Gurkan
________________________________
From: Mark Struberg <st...@yahoo.de>
To: openwebbeans-dev@incubator.apache.org
Sent: Thu, October 29, 2009 11:04:41 AM
Subject: AW: divergence between ManagedBeanConfigurator#define and BeansDeployer#defineManagedBean
Txs Gurkan!
Just for getting an an idea of what I like to test. I've now checked in the following changes of the extension test:
webbeans-impl/src/test/java/org/apache/webbeans/test/component/portable/events/MyExtension.java
As you see there are a lot of lifecycle events and I already found a few which we do not fire (even in the 'real' lifecycles).
That's the reason why I like to switch over to the 'real thing' ;) Maybe it will be tricky in a few parts of the TestContext, but it should be doable.
I think we can even drop the whole ManagedBeanConfigurator at some point, don't we?
LieGrue,
strub
----- Ursprüngliche Mail ----
> Von: Gurkan Erdogdu <gu...@yahoo.com>
> An: openwebbeans-dev@incubator.apache.org
> Gesendet: Donnerstag, den 29. Oktober 2009, 7:10:02 Uhr
> Betreff: Re: divergence between ManagedBeanConfigurator#define and BeansDeployer#defineManagedBean
>
> >>>Somehow those 2 functions cover pretty much of the same functionality, isn't?
> Actually ManagedBeanConfigurator#define was used for defining managed beans
> without lifecycle events etc. before specification containing Portable
> Integration chapter. After implementing portable integration, I replaced managed
> bean creation to BeansDeployer#defineManagedBean and
> ManagedBeanConfigurator#define was deperecated. It is still used in some places
> that contains "TestContext" class.
>
> >>>Gurkan, do you think we can merge the functionalities somehow?
> It is not necessary to merge them from code implementation becuase
> BeansDeployer#defineManagedBean already contains ManagedBeanConfigurator#define
> functionality. But we can update our code to replace old
> ManagedBeanConfigurator#define within several places.
>
> >>>E.g. for the tests we could use BeansDeployer#deploy with a special
> MetaDataDiscoveryService which only returns the one bean class under
> test.
>
> Currently tests do not work in the simulating container. Each test uses
> "TestContext" methods to do something . As you specified, we can implement
> simple "Lifecycle" implemetation using for the tests. It can be used fır future
> tests .
>
> Currently we have two implementation of "Lifecycle" that you can get help from
> their implementation.
>
> EnterpriseLifecycle --> org.apache.webbeans.lifecycle.EnterpriseLifecycle uses
> WarMetaDataDiscoveryImpl
> StandaloneLifecycle-->org.apache.webbeans.lifecycle.StandaloneLifecycle uses
> MetaDataDiscoveryStandard
>
> We can implement whatever funtionality in "TestLifecycle" using
> "TestMetaDataDisceovery."
>
> Thanks;
>
> --Gurkan
>
>
> ________________________________
> From: Mark Struberg
> To: openwebbeans-dev@incubator.apache.org
> Sent: Thu, October 29, 2009 12:29:43 AM
> Subject: divergence between ManagedBeanConfigurator#define and
> BeansDeployer#defineManagedBean
>
> Hi!
>
> Somehow those 2 functions cover pretty much of the same functionality, isn't?
>
> Gurkan, do you think we can merge the functionalities somehow?
>
> E.g. for the tests we could use BeansDeployer#deploy with a special
> MetaDataDiscoveryService which only returns the one bean class under test.
>
> something like:
>
> TestContext#defineSimpleWebBean(Classclazz) {
> BeansDeployer bd = getBeansDeployer();
> MetaDataDiscoveryService mockMdd = new MockMetaDataDiscoveryService(clazz);
> bd.deploy(mockMdd);
> }
>
> similar stuff for XML, etc. got me?
>
> This way we could test all the lifecycle events and stuff. For my gut feeling
> the test container code is way too far from the 'real' lifecycle code currently.
>
> Should I try it, or do you see any problem which will be a show stopper?
>
> LieGrue,
> strub
AW: divergence between ManagedBeanConfigurator#define and BeansDeployer#defineManagedBean
Posted by Mark Struberg <st...@yahoo.de>.
Txs Gurkan!
Just for getting an an idea of what I like to test. I've now checked in the following changes of the extension test:
webbeans-impl/src/test/java/org/apache/webbeans/test/component/portable/events/MyExtension.java
As you see there are a lot of lifecycle events and I already found a few which we do not fire (even in the 'real' lifecycles).
That's the reason why I like to switch over to the 'real thing' ;) Maybe it will be tricky in a few parts of the TestContext, but it should be doable.
I think we can even drop the whole ManagedBeanConfigurator at some point, don't we?
LieGrue,
strub
----- Ursprüngliche Mail ----
> Von: Gurkan Erdogdu <gu...@yahoo.com>
> An: openwebbeans-dev@incubator.apache.org
> Gesendet: Donnerstag, den 29. Oktober 2009, 7:10:02 Uhr
> Betreff: Re: divergence between ManagedBeanConfigurator#define and BeansDeployer#defineManagedBean
>
> >>>Somehow those 2 functions cover pretty much of the same functionality, isn't?
> Actually ManagedBeanConfigurator#define was used for defining managed beans
> without lifecycle events etc. before specification containing Portable
> Integration chapter. After implementing portable integration, I replaced managed
> bean creation to BeansDeployer#defineManagedBean and
> ManagedBeanConfigurator#define was deperecated. It is still used in some places
> that contains "TestContext" class.
>
> >>>Gurkan, do you think we can merge the functionalities somehow?
> It is not necessary to merge them from code implementation becuase
> BeansDeployer#defineManagedBean already contains ManagedBeanConfigurator#define
> functionality. But we can update our code to replace old
> ManagedBeanConfigurator#define within several places.
>
> >>>E.g. for the tests we could use BeansDeployer#deploy with a special
> MetaDataDiscoveryService which only returns the one bean class under
> test.
>
> Currently tests do not work in the simulating container. Each test uses
> "TestContext" methods to do something . As you specified, we can implement
> simple "Lifecycle" implemetation using for the tests. It can be used fır future
> tests .
>
> Currently we have two implementation of "Lifecycle" that you can get help from
> their implementation.
>
> EnterpriseLifecycle --> org.apache.webbeans.lifecycle.EnterpriseLifecycle uses
> WarMetaDataDiscoveryImpl
> StandaloneLifecycle-->org.apache.webbeans.lifecycle.StandaloneLifecycle uses
> MetaDataDiscoveryStandard
>
> We can implement whatever funtionality in "TestLifecycle" using
> "TestMetaDataDisceovery."
>
> Thanks;
>
> --Gurkan
>
>
> ________________________________
> From: Mark Struberg
> To: openwebbeans-dev@incubator.apache.org
> Sent: Thu, October 29, 2009 12:29:43 AM
> Subject: divergence between ManagedBeanConfigurator#define and
> BeansDeployer#defineManagedBean
>
> Hi!
>
> Somehow those 2 functions cover pretty much of the same functionality, isn't?
>
> Gurkan, do you think we can merge the functionalities somehow?
>
> E.g. for the tests we could use BeansDeployer#deploy with a special
> MetaDataDiscoveryService which only returns the one bean class under test.
>
> something like:
>
> TestContext#defineSimpleWebBean(Classclazz) {
> BeansDeployer bd = getBeansDeployer();
> MetaDataDiscoveryService mockMdd = new MockMetaDataDiscoveryService(clazz);
> bd.deploy(mockMdd);
> }
>
> similar stuff for XML, etc. got me?
>
> This way we could test all the lifecycle events and stuff. For my gut feeling
> the test container code is way too far from the 'real' lifecycle code currently.
>
> Should I try it, or do you see any problem which will be a show stopper?
>
> LieGrue,
> strub
Re: divergence between ManagedBeanConfigurator#define and BeansDeployer#defineManagedBean
Posted by Gurkan Erdogdu <gu...@yahoo.com>.
>>>Somehow those 2 functions cover pretty much of the same functionality, isn't?
Actually ManagedBeanConfigurator#define was used for defining managed beans without lifecycle events etc. before specification containing Portable Integration chapter. After implementing portable integration, I replaced managed bean creation to BeansDeployer#defineManagedBean and ManagedBeanConfigurator#define was deperecated. It is still used in some places that contains "TestContext" class.
>>>Gurkan, do you think we can merge the functionalities somehow?
It is not necessary to merge them from code implementation becuase BeansDeployer#defineManagedBean already contains ManagedBeanConfigurator#define functionality. But we can update our code to replace old ManagedBeanConfigurator#define within several places.
>>>E.g. for the tests we could use BeansDeployer#deploy with a special
MetaDataDiscoveryService which only returns the one bean class under
test.
Currently tests do not work in the simulating container. Each test uses "TestContext" methods to do something . As you specified, we can implement simple "Lifecycle" implemetation using for the tests. It can be used fır future tests .
Currently we have two implementation of "Lifecycle" that you can get help from their implementation.
EnterpriseLifecycle --> org.apache.webbeans.lifecycle.EnterpriseLifecycle uses WarMetaDataDiscoveryImpl
StandaloneLifecycle-->org.apache.webbeans.lifecycle.StandaloneLifecycle uses MetaDataDiscoveryStandard
We can implement whatever funtionality in "TestLifecycle" using "TestMetaDataDisceovery."
Thanks;
--Gurkan
________________________________
From: Mark Struberg <st...@yahoo.de>
To: openwebbeans-dev@incubator.apache.org
Sent: Thu, October 29, 2009 12:29:43 AM
Subject: divergence between ManagedBeanConfigurator#define and BeansDeployer#defineManagedBean
Hi!
Somehow those 2 functions cover pretty much of the same functionality, isn't?
Gurkan, do you think we can merge the functionalities somehow?
E.g. for the tests we could use BeansDeployer#deploy with a special MetaDataDiscoveryService which only returns the one bean class under test.
something like:
TestContext#defineSimpleWebBean(Class<T> clazz) {
BeansDeployer bd = getBeansDeployer();
MetaDataDiscoveryService mockMdd = new MockMetaDataDiscoveryService(clazz);
bd.deploy(mockMdd);
}
similar stuff for XML, etc. got me?
This way we could test all the lifecycle events and stuff. For my gut feeling the test container code is way too far from the 'real' lifecycle code currently.
Should I try it, or do you see any problem which will be a show stopper?
LieGrue,
strub