I am having trouble with setting headers in the web console of Artemis. If I try to add a header field I can write the write in the header name and the value in the appearing text boxes, but if I press "Send message" nothing happens and an error is printed to the built-in error console.
[ARTEMIS] 123
[ARTEMIS] About to send headers: {"JMSPriority":"4"}
[ARTEMIS] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[Core] Operation sendMessage(java.util.Map, int, java.lang.String, boolean, java.lang.String, java.lang.String) failed due to: java.lang.IllegalStateException
This happens when I am trying to use predefined headers like "JMSPriority" aswell as custom header fields.
The funny thing is that I if set the header fields in a Java application I can use the predefined headers aswell as custom headers without any problems.
Is there a special way to add (custom) header fields to messages in the Artemis web console?
Apparently it was a server issue and it should be fixed in the last versions
The body must be base64 encoded:
Related
I am getting this error while using SOAP web service client with axis 1. I had created stub from the wsdl file and tried to consume it then I got this error. wsdl is given to me by someone else.
error in msg parsing: xml was empty, did't parse!
below is the error message and stack trace for the same. Anyone can help.?
In order to fix the javax.activation.DataHandler issue you must add the JavaBeans Activation Framework activation.jar in your classpath.
In order to fix the javax.mail.internet.mimeMultipart issue you must add the Java Mail API mail.jar in your classpath.
The warning messages printed in your console shows that the above jars are not in the classpath.
There are several common reasons to receive the message:
error in msg parsing: xml was empty, did't parse!
The most obvious is that no message was sent. If you have some way of inspecting your transport channel, that would be worth looking at.
Also, the xml message could have been sent in an unexpected character set, e.g. A header declares it to be "Utf-8" but it is really "Win-1252", sometimes you can get away with that if you only use 7-bit ASCII characters, but anything in the 8-bit plane will cause it to bomb.
Also, the xml message could have had a byte order mark unexpectedly inserted at the beginning of the message.
Also, the xml message might not have the document declaration ( starting in the first byte of the message, that violates the specification, and often causes parsers to puke and claim that no message was found.
All things considered with this error message, the parser was not able to find a valid xml message that it could parse, so it didn't. You need to grab the data on the transport channel and figure out what exactly is wrong to resolve the issue.
I need to send a binary message to Message Broker using the perl library Net::Stomp::Client. But whenever I send a message using the send or send_with_receipt methods, the message is received as a Text message.
I'm using ActiveMQ in my server, and when I call consume, the received message is of type TextMessage. I need it to be of type BytesMessage.
Update:
I see in this link that setting the content-length header will set the type to Bytes message... But I didn't find any example using Net::Stomp::Perl... If anyone can provide an example it would be great...
I solved this by adding bytes_message => 1 to the send() method
In newer versions you need to use stomp 1.1 or greater (default is 1.0) (pass version or accept_version to the stomp client constructor) and higher and set the content-type
I created my own “404 Page not found” error page on a TYPO3 website and implemented it via the /typo3conf/LocalConfiguration.php as follows, using the page’s Speaking URL path:
return [
...
'FE' => [
...
'pageNotFound_handling' => '/page-not-found/',
]
]
Now when I call a non-existing page, the error page gets displayed but there is a 4-digit alphanumeric number (hexadecimal as far as I’ve seen by now) BEFORE the HTML source code and a “0” AFTER it. Example (the number in the beginning is different after most of the reloads):
37b3
<!DOCTYPE html>
...
</html>
0
When calling the error page URL itself the page is returned correctly without those numbers.
Having the RealURL extension activated or deactivated does not make a difference.
Thanks a lot in advance!
I added the full description from the install tool and I guess we might find the solution there.
How TYPO3 should handle requests for non-existing/accessible pages.
empty (default)
The next visible page upwards in the page tree is shown.
'true' or '1'
An error message is shown.
String
Static HTML file to show (reads content and outputs with correct headers), e.g. notfound.html or http://www.example.org/errors/notfound.html.
Prefix "REDIRECT:"
If prefixed with "REDIRECT:" it will redirect to the URL/script after the prefix.
Prefix "READFILE:"
If prefixed with "READFILE" then it will expect the remaining string to be a HTML file which will be read and outputted directly after having the marker "###CURRENT_URL###" substituted with REQUEST_URI and ###REASON### with reason text, for example: READFILE:fileadmin/notfound.html.
Prefix "USER_FUNCTION:"
If prefixed with "USER_FUNCTION:" a user function is called, e.g. USER_FUNCTION:fileadmin/class.user_notfound.php:user_notFound->pageNotFound where the file must contain a class user_notFound with a method pageNotFound() inside with two parameters $param and $ref.
What you configured:
You're passing a string, thus TYPO3 expects to find a file - which you don't have, because it's more like an URL.
From what you try to achieve I'd go with REDIRECT:/page-not-found/.
Thanks for pointing this one out btw, I will remove the string configuration from the core since it does not make sense to have more people trip into this pitfall.
In short: change the following line in the FE section of your LocalConfiguration.php:
'pageNotFound_handling' => '/your404page.html',
to
'pageNotFound_handling' => 'REDIRECT:/your404page.html',
Cause
The actual cause is a combination of chunked Content-Encoding and the TYPO3 not being able to decode that in some cases. In your case the page not found handler eventually uses GeneralUtility::getUrl() to retrieve the error page.
If you have [SYS][curlUse] enabled it will use cUrl to retrieve the page and there is no problem.
If you don't have [SYS][curlUse] enabled it will open a socket, read the headers and then read the rest of the body. If the webserver uses "chunked" Content-Encoding the body will contain blocks of data and each block starts with a line with the length in hexadecimal format. The content ends with an empty block (with of course a line with the length "0").
cUrl apparently knows how to decode chunked data.
getUrl() itself does not know how to handle chunked data and uses the content as is as the page content.
In TYPO3 8 LTS the guzzle library is used to handle HTTP requests. In the guzzle code I can't find anything about handling chunked data. Guzzle will check if the cUrl PHP extension is present and use that as preferred transport. In most installations cUrl is present and since this decodes chunked data automagically no problem is visible. I have to test guzzle with PHP that has cUrl disabled to see if the issue is also present in v8/master.
Workaround/solution
If the PHP extension cUrl is enabled in your installation you can simply set [SYS][curlUse] in the Install Tool. The numbers around the 404 page content will disappear.
I need to disable quickfix validation.
Setting UseDataDictionary=N does not work.
Removing paths to dictionary files in the config file does not work.
Renaming xml files in the directory to some other extension does not work.
Still rejecting messages based on failed validation.
The directory is correct. Please help! I'm sure I am missing something trivial.
Thank you!
PS - in reply to some questions:
The error I am getting is: 58=Tag specified out of required order 371=143 372=8
Indeed, the client is sending tag 143 in the message body, not the header. The client will not change the code. I tried adding tag 143 to the ExecutionReport body, but that did not help. I am weary of taking tag 143 out of the header just for these guys.
PS - config file:
[DEFAULT]
ConnectionType=initiator
ReconnectInterval=60
FileStorePath=store
FileLogPath=log
StartTime=00:00:00
EndTime=00:00:00
UseDataDictionary=N
DataDictionary=/xxxxxx
TransportDataDictionary=/xxxxx
ResetOnLogon=N
DefaultApplVerID=9
[SESSION]
BeginString=FIX.4.4
SenderCompID=xxxxxx
TargetCompID=xxxxxx
SocketConnectHost=xxxxxxxxx
SocketConnectPort=52400
HeartBtInt=30
You can disable this specific check by setting the ValidateFieldsOutOfOrder parameter to N in your configuration file. See Configuring QuickFIX.
You have to have UseDataDictionary=Y if you have repeating groups, it tells QuickFIX how to handle items in repeated groups. "Tag specified out of required order 371=143 372=8" usually means that a header tag is in the message body, a body tag is in the header, a repeating group tag is in the body, a body tag is in a repeated group etc.. Since the client is sending tag 143 in the message body rather than the header you will need to edit the DataDictionary so that that tag appears in the message body instead of the header. Since you can set the DataDictionary on a per connection basis I would strongly recommend that you create a copy of the original dictionary, give it a client specific name and edit that file and then connect it to that connection keeping the original clean.
I need to update an order which is done via PUT method passing the order id as part of the https url string and a single parameter, the status_id.
https://mystore.mybigcommerce.com/orders/12345.json
I have tried several methods to pass the status_id value but no matter what I try "status_id=12" or formatted as JSON "{"status_id": 12,}" I always get the same response:
[{"status":415,"message":"The specified input content type is not valid."}]
I have also tried as a POST request passing the JSON or XML code as raw data but that method is not supported.
How am I supposed to pass that field=value pair? can I embed it in the url string?
I also tried it but it wouldn't work for me.
Any ideas?
In case you are wondering I am doing it within FileMaker with TROIUrl plugIn, not a very popular technology, but the GET method retrieving orders works like a charm
TURL_Put( ""; $url ;"status_id=12") (I have also tried other FM plugIns to no avail)
Don't get too caught up in the Filemaker part, I don't expect many people out there to be familiar with BigCommerce and Filemaker. I just need a generic answer.
Thanks
Commandline tool curl is worth a try. It supports put and https.
Mac OS X: curl already installed, call from FileMaker via AppleScript do shell script.
Windows: must be installed, call via Powershell.
It works for me using { "status_id": "3" } which means you probably need to put quotes around the actual number.
Also, it is a PUT operation and application/json which is part of the request content.
The error message received by the OP:
[{"status":415,"message":"The specified input content type is not valid."}]
Is saying that he did not supply the 'Content-Type' header in his request or that the header supplied is for a content type that is not allowed. For the OP's case using JSON he would need to include the header:
Content-Type: application/json
in his HTTPS request. This description can be found along with those of the other status codes you may see here:
https://developer.bigcommerce.com/api/status-codes