This is a follow-up question to Manual Conversion of 3rd Party Class With Morphia
I've an #Entity class which has a field of type javax.activation.MimeType. When I run my application I see a warning message in the output window, telling
WARNING: The multi-valued field
'javax.activation.MimeTypeParameterList.parameters' is a possible
heterogeneous collection. It cannot be verified. Please declare a
valid type to get rid of this warning. class java.lang.Object
I've already written and registered a type converter class for the type "MimeType", which effectively just ignores its 'parameters' field. But the warning keeps coming.I debugged it and saw that the warning was issued when datastore.ensureIndexes(); is called.
I tried writing a type converter for "MimeTypeParameterList" type but it didn't supress the warning. I can't just go and put a #Transient annotation over the field declaration because it's third party code (Java SE core!), not mine.
Is there an "elegant" way to eliminate this warning?
I just pushed a change to morphia's github repo that suppresses that logging for you. It'll be in 0.108 or you can build it locally if you want to try it out.
Related
I am Using soong build system with kotlin and want to opt in for experimental APIs to be used in the code
I have added #file:OptIn(kotlinx.coroutines.ExperimentalCoroutinesApi::class) in kotling file but upon compiling I get error stated as
error: this class can only be used as an annotation or as an argument to #UseExperim
ental
#file:OptIn(kotlinx.coroutines.ExperimentalCoroutinesApi::class)
Can anyone tell me what additional things I need to do to make it work ?
When deserializing an autobean from JSON I get an AssertionError from com.google.web.bindery.autobean.shared.impl.AutoBeanCodexImpl.CoderCreator#getCoder. Looks like there are two types registered for my autobeans:
my.project.model.MyAutoBean
java.lang.Class
Of course I find the second one quite useless but I don't know where it comes from and how to get rid of it. When I disable assertions the code just works fine and (de)serializes my Autobean perfectly.
I already get two types in the initialization of the ClientPropertyContext but I cannot debug what in MyAutoBean.traverseProperties is happening.
I found it out on my own:
My autobean interface was extending another interface that had a method to return the AutoBean's class (to work around java type erasure in a facoty method). After removing this method it worked.
As you may know, it is pretty easy to have active code of a class containing syntax errors (someone activated the code ignoring syntax warnings or someone changed the signature of a method the class calls, for instance).
This means that also dynamic instantiation of such a class via
CREATE OBJECT my_object TYPE (class_name).
will fail with an apparently uncatchable SYNTAX_ERROR exception. The goal is to write code that does not terminate when this occurs.
Known solutions:
Wrap the CREATE OBJECT statement inside an RFC function module, call the module with destination NONE, then catch the (classic) exception SYSTEM_FAILURE from the RFC call. If the RFC succeeds, actually create the object (you can't pass the created object out of the RFC because RFC function modules can't pass references, and objects cannot be passed other than by reference as far as I know).
This solution is not only inelegant, but impacts performance rather harshly since an entirely new LUW is spawned by the RFC call. Additionally, you're not actually preventing the SYNTAX_ERROR dump, just letting it dump in a thread you don't care about. It will still, annoyingly, show up in ST22.
Before attempting to instantiate the class, call
cl_abap_typedescr=>describe_by_name( class_name )
and catch the class-based exception CX_SY_RTTI_SYNTAX_ERROR it throws when the code it attempts to describe has syntax errors.
This performs much better than the RFC variant, but still seems to add unnecessary overhead - usually, I don't want the type information that describe_by_name returns, I'm solely calling it to get a catchable exception, and when it succeeds, its result is thrown away.
Is there a way to prevent the SYNTAX_ERROR dump without adding such overhead?
Most efficient way we could come up with:
METHODS has_correct_syntax
IMPORTING
class_name TYPE seoclsname
RETURNING
VALUE(result) TYPE abap_bool.
METHOD has_correct_syntax.
DATA(include_name) = cl_oo_classname_service=>get_cs_name( class_name ).
READ REPORT include_name INTO DATA(source_code).
SYNTAX-CHECK FOR source_code MESSAGE DATA(message) LINE DATA(line) WORD DATA(word).
result = xsdbool( sy-subrc = 0 ).
ENDMETHOD.
Still a lot of overhead for loading the program and syntax-checking it. However, at least none additional for compiling descriptors you are not interested in.
We investigated when we produced a dependency manager that wires classes together upon startup and should exclude syntactically wrong candidates.
CS includes don't always exist, so get_cs_name might come back empty. Seems to depend on the NetWeaver version and the editor the developer used.
If you are certain that the syntax errors are caused by the classes’ own code, you might want to consider buffering the results of the syntax checks and only revalidate when the class changed after it was last checked. This does not work if you expect syntax errors to be caused by something outside those classes.
I would like to suppress some of these VB.NET warnings at class level. (=Not globally.) Supression is intended as temporary woarkaround until the code of some classes gets properly cleaned. There are hundreds of ID: 42016 (Option Strict On disallows implicit conversions from 'TypeA' to 'TypeB'.) warnings in legacy code, I cannot afford to fix them all right now.
I found that SuppressMessage attribute can be effectively used for the task but I cannot find proper argument values to supply to <SuppressMessage()> for warning 42016.
My question is: can be warning 42016 and other above referenced VB.NET-specific warnings suppressed by SuppressMessage attribute?
If you know there is no way of doing it, I will accept it as the answer, too.
Note: I know how to suppress them globally, this is not an option at the moment.
No, that does not get you anywhere. SuppressMessageAttribute is only used by code analysis (aka FxCop), the VB.NET compiler ignores it. And it is not a warning, it is a compile error. You can never ignore an error.
Option Strict can only be changed at file scope, there is no support for changing it on-the-fly. The only reasonable approach here is to tackle the borken source code one .vb file at a time. Not an unreasonable approach.
It blows my mind that the official document at MSDN doesn't say anything about what the underlying object type of the enumerable that returned by GetErrors of INotifyDataErrorInfo should be: http://msdn.microsoft.com/en-us/library/system.componentmodel.inotifydataerrorinfo.geterrors(v=vs.95).aspx
Options are: System.String, System.Object, MyCustomObject, ISomeOtherShitThatDoesntHaveAnythingToDoWithValidationWhatsoever
Can anybody explain to me how an arbitrary enumerable of object can be OK for notifying about errors without making any assumptions about its structure?
The docs for INotifyDataErrorInfo give more information:
The validation errors returned by the GetErrors method can be of any type. However, if you implement a custom error type, be sure to override the ToString method to return an error message. Silverlight uses this string in its default error reporting.
Custom error objects are useful when you provide custom error reporting in the user interface. For example, you can create a template for the reporting ToolTip that binds to an ErrorLevel property in order to display warnings in yellow and critical errors in red.
There's a link in the Examples section of GetErrors back to that documentation:
For an example of an implementation of this method, see the INotifyDataErrorInfo class overview.
I agree it's less clear than it might be, but the documentation is there...