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!


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!


What’s cool in Java EE 6 — JSF 2.0

Howdy — been a while since I’ve been around here, but I’ve been fiddling with some of the new technologies in Java EE 6, and figured that this is as good a place as any to start to talk about them :)…

First off, I’ve been working with NetBeans 6.7 and Glassfish v3 Preview (look here for info on how to get the two to work together)… I have plenty of experience with NetBeans, but less with Glassfish — ever since it took forever for JBoss 5 to come out, it has been my App Server of choice for ‘fiddling’ with technologies… it’s really quite impressive, and seems to be one of the places for early access into new technologies…

Anyway, there is plenty of new stuff in EE 6, and one of the areas that shows a ton of improvement is JSF 2.0… Where to start?

So long, faces-config.xml!
Well the most obvious starting point has to be the Annotations… in old-school JSF, any sizable application needed to have every Managed Bean registered in an XML file, which is fine for the smaller examples, but quickly gets to the point of needing to use an appropriate tool to decipher and organize it… Thankfully, this has been replaced by a single (sometimes two) annotations directly on the class, like so:

public class LoginBean {


And no discussion of XML in JSF would be complete without mention of the navigation… not only was this too verbose, but it never struck me as an appropriate place to store navigation information — after all, I already have my Managed Beans and XHTML pages (we’ve all been using Facelets for years now, right?) — why do I need to look in a third place to configure what page an action in a page takes us? Again, manageable, but a bit smelly…

Once again, JSF 2.0 makes an improvement here by allowing us to return the names of our views directly from our Managed Beans — so instead of returning “Success”, and then having to indicate what that really means in another file that’s too big as it is, I can just return “success.xhtml”, and the page will be found for me (in fact, I believe a return of “success” would have the .xhtml added for me, but for some reason the explicit version seems more palatable to me)… and if I want this to be a redirect, it becomes “success.xhtml?faces-redirect=true” — admittedly a bit awkward, but simple and easy to remember…

Ok, this is the really big one — frankly, I am stunned that it has taken, what — 8 years for JSF to add this feature natively (I apologize if that number is wrong, I’m not up to looking up the JSF history right now)… in the past, I have created my links with standard html ‘<a href' tags and used a @PostConstruct tag in my Managed Bean to load whatever data I needed, but frankly it's a hack, and the fact that @PostConstruct operates in an undefined transactional state forces you to jump through hoops, not to mention that circumventing the JSF View lifecycle can be difficult at times… In fact, I was actually quite concerned in the later days of the spec development, because it appeared that this feature was not being taken seriously by the spec group — that Ajax and skinning were more important features than perhaps one of the most basic features of any browser… blog entries by those with ‘inside information’ were coming out as late as early 2009 that seemed to gloss over the demand for bookmarkable features, but thankfully it made it in at the last moment… whew!

There are a couple of items that are important here, but the basic idea is that any page that can be bookmarked (and that requires info from the query string) uses three new tags — f:metadata, to define metadata for a view, f:viewParam, which can take a parameter from the query string and store it in a variable (including conversion, validation, etc), and f:event, which can be used to register an event listener on the new PreRenderViewEvent — it might look something like this:

Alternately, you could simply use the old c:set tag to set the variable in the page, however this appears to store a copy of the variable, which doesn’t work out well if you are later editing or modifying it…

Finally, to create a link to your new-fangled page, there is also the new h:link tag, which follows the same direct navigation rules mentioned above, and that can support the f:param tag to easy include parameters — easy peasy!

To Be Continued…
Ok, this turned out to be longer than expected — I still want to talk about PDL, Events, Annotations for Converters and Validators, Bean Validation integration, Web Beans integration, and plenty more, but that will have to wait for a later date…

The bottom line is that yes, JSF is a viable web framework — it has had its’ problems historically, but the latest version seems to have addressed them quite effectively, and there are plenty of component libraries out there like RichFaces, IceFaces, etc., that can make your apps look and operate great… Hopefully it can shed some of its’ poor reputation (much of it deserved, some of it not) — it’s definitely worth a look!


Java EE reminds me of the government…

Don’t get me wrong — I like Java EE 5… I’m especially a big fan of being able to make a living working with it, but sometimes you run into some weird things that just make you scratch your head…

The government analogy comes from the fact that the @PostConstruct annotation cannot be used in conjunction with a transactional or a security context… It’s almost like a bunch of possibly well meaning but badly misguided (and possibly well bribed) politicians just couldn’t agree on the ‘right’ way to combine these features, so they did the worst thing that they could have done — they simply failed to make a decision… (at least they didn’t do what our esteemed New York State politicians have been doing lately)

I ran into this issue about a year ago while working with JSF Managed Beans… I wanted to use a @PostConstruct method to load data for a view page — I needed to access a few repository beans to load the data properly, and I wanted the Managed Bean to act as a transactional boundary… seemed to be an eloquent way to provide for bookmarkable pages in JSF, which is notoriously difficult… Anyway, I was unable to do this directly, as the semantics for @PostConstruct don’t allow it…

Turns out this is problematic with Spring’s usage of @PostConstruct as well… while experimenting with Spring 2.5 a few nights ago, I setup a quick experiment with some JPA Entities and the new annotation-based dependency injection mechanisms (big fan so far, by the way)… I hacked together a test bean that had a method marked with @PostConstruct and @Transactional, which created a single instance of an Entity and persisted it to the database to test that everything was working… but it didn’t work… no errors, just no data in the database…

I’ve seen this symptom before related to mis-configured transactions, so I looked there first — I copied the JPA code into another method, and marked it with “@Transactional (propagation=Propagation.MANDATORY)”, and it gave me an error because there was no existing transactional context… huh? A little research led me to several articles indicating that these two items can’t work together… Oddly enough, if I put the JPA code into another class, everything worked fine…

This is one of those odd restrictions that makes working with Java EE just a little more annoying than it should be… it’s not a huge deal but it does force you to change your programming style in some cases, and it forces you to think about things you shouldn’t have to think about… Spring’s implementation in this regard is somewhat surprising — after all, Spring isn’t a Java EE container… it seems that they could have made their implementation act a little closer to what you would expect, or, if they’re not willing to distort how the standard annotations work, perhaps they aught to create their own version…

I’m just glad the Java EE standards committee hasn’t figured out a way to tax us yet…


EJB Lite? Now I’m really confused…

Something smells a bit about the Java EE 6 ‘profiles’ discussions from a few weeks back, triggered by Roberto Chinnici’s blog entry here… I’m not talking about the contents of the profiles themselves — although I do have some issues here, that’s for later… what I’m talking about is this concept of EJB ‘Lite’… huh?

Why is this needed? Isn’t WebBeans supposed to provide a light-weight component model, without a lot of the advanced services that EJB provides such as remoting, messaging, etc, that simple websites don’t require? It sounds to me that there is some major disjoint between the various JSR’s that will be making up the Java EE 6 spec…

It’s important to note that Roberto is very clear that the contents of this ‘Lite’ version is completely undefined, but let’s look at the example he gives of “annotation-based programming model introduced in EJB 3.0, restricted to session beans with local interfaces (only)”.

As far as I can see, the only feature that this will support that isn’t explicitly defined by WebBeans is Container Managed Transactions… the WebBeans spec does define an interceptor model, and it would be relatively straight forward to provide a transactional interceptor to mimic this functionality — I’m pretty confident that we’ll see this functionality created by multiple vendors and open source projects in very little time if it’s not explicitly defined in the spec…

So why the added complexity and confusion of an EJB Lite, when you have a brand-spanking new spec that is already poised to fill the need? It looks to me like a worst-case scenario of what can happen when a system is designed be committee, without any kind of strong leadership to identify this kind of problem… Can someone please introduce the Java EE JSR’s left hand to its’ right hand?


It figures…

Wouldn’t you know it, one day after I write an entry about how development on JBoss’ app server seems to be crawling, they release a new beta version of the 5.0 series! I figured that would happen, although my comments still hold true — JBoss AS 5 is still in beta, and as far as I know, it has not been Java EE 5 certified (I could be wrong on that — please correct me if I am)…

They’ve indicated that this is the last beta version before it reaches General Availability — let’s hope it gets to that point soon!


Um… Has anyone seen JBoss?

Ok, can anyone explain why JBoss seams to have dropped off the map? The 5.0 version of the JBoss Application Server has been in beta for over a year! What’s going on? I see a lot of the JBoss folks active in blogs and articles, but JBoss appears to be one of the only major server vendor who has not released Java EE 5 compliant server — for God’s sake, even WebSphere has a Java EE 5 server (although to be fair, it appears to only be their community edition — still, WebSphere has a history of being 2-3 years behind the most recent spec, and even they seem to have made more progress)…

A lot of development seems to be going into Seam and Hibernate, which are both great products, but the Application Server has to be considered JBoss’ bread and butter product… what’s going on?

I will say that I’ve been using the JEE 5 features that are in the 4.2 version for some time, and they are solid — why hasn’t JBoss been able to take that next step with their server and achieve compliance? The lack of progress here has definitely made me think twice before recommending the server…


Architectural Pattern – Layering Enforcement

There are times in just about any Software Architects’ or Lead Developers’ careers when they wish that they had enforced a pattern more effectively – usually this comes when they find some code that has been around for ages that, for example, accesses a Data Access Object directly from a Servlet, a JSF Managed Bean, or (*gulp*) a JSP page… It usually leads to about a week of brainstorming and discussing ways to do better code reviews, and promises that each line of code will be painstakingly inspected before each commit – usually these efforts fall flat before long…

Before I go any further, let me make it clear that nothing can take the place of solid processes that include code reviews at every level, but let’s face it, we don’t all have an infrastructure like Google that will support this level of rigor – in these cases, we’ll take all the help we can get, and there are ways that we can both prevent the situation listed above, and (more importantly) remind the project developers to think about what they’re doing before it’s done… That’s primarily what the following Architectural Pattern is about – a little technical help to try and keep things in line until someone gets a chance to do that code review…

So here I present the Layering Enforcement pattern, the purpose of which is to help ensure that certain classes, or types of classes are only called in certain situations… there could be many places where this will be useful in a given project – the example that follows involves a situation where the Generic CRUD Components from a recent blog entry by Adam Bien should only be called by Repository classes, so that database access is confined to places where it is expected, rather than spread around the classes in the project…

Many different implementations and variations of this are possible – my choice here has been to model a simple user management system with EJB 3 components… in addition, we get some help from a custom Java 5 Annotation, and an EJB Interceptor – this example could just as effectively be implemented with a Spring-based framework as well (probably better, as the EJB 3 Interception functionality is pretty weak – this effort was just as much about proving that EJB Interceptors could be useful as it was about proving the pattern itself 🙂 )…

First off, we have the CRUD Component – I take no credit for this, it is purely from an example by Adam Bien:

public interface GenericCrudService {
public Object create(Object t);
public Object find(Object id,Class type);
public void delete(Object t);
public Object update(Object t);
public Collection findByNamedQuery(String queryName);
public Collection findByNamedQuery(String queryName,int resultLimit);

And the implementation:

public class GenericCrudServiceBean implements GenericCrudService {

private EntityManager em;

public Object create(Object t) {
return t;

public Object find(Object id, Class type) {
return (Object) this.em.find(type, id);

public void delete(Object t) {
t = this.em.merge(t);

public Object update(Object t) {
return this.em.merge(t);

public Collection findByNamedQuery(String queryName) {
return this.em.createNamedQuery(queryName).getResultList();

public Collection findByNamedQuery(String queryName, int resultLimit) {
return this.em.createNamedQuery(queryName).setMaxResults(resultLimit).getResultList();

Next, we need a way to identify that a class is a Repository – this may be done in any number of ways, including a properties file that lists each Repository class, a specific class naming pattern (i.e. – MyFavoriteRepository.class), but my favorite is to use a custom Annotation – this particular one has no ‘data’ attached to it, and could potentially be considered a Marker Annotation (thanks again, Adam)… at any rate, any class annotated with @Repository will be able to access the CRUD Component either directly or indirectly (It also serves as a self-documenting annotation, which is another great benefit):

public @interface Repository {


Finally, we need our EJB 3 Interceptor – as you saw above, the GenericCrudServiceBean listed the ‘RepositoryChecker’ Interceptor… the implementation, listed below, will be executed ‘around’ all method calls against the business interface of the GenericCrudServiceBean – it will inspect the StackTrace on the current thread, and use reflection to try and find any class that is annotated with @Repository… as soon as it finds one, it will allow processing to continue – if it does not find one, it will throw an IllegalStateException, indicating the problem for the developer:

public class RepositoryChecker {

public RepositoryChecker() {

public Object verifyRepositoryInStack(InvocationContext ctx) throws Exception {

List trace = Arrays.asList(Thread.currentThread().getStackTrace());

boolean foundRepository = false;

for(StackTraceElement element: trace) {
Class currentClass = Class.forName(element.getClassName());

Repository rep = (Repository)currentClass.getAnnotation(Repository.class);
if(rep != null) {
foundRepository = true;

return ctx.proceed();
throw new IllegalStateException("The target class "+ctx.getTarget().getClass().getName()+" must be called by a class marked with @Repository");

As I said, there are many ways that this could be implemented – I experimented with the idea of using another Interceptor that would place a variable into the InvocationContext when executing around a class marked with @Repository, and simply looking for the existence of that variable in the RepositoryChecker class, but decided against it, as I would need to either explicitly add the new Interceptor on each Repository class, or add it to all EJB 3 components (I could use it instead of @Repository, but I like the self-documenting nature of the annotation)… This alternative implementation would be simpler to build with Spring, as you could use a pointcut to specifically intercept calls on classes with the @Repository annotation…

As for using reflection for this solution – it may become a concern from a performance point of view, but I’m not inclined to worry about it unless there is a real problem… we’re not likely to be spending enormous amounts of time here, and if we are seeing a problem, then we can simply turn off the Interceptor in our staging and production environments, but leave it on for development (or integration, or whatever you call it) – we still get all of the benefits of the pattern (assuming that you actually use the development environment 🙂 ), and most importantly, any developers that break the layering rule will hit it on their own machines, which will make them think twice about what they’re trying to do – ultimately, this is where the most value comes from when using this pattern, as it will help your team to better understand the patterns and policies that are in place on the project…


The Smoke

Ok, so it’s time to explain the ‘Smoke’ part of the title of this blog – Smoke and Ice… One of my favorite hobbies over the last year or so has been to cook up some fine Southern Barbecue – well, Southernish, I suppose, since I live in New York… I’ll tell you what, you can’t beat the smell of a nice pork butt on the grill, smoking all day long with a nice, spicy rub on it during a summer’s day (or winter… whatever)… from time to time, I’ll be throwing some recipe’s that I use up here, since it’s always best to share barbecue with 30 or 40 of your best friends (and a lot of the time, you’ll still end up with leftovers!)

So let’s start with the basics – I use my standard 22 1/2” Weber Grill… at around $80, you can’t beat it when compared to the many smokers you can get for several hundred, or thousand dollars… Sure, I could cook more with a proper smoker, and I’ll bet it could be done a little better too, since the food isn’t as close to the heat source, but hell, I’m on a budget here… With the Weber grill, I can also fire up the coals to a raging 500-600 degrees, and grill a proper steak as well, so it’s versatile…Oh yeah, and the fuel is charcoal… no gas here – gas grills tend to run too hot, and I just have the feeling that I’d be emptying propane tanks every time I light them up…

As you can probably tell, when I talk about barbecuing, I am not talking about anything to do with ground beef, or fancy cuts of meat… While I love a good burger as much as the next guy, grilling a few burgers does not make a barbecue… instead, barbecuing is the process of cooking over low heat – usually around 225-250 degrees – for extended periods of time, usually throwing some wood right on the coals to produce a fragrant smoke that works it’s way into the meat… additionally, the meat involved is usually tough, with a lot of connective tissue – these meats would be barely edible when cooked on a hot grill, but when allowed to cook slowly, the fat and connective tissue dissolve to make the most tender, lip smacking meal you’ve ever tasted!

My personal favorite right now is South Carolina-style pulled pork, which starts with a 12-15 lb pork shoulder (which, oddly enough, comes from end of a pig opposite the shoulder), takes about 16-18 hours to properly cook, and shreds after cooking like it was butter… I usually buy these suckers two at a time at a wholesale club for about $25, so it ends up being around a dollar/pound, and will literally feed me for a month! (I made up a pair of these this spring for a party with about 30 people, and we not only fed everyone, but had enough for a week and a half of leftovers for myself )… I’m going to fire one of these babies up early next month – I’ll put up a bit of commentary on it when the time comes…

I also do a lot of baby-back ribs and beer-can chicken as well, mainly because they don’t take quite as long, so they don’t take as much care and prep-work (the chicken comes in at about an hour and a half, so it’s something I can start up at 4:00 on a Saturday afternoon)… I’ve tried my hand at brisket once, and while it was a bit tough, the flavor was out of this world, so I will be doing one of those again at some point – I stopped at a barbecue joint the other day and ordered sliced brisket (you know, for research), and surprisingly, it was not at flavorful as mine, and it was nearly as tough… disappointing, but just more motivation to cook it myself

Last but not least – there’s a lot of ‘passive’ time involved in barbecue, and as far as I can tell, there’s only one worthwhile way to pass that time – drink a few beers, listen to some blues and spend time with your family and friends while you’re soaking in that incredible barbecue smell… sound like the perfect way to spend a weekend? Well then get cookin’!


Howdy, y’all!

Yes, I know, it’s another ‘First Post’ message… yeah, I’ll get on with it… This blog will be a place for me to put my thoughts, whether they be about programming (my profession), barbecue (the ‘Smoke’ from the blog’s title), hockey (read the title again), family, movies, books, whatever… More than likely, I’ll end up figuring all of that out as we go…

Ok, ok, I’m getting on with it… you’ll have to wait for the next post for anything else…