Blog Archives

October 27th, 2010
2:07 pm
Primefaces Hotkey Component

Posted under JSF
Tags , , ,

This component binds a hotkey combination to specified javascript event handlers or ajax calls.
Unfortunately The Primefaces docs do not fully document the hotkey bindings.

This component appears to be based on the JQuery  js-hotkeys plugin which is documented here and has more details about the bindings and operation.

Note that some bindings are browser dependent – i.e. some browsers may not allow a browser hotkey to be overridden.
Also one gotcha to look out for is that hotkey prefixes (alt, ctrl) etc. are case insensitive but must be placed in alphabetic order, so ctrl-alt-s will not work.

No Comments »

September 26th, 2010
11:28 am
Choosing a DOCTYPE for maximum browser compatibility and standards mode

Posted under HTML
Tags , , , , , , ,

This follows on from my previous post which highlighted an example of a valid DOCTYPE which still threw IE into Quirks mode.

The DOCTYPE issue has been something of a minefield – there are a number of different declarations and they are relatively complex, some have browser compatibility issues, and then of course different ones are needed for XHTML/facelets use.

It seems the holy grail of simplifying all of this is just to stick to the remarkably simple and highly compatible HTML5 DOCTYPE:-

<!DOCTYPE html>

  • This has the following highly desirable characteristics:-
  • It triggers standards mode for all known modern browsers
  • It is backwards compatible
  • It works with HTML pages and facelets/XHTML

See these posts here, here and here for more discussion on this.

It really does seem to solve all the DOCTYPE pain – I think I’ve died and gone to heaven!

No Comments »

September 25th, 2010
11:32 am
Primefaces test application does not display correctly with Google Chrome

Posted under JSF
Tags , , , , ,

A simple Primefaces table sample application was not displaying in Chrome. Some of the output data from the cells plus some other metadata was displayed as raw text with no formatting.

This answer to FAQ question 6 in the documentation PDF details the problem and the solution:-

6. With facelets some components like charts do not work in Safari or Chrome but there?s no problem with Firefox.
The common reason is the response mimeType when using with PrimeFaces with facelets. You need to make sure responseType is “text/html”. With facelets you can use the <f:view contentType=”text/html”> to enforce this setting.

I added this to the sample code and Chrome then worked correctly. I checked the Primefaces Showcase and note that the same is done there.

No Comments »

September 22nd, 2010
5:28 pm
Simple Primefaces JSF app displays blank page – incorrect glassfish deployment

Posted under Eclipse
Tags , , , , ,

I recreated a new simple JSF application from scratch, in the end making it identical to an existing one that worked.
Each time I ran it on Glassfish 3.0.1 from Eclipse, it displayed a blank page as if not being sent to the faces servlet.
I checked every detail in making the apps identical – checking every configuration file and the xhtml page.
I cleaned and republished to Glassfish, but still no joy.

In the end I did a detailed examination of the deployment folders under the Glassfish domain (Eclipse deploys its apps under domain1\eclipseApps\ assuming you are using the default domain of domain1). I discovered that the Primefaces jar, primefaces-2.2M1.jar had not been deployed, even though the library was added and the web deployment assembly page had an entry for it.

I tried explicitly removing the app from Glassfish by using the Add and Remove… option on Eclipse’s server context menu for the Glassfish server, and then adding it back. This time, the deployment folders were correct and the library was deployed correctly. The application then ran correctly and displayed the page.

The lesson from this is that deployment to Glassfish 3.0.1 from Helios can be flakey, and just using a clean in Eclipse is not always enough to really clean out any issues. Removing the app and re-adding may be needed. If there is any strange behaviour, the deployment folders under the Glassfish domain should be examined early on to check that everything did in fact deploy – sometimes Eclipse will say it is all ‘synchronised’ when it may not be, and you will not always get smoking gun errors to lead you to the problem!

No Comments »

September 19th, 2010
8:46 pm
Servlet Mapping Issues with Glassfish V3.0.1

Posted under Glassfish
Tags , , , ,

There seem to be some servlet mapping issues with Glassfish V3.0.1.

To summarize, the following outlines what the servlet mapping logic should do:-

  1. The <url-pattern> as below matches the input url and if there is a match, passes the url to the designated servlet (in this case the faces servlet).
  2. The url parts that match are stripped out, so that for extension mapping e.g. “*.jsf” pattern the “.jsf” is removed, and for path mapping e.g. “/faces/*” pattern the /faces subdirectory is removed.
  3. The javax.faces.DEFAULT_SUFFIX as below is applied to the result as a file type if one is not present, to give an actual file to be searched for. This is passed to the faces servlet for processing.

I tried the same combination in web.xml that I had used previously on Glassfish V2.1 with ICEfaces:-

<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>*.jsf</url-pattern>
</servlet-mapping>
<context-param>
<param-name>javax.faces.DEFAULT_SUFFIX</param-name>
<param-value>.jsf</param-value>
</context-param>

The actual file type was also .jsf (index.jsf in this case)
This gave rise to the following intermittent error when run – it would run once or twice and then blow up:-

url:  http://localhost/PrimeTest1/index.jsf
error:  javax.servlet.ServletException: PWC1232: Exceeded maximum depth for nested request dispatches: 20

Changing the actual file type and the above javax.faces.DEFAULT_SUFFIX value to .xhtml worked correctly in every case.
This error occurred both with a simple Primefaces test page:-

<html xmlns=’http://www.w3c.org/1999/xhtml’
xmlns:f=’http://java.sun.com/jsf/core’
xmlns:h=’http://java.sun.com/jsf/html’
xmlns:p=’http://primefaces.prime.com.tr/ui’>
<h:head> </h:head>
<h:body>
<p:editor />
</h:body>
</html>

and also with a simple JSF page in a non Primefaces JSF 2 faceted eclipse web project:-

<html xmlns=”http://www.w3.org/1999/xhtml”>
<head>
<title>Test Page Title</title>
</head>
<body>
Test page body
</body>
</html>

It was therefore clear that the error was not Primefaces related, but appeared to be recursion caused by a servlet mapping issue. This post on the Glassfish Forums reported the issue – there was some discussion but no resolution, and I don’t think a bug has been raised.  This post also reported the same issue. Whilst I found a number of other posts too with what seemed like a related issue, there appeared to be no clear conclusion on any of them re the nature of the problem or a fix for it. I tried other combinations such as path mapping using “/faces/*” for the url pattern, “.jsf” for the default suffix, and “http://localhost/PrimeTest1/faces/index.jsf” for the url, but in this case the above error did not occur but a blank page was displayed. On examining the source for the page, it turned out to be the original page source i.e. it had not passed through the faces servlet.

My conclusion is that the servlet mapping/url pattern handling for Glassfish V3.0.1 has some issues, the precise nature of which is not clear. My solution is to use “.xhtml” for the actual filetypes and for the default suffix, and extension mapping using “*.jsf” for the url pattern – this combination works fine with no issues.

No Comments »

September 18th, 2010
11:08 am
Using display:inline-block and vertical-align in CSS

Posted under CSS
Tags , , , , , ,

Update 23/11/2010

Having experimented with this extensively on different browsers, I have found inconsistent results across browsers when trying to vertically centre a group of controls in a bordered div which closely surrounds them. If you need just a few pixels between the controls and the border, vertical centering does not work in a consistent browser independent manner. For larger centring, e.g. for centring a paragraph of text in a large div, the differences may not be noticeable, but at small scale they definitely are. For placing a close border around a group of related controls, my preferred method is now to use floats as detailed here. Note that the fact that floats are used does not force the rest of the document to use floats or to have non fixed sizing – the floats can be invisible to the outside due to a second outer non floated fixed size div. Also, the floated version works better when the contained controls are of variable or unknown size.

Original post

I originally used this here in order to centre the text on a Primefaces button, the usage of inline-block was incorrect.

What it does not do is allow you for example to centre a <span> element vertically and/or horizontally in a parent div!

What it does do is to allow setting of the alignment of an inline element relative to adjacent inline elements on a line (not relative to the parent container). It will therefore work within a <td> but not within a <div>

There appear to be a lot of fuzzy and partly incorrect articles on the net about this, and it was hard to find clear definitions. even the W3schools site does not greatly help, and does not appear to list for each element whether it is an inline or block element by default, which seems quite an omission.

In the end I found some helpful posts on it here and here which cleared it up for me, and explained why my simple example of a <span> in a <div> would not centre vertically with inline-block and vertical-align:middle!

Note regarding the use of vertical-align, a typical gotcha on this is if you have a horizontal group of buttons/combos and attempt to use top/bottom margins to try to centre them vertically, you may wonder why you do not get the expected behaviour as the margins do not appear to be properly honoured. This is a classic case for using display:inline-block and vertical-align:middle on all the controls.
Primefaces note:- the Primefaces commandButton components are set to  display:inline-block by Primefaces, using the internal jQuery ui-button class.

No Comments »

September 14th, 2010
3:17 pm
Adding Boot files to a Windows 7 System

Posted under Windows 7
Tags , , ,

Update 3/2/2012

One note to be aware of when doing this is that depending what other upgrades have been done, it may also be necessary to reset the boot order in the bios. Failure to do this may mean that the Windows boot manager on an old hard drive may still be presented at boot time even though bcdboot has run correctly as per the process below.

In my case, resetting the boot order solved the issue and boots were then done entirely from the SSD. I still had the option to boot from the other system by using the bios boot manager to pick the other hard drive to boot from.

 

Original Post

I needed to do this after installing Windows 7 64bit on an SSD, when I already had A Windows 7 installation on another HD.
I wanted the SSD to be the active partition/primary boot device – perhaps I should have made it the active partition in disk manager before installing but anyway I did not.

The install therefore kept the HD as the boot dev and installed a boot menu on it. The boot files were missing from the SSD. These can be added via the bcdboot  utility as follows :-

>bcdboot c:\windows /s c:

This had to be done from an elevated privilege command prompt (right click command prompt option or icon, run as administrator).

Microsoft information on bcdboot may be found here.

No Comments »

June 9th, 2010
5:06 pm
Centre text and other items e.g. on a Primefaces command button

Posted under HTML
Tags , , , , ,

Update

This post originally used display:inline-block and vertical-align:middle thinking mistakenly that these were part of the fix for the problem.
See here for a more complete understanding of it.
The modified CSS below works fine just by removing the padding and setting the font.

Taking the Primefaces commandButton as an example, the label is embedded in a span:-

<button attr1=value attr2=value…>
<span>Submit</span
</button>

The button has many attributes which are not relevant to this discussion.
However, as the span is an inline element, it does not have a top/bottom margin, width or height and using text-align:center; in css has no effect.

The default Primefaces button has fixed padding for the label, which works fine by default but which is a pain when you change the size of either the button or the text.

The following rules remove the padding and set the desired font correctly to centre the text for the Primefaces commnadButton:-

.ss-textbutton {
height:20px;
width:52px;
}
.ss-textbutton > .ui-button-text {
font-size:90%;
font-weight: bold;
padding:0px;
}

This CSS is activated when the class ss-textbutton is passed to the styleClass attribute of the commandButton tag.
This example declares a 52 x 20 button. It then targets the <span> within the button using ss-textbutton > ui-button-text, as the <span> in the commandButton has the ui-button-text class. It does the following to the <span>:-

  • sets a font size and weight
  • removes all the padding, so that the centring works correctly

In this example, I have deliberately not changed all buttons globally. The Primefaces documentation explains how to use the classes  ui-button, ui-button-text and ui-button-text-only to skin all buttons globally if this is desired.

This now allows us to resize our button, change the font size and the text, and still have the label nicely centred. We don’t have to mess around with tweaking the padding and other attributes in every case, which is a whole lot simpler and more modular.

No Comments »

May 26th, 2010
9:35 pm
Notes on Using CDI/Weld

Posted under Java
Tags , , , ,

CDI stands for Context and Dependency Injection, and is the standard for Java EE 6, being an important part of the Java EE 6 stack. The reference implementation of CDI is JBoss Weld. Full details including documentation downloads for Weld, may be found here.

Here are some initial pointers/gotchas when starting out with CDI:-

  • Any bean which is @SessionScoped or @ConversationScoped must be serializable. If you do not obey this rule you get an error when trying to deploy your application. The easiest way to do this in Eclipse is to implement Serializable. This will give a warning about the need to declare serialVersionUID.Just right click the warning and pick quick fix. You will have the choice of a default serialVersionUID or a generated one. Normally you would want to use a generated one, which Eclipse will do automatically for you when you pick the option. (You can also use a Java command line tool to do it but there is no point as Eclipse is easier). This post here gives more details about SerialVersionUID and serialization.
  • Any bean which uses parameterised types (i.e. generics) in its interface must be declared as @Dependent, i.e. it is only used and referenced from one client bean and its lifetime is dependent on the lifetime of that client bean – it is created when the client bean is created, and destroyed when it is destroyed. If you do not obey this rule you get an error when trying to deploy your application. An example of this situation might be a generic table bean which returns a list of rows of a generic type <E>, e.g. @Dependent public class TableBean<E> implements Serializable. This makes sense if you think about it – if it returns a generic type, it cannot be instantiated in isolation as it is the creating client which determines the actual type returned. Remember in this regard that CDI performs type safe injection in order to pick up as many errors as possible at compile time. Therefore, taking an example of our table bean, a consequence of this is that the table bean cannot be referred to directly from a JSF page. This is not the issue that it might appear. In practice, the table bean will be created by a client backing bean for the page. For example, a UserCredentials.jsf page might contain several tables, each backed by a different TableBean. The page will have its own backing bean, for example UserCredentialsBean, which will hold the backing state for the whole page. When referring to a table on the JSF page, it will always be referred to via the page backing bean, for example userCredentials.rightTable.rows. This is what you would naturally do anyway, and referring to the dependent bean via a property of its ‘owning’ parent if perfectly correct and does not violate any CDI rules. Note that it is also perfectly correct to assign such a reference to a JSF table value attribute for use in the table, and to then use the shorthand name assigned to the var attribute to refer to the bean. This is also fine and does not break any rules.
  • When referencing an EJB from a JSF backing bean, you should always use CDI annotations rather than the older @EJB ones, as the CDI ones are typesafe and allow all the additional flexibility of CDI, such as alternatives for swapping in mock test versions of EJBs by adding settings in beans.xml. An example of injecting a local EJB into a backing bean might be  private @Inject SentryServiceLocal sentryService; assuming that SentryServiceLocal is the local interface for the EJB.
  • Given the choice, you should always use CDI for preference rather than a legacy feature. For example, JSF managed beans are still available for backwards compatibility in JSF (and even have some new features for JSF 2.0). However, you should ignore these and use CDI instead as it offers superior flexibility and type safety. Using CDI across the board gives additional benefits such as when grouping annotations using Stereotypes.

No Comments »

May 14th, 2010
6:45 pm
Javadoc creation and formatting

Posted under Java
Tags , , , ,

Some tips and gotchas on this, as follows :-

1/ the Oracle documentation pages for Javadoc complete with examples etc. may be found here

2/ An example of Javadoc applied to a project may be found in the PropertyTree project in the repository.

3/ JAutodoc is a useful Eclipse plugin. Whilst Eclipse can generate Javadoc comments at source creation time if you tick the box for it, and lets you add them afterwards one by one via ctrl/alt/J etc., using  JAutodoc allows creation, addition or replacement of a full set of Javadoc comments to an entire project at any time. It also has a better stab at guessing comments for properties etc. than Eclipse, by parsing words out of the code. Obviously there is still a lot of manual editing to be done, but I found it a useful addition. Note that JAutodoc is available for a project on the package Explorer context menu for a project, but not on the project explorer one.

4/ Package level documentation sits in package.html in the package source directory. As Javadoc is frames based, the following doctype is recommended by Oracle for this file :- <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">. Simple html is the order of the day as Javadoc has simple, somewhat retro styling. You can get new style sheets for it to spice it up, but I find the standard ones perfectly readable. Javadoc has its own Stylesheet.css, but I avoided amending this, and deliberately did not add another stylesheet of my own. Therefore, I avoided heavy use of styling, and just borrowed the odd style from the built in stylesheet for my own uses such as table header styling below.

5/ For subheadings in the package doc <h3> and <h4> worked fine.

6/ It was straightforward to add simple tables. Whilst some of the attributes are rather outdated/deprecated in favour of CSS, they are also used elsewhere in the Javadoc for its own tables, so I did not lose sleep over it. I used the TableHeadingColor class from Javadoc’s own stylesheet to give a similar background colour to my own table headers.

<table border="1" cellspacing="1" width="100%">
    <tr class="TableHeadingColor">
        <th>Column 1 Header</th>
        <th>Column 2 Header</th>
    </tr>
    <tr>
        <td>Column 1 data</td>
        <td>Column 1 data</td>
    </tr>
</table>

7/ Styling code samples is a bit messy with several tags being involved. This post here on StackOverflow discusses some of the issues In the end I used the following examples, generally going with what worked well:-

<blockquote><pre>
      PropertyTree propertyTree = new PropertyTree("lan").load("Test.properties");
</pre></blockquote>

or :-

<blockquote><pre>{@code
lan.default.broadcast=10.0.0.255
lan.default.port=7

}</pre></blockquote>

The code tag (“{@code …}” was supposed to be the one to use here (particularly when Generics are involved) but was a bit mixed in its usefulness, and I found some variations in the tabbing, and closing braces in the code can be an issue as the code tag also uses this for its own closure. I did not therefore always use it. Interestingly the above StackOverflow post cites that String.java in the JRE just uses <p><blockquote><pre>,  so I often followed suit.

8/ Individual code or data identifiers such as class and method names looked good in a fixed font when framed with <code></code>, which seemed to be the preferred way to highlight them. Sometimes I made them links as follows, but I did not do this all the time when there was already a link on the comment, as it was tedious and unnecessary. Links can be added, and you can link to a method, a class or a package (which links to package.html) by just linking to the desired level. The first parameter after {@link is the hyperlink, and the second parameter is the clickable description that appears for the hyperlink. Eclipse does code completion for the tags when you are entering them. The following example links to a property (which is specified after the “#”):-

{@link  uk.co.salientsoft.util.propertytree.TagTree#getProperty() TagTree.getProperty()}

9/ One gotcha is that for overriden methods, the Javadoc always comes from the inherited method, and the Javadoc method comments in the subclass are ignored. However, you can add additional comments by using the Javadoc documentation comment syntax (prefixed “/**” i.e. with the extra asterisk on the first line) in the subclass, and these will be added in and not ignored:-

/**
  * For the <code>NullIterator</code> this will always return <code>false</code>.
  */

10/ In Eclipse, you can create Javadoc via the Project/Create Javadoc menu bar option (this is not available on the package explorer context menu). There are a number of options when doing so, but these are not all defaulted to your previous settings when you go back next time round. You can therefore create and save an Ant build file for the Javadoc which you can then re-run much more easily. Javadoc.exe needs to be on the path for this – it should be anyway if you have Java SE installed and on the path, and for me I did not have to add it. You can then open the Ant view in Eclipse. In the view pane, right click and select Add Buildfiles… and browse for the Ant build file which you saved at Javadoc creation time. This then stays pinned to the Ant pane and you can double click it any time to recreate your Javadoc with all the saved settings.

No Comments »