Our Cognos 8 application has an error affecting many users:
http://img543.imageshack.us/img543/6849/aoeu.png
CM-REQ-4158
The search path ... is invalid.
We know how to fix this problem (it's a browser configuration issue) but the error message is not helpful. Also, users will get this issue if they upgrade IE.
SO
Is it possible for us to modify this error message so it is more useful?
I believe the only way you'll be able to hone in on those messages is to use the Language Development Kit (LDK).. I'm sure you can edit them by hand, but I don't think it's worth it.
Related
i am using B2C provider for DNN and trying to install it as extension and it's throwing error https://i.stack.imgur.com/6faW1.png
i am trying to use multiple version as well but not installed properly and using source from https://github.com/intelequia/dnn.azureadb2cprovider/releases
Please help me out.
There was an issue in the DNN manifest file that has been solved on v1.4.7 (release https://github.com/intelequia/dnn.azureadb2cprovider/releases/tag/v1.4.7). Tracking the issue at https://github.com/intelequia/dnn.azureadb2cprovider/issues/19
I wrote the answer below before seeing this: https://github.com/intelequia/dnn.azureadb2cprovider/issues/19
Perhaps this is pertinent to your question. You might want to check with Ryan Moore (moorecreative" to see if he was able to resolve the issue.
First, please bear in mind that I am not familiar with this particular extension, but it seems as if it is "just another" authentication provide for DNN.
I'm also a little confused. The error message indicates that you've already installed th Intelequia AzureB2C provider. Is that true?
You also say "I am using" and then "trying to install it as an extension." If you are using it, that means that it is already installed as an extension, so a second attempt to install it should throw an error. But, I would think that the installer should see that problem earlier in the process.
Finally, you say "i am trying to use multiple version as well." A provider should be installed only once, and that is what the error message is telling you.
Once you have installed an authentication provider you typically enable it for a portal, and it becomes part of the authentication process.
You should read the documentation carefully, and make sure that you are trying to use the provider as the developer intended.
So before the question I wanna point out that the only thing I could find on this issue was on this stackoverflow question. This issue suggest that this was an issue with wappalyzer, and it was fixed in version 4.0.1. however I am using wappalyzer version 5.1.4 and is up to date with this.
I am building a web-app based on the MEAN-stack, everything worked as intended for a long time, until this error kept poping up in my google-chrome console:
Everytime i would click in my app header, and use my front-end routing to load up different components / modules this error appears, however I dont see any issue with what the web-app presents to me (it's not like I am missing data)
More details on the error:
I have no idea whats going on, or where this issue comes from.
This was due to a failing plugin.
Disable all plugins, and enable them one at a time to find failing chrome extensions.
In this case it was the wappalyzer extension.
I am running Xpage Application on Domino Server 8.5.3 FP1 Windows 64bit.
We are sending the bills(documents) around 2500 users. during testing ,this application works fine without any error. When we rollout the bills to user. All users are trying to open the application.
It is throwing the following error. But Application still works. At some point of time, Application gets slow and http hang. I have do restart of HTTP. Then it works fine.
I am not able to find the cause whether any error in the code or because number of users are accessing the application increases.
06/04/2014 10:58:53 AM HTTP JVM: CLFAD0211E: Exception thrown.
For more detailed information, please consult error-log-0.xml located in D:/Lotus/Domino/data/domino/workspace/logs
And sometimes this is also throwing ,
HTTP JVM: CLFAD0141E: Error processing XPage request. For more detailed information,
please consult error-log-0.xml located in D:/IBM/Lotus/Domino/data/domino/workspace/logs
Please help on this query.
You should start with what Paul suggests. If you haven't already downloaded and installed LogReader (by Jakob Majkilde), then you should. It is a database on your server that will read the various error file types and show them for you in an easy way. You can find it here: http://www.openntf.org/internal/home.nsf/project.xsp?action=openDocument&name=XPages%20Log%20File%20Reader
From these log files you will then have to look at where the system complains about problems. Did you write the code in Java or Serverside Javascript (SSJS)? You have options to debug both of these (although I cannot remember if you can debug SSJS in version 8.5.3 - it may not be available until version 9.0). But you could always add a println in the code near where you think it breaks ;-)
/John
At some point of time, Application gets slow and http hang. I have do restart of HTTP. Then it works fine.
As mentioned by Paul + John, no one is going to be able to give you an exact answer from the posted message.
As you mention the application gets slows and hangs, I would also recommend watching the XPages Masterclass.
It is approx 4 hours of videos, and goes into detail on how to debug your application for performance issues using the XPages Toolbox.
Again this isn't an exact solution. You will need to use the XPages toolbox to drill down on your code/JVM to see where it is slowing down/hanging.
Posting the stacks from the error-log-0.xml log file might give some hints, but with performance/hangs it's rarely that simple to find.
Now Application is working without issue. I have just included exception handling in all ssjs.
Now it is not throwing error.
Thanks for all your help and time.
In UrlMappings.groovy, I have set "500"(controller:'error', action:'error') so that my own error controller (and view) is used.
It usually works, however when I tried tampering with the request input (submitting a parameter with 1MB size), I got a Tomcat generated error page with HTTP Status 500.
First I thought this error was only generated by Tomcat so that grails couldn't do anything about it, but the Exception is an org.springframework.web.util.NestedServletException (nested Exception java.lang.StackOverflowError) and there are many org.codehaus.groovy.grails packaged Classes in the stack trace.
I think showing this Exception including stack trace to potential attackers is dangerous, so how I can I configure grails to always show my own error page? Or is it only possible to configure that in Tomcat?
It's possible that this is a Grails bug. I found this Nabble thread which directed me to this JIRA issue. That issue was resolved, but in the comments Peter Ledbrook linked to a different JIRA issue that may or may not be your problem.
If that does look like what's happening for you, there's a workaround suggested in the comments, which can be found here. The bug itself is scheduled to be fixed in 1.4; the fix workaround above is targeted for 1.3
Agreeing with Rob Hruska, having stumbled across most of his links myself.
I, too, suspect that the grails-error-pages-fix plugin ought to fix the issue - as the grailsWebRequest servlet by default doesn't have a <dispatcher>ERROR</dispatcher> assigned in web.xml.
The technique used with this plugin basically does the same as the technique that I'd suggested in a previous post. (Nevertheless, my own testings, as can be seen by my comments there, haven't led to consistent findings yet.)
Finally, one thing that would work at any rate is to implement a custom servlet Filter.
This happens when I try to deploy a Sharepoint WebPart solution. Is there a file or configuration option that I have missed that is causing this error to occur?
Thanks.
I assume that you're using VSeWSS 1.3 to deploy you solution and that these error occur when you try to deploy the solution. I'm not 100% sure but I think I had the same error some time ago. Unfortunately I could remember what I exactly did to solve this problem. But I'm quite sure the problem was related to some network issues as VSeWSS 1.3 uses web services to handle solutions.
So I would advise you to double check you network settings. For example you could try to adjust your hosts file so that your computer's name could be resolved.