Coming Up for Air



  • 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.


  • 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…​



  • 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.



  • 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.





  • 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,

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


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

    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. :)



  • 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.



    Sample quote

    Quote source


    My name is Jason Lee. I am a software developer living in the middle of Oklahoma. I’ve been a professional developer since 1997, using a variety of languages, including Java, Javascript, PHP, Python, Delphi, and even a bit of C#. I currently work for Red Hat on the WildFly/EAP team, where, among other things, I maintain integrations for some MicroProfile specs, OpenTelemetry, Micrometer, Jakarta Faces, and Bean Validation. (Full resume here. LinkedIn profile)

    I am the president of the Oklahoma City JUG, and an occasional speaker at the JUG and a variety of technical conferences.

    On the personal side, I’m active in my church, and enjoy bass guitar, running, fishing, and a variety of martial arts. I’m also married to a beautiful woman, and have two boys, who, thankfully, look like their mother.

    My Links