Coming Up for Air

2011

October

  • Funky Object Initialization

    I’ve been using a technique a lot, recently, for initializing an object a bit more succinctly. It looks pretty odd, I’ll admit, enough so that it really caught a coworker of mine off guard. If you’ve been reading my recent REST posts, you’ve seen this a few times. I like it a lot, so I thought I’d a take a quick look at it.

February

  • Java EE's Buried Treasure: the Application Client Container

    From time to time, I’m asked about accessing various EE artifacts (EJBs, etc) from a standalone client. Almost invariably, the user is having trouble getting the environment setup, grabbing an InitialContext, etc. Also almost invariably, my answer to them is "use the application client container", which is as far as I can take them. The topic of application client container, or ACC, came up again recently when I was asked on Twitter about an issue with ACC and GlassFish in a clustered environment. While this user (hi, Markus! : ) figured out his issue before I could be of much help, I took this opportunity finally to learn exactly what the ACC is and how to use it. Thanks to Oracle’s Tim Quinn for his patient and tireless help, here’s what I learned…​

2010

March

  • Writing Selenium Tests for the GlassFish Admin Console

    One of the results of the Oracle purchase of Sun has been an increased focus on testing — not that we didn’t test GlassFish before, but it was mostly manual in my area of the server. The task of automating this fell to me, and, after a little — ahem — testing, I settled on Selenium.

2009

January

  • Bootstrapping a JSF 2 project

    I needed a break this afternoon, so I thought I’d see how easy it is to bootstrap a JSF 2 project. One of the biggest complaints about JSF 1.x is all that XML, so JSF 2 is aiming to fix that. How have we done so far? Based on this quick look (which is my first from-scratch JSF 2 app), really, really well.

2008

December

November

February

  • A ValueChangeListener Question and Answer

    At the lunch session of the OKC JUG today, a question was asked about the difference between the valueChangeListener attribute and <f:valueChangeListener/>. That is,

    1
    2
    3
    4
    
    <h:selectOneMenu id="optionMenu" value="#{optionBean.selectedOption}"
            valueChangeListener="#{optionBean.optionChanged}" onchange="submit()">
        <f:selectItems value="#{optionBean.optionList}" />
    </h:selectOneMenu>
    

    and

    1
    2
    3
    4
    
    <h:selectOneMenu id="optionMenu" value="#{optionBean.selectedOption}" onchange="submit()">
        <f:selectItems value="#{optionBean.optionList}" />
        <f:valueChangeListener type: "com.mycompany.MyValueChangeListenerImpl" />
    </h:selectOneMenu>
    

    The question was, which is "better?" There was also a question if the latter form automatically handled the JS on the parent component. I will now attempt to answer those questions. :)

2006

December

  • JSF Component Writing Check List
    = JSF Component Writing Check List I've been doing a fair amount of JSF component writing of late, and, invariably, I miss one or more "minor" details, causing my component to explode in spectacular fashion at runtime. What follows, then, is a check list for writing JSF components, with notes on the differences between the 1.1 and 1.2 versions of the specification.

My Links

Quotes

Sample quote

Quote source

Publications