For serial name Duration there already exist DurationSerializer / Serializer has not been found for type 'Duration' - kotlinx.serialization

Up until now, I had been using the following libraries:
kotlin("jvm")
kotlin("plugin.serialization") version "1.7.10"
implementation("org.jetbrains.kotlinx:kotlinx-serialization-json:1.3.2")
Since until now, there is no serializer for the type kotlin.time.Duration, I had my own custom serializer. So far so good.
Now I want to update the kotlinx serialization libraries to 1.4.0, which has a DurationSerializer.
When I do this, the compiler naturally protests the following:
Caused by: java.lang.IllegalArgumentException: The name of serial descriptor should uniquely identify associated serializer. For serial name Duration there already exist DurationSerializer.
So I delete my custom DurationSerializer in order to use the new one included in the library, clean and attempt to recompile. However, when I do that, the following happens:
Serializer has not been found for type 'Duration'. To use context serializer as fallback, explicitly annotate type or property with #Contextual
Basically, the new library version can tell that my custome DurationSerializer is conflicting with its own, but then can't actually use its own. How do I get around this?

Got the answer from the kotlinx.serialization github repository here.
Turns out the library version of the serializer will only be added in a future compiler update.
In the meantime, our serial name for the custom serializer was too similar to the libraries', causing a conflict. Changed it from kotlin.time.Duration to CustomDurationSerializer and the issue went away.

Related

I cannot upgrade gradle wrapper version 6.7 to 7.0.2

I tried to upgrade wrapper version 6.7 to 7.0.2 in our Spring boot application,
but I couldn't.
I need to upgrade wrapper version to can upgrade Spring boot version, because when I upgrade spring version to 2.5.2
I got this kind of error message:
* What went wrong:
Some problems were found with the configuration of task ':copyContracts' (type 'ContractsCopyTask').
- Type 'org.springframework.cloud.contract.verifier.plugin.ContractsCopyTask' property 'config.backupContractsFolder' of mutable type 'org.gradle.api.file.DirectoryProperty' is writable.
Reason: Properties of type 'org.gradle.api.file.DirectoryProperty' are already mutable.
Possible solution: Remove the 'setBackupContractsFolder' method.
Please refer to https://docs.gradle.org/7.0.2/userguide/validation_problems.html#mutable_type_with_setter for more details about this problem.
- Type 'org.springframework.cloud.contract.verifier.plugin.ContractsCopyTask' property 'config.contractsDirectoryPath' is missing an input or output annotation.
Reason: A property without annotation isn't considered during up-to-date checking.
Possible solutions:
1. Add an input or output annotation.
2. Mark it as #Internal.
Please refer to https://docs.gradle.org/7.0.2/userguide/validation_problems.html#missing_annotation for more details about this problem.
- Type 'org.springframework.cloud.contract.verifier.plugin.ContractsCopyTask' property 'config.contractsMode' of mutable type 'org.gradle.api.provider.Property' is writable.
Reason: Properties of type 'org.gradle.api.provider.Property' are already mutable.
Possible solution: Remove the 'setContractsMode' method.
Please refer to https://docs.gradle.org/7.0.2/userguide/validation_problems.html#mutable_type_with_setter for more details about this problem.
- Type 'org.springframework.cloud.contract.verifier.plugin.ContractsCopyTask' property 'config.contractsPath' of mutable type 'org.gradle.api.provider.Property' is writable.
Reason: Properties of type 'org.gradle.api.provider.Property' are already mutable.
Possible solution: Remove the 'setContractsPath' method.
Please refer to https://docs.gradle.org/7.0.2/userguide/validation_problems.html#mutable_type_with_setter for more details about this problem.
- Type 'org.springframework.cloud.contract.verifier.plugin.ContractsCopyTask' property 'config.copiedContractsFolder' of mutable type 'org.gradle.api.file.DirectoryProperty' is writable.
Reason: Properties of type 'org.gradle.api.file.DirectoryProperty' are already mutable.
Possible solution: Remove the 'setCopiedContractsFolder' method.
Please refer to https://docs.gradle.org/7.0.2/userguide/validation_problems.html#mutable_type_with_setter for more details about this problem.
this is my gradle-wrapper.properties

Xamarin.Forms Android Binding library error

I am currently facing an issue about Xamarin Forms Android Bindings library.
I've put a .jar library inside my bindings project and I realize that the library is not fully loaded.
When I build my bindings project it compiles properly but I still have some warnings in my output.
1>BINDINGSGENERATOR : warning BG8102: Class Java.Util.LinkedHashMap has unknown base type Java.Util.HashMap.
1>BINDINGSGENERATOR : warning BG8103: Class Com.MyParams has invalid base type java.util.LinkedHashMap.
1>BINDINGSGENERATOR : warning BG8701: Invalid return type com.MyParams in method GetParams in managed type Com.TagOp.
1>BINDINGSGENERATOR : warning BG8801: Invalid parameter type com.MyParams in method TagOps in managed type Com.TagOp.
1>BINDINGSGENERATOR : warning BG8801: Invalid parameter type com.MyParams in method TagOps in managed type Com.TagOp.
1>BINDINGSGENERATOR : warning BG8801: Invalid parameter type com.MyParams in method TagPage in managed type Com.Tag.
In my Android code I can't use the Com.MyParams class because it's not loaded.
This problem occurs since the update of Xamarin for Visual Studio 2017.
Do you have any leads to solve this problem ? Thanks in advance.
HashMap & LinkedHashMap are not known ...therefore nothing based upon them can be instanced.
When the data-binding does not know a class, then it either lacks the annotations, it might not extend class BaseObservable and/or has wrongful get / set method names (which need to match the name of the field); there are quite a few conditions to meet, depending if one-way or two-way data-binding is required. Reviewing the generated code often gives a clue what one has to change.
However, directly data-binding the JAR classes does not even appear possible, unless adding the required annotations into them and then building the JAR, in order to have them bind-able. The documentation of the Android Data Binding Library and Xamarin Java Bindings Metadata explains it (replicating the required Java classes from scratch, perfectly bind-able, might be the most fast-forward, if not the only way).
One can only work around it, by substituting the classes to be bound to the GUI - which is possible with rather simple classes, or when using a Java decompiler (in order to know the fields to use).

ValueInjecter v3.0 Exception when target type property has no setter

we updated our solution to ValueInjecter v3.0 and now we have big problems because in this version an exception is raised if a property has no setter. This is different to Version 2.3.3.
We have a lot of classes where the missing setter is possible, so what can we do beside scanning the whole source code and check every usage of InjectFrom???
Is there any global Setting who avoids the exception when there is no setter?
Greeting
Martin
no, there isn't any global setting for that, but this has been recently fixed,
you can update to the latest version now, and it should work

Which JAR file contains the JsonProcessingException class?

When I try to use Jackson 2.1.1 with the following jar files (in Spring 3.2.2),
jackson-core-2.1.1.jar
jackson-annotations-2.1.1.jar
jackson-databind-2.1.1.jar
I get the following exception.
java.lang.ClassNotFoundException:
org.codehaus.jackson.JsonProcessingException
So I think, the class JsonProcessingException is contained by the jackson-core-asl-2.1.1.jar file (I'm not quite sure though) but I cannot see this file in the download. So where to get this file to resolve that exception?
jackson-all-1.9.8.jar contains necessary classes including the class org.codehaus.jackson.JsonProcessingException and JSON also works fine but I'm not sure this is perfectly compatible as I'm using classes from Jackson 2.1.1 for object mapping. Therefore I'm looking for the jackson-core-asl-2.1.1.jar file but I can't see such a JAR file. I can only see 1.x.x versions here.
In version 2.1.2, that class is called com.fasterxml.jackson.core.JsonProcessingException, and it's in the jackson-core jar. Jackson changed its packaging for version 2.0, along with numerous other things.
It seems you have some code that was written against an older version of Jackson, and is trying to load the class under an old name. You will need to either update this code, or use an old version of Jackson.
Use jackson-all-1.9.9 jar instead of the later versions(2.x.x.) of jackson-core, jackson-annotations and jackson-databind. Here is the link.

XSLT ClassCastException in WebSphere when Spring tries to create an AnnotationMethodHandlerAdapter

When starting WebSphere, I get this exception:
Could not instantiate bean class [org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter]:
Constructor threw exception; nested exception is java.lang.ClassCastException:
com.ibm.xtq.xslt.jaxp.compiler.TransformerFactoryImpl incompatible with
javax.xml.transform.TransformerFactory
Caused by: java.lang.ClassCastException: com.ibm.xtq.xslt.jaxp.compiler.TransformerFactoryImpl
incompatible with javax.xml.transform.TransformerFactory
at javax.xml.transform.TransformerFactory.newInstance(Unknown Source)
at org.springframework.http.converter.xml.AbstractXmlHttpMessageConverter.<init>(AbstractXmlHttpMessageConverter.java:47)
at org.springframework.http.converter.xml.SourceHttpMessageConverter.<init>(SourceHttpMessageConverter.java:45)
at org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.<init>(AnnotationMethodHandlerAdapter.java:197)
This doesn't seem have any impact on any beans in my applicationContext.xml but it's still odd. For me, this looks as if IBM classes are leaking into my application.
How can I fix this? I already set the option "Access to internal server classes" to "Restrict".
It was indeed a class-loading issue, however this cannot be solved by changing class-loader settings.
The problem was that the xml-apis and javax.xml jars were being imported over some maven dependencies.
Since we already set the class loader policies for the application to PARENT_LAST, the javax.xml.transform.TransformerFactory was being loaded from the WebApp-Class loader from our jar files.
However its implementation 'com.ibm.xtq.xslt.jaxp.compiler.TransformerFactoryImpl' was coming from the server class loader, this one was linked to the javax.xml.transform.TransformerFactory provided by the JDK/JRE.
Since the classes were loaded from different sources a ClassCastException was thrown.
Removing all dependencies to xml-apis / xerces / javax.xml jars solved the problem.
Since these APIs are now part of the JDK they no longer need to be imported.
... and if you wonder why I know so much about this issue: I work together with Aaron. ;)
I can't speak for Restrict as I have no personal experience with it,But I think the problem is more to do with IBM Class Loader. The class you are referring to is part of IBM Java implementation of TransformerFactory, I think you can try one of the following to solve this issue on hand
Either change the server class loader policy to PARENT_LAST (This way class loader will find the class from application's local class path, before going to up the chain all the way to java run time)
The other option would be look at the jaxp.properties file, I think it is located in (was_root\java\jre\lib), I only read about this option never actually used it
Why do you say IBM classes are leaking into your application?
The TransformerFactory is asked to create a newInstance. It follows a sequence of steps to determine which TransformerFactory to use. If none of the config is specified, it simply chooses to use the default factory.
Here is the javadoc for TransformerFactory:
http://download.oracle.com/javase/1.5.0/docs/api/javax/xml/transform/TransformerFactory.html#newInstance()
What is the OS ? Is that AIX?
http://www.ibm.com/developerworks/java/jdk/aix/j664/sdkguide.aix64.html
Looking at this doc (link above) for AIX it tells me that this is the default Impl:
javax.xml.transform.TransformerFactory
Selects the XSLT processor. Possible values are:
com.ibm.xtq.xslt.jaxp.compiler.TransformerFactoryImpl
Use the XL TXE-J compiler. This value is the default.
Post back additional information so that we can try and troubleshoot this.
HTH
Manglu

Resources