Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Some More Java EE 6 Musings

DZone's Guide to

Some More Java EE 6 Musings

· Java Zone
Free Resource

Find your next Integration job at DZone Jobs. See jobs focused on integration, or create your profile and have the employers come to you!

Been doing a new project using Java EE 6, starting with some domain model code. Here are some comments about various aspects of the 6 v. 5 experience thus far.

Domain Programming with TDD

You can‘t get apps to do much of anything without some domain classes. I used the Weld Archetype to create the project. The archetype has evolved over the year(s). One of the things that's kind of interesting is that the controller classes are not named controller and are where the actual manipulation of the entities occurs. The type-safe repository (really just an EntityManager with an annotation on it), is injected in and the queries, etc., are done right in the 'controller.' The classic simplistic modeling approach is to have a single monolithic repository for each entity, then create Controllers that expose those things to the ui and coordinate some of the activities. When I first saw this approach, I remembered that some of the documentation I'd read around the CDI spec talked about event orientations. I kind of like this approach. The great Jacobsen book about Aspects discusses the separation of concerns driving the first part of design, and the recombination of those concerns when collaborations are required is where complexity can go crazy. One of the things that this approach brings to the fore is really a very interesting question: as time wears on, is anything gained from having all the operations of a given entities repository in one place? The answer is definitely no. For instance, you might have a Patient class. By the time you get to the end, you could have manipulations for admitting and discharging them, getting them medication, diagnosing them, analyzing them, etc. The repository is likely to be a garbage pit of stuff that is frankly not really related to each other but by the most tenuous concept (the Patient). In Objective-C, this problem is dealt with using Categories. Personally, I like the idea of doing some kind of mixture model where you break down the realms into distinct interfaces, then you might have a simple amalgamation of those into one conceptual ball (perhaps a package, though package design is pretty nonexistent in Java). (I am folding back on my prior post about Role Classes.)

When I was writing this code over the weekend, I had occasion to walk through hell. It all happened because I was injecting a bean that would represent the current Facility. In 5 I would have made a Session scoped bean and defined some kind of factory for creating it. In 6, I made a factory class that had a Produces method. I was kind of surprised that it was telling me there was ambiguity. Facility is an Entity, so why? is it trying to say it could inject that? 6 is different that way. So the simple solution was to put a qualifier on the Produces method. Here‘s where things went kind of dark: eclipse stopped complaining, and I thought I was good but the tests kept failing. Turned out, after a bunch of grief, it was because I had forgotten to add the Qualifier (an annotation) class to the Arquillian/Shrinkwrap list of classes. What sucks is if Arquillian is missing another class, you will no doubt hear about it. It failed silently in this case.

Which brings me to my last point. I have been doing some 5 work and some 6 work. Overall, 6 is awesome, dying to be doing only 6 ASAP. But, also, 5 is not that bad, as I was doing it. Here are the key caveats. Seam is so much better than Spring it‘s really laughable. I could not imagine doing Spring again. Just conversations and outjecting. But also, the Seam tests that we were doing in 5 were pretty bloody good. Am I going to end up liking Arquillian a lot better? yes, but, the business of having to list the classes is an achilles heel. Is it DRY? It‘s kind of stupid DRY, but it generally is VERY bad to have to remember to configure things in multiple places. Having to remind myself ‘der, meathead, you just added a qualifier, remember to go stick it into the class list,‘ is fraught with suckiness. The great thing about Arquillian is once you get going, it really has a great flow. I have JB6 running and I just keep rerunning the tests and the console is much cleaner. I had some funny thoughts about how the classes thing might be solved. Some of them fell into that zone of like ‘this is either absolute genius, or an episode of Lancelot Link..‘ The star of that one was the idea of doing a testbuilder that you use to run your test that would catch broken stuff and help you fix it. So, in other words, you write the test, and run it in the builder and it would catch things like missing classes, etc., and give you one clicks to fix them, then when the test was functioning, you could just drop it into the runner and go about your business.

BTW, I did install JBoss 7, based on Max Andersen‘s blog post about being able to use Indigo with an early release. Damn if the thing doesn‘t start in 2.5s.. (so those 200 tweets from the Red Hat guys seem to have an emprical basis, I‘m happy to report).. Looking forward to that, but the Indigo setup is not really usable for much right now…

 

From http://www.jroller.com/robwilliams/entry/little_more_exposure_to_arquillian

Find your next Integration job at DZone Jobs. See jobs focused on integration, or create your profile and have the employers come to you!

Topics:

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}