In reading the Jax-RS spec it's not clear to me how a #HeaderParam automatic conversion for the Java primitive boolean would be handled in the event the incoming string can not be converted to "true" or "false". e.g. if a value of "xxx" is passed would a Bad Request exception be thrown ?
The Jax-RS implementation I'm working with seems to never throw an exception but rather converts an "xxx" string to boolean value of false.
Related
The Go template Sprig function kindIs is used to test the type of a value:
kindIs "string" "hello" returns true.
What if the string is actually "true", not the boolean true. Is there a special character or any other mean?
(I can add a space after: "true " but it's not exactly a solution).
Should have put more background in the question: this came about when executing a Bake stage in a Spinnaker pipeline, with Key Overrides. One key (let's call it my-key) was overridden with value true . Bake stage failed at execution. Reproduced the error by doing a helm template command with --set my-key=true, outside spinnaker. The error had to do with kindIs checking for string but getting boolean (true). Changing to "true" didn't help.
Solution was to use helm option --set-string instead of --set.
My Spinnaker pipeline had the Raw Overrides checked hence the Overrides were done with --set iso --set-string.
Here's the Help pop up for Raw Overrides:
Use --set instead of --set-string when injecting override values. Values injected using --set will be converted to primitive types by Helm.
Just had to remove the Raw Override.
I need to create a validator for JSON input and I want to try to defer Exception to be thrown as late as I could. Many Exceptions can be disable by DeserializationFeature like READ_UNKNOWN_ENUM_VALUES_AS_NULL. For other Exceptions, I am thinking if I could use DeserializationProblemHandler to catch all of them so that I have same place to write logic for all fields.
However, the handler is not able to catch all kind of invalid string. Like I want to convert a string to a list. Handler can find "12" is unexpected token but it will not work for string like "" or "foo" or "{".
Is there any way to set some rule like conversion failure using fall back null for all fields? Then I can use the returned object to collect error type of all fields.
I have a wcf service having the following operation:
public NewPCNResponse CreateNewPcnExtended(NewPcnExtendedData newPcnExtendedData, string chargeBand, string deviceId, decimal? usageCharge, string plateType)
Note the camel cased parameter chargeBand. The problem is with all the camel cased parameters but I am taking this one for demonstration.
I am using SoapUi to test the calls and the following is the relevant part of the SOAP request:
The element is camel cased and even though it is nullable, it comes thorough as an empty string as shown in the following screenshot:
this fails the validation which I have down the line.
However if the argument is pascal cased, it comes through fine
The easier solution for me to change the casing but I want to know the reason behind this odd behaviour and if I want to keep the argument camel cased what option do I have.
My WCF service fails to deserialize an XML response. I get an error stating that 'String was not recognized as a valid DateTime.'
I see in the stack trace that the code fails on
System.DateTime.ParseExact(String s, String[] formats, IFormatProvider provider, DateTimeStyles style) +6364410
System.Xml.Serialization.XmlCustomFormatter.ToDate(String value) +58
Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderINgiReportingMgmnt.Read50_TransactionItem_Type(Boolean isNullable, Boolean checkType) +629
Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderINgiReportingMgmnt.Read105_transactionDetailRs() +1261
Microsoft.Xml.Serialization.GeneratedAssembly.ArrayOfObjectSerializer54.Deserialize(XmlSerializationReader reader) +43
System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader xmlReader, String encodingStyle, XmlDeserializationEvents events) +579
How do I figure out which Datetime format WCF is using? And how do I change the format? I can't control what format I get the dates in.
PS: The date in the XML is "2010-01-03T11:59:59". This deserializes fine using a normal DateTime.Parse.
Turns out the exact format did not matter. The problem was that the wsdl (the xsd specifically) specified that the value is an xsd:date. But since the value had time as part of the string the deserializer threw an exception.
So the problem was with incorrect data. I asked that the XSD be changed.
I have a WCF service I use to submit bugs for my project. Snippet of the data class:
Private _exception As Exception
<DataMember()> _
Public Property Exception As Exception
Get
Return _exception
End Get
Set(ByVal value As Exception)
_exception = value
End Set
End Property
I have a Silverlight app that uses the WCF service to send any bugs home if and when they occur. This is the error I'm testing with:
Dim i As Integer = 5
i = i / 0
The problem is SL is banging on with this message:
System.ServiceModel.CommunicationException was unhandled by user code
Message=There was an error while trying to serialize parameter :bug. The InnerException message was 'Type 'System.OverflowException' with data contract name 'OverflowException:http://schemas.datacontract.org/2004/07/System' is not expected. Add any types not known statically to the list of known types - for example, by using the KnownTypeAttribute attribute or by adding them to the list of known types passed to DataContractSerializer.'. Please see InnerException for more details.
Is there some trick to get a generic .NET Exception (any InnerException) to serialize properly? I'm not doing anything funky with the exception - it's just a plain 'ol exception
Thanks for any help.
I doubt very much that you can serialize a .NET-specific type like an Exception. I recommend you create your own class to hold the parts of the exception you want serialized.
This may be a problem with implicitly casting the OverflowException into a System.Exception.
The data contract serializer is very specific. This can be good and bad.
I would try just throwing a new System.Exception to see if this works OK.
If this is the case, you may need to dumb down the exception, creating a new System.Exception with the original exception message in it.
Or, like John said, you might have a better go of it if you create a custom error class that holds the exception info.