First of all thanks to Paul S Withers for his work:
https://openntf.org/main.nsf/project.xsp?r=project/XPages%20OpenLog%20Logger
I would like to use his logger (v8.0), but after some tests, I have to deal with one strange behaviour concerning the error document reference.
Here an example:
After logging an error or event including a doc reference e.g.:
OpenLogUtil.logEvent(new Throwable(), "This is a Java message with Doc", Level.INFO, doc);
all following logging calls - without an explicit doc parameter - now referencing the document of the prior call, e.g.:
openLogBean.addError(e, this);
OpenLogUtil.logError(e);
etc...
OpenLog Database - Entries:
UPDATE:
If you are logging from two different databases, the logging will crash with the following exceptions:
HTTP JVM: XOL_DEBUG error: Notes error 4091: Invalid universal id
HTTP JVM: XOL_DEBUG error trace: NotesException: Invalid universal id
HTTP JVM: XOL_DEBUG error trace: NotesException: Object has been removed or recycled
Thanks in advance for any help
Mea culpa, it's re-using the same OpenLogItem. I suspect, because it's scoped to the session, the 4091 error will occur. Please try this version https://openntf.org/main.nsf/project.xsp?r=project/XPages%20OpenLog%20Logger/releases/94080D45393E3DC88525835100495C88
Related
I am using strongloop 4 (lb4). I am facing one issue that in error object I need to one more custom parameter in the error object.
I want it on the global level. On every error, I want to add that custom parameter in every error message.
In loopback4 global error handling is done by src/sequence.ts.
Suppose the error message object is.
{
"error": {
"statusCode": 400,
"name": "xyz",
"message": "firstName is required"
}
}
I want error object output like.
{
"error": {
"customParam" : "customParam",
"statusCode": 400,
"name": "xyz",
"message": "firstName is required"
}
}
Cross-posting the answer I gave on GitHub in https://github.com/strongloop/loopback-next/issues/1867#issuecomment-434247807
Building HTTP error responses is a tricky business. It's easy to get it wrong and open your application to attacks.
In LoopBack (both 3.x and 4.x), we use our strong-error-handler middleware to take care of this. See Handling Errors in our docs.
Here are the important security constraints to keep in mind:
In production mode, strong-error-handler omits details from error responses to prevent leaking sensitive information:
For 5xx errors, the output contains only the status code and the status name from the HTTP specification.
For 4xx errors, the output contains the full error message (error.message) and the contents of the details property (error.details) that ValidationError typically uses to provide machine-readable details about validation problems. It also includes error.code to allow a machine-readable error code to be passed through which could be used, for example, for translation.
In debug mode, strong-error-handler returns full error stack traces and internal details of any error objects to the client in the HTTP responses.
Now that I have warned you, LoopBack 4 makes it very easy to format the error messages your way. Just provide a custom implementation of the Sequence action reject. See Customizing Sequence Actions in our docs, it explain how to create a custom send action. The solution for reject is pretty much the same, you just need a different signature for the action function.
export class CustomRejectProvider implements Provider<Reject> {
// ...
action({request, response}: HandlerContext, error: Error) {
// handle the error and send back the error response
// "response" is an Express Response object
}
}
Caveat: some errors thrown by LB4 have only code set, these errors need a bit of pre-processing to decide what HTTP status code they should trigger. (For example, the error code ENTITY_NOT_FOUND should be mapped to the status code 404). The built-in reject action does not yet expose this pre-processing for consumption by custom reject actions. It's an oversight on our side, l created a new issue https://github.com/strongloop/loopback-next/issues/1942 to keep track of that.
I tried adding error object into new object.
let error = new Error();
error.name = 'Invalid_OTP_AttemptsError';
error.status = 422;
error.message = 'You’ve exceeded the maximum number of One-Time Password (OTP) attempts';
let data={...error};
data.retryCount=foundMb.retryCount
data.resendCount=foundMb.resendCount
return callback(null,data);
Hi i am doing simple POC in mule.
I have a web service and i want to make it's Client.
It is SOAP web service and i want to send request to it but i am not getting wayout. Please give me some idea.
Following is code:
MULE:
<cxf:configuration name="CXF_Configuration" enableMuleSoapHeaders="true" initializeStaticBusInstance="true" doc:name="CXF Configuration"/>
<flow name="prjvm1" doc:name="prjvm1">
<http:inbound-endpoint address="http://localhost:5678/httpHello" contentType="application/x-www-form-urlencoded" doc:name="HTTP">
<http:body-to-parameter-map-transformer />
</http:inbound-endpoint>
<!-- This logger is just set to show the message accepted from the request -->
<logger level="INFO" message="#[payload]" doc:name="Logger"/>
<cxf:jaxws-client doc:name="VimService"
wsdlLocation="file:/C:/Users/gugla/MuleStudio/workspace/prjvm/bin/service/vService.wsdl"
operation="retrieveServiceContent"
clientClass="com.esxclient.VService"
port="VimPort">
<cxf:jaxb-databinding/>
</cxf:jaxws-client>
<outbound-endpoint address="http://localhost:8080/gep-sped/servicos/ServicoDeCadastroEAgendamento"
doc:name="Generic"
exchange-pattern="request-response"/>
<echo-component doc:name="Echo"/>
</flow>
I am getting exception, but operation is there in WSDL
Message : No such operation: retrieveServiceContent. Failed to route event via endpoint: org.mule.module.cxf.CxfOutboundMessageProcessor. Message payload is of type: ManagedObjectReference
Code : MULE_ERROR--2
--------------------------------------------------------------------------------
Exception stack is:
1. No such operation: retrieveServiceContent (java.lang.Exception)
org.mule.module.cxf.CxfOutboundMessageProcessor:282 (null)
2. No such operation: retrieveServiceContent. Failed to route event via endpoint: org.mule.module.cxf.CxfOutboundMessageProcessor. Message payload is of type: ManagedObjectReference (org.mule.api.transport.DispatchException)
org.mule.module.cxf.CxfOutboundMessageProcessor:150 (http://www.mulesoft.org/docs/site/current3/apidocs/org/mule/api/transport/DispatchException.html)
--------------------------------------------------------------------------------
Root Exception stack trace:
java.lang.Exception: No such operation: retrieveServiceContent
at org.mule.module.cxf.CxfOutboundMessageProcessor.getOperation(CxfOutboundMessageProcessor.java:282)
at org.mule.module.cxf.CxfOutboundMessageProcessor.getMethodFromOperation(CxfOutboundMessageProcessor.java:322)
at org.mule.module.cxf.CxfOutboundMessageProcessor.getMethod(CxfOutboundMessageProcessor.java:259)
+ 3 more (set debug level logging or '-Dmule.verbose.exceptions=true' for everything)
Following is WSDL in operation: I am confused and around 4 days on it as i am new to mule.
<operation name="RetrieveServiceContent">
<input message="vim2:RetrieveServiceContentRequestMsg" />
<output message="vim2:RetrieveServiceContentResponseMsg" />
<fault name="RuntimeFault" message="vim2:RuntimeFaultFaultMsg"/>
</operation>
There are a couple of ways to do this. I prefer to NOT us the way MuleStudio wants you to do it since I never really got that to work. Basically, whenever I create a webservice client my mule-config looks something like this:
<custom-transformer class="nl.thorax.someprogram.transformers.SomeRequestTransformer
<https:outbound-endpoint ref="someEndpoint" >
<cxf:jaxws-client
clientClass="nl.thorax.someprogram.someclass"
wsdlLocation="http://somedomain?wsdl
port="somePort"
operation="someOperation"/>
</https:outbound-endpoint>
<custom-transformer class="nl.thorax.someprogram.transformers.SomeResponseTransformer
Where:
SomeRequestTransformer: a transformer to create your request.
someEndpoint: some endpoint defined in your MuleConfig. In my example, this is https but it could also be plain http.
someclass: Important! This is your client class. It can be generated from a WSDL by free tools like Apache's WSDL2Java. Google is your friend on this.
somePort: The port in your webservice to use. It can usually be found in the WSDL itself or in the client class you generated. The port more or less specifies what operations you can use.
someOperation: The operation you want to use. Make sure it is typed EXACTLY the same as it's definition in the client class. Wrong use of cApItAlS will cause errors!
SomeResponseTransformer: a transformer to do something with your response.
Now, the way I configure the call (and parse the response for that matter) is to use POJOs. My first transformer, the SomeRequestTransformer (based on the AbstractMessageTransformer in the Mule library) has a bit of code looking like this:
public Object transformMessage(MuleMessage message, String outputEncoding) throws TransformerException
{
RequestObject request = new RequestObject();
request.setText("Hello!");
message.setPayload(request);
return message;
}
I create the request, set the variables and return it to Mule. The RequestObject is a class generated by WSDL2Java and corresponds to some operation in the WSDL. Parsing the response works pretty much the same way.
Now I know from experience that a lot of webservices do not quite work in the same way. Try to implement my example yourself. If that doesn't work, please provide your Mule-Config and any and all Java classes you may be using.
EDIT:
I've created an example of my method that actually works. The files can be downloaded at our website. Please see the comments in the files. You have to manually create the Mule project, of course.
Points of note for the example:
The XML-representation of the Mule-config can be found in the 'resources' folder in the archive.
The 'nl.example.example' folder contains all the generated JAX-WS files.
The WSDL location in Mule-config has to be changed since it contains an absolute path.
The example creates an endpoint at http://localhost:8088 for you to call. The flow contains a transformer which creates an example call using pre-defined parameters. Then it tries to connect to the webservice. I've used the default address used by SOAPUI when you create a mock service, but this could of course be changed into anything you want. The webservice (supposedly) returns something which is echoed into the user's browser.
In this example, the parameters are actually Strings, since the WSDL-request doesn't contain anything. To figure out what object to pass to the cxf:jaxws-client look at the operation definition which can be found in the Port definition in your generated files.
I am trying to implement Paul Calhoun's Apache FOP solution for creating PDF's from Xpages (from Notes In 9 #102). I am getting the following java exception when trying to run the xAgent that does the processing --> Can't get a Writer while an OutputStream is already in use
The only changes that I have done from Paul's code was to change the package name. I have isolated when the exception happens to the SSJS line: var jce: DominoXMLFO2PDF = new DominoXMLFO2PDF(); All that line does is instantiate the class, there is no custom constructor. I don't believe it is the code itself, but some configuration issue. The SSJS code is in the beforeRenderResponse event where it should be, I haven't changed anything on the xAgent.
I have copied the jar files from Paul's sample database to mine, I have verified that the build paths are the same between the two databases. Everything compiles fine (after I did all this.) This exception appears to be an xpages only exception.
Here's what's really going on with this error:
XPages are essentially servlets... everything that happens in an XPage is just layers on top of a servlet engine. There are basically two types of data that a servlet can send back to whatever is initiating the connection (e.g. a browser): text and binary.
An ordinary XPage sends text -- specifically, HTML. Some xAgents also send text, such as JSON or XML. In any of these scenarios, however, Domino uses a Java Writer to send the response content, because Writers are optimized for sending Character data.
When we need to send binary content, we use an OutputStream instead, because streams are optimized for sending generic byte data. So if we're sending PDF, DOC/XLS/PPT, images, etc., we need to use a stream, because we're sending binary data, not text.
The catch (as you'll soon see, that's a pun) is that we can only use one per response.
Once any HTTP client is told what the content type of a response is, it makes assumptions about how to process that content. So if you tell it to expect application/pdf, it's expecting to only receive binary data. Conversely, if you tell it to expect application/json, it's expecting to only receive character data. If the response includes any data that doesn't match the promised content type, that nearly always invalidates the entire response.
So Domino in its infinite wisdom protects us from making this mistake by only allowing us to send one or the other in a single request, and throws an exception if we disobey that rule.
Unfortunately... if there's any exception in our code when we're trying to send binary content, Domino wants to report that to the consumer... which tries to invoke the output writer to send HTML reporting that something went wrong. Except we already got a handle on the output stream, so Domino isn't allowed to get a handle on the output writer, because that would violate its own rule against only using one per response. This, in turn, throws the exception you reported, masking the exception that actually caused the problem (in your case, probably a ClassNotFoundException).
So how do we make sure that we see the real problem, and not this misdirection? We try:
try {
/*
* Move all your existing code here...
*/
} catch (e) {
print("Error generating dynamic PDF: " + e.toString());
} finally {
facesContext.responseComplete();
}
There are two reasons this is a preferred approach:
If something goes wrong with our code, we don't let Domino throw an exception about it. Instead, we log it (instead of using print to send it to the console and log, you could also toss it to OpenLog, or whatever your preferred logging mechanism happens to be). This means that Domino doesn't try to report the error to the user, because we've promised that we already reported it to ourselves.
By moving the crucial facesContext.responseComplete() call (which is what ultimately tells Domino not to send any content of its own) to the finally block, this ensures it will get executed. If we left it inside the try block, it would get skipped if an exception occurs, because we'd skip straight to the catch... so even though Domino isn't reporting our exception because we caught it, it still tries to invoke the response writer because we didn't tell it not to.
If you follow the above pattern, and something's wrong with your code, then the browser will receive an incomplete or corrupt file, but the log will tell you what went wrong, rather than reporting an error that has nothing to do with the root cause of the problem.
I almost deleted this question, but decided to answer it myself since there is very little out on google when you search for the exception.
The issue was in the xAgent, there is a line importPackage that was incorrect. Fixing this made everything work. The exception verbage: "Can't get a Writer while an OutputStream is already in use" is quite misleading. I don't know what else triggers this exception, but an alternative description would be "Java class ??yourClass?? not found"
If you found this question, then you likely have the same issue. I would ignore what the exception actually says, and check your package statements throughout your application. The java code will error on its own, but your SSJS that references the java will not error until runtime, focus on that code.
Update the response header after the body can solve this kind of problem, example :
HttpServletResponse response = (HttpServletResponse) facesContext.getExternalContext().getResponse();
response.getWriter().write("<html><body>...</body></html>");
response.setContentType("text/html");
response.setHeader("Cache-Control", "no-cache");
response.setCharacterEncoding("UTF-8");
I'm trying to generate a custom error page for my xpages. I googled a lot of solutions and so far I get an error page telling me, that an error occured.
But I can't get the information what exactly happened (in this case the error is, that an "doc" has to be saved, but i named the variable "docs" just to get error).
All I do is:
var errObj = requestScope.error;
output = errObj.getCause().getErrorPropertyId();
output = errObj.getCause().getComponentId();
As soon as I try to call getExpressionText() I get an error 500.
How do I get the information, where the error happened (line number) and the variable that caused the error? - just like I do using the standard error page.
The error line and details are not easily accessible from requestScope.error. If you look at the source code for the latest release of Mark Leusink's Debug Toolbar, you'll see he's parsing the stack trace to get the details.
However, you can access all the relevant information using the underlying Java class for the SSJS exception - com.ibm.jscript.InterpretException using getErrorLine(). The getLocalizedMessage() method gets the error detail that usually starts "Script interpreter error". The getExpressionText() method retrieves the line that threw the error.
If you take a look at the XPages OpenLog Logger project I put on OpenNTF, that's what I use to log full details to OpenLog. http://www.openntf.org/Internal/home.nsf/project.xsp?action=openDocument&name=XPages%20OpenLog%20Logger
You can see the source code of the OpenLogPhaseListener which uses those methods here: https://github.com/paulswithers/openlogjava/blob/master/OpenLogJava/WebContent/WEB-INF/src/com/paulwithers/openLog/OpenLogPhaseListener.java
Even if you're not a Java expert, from use of SSJS the key parts should be understandable. Line 84 captures uncaught exceptions - when XPages routes to the default error page. That uses the methods I mentioned.
Lines 98 to 105 are the ones that log out all the details if you just use a catch block, passing OpenLogBean.addError(e, this) where e is the error object and this is the component the error occurs on. error.getError() in the Java code retrieves that error object. To get the typeahead in SSJS you'll need to use catch(e:com.ibm.jscript.InterpretException) I believe.
I haven't tested this, I've just working back from what I used for the project on OpenNTF.
Have a look at this XSnippet by Tony McGuckin: http://openntf.org/XSnippets.nsf/snippet.xsp?id=custom-error-page-cw-cause-and-stacktrace-information. It uses the following to output details on the error:
var output = requestScope.error.toString()+"\n\n";
if(requestScope.error instanceof com.ibm.xsp.exception.XSPExceptionInfo){
var codeSnippet = requestScope.error.getErrorText();
var control = requestScope.error.getErrorComponentId();
var cause = requestScope.error.getCause();
output += "In the control : " + control + "\n\n";
if(cause instanceof com.ibm.jscript.InterpretException){
var errorLine = cause.getErrorLine();
var errorColumn = cause.getErrorCol();
output += "At line " + errorLine;
output += ", column " + errorColumn + " of:\n";
}else{
output += "In the script:\n";
}
output += codeSnippet;
}
return output;
For now I've dealt with this problem by using the Debug Toolbar and the OpenLog Database.
If an error occurs the user only gets a custom error page (using the example of the Debug Toolbar) with the information, that something went wrong. So he does not have to bother with any other problems or even the Stack Trace. But at the same moment he gets the error page, the error is logged in our Log-Database with all informations needed (like line, exact error message etc.).
I've also implemented an "Report this problem" Link-Button to create a new E-Mail containing important information about the session the user is currently in.
We have one very old legacy application written on Classic ASP. Recently on a couple of servers we've started to get fatal errors. IIS process crashes. We've got few error's stack traces with IIS Debug Tool. There is 2 common types of errors.
We are using only few types of COM components in our application: ADO, Scripting.Dictionary, Scripting.FileSystem & MSXML6.
IIS logs says that error description is access violation exception (0xC0000005).
Do you have any ideas about the reason of errors or any ways for future debugging. Any ways to get more info about this errors will be very appreciated.
Thanks.
Stack traces:
1.
1996e18
oleaut32!VariantCopy+173
oleaut32!SafeArrayCopyData+14e
oleaut32!SafeArrayCopy+e3
oleaut32!VariantCopy+5b
oleaut32!VariantCopyInd+1a1
asp!CComponentObject::GetVariant+27
asp!CApplnVariants::get_Item+da
oleaut32!DispCallFunc+16a
oleaut32!CTypeInfo2::Invoke+234
asp!CDispatchImpl<IVariantDictionary>::Invoke+55
oleaut32!CTypeInfo2::Invoke+58a
asp!CDispatchImpl<IApplicationObject>::Invoke+55
vbscript!IDispatchInvoke2+b2
vbscript!IDispatchInvoke+59
vbscript!InvokeDispatch+13a
vbscript!InvokeByName+42
vbscript!CScriptRuntime::RunNoEH+22b2
vbscript!CScriptRuntime::Run+62
vbscript!CScriptEntryPoint::Call+51
vbscript!CSession::Execute+c8
vbscript!COleScript::ExecutePendingScripts+144
vbscript!COleScript::SetScriptState+14d
asp!CActiveScriptEngine::TryCall+19
asp!CActiveScriptEngine::Call+31
asp!CallScriptFunctionOfEngine+5b
asp!ExecuteRequest+17e
asp!Execute+24c
asp!CHitObj::ExecuteChildRequest+12c
asp!CErrInfo::LogCustomErrortoBrowser+28a
asp!CErrInfo::LogErrortoBrowserWrapper+8b
asp!CErrInfo::LogError+77
asp!HandleError+100
asp!HandleErrorMissingFilename+ac
asp!CActiveScriptEngine::Call+a7
asp!CallScriptFunctionOfEngine+5b
asp!ExecuteRequest+17e
asp!Execute+24c
asp!CHitObj::ViperAsyncCallback+3f0
asp!CViperAsyncRequest::OnCall+92
comsvcs!CSTAActivityWork::STAActivityWorkHelper+32
ole32!EnterForCallback+c4
ole32!SwitchForCallback+1a3
ole32!PerformCallback+54
ole32!CObjectContext::InternalContextCallback+159
ole32!CObjectContext::DoCallback+1c
comsvcs!CSTAActivityWork::DoWork+12d
comsvcs!CSTAThread::DoWork+18
comsvcs!CSTAThread::ProcessQueueWork+37
comsvcs!CSTAThread::WorkerLoop+190
msvcrt!_endthreadex+a3
kernel32!BaseThreadStart+34
2.
scrrun!FreeList+f
scrrun!VBADictionary::~VBADictionary+28
scrrun!VBADictionary::`scalar deleting destructor'+d
scrrun!VBADictionary::Release+17
oleaut32!VariantClear+b1
oleaut32!ReleaseResources+98
oleaut32!_SafeArrayDestroyData+4d
oleaut32!_SafeArrayDestroy+b3
oleaut32!SafeArrayDestroy+f
oleaut32!VariantClear+75
vbscript!VAR::Clear+a6
vbscript!CScriptRuntime::Cleanup+63
vbscript!CScriptRuntime::Run+8d
vbscript!CScriptEntryPoint::Call+51
vbscript!CScriptRuntime::RunNoEH+1e02
vbscript!CScriptRuntime::Run+62
vbscript!CScriptEntryPoint::Call+51
vbscript!CScriptRuntime::RunNoEH+1e02
vbscript!CScriptRuntime::Run+62
vbscript!CScriptEntryPoint::Call+51
vbscript!CScriptRuntime::RunNoEH+1e02
vbscript!CScriptRuntime::Run+62
vbscript!CScriptEntryPoint::Call+51
vbscript!CScriptRuntime::RunNoEH+1e02
vbscript!CScriptRuntime::Run+62
vbscript!CScriptEntryPoint::Call+51
vbscript!CSession::Execute+c8
vbscript!COleScript::ExecutePendingScripts+144
vbscript!COleScript::SetScriptState+14d
asp!CActiveScriptEngine::TryCall+19
asp!CActiveScriptEngine::Call+31
asp!CallScriptFunctionOfEngine+5b
asp!ExecuteRequest+17e
asp!Execute+24c
asp!CHitObj::ViperAsyncCallback+3f0
asp!CViperAsyncRequest::OnCall+92
comsvcs!CSTAActivityWork::STAActivityWorkHelper+32
ole32!EnterForCallback+c4
ole32!SwitchForCallback+1a3
ole32!PerformCallback+54
ole32!CObjectContext::InternalContextCallback+159
ole32!CObjectContext::DoCallback+1c
comsvcs!CSTAActivityWork::DoWork+12d
comsvcs!CSTAThread::DoWork+18
comsvcs!CSTAThread::ProcessQueueWork+37
comsvcs!CSTAThread::WorkerLoop+190
msvcrt!_endthreadex+a3
kernel32!BaseThreadStart+34
We had very similar situation last couple weeks. It was very complicated to track down this issue. The problem is in OnError handler of VB6 code. There are 2 cases to reproduce:
you do not have OnError handler, error occurs and goes directly to
IIS
error occurs in OnError handler and goes directly to IIS.
After ~100 such errors IIS will fail to work normally. It will be absolutely unpredictable behavior after this moment.