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
