Has there been some change in the underlying Java classes for Notes between 5 and 6?
Some time ago, I used the domino classes to write a small Java application to replicate a new user’s mail file and then remove the creating Administrator’s ACE from the ACLs of both the original and the replica. To the best of my knowledge, it has been running without incident for about two years.
Recently, the machine it was running on was upgraded from an R5 client to a 6 client and now the application appears to be broken. It stops runninig at the point where the ACE is removed from the first database. It doesn’t throw an exception either, it just stops dead. I have both generic Exception and NotesException catch blocks protecting these operations, but they appear to be completely ignored.
As far as I know, the underlying java version installed with Domino R6 is newer than version used in Domino R5.
Why isn’t the newer version fully compatible with the older one, I don’t know, but I’ve seen few problems also after upgrading our server from R5 to R6.5.1.
We had quite few java-agents running in R5 properly for many years, but after upgrading to R6 some of the agents started to throw errors in notes log when run scheduled.
I haven’t been able to solve all of these issues yet, but obviously there have been some changes.
This didn’t solve Your problem, but now U least know that somebody else is having tha same problem also.
I’m not privy to what changes have been made to the Domino Java model “under the hood” (apart from the new classes and the fact that it runs within a 1.3.1 JVM in Notes 6.x), but on the scheduled Java agent point, you might want to check out your security settings and agent signers, as the agent security model has changed in release 6.
I had the same issue and there is a new setting where you can run an agent “on behalf of” in v6 + . Unfortunatly if you didnt examine who your agents before upgrade then they will run on behalf of the last person who signed them. In my case the person had left therefore agents were failing.
As benpoole said, check security settings of all agents but also check who can “run agents on behalf of…” in the server doc.
Also I created a generic agent signing id specifically for this purpose.