Salient Soft

cvslock.exe sometimes crashes with the following pair of event log messages :-

1. Failed to bind listening socket: Only one usage of each socket address (protocol/network address/port) is normally permitted.
2. Faulting application cvslock.exe, version 0.0.0.0, faulting module advapi32.dll…

Initially I thought this was due to not adding it as a firewall/antivirus exception, but the error still appears to happen the first time a repository is created and brought up/reconfigured. The 2 errors appear to be related – the socket error may be due to cvslock being started twice in error (indeed, this may be the cause of the other error too.)

Once the repository configuration is up and stable, the error does not seem to occur.

When the error occurs, a systray icon for cvslock appears, and selecting the debug listing menu option for the tray icon displays the error “no ipv6 address found for host” in a command window.

I tried stopping the services, creating a new repository (which succeeds), and then starting the services. The cvslock service refuses to start, and the tray icon appears as above. After a few seconds, the tray icon disappears, and the service can be started as normal.

This does appear to be a cvslock issue related to new repository creation. As the workaround is straightforward, and operation appears stable after that, the bug appears to be a minor one.

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 »

Download and install TortoiseCVS from here. Note that the release notes for version 1.10.10 state that 64-bit versions of Windows are supported. My installation runs fine on Windows 7 64-bit.

Except for the main preferences screen, all of Tortoise CVS is accessed via Windows Explorer context menus. Note that this also works within the file open dialogs of applications.

Connecting to the server is done from the CVS/Checkout… menu. In the left pane of the resulting dialog, you select the protocol, protocol parameters, the server, and the repository folder. In the case of my Java repository above, this will be /Java. Note that you do not need to tell the client the server side path of the repository root.

Tortoise does not cache passwords for access to the CVS server, so you have to enter it for the first time in each session. You can however add custom switches for the connection protocol, which may allow a password to be specified. Note that this is therefore not encrypted! You will probably want a dedicated low privilege account for CVS access if you do this, and in fact this is recommended anyway  – see here for details on how to set this up.

For the pserver protocol, you can add password=mypassword to the Protocol Parameters box in the checkout dialog.
The settings in this dialog are remembered for the next time you use it. If you access multiple replositories, they are remembered and may be selected in the list box at the top.

You do not want Tortoise control on all your explorer folders, as this can slow explorer down and clutter up the context menus when you don’t want it. Use the advanced tab in the preferences dialog to include/exclude folder trees from Tortoise control. Note that if you add a folder tree to include, all others are excluded – see this post here. You can also exclude network shares etc. (done by default).

Usage Points

1. When checking out, you pick a module name in the RHS pane. You can browse for/refresh the module list first.
2. After checkout, you get a subfolder for the module tree, which contains a cvs folder which contains metadata and is managed by Tortoise.
3. If you do a ‘wild’ checkout you will end up checking out CVSROOT which you don’t need – this can be deleted.
4. You can tag a file or group of files/module etc. to indicate a version, then check this out later using the tag. Note that internally, CVS uses a an “n.n” style internal version number starting at “1.1” for a file.

No Comments »

This post details the setup of a repository server on a Windows based PC.

Download and install the CSVNT server here.
Make sure you pick the Windows Server software and not the “client trial”.
If you show all downloads you need to pick a server OS, not a client OS like Windows XP, even if installing on Windows XP Pro like I was. (You cannot install on XP home at all  – you must have simple file sharing turned off and Windows XP Home cannot do this). In my case, simple file sharing was off as I had already turned off ForceGuest, see here.
You can pick a specific account for access, or use the client account  – I presume the user/password must also match the server if you are in a workgroup rather than a domain but I did not test this. My installation was in a Workgroup with a specific account on the server PC. Note that you should run CVSNT under an account on the server with the minimum of privilege, rather than an administrator account. See here for details on how to do this.

The server runs 2 services – CVSNT Dispatch Service and CVSNT Locking Service, which both need to autostart (this is done by default). The server administration is via a control panel utility which is also available via the start menus.

Ensure that Simple File Sharing is turned off.
Make sure that you exclude cvsservice.exe and cvslock.exe in both the Windows Firewall and any Antivirus software.
In my case failure to do this caused 2 problems :-

1. cvslock.exe crashed soon after startup
2. The repository was not visible at all from the client side (in Eclipse) and would not connect – connection timeouts occurred.

You can run multiple repositories from a CVSNT server. In my case I am using a common root – “D:\CVS Repositories” and a subfolder for each respository underneath. My Java repository is named /Java and is similarly connected this way on the client. Its Root is therefore defined as D:\CVS Repositories\Java.

Connecting to the server

In all cases I use the pserver protocol – the Eclipse plugin does not support many protocols natively and pserver is the most common. I use the same protocol for Tortoise..  The server does not mandate the protocol used by the client (as far as I know) so provided the plugin is loaded for the protocol (see plugins page in the CVSNT control panel server admin tool) it should work. Pserver apparently only encrypts passwords but if you are running on a secure internal development network behind a firewall this should not be an issue, and should also improve performance as the protocol is not having to encrypt everything.

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 »

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 »

A little counter intuitive gotcha this one. At first glance, you would expect to right click a server in the servers view, and pick properties. However, if you do this, you do not get the full set – you just get the ability to switch deployed file location and some monitoring options.

If you just double click the server in the list, or right click and select Open, you get the Overview page listing (almost – see below) all the available properties for the server. For some reason in the past I tripped over this more than once, as it just does not seem right that the properties context menu option does not give the full property page (or at least link to it)!

Also, note that the ‘monitoring’ options available on the properties context menu option do not also appear on the Overview page – however the location  options do appear on the overview page in more comprehensive form.

DOH!!!

Comments Off on Changing Server Properties in Eclipse