hi, implement the default-producer in one class and a test-producer in a second class. -> annotate only the second class with @Alternative and e.g. with @Exclude(exceptIfProjectStage = ProjectStage.UnitTest.class)
+ configure the second class as alternative in the beans.xml + configure the project-stage for your test-environment (or set it manually via ProjectStageProducer#setProjectStage) regards, gerhard 2013/3/12 titou10 titou10 <[email protected]> > 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 > > > > > > >
