Monday, August 17, 2009

Nice NetBeans/Maven integration

Just found this pretty cool feature in the latest 6.8 M1 release of NetBeans... when working with Maven project, you can, of course setup dependencies on other Maven libraries, but 'native' NetBeans projects don't have this ability -- you can only setup dependencies to other Projects, to 'Libraries', and to random .jar files... however, NetBeans now has the ability to create Libraries from Maven libraries, and then use those in any projects... check this out...

Open the Maven Repository Browser (Window -> Other -> Maven Repository Browser if you haven't seen this before), and find a project you're interested in by either browsing or searching... once you're here, right click on the version you want, and select 'View Details', like so:



This brings up the details of the .pom file, which has all sorts of good stuff, but the cool part is the icon of the stack of books in the upper right -- click this, and it will automatically download the project and set it up as a NetBeans Library, for use in any project... pretty sweet!


Of course, this may have been here all along -- if anyone knows of a prior version of NetBeans that this works with, chime in!

M


Thursday, August 6, 2009

What's cool in Java EE 6 -- Singleton EJB's and Pruning

Well, with the all the excitement about the addition of JSR 330 Dependency Injection into the EE 6 platform, I figured I'd switch gears a bit and talk about the changes in a different spec -- this time, the EJB spec... Now, this spec is enormous -- 618 pages to be exact -- but luckily, we can ignore most of it! I mean seriously, who wants to read about EJB QL, 2.1 Client Views and the like... I'd rather dig into the meatier stuff, like...

Singleton Session Beans
We all know the Singleton pattern -- it may be one of the most well known designs patterns, and it's easy to understand... basically, if something's a singleton, then there's only one of 'em... ever... that means if you lose it or break it, it's gone for good... ok, that last part isn't true, and really the parts before that aren't quite true, either -- in most implementations of the Singleton pattern, folks conveniently forget to account for the fact that Enterprise applications often live in clusters, and instead they make singletons so that there is only one per virtual machine... most of the time this is fine -- they're often used for things like Service Locators, which were used back in the olden days of EJB 2 as a convenient way to do all the nasty JNDI lookups for EJB's...

Enter Singleton Session Beans... these are pretty much what you'd expect them to be -- an EJB that you can only find one of per JVM (the spec is specific about that last part, so really, they're only Singletons part of the time)... frankly, I was somewhat underwhelmed when I first heard of them, but they do add one interesting capability that I've needed on several EJB applications in the past, and have never had in an easy, portable way to pull off -- the ability to execute on application startup...

This can be achieved with a few simple annotations, like so:

@Singleton
@Startup
public class InitBean {
@PostConstruct
@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
public void initializeSomeStuff() {
...
}



I know, lot's of annotations on that sucker, but it's pretty straight forward:
  • @Singleton -- defines this as a Singleton Session Bean... big surprise here, eh?
  • @Startup -- this is an indication to the app server that this class must be created and initialized at application startup, and yes, the spec uses the 'must', so there's no soft language here
  • @PostConstruct and @TransactionAttribute -- these are the old tags that we all know and love...
Anyone who's read this blog before may notice a hidden gem in here that makes all of this worthwhile... I'll give you a hint -- go read this entry on @PostConstruct... yes, that's right, this is a Transactional @PostConstruct method... and it will work! They got this one right when they wrote the EJB 3.1 spec, in that it guarantees that @PostConstruct methods will obey your @TransactionAttribute attributes! Now if only they would extend this capability to all EJB's, we'd have all of our problems solved! Ok, perhaps not all of them...

So anyway, you can do pretty much whatever you want in here, including initializing 3rd party systems, creating timers, sending email, truncating all of your database tables, etc... what most intrigues me, though, is data bootstrapping, similar to what you get with the Grails Bootstrap class:

...

@PostConstruct
@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
public void setupUserData() {

List expectedUsers = getExpectedUsers();

for (User u : expectedUsers) {
User found = em.find(User.class, u.getId());
if (found == null) {
log.info("Persisting user "+u.getUsername());
em.persist(u);
} else if (!found.equals(u)) {
log.info("Updating user "+u.getUsername());
em.merge(u);
} else {
log.info("No need to update user "+u.getUsername());
}
}
}

...


In other words, this Singleton will ensure that your standard set of users will always be available upon application startup -- if this is something you want only in a development environment, you can configure each machine with environment information via JNDI, System properties, or a configuration that is set in your build so that it only takes these actions on a development environment -- it is a great way to ensure a consistent development environment across your team...

A Word about Pruning
Ok, this is, by far, my favorite feature of Java EE 6 -- and it's not even a feature! That's right, we're finally going to be able to actually remove some of the stuff that's been added to Java EE over the years! This could include a wide variety of things, but just think -- some day in the near future, you won't have to sift through details about Entity Beans, outdated communication protocols like JAX-RPC, EJB Home interfaces... instead, it will all be gone! Unfortunately, this day hasn't come just yet -- they're just telling us that they're planning to do it some day, but at least it's a step in the right direction... now I have to wonder -- will Java EE 7 actually be a smaller spec than EE 6? Now that would be impressive :)

In the meantime, you can get a little hint of the pruning goodness by taking advantage of the new Web Profile -- this is a nice customization of the spec that removes a lot of the stuff that most folks don't use anyway, but that is still pretty useful in some cases... unfortunately, you still do have to thumb past all of the extra stuff if you decide to go diving into the spec documents...

Conclusion
It seems odd to me that it took so long for Java EE to standardize such a simple, but useful piece of functionality as startup logic -- to me, this is more important than the fact that this EJB is a (kind-of-)Singleton! Sure, I've always been able to do this through an eagerly loaded Servlet, or with WebLogic or JBoss specific code, but the Servlet solution is just plain weird if I'm not acting upon my web container, and this is obviously more portable than an app-server specific piece of functionality... the above example just seems a little less... dirty to me :)

But who am I to complain about a nice new feature :)

M

Tuesday, August 4, 2009

What's cool in Java EE 6 -- JSR 330?

Hey, interesting timing on this one, given my previous two entries this week -- a blog entry just caught my attention indicating that Java EE 6 is getting a late entry in the form of JSR-330 -- Dependency Injection for Java... I noticed this spec when it was first announced back in May or so, and immediately thought "Oh boy, a direct competitor to Web Beans! This is going to confuse things!"... don't forget, Web Beans was renamed at some point to 'Contexts and Dependency Injection for the Java EE Platform', so these specs appear to be very similar at first glance...

So what's going on here? I haven't the foggiest, but it is interesting that JSR-330 is headed up by Bob Lee and Rod Johnson, the masterminds behind Guice and the Spring Framework -- certainly a pair of heavy hitters in open source Java land... I seemed to recall that Bob Lee had some involvement with Web Beans as well, but he is not listed on the JSR-299 expert group, so it may well have been my imagination...

Another interesting blog by Roberto Chinnici has a little more detail, giving some background behind the decision and indicating that Web Beans will be modified to use the JSR-330 annotations -- I'm quite interested in his last sentence (well, second to last -- the "Stay tuned!" doesn't count), which is a vague reference to reconciling Web Beans with the rest of the spec, especially in regards to Managed Beans... I was actually wondering if anything was going to happen here -- early indications are that a Managed Bean can become a Web Bean by replacing the @ManagedBean annotation with @Named, so why have both, especially if both are included in the Web Profile? At first glance, they seem to both be extremely similar, with Web Beans simply adding a few pieces of functionality -- more digging needs to happen on my part here, for sure...

So what the heck does this mean? Well here's my initial impression:

  • This appears to be a good thing -- one of my pet peeves with the EE spec process is the tendancy to simply not make some hard decisions. This appears to be a pretty bold move, and may have prevented a situation where we have three distinct DI mechanisms in the standard (the original @EJB/@Resource/@PersistenceContext, the Web Beans @Current and @BindingType, and the JSR-330 @Inject and @Qualifier annotations)
  • It is an interesting turn of events for SpringSource, which has appeared poised to become a possible implementation of the Web Profile with their new tc Server, or even a full fledged app server with the dm Server -- this certainly seems to indicate the direction they plan to go
  • Gavin King must be pissed :)... ok, so I have no idea about this one, but it will be interesting to see how it turns out anyway...
  • We may end up with a slightly more cohesive web framework if, for example, Managed Beans and Web Beans are combined, but we have yet to see what direction this is going to go -- certainly interesting! If I'm correct in my understanding of the similarities between the two types of objects (and I may very well be incorrect at this point), one could make do by always using the Web Beans version, which makes @ManagedBean dispensable...
So my ears will definitely be open to movement in this space... nothing like an 11th hour addition to the spec which may cause changes in two or more existing and 'finalized' specs to make things interesting!

M

Saturday, August 1, 2009

More cool in Java EE 6 -- JSF 2.0, Bean Validation

There's definitely more cool stuff in JSF 2.0 that I didn't get to last time -- so let's get right to it...

Annotations for Converters and Validators
The @FacesConverter and @FacesValidator annotations are nice little additions to the framework... they're simple to use -- you write your converter and validator classes in the same way as you always did, but instead of needing to crack open your already-way-too-large-faces-config.xml and look up the syntax for the converter tags, you can now rely on your IDE to help you out -- just throw @FacesConverter on the class with the 'forClass' attribute, and it will automatically register that converter for all form fields of the appropriate class... it doesn't get much easier than that, and of course you can use the 'value' attribute in the same way you used to use the 'converter-id' tag in the faces-config.xml, and then reference it in any of your pages...

Ok, you're saying -- so I get to add a line to my class file and take four lines out of an xml file -- so what? But wait, there's more -- and this is my favorite part... throw an empty faces-config.xml file in your META-INF folder, and these converters and validators will automatically be registered for any JSF web app that includes this jar! This is a great mechanism to promote reuse -- create a utility component that has a bunch of these files, and every one of your web apps can get them with a couple of lines in a Maven .pom file (or whatever it is you use for your builds)... I suspect it won't take long for standard sets of converters and validators to become available in component libraries like RichFaces or IceFaces...

Bean Validation
Speaking of validation, here's where it gets interesting -- with the new Bean Validation integration, it's no longer necessary to think about validation just in terms of JSF... I personally believe that validation could be better approached as an integral part of a well designed domain model (think Domain-Driven Design here), so putting that logic in a JSF specific validator has always seemed awkward -- likewise, adding a 'validate()' method that needs to be called while processing a form submit or just before persisting your object (in the case of a JPA Entity, for example) is just as awkward, if not worse... not only that, but many applications are more than just web apps -- some have batch-processing or scheduled aspects to them which don't have any exposure to JSF... using JSF validators in these cases would be a bit smelly, and duplicating the code is even worse -- this is where Bean Validation comes in...

With the annotations in the javax.validation.constraints package, we can now annotate our domain fields with things like @Min, @Max, @NotNull, @Pattern, etc, so that the validation rules that our domain objects abide by are defined right along-side the fields themselves... there is, of course, an API available for evaluating the rules against a given object, but here's where it gets cool -- JSF and JPA both provide support for this automagically! That means whenever you have a domain object that is exposed through a ManagedBean in a form, the validation rules will be executed for you, and any failures are made available through the standard h:message tags! Not only that, but the validation can also be executed when you persist or merge your domain object via JPA, so batch-processing applications are covered as well -- very cool...

A very similar incarnation has been available through the Hibernate Validation and Seam projects, but it is great to see this get worked into the standards... The basic constraints here are lean, but take care of most use cases -- I have experimented with some simple custom validators, but am looking forward to getting into some more complex rules with multiple fields and see how it handles them...

Still more?
There's still more stuff in EE 6 that I'd like to talk about, including the Facelets support and the new Composite Component stuff, but I need to do a little more fiddling with that -- I came across the new 'Behavior' API as well, which looks like a slick way to make your components do what you want, as well as make them extensible... At some point, I'm going to get my hands on Web Beans, the new JPA 2.0 capabilities, Singleton EJB's, Asynchronous EJB's, etc -- there is a lot of good stuff in this new spec, so stay tuned!

M