I am getting the error:
java.lang.IllegalArgumentException: Cannot handle method. It is not a valid getter or setter and does not have an implementation supplied. Signature: public abstract ...
in a unit test run with ActiveObjectsJUnitRunner.
The project is an Atlassian Jira plugin with Active Objects.
The problem was that some my colleague wrote the getter as:
import net.java.ao.0neToMany;
#OneToMany
Collection<NdaProtectedItem> getNdaProtectedItems();
while it should have been:
#OneToMany
NdaProtectedItem[] getNdaProtectedItems();
The result must be a plain array, ActiveObjects do not support collection getters!
Related
I was trying to serialized a class (DTO) to be used in send and receive
in flows.My DTO class is not in the same module as flows. I
am getting the below errors
1.With #CordaSerializable annotation , My DTO class is not getting serialized and it is throwing
java.io.NotSerializableException: Class "class com.e_mobility.dto.dashboard.DashboardDTO" is not on the whitelist or annotated with #CordaSerializable
With manual whitelisting like below
class CustomSerializationWhiteList : SerializationWhitelist {
override val whitelist: List<Class<*>> = listOf(DTO::class.java)
}
I am getting this error during runtime
net.corda.core.serialization.internal.MissingSerializerException: Unable to create an object serializer for type class com.e_mobility.dto.dashboard.DashboardDTO:
Mandatory constructor parameters [arg0, arg1, arg2, arg3, arg4, arg5, arg6] are missing from the readable properties []
Either provide getters or readable fields for [arg0, arg1, arg2, arg3, arg4, arg5, arg6], or provide a custom serializer for this type
Please help me to resolve this error. (edited)
As you are creating a custom type, did you check that all the needed requirements are fulfilled in your class? The annotation alone might be not enough. From the related Corda documentation about serialization with custom types:
The class must be compiled with parameter names included in the .class file. This is the default in Kotlin but must be turned on in
Java using the -parameters command line option to javac
The class must be annotated with #CordaSerializable
The declared types of constructor arguments, getters, and setters must be supported, and where generics are used, the generic parameter
must be a supported type, an open wildcard (*), or a bounded wildcard
which is currently widened to an open wildcard
Any superclass must adhere to the same rules, but can be abstract
Object graph cycles are not supported, so an object cannot refer to itself, directly or indirectly
What is the naming convention for boolean returning methods?
Using an 'is', 'has', 'should', 'can' in the front of method sound ok for some cases, but I'm not sure.
Is there a better way to name such methods?
for example: a function that checks card's validation. Should I call it isValidCard or cardValidation or another name?
(I didn't find it here: https://kotlinlang.org/docs/reference/coding-conventions.html)
Something about naming convention for properties in Kotlin, I know it's not for methods. But it's related:
From book Kotlin in Action (by Dmitry Jemerov & Svetlana Isakova) - section 2.2.1 Properties:
In Kotlin, properties are a first-class language feature, which entirely replaces fields and accessor methods.
Listing 2.5. Declaring a mutable property in a class:
class Person {
val name: String, // read only property: generates a field and a trivial getter
var isMarried: Boolean // writable property: a field, getter and a setter
}
Kotlin’s name property is exposed to Java as a getter method called
getName. The getter and setter naming rule has an exception: if the
property name starts with is, no additional prefix for the getter is
added and in the setter name, is is replaced with set. Thus, from
Java, you call isMarried().
For those using properties prefixed with can, should, etc. in mixed Kotlin/Java projects, you can also use #get:JvmName to make the generated Java method more idiomatic for Java clients.
For example, say you have a class like this:
class User(
#get:JvmName("canView")
val canView: Boolean
)
Without the annotation, Java clients would be forced to call user.getCanView(), but now they can call the more idiomatic user.canView().
Kotlin naming style assumes you use the Java naming conventions to the possible extend. I suggest you use this answer to the same question about Java.
UPDATE: they have released coding conventions
http://kotlinlang.org/docs/reference/coding-conventions.html
In JsonDeserialize annotation documentation the contentAs field is supposed to define the "Concrete type to deserialize content".
I tried to use this in combination, with either a Converter (via contentConverter field of the same annotation) or a JsonDeserializer (via contentUsing field of the same annotation), by extending either StdConverter or StdDeserializer, respectively, in an attempt to create an agnostic custom deserializer.
I cannot find a way to access the JsonDeserialize#contentAs information inside any of these two classes.
I am aware that the classes I extend from have a type parameter, I just put an Object class there. Documentation states
contentAs Concrete type to deserialize content (elements of a Collection/array, values of Maps) values as, instead of type otherwise declared. Must be a subtype of declared type; otherwise an exception may be thrown by deserializer.
Apparently I am applying the #JsonDeserializer annotation on a Collection of some persistable Class. I want to deserialize each such object, solely by knowing its id. Well, if I could only get that very type I defined in the #JsonDeserializer#contentAs field...
Can anyone tell me if this is possible anyhow?
I managed to implement the agnostic deserializer withou the use of #JsonDeserializer#contentAs after all.
After reading the javadocs of com.fasterxml.jackson.databind.JsonDeserializer I concluded that my custom deserializer should implement the com.fasterxml.jackson.databind.deser.ContextualDeserializer interface.
Inside the implementation of ContextualDeserializer#createContextual(DeserializationContext ctxt, BeanProperty property)
I could finally get access to the class type of the content of the collection, which I applied the #JsonDeserialize annotation on,
by calling:
ctxt.getContextualType().getRawClass()
NOTE that the same call inside the implementation of com.fasterxml.jackson.databind.JsonDeserializer#deserialize(com.fasterxml.jackson.core.JsonParser, com.fasterxml.jackson.databind.DeserializationContext) returned null, hence the need of the aforementioned interface.
All I had to do then is store the returned class in a member field (of type Class< ? >) of the custom deserializer and use it in the execution of JsonDeserializer#deserialize()
The only thing that remains to check is whether an instance of this custom deserializer is shared between threads. I only did some minor checks; I used the same implementation for two different collections of different types. I observed that ContextualDeserializer#createContextual(DeserializationContext ctxt, BeanProperty property) was called once (among multiple deserialization invokations), for each distinct type that was going to be deserialized. After checking during debugging, it seems that the same deserializer object is used for the same type. In my case, since what I store in the member field is this type itself, I don't mind if the same deserializer is used for the same java type to be deserialized because they should contain the same value. So we 're clear on this aspect as well.
EDIT: It appears all I have to do is update the com.fasterxml.jackson.databind.deser.std.StdDeserializer#_valueClass value to the now known class. Since it is final and since the ContextualDeserializer#createContextual(DeserializationContext ctxt, BeanProperty property) returns a JsonSerializer object, which is actually used,
instead of returning "this" serializer I can create a new one, passing the discovered class in the constructor, which actually sets the StdDeserializer#_valueClass to the class I actually want, and I'm all set!
Finally, NOTE that I didn't have to use the #JsonDeserializer#contentAs annotationfield as I get the value from the ctxt.getContextualType().getRawClass() statement inside ContextualDeserializer#createContextual(DeserializationContext ctxt, BeanProperty property) implementation
I'm completely new to JMockIt. In the tutorial I see example codes that uses the final modifier for a #Mocked parameter e.g.
#Test
public void doSomethingHandlesSomeCheckedException(#Mocked final DependencyAbc abc) throws Exception
{
...
}
What does final mocked parameter mean here? Sometimes, "final" is not used. What is the difference?
This is merely a Java language issue, nothing to do with JMockit itself. For a method parameter or local variable to be used inside an inner class (anonymous or not), the Java compiler requires it to be declared as final.
From the JMockit tutorial:
"For a mock parameter declared in a test method, an instance of the declared type will be automatically created by JMockit and passed by the JUnit/TestNG test runner when calling the test method. Therefore, the parameter value will never be null.
For a mock field, an instance of the declared type will be automatically created by JMockit and assigned to the field, unless it's a final field. In such case, a value should be created and assigned to the field explicitly in test code. This value can be null, though, which is perfectly valid for a mocked class if only constructors and static methods are going to be called on it."
http://jmockit.googlecode.com/svn/trunk/www/tutorial/BehaviorBasedTesting.html#declaration
Keep in mind that a mock parameter/field is any annotated with #Mocked or #Injectable.
Why does this line of unit test code work? groovy.sql.Sql doesn't have a no argument constructor.
Sql.metaClass.constructor = { dataSource -> return new Sql(); }
That line is amongst some others in a grails app which mocks out a Sql object's constructor and one of its methods. It works great.
Looking at the API for the Sql object, I do not see a no argument constructor: http://groovy.codehaus.org/api/groovy/sql/Sql.html
This style of overriding the constructor using Sql.metaClass.constructor is something I found at:
http://manuel-palacio.blogspot.com/2010/07/groovy-tip-metaprogramming-1.html
Thanks!
groovy.sql.Sql has no public no-args constructor, but as can be seen in the source, it does have a private no-args constructor -- I guess in order to support the syntax new Sql(connection: connection)?.
I'm kind of surprised, though, that that technique for stubbing doesn't generate an exception, e.g., when running sql.execute or the like.