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.

I recently found this entry that shows how you can update your PS1 value to display certain information about your git workspace.  I don’t get to use git too much right now, but I use subversion a lot and wondered what there was for that.  I didn’t find anything in the bash-completion entries for svn (though I admittedly didn’t look too hard) so I whipped up my own solution late last night.

One slight disclaimer before seeing the script:  it was late when i wrote this.  There doesn’t appear to be any noticeable performance hits other than the initial run of this script but I make no guarantees.  I’m sure it could be optimized but it’s snappy enough and might prove to be mildly useful.  It was interesting enough at midnight at least.  :)  Anyway, the code!

#! /bin/sh
extract() {
	TEXT=$( svn info | grep "$1" )
	echo ${TEXT##$1}
}
 
if [ -e .svn ]
then
	URL=`extract "URL: "`
	REPROOT=`extract "Repository Root: "`
 
	echo "\n\033[01;33m[svn: ${URL##$REPROOT}] \033[01;34m"
fi

This can be displayed in your command prompt by setting your PS1 variable like this:

export PS1='\[\033[01;32m\]\u@\h\[\033[01;34m\] \w $(svn_ps1)\$\[\033[00m\] '

The single quotes are important there to prevent immediate execution of the script. If you use double quotes, it will be evaluated immediately and your prompt won’t update as you navigate around. You only need to save the first script as svn_ps1 somewhere on your PATH or name it as you wish and update the PS1 variable accordingly. You can, of course, specify the full path in the PS1 var if you’d like. This setting will put the path within the current subversion repository in yellow text on a new line. If you’re not in a subversion workspace, your prompt is unaffected. I had some code in there to strip off the relevant portions of the cwd from that display so you essentially only saw what branch or tag you were or if you were in trunk. With the script as it is, there’s some redundancy between the subversion info display and the cwd shown, but I can live with that.

I switch between branches and even version control systems often enough that i’ll probably expand on this to work for git/svn/hg/cvs accordingly. Next time I’m up late hacking.

Technorati Tags: bash, mac, subversion

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

Once work had started on GlassFish v3 the decision was made to drop schema validation for the domain.xml configuration file.  In previous versions, you could be assured that your xml was valid because we shipped a DTD to enforce that.  In v3, however, that is no longer the case.  The decision was made because v3 is very different in some fundamental ways.  In v3, you can add an arbitrary container to GlassFish and configure it via domain.xml.  This dynamic nature of the document structure makes validation difficult at best so the decision was made to drop validation altogether.  However, the problem still remains of how to determine what the document should look like.

First things first, you should avoid editing that xml file by hand.  You should be able to do everything you need via either the admin GUI console or the asadmin CLI tool.  That said, that still doesn’t necessarily help you know what values can go where.  The question has come up dozens of times even among the development team.  Various teams have updated and migrated their respective sections of the document leaving some confusion about the new schema.  (My own work on the grizzly-config updates is probably the biggest offender here).  There are, to my knowledge, two different attempts to fix this.

Tim Quinn developed the first publicly available tool.  You can find that here.  I had my own going on locally as well.  I borrowed some ideas from Tim’s approach and came up with this.  My version differs from Tim’s in that it runs in container as an asadmin command.  This has a few advantages but most importantly is that I think it’s easier to use.  The output I generate is also a bit more accessible than Tim’s but then Tim’s was really a rough first cut.  I’m not sure he’s done much with it since.  I, on the other hand, still get questions about the grizzly-config schema changes so this is near and dear to my heart.

At the moment, it only generates a javadoc-like HTML output.  I plan on adding a DTD and XSD option but there are some disconnects between the internal Java API used to configure GlassFish and what a user sees in domain.xml that make this not so trivial.  You can find those details here.  The HTML generated reflects the currently valid structure of the document and not the content.  This structure changes as you add/remove modules such as JRuby support and the like.  The files are generated in the config directory (<glassfish>/domains/domain1/index.html for most people).

The color scheme is a work in progress.  The main blue is a bit jarring, I think, but I just haven’t had much time to play with such things lately.  You can find sample output here.  In the detail frame you’ll see that some elements have properties defined.  This lists all the documented properties on that attribute.  In a perfect world, that list would be exhaustive but that’s not always possible.  e.g., Some configuration elements such as JDBC connection pools configure third party libraries and capturing all possible properties there is impossible.  Nevertheless, for all internal GlassFish items this list should give you much of what you need.  If you find a missing property, don’t hesitate to file an issue with the GlassFish tracker and we’ll try to update our documentation.

If you find an issue with the doc tool itself, please file an issue and I’ll do my best to correct it.  This is an unofficial contribution to GlassFish, though, so bugging the GlassFish lists isn’t likely to help much.  I hope this tool helps you as you evaluate v3.  We really are very excited about this one.