JBossDeveloper

Salut Marko,

we testet this multiple times, no LineItemAccessDao exists only once!

unzip ear gives:

    testing: META-INF/MANIFEST.MF     OK

    testing: lib/as24BillingCommon.jar   OK

    testing: lib/as24BillingService.jar   OK

    testing: as24BillingWeb.war       OK

    testing: as24BillingEJB.jar       OK

    testing: META-INF/                OK

    testing: META-INF/application.xml   OK

    testing: META-INF/maven/          OK

    testing: META-INF/maven/de.as24.billing/   OK

    testing: META-INF/maven/de.as24.billing/as24BillingEAR/   OK

    testing: META-INF/maven/de.as24.billing/as24BillingEAR/pom.properties   OK

    testing: META-INF/maven/de.as24.billing/as24BillingEAR/pom.xml   OK

    testing: org.eclipse.persistence.moxy-2.4.0.jar   OK

    testing: org.eclipse.persistence.core-2.4.0.jar   OK

    testing: org.eclipse.persistence.asm-3.3.1.v201206041142.jar   OK

    testing: junit-4.11.jar           OK

    testing: hamcrest-core-1.3.jar    OK

The  calculation enginne, that is called by the EJB is located in

the  lib/as24BillingService.jar.

unzip lib/as24BillingService.jar has:

  inflating: META-INF/MANIFEST.MF   

   creating: de/

   creating: de/as24/

   creating: de/as24/annotation/

   creating: de/as24/billing/

   creating: de/as24/billing/helpers/

  inflating: de/as24/billing/helpers/TimestampAdapterJAXB.class 

   creating: de/as24/billing/persistence/

   creating: de/as24/billing/persistence/billingclasses/

  inflating: de/as24/billing/persistence/billingclasses/DebitPosition.class 

  inflating: de/as24/billing/persistence/billingclasses/DebitStateMachineBean.class 

  inflating: de/as24/billing/persistence/billingclasses/ResultClassDebitPosCandidate.class 

   creating: de/as24/billing/persistence/sfclasses/

  inflating: de/as24/billing/persistence/sfclasses/Account.class 

  inflating: de/as24/billing/persistence/sfclasses/Branch.class 

  inflating: de/as24/billing/persistence/sfclasses/Contact.class 

  inflating: de/as24/billing/persistence/sfclasses/ContactRole.class 

  inflating: de/as24/billing/persistence/sfclasses/Contract.class 

  inflating: de/as24/billing/persistence/sfclasses/Debtor.class 

  inflating: de/as24/billing/persistence/sfclasses/DiscountType.class 

  inflating: de/as24/billing/persistence/sfclasses/LineItem.class 

  inflating: de/as24/billing/persistence/sfclasses/LineItemDiscount.class 

  inflating: de/as24/billing/persistence/sfclasses/LineItemPrice.class 

  inflating: de/as24/billing/persistence/sfclasses/PackageInterval.class 

  inflating: de/as24/billing/persistence/sfclasses/Price.class 

  inflating: de/as24/billing/persistence/sfclasses/PriceLevel.class 

  inflating: de/as24/billing/persistence/sfclasses/Product2.class 

  inflating: de/as24/billing/persistence/sfclasses/ProductDiscount.class 

  inflating: de/as24/billing/persistence/sfclasses/ProductPackage.class 

  inflating: de/as24/billing/persistence/sfclasses/TaxRecord.class 

  inflating: de/as24/billing/persistence/sfclasses/Unit.class 

   creating: de/as24/exceptions/

  inflating: de/as24/exceptions/As24BillingException.class 

  inflating: de/as24/exceptions/As24BillingFunctionalException.class 

  inflating: de/as24/exceptions/As24BillingJAXBMarshallingException.class 

  inflating: de/as24/exceptions/As24BillingTechnicalException.class 

   creating: de/as24/service/

   creating: de/as24/service/billing/

   creating: de/as24/service/billing/dataif/

  inflating: de/as24/service/billing/dataif/CalculateDebPosTaskIf.class 

   creating: de/as24/service/billing/interf/

  inflating: de/as24/service/billing/interf/CalculateBillingIf.class 

  inflating: de/as24/service/billing/interf/DebitStateServiceIf.class 

  inflating: de/as24/service/billing/interf/FinalizeOutstandingIf.class 

  inflating: de/as24/service/billing/interf/LineItemServiceIf.class 

  inflating: de/as24/service/billing/CalculateBillingBean.class 

   creating: de/as24/service/calendar/

  inflating: de/as24/service/calendar/CalendarService.class 

  inflating: de/as24/service/calendar/CalendarServiceIf.class 

  inflating: META-INF/beans.xml     

warning:  stripped absolute path spec from /META-INF/maven/

   creating: META-INF/maven/

warning:  stripped absolute path spec from /META-INF/maven/de.as24.billing/

   creating: META-INF/maven/de.as24.billing/

warning:  stripped absolute path spec from /META-INF/maven/de.as24.billing/as24BillingService/

   creating: META-INF/maven/de.as24.billing/as24BillingService/

  inflating: META-INF/maven/de.as24.billing/as24BillingService/pom.properties 

  inflating: META-INF/maven/de.as24.billing/as24BillingService/pom.xml

and the EJB-JAR has some beans that delegates to the service and

besides implements our LineItemAccessDao

    testing: META-INF/MANIFEST.MF     OK

    testing: META-INF/                OK

    testing: META-INF/beans.xml       OK

    testing: /META-INF/maven/         OK

    testing: /META-INF/maven/de.as24.billing/   OK

    testing: /META-INF/maven/de.as24.billing/as24BillingEJB/   OK

    testing: META-INF/maven/de.as24.billing/as24BillingEJB/pom.properties   OK

    testing: META-INF/maven/de.as24.billing/as24BillingEJB/pom.xml   OK

    testing: META-INF/persistence.xml   OK

    testing: de/                      OK

    testing: de/as24/                 OK

    testing: de/as24/billing/         OK

    testing: de/as24/billing/businessbean/   OK

    testing: de/as24/billing/businessbean/controller/   OK

    testing: de/as24/billing/businessbean/controller/pricing/   OK

    testing: de/as24/billing/businessbean/controller/pricing/type/   OK

    testing: de/as24/billing/businessbean/controller/pricing/type/PricingResultDO.class   OK

    testing: de/as24/billing/businessbean/controller/pricing/PricingController.class   OK

    testing: de/as24/billing/ejbeans/   OK

    testing: de/as24/billing/ejbeans/billing/   OK

    testing: de/as24/billing/ejbeans/billing/scheduleutil/   OK

    testing: de/as24/billing/ejbeans/billing/scheduleutil/QueueControlBilling.class   OK

    testing: de/as24/billing/ejbeans/billing/BillingSchedulerMdb.class   OK

    testing: de/as24/billing/ejbeans/billing/DebitPositionTrigger.class   OK

    testing: de/as24/billing/ejbeans/mailing/   OK

    testing: de/as24/billing/ejbeans/mailing/SimpleInfoMailGatewayBean$1.class   OK

    testing: de/as24/billing/ejbeans/mailing/SimpleInfoMailGatewayBean.class   OK

    testing: de/as24/billing/persistence/   OK

    testing: de/as24/billing/persistence/billingclasses/   OK

    testing: de/as24/billing/persistence/billingdao/   OK

    testing: de/as24/billing/persistence/billingdao/DebitStateDao.class   OK

    testing: de/as24/billing/persistence/sfclasses/   OK

    testing: de/as24/billing/persistence/sfdao/   OK

    testing: de/as24/billing/persistence/sfdao/LineItemAccessDao.class   OK

    testing: de/as24/billing/servicebeanimpl/   OK

    testing: de/as24/billing/servicebeanimpl/DebitStateServiceJpaImpl.class   OK

No errors detected in compressed data of as24BillingEJB.jar.

Our lib/Service models the calculation engine. Each data access uses injects In order

to retrieve data, In a test case, this will inject an instance of a mocking class and

for our EAJ usage, the inject will render us an instance of an dao.

So the delegate lib/Service jar may call back the EJB.

Maybe this circular dependency mess up WELD?

Thank you

Christian

Dear Marko,

ya right, that was too much information. I will shrink down the code and will sent it

to you. Antother thing is, we do not use arquillian. Since the calculation engine  is

outside the EJB project, we do not need arquillian.

I'll come back to you soon.

Many thanks for your assistance.

Christian

Salut Marko,

sorry for the delay. I managed to write a very simple JEE(EJB) application, that

is using CDI in order to call  a @RequestScope service.

You may find that archive under my initial post (see https://community.jboss.org/servlet/JiveServlet/download/793442-77313/CdiTestMack.tgz)

This archive contains a multi-maven project, with a EJB-subproject and an sercide-subproject.

You should be able to run this application without any problems. The application has a

time methode, that will run the CDI test automatically 1 minute after deploiyment.

State: When we swithed from JBoss6.1 to Jboss-7.1 we ran into several problems,

caus the new app server works different. This may caused our deployment problem

with CDI, anyway CDI stiill does not work inside the Stateless session bean,

cause it in not able to instantiate the RequestLevel bean and simply cause a

NullPointer Exception when tryinig to call the service.

Note: The JpaDataSvc class is the exact copy of the LineItemAccessDao you were

asiking for in the previous mail

As you may notited, we do not use aquillian. Out aim is to test the calculation engine

(CalculationEngineExmp01Impl). Out aim is to call the Calculation Engine outside

fom the EJB.

For this reason, there is a src/test/java source-folder in the CdiTestMackService

subproject, that can invoke the CalcEngine.  A simple mocking class in the test

directory will implement DataSvcIf interface and mock the functionality/data.

Since both execution environment

1) runtime/ejb

2) junit/test

will have exactly one implementation of a DataSvcIf interface, the test shall

work.

In about 1 hour i will send you an update with a functional Junit test, that succefully

use deltaspike and weld.1.1.10 to perform Junit test.

(i'll have to go to a meeting now)

Feel free to send me further questions if you want!

Groovy

Salut John,

i uploaded a maven example under (https://community.jboss.org/servlet/JiveServlet/download/793442-77313/CdiTestMack.tgz).

This archive contains a maven JEE project using CDI. The implemented SessionBean is activated with a time and tries to

access a service, that is injected via CDI. Unfortunately, the test throws a NullPointer Exceptiion beacause of a CDI inject failure.

Simply build and deploy the applicaiton and then wait a little bit (approximately 1 minute)

Trusting to hear from you seon.

Christian

Hy Marko,

sorry META-INF/META-INF was a copy problem, sorry an oversight i did not recognize.

Now i'll get a WELD-001408, but there is not any ambiguity. The working set of the ear

has only one implementation, for each Interface-reference that is beeing injectd:

CalculationEngineExmp01Impl implements CalculationEngineIf

class CalculationEngineExmp01Impl implements CalculationEngineIf

As the Highlander used to they: There can be only one and in fact, there is only

one implementation for each interface !!!!!

Thanks for your support

Groovy

Hello Marko,

Hello John,

bean.xml were in two cases in the wrong place! Ya right.

But i still get an exprection. Hold on, i'll publich my new

maven soon, cause the Junit is working, but EJB not !

Groovie

Salut Marko,

Salut John,

ok, its running. There was another bug in my test application (weired calcengine implementation ;-)

but now its is working. Sorry Marko and John for the confusion i made.

We migrated from JBoss6 to 7 and got messed up.

Exhausitve digging in my code as well as some minor incompatibilities

in both app servers went me dizzy. Sometimes you are beginning to see

directories, that do not exisit. Sorry !

OK, here you may find a use case for a practical use of CDI, that

helps to test functional application code outside an EJB, without

aquillian.

We are lucky to have a test-case, that runs out of the box, driven

by maven. For neebees it is  sometimes hard to bring all things

together.

Thank you for your support and have a nice weekend.

Christian (Groove)

https://community.jboss.org/servlet/JiveServlet/download/793442-77333/CdiTestMack_corrected.tgz

Self-praise is no recommendation.