Java EE Maven Archetype (BCE / ECB) v0.0.2 - With Arquillian

Unit tests, integration tests and Java EE -- an endless stream of questions. The Java EE Maven Archetype comes with both.

Execute the following archetype from the command line choose the version v0.0.2 to create a sample "workshops" project:


mvn archetype:generate -Dfilter=com.airhacks:javaee-bce-archetype

The sources of the sample project are also available directly: https://github.com/AdamBien/javaee-bce-pom.

Feedback is highly appreciated!

See you at airhacks in Munich and each first Monday of the month at 6 P.M. (CET) airhacks.io

Comments:

How do I run integration tests? mvn test does not trigger them, nor the mvn integration-test

Posted by zemiak on June 30, 2014 at 11:52 AM CEST #

Hello Adam,greetings from Athens Greece. May I suggest the following updates to the pom?

1. arquillian-bom.version to 1.1.5.Final
The 1.1.4 had a bug you could create archives that were not valid but the test would not fail. It was release a couple of days ago.

2. Also on top of the arquillian-bom I would add it's sibling shrinkwrap one, since it contains the depchains for handy resolvers and extensions. If anyone is going to write a test most probably he/she going to end up, using one of the apis included on this lib.

<groupId>org.jboss.shrinkwrap.resolver</groupId>
<artifactId>shrinkwrap-resolver-bom</artifactId>

That is all for now. Thanks keep up the good work and many thanks for your posts.

Posted by Paris Apostolopoulos on June 30, 2014 at 06:32 PM CEST #

Hi Adam,

In my opinion the Registrations class is in the wrong package. It should be in the control package.

The main reason is because the Registrations class uses the EntityManager to interact with entities.

http://de.wikipedia.org/wiki/Robustheitsanalyse

Kind regards,
Simon

Posted by Simon Martinelli on July 08, 2014 at 09:59 AM CEST #

@Simon Martinelli
In Adam's variant of the ECB pattern the 'control' package is optional and contains reusable classes that can only be seen by boundaries.
In this example Registrations is a java specific boundary service and RegistrationsResource acts as an rest-specific protocol adapter.
If your archive is bundled with a JSF application, instead of accessing the data via the rest endpoint, the Registrations boundary can be injected directly in the controllers of your pages, so that no additional serialization overhead is needed.
The EntityManager already is a generic DataAccessObject and can be injected in the boundary, but if you are using the criteria api you could wrap the EntityManager and the criteria operations inside a reusable control service and inject this one instead of the EntityManager itself.
If all classes containing a EntityManager were packaged inside the 'control' package, in projects with simple crud operations a lot of empty delegates would be the result.
Only if it makes sense and you need some code multiply times in different boundaries or you have helper classes, they should be packaged as 'control'. Refactored EJBs can be marked with the TransactionAttribute.MANDATORY, so that a TransactionRequiredException will be thrown if, for instance one of your colleagues violates the pattern and uses a 'control' without an already existing transaction started at the begin of a boundary method.
I´m using this pattern in my projects and it works great! :)

Posted by Patrick Leitermann on July 12, 2014 at 07:41 PM CEST #

Hi Patrick,

I am using ECB since 1995 and have another opinion about the Registrations class.

But thanks anyway for your explanation.

Posted by Simon Martinelli on July 16, 2014 at 09:55 AM CEST #

Hi again Patrick,

Btw. if using JSF then all JSF artefacts are boundries. And again Registrations will be the controller.

Posted by Simon Martinelli on July 16, 2014 at 09:57 AM CEST #

Hello Simon,
it depends on the perspective of view, because the business and presentation classes are packaged in different packages.
This archetype contains only the separation inside the business layer.

Business Layer (inside package 'business'):
workshops/business/registrations/boundary/Registrations
workshops/business/registrations/boundary/RegistrationsResource
workshops/business/registrations/boundary/Registrations
workshops/business/registrations/control/VatCalculator
workshops/business/registrations/entity/Registration

View in the business layer:
Boundary: Registrations and RegistrationsResource; services that can be accessed by clients (via injection/rest/etc)
Control: Only visible to boundaries of the business layer
Entity: Domain Objects (Registration)

JSF UI (inside package 'presentation'):
workshops/presentation/overview/RegistrationsOverviewBean (responsible for overview.xhtml)
workshops/presentation/create/RegistrationsCreateBean (responsible for create.xhtml)

View in the presentation layer:
Boundary: The ui controller beans (RegistrationsOverviewBean and RegistrationsCreateBean)
Control: The business logic for getting and creating Registration entities, that can be accessed by injecting the Registrations boundary
Entity: Registration objects shown in the user interface

Posted by Patrick Leitermann on July 17, 2014 at 10:50 PM CEST #

Hi Patrick,

Thanks for the outline.
I see now where my confusion comes from.

I use the ECB as it was designed years ago. See http://www.cs.sjsu.edu/~pearce/modules/patterns/enterprise/ecb/ecb.htm

In your example you have
<technical layer>/<business layer>/<technical layer>

I usually hae
<technical layer>/<business layer>

The technical layer is covered by ECB as in described in the linke above.

If Adam has the same opinion as you then I think the usage of ECB is misleading.
Have a look at the description on Wikipedia: http://de.wikipedia.org/wiki/Robustheitsanalyse

Kind regards,
Simon

Posted by Simon Martinelli on July 20, 2014 at 10:57 AM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed
...the last 150 posts
...the last 10 comments
License