Port Unification in GlassFish 3 – Part 2
It's taken more time to get back to this topic but it's time. In part 1, I covered how to set up GlassFish to push all HTTP traffic to HTTPS. In this post, I'll show you how to set up the reverse. In the next post, I'll cover how to configure GlassFish to serve up multiple protocols from the same port. The steps are basically the same so this will be a short one. Similar to last time, we'll issue a few simple commands:
asadmin create-protocol --securityenabled=true https-redirect asadmin create-protocol-filter --protocol https-redirect --classname com.sun.grizzly.config.HttpRedirectFilter redirect-filter asadmin create-ssl --certname s1as --type network-listener --ssl2enabled false --ssl3enabled false --clientauthenabled false https-redirect asadmin create-protocol pu-protocol asadmin create-protocol-finder --protocol pu-protocol --target-protocol http-listener-1 --classname com.sun.grizzly.config.HttpProtocolFinder http-finder asadmin create-protocol-finder --protocol pu-protocol --target-protocol https-redirect --classname com.sun.grizzly.config.HttpProtocolFinder https-redirect asadmin set configs.config.server-config.network-config.network-listeners.network-listener.http-listener-2.protocol=pu-protocol asadmin set configs.config.server-config.network-config.network-listeners.network-listener.http-listener-2.enabled=true |
This should familiar if you've read part 1. We do a little extra work to set up some ssl config elements primarily to preserve the standard settings in case you want to roll back these changes when you're done. If you do, you simply need to delete those new protocol elements.
To see it in action, simply issue the following command:
wget -q -S --no-check-certificate https://localhost:8181/ |
You should see something like the following:
HTTP/1.1 302 Moved Temporarily Location: http://localhost:8181/ Connection:close Cache-control: private HTTP/1.1 200 OK X-Powered-By: Servlet/3.0 JSP/2.2 (GlassFish Server Open Source Edition 3.1-SNAPSHOT Java/Apple Inc./1.6) Server: GlassFish Server Open Source Edition 3.1-SNAPSHOT Accept-Ranges: bytes ETag: W/"5212-1279828070000" Last-Modified: Thu, 22 Jul 2010 19:47:50 GMT Content-Type: text/html Content-Length: 5212 Date: Fri, 23 Jul 2010 16:50:22 GMT Connection: Keep-Alive |
As you can see, the https request received an initial 302 response pushing off to the http url which then returns the 200 response we'd expect. To verify even further, use wget to fetch the http url and you'll see something like this:
HTTP/1.1 200 OK X-Powered-By: Servlet/3.0 JSP/2.2 (GlassFish Server Open Source Edition 3.1-SNAPSHOT Java/Apple Inc./1.6) Server: GlassFish Server Open Source Edition 3.1-SNAPSHOT Accept-Ranges: bytes ETag: W/"5212-1279828070000" Last-Modified: Thu, 22 Jul 2010 19:47:50 GMT Content-Type: text/html Content-Length: 5212 Date: Fri, 23 Jul 2010 16:57:31 GMT Connection: Keep-Alive |
That's it. As promised, short and sweet. Currently this approach does not allow you redirect to a different port number. We have added a new configuration element that simplifies this setup and allows for cross-port redirects. However since there isn't asadmin support for it yet, I'll defer discussion until we can get those commands written. That's in the works so it should be in the next week or two.
With that, though, I'll wrap this one up and start working on the more interesting Part 3.
Apache, Oracle, and the JCK
The Apache/Sun rift is well-known to most following the Java world. Apache has long demanded that the field of use restrictions be dropped. There's some consensus that the FOU clause actually violates the JCP's charter. I'm not a lawyer so I can't really comment either way. This has prevented Apache Harmony from certifying as a Java implementation and, at least in part, has led to the development of the Dalvik VM up on which Android based applications run. A new article in The Register reports that talks between Apache and Oracle have started to break down and that should worry anyone who works with Java.
Java's promise and value has long been platform portability. Except for a few corner cases here and there, an application written in Java could run on any platform which had a JVM. Even most of those cases can be mitigated if your application is written correctly. With the rising popularity of "non-computer" computing devices (smart phones, tablets, etc.), Android has become an considerable presence in the industry. Whether or not Google chooses to certify Dalvik as a JVM or not, it isn't allowed to even try, really. The Java JCK won't allow it. And that poses a real threat to Java.
The FOU restriction was added, in part, to protect Sun's JavaME business. This made business sense to a degree as that's an enormous market. Back when devices couldn't support a full JVM, JME made a lot of sense. That's changing rapidly these days. Personally, I think the days of JME are numbered. I think Android is going to be a huge player in the years to come. And it isn't Java. Already, dozens of times I've personally helped debug someone's "Java" code only to find that the tried and true answer doesn't apply because, surprise!, that code was actually running on an Android device.
The mobile market is already huge and it's only getting bigger. There's little reason for Oracle to retain the FOU clause. Oracle doesn't need the JME market the way Sun did. Opening that up will allow Dalvik, and others, to certify as a Java implementation and push Java into even more markets. If Oracle fails to do this, it could ultimately end up ceding the mobile market to others. I've long agreed with Apache that the FOU is unfair and violates the spirit (and probably the letter) of the JCP agreement. Oracle should drop the clause as they've said in the past that Sun should. Vendors who still need JME can still pay for it. But, increasingly, JME is looking more and more anachronistic. I see very little reason to protect it any longer and every reason to push Java in to more and more markets.
Update: Yes, in some ways I'm conflating Harmony and Dalvik. They're both emblematic of the larger issue. The problem of the FOU and the viability of the JVM on an embedded device is the main point. Please don't get too caught up in the finer technical points. I apologize for any confusion.
Disclaimer: These opinions are my own. I do not speak for any of the parties involved nor do I have any inside knowledge despite my employment at Oracle. I am simply a passionate Java advocate expressing an opinion.
Port Unification in GlassFish 3 – Part 1
There are two main cases I want to cover here: port redirection and serving multiple protocols on one port. I'm pretty sure that covering both in one post would egregiously long so I'm going to break things up into two posts. In this first post, we'll cover what will likely the be more common use case: port redirection. In this example scenario, you only want to serve requests via https rather than http. In this case, you can configure GlassFish to return a 302 and push clients off to https transparently. This type of configuration has been available in GlassFish since at least v2 and is still available in v3. However, in v3 it wasn't "officially" supported so you had to manually massage your domain.xml.
While documented in various blogs around net, it's not officially supported in v3. As of, well now I guess, that's all changed. I've added some asadmin commands to the 3.1 nightly builds that expose a more user friendly way to configure port unification. In this blog, I'll introduce these commands and show you how to set up a simple redirect to enforce https requests on a given listener. As always, when experimenting with this sort of thing, you should back up your domain.xml so if you hose your configuration, you can easily roll back to a working configuration.
There are two main concepts involved: <protocol-filter> and <protocol-finder>. There are a handful of other elements involved but we've hidden them from you by default since very few people will need to manage those elements. The first step is to create the <protocol-filter>:
asadmin create-protocol --securityenabled=false http-redirect asadmin create-protocol-filter --protocol http-redirect --classname com.sun.grizzly.config.HttpRedirectFilter redirect-filter |
We need to create a new <protocol> element to hold our new filter first. You can't simply reuse, say, http-listener-1 because port unification elements and <http>/<ssl> can't coexist on the same protocol elements. You could of course issue a number of commands to preserve the name of http-listener-1 but the work involved is likely not worth it. It's certainly overkill for this example so I'll leave that as an exercise for you if you're that interested in it. The next asadmin command creates the actual protocol filter. With these two commands we have now have a new entry in our domain.xml that looks like this:
<protocol name="http-redirect"> <protocol-chain-instance-handler> <protocol-chain> <protocol-filter classname="com.sun.grizzly.config.HttpRedirectFilter" name="redirect-filter" /> </protocol-chain> </protocol-chain-instance-handler> </protocol> |
Notice that there are new elements: <protocol-chain-instance-handler> and <protocol-chain>. These are some implementation details that should be mostly irrelevant to all but a handful of users. I only mention them so that you'll be expecting to see them and that you know you can safely skip over them. With those pieces in place, we can now create our finders.
To create our finders, we need to create another <protocol> element to hold them and then create the finders themselves:
asadmin create-protocol --securityenabled=false pu-protocol asadmin create-protocol-finder --protocol pu-protocol --target-protocol http-listener-2 --classname com.sun.grizzly.config.HttpProtocolFinder http-finder asadmin create-protocol-finder --protocol pu-protocol --target-protocol http-redirect --classname com.sun.grizzly.config.HttpProtocolFinder http-redirect |
Note that the first <protocol-finder> refers to the http-listener-2 <protocol>. We'll be using that protocol definition to configure the https processing. The second finder refers to the <http-finder protocol> definition we just created and it is this piece that will be doing the redirect from http->https for us. The first finder will trap all https requests and hand them off, while the second will handle all cleartext http requests and redirect for us. The resulting domain.xml elements looks like this:
<protocol name="pu-protocol"> <port-unification> <protocol-finder protocol="http-listener-2" classname="com.sun.grizzly.config.HttpProtocolFinder" name="http-finder" /> <protocol-finder protocol="http-redirect" classname="com.sun.grizzly.config.HttpProtocolFinder" name="http-redirect" /> </port-unification> </protocol> |
Again, we silently create the <port-unification> element for you so you needn't worry about it. These elements that we silently create for you, we will also silently delete them for you when you delete the last elements contained in them. So those are our port unification elements. With those created, we just need to reconfigure listener to use these new elements:
asadmin set configs.config.server-config.network-config.network-listeners.network-listener.http-listener-1.protocol=pu-protocol |
With that, we can try hitting port 8080 and see things in action. The easiest way to see this, probably, is to use wget:
wget -q -S http://localhost:8080/ |
With this command, you should see the following output:
HTTP/1.1 302 Moved Temporarily Location: https://localhost:8080/ Connection:close Cache-control: private |
As you can see there, the server returns a 302 back to the client with the new location of https://localhost:8080. That's all it takes. Now every request will use https regardless of the original request. You could, of course, use a similar set up to push everyone from https back to http. This is especially useful for those without any need for https and are concerned about server load since https can be expensive to process.
In the next entry, I'll tackle the use case of serving up multiple protocols from one listener. This will be especially useful for those behind firewalls wanting to open only a single port to the outside world. Hopefully this will get you started. If you have any questions, feel free to leave a comment or ask on the glassfish users mailing list.
For convenience, here are all the commands necessary to try this out at home in one downloadable file:
wget -q -S http://localhost:8080/ asadmin create-protocol --securityenabled=false http-redirect asadmin create-protocol-filter --protocol http-redirect --classname com.sun.grizzly.config.HttpRedirectFilter redirect-filter asadmin create-protocol --securityenabled=false pu-protocol asadmin create-protocol-finder --protocol pu-protocol --target-protocol http-listener-2 --classname com.sun.grizzly.config.HttpProtocolFinder http-finder asadmin create-protocol-finder --protocol pu-protocol --target-protocol http-redirect --classname com.sun.grizzly.config.HttpProtocolFinder http-redirect asadmin set configs.config.server-config.network-config.network-listeners.network-listener.http-listener-1.protocol=pu-protocol wget -q -S http://localhost:8080/ |
Saying that Final Goodbye
I'd never been in the room when someone died. Yet for the last week, we'd all been waiting for, and dreading that fateful moment. With my father stretched out on the bed, tubes streaming from his withered form, we huddled together and waited for the end. An end all the more bitter for its prematurity. We'd all thought we'd have more time together.
My father was, by all accounts, in very good shape. At 60 years of age, he exercised more than most people I knew: running, sit-ups, push-ups, etc. He worked on his cars himself. Reroofed his house basically single-handedly. Built his own garage. He did it all himself with only slight grumbling about his knuckles hurting from when he'd tried to punch through a board in karate class some years prior. The man was busy. Then ... he had trouble swallowing one day.
"It's cancer," the doctor told my mom and dad. My dad's response, as I am told, was to turn Mom and, "I'm sorry." That's the kind of man he was: so worried about being a burden that he apologized to his wife. For having cancer. I'm sure there was more to it. He had to have known that this was essentially a death sentence. More and more people fight and beat cancer these days. But not as many as we would like. Not even close.
With little else to do but get on with it, Dad started rounds of chemo. Chemo, being chemo, was going "ok." Hair came out. Weight came off. Appetites disappeared. But he remained in good spirits. At least, as far as he showed us. Knowing the course this cancer would probably take, we decided at the last minute to fly back to Oklahoma to spend his birthday with him. We couldn't be back there for Christmas (we had family coming to see us for a change) and knew that by then he might be too sick and weak to really enjoy his grandchildren. So we went. It was, all things considered, a great visit. The kids enjoyed seeing Grandpa Lee and Grandma Lee. My parents had fun with the girls. We took lots of pictures. It was one of the last times I heard his voice. It was the last time I saw him on his feet.
We flew back to Brooklyn and continued on with our lives. I tried to check in weekly with Mom and see how things were. I talked to Dad occasionally but mostly talked to Mom. Some weeks he was doing pretty well; others, he couldn't eat too much. Some weeks he seemed to improve and others … not so much. Thanksgiving came and went. He couldn't eat too much. Wasn't terribly interested. On December 10, he went in to the hospital for the last time.
He'd had trouble swallowing and had Mom call the doctor. The doctors looked him over and found more cancer. It was here, It was there. They needed to operate. The doctors tried valiantly. I can find neither fault nor blame with their efforts. They were fighting a losing battle. But they tried their damnedest. All through this, I would check in with Mom. "Should I come?" "I'm not sure. Do what you think is best." She was so gracious with me in all this. I wanted to be with them but I had work and kids and such. What I ultimately wanted was to be with Dad at the end and be with Mom. But trying to time that long distance is as quixotic as trying to time the stock market. We would just have to wait and see how things went.
Christmas came. "Should I come now?" "You have your family and your kids. Stay with them. Enjoy your Christmas. We can see what happens in a few days." It was getting harder and harder to not be there. I could hear him in the background grumbling and complaining. He wasn't entirely coherent all the time. The pain medicine was taking most of that away. But he had his moments. He knew he had family around him. Christmas, it turns out, would've been a horrible time to travel there. My siblings, a mere 20 minutes away, couldn't even make it to the hospital. Snow and ice shut down much of the state. So I stayed in NY. I enjoyed Christmas with my wife and kids. With my wife's sister and her husband. I had fun. I kept thinking of Dad.
Every time my phone would ring, I would go in to near seizures trying to get to it. Was this it? Is this The Call? Then it came. "If you want to see him one last time, you probably should come now. He's … not doing so well." I booked a flight and that Tuesday I flew down. Without being too dramatic about it, it felt like a storyline out of a movie: Will I get there to find he passed away while I was in the air? Every little delay was agonizing but there was nothing to do about it but ride it out.
When I finally arrived, the worst had almost happened. After a reasonably routine procedure to remove a line, he (almost?) crashed. They'd had to put him on life support or he *would* have died while I was in the air. He was still with us. But he couldn't speak. He couldn't, for the most part, respond to any stimulus whatsoever. Apart from groans he would utter over the next week, I would never his voice again.
The waiting game began. He was getting food and oxygen from bags and tubes and machines. He would from time to time roll his head when we went in to see him. His eyes would roll around glassily only to snap into hard focus as if he had found some reserves deep inside for one brief moment.
For the next week, I lived in the hospital with my mom. We stayed in the ICU waiting room and we, well, waited. We talked about this and that: what's to come, the sadness we were feeling, whatever stupid show was on TV. We made friends with another family who was there with their loved one. We laughed together. We shared stories, jokes, and sorrow. At times we felt guilty having such a good time with my father dying just through those doors. But we never would've made it without that family. Life isn't all jokes and laughter but neither is death all sorrow and pain. We gave and received a measure comfort in our unexpectedly shared time of sorrow and worry. It was probably the sweetest, most heartbreaking week of my life. And it shared with strangers turned new friends.
We spent the nights at the hospital. Mom had been there for three weeks already. I'd missed enough already that I had no desire to leave. I could've slept on a real bed only 20 minutes away but I couldn't bear the thought of being away anymore. It was my turn. Mom wasn't leaving. Neither was I. Oh, I left once or twice for food. I walked down the hall to grab coffee sometimes with, sometime without, company. But we were there. We weren't going anywhere. Mostly we ate in the cafeteria there. Sometimes it was most or all of us siblings and Mom. Sometimes it was just me and Mom. We talked about more about the next steps. We knew it couldn't be too much longer.
Finally, we all came to the question we'd been putting off: What to do about life support? We all knew there's no way Dad would want to be kept alive by mechanical means. Truth be told, there wasn't really anything left for him to hold on for. He was on life support for various reasons unrelated to his cancer. But that cancer had done far more damage than we'd thought. He had weeks at most left. There was no hope of recovery. He would never leave that hospital again.
With the dawn of realization washing over of what we were talking about, we decided to remove his feeding tube and let nature take its course. We signed the papers. We talked to the doctors. We went in to say goodbye. We held his hands. Told him we loved him. Kissed his forehead. Then we all stepped back and let the tech do his job. In minutes it was done. The feeding tubes and the oxygen tubes were out. And despite all expectation, he held on. We moved him to a hospital room and began the wait once again.
He lasted only handful days more. He'd moan and grunt as who knows what was going on for him. He was all but unresponsive to us. But we were there. Holding his hand. He'd gasp for air as hard as he could and then suddenly he'd stop. Desperately watching his pulse throb in his throat, we'd hold our breaths. Seconds would pass and finally one of us would call out, "Dad?" A slight pause and suddenly he'd draw another ragged breath and settle back down.
Days like this passed. Until finally on January 4, he drew his last breath. I watched as his throat ceased to throb and no amount of calling his name would bring that next breath. Mercifully, painfully, his suffering was over. The nurses and and doctors came in to do their jobs as unobtrusively and respectfully as they could. But it was worrying and the wondering were over. It was time to grive. After some time, we all started making phone calls: me to my family still here in Brooklyn, others to various friends, loved ones, or church members.
We buried my dad a few days later on a frigid Oklahoma winter's day. The little country church my family has attended since I was a child was packed with more people than I can ever remember seeing in it. My father was a Marine Corps veteran of the Viet Nam War. He didn't talk much about it preferring to try to forget it as much as possible. He'd talk about it from time to time but there were too many painful memories for him. So much so that he'd leave a graveside service where Taps was played; the grief was just too much. So we didn't have Taps played at his funeral as much as I would have loved to have honored him that way. But the Marines did send out two soldiers whose sole duty that day was to deliver some of the saddest, most reverent words I know:
On behalf of the President of the United States, the Commandant of the Marine Corps, and a grateful nation, please accept this flag as a symbol of our appreciation for your loved one's service to Country and Corps.
Five months it's been now. I feel fine most days. But occasionally something will trigger an especially poignant remembrance of him. This weekend as the trailer for the new Tron movie started, I began to cry in the middle of the darkened movie theater. My dad would have loved that movie. There's so much he would've loved to have seen. But he's gone now and I can only remember the man as best I can. And what I remember is that he loved his family more than his own life. And I remember that I love him. And that loss hurts like hell.
Scripts to Help with GlassFish Development
GlassFish is a big enough source base that sometimes you just need a little help managing the development lifecycle. Over time I've developed a number of scripts that I use while working on either grizzly or glassfish to help manage the load. After a number of discussions, I've decided to share them in the hopes they will help others, too. Not of all these scripts are really glassfish or grizzly related so you might find them useful in your own projects as well. You can check out these scripts using git from this url: git://kenai.com/schema-doc~git-repo.
There are several scripts but I'll try highlight the more interesting ones. Just a note, though. These are bash scripts that have grown organically for a long time. So they're not necessarily going to be pretty. Some might even consider some of the hoops I've jumped through "stupid." That's fine. I'm not getting a Ph.D. with these. They work and that's enough for me. But anyway.
General Scripts
The first set of scripts that should apply to almost any project.
| script | description |
|---|---|
| changed.sh unknown.sh |
These scripts will show you any changed (or unknown) files for whichever VCS you're using. They currently support subversion, mercurial, and git. The git support is new-ish so let me know if something's off |
| findInJar.sh | As the name implies, this script will find every jar in or under the current director and grep for, well, really whatever you tell it. I wrote it with looking for classes in mind but since it just greps the contents, it will find anything that matches. It seems like everyone eventually writes a similar script so maybe this will save some people a little time. |
| failedTests.sh | This script requires that you use maven. It will run mvn surefire-report:report-only and scan for any failed tests. If it finds any, it will use the open command to open the report html in your default browser. It can, optionally, run your tests before looking for failures. If you'd like it to do this, simply pass --run to the script. |
GlassFish/Grizzly Related Scripts
Obviously, these scripts will be of little interest to those not working with some aspect of glassfish development. But if you're not, you're probably reading the wrong blog entry anyway. All of these scripts rely on the presence of environment variables. The scripts are set up to check for the variables and prompt you to define them so I won't go into them here. Just be aware that at first you'll have to define a few variable before these scripts will work for you. And these scripts need a UNIXy environment so if you're on Windows, you'll need something like cygwin to make these work. But even then, I've not tried these with cygwin so you might have issues even still. I'll refer to some of these variables by name below, but the script will walk you through what to set to what.
| script | description |
|---|---|
| distro.sh | This script will build the glassfish distribution bundles. Most of the heavy lifting is really done by maven but this script goes a step further and extracts the "glassfish" distribution of into ${GF_INSTALL}. Executed without parameters, it will build the distro, remove the current install, and unzip the new one. There are 3 options you can pass to this one:
|
| devtests.sh | This one is really specific. This will run the webtier devtests after reconfiguring the glassfish install in ${GF_INSTALL}. It can be run from anywhere so you don't need to worry about where to launch this one. Once the devtests finish, it will open the test_results.html displaying the results of the tests. This one takes a while to run. There are a lot of tests... |
| single.sh | Similar to devtests.sh, this test will run a single test in the webtier devtests. Just pass it the name of the directory while in v2/appserv-tests/devtests/web and it'll do the rest. |
| quicklook.sh | This script runs the quicklook tests to test your v3 tree. This script takes --debug and will run the quicklook tests using the mvnDebug script. |
| updateBundle.sh | This script compiles the current maven module and copies the resultant jar into your glassfish install. This should work for any glassfish-related project. I use it with grizzly, too, for example. |
| rebundle.sh | This script will scan svn looking for changed files and try to determine the module owning each file. It will then call updateBundle for each of those modules and update your glassfish install. Passing --start will then launch glassfish with your updated code. |
| startgf.sh stopgf.sh |
These scripts will start/stop glassfish from wherever you may be in the filesystem. Passing --debug will launch glassfish in a debug VM. It will also update your domain.xml such that the launch will pause until you connect to it with a debugger so be aware that things will appear to hang until you do. |
| tailgf.sh | This will tail your glassfish's server.log from wherever you are in the filesystem. If glassfish is not yet running, it will also truncate the logs first. |
That about does it. I use these scripts daily and I find them quite useful. Hopefully, you do as well.
GlassFish Web Sockets Sample
A few weeks back I blogged about the impending GlassFish support for the emerging Web Sockets standard. To update, I have some good news and some some ok news. The good news is that the implementation has stabilized enough to show some concrete code. The ok news is that, despite my best efforts and overly persistent petitioning, this support won't show up in 3.0.1. You'll need to use the GlassFish nightly builds to play with it. Hopefully that's OK given that web sockets are still evolving anyway and browser support is spotty at best. With that out of the way, let's look at a simple example.
For familiarity's sake, and for simple comparison, I ported the comet chat sample in grizzly to use web sockets. I wanted to see how different the code would look between two similar applications. So if you're familiar with the comet example, the web socket example should be very familiar. At the heart of grizzly's/glassfish's web socket support is the WebSocketApplication. For our chat, it's pretty simple: every time someone sends a message, broadcast it to everyone. The code is pretty simple:
package com.sun.grizzly.samples.websockets; import com.sun.grizzly.tcp.Request; import com.sun.grizzly.tcp.Response; import com.sun.grizzly.websockets.DataFrame; import com.sun.grizzly.websockets.WebSocket; import com.sun.grizzly.websockets.WebSocketApplication; import java.io.IOException; import java.util.ArrayList; import java.util.List; import java.util.logging.Level; public class ChatApplication extends WebSocketApplication { List<webSocket> sockets = new ArrayList<webSocket>(); @Override public WebSocket createSocket(Request request, Response response) throws IOException { final ChatWebSocket socket = new ChatWebSocket(this, request, response); sockets.add(socket); return socket; } public void onMessage(WebSocket socket, DataFrame frame) { final String data = frame.getTextPayload(); if (data.startsWith("login:")) { login((ChatWebSocket) socket, frame); } else { broadcast(data); } } public void onConnect(WebSocket socket) { } private void broadcast(String text) { WebSocketsServlet.logger.info("Broadcasting : " + text); for (WebSocket webSocket : sockets) { send(webSocket, text); } } private void send(WebSocket socket, String text) { try { socket.send(text); } catch (IOException e) { WebSocketsServlet.logger.log(Level.SEVERE, "Removing chat client: " + e.getMessage(), e); onClose(socket); } } public void onClose(WebSocket socket) { sockets.remove(socket); } private void login(ChatWebSocket socket, DataFrame frame) { if (socket.getUser() == null) { WebSocketsServlet.logger.info("ChatApplication.login"); socket.setUser(frame.getTextPayload().split(":")[1].trim()); broadcast(socket.getUser() + " has joined the chat."); } } } |
As you can see, we implement some very basic logic here. This, of course, could be as complex as you need it it to be. In a real chat application, for example, we'd have rooms/channels and the like but we're keeping it simple here. The other class to note is ChatWebSocket. There's not much need to provide custom WebSocket implementations but in this case, I chose to store the chat user's user name on the WebSocket. I could've used a Map in ChatApplication and used the default implementation but this seemed a bit more ... OOPish. The implementation there is, again, quite simple:
package com.sun.grizzly.samples.websockets; import com.sun.grizzly.tcp.Request; import com.sun.grizzly.tcp.Response; import com.sun.grizzly.websockets.BaseServerWebSocket; import java.io.IOException; public class ChatWebSocket extends BaseServerWebSocket { private String user; private final ChatApplication app; public ChatWebSocket(final ChatApplication listener, Request request, Response response) { super(listener, request, response); app = listener; } public String getUser() { return user; } public void setUser(String user) { this.user = user; } @Override public void send(String data) { super.send( toJsonp(getUser(), data) ); } @Override public void close() throws IOException { WebSocketsServlet.logger.info("closing : " + getUser()); app.remove(this); super.close(); } private String toJsonp(String name, String message) { return "window.parent.app.update({ name: \"" + escape(name) + "\", message: \"" + escape(message) + "\" });\n"; } private String escape(String orig) { StringBuilder buffer = new StringBuilder(orig.length()); for (int i = 0; i < orig.length(); i++) { char c = orig.charAt(i); switch (c) { case '\b': buffer.append("\\b"); break; case '\f': buffer.append("\\f"); break; case '\n': buffer.append("<br />"); break; case '\r': // ignore break; case '\t': buffer.append("\\t"); break; case '\'': buffer.append("\\'"); break; case '\"': buffer.append("\\\""); break; case '\\': buffer.append("\\\\"); break; case '<': buffer.append("<"); break; case '>': buffer.append(">"); break; case '&': buffer.append("&"); break; default: buffer.append(c); } } return buffer.toString(); } } |
Again, it's pretty simple. There's some extra code for escaping the text since in our javascript, we'll simply eval() the text and let the browser work its magic. With these two pieces in place, we're almost done on the server. In order to let the web sockets system know of our application, we need to register it. (This is an optional step that we'll cover later.) In our case, we have a servlet in our web app. The servlet actually doesn't do anything. It doesn't override doGet() or doPost(). It only really exists for this one method:
@Override
public void init(ServletConfig config) throws ServletException {
WebSocketEngine.getEngine().register(config.getServletContext().getContextPath() + "/chat", app);
} |
This line registers the request URI with the WebSocketEngine so that it knows that when it sees a web socket request come in that matches that URI, to hand things off to the appropriate application. For our chat sample, we need an application to handle the logic related to running a chat system. However, if you don't need such logic, you don't even have to register (or write) and application class at all.
When a web socket request comes in, grizzly will look for any registered application for that URI. If it can be found, handling is handed off and grizzly's request handling is done. However, if no application can be found, grizzly can still process the web socket request by deferring the request to whatever the ultimate endpoint is. Grizzly will still frame anything written back to the client from, say, the servlet such that your web socket client gets a proper response. This scenario doesn't support bidirectional conversations, but it does allow you to expose any URL to a web socket client with no additional work.
There is one final step before we can try out the sample. Web socket support is disabled by default in grizzly and in glassfish so we must enable it first. In glassfish, we can do this by issuing this command:
asadmin set configs.config.server-config.network-config.protocols.protocol.http-listener-1.http.websockets-support-enabled=true |
You will need to adjust the name of the protocol element to match your system if you changed any of that, but if you use the standard configuration, that's all you need. If you're using grizzly outside of glassfish, you have neither asadmin nor a domain.xml. For that, you'll need to enable web socket support on your SelectorThread:
SelectorThread st = new SelectorThread(); /* whatever other settings you might need */ st.setAsyncHandler(new DefaultAsyncHandler()); st.setEnableAsyncExecution(true); st.getAsyncHandler().addAsyncFilter(new WebSocketAsyncFilter()); |
That does it for the server side. On the client side we have the usual mix of HTML and javascript. I don't want to go in to depth on most of that but I do want to take a look at one particular piece. In application.js, we have this code:
var app = { url: 'ws://localhost:8080/grizzly-websockets-chat/chat', initialize: function() { if ("WebSocket" in window) { $('login-name').focus(); app.listen(); } else { $('missing-sockets').style.display = 'inherit'; $('login-name').style.display = 'none'; $('login-button').style.display = 'none'; $('display').style.display = 'none'; } }, listen: function() { $('websockets-frame').src = app.url + '?' + count; count ++; }, login: function() { name = $F('login-name'); if (! name.length > 0) { $('system-message').style.color = 'red'; $('login-name').focus(); return; } $('system-message').style.color = '#2d2b3d'; $('system-message').innerHTML = name + ':'; $('login-button').disabled = true; $('login-form').style.display = 'none'; $('message-form').style.display = ''; websocket = new WebSocket(app.url); websocket.onopen = function() { // Web Socket is connected. You can send data by send() method websocket.send('login:' + name); }; websocket.onmessage = function (evt) { eval(evt.data); $('message').disabled = false; $('post-button').disabled = false; $('message').focus(); $('message').value = ''; }; websocket.onclose = function() { var p = document.createElement('p'); p.innerHTML = name + ': has left the chat'; $('display').appendChild(p); new Fx.Scroll('display').down(); }; }, post: function() { var message = $F('message'); if (!message > 0) { return; } $('message').disabled = true; $('post-button').disabled = true; websocket.send(message); }, update: function(data) { if (data) { var p = document.createElement('p'); p.innerHTML = data.name + ': ' + data.message; $('display').appendChild(p); new Fx.Scroll('display').down(); } } }; |
Most of that is prototype/scriptaculous code for managing the UI but notice in login() how we connect to the server and define our callbacks for when we receive various events. In post() we send our entry to the server and in update() we take what the server gives us and update the UI accordingly. It's a very simple and naive system to be sure but serves to illustrate the basics without getting mired down in details of building a large scale, fault tolerant system. Yes, I know there are things that could be improved with this or that detail. But I'm not building a replace for Yahoo! chat. 
If you want to see the code in full, you can browse the grizzly subversion repository here.
Now, there *is* some bad news but it's temporary at least. This code is in the trunk of grizzly's subversion repository and will be included in the 1.9.19-beta2 release. This hasn't been integrated into glassfish 3.1 yet but will be soon. Until then, you'll need to build your own grizzly tree and glassfish distribution with the root pom updated to use 1.9.19-SNAPSHOT. This is, indeed, quite ugly but we should be integrating a new 1.9.19 beta soon and then you can simply use the nightly builds.
If you have any questions, please leave a comment or, better yet, join the dev and/or users mailing lists here. There's still some tweaking left to do here and there but things are shaping up quite nicely, I think. But I won't know what's missing or wrong unless you tell me. So, please, play. Comment. Let me know what you think.
Wicket and Embedded GlassFish
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.
Subversion and the bash prompt
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.
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 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.