Thursday Dec 10, 2009

The Ajax Experiment

Ajax was not new to our team, however, we had not used it too extensively in our application in the past -- we generated bread crumbs, calculated when the browser needed to be reloaded, and populated tree nodes when server state changed.  To solve our performance problem, we decided to Ajax was our best hope (or going back to frames -- and that was NOT going to happen)....[Read More]

Tuesday May 26, 2009

JavaOne Hidden Treasure

JaveOne is 1 week away! Hurray!  What are you going to be doing at JavaOne?  Reply with what you're looking forward to seeing at JavaOne, I'm curious. :)

One cool thing during JavaOne that I suspect many people didn't know existed, are the Hands-on Labs.  Everyone knows about the traditional sessions where you hear a good (usually) speaker talk about an interesting topic (or where you can relax and check email in peace).  However, the Hands-on Labs are the hidden treasure of JavaOne.

The Hands-on Labs take a topic and let you learn about them by doing.  Topics range from several JavaFX labs (REST, WebServices, Mobile, and more), to cloud computing, to SIP applications, or the lab that I co-authored: Building OSGi Plugins for the GlassFish v3 Administration Console.   Each lab is either presented in a Bring Your Own Laptop (BYOL) format, or has machines already configured with the lab software ready to go at JavaOne.  Regardless of format, they provide step-by-step instructions on how to complete the lab.

Hands-on Lab Instructions

The building OSGi plugins lab that I helped write shows how the GlassFish Admin Console web application was written to take advantage of OSGi bundles.  The lab walks you through the process of creating several OSGi plugin bundles which add new features to the web application.  You have a chance to create a twitter plugin (thanks to Ryan Lubke), make a Jeopardy game, add a tagging capability to the console, and more.  And best of all, the concepts in the lab can be applied to your own GlassFish web applications.  Here's a screenshot of what the tagging plugin looks like after you're done (also with a "notes" plugin installed):

GlassFish v3 Admin Console with Tags and Notes Plugin

So... if you didn't know about the JavaOne Hands-on labs, or you haven't checked them out in the past.  Give them a shot this year -- you won't be disappointed.  Remember to Bring Your Own Laptop to the ones listed as BYOL when you search Schedule Builder (the Building OSGi plugins lab will be in a machine-provided room on Wed at 1:35PM).

Whether you choose a Hands-on Lab or not, I hope everyone attending JavaOne has a great time.  Don't forget to reply and post what you're looking forward to seeing at JavaOne this year.  Also, if you're planning on attending my OSGi plugins lab, let me know!

See you at JavaOne!

Wednesday Feb 25, 2009

Looking for Opinions...

The GlassFish admin console team has been working hard on ways to simplify our development, while at the same time attempting to improve the experience of using the console.  We have created a prototype which shows a couple different designs we are considering -- we'd like your feedback.  Here's how you can help:
Here are some things we are particularly interested in feedback on:
  • Do you like (or dislike) the menus?
    v3 Console with Menus
  • Do you like (or dislike) the tree?  (Be sure to click the "Toggle Scheme" button.)
    v3 Console with a Tree
  • Do you like / dislike the tagging feature? (See first screen shot above.)
Of course all other comments are also welcome (What's missing?  What do you really like?  What do you hate? etc.).  We know there are many issues with this UI, it is an early prototype -- far from production ready.  Just a few of the major issues we're aware of:
  • Many broken button clicks (particularly posts that don't do a redirect)
  • 404 pages cause a loop due to a JSF bug
  • Performance -- it's not good right now, it will be MUCH better when it's not a prototype (note: it also doesn't help that this prototype is running on a small desktop machine over a DSL-line... ;) ).
  • Many pages are broken (some intentionally for the public demo, others are simply not implemented)
  • List of tagged pages can sometimes show duplicates
  • Ajax for updating tags and other portions of the screen is not implemented
  • Breadcrumbs do not exist

So... as you can see we're not looking for bugs, but rather general feedback on the navigation and Look-and-Feel.  So post your thoughts and help make GlassFish better. :)

Thanks for taking a look!

Tuesday May 06, 2008

Tips for creating a GlassFish Admin Console Plugin

If you're at JavaOne 2008 you've probably already heard about the "Plug into GlassFish v3 Contest".  I'm going to give a few hints here to help get you started.

First, attend the "Plugin into GlassFish with JavaServer Faces and jMaki" lab.  Unfortunately this lab is difficult to get into, but don't worry!  If you are unable to attend the lab on Wednesday night from 6:30PM - 8:30PM, you can visit booth #175 and ask for a copy of the lab.  You can then do the lab exercises on your own time.  Or, if you attend another Hands-on Lab during JavaOne 2008, you can find the GlassFish plugin lab on the DVD (lab #4520).

Ok, now that you've worked on the lab, let me point out a few important things you need to know to be successful.

  1. Come up with a great idea.  In order to win the contest, you will need to have interesting content that appeals to GlassFish users and developers.  Plugins which add-on to GlassFish or highlight existing GlassFish features are also more likely to be picked.
  2. Be aware of your "plugin id."  The plugin id is specified in your "console-config.xml" file.  The value of the "id" attribute on the "console-config" element specifies your "plugin id".  This same value shows up in all urls to pages, images, CSS, and JavaScript.  If you include an aboslute path, you will need to know this value.  For example if your plugin id is "jeopardy," you might have something like this:

    <img src="#{request.contextPath}/resource/jeopardy/glassfish.gif" />

    So obviously your plugin id must be unique.  So make sure you change this value if you're copying code from the plugin lab.

  3. Load your resources from a jar file.  The plugin you create will be an OSGi bundle, which is a jar file.  This means a normal request for a resource (JavaScript, images, etc.) will fail.  However, simply adding "/resource" after your context path will solve this.  See the url in the image tag above for an example.
  4. Adding new Java code is broken.  We have not yet fixed some issues related to finding new Java code added via your OSGi plugin jar file.  To get around this, you must place your new code inside a jar and put the jar in the "<install-root>/lib/install/applications/__admingui/WEB-INF/lib" directory.

If you get stuck, get help.  You can post a question on this blog, email admin@glassfish.dev.java.net, or visit the GlassFish Pod #175.  We'll be happy to help get you unstuck.

For those of you not at JavaOne, you won't be able to participate in this contest, however, this may be a good way to contribute to GlassFish.  By contributing to GlassFish you may qualify for the GlassFish Awards Program.  Check the GAP program rules for details and earn your share of the $175,000.

Good luck!

Sunday May 04, 2008

GlassFish Birds Of a Feather (BOF) Session at JavaOne 2008

Tuesday night from 7:30PM - 8:20PM, there will be a GlassFish BOF (BOF 7900: GlassFish Application Server: Open Source, Fast, Easy and Reliable) in Gateway 104.  You'll be able to meet with many of the big names behind GlassFish, or get your tough questions answered by GlassFish experts.  In addition, the GlassFish team will challenge the audience to see what they know by playing a round of Glassfish Jeopardy for cool prizes!  This will be a fun BOF and a great networking opportunity -- see you there!

GlassFish game board

Friday May 02, 2008

Don't forget your laptop!

Are you lucky enough to be going to JavaOne 2008?  If so, don't forget your laptop!

This year at JavaOne there will be quite a few Hands-on Lab sessions where you will be able to try out cool technologies rather than just hear about them.  In many of them you'll be given courseware and the software needed to use the technology on your laptop, other labs will provide machines for you to use.

I will be one of the presenters for the "Plug into GlassFish v3 with JavaServer Faces and jMaki" lab.  The lab will show how GlassFish v3 will provide a pluggable platform which enables anyone to extend the functionality provided by the GlassFish v3 administration console.  This is done in the context of our JavaServer Faces application with the help of OSGi bundles and our plugin API for our application.  If you're already signed up, great!  If not, you can try to get in (the lab is already full) or stop by the GlassFish booth #175 in the Pavilion and you can get a copy of the lab to try on your own time.  Oh... and if you do create a GlassFish v3 plugin during JavaOne, you're eligible for a chance to win a Canon PowerShot SD1000 Digital Camera!  See the contest rules for more details.

Wednesday Apr 02, 2008

JavaServer Faces overview @ the Salem JUG

Yesterday I made a nice drive down I-5 from my home in Brush Prairie, WA to Oregon's state capital, Salem.  I spoke with the Salem Java Users Group about JavaServer Faces, and also demoed JSFTemplating and GlassFish.  Many of the members of the JUG were already using JavaServer Faces and had lots of good questions.  I had a great time and look forward to visiting them again to talk more about GlassFish!

You can find my slides here.  If you want me to come talk to your JUG (or company), send me an email (and possibly a plane ticket ;) )... or better yet, meet me at JavaOne 2008!

Thursday Jan 17, 2008

JSF Component Authoring Made Easy

Frustrated with the complexities of writing a JavaServer Faces component? With the help of the JSFTemplating and Woodstock projects, you can write a component with only two files.[Read More]

Thursday May 10, 2007

Howto win a Helicopter

How to win a helicopter @ JavaONE

BT had a booth at JavaONE for their Web21C SDK.  The SDK, among other things, allows you to write software that invokes a WebService hosted by BT to place a phone call between 2 parties.  You simply need to provide 2 phone numbers and BT calls both parties and connects the two.  They provide a limited amount of usage for free, and for a small fee you can use their service more, here's a link to their pricing.  The Web21C SDK opens up the door to many possibilities, however, that's outside the scope of this blog.

BT was offering a challenge at their booth: Use their SDK to place a phone call and win a remote controlled helicopter.  My son is 5 and would love to crash the helicopter, and it sounded like any easy task for GlassFish + JSFTemplating... so I got to work!

Here's what I had to do:

1) I started with the JSFTemplating demo application. (Note: I used the version from CVS so that I would already have a build environment setup which uses APT.)

2) I added the Web21C jar files to my WEB-INF/lib directory of the demo app.  They gave me a memory stick with these, but I think you can find them here.

3) I had problems w/ some of their jar files because many of them are already part of GlassFish and were not needed.  Also some of the versions may not have been compatible.  I ended up turning off classloader delegation by adding this to my sun-web.xml file:

  <class-loader delegate="false"/>

4) I registered my application.  BT requires you to register your application.  This was a necessary, but the most painful part of the process.  It required me to download the Web21C-Certificate-Tool, patch the JDK with the unlimited strength policy files, run their certificate tool, place the generated file in the WEB-INF/classes directory of the demo app, and create / place a security.properties file in the WEB-INF/classes directory that pointed to the generated file.

5) With the environment finally setup, I was ready to write the app!  I created the following JSFTemplating page:


call.jsf

<sun:page>
<sun:html>
<sun:head />
<sun:body>
<sun:form>
<sun:messageGroup />
<sun:propertySheet>
<sun:propertySheetSection label="Web21 Phone Dialer">
<sun:property>
<sun:textField required="true" label="Call From:" value="#{requestScope.from}" />
</sun:property>
<sun:property>
<sun:textField required="true" label="Call To:" value="#{requestScope.to}" />
</sun:property>
<sun:property>
<sun:button text="Make Call">
<!command
Web21.call(from="#{requestScope.from}", to="#{requestScope.to}");
navigate("calling.jsf");
/>
</sun:button>
</sun:property>
</sun:propertySheetSection>
</sun:propertySheet>
</sun:form>
</sun:body>
</sun:html>
</sun:page>



6) I created the following handler in a new java file called Web21Handlers.java (see above call.jsf page where the button is invoking this handler):

Web21Handlers.java

package org.example.handlers;

import com.sun.jsftemplating.annotation.Handler;
import com.sun.jsftemplating.annotation.HandlerInput;
import com.sun.jsftemplating.annotation.HandlerOutput;
import com.sun.jsftemplating.layout.descriptors.handler.HandlerContext;


/\*\*
\* <p> This class is written to demonstrate how to write a
\* <code>Handler</code>.</p>
\*/
public class Web21CHandlers {

/\*\*
\* <p> This is a handler makes phone calls.</p>
\*
\* @param context The <code>HandlerContext</code>.
\*/
@Handler(id="Web21.call",
input={
@HandlerInput(name="to", type=String.class, required=true),
@HandlerInput(name="from", type=String.class, required=true)
})
public static void calculateResponse(HandlerContext context) {
// Get the input.
String to = (String) context.getInputValue("to");
if (!to.startsWith("tel:+")) {
to = "tel:+" + to;
}
String from = (String) context.getInputValue("from");
if (!from.startsWith("tel:+")) {
from = "tel:+" + from;
}

com.bt.sdk.thirdpartycall.ThirdPartyCall tpc = new com.bt.sdk.thirdpartycall.ThirdPartyCall(to, from);
tpc.startCall();
}
}



7) I compiled the app (just typed "ant" on the command line, the demo application already has the build environment setup), started the server and went to http://localhost:8080/demo/call.jsf where I saw:

Screenshot 

After typing in the 2 phone numbers and clicking the "Make Call" button... the 2 phones rang! 

8) Finally... I showed this to the Web21C people and they gave me a helicopter!

Ken and Senthil 

(I'm in the blue Sun shirt.  You can also see this on flickr.)

That's how to get a helicopter using JSFTemplating + Web21C + GlassFish at JavaONE.


Sunday May 06, 2007

Streaming Content in JSF with JSFTemplating's FileStreamer

 

FileStreamer

I have received questions from several people about how to use the "FileStreamer" feature of JSFTemplating.  So I thought a blog would be the best way to demonstrate how it works. 

FileStreamer provides the ability for the FacesServlet to stream content to the client (i.e. web browser).  If that sounds generic, it is because FileStreamer is very generic.  It allows you to define a ContentSource that is capable of getting content from just about anywhere.  You might choose to get content from a database, retrieve it via a web service, generate it in code, access it from the filesystem or the classpath, or just about anywhere else.  The ContentSource interface allows you to specify the content and information about it so that appropriate http headers will be set, causing the client (browser) to treat it correctly (i.e. Content-type, Content-Disposition, etc.).  In addition to this, FileStreamer works in the context of JSF, meaning you will have access to managed beans or anything you require from your JSF environment.  (NOTE: FileStreamer actually provides a Context which interacts with its environment.  This allows different Context implementations to be provided for different environments; Servlet and JSF Contexts are currently available, see: ServletStreamerContext and FacesStreamerContext).

Lets look at a couple of examples.

Setup

First you have to have your JSFTemplating evironment setup.  Follow these instructions for this. 

Next to configure FileStreamer for JSF, add the following to your web.xml file:

  <context-param>
    <param-name>ContentSources</param-name>
    <param-value>org.example.contentSources.ExampleContentSource,org.example.contentSources.ProxyContentSource</param-value>
  </context-param>
  <servlet-mapping>
    <servlet-name>FacesServlet</servlet-name>
    <url-pattern>/resource/\*</url-pattern>
  </servlet-mapping>

The context-param registers 2 ContentSources.  The source to both of these is checked into JSFTemplating's demo application.  You can browse that source online here.  The servlet-mapping requires a prefix mapping and needs its own dedicated FacesServlet mapping.  "/resource/\*" is the default, however, this can be configured, see RESOURCE_PREFIX for more info.

ExampleContentSource

Let's take a look at the key part of the ExampleContentSource to see how it works.


ExampleContentSource.java:

public InputStream getInputStream(Context ctx) throws IOException {
// See if we already have it.
InputStream in = (InputStream) ctx.getAttribute("inputStream");
if (in == null) {
// Create some content...
in = new ByteArrayInputStream(("<b>Hello! You requested: '"
+ ctx.getAttribute(Context.FILE_PATH) + "'</b>").getBytes());


// Set the extension so it can be mapped to a MIME type
ctx.setAttribute(Context.CONTENT_TYPE, "text/plain");

// Save in case method is called multiple times
ctx.setAttribute("inputStream", in);
}

// Return the InputStream
return in;

The above ContentSource (ExampleContentSource) is very simple, it generates its content from a String (see green text above).  The String is some text with the request path (which is the PATH_INFO of the request, in other words the part of the URL after the "/resource").  Notice I added some HTML tags to show how they're treated.  The red text shows that the Content-type is being explicitly set to "text/plain".  This should cause the browser not to parse any html (so we should see those <b> tags on the screen).

 ExampleContentSource in action

As you can see, this simple ContentSource produces plain text in the browser.  You also see that the URL requires "contentSourceId=example".  "example" comes from the "id" of ExampleContentSource.

ProxyContentSource

Let's take a look at 1 more example ContentSource.  We'll use the same URL, except we'll use the contentSourceId of "proxy" to target our other ContentSource.  Below is the interesting part of the source code for ProxyContentSource.java:

ProxyContentSource.java:

public InputStream getInputStream(Context ctx) throws IOException {
// See if we already have it.
InputStream in = (InputStream) ctx.getAttribute("inputStream");
if (in == null) {
// Get the path...
String path = (String) ctx.getAttribute(Context.FILE_PATH);
while (path.startsWith("/")) {
path = path.substring(1);
}

// Get the URL...
URL url = new URL("http://" + path);

// Set the extension so it can be mapped to a MIME type
int index = path.lastIndexOf('.');
if (index > 0) {
ctx.setAttribute(Context.EXTENSION, path.substring(index + 1));
}

// Open the InputStream
in = url.openStream();

// Save in case method is called multiple times
ctx.setAttribute("inputStream", in);
}

// Return the InputStream
return in;

Again we are creating an InputStream, however, this time we are getting it via a URL.  This time instead of hard-coding the Content-type, we're setting the extension of the file so that it will be mapped to an appropriate Content-type.  Here's the output for the same URL as before (except w/ our "proxy" contentSourceId):

ProxyContentSource in action!

In this example, the content is pulled from java.sun.com from the server (not the client), then streamed to the client.  The appropriate Content-type of "image/gif" was sent to the browser so that it could treat the content correctly.  If you run this example, try other urls and types of media (html, pdf, doc, etc.).

I hope this blog gives you an idea of how FileStreamer functionality is useful.  Please leave a comment and let me know what you think!  Below is one more section describing how to configure FileStreamer in a Servlet environment (doesn't need JSF):

Servlet Setup

  <servlet>
    <servlet-name>servletStreamer</servlet-name>
    <servlet-class>com.sun.jsftemplating.util.fileStreamer.ServletStreamer</servlet-class>
    <init-param>
        <param-name>ContentSources</param-name>
        <param-value>org.example.contentSources.ExampleContentSource,org.example.contentSources.ProxyContentSource</param-value>
    </init-param>
  </servlet>
  <servlet-mapping>
    <servlet-name>servletStreamer</servlet-name>
    <url-pattern>/resource/\*</url-pattern>
  </servlet-mapping>

 

That's it... the rest is the same as above.  You can change the url mapping directly in the web.xml file in this case.  Oh... and yes, you can use the same ContentSources in both environments!

Have Fun!

 

About

paulsen

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today