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
Related
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.
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).
We have recently migrated to Jboss EAP 6.4 from Jboss 4.2. In one of our EJB classes we are having over loaded methods create(AbstractBean) and create(AbstractEntity). The class AbstractEntity is extending AbstractBean class. When we try to invoke the create(AbstractBean) method in Jboss 6.4 instance we are getting the IllegalArgumentException: argument type mismatch error, but we are not getting this exception in Jboss 4.2.
When we comment out the create(AbstractEntity) method, the exception is not occurring, also when we try to invoke the method using reflection the exception is not occurring.
But we just wanted to know is there anything to be done in the server configuration to resolve this issue or as mentioned above using reflection is a correct solution.
Can anyone help us understand the Jboss6.4 behavior correctly.
We were having two methods in a class which having different arugment type but argument type of one method extends argument type of other so JBoss ended up with ambiguity error. we have removed the method with derived class as argument and kept the super class one. That resolved the issue for us.
We're upgrading our version of SonarQube to 5.1.2, and see that we're now on a version that no longer ships with FindBugs. It appears that there should be equivalent rules available, but we're battling to find them, especially the ones dealing with database resources that are not closed.
Is there a way of finding which rules replaced these rules?
Bad practice - Method may fail to close database resource
Bad practice - Method may fail to close database resource on exception
Bad practice - Method may fail to close stream
Bad practice - Method may fail to close stream on exception
Bad practice - Non-serializable value stored into instance field of a serializable class
Dodgy - Transient field of class that isn't Serializable.
Method may fail to clean up stream or resource on checked exception
Non-transient non-serializable instance field in serializable class
Found them - they appear to all be covered by the following two rules that are included with SonarQube.
Fields in a "Serializable" class should either be transient or serializable
Resources should be closed
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