Salient Soft

This post brings together a number of past issues which I have not posted previously, discovered while setting up and using iMedia embedded Linux on my diskless LinITX Jupiter test box.

A zip of all the customised scripts and various config files (such as the infamous xorg.conf) are in the repository.

Shell Script Usage

1/ The startup scripts for applications and drivers etc. are in /etc/rcS.d/. You just add scripts to that and they are automatically run. They are all run by /etc/rcS in alpha order. They are grouped by a prefix of M05, M10, M20, M30 etc. – this seems just to be an arbitrary grouping that determines the order for dependencies etc. Note that all of rcS.d/ is run at run level 3 as set in /etc/inittab

The general order of startup is therefore (see /etc/inittab):-

• /etc/rc.init runs, and calls rc.sysinit directly
• /etc/rc.sysinit iterates init.d and runs everything in it. The order is partly determined by an initial grouping number – note the first to run is 00createvar which creates the /var tree on startup (see later)
• /etc/rcS runs as above, iterating /etc/rcS.d/

2/ /usr/local/bin/ has the extra shared shell scripts – rlog, rlog-leafpad, sx (start X), sxr (start X as root), plus start/stop scripts for Tomcat and Glassfish.

In Thunar, you can add file associations for scripts by right clicking in the file and selecting open with other application – for each app you can add a custom launch command below. (I added rlog and rlog-leafpad). If you add an incorrect one (I added beaver by mistake) Thunar may not let you remove it from the list. Just edit ~/.local/share/applications/defaults.list and remove it from there. Note that /usr/local/bin/ is already on the path so all the script in it are visible – good place to put other global scripts.

Note that you can add scripts to e.g. a program launcher on the top panel bar – right click and create a program launcher, then add items to it – useful for scripts which run without parameters (unlike the rlog and rlog-leafpad above which act on files and therefore are Thunar’s context menu for the files they operate on). When adding a script as an item to a program launcher, the ‘startup notification’ just gives a wait cursor while the script is running (useful). Running in an explicit terminal window is WEIRD – for example for glassfish I set the middle icon on the RHS pane to “terminal”, and set the command to be “aterm -e start-glassfish”. I did not tick “Run in Terminal” as this did not work however!

Logging under iMedia Linux

1/ Logs are stored under the /var tree which is recreated at startup each time see above, so log files are purged as we are running on a small flash based distro. Therefore, Tomcat and Glassfish for example are set to use sym links to link their log directories from their normal install directories to be under /var/log/. There is some trickery to this – for Glassfish I make sure that the *normal* log folder is not present (renaming it with a date/time stamp if required) else the sym link is set up wrongly.

2/ Some logs (but by no means all) in /var/logs/ are circular buffers handled by emlog  – see here for details. They show in Thunar as ‘character type devices’ and  need copying to be visible – /usr/local/bin/rlog does this using nbcat as per the emlog site. I also added /usr/local/bin/rlog-leafpad which does the copy and fires up leafpad on the result. Note that as the emlog site states, you cannot list such a log when active using cat as a non blocking read is required – hence the need for nbcat as used by rlog and rlog-leafpad.

Installing new Applications

1/ Installing new apps is a pain, as rpm installs don’t appear to be supported etc. I tried installing various zipped tarballs of VNC/RDP alternatives for remote desktop but they all needed dependant libraries I did not have, so I had to give up. I think you can build from source to add things but did not go that far! The apps I did install successfully – java 1.6.0_29, tomcat 6.0.29 and Glassfish 3.0.1 – was all installed in folders under /opt as this appeared to be the correct place. Note that for Tomcat, I placed the config files under /etc/apache-tomcat-6.0.20/conf/ and sym-linked them from the ‘expected’ place, /opt/apache-tomcat-6.0.20/opt/, as this appeared to be correct protocol – other apps placed their config under /etc/ and linked to it from their install directory under /opt/. However I did not go to the trouble of doing this for Glassfish – it would be possible (I did do it for the log directory) but the directory structure is more complex.

2/ I did have success with Java – I just ran the .bin install kit of the latest Linux version of the sun Java SE (jdk6u29), and it all unzipped properly and ran fine. Thankfully there were no library problems – probably because there had already been an earlier working jdk6 already installed by default. I added a shell script /etc/profile.d/java-jdk1.6.0_29.sh which created the JAVA_HOME and added the bin directory to the path, but note that this did not work for init time shell scripts for either Tomcat or Glassfish, so their startup scripts had to add their own definitions to work.

3/ I successfully installed Glassfish 3.0.1 (from the zip kit download). To get it to work I had to upgrade Java as above as I got errors otherwise, and the old jdk was below the minimum certified version. However, it worked fine after upgrading java. Note that to stop it checking for updates on startup I just renamed /opt/glassfish-3.0.1-web/glassfish/modules/console-updatecenter-plugin.jar by adding “.disabled” on the end. You can achieve the same thing using the updatetool, but this failed to install properly due to a python error/dependency. I also removed the default jsf-api.jar and jsf-impl.jar from the same folder as above, and added the Mojarra 2.0.4 FCS jars to the folder instead, as my apps needed this version. Note that this also speeds up the startup of the Glassfish admin tool. See my notes here about clearing the osgi cache if you do this.

4/ For Tomcat and Glassfish I separated out the log directory creation from the actual startup, using separate scripts. The log creation is always run, and so sits under /etc/rcS.d/, and the auto startup is optional and may sit under /etc/rcS.disabled/ as a placeholder if it is not autostarted. However, as the log directories under /var/ are always setup, you can then manually start them if desired and they will still work. This is done with the scripts in /usr/local/bin/ – start-glassfish/stop-glassfish/start-tomcat/stop-tomcat. As this directory is on the path, the scripts can be directly run from a terminal window OR from a remote SSH window BUT you would need to be logged in as root to do it.

Graphical Remote Desktop

Re remote desktop, it is in theory possible to use a windows based X server and connect in that way. To do this, you need to run an X display manager on the Linux box to handle the xdmcp protocol etc. imedia linux does have /usr/bin/xdm which is an old display manager. I did manage to run it from the initial login prompt before typing startx, just by typing xdm, and it popped a login screen. However it would not connect to xfce. It recognised a valid login and tried to do something, failed, and redisplayed itself. An invalid login gave a login failure. I also managed to run the launcher from XMING under windows, and got as far as connecting to xdm. to do this I edited /etc/X11/xdm/Xaccess to enable the “*” entry to allow all comers. I also experimented with editing /etc/X11/xdm/xdm-config and set DisplayManager*authorize to false, and tried commenting out the last line as follows :-

! SECURITY: do not listen for XDMCP or Chooser requests
! Comment out this line if you want to manage X terminals with xdm
!DisplayManager.requestPort:    0

I managed to get XMING to display the same xdm login screen that I got locally, which was a good start – I knew I had a connection working. However, I realised in the end that xfce does not appear to be using a display manager – it simplifies things and bypasses it, and to set up xdm to link properly to xfce and to work remotely looked like loads of setting up with no instructions on how to do it properly.

I therefore sadly gave up on this and admitted defeat on installing any kind of graphical remote desktop!

Samba

I got the samba server to share folders successfully – I added the shares in /etc/samba/smb.conf. Security was set to user (security = user). I tried setting “valid users=” to a list of users, to allow restriction of users e.g. to glassfish/tomcat log folders, but could not get this to work, so I left it out.

Note that I did need to use “smbpasswd -a username” to add an existing linux user to the samba user list, and give it a password. You need to run as root to do this, or it merely allows you to change your own password. smbusers allows you to map external users (used by windows clients) to linux users – see here. Note that you don’t need to do this – you can just use the linux names. Note also that when adding/setting passwords with smbpasswd, you *always* use the Linux name, not the samba alias. Some other useful links for Samba follow:-

• http://www.samba.org/samba/docs/man/manpages-3/smbpasswd.8.html
• http://www.samba.org/samba/docs/man/manpages-3/smb.conf.5.html
• http://htyp.org/smbusers

Ftp, Telnet and SSH

1/ ftp is enabled by default via vsftp. The config file is in /etc/vsftpd/vsftpd.conf. The default settings are pretty sensible in opening it up for use in a secur local lan. ftp works via all the local linux accounts including root. The log is in /vat/log/vsftpd.log.

2/ Telnet works but does not allow root access (presumably as too insecure). utelnetd is the daemon but there is no documentation for it on the net I could find. SSH works fine via the sshd and allows root access, but could not find any config files or logging for it, although it is documented on the net – the man pages are here, however the config files mentioned for the daemon do not appear to be present under imedia Linux. No problem, it is set up fine for LAN use and works well from putty in ssh mode.

No Comments »

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 »

This follows on from this post which detailed my previous development stack based on ICEfaces and Glassfish V2.1.

This new stack uses Primefaces, which I now prefer to ICEfaces, for the following reasons (in no particular order):-

1. It has a JSF2 full release – ICEfaces is still only in Beta for JSF2 (as is richFaces)
2. According to various reviews, it is simpler and more lightweight – this may also be a factor contributing to it being further ahead in JSF2 support.
3. It has fuller functionality as standard – with ICEfaces you need to subscribe to the commercial paid version to get some enhanced features such as the treetable.
4. Like ICEfaces, it has a very clean and modern look and feel out of the box with minimal effort. It comes with many themes out of the box, and new themes may be constructed easily online via themeroller, with minimal CSS knowledge. The Primefaces CSS is structured to global theme skinning CSS from component specific CSS.
5. The transparent AJAX bridge of ICEfaces was a compelling feature, as it gave completely transparent partial rendering, although at the expense of resources/performance due to the need for a replica DOM tree in the server which had to be kept in synch. However the new AJAX features of JSF2 perform this in a new way which is also now standard.
6. It has a related component library, Touchfaces, which supports webkit based mobile browsers – widely compatible mobile support will be an important requirement for me.

The following operations should be performed :-

1. Download and install the chosen Java SE JDK
2. Download and install Glassfish V3.0.1 (in my case, the Web profile edition,as it is lighter, I don’t need the full EE feature set and can upgrade incrementally as required). Eclipse has a plugin for, and therefore a dependency on, Glassfish so we do the latter first.
3. Download and install Eclipse (in my case, Eclipse Helios for Java EE, which includes Java EE 6, Eclipselink and all the web tools.
4. Install the Glassfish Plugin for Eclipse (note the updated workaround for Helios), then create a new server for it in Eclipse – right click in the server view then select new and follow the wizard instructions. Note that by default, Eclipse Helios appears to configure the default JVM using the separate JRE (installed by default by the JDK kit) rather than the JDK, even though the JDK was installed. The Glassfish adapter complains about this JRE as it needs a JDK based one. You can just add an additional one for the JDK, and point the server create wizard at it, as detailed here
5. Download and install Primefaces and its documentation. Primefaces is installed manually – I just download the jar to e.g. <workspace>\libraries\primefaces-2.2M1. I then create it as a User Library as detailed here. If you open a web page with the Eclipse web page editor, and display the palette, you will find all the Primefaces components under the http://primefaces.prime.com/tr/ui pallet entry (there may be other palette entries with the name primefaces which may be empty, and should be ignored). Code/tag completion for the components should all work correctly.
6. Download Tomcat if required. I use this for some projects that need a servlet container but not 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.

Comments and issues when test driving the resulting installation:-

• The new Glassfish V3 is fully OSGI compliant, as is Eclipse, so the old issues about Eclipse losing sync as to whether Glassfish was started or not are a thing of the past. However, Eclipse would not use the configured Glassfish admin username/password, and always asked for username and password on startup. It also gave the impression that Eclipse was occasionally losing sync and did not detect properly that Glassfish had already been started externally. This can be avoided by setting Glassfish to have a null password. When I did this, Eclipse never asked for credentials and always seemed to sync with it properly. As this was a dev workstation with no inbound external access and a dev/test install of Glassfish, I was quite happy to run it without a password.
• I imported the Primefaces Component Showcase .war file directly into Eclipse as a test to play around with. This ran fine, but initially any changes to the Java code did not deploy to Glassfish. It turned out that the code folders as loaded were not under the src folder where Eclipse was expecting them, so the auto build process was not compiling them. I just moved all the source up to where Eclipse was expecting them – it already had a set of empty packages there so I just dragged all the source files in the project explorer from where it originally was into the appropriate matching empty packages and all was well. Eclipse then compiled and deployed any Java changes I made correctly.
• Glassfish 3 is supposed to start much faster than 2.1, it did not feel much faster but I did not do any testing on this. However, the new hot deployment on Glassfish 3 was good. I made some simple changes with the Primefaces component showcase, saved them and then did a republish. Some changes e.g. to xhtml files deployed almost instantly. Some java code changes that had larger scale impact took several seconds but were still hot deployed successfully. With Glassfish 2.1, I had found that the integration with Eclipse was a bit hit and miss – sometimes changes would hot deploy, but quite often things just got a bit sick/out of sync as already stated and Glassfish would need restarting, which was always the slow thing. This is why in the end I stuck with Tomcat for dev testing etc. as even though code changes triggered a restart, the start time was so much faster. I’m hoping for better things with Glassfish V3 and the reports I have seen are positive but will need to try it in anger for a while.

No Comments »

This post is to explore best practice in this area.

The reason is that I am looking at a stack based on JSF/ICEfaces or PrimeFaces/Tomcat/JPA, as I have a project in mind to run in a hosted environment and Tomcat hosting is easier and cheaper than JBoss/Glassfish hosting.

Spring’s JPATemplate looks useful, but ties you to a Spring standard rather than an open (JPA) one which is vendor independent.

I am always wary when I read in a vendor’s documentation that “such and such an interface abstracts all the other interfaces used by other vendors/standards etc.”
Whilst of course abstraction is a good thing, you do end up tied to the abstraction interface and so need to be aware of the implications of this!

On face value (and I have not explored this at all yet as I am just starting to look at Spring) it seems a backwards step to encapsulate a platform/container independent standard (JPA) which has cross platform support with a platform/container specific one (Spring)?

This post (which I have yet to explore in detail) suggests that it is cleaner not to use Spring’s JPA support classes, which makes sense to me.

The True Way Of Developing Applications has been disturbed and that is damn good. For starters, please take a moment to read these articles in order:

Getting started with JPA and Spring
JPA Annotations Guide (broken link)
Advanced JPA with spring

• What will happen if you do:
• No more need for hibernate mapping files; everything will work from annotations, persistent classes are automagically discovered, and greenfield projects can have the database automatically generated. Controller interceptors can be substituted with Transaction annotations, which is much easier to understand and maintain. Spring will generate interceptors anyway but at least you do not have to be so aware of them.
• No more need of JpaDaoSupport and JpaTemplate. They were a great commodity with JDBC and raw Hibernate, but with JPA it’s cleaner if you do not use the support classes.
• Do not forget to make your test classes extend AbstractJpaTests so that Spring can inject your attributes.

 
I will continue to post links and discusssions here as I explore it in more detail.

No Comments »

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 »

See the Tomcat 6 Download Page

If you use the Windows service installer (self installing Exe) to install Tomcat 6.0.24 under Windows 7 64 bit, it insists on a 64 bit JVM. I am using a 32 bit JVM and if you try to use that, Tomcat will not start.

You can do this by using the 32 bit Windows zip version, which still allows you to run Tomcat as a service. It also allows you access to the Tomcat Configuration/Monitor utility which you can also run in the System Tray, but you have to set this up manually.

The following steps will do this install :-

1/ Download the 32 bit Zip installation above, and unzip to the desired target installation location.

2/ Edit <Tomcat Home>\conf\server.xml to change the default http port from 8080 if required

3/ Edit  <Tomcat Home>\conf\tomcat-users.xml to add an admin user if desired, by inserting the following in the <tomcat-users> section :-

<role rolename=”manager”/>
<role rolename=”admin”/>
<user name=”admin” password=”mypassword” roles=”manager,admin”/>

4/ Issue the command Service install from an administrator privileged command window pointing at the <Tomcat Home>\bin directory.

5/ Create the following shortcuts to run the Tomcat Configuration Utility and the System Tray Monitor Utility.
Substitute your device and directory for <Tomcat Home>.

Configuration Utility – Target:  “<Tomcat Home>\bin\tomcat6w.exe”  //ES//Tomcat6
System Tray Monitor – Target:  “<Tomcat Home>\bin\tomcat6w.exe”  //MS//Tomcat6
(Both Cases) – Start In: may be left blank
(Both cases) – Tick the Run as Administrator check box under either the Shortcut or compatibility tab.

6/ Note that you will have to OK running as administrator each time you run one of the shortcuts, assuming you have User Account Control turned on in Windows 7. This is also true if you try to run the tray monitor automatically in the startup group. Windows 7 insists that each time you log in, you have to OK the administrator usage(!) This is supposed to happen by adding such autostarted tray applications to a “blocked startup” group which have a tray icon to display and then selectively “OK” them to unblock them/OK the administrator usage. This never worked for me – anything I placed in the startup folder which needed administrator access just plain did not run at all, and I never saw this “blocked” icon. As it would mean OKing at each login anyway, it seemed to me that there is no point trying to autostart tray icons that need administrator access as it was more hassle to unblock them (even if it did work) rather than just run them as needed from the super bar or quick launch bar (and of course OK them).

No Comments »

I hit this when deploying  an Eclipselink 1.1 web application to Tomcat 6.0.24, when trying to place all the persistence jars in <Tomcat Home>\lib

The app worked fine when including its own copy of the jars under WEB-INF\lib, but moving them to <Tomcat Home>\lib gave the following error :-

java.lang.SecurityException: class “javax.persistence.Persistence”‘s signer information does not match signer information of other classes in the same package

I checked all the other (non eclipselink) libraries present and could not see a clash. This post appears to shed some light, indicating that it is perhaps a mismatch of jar signing in the Eclipsink libraries.
However, it is strange that it works fine with the libraries deployed with the application rather than under Tomcat.

As Tomcat does not provide its own JPA support, I decided I was quite happy to deploy the libraries with the web app as that works fine, and to leave the issue unresolved.

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 »

I’ve found that this is useful for prototyping/mockups of apps that are targetted for GlassFish. It is possible to run JPA with Eclipselink outside an EJB container, so a JSF/JPA app can be run under Tomcat, resulting in less overhead and faster turnaround of changes. For a while I’ve had to use a PC which is RAM limited, and so developing/prototyping with Eclipse and Glassfish has been slow. Turning around deployments/changes around takes time, and I’ve found the synchronisation between Eclipse and Glassfish to be a bit fussy – sometimes Eclipse misunderstands the state of Glassfish, needing a Glassfish restart which again takes valuable time.

Note the following points on doing this:-

1/ My application stack looks similar to the ‘real’ one, but my Service layer/domain objects are just POJOs which are explicitly created or injected via faces_config.xml. This Oracle Example details the various IOC features of the JSF. managed bean facility.

2/ Persistence.xml needs setting up differently to run JPA outside the container. I have found it easiest to specify the database connection explicitly, rather than using a data source. In Eclipse, you can use the persistence.xml editor to populate the connection properties directly from the one Eclipse uses for its entity validation. Whilst you can do JNDI lookups of a data source stored in Tomcat, the naming context used is different, as it makes use of the Enterprise Naming Context (ENC), i.e. “java:comp/env”. This example details how to do it if you want to go that way. A sample persistence.xml follows (with entries commented out where they have been replaced for use with Tomcat) :- 

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="1.0" xmlns="http://java.sun.com/xml/ns/persistence"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
 http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">

 <!--<persistence-unit name="SentryPrototype" transaction-type="JTA">-->
 <persistence-unit name="SentryPrototype" transaction-type="RESOURCE_LOCAL">

   <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>

   <!--<jta-data-source>jdbc/JPATestPool</jta-data-source>-->

   <class>uk.co.salientsoft.jpatest.domain.UserInfo</class>
   <properties>
    <property name="eclipselink.logging.level" value="INFO" />

    <!-- <property name="eclipselink.target-server" value="SunAS9" />-->
    <property name="eclipselink.target-server" value="None" />

    <property name="eclipselink.session-name" value="SentryPrototypeSession" />
    <property name="eclipselink.target-database" value="Oracle" />   
    <property name="eclipselink.ddl-generation.output-mode" value="database" />

    <property name="eclipselink.jdbc.url" value="jdbc:oracle:thin:@localhost:1521:xe"/>
    <property name="eclipselink.jdbc.user" value="sentry"/>
    <property name="eclipselink.jdbc.password" value="sentry"/>
    <property name="eclipselink.jdbc.driver" value="oracle.jdbc.OracleDriver"/>

   </properties>
  </persistence-unit>
</persistence>

3/ Ref this eclipse tutorial :-
Tomcat does not have an EJB container so you must add EJB 3.0/JPA 1.0 capability for EclipseLink JPA by placing the specification persistence.jar into the container lib directory $TOMCAT_HOME/lib.
It is recommended to put persistence_1_0.xsd there as well.  It is not recommended that the WAR include its own version of persistence.jar. Your eclipse project should reference but not include this jar and xsd.

The eclipselink.jar should be placed off of the container lib directory $TOMCAT_HOME/lib.
Since Tomcat does not include an EJB container, you may put eclipselink.jar in the web applications’s lib directory or higher up in the classloader by putting it off of Tomcats’ lib directory, where all web applications can access it.
Do not split the eclipselink.jar from the javax.persistence jar – keep them together – preferably in $TOMCAT_HOME/lib

 4/ Tomcat has its own dependencies on the Expression Language (EL) web libraries. These should be removed from WEB_INF/lib when deploying to Tomcat as pointed out here. (If you do not do this, the application will crash with duplicate class loading exceptions.) This may be done in eclipse on the Java Server Faces facet page – open the project properties for the project, and select Java Server Faces under Project Facets. Untick the entry for Standardized EL Library v1.0.

Then save the changes and redeploy the application.

For more information, the eclipse tutorial referenced in 3/ goes into greater depth on the subject. You can also find a list of the available eclipse JPA tutorials here.

5/ When running xxxxxx

Comments Off on Using Eclipse/JSF/JPA with Tomcat 6

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 »