Sure and that s why openejb embedded adpater exists too
Le 22 mars 2013 10:37, "Mark Struberg" <[email protected]> a écrit :

> I use Arquillian too, but only if I only need to test single classes in
> different environments/configurations.
>
> Arquillian is really perfect for testing framework stuff (which _you_ will
> do most of the times). But once you do more complex real world business
> projects it's a nightmare to get the @Deployment right. Either you mock
> away all stuff or you need add tons of stuff for each test.
> In such a 'business' case it's much easier to just startup an embedded
> container and perform your unit tests against the 'real thing'.
>
> Of course, I'm aware that this is 'unit testing with a grain of
> integration test salt' :) But in practice this is a good compromise between
> doing 'pure unit tests' (which are very restricted and most times you more
> or less mostly test your mocks and not your own implementation) and fully
> blown integration tests (which are slow and painful to do). But that's
> almost a philosophical question already ;)
>
>
> LieGrue,
> strub
>
>
>
>
>
>
> >________________________________
> > From: Romain Manni-Bucau <[email protected]>
> >To: Mark Struberg <[email protected]>; [email protected]
> >Sent: Friday, March 22, 2013 9:44 AM
> >Subject: Re: WG: Transaction Rolled back in decorator or service even
> exception is catched
> >
> >
> >@Mark you are the single one i know to do so, arquillian seems more
> common and easy from my window
> >Le 22 mars 2013 09:38, "Mark Struberg" <[email protected]> a écrit :
> >
> >
> >>
> >>Hiho!
> >>
> >>
> >>Afaik WAS-8.0.0.x uses owb-1.0.1 with a few selected bugfixes which got
> backported.
> >>
> >>We have fixed quite a few issues which could cause this behaviour in
> later owb versions.
> >>
> >>
> >>Do you have access to the latest WAS-8.5.0.x for running the test? Or at
> least upgrade to WAS-8.0.0.2.
> >>8.0.0.1 is known to have quite some issues.
> >>
> >>
> >>LieGrue,
> >>strub
> >>
> >>
> >>PS: seems to be a quite common pattern to use DeltaSpike cdictrl with
> openejb for testing if WAS is used in production - have the same setup for
> a few customers, and they are happy to have some tests now ;)
> >>
> >>
> >>
> >>>________________________________
> >>> From: Thomas Herzog <[email protected]>
> >>>To: [email protected]
> >>>Sent: Friday, March 22, 2013 8:08 AM
> >>>Subject: WG: Transaction Rolled back in decorator or service even
> exception is catched
> >>>
> >>>
> >>>Hi guys
> >>>
> >>>I have the following problem.
> >>>
> >>>I have a  EJB service which is decorated.
> >>>This decorator calls another EJB service and catches its thrown
> Exception (RuntimeException annotated with
> @ApplicationException(rollback=”true”)).
> >>>I get an InvocationTargetException, that’s the first catch. But the
> transaction is marked a rollback only even the exception is catched.
> >>>If I have a ejb service method which catches the thrown exception
> within the service method and here the same issue occurs.
> >>>
> >>>The EJB service are annotated with:
> >>>@Stateless
> >>>@TransactionManagement(TransactionManagementType.CONTAINER)
> >>>@TransactionAttribute(TransactionAttributeType.REQUIRED)
> >>>
> >>>EJB Service method (Saves an assignment):
> >>>
> >>>    @Override
> >>>    publicCarrierHasCompanyCategoryEntry
> saveCarrierToCustomerAssignment(CarrierHasCompanyCategoryEntry assignment) {
> >>>
> carrierDataAccessLocator.getCarrierDataAccess().checkForExistingCarrier(assignment.getId().getCarrierId());
> >>>        returndataManager.merge(assignment);
> >>>    }
> >>>
> >>>Decorator (checks for exisiting assignment, to determine which event
> shall get fired):
> >>>
> >>>    @Override
> >>>    publicCarrierHasCompanyCategoryEntry
> saveCarrierToCustomerAssignment(CarrierHasCompanyCategoryEntry assignment) {
> >>>        Boolean active = null;
> >>>        Boolean newAssignment = null;
> >>>
> >>>
> >>>        // Get active value of existing assignment / CarrierDateAccess
> is annotated with @Stateless
> >>>        try{
> >>>            CarrierHasCompanyCategoryEntry assignmetDB =
> carrierDataAccessLocator.getCarrierDataAccess().checkForExistingAssignment(assignment.getId());
> >>>active = assignmetDB.getActive();
> >>>newAssignment = Booelan.FALSE;
> >>>        } catch(Throwable e) {
> >>>            // If throw the transaction will be rolled back
> >>>            e = ExceptionUtils.unwrap(e,
> InvocationTargetException.class);
> >>>            if(!(e instanceofAssignmentNotFoundException)) {
> >>>                thrownewCoreException(e);
> >>>            }
> >>>        }
> >>>
> >>>        assignment =
> delegate.saveCarrierToCustomerAssignment(assignment);
> >>>
> >>>        // If new assignment has been created
> >>>        if(newAssignment) {
> >>>
> assignedToCustomerEvent.fire(newCarrierAssignedToCustomerEvent(assignment));
> >>>        }
> >>>        // If assignment has been updated
> >>>        else{
> >>>            // If state has been changed
> >>>            if(!active.equals(assignment.getActive())) {
> >>>                if(assignment.getActive()) {
> >>>
> carrierActivatedEvent.fire(newCarrierActivatedEvent(assignment));
> >>>                } else{
> >>>
> carrierDeactivatedEvent.fire(newCarrierDeactivatedEvent(assignment));
> >>>                }
> >>>            }
> >>>        }
> >>>
> >>>        returnassignment;
> >>>    }
> >>>
> >>>Here  I face the same issue (@Stateless):
> >>>
> >>>    @Override
> >>>    public User generateDefaultAdminUser(final Carrier carrier) {
> >>>        final Carrier carrierDB =
> coreDataAccessLocator.getGenericDataAccess().byId(Carrier.class,
> CarrierNotFoundException.class, carrier.getId());
> >>>        final SecureRandom random = new SecureRandom();
> >>>        String username = null;
> >>>        String password = null;
> >>>
> >>>        // Check for already existing user credentials
> >>>        for (int i = 0; i < 5; i++) {
> >>>            try {
> >>>                username =
> RandomStringUtils.random(MIN_PASSWORD_LENGTH, 0, 0, Boolean.TRUE,
> Boolean.TRUE, null, random);
> >>>                password = RandomStringUtils.random((2 *
> MIN_PASSWORD_LENGTH), 0, 0, Boolean.TRUE, Boolean.TRUE, null, random);
> >>>
> carrierDataAccessLocator.getUserDataAccess().getUserByUsername(username);
> >>>                if (i == 4) {
> >>>                    throw new InternalErrorException("Could not
> generate the usernamee and password for the admin user 5 times in a roll
> !!!");
> >>>                }
> >>>            } catch (UserNotFoundException e) {
> >>>                break;
> >>>            }
> >>>        }
> >>>
> >>>        User user = new User();
> >>>        user.setAdimn(Boolean.TRUE);
> >>>        user.setCarrier(carrierDB);
> >>>
> user.setContact(dataManager.merge(carrierDB.getDefaultContact().clone()));
> >>>        user.setEnabled(Boolean.TRUE);
> >>>        user.setLastPasswordChangeDate(Calendar.getInstance());
> >>>        user.setUsername(username);
> >>>        user.setPassword(password);
> >>>
> >>>        return dataManager.merge(user);
> >>>    }
> >>>
> >>>The funny thing is that the test with deltaspike-cdi-ctrl, openEjb and
> openwebbeans do work.
> >>>Is that a bug in webspehere embedded openwebbeans ?
> >>>
> >>>TestLibs:
> >>>deltaspike-cdictrl-api-0.3-incubating.jar
> >>>deltaspike-cdictrl-openejb-0.3-incubating.jar
> >>>openejb-lite-4.5.1.jar
> >>>was_public.jar
> >>>
> >>>Productive:
> >>>Websphere 8.0.0.1
> >>>OWB version ? (ibm secret)
> >>>
> >>>For addition, we faced the issue that the decorated method must be the
> first called on the delegate before any other method gets invoked,
> otherwise decorator chain will be broken.
> >>>The second is that the thrown Exceptions are not unwrapped and will be
> InvocationTargetExceptions.
> >>>
> >>>For now I solved it with an additional method parameter (Boolean) which
> indicates that the assignment is a new one, so that the
> AssignmentNotFoundException can never occur.
> >>>
> >>>Mit freundlichen Grüßen
> >>>
> >>>Thomas Herzog
> >>>Softwareentwicklung
> >>>
> >>>curecomp Software Services GmbH
> >>>Hafenstrasse 47-51
> >>>4020 Linz
> >>>
> >>>web: www.curecomp.com
> >>>e-Mail: [email protected]
> >>>tel: +43 (0)732 9015-5563
> >>>mobile: +43 (0)664 8867 9829
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >
> >
>

Reply via email to