Grizzly and WebSockets

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.

GlassFish v3 is out

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

Documenting the GlassFish v3 Schema

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.