I have a xpage which uses a java bean to generate some content on the page. The page gives error "Error 500 HTTP Web Server: Command Not Handled Exception". But error just disappears once I open the database using designer. I do not do any modifications to the database, but just open the database using designer client. I have to open the database every day to fix this problem. Can anybody tell me why this is happening and how can I fix it?
"Error 500" is a pretty catch-all error description, and I believe it shows up if you don't tell the app to display the XPages runtime error page (the default with the stack trace) or provide your own. If you do one of those (or look at the server console and error-log-0.xml in the data/domino/workspace/logs folder), you may be able to get a more-specific description of the problem.
But one plausible "crops up every day" type of problem I've run into is the "X is incompatible with X" ClassCastException problem - at some point in the growth of most XPages apps, this starts to crop up (I don't know why other than "using Java") and gets to the point where even changing non-XPage design and potentially data docs triggers it. Fortunately, the fix is easy: assuming you're running 8.5.3 or above, go into the xsp.properties and check the option to "Refresh entire application on design change" (or thereabouts). That should fix it if this is indeed your problem.
Looks like it was my designer client. I was using 8.5.3 without any fix packs. I installed FP6 and signed the design again and the problem is fixed.
Related
I have this popup window showing on my website in Firefox.
It is indeed a system window displayed by the browser, not by the page.
There is no useful information in the console.
What may cause it and what can I do about it?
I encountered this today. It came from window.Muse.assets.check being unable to verify some script in a list of those required. I believe that this is Adobe Muse, which appears to be a library of widgets (like slideshows and effects).
Last week I tried to update my Notes client installation from 9.0.1 FP9 to FP10 IF 3. For technical reasons I had to roll back which proved to be quite difficult, and I ended up completely uninstalling Notes and doing a fresh installation of 9.0.1 (standard) then FP9 IF 2.
Everything's fine (and much more responsive than before, too) with one serious exception:
Within the client help popup window for Notes client and Domino Designer help is hardly usable now; obviously there's no CSS style or whatever applied to the nav page / frame:
As you can see in the screenshot styling of the main window part (green frame) is fine. But everything that is releated to navigation (red frames) appears to be raw html. Javascript calls are apparently working but it's really hard to navigate the "chapters". Same applies to Designer help, of course.
Here's what I tried to solve that riddle:
uninstalled and re-installed full client 3 times; sometimes I ran the
installation as local Admin other times I didn't (no difference)
just installed plain Notes 9.0.1 from scratch then tested Client help before updating to FP9IF2 (no difference)
restored the entire [Notes-Programm]\framework directory from a
backup I took when Notes help still was working as expected (no difference)
copied over the entire \Notes\ folder from a different PC where popup help is still working fine (no difference)
Problem with that is: being a Developer I need to have a functioning help window in my Domino Designer. The navigator as it is right now however is plain useless. And designer_help.nsf isn't of help at all when it comes to Java, LotusScript etc. objects and classes.
One of my co-workers has the same phenomenon while another one hasn't.
Question: did anyone else experience something like that? Where you able to solve it? How?
This seems to be related to an issue with the embedded browser windows that Domino Designer uses to open the Help website.
Try to open following link in a modern browser (such as Chrome or Firefox) and the navigation should be fine.
http://localhost:50970/help/index.jsp?topic=%2Fcom.ibm.notes.help.doc%2Ffram_getting_started_c.html
Bookmark it and use it when you need it.
Try using the IBM Nice tool to see if it can fix your issue
https://www-01.ibm.com/support/docview.wss?uid=swg21459714
Meanwhile I restored my entire Windows system partition from a backup created just before all that began (lucky me that I have both regular local backups plus a separate system partition). And that finally helped resolve the problem.
Meanwhile I'm 99% sure that this is due to a rather new registry and/or firewall setting not yet known to IBM's NICE tool.
When I am trying to access a Spotfire dashboard via web player, I am getting the below error message. I was able to access this dashboard earlier without any issues, this issue has popped up recently.
Please advise as what could be the reason for this error?
Below is the screen shot:
Thank you!
this error means that the data source has changed or is not available.
verify that your data source is still working in the Spotfire desktop client. check that the data source is either a linked DB table of some kind and that the information link still works. otherwise ensure any file-based data is embedded in the document.
the error seen on webplayer is pretty high level; it's basically "oh no, something's wrong!" and not very descriptive. if you can share some more including your Spotfire version and relevant logs (don't forget to remove sensitive data) I can probably give you a better answer.
#scsimon/niko - Thanks for your suggestions. I was able to resolve this issue. Cleared cookies and tried to login again. I was able to login to dashboard but one of the pages was not loading. Duplicated page in client and deleted the old one. This resolved the issue.
Greeting, brethren,
So I inherited this app (yes, XPages can be legacy now ;-). It is meant for the Notes client only and one process takes a convoluted route via what I understand is called a Managed Bean (the Code/Java design element).
The database resides on a server.
When editing said bean.java, I meet two issues.
If I test immediately thereafter, I'm greeted with an Error 500 that won't go away unless I close then restart both Notes and Designer
In some cases, changes made to bean.java are not immediately available. So far I haven't been able to characterize those cases. For example, yesterday afternoon I could no anything, nothing would bring a change to the Notes client. (Yes, I cleaned & rebuilt and autobuild is disabled). This morning changes are apparent immediatly (save for the quit/relauch bore).
I've tried to set xsp.application.forcefullrefresh=true in the app's Xsp properties but haven't noticed much effect.
What am I doing wrong ? What could I do to fluidify the modifying of a bean ?
When working in XPiNC, after every change you have to close and restart designer. If I understand things correctly, it's trying to access class files that have been discarded. That's why whenever I've had to develop for XPiNC, my initial testing during development is on a browser, I would recommend this approach.
There are minimal differences in syntax, usually only encountered if manually creating URLs to files etc or using the bad practice "" to specify database location in #DbLookup. Wherever possible, avoid #Formula approaches, their performance is worse than object orientated methods (e.g. view.getAllEntriesByKey())
It's the same for the bean. There are only two ways to speed up picking up updates - use a browser or use XPiNC on a different PC.
Sometimes the style sheet disappears when naviguating on our WSS 3.0 sites (white background on the site, no colors, no formatting, etc.). This has mainly happened with IE6 (corporate browser for the majority of our computers). The fixes were :
clean up temporary internet files
if it still doesn't work, upgrade to IE 7
However, this time, the upgrade to IE 7 hasn't worked, the style sheet isn't applied. When we clean up temporary internet files, things go back to normal, but after a while the css disappears again.
Here are a few ideas on what you could try:
Fiddler should be able to tell you if there is a network problem.
Check the HTML for anything unusual. Is it malformed in any way? Can you save a copy and run it through an online validator (although this is limited in use as SharePoint's default markup isn't compliant).
If some users are having the issues but others aren't, check their permissions on the server.
You could also try using the SharePoint "Log in as another user" feature to see if the problem can be reproduced on your machine when logged in as them. You may also want to try running Internet Explorer as that user.
Check the Event Viewer on both client and server for anything unusual.
Check the IIS logs on the server for any errors.
Check the SharePoint ULS logs on the server in the "12 Hive" for errors that might be related to this problem.
Try running Process Monitor on the client and reproduce the problem. Search for keywords such as FAIL or ERROR to see if anything appears. Make a note of the time the problem occurs and see if the Process Monitor logs give any additional information.
Is there some javascript that's involved as well? Could it be a virus scanner that is set way to strict? As you pointed out in one of the comments, the CSS isn't even being requested (at IIS log level, which is as basic as you get, not even in SHarePoint yet), so it HAS to be something on the client PC.