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 <[email protected]> To: [email protected] 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 <[email protected]> > An: [email protected] > 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: [email protected] > 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
