Salient Soft

I decided to go from Java 8 to the most recent LTS release of Java, JDK 17, and to the current latest Spring Boot, 2.6.7, for my Spring Boot Identity API which is a java back end interface to Yoti.

Initially I used Oracle JDK 17, and I hit an issue when running live with Yoti, but using the Java IdentityAPI locally. Curiously (and annoyingly) everything worked fine when running in debug under the latest eclipse, 2022-03, but I failed to get a Yoti profile back when running the compiled Spring Boot version directly.

This Spring Boot issue details the problem, which is exactly what I was getting – an error returned when getting the Yoti profile, due to an interaction between Spring Boot, Oracle jdk 17, and Bouncy Castle encryption, causing an IllegalStateException citing ‘zip file closed’ when the jar is being unpacked. The issue does not occur when running an exploded deployment (i.e. not in a fat jar), such as is done when running in debug in eclipse as I was.

There is no resolution at present, but as the problem does not occur under openJDK, I elected to switch to openJDK 17 rather than revert to Oracle JDK 11, which would have been another option.

Switching to openJDK 17 fixed the problem, and I was able to successfully perform age verification using a local Spring Boot IdentityAPI of mine, built with openJDK 17, and using the production Yoti to retrieve a live profile.

Whilst doing this, I improved the logging and elected to use Lombok’s @slf4j annotation to create loggers, for convenience, as this also allows logging to be tweaked via the Spring Boot application.properties as normal for Spring Boot. This is detailed here for reference.

In addition I upgraded the Yoti Java SDK I was using to the latest one (yoti-sdk-api version 3.4.0) rather than the old one I was using (yoti-sdk-impl version 2.6.0). This involved a small change to my YotiService as the interface to Yoti has changed, and some small pom changes for the new version. This all worked fine.

Comments Off on Issues upgrading my Yoti Java IdentityAPI to JDK 17

Eclipse allows you to export Jars via the Export/Java/Jar File right click option from the package or project explorer on a project.

The export wizard has a number of options. I generally create one jar with the class files in and a second for the sources.

It is obviously somewhat tedious and error prone to select all the options each time, so fortunately on the export wizard, on the Jar Packaging Options page you can select the option to Save the description of this jar in the workspace.

This will then create a .jardesc file with all the options on. Later you can simply right click a previously saved .jardesc  and select Create Jar to recreate the jar with the same options that you saved.

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 »

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 »

I have experimented with the following techniques for managing user defined collections of library jars in a Java EE 6 web application within Eclipse Helios. Much of this follows from this chapter in Eclipse Distilled:-

1. An interesting method described in “Eclipse Distilled” is to use a local simple project in the workspace as a library project just to hold eclipse folders to plant the jar collections in. This then allows all other projects in the workspace to reference the jars using relative workspace references, which gives complete portability to the workspace across different locations and operating systems. It does not however allow the library collections to be designated via a single name in the way that user libraries do – you end up with a just a pile of jars on the build path of a referencing project. You can however at least add them all at once via multi select of the jars from a folder in the library project.
2. Another way is to use User Libraries, again as in the above chapter. They have the benefit of allowing a single name to designate the collection of jars, they can be used from anywhere in the workspace, and they can also be exported and imported between workspaces along with other workspace settings. The drawback is that the library location must be defined as an absolute file system location, which means that unlike the above method, you can’t just copy a workspace with all the libraries in it to somewhere completely different and have it ‘just work’ – you have to set up the library locations. However, you also have to typically do this for JSF and JRE libraries, so unless you have a lot of them it is not such a chore.
3. Another mechanism is to use eclipse Classpath Variables, which allow a folder location in the filesystem to be defined and then used via a name. Again, the definitions need to be set up on each different system/location that you migrate the workspace to.
4. Classpath Containers are a dynamic form of reference where a named reference is intercepted by code in a class. This is used by plugins, and allows the definition to change dynamically in response to other environmental changes detected by the plugin code.

On balance, in the absence of a plugin/Classpath Container approach, my favoured option is to use User Libraries for tools like Primefaces as they are convenient and look tidy on the build path even when it gets large. In an ideal world, it would be helpful if User Libraries allowed workspace relative references. This would permit the libraries to be packaged within the workspace which would mean no setup is needed to port the workspace. The downside is that when multiple workspaces are used, you end up with library duplication unless you use an absolute location outside the workspaces. However, you could have a libraries folder under a parent folder above all the workspaces. Then if a relative reference like ..\libraries was permitted you get your cake and eat it – no duplication and a portable collection of workspaces with a single copy of all the associated libraries.

However for now, it’s User Libraries for me. To create a User Library for a project in Eclipse, do the following :-

1. Select project properties/build path/Configure build path, then select the Libraries tab in the right hand pane.
2. Click Add Library…, select User Libraries, and hit Next.
3. Click User Libraries… which will display the User libraries page.
4. Click New to add a library, then add jar(s) to it with Add Jars…
5. Having added a jar, you can expand its definition using the tree control in the middle pane, and then double click on javadoc location, and/or Source attachment to add a jar or zip containing the javadocs/source for the jar.
6. The library is then accessible from all the projects in your Workspace. You can export it to other workspaces by using File/Export/Preferences.
7. Note that typically you need to tell Eclipse to deploy the libraries to WEB-INF\lib when deploying. Under Eclipse Helios, you do this using the Deployment Assembly options page under the project properties, adding an entry for each library you need deploying. When adding, you can elect to add from the java build path, which makes the most sense if you are deploying libraries you have added to the build path. Note that in previous versions of Eclipse, this option on the project properties was designated J2EE Module Dependencies.

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 »

Eclipse can compare  a pair of open files. It is not obvious how to do this however.

All you need to do is select the first file in the project/package explorer, then ctrl/select the second file so that both are selected. If you then right click, you can select Compare To/Each Other and a new differences view is created.

You can also select a single file, and compare to another version in CVS by selecting Compare To/Another Branch or Version

This post also discusses the technique.

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 »

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 »

The process is a workaround for this eclipse bug, which seems to have been around for some time.

1. In Eclipse, enter Help/Add new software
2. Click the Add button to add a new update site, and enter the url https://ajax.dev.java.net/eclipse (I have also used http://ajax.dev.java.net/eclipse instead as suggested by other forums, but some users state that this does not work).
3. Wait for the screen to populate (this may take some time), then select “Glassfish Java EE 5 and Java EE 6 support” and hit next
4. Proceed with the installation as directed by the wizard.

No Comments »