It seems that I finally got it to work it by using a @Specializes but
I don't really understand why the @Alternative doesn't work straight.
Still not sure it will work 100% of the time. Maybe the problem is a
"timing" problem and using @Specializes change this timing..
Would love to have someone explain why the@specializes works and not the other..
In the "common jar", the "production EntityManager producer" that has
to be mocked:
------------------------------------------------------------------------------------------
public class EntityManagerProducer {
@PersistenceContext private EntityManager em;
@Produces @RequestScoped
protected EntityManager createEntityManager() {
return this.em;
}
}
In the "test/batch" jar only on teh classpath for UT/batch:
----------------------------------------------------------------------------------
In beans.xml:
<alternatives><class>com.saq.depot.util.EntityManagerTestProducer</class></alternatives>
What works ("alternative" producers picked up 100% of the time):
@Alternative
public class EntityManagerTestProducer extends EntityManagerProducer {
@Produces @RequestScoped @Alternative @Specializes
public EntityManager createEntityManager() {
EntityManagerFactory emf =
Persistence.createEntityManagerFactory("SAQDepotJPATest");
EntityManager em = emf.createEntityManager();
return em;
}
}
What does not work ("alternative" producers picked about once in two,
don't know why):
@Alternative
public class EntityManagerTestProducer {
@Produces @RequestScoped @Alternative
public EntityManager createEntityManager() {
EntityManagerFactory emf =
Persistence.createEntityManagerFactory("SAQDepotJPATest");
EntityManager em = emf.createEntityManager();
return em;
}
}
2013/3/12 Gerhard Petracek <[email protected]>:
> hi,
>
> placing the two classes in two jar-files is perfectly fine.
> i've never seen the "random" effect you mentioned.
>
> regards,
> gerhard
>
>
>
> 2013/3/12 titou10 titou10 <[email protected]>
>>
>> This is almost exactly what I'm doing with maybe 2 small differences:
>> - my two producers are in two different jars, the unit-test/batch one
>> annotated with @Alternative is in a jar that is only used during
>> batch/unit test
>> - I didn't annotated the alternative with@Exclude(exceptIfProjectStage
>> = ProjectStage.UnitTest.class) as the jar is only on the classpath
>> when running batch/unit test. Will adding this annotation make OWB
>> use *this* @Alternative producer instead of the not "not alternative"
>> one? looks very strange to me..
>>
>> Still don't undertand why the producer annotaded with @Alternative is
>> only pick up by OWB at runtime from time to time
>>
>> (BTW DS @Exclude is only usable on classes, not on producer methods...)
>>
>>
>> 2013/3/12 Gerhard Petracek <[email protected]>:
>> > 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
>> >> >
>> >> >
>> >> >
>> >
>> >
>
>
