Salient Soft

Update

Another post here describes how to enable and control logging when using the Tomcat Server Adapter, as it is not enabled by default. As a result, I changed my thinking and have switched to using the Workspace Metadata to store the server configuration (as detailed below). This allows more convenient editing of the logging.properties file in Eclipse, and also allows a separate Tomcat configuration for each Eclipse Workspace. I have not experienced any corruption/pollution issues from working this way.

Original Post

I use this a lot for prototyping as it is significantly faster for deployment and has less overhead than Glassfish. I run JSF/ICEfaces/JPA applications by running JPA outside the container – see here for more details.

When running Tomcat inside Eclipse, it runs within its own context, i.e. separately from the installed Tomcat Server. Therefore, you should stop Tomcat externally when using it internally via Eclipse’s Tomcat Server Adapter.

You can use the adapter by right clicking in the Server view and clicking on New, then choosing the appropriate version of the Apache Tomcat adapter, browsing for the installation directory for Tomcat in the process.

When using this, you have 3 choices as to where the applications deployed to Tomcat are stored, all of which may be chosen by opening the Server Window for your Tomcat Server in Eclipse. As I point out here, there is often some ambiguity between which properties you change from the properties context menu option (resulting in a popup), and which are from the Server view via the Open option (also obtained by double clicking the server entry in the server view). In this case, the 3 choices are listed under the Server view (Open/double click option), but they are typically shown disabled and it is not always consistent as to how to enable the selections. Firstly stop all running applications on the server, and stop the server. Secondly, clear out any applications from the server by using the Clean context menu option, and/or visiting the Modules tab in the Server view and removing all applications there. You can also click the Switch Location button on the properties context menu popup. You will also need to refresh/reopen the Server view window to ensure that changes are picked up. Once you have reached the point where the the server locations are modifiable, you have the following choices :-

1. Workspace Metadata (does not modify Tomcat Installation)
2. Use Tomcat Installation (takes control of Tomcat Installation)
3. Use Custom Location (does not modify Tomcat Installation) :-
   Server Path: Top level location for all the deployed apps and other Tomcat metadata
   Deploy Path: Subfolder under the Server Path, where the apps sit – defaults to wtpwebapps

My preference is 3. – I like to avoid polluting the main Tomcat installation with Eclipse development stuff, as I can then use it for other purposes. Also, I like to avoid storing the Tomcat applications in the Eclipse workspace metadata. The metadata is cluttered enough as it is, and is sometimes prone to pollution and problems with Eclipse not starting (see here). I therefore like to keep this data in a custom location separate from both the Metadata and the Tomcat installation, but as part of a folder structure which includes the workspaces. I also include any libraries which are shared between workspaces (e.g. JSF/ICEfaces plugins) in the same structure. See here for details about sharing downloaded plugin libraries across multiple workspaces by exporting/importing Eclipse preferences.

My typical folder structure might be as follows :-

Dev (top level (sub)folder somewhere)
Tomcat (custom Tomcat apps location as above)
webapps (my preferred setting for the Deploy Path: above)
Libraries (Top level for libraries shared between workspaces, such as JSF/ICEfaces plugin libraries)
Workspaces (All Eclipse workspaces live under here)
Workspace 1
Project 1
Project 2
Project 3
Workspace 2
Project 4
Project 5

No Comments »

I had an Eclipse Galileo workspace containing several projects, and for some reason some of the projects did not show a full palette of components when opening a jspx file using the Web Page Editor. The main culprit was the ICEfaces components set which was missing. The workspace as a whole was clearly OK, but some projects had become broken. I now believe that some changes I made to user library locations may have caused the problem, but not sure on this.

Firstly, I visited the JSF project facets screen by right clicking the project in the explorer and selecting Properties to open the project properties page, then opening the  Project Facets entry in the left hand pane. I removed (unticked) support for ICEfaces and saved the changes. Then I added it back and saved again. This did not fix the problem.

I looked at the JSF Tag Registry view which lists all the Tag libraries registered for a project. This can be displayed by clicking menu option Window/Show View/Other and then entering Tag in the search box at the top. Select Tag Registry under JSF and the view will open. You must select the desired project in the view as it does not default to the current project. You can then expand the entries to see the Tag libraries registered. If you select one of the top level nodes on the registry tree (in my case these were labelled Facelet Tag Registry and JSP Tag registry) you can click the refresh button adjacent to the project selection button. This refreshes the entries, and you can elect whether or not to flush the cache in the resulting dialog. Unfortunately it was of no help to me in fixing the above problem, and refreshing/clearing the cache did not clear the issue. However, this view could be useful to browse Tag Library registrations.

I was aware that the palette entries are driven by the available Tag libraries on the project Build path, so still felt that it was library related. I then revisited the project properties page, and this time expanded the Project Facets entry in the left pane rather than clicking on it. I then selected Java Server Faces. This listed the user libraries for the project in the right hand pane, including all of the ICEfaces and JSF ones. I deselected all but one of them (you cannot deselect all of them), leaving the JSF 1.2 (Sun RI) library selected. I then applied/saved the changes and closed the screen. I then re-opened it, selected all the originally selected libraries and applied/saved again. This time, when I opened a jspx file in the project with the Web Page Editor, the ICEfaces components were present on the palette.

One last glitch was that after doing this, the palette entries for ICEfaces only had icons present, no descriptions. I then  closed the web page editor window, and closed Eclipse down normally, and re-opened the same workspace in Eclipse again. I then re-opened the same jspx in the Web Page Editor, and this time the ICEfaces components were all present with both the Icons and the descriptions. Problem solved!

No Comments »

The ice:form tag renders a stateSavingMarker div which declares a couple of hidden fields for use by ICEfaces.

In IE7, (or IE8 in IE& compatibility mode), this div has its margin to auto which can cause an extra 10px or so margin to be added in between any elements outside the form and those inside.

This can be eliminated by adding a style to the form, either by adding a StyleClass attribute to refer to a CSS class, or by using the Style attribute to code an inline style. As this is a ‘one off’ just to clear a margin, the following example uses an inline style :-

<ice:form style=”margin:0″>

No Comments »

A classic example of this is the need to add a selected flag to each row if you are using row selection with an ICEfaces table.

The fundamental point here is that you do not want to pollute the domain objects with state that is specific to the view – in this case, the flag is merely a convenience for supporting the user interface.

This post details a good solution to this problem, which is to use the decorator pattern to decorate the row domain objects with a decorator containing the row selected flag. Often, a decorator has an identical interface to its decorated object, but that is not always the case, and in this case we actually need to add a property. This does however mean that you have to be aware of which class you are using at a given point in the code, and you cannot use a generic decorator interface to declare the concrete decorators if they have new properties added. Also, if you have a number of such decorators, you cannot wrap the domain objects with them transparently in turn for the same reason. You can get around some of this with some clever use of reflection, but it does complicate matters and impact performance.

The ICEfaces page on row selection may be found here.

No Comments »

By default when you create a new ICEfaces Facelets project with a sample page, it codes the DOCTYPE directive directly. Unfortunately, this is stripped out during processing/rendering and does not  appear in the final HTML for the page. When running IE without a suitable DOCTYPE directive, it switches into Quirks Mode and is not fully standards compliant, which may cause pages to display incorrectly.

the DOCTYPE can be added back by using the <ice:outputDeclaration> tag. To do this, you also need to add an <f:view> tag as you would in JSP mode, as in the following example :-

<?xml version="1.0" encoding="UTF-8"?>
<f:view xmlns="http://www.w3.org/1999/xhtml"
 xmlns:ui="http://java.sun.com/jsf/facelets"
 xmlns:f="http://java.sun.com/jsf/core"
 xmlns:h="http://java.sun.com/jsf/html"
 xmlns:ice="http://www.icesoft.com/icefaces/component">
 <ice:outputDeclaration
  doctypeRoot="HTML" doctypePublic="-//W3C//DTD XHTML 1.0 Transitional//EN"
  doctypeSystem="http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" />
 <html>
    <head>
    ...
    </head>
    <body>
    ...
    </body>
 </html>
</f:view>

The issue is discussed and solved in this ICEfaces forum post. Interestingly, a page created by ICEfaces for a  JSP (non-facelet) project also uses the <ice:outputDeclaration> tag, presumably for the same reason.

Note that you cannot omit the <f:view> tag and add the xmlns namespace declarations to the <ice:outputDeclaration> tag as this fails – the <f:view> tag needs to be present.

Another post about Quirks mode and DOCTYPE switching, which also contains a useful Bookmarklet (Javascript link) which will tell you directly what mode a page is running in, may be found here.

No Comments »

This tutorial describes how to use the Component showcase css and icons as the template for your own project.

I’ve not looked into it in detail, but it certainly makes sense to use the same look and feel and borrow from ICEfaces where necessary.

One of the comments is less than complementary about some of the CSS code in the example.

No Comments »

At the time of writing, the latest plugin version is 3.6.2. The zip of this version does not contain the installation instructions which were present in version 3.6.1, explaining how to download to a local repository and install from that within Eclipse.

The instructions may be found in ReadMe.pdf here.

No Comments »

1. Decide on component versions to be used by building a cross compatibility matrix. Generally you will want to install the latest production builds of all components consistent with full cross compatibility. Also to be considered are the various tool bundles available, which can simplify installation and configuration by allowing multiple tools to be installed from a single kit. However, many of the bundles overlap, so this needs to be taken into account (in addition to the compatibility matrix)  so that you do not end up installing multiple versions of the same tool – for example, Java EE can come with the JDK or with Eclipse. In my case, I am using an Eclipse bundle which includes Java EE.
2. Download and install the chosen Java SE JDK.
3. Download and install Glassfish (Eclipse has a plugin for, and therefore a dependency on, Glassfish so we do the latter first).
4. Download and install Eclipse. My bundle included Java EE 5 and Eclipselink and all the web tools.
5. Install the Glassfish Plugin for Eclipse.
6. Download ICEfaces (e.g. v1.8.x). This just needs unzipping to any desired target folder (e.g. E:\ICEfaces-1.8.x). The distribution contains full documentation for getting started, running tutorials, and development.
7. Download and Install the Eclipse ICEfaces plugin.
8. Download Tomcat if required. You may just want to use Glassfish as your servlet container, but in my case some development projects will use JSF/ICEfaces/Tomcat without Java EE. I have in the past used the windows service installer version, which is a self installing .exe and installs/runs Tomcat as a service. However note that this does not work under Windows 64-bit if you are using a 32 bit JVM. See here for a manual install process from the zip kit to give you all the functionality of the windows installer version, including run as a service, configuration utility, and system tray monitor/utility.

No Comments »

If you want to configure the libraries for use with a particular Eclipse plugin, this can seem rather a mystery at first. The traditional way in Eclipse to configure libraries for a project is to open the project properties for a project, select Java Build Path in the list on the left, and visit the libraries tab in the pane on the right. You can then use the “Add Jars” or “Add External Jars” to add jars to the project. To improve project portability across different development platforms, you can also add Classpath Variables which can be defined appropriately for each platform to isolate a project from platform specific jar locations etc. An example of this screen, with the JSF and ICEfaces entries expanded, is here :-

However, whilst you will see entries for plugins such as Eclipslink and ICEfaces on this screen, it does not provide any means of configuring them. Libraries for such plugins use an Eclipse feature called a Classpath Container. This allows the library configuration to be completely dynamic, as it is handled in code via a class. This allows the configuration to change at any time in response to project changes, as every reference to the classpath container is handled via the code rather than being static. To configure plugin libraries, therefore, you need to visit the dialogs for the Project Facets, which is where plugins are configured for the project. This post here, which details how to create a JPA-enabled EJB, shows this in action for JPA.

Another example would be to configure the  libraries for JSF and ICEfaces. You can do this as follows :-

Open the Project Properties dialog for the project, and select the Java Server Faces option under Project Facets in the left hand pane. This lists all the JSF and ICEfaces libraries available which may be selected/deselected.

The buttons on the right of the libraries frame allow management and downloading of the libraries. Clicking the Manage Libraries button allows configuration of the libraries available for selection in the project facets dialog above.

This is for example where you would upgrade ICEfaces libraries to a new version. You can leave both versions, or remove the old ones once you don’t need them any more. You can then select the new versions for that particular project in the parent Project Facets dialog.

Note that one particular issue arises when creating a new Eclipse workspace, as it is useful to migrate all the library definitions to the new workspace to avoid having to set them up manually or download them again. This post describes how you can do this by exporting and importing workspaces preferences. The post also discusses the issue of library location when sharing libraries – this is important as by default you would end up with one workspace sharing libraries within the folder structure of another workspace. My typical development folder structure is detailed at the end of this post.

If you subsequently return to view the libraries on the Libraries tab of the Java Build Path screen, you will then see the results of your efforts – the libraries for the plugins will have changed in accordance with your actions.

The dialogs used for plugin configuration do vary and are certainly not always intuitive or consistent – in these examples JPA was configured via the Java Persistence dialog in the project properties or via a link on the JPA facet screen which is not always present. In contrast, the JSF libraries (including the ICEfaces libraries) are configured via the Java Server Faces option under Project Facets. Even though there is an ICEfaces option under project facets, in my 3.5 Galileo Eclipse this displays “unknown library configuration”. However, the configuration is all there if you are willing to hunt around a bit for it!

No Comments »

I created a simple test web app using ICEfaces, including the test/sample page that the plugin creates for you by default. When running the app on Glassfish, the error “Object doesn’t support this property or method” occurs and the page fails to load correctly. The same application works in Tomcat.

The issue turns out to be due to a single extra space in web.xml. The Eclipse code has an extra trailing space in the url pattern for the Persistent Faces Servlet mapping as follows :-

Broken Version with trailing space after the * – works on Tomcat 6, fails on GlassFish 2.1

<url-pattern>/xmlhttp/* </url-pattern>

Working Version without trailing space – works on both

<url-pattern>/xmlhttp/*</url-pattern>

The effect of the extra trailing space appears to be that GlassFish 2.1 does not obey the servlet mapping for this url pattern. Tomcat is not tripped up by the trailing space. An extra hazard for the unwary in Eclipse (Galileo) is that if you use the XML editor to edit web.xml, it hides the trailing space if it is present, so you could miss it even if you were aware of the potential issue. The text editor shows the space correctly.

My original post on this in the ICEfaces forums is here. This problem has been fixed in 1.8.2 – the bug tracker entry for the problem is here. Note that upgrading to 1.8.2 will not apply the fix to existing projects in Eclipse, only to new ones. For existing projects, you need to remove the extra space in web.xml manually.

No Comments »