Thanks Gerhard for your answer. Yes my unit test already set ProjectStageUnitTest but not the batch..Maybe it will have too?
About your post: - @Exclude on what? the producer in the common module used in the online app that is deployed in the online app? If so, I will have to remove this annotation on my producer at build/package time (!)....or maybe you want me to use the @Exclude(exceptIfProjectStage=UnitTest.class) on this producer? wow this is very intrusive and we will have to think of all our producers that HAVE TO be replace for batch/unit-test instead of "MAY BE" replaced by an "alternative" at runtime as in the semantic of the @Alternative mechanism. Looks much more like a dirty workaround than a real solution to me - @ProjectStageActivated on what? the producer in my unit-test/batch startup module? the producer is already activated.. as I can see it in the log and OWB use it about once on two. The problem is that OWB sometimes use it and sometimes use the one not annotated What I need here is that the producer annoted with @Alternative always take precedence on the one that does not have the annotation..I thought it was what CDI should provide out of the box. If not, what is the usage of @Alternative annotations then? .. Thx 2013/3/12 Gerhard Petracek <[email protected]>: > hi, > > you can use ProjectStage.UnitTest.class and > > @ProjectStageActivated provided by codi > or > @Exclude provided by deltaspike > > for your test-producer. > > in both cases you have to ensure that the project-stage is configured for > your unit-tests (e.g. as system-property). > > regards, > gerhard > > > > 2013/3/12 titou10 titou10 <[email protected]> >> >> Hi, >> I'm trying to setup a JUnit test (and a batch process) for our app >> with OWBv1.1.7 and we have problems with the way @Alternative >> producers is used by OWB at runtime >> >> Our setup is the following (by order in the classpath) >> - a jar with test functions (or batch functions) that include an >> @Alternative producer for a local EntityManager using a >> "TestPersistentUnit" defines in a specific persistence.xml file that >> directly points to the test (batch) database . The alternative is >> declared in beans.xml and "seen" (confirmed by the logs) by OWB at >> startup >> - a jar with the business classes and component (deployed in the war >> when deployed on WAS and used by the batch end tests process) >> - a jar with persistent/jpa classes (no beans.xml in there) with the >> "onlie/WAS" persistence.xml uses jndi lookup) >> - a jar with "common" classes and component, including an >> EntityMananger producer (using @PersistentContext annotation) >> >> We have OWB, CODI and DS in the classpath and use >> CdiContainerLoader.getCdiContainer().boot() .. to startup OWB >> In the log, OWB sees the 2 EntityManager producers but at runtime the >> alternative is picked up about once in two...Sometimes it works, >> sometimes not... >> >> I've read my posts on the web about @Alternative order/priority and so >> but didn't find any valid solution, including in the CDI forums >> I didn't find also valid solutions to this in CODI nor DS.. >> >> In this state we can not use @Alternative at all if we can not >> guarantee that the alternative EntityManager producer is always picked >> up, this is very true for our batch process >> Of course we could separate the entitymaneger producer in its specific >> jar and include it only when deployed in WAS and not in junit/batch >> but it seems it as the rôle of @Alternative.. >> >> Are here solutions to this? >> Thx > > >
