You can download the new API, along with the implementation, from the Mojarra project download area. For the folks using the Glassfish Application Server, the new API will be available via the Glassfish Update Center later today... but remember that this is very early code, so don't update your production machines just yet. Release notes for the EDR1 release of Mojarra are also available.
The actual JSF 2.0 EDR1 specification is available from the JCP site.
For those who'd prefer a more example-laden description of some of the new JSF 2.0 features, please check out Ryan Lubke's blog - he's been blogging about the new 2.0 features since February - skip back a bit in his blog to Part 1, and start reading from there.
As always, we'd love to hear your feedback! The whole purpose of this release is to get feedback both on the API, as well as on the implementation of it, so feel free to leave comments either here, on our forum, or on the mailing lists - or you could even just file a bug, either on the implementation or the spec.]]>
That said, they both only cover a small amount of the information you need.
I was able to put together the rest of the information required by looking at an existing example for Roller, as well as reading some of the API docs.
First, let's go over the actual structure of the program - there's really three different parts: The addon module (which has two parts, the installer and the configurator), and the update center module itself. The addon module is the way to actually modify Glassfish, while the update center module is just a delivery mechanism for the addon module. In fact, you can run the addon module without the update center by issuing the command asadmin install-addon addonfilename.jar, as well as removing the addon with asadmin uninstall-addon addonname.
The addon module is divided into two parts - the installer, and the configurator. The installer runs when the addon is first run, and it knows about the location of the install directory of the App Server. This is the process that you'd use to actually move all the files around to their proper places. The configurator runs when you next restart the App Server, and it knows about the location of the server instance that it's started under. This is the process that you would use to modify the server's configuration, located in the domain.xml file.
So, with all that in mind, take a look at the code that I wrote, and follow along:
First, we'll write the installer. This class implements com.sun.appserv.addons.Installer, and there are two methods that matter to us right now - install and uninstall. To install, we're going to take two files (jsf-api.jar, and jsf-impl.jar) and put them into the lib directory of Glassfish, backing up the existing jsf-impl.jar. Uninstall will reverse the process. First, we need to find destination directory - we do this by using the InstallationContext we're passed as part of the method call:
File appserverDir = ic.getInstallationDirectory();
String appServerInstallRoot = appserverDir.getAbsolutePath();
String appServerLibDir = appServerInstallRoot + File.separator + "lib";
And we also need to find the source for these files - which is the jar that we created for the install.
String addOnsDir = appServerInstallRoot + File.separator + "addons";
String installerJar =
addOnsDir + File.separator + INSTALLER_JAR;
Where INSTALLER_JAR is the name of the installer file.
Now, the rest of the program is just standard unjar, copy, and move commands in Java, except for one last thing: we also need to place the configurator jar someplace where the starting App Server instance will find it upon next startup.
String addOnsLibDir = appServerInstallRoot + File.separator+ "lib" + File.separator + "addons";
....
File confJarFrom = new File(tmpWorkDir + File.separator + CONFIGURATOR_JAR);
File confJarTo = new File(addOnsLibDir + File.separator + CONFIGURATOR_JAR);
copyFile(confJarFrom, confJarTo);
Where, once again, CONFIGURATOR_JAR is the name of the jar file that holds the configurator information.
Now we'll talk about the configurator. Don't worry, we'll discuss packaging next. The configurator implements com.sun.appserv.addons.Configurator, and once again, there are two methods we need to be concerned about: configure and unconfigure. Our configure method does only one thing: it loads the domain.xml configuration file into a DOM tree, modifies the part that we need to change, and then writes it back out. Unconfigure will reverse this process. First, we need to find the domain.xml file for the running instance:
String domainRoot = cc.getDomainDirectory().getAbsolutePath();
String domainFilePath = domainRoot
+ File.separator + "config"
+ File.separator + "domain.xml";
File domain = new File(domainFilePath);
Then we simply modify the xml and rewrite it in a fairly standard manner. Note that since we're going to be changing the classpath of the server, a addtional restart is going to be required, for a total of two restarts (one to run the configurator, and one more to change the classpath.)
Now, let's talk packaging, because that's the entirety of what's left to do. Manveen's blog covers this, but it's worth going over again.
The configurator jar will have two parts - a file, called services/com.sun.appserv.addons.Configurator which contains the name of the file implementing Configurator as it's content, and the class files, including the named file. Also, the configurator jar file should be named something like addonname_configurator_versionstring.jar by convention.
The installer jar is similar in structure - a file, named services/com.sun.appserv.addons.Installer containing the name of the file implementing the Installer interface. The installer jar will also have the files to install, such as jsf-impl.jar in our case, as well as the configurator jar file mentioned above. This installer jar is the file that you can use with the asadmin install-addon command.
Lastly, there's the Update Center module jar. The format of this jar is based on the Netbeans module format. Pretty simple stuff - there's two top level directories - info and module. Under module, we have the installer jar file. Under info, we place a small info.xml file, which is basically just a stub. Ours looks like this:
<module codenamebase="jsf2.0">
<description>JavaServer Faces 2.0 EDR1 Release</description>
</module>
Lastly, if you want to put this into the official Glassfish Update Center, you'll need an additional xml file - for information on this, check out Manveen's Update Center Testing blog.
So, that's it - how to write an update center module that installs a new library, and adds it to the classpath of the app server in domain.xml. Hope this helps you.
UPDATE: There's a little confusion about how uninstalling works, so it's probably worth a quick note: GF v2 doesn't support a programmatic unconfigure (or for that matter, uninstall) via the updatetool - when you want to uninstall an installed module, you need to first manually edit a configuration file called domain-registry in your domain's config directory (the same place as the domain.xml file). You'll find two properties there - change them to "false". My file looks like this:
#Wed Jun 25 13:17:28 PDT 2008 jsf2.0_configurator_01_00_00.configured=true jsf2.0_configurator_01_00_00.enabled=trueOnce you've changed these files, bounce the server. That will run the Configurator's unconfigure method of the configurator class. Then, uninstall the package either via the updatetool or via
asadmin uninstall-addon addonname - that will then run the uninstall method of the installer class.
]]>
You can find the full Netbeans project here.
Essentially, the program logic is contained in only two files: ttt1.html, and CometServlet.java. Check 'em out. After my initial example two posts ago, these should be pretty self explanatory. If you have any questions, by all means ask in the comments below.]]>
Turns out the answer is both easy and blindingly obvious once you think of it: the iframe onload event. And while we're add it, we'll add a onerror event too.
In my previous program, I had had a hidden iframe, and on every update, I would reset the source for the iframe using the location property.
We'll still do that, but add a new function:
<iframe name="hidden" src="CometCount" frameborder="0" height="0" width="100%"
onload="restartPoll()" onerror="restartPoll()" ></iframe>
Note the onload and onerror events - whenever the server closes the connection, these will be called. And here's the function that's called:
var retries = 0;
function restartPoll() {
if (retries++ > 10) {
alert("The connection has errored out too many times");
} else {
hidden.location = url;
}
}
Also, I've added a retry limit in there - it wouldn't do to have the client go into a fatal spin just because the server is down.
Now when the server closes the connection (from a timeout, or an error), the client will continue to function, automatically calling back into the server. Not a solution you'll want for every situation, but useful enough, especially for our small example.
Lastly, there was a bug in my previous version under IE - sorry about that. It turns out that if you send a POST via IE, you need to have a content body, or IE gets fussy. The fix is to change the line
xhReq.send(null);
to
xhReq.send("null");
I've uploaded new versions of the files index.html and CometCount.java, so you can see the complete code in context.
]]>
I've whittled it down to about 100 lines, and only 2 files, and I thought I'd go over it here. The full example (both files) are index.html and CometCount.java. So this will be a little long, but if you're tired of reading my rambling, just look at the files, and the code should speak for itself.
First, about the app: It's a simple counter, which is updated every time you hit a button on the page. Pretty basic, except - every other web browser viewing that page will have the counter updated as well, through the magic of Comet.
About setting it up: make sure that the url mapping points to /CometCount, the value is hardcoded in a few places. Also, to compile you'll need access to the Grizzly Comet APIs - you can either get them from Grizzly, or Glassfish v3 tp2. You'll need to also add the jar in the modules directory named grizzly-optionals to your classpath in order to build, along with the standard Servlet API. You'll also need to update the domain.xml of the v3 instance to add the property cometSupport=true, as you see below:
<http-listener acceptor-threads="1" address="0.0.0.0"
blocking-enabled="false" default-virtual-server="server"
enabled="true" family="inet" id="http-listener-1" port="8080"
security-enabled="false" server-name="" xpowered-by="true">
<property name="cometSupport" value="true"/>
</http-listener>
Now on to the description of the program flow. On startup, the servet is initialized, and registers itself with with the Comet Engine (make sure the servlet is installed with a url CometCount, or it won't work). We set a timeout of 2 minutes.
public void init(ServletConfig config) throws ServletException {
super.init(config);
ServletContext context = config.getServletContext();
contextPath = context.getContextPath() + "/MyComet";
CometEngine engine = CometEngine.getEngine();
CometContext cometContext = engine.register(contextPath);
cometContext.setExpirationDelay(120 * 1000);
}
Then on the first load of index.html in the browser, the hidden iframe makes a call to the doGet of the servlet - this call suspends, awaiting further action. It does this by attaching the response to a handler (of type CounterHandler), and attaching the handler to the servlet's CometContext. This also gives rise to the first bug of the program - there's no display of initial result.
So this:
<iframe name="hidden" src="CometCount" frameborder="0" height="0" width="100%"></iframe>
calls this:
protected void doGet(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
CounterHandler handler = new CounterHandler();
handler.attach(res);
CometEngine engine = CometEngine.getEngine();
CometContext context = engine.getCometContext(contextPath);
context.addCometHandler(handler);
}
Next, someone, somewhere, who's also using the program, hits the button marked "click". This calls the onclick method, postMe(). postMe sends an empty POST to the servlet, triggering the doPost method.
So this:
<input type="button" onclick="postMe();" value="Click">
Calls this:
var url = "CometCount";
function postMe() {
function createXMLHttpRequest() {
try { return new XMLHttpRequest(); } catch(e) {}
try { return new ActiveXObject("Msxml2.XMLHTTP"); } catch (e) {}
try { return new ActiveXObject("Microsoft.XMLHTTP"); } catch (e) {}
alert("Sorry, you're not running a supported browser - XMLHttpRequest not supported");
return null;
};
var xhReq = new createXMLHttpRequest();
xhReq.open("POST", url, false);
xhReq.send(null);
hidden.location = url;
};
The doPost method increments the counter, and then sends a notify event to the servlet's CometHandler.
protected void doPost(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
counter.incrementAndGet();
CometEngine engine = CometEngine.getEngine();
CometContext context = engine.getCometContext(contextPath);
context.notify(null);
}
This event now wakes up that initial GET request, and sends a bit of javascript down the line. Lastly, we call resumeCometHandler, which marks the current event as completed, removing it from the active queue.
public void onEvent(CometEvent event) throws IOException {
if (CometEvent.NOTIFY == event.getType()) {
int count = counter.get();
PrintWriter writer = response.getWriter();
writer.write("<script type='text/javascript'>parent.updateCount('" + count + "')</script>\n");
writer.flush();
event.getCometContext().resumeCometHandler(this);
}
}
Back at the client, that javascript that got sent down gets put into the hidden iFrame, and then executed. This calls the updateCount function, which updates the counter with the new value. Then, we set the iframes' location object, which reconnects with GET to the servlet, and we're ready for our next request.
function updateCount(c) {
document.getElementById('count').innerHTML = c;
hidden.location = url;
}
That is, unless we time out. If we time out (remember, we set the timeout to 2 minutes, not "infinite"), the iframe goes dead, the GET polling loop is broken, and we never again update the counter on the webpage, though the user's increasing frustrated button pushing on the client will happily update counter on the server. So, to get around this, we add a single line at the end of our postMe function, updating the hidden iframe's location again. This is the one really hacky part of the program, and I'd love to know a better way to do it. Also, it gives rise to the second bug of our program, related to the first - if the connection dies, you need to click the button twice to see an update of the counter on the client.
So - ta da! We have a bare bones, long polling comet application in two files and about 100 lines.
Again, here's the programs Download file index.html Download file CometCount.java
Jeanfrancois Arcand and I have a BOF on Wednesday night (May 7th, 2008) at JavaOne. If you're at JavaOne and are just getting started with Comet, come on by.]]>
The symptoms of the bug are a crash with an error message that contains:
xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
At Dave Shucks blog, I found a patch that works:
LIB_TO_PATCH=libmawt.so
for f in `find /opt -name "$LIB_TO_PATCH"`
do
echo "Patching library $f"
sudo sed -i 's/XINERAMA/FAKEEXTN/g' "$f"
done
Where "/opt" is a directory where you keep your JDKs.
The fix is widely available on the internet, but I thought it was worth restating here.
]]>My current thought - we're going to have lots of stuff related to modern web practices (i.e., Web 2.0, I don't care for the term). But like last year, it's going to be a balancing act - we can't have every session be "Introduction to AJAX Programming". Besides, we try not to cover things two years in a row.
What do you want to see? Please leave me comments below.]]>
One thing we'll do is have a Lessons Learned meeting, and I want to be ready - so I thought I'd throw out my ideas for what worked and what didn't, and ask for a little help in working on my list. Here's your chance to kvetch with me!
First, what worked: I thought the talks pretty much rocked. Now, prehaps I'm a little biased, but really, I didn't hit any clunkers. This is the one thing I DON'T need to worry about for the meeting, since we'll have *very* accurate data on attendance and evaluations. But I'm pretty pleased with this, since the talks *are* mostly why you came to JavaOne, right? Also, I thought that the keynotes were mostly OK, and there were some neat demos.
The food at lunch wasn't bad - for cafeteria food, anyway (ok, it's a low bar). And the lines for lunch moved more quickly than I would have thought possible, given just how many people were filing through there.
I'm going to go out on a limb, but I'm going to say that by the last day, the reserved seating thing was working well. Over and over again, I went to full talks, confident that I'd get in. The lines moved much faster, crowd control was better, and they had more card readers and docents.
Then, there's what didn't work: The stage crew was noticably incompetant. I watched a speaker beg for his slides to be shown for about 4 minutes - and this was the third time that that had happened to him that talk. And it happened to him in a previous talk that day. And he wasn't alone. Demo screens only on the left side of the room? Excuse me? There were lots of problems with audio in 307. And ask any keynote demo person about the sysadmins... and you'll get an earful. The WiFi was up and down like a yoyo. But at least the cardreaders worked better than last year - in fact, I think those worked well.
A loud audible alarm went off at the end of a speaker's talk - several commented that they would have liked a more subtle 1 minute warning, though other speakers seemed to have no trouble - by watching the clock up on stage.
I think that covers it - did I miss anything? Tell me below. Both bad and good (so we don't forget to do it next time :-)
See you next year!
]]>
Well, we're now far enough along to talk about things - there' quite a few different things in particular that we've announced this week that merit special attention:
The old standard of the Blueprints Petstore has gotten a new look, in the new Java Petstore 2.0 EA - with lots of AJAXey goodness. If you haven't checked it out yet, you should. The Blueprints guys have also been working hard on all getting out all kinds of AJAX related information, including a nifty set of JSF AJAX components, that are also usable in Java Studio Creator...
But of course, that's not all - Project jMaki is a really neat wrapping technology (Maki is "wrap" in Japanese) that takes JavaScript widgets and puts them inside JSP and JSF tags in a really simple way - and Greg's got a bunch of components aready done - check it out - there's support for Dojo, Scriptaculus, Yahoo UI Widgets and DHTML Goodies.
There's also JSF Dyamnic Updating - this is a JSF extension library which divides the page into zones, and allows partial updating of pages through these zones.
Lastly, who says JavaScript needs to just be on the client? Project Phobos is a framework to allow scripting on the server side. And since there's native support for JavaScript in Rhino in Mustang, JavaScript is supported out of the box in Phobos - it's really interesting, check it out.
And of course, there's more on the way - watch our main AJAX page to hear more.]]>
Well, first day is mostly done, and I think we've gotten a pretty good idea of how it's working.
My evaluation is "could be better". I've yet to see the first 3 slides of ANY talk that I've attended - and I was registered for all of them. On the other hand - I actually got in to all the talks that I wanted to see - because I was registered (and 2 of them were totally full).
So - what's the problem? Crowd control is an issue - the lines are longer, and take longer to traverse, than in previous years. Which means that crowd control is more of an issue, and was probably not planned for well enough.
Also, if you're going to stuff 1200 people into a room in 15 minutes, how many stations for reading cards would you have? Hint: More than 4.
And lastly, if you've got a real problem with getting people in quickly, doesn't it make sense to open the rooms up as soon as you can? So far, they haven't - rooms were closed until 15 minutes before the sessions started, even if the rooms were free.
So, what can be done about this? Well, it seems clear that in order for this to be successful, we're going to have to put more people on crowd control, and get more badge readers.
I know that the organizers are looking hard at this, and I suspect that we'll see improvements tomorrow. What's your experience? Please comment below. ]]>
Every year at JavaOne, we have the same problems - some talks are in big rooms, and you can hear the crickets chirp. Others are in medium (600 capacity) rooms, and there are people sitting on the floor - or worse, turned away at the door. We do the best we can at guessing, but it's impossible to get it right 100% of the time. And hastily thrown together overflow rooms are only a patch on the problem.
So, JavaOne is going to be run a bit differently this year. Instead of queueing up outside the talk you wish to attend (or camping in the room prior to the previous talk ending), there's going to be reserved seating.
No, really... reserved seating. You'll be required to register ahead of time for the talks you wish to attend, and everyone who's registered will get to go in first. Only after all the registered people go in will the unregistered people be allowed to go into the room. This also means that the rooms will be cleared after each talk.
I have to say, when I first heard this, I was a little skeptical - the Esplanade, in particular, tends to get really crowded with human traffic at every talk change. Visions of mobs of unhappy people milling about in that narrow corridor quickly sprang to mind. I wasn't the only one who was skeptical, either. But the conference organizers assured us that they'd done the same thing for other conferences as well (many as big as JavaOne), and they had answers for every objection that we threw at them. In the end, we were convinced - moving around 10k+ people is a difficult job, but it's what they do for a living, and they're pretty good at it.
Doing things this way has some obvious benefits - for one thing, it'll allow us to change our plans for how we'll be giving talks BEFORE everyone shows up at the door. It also has some interesting benefits that may not be readily apparent at first glance - such as allowing us to really plan a better JavaOne next year, since we'll finally have a truely accurate attendance number for each talk.
So, I'm optimistic about the process. But it will only work if everyone goes out and registers for the talks they want to attend. So, if you've already registered for JavaOne, please don't skip this step.
As always, I'd love to hear what you think of this idea. Let me know below.]]>
In his book, Bruce says: "In the halls of Netscape, server-side Java emerged. Servlets (a term originally coined by O'Reilly) made server-driven Internet applications available to application developers. Sun capitalized on this movement quickly with a standard, and an open source implementation of a servlet engine called Tomcat."
Whoosh, where to start. Prehaps at the beginning:
Servlets were originally conceived of by James Gosling in 1995, but put aside for other interests. After some time, the concept was picked up by Pavani Diwanji, who built on the concept to create servlets as part of a project then called Jeeves (from a fictional character). This project was eventually productized into the Java Web Server, which many of us in Java EE land remember fondly to this day. I still have a shirt showing Duke in a Tux holding a platter, the symbol for Java Web Server. And incidently, the first versions of the servlet package were called java.servlet.*, since the javax extension hadn't been invented yet.
Incidently, JSP was invented over a weekend by Anselm Baird-Smith, then later elaborated on as a specification by Satish Dharmaraj (now of Zimbra). (Just in case anyone was curious.)
The server-side Java container conceived of by Netscape was done as a parallel effort, as was another similar thing done by Oracle. (I was part of the team that visited both companies to try to sell them on this technology.)
The Tomcat stuff came a few years later, as did the first version of the servlet spec, written by James Davidson.
As for O'Reilly coining the term servlets, I don't know for sure about that, but given the history I do know, I'm skeptical.
There, I've gotten that off my chest.
Know something I don't? Please comment below.
]]>Neither did I, until a couple of months ago.
So, if you're the kind of person who likes to watch sausage being made, or you're just an amateur fan of the Open Source license process, go check it out:
To subscribe to the mailing list, send an email to license-discuss-subscribe@opensource.org
The original pointer on the OSI site is here. It's a little hard to find without a full read of the site, so I thought I'd help point interested people in that direction.
So what's discussed on this list? Well, remember that in order for a license to be called Open Source, that license needs to be approved by the OSI's directors. This list acts as a group of advisors to the OSI (in classic FOSS fasion, you get a voice by just showing up and making sense).
Currently, it's a little slow, so it's a perfect time to sign up - there isn't any current crisis that's driving email traffic.
Look forward to seeing you there.]]>