Antwerkz, Inc.

One of the newer features available in GlassFish v3 is the ability to run glassfish in an embedded mode similar to how jetty is often used. This is approach is very common when working with Wicket and is, in fact, part of the quickstart maven archetype.  So what I’d like to see is GlassFish in place of Jetty.  It’s not terribly difficult once you get past the first few steps.  This is a pretty new (and evolving) option so the documentation isn’t all that easy to find, necessarily, but it’s building.  I’ll list some resources at the end.

The first step, of course, is to configure maven appropriately.  In my pom.xml, I have the following:

    <repositories>
        <repository>
            <id>glassfish-repository</id>
            <name>GlassFish Nexus Repository</name>
            <url>http://maven.glassfish.org/content/groups/glassfish</url>
        </repository>
    </repositories>

This will add the repository to find the deployed GlassFish artifacts. With that done, we can define a few dependencies:

        <dependency>
            <groupId>org.glassfish.common</groupId>
            <artifactId>glassfish-api</artifactId>
            <version>${glassfish.version}</version>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>org.glassfish.extras</groupId>
            <artifactId>glassfish-embedded-web</artifactId>
            <version>${glassfish.version}</version>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>org.glassfish.web</groupId>
            <artifactId>web-embed-impl</artifactId>
            <version>${glassfish.version}</version>
            <scope>provided</scope>
        </dependency>

${glassfish.version} here is defined elsewhere in the pom to 3.0. The class at the center of it all looks like this:

public class Embedded {
    public void start() throws IOException {
        final Server server = new Server.Builder("testBuilder").build();
        ContainerBuilder containerBuilder = server.createConfig(ContainerBuilder.Type.web);
        server.addContainer(containerBuilder);
        final EmbeddedWebContainer container = (EmbeddedWebContainer) containerBuilder.create(server);
        container.setLogLevel(Level.INFO);
        server.createPort(8888);
        final EmbeddedDeployer deployer = server.getDeployer();
        DeployCommandParameters deployParams = new DeployCommandParameters();
        deployParams.contextroot = "/";     // overrides whatever the WAR contains
        File archive = new File("target/wicket-glassfish").getAbsoluteFile();
        System.out.println("Deployed: " + deployer.deploy(archive, deployParams));
    }
 
    public static void main(String[] args) throws Exception {
        new Embedded().start();
        while (true) {
            Thread.sleep(1000);
        }
    }
}

Now, that’s all rather dense, I know. This code is a condensed version of a much larger, more complete version written by Alexis Moussine-Pouchkine. His blog is a great resource not only for embedded GlassFish but all sorts of GlassFish related topics. This is all that’s needed to run your app on GlassFish.

There are a number of other avenues left to explore. If you want to run glassfish from maven, you’ll want to probably look at this entry. You can also enable some security as noted here. For the definitive word on the matter, however, please see the formal documentation for embedded glassfish here.

As HTML5 lumbers its way through the standardization process, more and more developers are starting to play with the emerging features.  One feature getting some serious attention is that of the websocket.  Full details of the websocket protocol can be found here but I’ll lay out the basics of it.  Essentially a websocket is a TCP based socket that can be opened from a webpage via, typically, javascript code allowing bidirectional communication between the browser and the server.  This allows for comet-like interactions but with an extra benefit (or two).  Once the websocket connection is established there are no more protocol negotiations and handshakes unlike your typical AJAX conversations.  And unlike (most?) comet implementations, a websocket can process multiple requests from the client.  Obviously, this can lead to some rather interesting use cases.

It’s early yet so support for websockets on either end of the browser/server connection is spotty at best.  But we’re staring to see browser support emerge and a number of server side options are popping up as well.  This morning I committed an early rough draft, if you will, for support inside the grizzly project and soon glassfish itself.  It’s a mostly complete implementation and is ready for some experimentation.  At the moment, the sample in the unit tests that will be of the most interest is a servlet based approach.  What’s nice about the current approach is that the servlet is largely unaware that it’s involved in a websocket transaction at all.  There’s a lot of value in something like that but might limit some other, more powerful, use cases.

For now, though, you can play with the unit tests and see what can be done.  It’s preliminary but working and the API will evolve as we get feedback from the community.  We’ll be discussing how best to expose this functionality without needing to know all that much about grizzly internals.  We’ll be looking at other cases such as jetty and atmosphere to make sure we can provide a smooth, useful API that most people are comfortable with.  There’s been talk at various levels of building some form of standard interface to plug in to various websockets implementations on the server side but until then, we’d love your help in building something with grizzly and glassfish that we can all use.

So please join us on the mailing lists and give us a hand.

Technorati Tags: glassfish, grizzly, html5, websockets

Today marks the official(ish) release of GlassFish v3.  v3 is the product of years of hard work in what is, in some ways, a rewrite of v2.  Built on top of OSGi, v3 offers a modularity and extensibility leap over v2.  It’s also the first to fully support the JEE 6 specification.  I’ve been a spring guy for a long time now but honestly (and employer imposed bias aside)  JEE 6 makes a compelling case for skipping spring altogether.  At least for my uses.

GlassFish v3 and JEE 6 offers a number of profiles so you can install as much or as little as you’d like.  Using the web profile gives you everything you need to run many web apps.  You can add additional features via the updatecenter as you need them often without needing to restart the server.  If you’re a v2 user most of that should be very familiar to you already.  Borrowing from Eduardo’s blog entry:

Key links available now:

• GlassFish v3 Main Product Page
• JavaEE 6 Hub
• JavaEE 6 Downloads (multiple bundles)
• Java EE 6 Feature Article (also see Overview White Paper).

You can read more here.  You can also find all the GlassFish v3 related blogs on blogs.sun.com (at least those tagged as such) here.  I’m really quite excited about this release but at the risk of sounding too press releasey about it all, I’ll leave the gushing to others.  You can check it for yourself by downloading it.

Download it.  Kick the tires.  Take it for a spin.  I think you’re going to like what you find.  Especially if you haven’t given glassfish a look in some time.  This is truly a different creature.

Technorati Tags: glassfish, glassfishv3, Java

Everyone hates the deprecation policies of the JDK team but it’s certainly an understandable policy.  Millions and millions of lines of code exist out in the wild and there’s no telling what calamity would befall us if methods were actually removed the JRE libs.  On the other hand, people still use those deprecated methods despite their failings and the presence of better options.  I was reading Joseph Darcy’s blog entry on this policy and ran across an interesting comment.

The idea is pretty simple:  make compiling fail against the deprecated methods without actually removing them from code.  This preserves binary compatibility while preventing any new code from compiling against these methods.  This would actually include new releases of applications written before the method was deprecated as these new versions would no longer compile while the previous releases would still run.

This seems to be the best of both worlds.  Building on the idea from comment, I’d offer this enhancement:  Introduce an @Obsolete annotation.  This would supplant the @Deprecated annotation on these methods.  Any usage of a method or class (or field?) with this annotation would return an error at compile time.  Reflective access to these items would also be disallowed just to drive the point home.  Of course, the annotations would need to include facilities to describe the alternatives to use for these old methods to provide the same functionality as the javadoc comment.  Given this simple addition, I think we’d finally start to make some progress on modernizing our code.

Technorati Tags: development, Java

I have a mild compulsion to clean up code.  When i see mixed indentation (usually tabs vs spaces), I start getting twitchy.  When I see star imports, places where old loops can be replace with the “new” foreach loops (thereby reducing line noise in many cases), or any of a number of different “improvements” to the code I start itching to start cleaning up.  But there’s (at least) one problem:  not everyone wants their code cleaned up.

For many, such janitorial efforts hide any actual functionality changes and they would prefer such changes be made in a separate commit/task.  While there’s some merit to that complaint, it’s also often true that time for mere janitorial work will rarely/never get allocated.  So without taking advantage of opportunities, it will never get done.  Unless you work on a project that values such changes, these changes will either be made alongside functional fixes or not at all.

To resolve this tension, there are things both camps can do.  If your project is open source, you could implement something like The Linux Kernel Janitor Project.  This project is used as one possible entry point for beginners to begin to learn the system and make some changes without necessarily having to know enough to effect major changes.  This kind of project can work in a corporate setting as well, though most companies would prefer to get some “value” from their employees as quickly as possible.

If a janitorial project is not an option, then try to grant some leeway for intermittent clean up.  If code isn’t maintained, it can become so crufty over time that making actual bug fixes or functional enhancements can be difficult.  On the flip side, those like me that like to get code into shape need to show some restraint and courtesy.

Sometimes its just pride that rebels against having someone else muck with “my” code that leads people to object to such changes.  But in many cases, drastic and pervasive reformats or “tweaks” to code can lead to impossible to decipher merge conflicts for people doing significant changes in those files.  It can be tempting (and gratifying) to do a deep clean on a file or whole sets of files but you have to consider the impact of those changes.  You might have to settle for one or two things to clean up this time and catch the rest later.  At the end of the day, it’s about making a working product and if your cleanups cause delays for others as they sort out what exactly you did, then you’re not exactly helping out.

Of course, prevention is the best medicine so each project should choose a set of standards and conventions.  These could include a set of libraries that everyone agrees to use.  This can lead to a set of standard/best practices in the project rather than everyone choosing their own favorite XML libary for their subsystem, e.g.  It should certainly include code style conventions.  For me, I choose the Sun conventions. There’s nothing magical about them.  I like them and encourage their use.  But whatever works for your team, just pick something and stick to it.  This will help reduce the need in the future for large scale janitorial work.

The criteria for what is the “right” way to do things can change over time.  e.g., the foreach loop is newer than most java code, I’d wager.  On older code you’re still likely to see many while loops or old style for loops that could be migrated to the new style.  Your team’s style/practice guidelines should be periodically reviewed and update to account for the change landscape in both language features and third party libraries.  Once any changes are agreed upon, you need to prepare yourself for those changes to start trickling in.  These can be done in an organized sweep and clean up of the code or piecemeal by individuals as they find them.

Either way, you’re going to want people like me in there to help.