I just upgraded a VM to R8.5.1 to see how it works before doing that to my main instance. Using this VM I edited a project I’ve been web enabling using XPages.
Right off it got a 500 error - Command not handled exception. I looked … the default error page is checked, yet I g0t no stack track, nothing but a 500 error line by itself.
So I edited it using R8.5FP1. Now it gets a 404 - file not found error loading the launch page, yet that page is clearly available when I select launch options, clearly present in the XPages list, and is loaded from a bookmark that hasn’t changed since the project started.
The only change is that I edited it use R8.5.1 Designer. Yesterday at COB it loaded and worked without a hitch.
The server is “Lotus Domino (r) Server, Release 8.5FP1, June 15, 2009”. I looked for an R8.5.1 server upgrade and didn’t find one. Far as I know this is more a client upgrade, anyway, but I did look.
Is there something I could try to fix this? I fully expected it to mess up client stuff, which it didn’t do in the slightest. Client, DDE, etc are all completely untarnished, which made me very happy. I’m not quite so happy about my work being interrupted such that I can’t even roll back to R8.5FP1 and continue.
I don’t think using an X.Y.N+1 Designer client on an X.Y.N server has ever been supported. If it has and worked, I’d still say it’s generally not a good idea.
It probably didn’t matter in the past since Designer was very static from version to version (6.0.0 Designer → 7.0.4 only has a few changes of minor significance). But since IBM seems to be pouring the love on the Designer side of things I’d try very hard to run the same version of Designer for the server you’re deploying to.
Oh, and you’ll like this: In 8.5.1 there’s a “Recompile all dependencies” option. It might be the “scalpel” approach to the “shotgun” of “Recompile All Lotusscript”!
In fact this is the first time I can recall where I intentionally ran a higher version of Designer against a lower server. Others in my company do this all the time, but I have myriads of Client & Designer installs lying around, and have had for years and years, specifically to be able to employ the correct version of client/designer against the correct server.
The only reason I did it this time is because when I downloaded 8.5.1 I missed the server. I thought it was odd that the client was 8.5.1 and there was no server, but I installed it anyway.
Rest assured that will never happen again. This has been a nightmare.
Dependencies recompile does sound very sweet. I also like the line numbers in the LS editor, and the fact that it actually lists methods and such at last. I knew moving to Eclipse would be good. Now we’re actually seeing more of that…
It appears to have scrambled its build. If I use R8.5FP1 to change the launch option to “use Notes” (instead of an XPage), I get a 404 error in the banner frame. That 404 is referencing an item in the XPage banner. Since the Notes web stuff (non-Xpage) has never been changed it should be attempting to render the client’s normal interface as a web page, and the client does not and should not be referring to XPage-only design elements.
If I could clear the DDE cache that may fix it, but despite numerous queries I’ve never been told where that is. It used to be shared with the client, in cache.ndk, but while R8.5 still has that file, forum posts seem to indicate there are numerous other places where caching can occur.
Subject: Random chance is not an acceptable solution.
Closing Notes/DDE, deleting cache.ndk, and flush http caches had no effect.
I also enabled thread debugging on http, and started removing imported JS libraries from the XPages, thinking perhaps one of the libraries is corrupted. I’m now at a consistent 500 - Command not handled exception, I still get no default error page/stack trace, and the request thread log looks perfectly normal. No exceptions, nothing.
I’m using R8.5FP1 for everything.
I progressed to removing components and it appears two controls cause it to fail:
A pager on a repeat that builds a table from a View.
The data binding on document-driven list of links that select the view built by Item 1.
This is some of the first XPage stuff I got working, particularly Item 2. It makes no sense that it would suddenly (and apparently irreparably) fail now.
After spending the last two hours fiddling with this, and getting it to load with the items above commented out, I restored all components and libraries one-by-one, and it works perfectly. I find it more than a little annoying that I’ve wasted four hours installing R8.5.1, having it destroy my work, then attempting to diagnose what it broke, only to have the automagic mysteriously repair itself for no more reason than it broke to begin with.
There needs to be a better way to deal with problems. Random chance is not an acceptable solution.
Subject: Unfortunately I think you’re gonna see that…
Apparently they made some changes in 8.5.1, certain things you do to an XPage in 8.5.1 won’t run on an 8.5 server. I’m guessing 8.5.1’s DDE is “touching” some stuff and revealing something that was (probably) in a broken state from 8.5’s DDE. I had stuff like what you describe in the 8.5.0 Beta happen all the time. Just at some point, things get “munched” and you’re back to cut-and-pasting your way to it magically working again. It’s one of the reasons we avoided 8.5’s DDE and let it go to 8.5.1 before we started touching it.
I’d touch all your custom controls and XPages (in that order) with 8.5.1’s DDE and then rebuild the ones that still break. I’m guessing you’re going to see that problem again, hopefully that will help you get a handle on it before it bites you bad.
I thank you kindly, Erik, for your information. I couldn’t find the server yesterday so I didn’t install it. I found it and I’m downloading it now. Forty-two minutes remaining.
One of Lotus’ strongest points has always been backward compatibility. If that is being abandoned it is an extremely, extremely sad day.
For the last twelve years I’ve mixed and matched servers and clients without any real problems. True, I tend to have more issues when upgrading a client against an older server, but this is minor point release. Despite any other consideration I have never, once (before today), seen problems using an X.Y.N server and an X.Y.N+1 client. Or N+anything, actually, as long as X.Y remains the same. In over twelve years. Across four major and dozens of minor releases.
Now that seems to be tossed on its ear. Very, very unfortunate indeed.
And it’s doing this random automagic failure on other XPages now, so it looks like this entire day is likely lost to R8.5.1. There is no joy in Mudville…
It’s like LotusScript of yore, before they added the sledge-hammer “Rebuild all LotusScript” option. I rebuilt each and every XPage design element in reverse order, from “lowest” in the heirarchy to “highest” (the XPages themselves), and it works fine as frog hair.
Well, almost. One XPage is still getting the 404 error. (sigh) Oh well. It’s close enough I may actually bet able to get some work done today, with the parts that work, and maybe the automagic will re-fix itself while I’m editing. (crosses fingers)
With 8.5.1, we try to guarantee that 8.5 applications will run as is on an 8.5.1 server. This is the case, except if your application is taking advantage of a bug that kept some JavaScript data in memory, which has some impact on scalability. For that one, we asked the community and we got a clear answer that we should fix it, favoring the scalability against the compatibility. This is what we did, along with a property you can set to revert this behavior, just in case of…
Now, an 8.5.1 application might use some new controls/attributes and thus prevent it from running on an 8.5 server. This is called upward compatibility and we cannot guarantee it, as we cannot simply just ignore the new properties. To prevent any bad behavior, the XPages compiler (within Designer) is tagging the pages with the minimum requested server number (8.5, 8.5.1…), based on each control/property used in the page. If it has just 8.5 controls/attributes, then the page is tagged ‘8.5’. Else, it is tagged with the highest version number found. At runtime, the server is checking if it matches this minimum requirement. If not, it throws an error, which is basically your case.
On the other hand, event management had been simplified in 8.5.1, and it doesn’t need the ‘handler’ tag as it needed in 8.5. From a compatibility standpoint, the old tag is still supported on 8.5.1 servers (and will be forever), but Designer is now taking advantage of a new ‘script’ property when generating the event code. So if you use Designer 8.5.1 on a 8.5 database, if you change an event using the event panel then it generates the new property and the page becomes tagged ‘8.5.1’. If you change it in the source code, without the event panel, the problem does not appear. So you can still revert your change this way.
I think see what happened. The change I made using 8.5.1 DDE was in the beforePageLoad event, in the Source editor, as I pretty much avoid the Design tab like anthrax. Based on your description, Philippe, this marked that CC “8.5.1”, even though nothing was really changed, and this utterly hosed everything.
So while “the old tag is still supported on 8.5.1 servers”, it’s not, really, because under the hood the automagic has changed and it breaks compatibility. Sure, the tag doesn’t cause an error on build, but it does destroy functionality. This is not backwards compatible. Once any event in any XPage/CC is ever saved using 8.5.1 DDE, that XPage/CC will be completely non-functional on any server less than 8.5.1.
I repeat: This is not backwards compatible.
Backwards compatible would be to retain the prior behaviour across the board unless it’s saving to an 8.5.1 server or above. I’m sure DDE knows or can query what the server is, and it would be significantly simpler than all this version tracking that does not maintain backwards compatibility.
The only observable behaviour from all this version tracking is that the application becomes unstable under 8.5FP1, not showing error pages as defined, randomly tossing either a 500 or a 404 error, and failing on random controls in completely different design elements, in addition to breaking compatibility.
So I’ve upgraded my server as well, seeing as how I have no choice, because even manually recompiling each CC/XPage using 8.5FP1 DDE against server 8.5FP1 did not fix all the errors. I have my fingers crossed that manually rebuilding the entire system using 8.5.1 DDE on the new 8.5.1 server will actually make it work again. At this point I have little hope, however, and am ready to toss all changes since the last backup and start over.
If the above is incorrect please tell me what I’ve missed. I would much rather be wrong than continue to think backwards compatibility has been so savaged.
Subject: I think I should open a ticket if I’m going to do that…
A support call would mean reproducing the issue using the backup copy. It would also mean a block of time to strip out elements not essential to the web presentation, when I’ve already lost two days to this. In short, I have to run that by management. If they concur I’ll happily open a support ticket for it.
Subject: Difference in Event (Client side and Server side) XML
I also found that resaving an XPages in Designer 8.5.1 “broke” it when running on a Domino 8.5 Server. I traced the problem to Javascript called from a button event. In the Source view of the XPage, Designer 8.5 has 2 extra levels of tag inside of the eventHandler tag: xp:this.handlers <xp:handler type=“text/javascript”>
Designer 8.5.1 removes these. Re-saving the event code using Designer 8.5 allows it to run on the Domino 8.5 server.
Very surprised that Lotus/IBM QA didn’t catch this one but hope that this additional info is helpful.