Salient Soft

This post continues from my previous post on using the Tomcat Server Adapter, and details how to enable and configure logging. Configuring this is not obvious, and there are a number of issues :-

1. Eclipse does not fully enable logging for the Tomcat Adapter by default, so you will likely find application log calls not going anywhere, and any logging.properties file you set up won’t have any effect.
2. The Tomcat Adapter ignores any logging.properties file placed in WEB-INF\lib completely. You can only use one in the <Cataline  Base>\conf directory. More is said on the actual location of this directory later.
3. The configuration instructions are somewhat buried in the Eclipse WTP FAQ.

To enable logging for the Server Adapter, see here in the Eclipse WTP FAQ, details copied as follows. Note that the same procedure works on Eclipse Galileo 3.5.1 and Tomcat 6.0.24 :-

How do I enable the JULI logging in a Tomcat 5.5 Server instance?

Tomcat 5.5 comes with an enhanced implementation of java.util.logging, called JULI, which is configured by default in a standard Tomcat 5.5 installation. This JULI logging configuration is not picked up automatically when creating a new Tomcat 5.5 server in WTP. Some manual steps are necessary to add this configuration to your WTP Tomcat 5.5 server.

1. Open the server editor for the Tomcat server and note the folder specified by the Configuration path field.
2. Import the logging.properties file from the conf directory of your Tomcat 5.5 installation into this folder in your workspace.
3. In the server editor, click on the Open launch configuration link and in the launch configuration Properties dialog, switch to the Arguments tab.
4. In the VM Arguments field, add the following two system properties substituting the catalina.base path where noted:
   -Djava.util.logging.config.file=”<put catalina.base path here>/conf/logging.properties”
   -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager

The imported logging.properties file can be used to control the JULI logging configuration for the Tomcat server.

Note that in my case I had set up the adapter to use the Workspace Metatdata so that the installed Tomcat server could also be used independently. Therefore, the cataline base path used was the configuration directory used by eclipse, listed as the configuration path on the Server Overview screen (double click the server to see this screen). My settings for the VM arguments were therefore as follows :-

-Djava.util.logging.config.file=
   "E:\Java\Dev\Workspaces\Sentry1\Servers\
     Tomcat v6.0 Server at localhost-config\logging.properties"
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager

This allowed me to expand the Server node for the server in the package explorer, and open the logging.properties file directly from there.

The following example logging.properties file illustrates the configuration of the logging. Tomcat uses JULI, an extended version of java.util.logging which allows extra features. It has the abilility to support per-application logging  – note that as above this is not supported in the Eclipse Server Adapter version, although for development time debugging this is not an issue, as you can have separate Tomcat configuration per Eclipse workspace if you store the Tomcat configuration in the Workspace metadata as above. JULI also allows multiple handlers to be loaded from the same class instance. See here for the official Tomcat documentation for configuring Tomcat logging.

The following example logging.properties file illustrates some configuration points :-

A custom console handler has been added to the handlers property at the top of the file, to allow uk.co.salientsoft to have finer grained logging than the default console logger. The default handler has a level of FINE, which would prevent other lower level loggers from using FINER or FINEST. Adding the additional handler allows all the existing logging to remain as is, but gives full flexibility to uk.co.salientsoft logging :-

handlers = 1catalina.org.apache.juli.FileHandler, \
           2localhost.org.apache.juli.FileHandler, \
           3manager.org.apache.juli.FileHandler, \
           4host-manager.org.apache.juli.FileHandler, \
           java.util.logging.ConsoleHandler, \
           5salientsoft.java.util.logging.ConsoleHandler

The new console handler is used to configure logging at FINEST level at the bottom of the file :-

5salientsoft.java.util.logging.ConsoleHandler.level = FINEST
5salientsoft.java.util.logging.ConsoleHandler.formatter = \
   java.util.logging.SimpleFormatter
uk.co.salientsoft.handlers = \
   1catalina.org.apache.juli.FileHandler, \
   5salientsoft.java.util.logging.ConsoleHandler
uk.co.salientsoft.level = FINEST

The following is a complete listing of the sample logging.properties file :-

# Licensed to the Apache Software Foundation (ASF) under one or more
# contributor license agreements.  See the NOTICE file distributed with
# this work for additional information regarding copyright ownership.
# The ASF licenses this file to You under the Apache License, Version 2.0
# (the "License"); you may not use this file except in compliance with
# the License.  You may obtain a copy of the License at
#
#     http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

handlers = 1catalina.org.apache.juli.FileHandler, \
           2localhost.org.apache.juli.FileHandler, \
           3manager.org.apache.juli.FileHandler, \
           4host-manager.org.apache.juli.FileHandler, \
           java.util.logging.ConsoleHandler, \
           5salientsoft.java.util.logging.ConsoleHandler

.handlers = 1catalina.org.apache.juli.FileHandler, \
            java.util.logging.ConsoleHandler

############################################################
# Handler specific properties.
# Describes specific configuration info for Handlers.
############################################################

1catalina.org.apache.juli.FileHandler.level = FINE
1catalina.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
1catalina.org.apache.juli.FileHandler.prefix = catalina.

2localhost.org.apache.juli.FileHandler.level = FINE
2localhost.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
2localhost.org.apache.juli.FileHandler.prefix = localhost.

3manager.org.apache.juli.FileHandler.level = FINE
3manager.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
3manager.org.apache.juli.FileHandler.prefix = manager.

4host-manager.org.apache.juli.FileHandler.level = FINE
4host-manager.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
4host-manager.org.apache.juli.FileHandler.prefix = host-manager.

java.util.logging.ConsoleHandler.level = FINE
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter

############################################################
# Facility specific properties.
# Provides extra control for each logger.
############################################################

org.apache.catalina.core.ContainerBase.[Catalina].[localhost].level = INFO
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].handlers = \
   2localhost.org.apache.juli.FileHandler

org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager].level = INFO
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager].handlers = \
   3manager.org.apache.juli.FileHandler

org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/host-manager].level = \
   INFO
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/host-manager].handlers = \
   4host-manager.org.apache.juli.FileHandler

5salientsoft.java.util.logging.ConsoleHandler.level = FINEST
5salientsoft.java.util.logging.ConsoleHandler.formatter = \
   java.util.logging.SimpleFormatter
uk.co.salientsoft.handlers = 1catalina.org.apache.juli.FileHandler, \
                             5salientsoft.java.util.logging.ConsoleHandler
uk.co.salientsoft.level = FINEST

No Comments »

I have run in to an issue with Eclipse (Galileo 3.5.1) when opening a jsf page with the web page editor – I get the error:-

“Could not open the editor: null argument:”

I tried the -clean flag on startup as per this post but this did not fix the problem. I also tried deleting this metadata file but this had no effect in this case

This appeared to be due to Eclipse disliking the syntax of some sections of the code I had commented out. In one case, adding the following comment:-

<!–  value=”#{appRoles.selected}” –>

caused the error to occur, and removing it caused the error to disappear. The cause was not always consistent – in another copy of this same page I had to delete a commented out table column to fix the problem:-

In general, I think that certain usage of commented out sections can trip Eclipse up and cause the editor to fail. removing these causes the problem to disappear.

Note that the error does not occur with the JSP editor, so this can be used instead or to edit the sections causing the problem.

No Comments »

This post details the installation I use for CVS based source control, together with some usage points and gotchas I came across. My preferred installation consists of the Eclipse CVS plugin and TortoiseCVS on the client side. This gives the flexibility of CVS access both inside and outside Eclipse. In my experience both CVS clients coexist well, and changes in one are immediately  reflected correctly in the other as would be expected. My server side consists of CVSNT running on a separate repository server.

I have broken this tutorial down into linked sub-posts as it was becoming too monolithic and covered multiple topics. The steps are as follows :-

1/ Server Installation using CVSNT

3/ Client Installation, Configuration and usage notes- TortoiseCVS

4/ Client Installation, Configuration and Usage notes – Eclipse CVS Plugin

5/ Branching and Merging in Eclipse CVS and TortoiseCVS

No Comments »

I had this issue when deleting and refetching a project from CVS into Eclipse.

It reported that it was unable to resolve a number of the persistence classes such as EntityManager and EntityManagerFactory, even though the libraries and the imports were all present correctly.

This was solved by removing the Java persistence facet from the project facets page, applying the change, and adding persistence back and reconfiguring it. The problem then disappeared.

This was one of several Eclipse ‘gotchas’ I have found where Eclipse reports errors which do not exist. Often, a reconfigure such as the above, or a restart/reload will sort it.

No Comments »

Sometimes eclipse lists the following error in the problem view :-

Class xxx is listed in the persistence.xml file but is not mapped

This appears to be a synchronisation problem within Eclipse, as deleting the classes from persistence.xml and then adding them back by browsing with Eclipse’s own persistence.xml editor eliminates the problem, even though the resulting file is identical. Validating the original file did not solve the problem.

Even with the error listed, projects still run and build successfully, so the problem is not serious.

I have also had other cases where Eclipse has whinged about a perfectly good persistence.xml, and have in general just lived with it as it is not serious.

This is an important issue to be aware of though to prevent much head scratching when such a problem is believed to be a real error and is not!

No Comments »

This appears to be an issue if you start Glassfish (2.1.1) outside of Eclipse (3.5.1) – Eclipse does not then always sync with it properly. It may try to start it when it is already started and fail, then fail to publish/run projects correctly.
There is an old bug logged on this here. It claims to have been resolved, but the resolution does not appear to be seamless – it appears that Eclipse cannot fully integrate with an externally started Glassfish.

I expect this to be sorted with Glassfish V3 as this is fully OSGI compliant.
In the meantime, the answer seems to be to allow Eclipse to fully control Glassfish, i.e. start and stop it itself, and to not start Glassfish externally when using Eclipse.

No Comments »

Branching allows version histories of a CVS module to proceed in parallel, by branching from an earlier version in the repository. This typically arises when a new release is under development in the repository (or has been released) and bug fix changes are needed to an older version without affecting the new release. A branch would be made at the older version and the bug fixes placed on the branch. A client (Eclipse or TortoiseCVS) can pick the branch to work with, and the local files are updated to reflect that branch.

1. To create a branch in Eclipse, select Team/Branch… from the context menu for the project
2. To create a branch in TortoiseCVS, select CVS/Branch… from the context menu.
3. To select a branch in TortoiseCVS, you do an Update Special and pick the branch to switch to.
4. To select a branch in Eclipse, you do Team/Switch to another branch or version

When Branching, you should normally branch a complete module not just a file. If you just branch a file in eclipse, Eclipse gives you a warning that you are mixing tags within a project. Tortoise does not give you a similar warning however. See here for the internals of branching in CVS. It seems that whilst internally it is done per file due to historical coding reasons, it should ideally be ‘grouped’ as CVS does group files.

If you branch by mistake, you cannot delete it – just leave it unused in the repository.

You can merge changes back into a branch from another branch with both these clients. In both cases, you should have the target branch (which will often be the head) as the current loaded one. You then pick the branch to be merged into it.

1. To merge a branch into the current branch in Eclipse, use Team/Merge
2. To merge a branch into the current branch in TortoiseCVS, use CVS/Merge

No Comments »

Eclipse comes with a CVS plugin pre-installed. To connect to a repository, open the CVS Repositories view and add one via new from the context menu. The Eclipse CVS client is a pure Java one with a more limited set of protocols than the full set allowed by CVSNT – I use the pserver protocol, which encrypts passwords but not any other traffic. This is fine for a trusted internal development network behind a firewall. Eclipse does allow password caching and asks for secret questions for password recovery.

Note that if you get timeouts trying to connect to your repository and you are using CVSNT, make sure that you have excluded cvsservice.exe and cvslock.exe fully from both your Antivirus software on the server and the Windows Firewall on the server. In my case I used the default TCP ports in all cases on both clients and the server without problems once this had been done.

By default, my icons in the package/project explorers did not show when a file was dirty, i.e. when I had made local changes to a checked out file (Eclipse terms this an outgoing change). I could see the changes in the Team Synchronization view, which is useful as it isolates your changes from all the unchanged files, and allows filtering on the type of changes (outgoing, incoming, both, change conflicts). However, it is highly desirable to have the simple feature of tagging the icons on the dirty files, and this did not work even though I strongly suspected that such a feature would be available. It turned out that this labelling of the icons is enabled in the preferences.  Select Window/Preferences, then select Team/CVS/Label Decorations in the left pane, then the Icon Decorations tab, and select all the options. In my case, Outgoing changes was not selected, so local changes to a file in Eclipse did not make it show up as ‘dirty’ on the explorer icon. Selecting the option fixed the problem.

Usage Points

1. Most of the CVS options are under the Team submenu in the package explorer context menu.
2. However, one exception which can catch the unwary – to revert to checked out version – use Replace With and Latest from HEAD or Another Branch or Version on the explorer context menu
   i.e. this command is not under the TEAM submenu.
3. The CVS Repositories view is useful for browsing the server side repository including all the branches and files.
4. The Team Synchronization view is useful for viewing your changes – incoming, outgoing, and change conflicts

No Comments »

This error was caused by importing Eclipse projects from another configuration. The projects had a different JRE library configured, which eclipse listed as “Unbound” as it was not present.

Simply adding the default JRE system library and removing the unbound definition solved the problem. To do this, right click the project, and select Build Path/Configure Build Path. Select the libraries tab on the right hand pane and add/remove from there.

Strangely, this problem did not stop projects running completely – eclipse still allowed a number of small test projects to run even with the “unbound” jre configured. The problem only appeared to manifest itself when trying to create the database schema from the entities via right clicking on the project and selecting JPA Tools/Generate Tables from Entities, wherupon the error occurred.

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 »