I wrote some Perl program that uses $ldap->schema to get the server's schema.
So far the servers used returned a schema.
However I have one server does returns just undef, so I tried passing some dn => 'CN=Schema,CN=Configuration,...' to schema().
Unfortunately I still get an undef result.
Trying to get the schema using ldapsearch, I see an error message from the server like:
text: 000004DC: LdapErr: DSID-0C090A71, comment: In order to perform this operation a successful bind must be completed on the connection., ...
I'd like to get the server's error message from the $ldap->schema method.
How can I do that using the 0.44 version of Net::LDAP (I know it's a bit old meanwhile)?
It doesn't report any details. But you could trace through it with the debugger, or make a copy of it and add debugging statements.
Related
I'm trying to get a history report for a repository connection over ManifoldCF REST API. According to the documentation:
https://manifoldcf.apache.org/release/release-2.11/en_US/programmatic-operation.html#History+query+parameters
It should be possible with the following URL (connection name: myConnection):
http://localhost:8345/mcf-api-service/json/repositoryconnectionhistory/myConnection
I have also tried to use some of the history query parameters:
http://localhost:8345/mcf-api-service/json/repositoryconnectionhistory/myConnection?report=simple
But I am not sure if I am using them correctly or how they should be attached to the URL, because it is not mentioned in the documentation.
The problem is also that I don't receive any error, but an empty object, so it is difficult to debug. The API returns an empty object even for a non-existing connection.
However it works for resources, which doesn't have any attributes, e.g.:
http://localhost:8345/mcf-api-service/json/repositoryconnectionjobs/myConnection
or
http://localhost:8345/mcf-api-service/json/repositoryconnections/myConnection
Thanks in advace for any help.
I also wrote a message to ManifoldCF team and they gave me an answer. So I summed up it for you below.
Query parameters go after the fixed "path" part of the URL and are of the form ?parameter=value¶meter2=value2...
So in the same way as in any other URL.
The problem was that I didn't supply the activity(s) that I wanted to match. Possible activities are e.g. fetch, process. My example:
http://localhost:8345/mcf-api-service/json/repositoryconnectionhistory/myConnection?activity=process&activity=fetch
Finally, the reason why I didn't get an error when I used a connection name that is bogus is because the underlying implementation is merely doing a dumb query and not checking for the legality/existence of the connection name.
Fairly new to Mirth, so looking for advice in regards to debugging/getting more information from errors reported in the Server Log in Mirth Connect. I know what channel this is originating from, but that's about it. This error is received 10 times for each message coming through. It should be noted that the channel is working properly except for this error cluttering up the logs.
The Error:
ERROR (transformer:?): TypeError: undefined is not an xml object.
What I've Tried:
Ruled out Channel Map variables (mappers), they don't have null default values, they match up with vars in the incoming xml message, even changed to Javascript transformers to modify the catch to try to narrow down the issue, but no luck.
Modified external javascript source files to include more error handling (wrapped each file in a try/catch that would log with identifying info) but this didn't change the result at all.
Added a new Alert to send info if errors are received, but this alert never fired.
Anything else to try? Thanks for any/all help!
This is a Rhino message that happens when you use an e4x operator on a variable that isn't an xml object. The following two samples will both throw the same error you are seeing when obj is undefined. Otherwise, 'undefined' in your error will be replaced with obj.toString();
// Putting a dot between the variable and () indicates an xml filter
// instead of a function call
obj.('test');
// Two consecutive dots returns all xml descendant elements of obj
// named test instead of retrieving a property named test from obj.
obj..test;
To delete an existing module the documentation (http://cumulocity.com/guides/reference/real-time-statements/) says to do a DELETE request against /cep/module/<<moduleId>>. But this results in a response status 500 with the reason that "Request method 'DELETE' not supported".
What is the correct request to delete a single module?
The documentation gives the wrong path. It needs to be /cep/modules/<<moduleId>> instead of /cep/module/<<moduleId>>. This can be seen by debugging the behaviour of the web-GUI.
I am building a mailout capability and it is working OK as far as it goes. However, I want to distinguish between various potential (high level) outcomes in order to determine what happens to each message after the current send attempt.
This must be a common requirement so I seem to be missing something pretty obvious, but I can't find anything that addresses it, either here or via Google or on PHPMailer site or .. . Possibly because there are so many questions about specific errors that I just can't find anything useful in all the other results.
At very high level:
Attempt send, and assess resulting error/result. Identify whether this message has been sent, must be retried later, or failed permanently.
- success -> update message status as 'SENT: OK'
- sent, but some issues (e.g. one recipient failed, others processed OK)-> 'SENT: some error'
- failed, due to temporary problem (e.g. connection problem, attachment open) -> 'TRY LATER'
- failed, due to message-specific problem that we should NOT try to resend-> 'FAILED: some error'
As I was unable to find an existing resource with e.g. a table of errors, I spent some time working through the phpmailerException code to try to build one myself, but it's not simple because a) they don't appear to have been designed in terms of this kind of grouping logic, b) it is not easy to uniquely identify a particular error: PHPMailer provides human-friendly messages, which are different in different languages, rather than an identifiable code - given that my solution will need to work across different language installations that's a problem!
Obviously SMTP itself provides a range of errorcodes which I could potentially use for this purpose, but how do I access these via PHPMailer? (This would work for me as I only use SMTP at this point - however, this would NOT work if other message transport like sendmail was used, so I would prefer a PHPMailer solution)
If you want individual result codes for individual address, you really need to send each message separately. If you do get errors on some recipients, they will be listed in the ErrorInfo property - look in the smtpSend function to see how the error string is assembled. I agree that it's not especially easy to parse that info out. The error messages in PHPMailer are generally more for the developer than the end user, so the translations are not that significant. You can get slightly more information about errors if you enable exceptions rather than relying only on return values.
We're using a $server = SOAP::Transport::HTTP::Apache->new; $server->dispatch_with(...) over here as a backend to a JS-based application. Should the underlying module die, it sends back a nice error message that gets displayed by the JS code.
The problem is, I would like more detailed messages (e.g. Carp::longmess), and a hard copy of those on STDERR.
How can I inject a custom exception handler into SOAP::Transport::HTTP::Apache with minimal code modifications?
(This is a large and old project we can't afford to rewrite, though honestly it deserves a rewrite).
UPDATE: here's a sample error message:
<soap:Body><soap:Fault>
<faultcode>soap:Server</faultcode><faultstring>Column
'allocation' cannot be null at
/usr/local/lib/perl5/site_perl/5.8.8/Tangram/Storage.pm
line 686. </faultstring></soap:Fault></soap:Body>
I get a Tangram error but this is unlikely a bug in Tangram and anyway I need a full stack-trace. OTOH, the die message got into a SOAP message which is not a normal die action so there's a handler somewhere -- which I want to customize a bit.
The error handler is located under SOAP::Transport::HTTP::Server::_output_soap_fault. Try a grep on <faultcode> in the perl INC paths.