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.
Related
Just wondering if you can mark a method as pending to implement in pharo, like you can do in java using "todo"
I'ts really hard for me to keep track of what's complete on pharo without something like that
Methods whose implementation is still pending should send the notYetImplemented message like this:
methodImNotSureHowToImplement
^self notYetImplemented
if the unimplemented message gets sent anyway, it will signal a NotYetImplemented exception which will know the offending selector, #methodImNotSureHowToImplement in my example.
Note also that this will make it easy finding all methods that need to be implemented as senders of #notYetImplemented.
The implementation of #notYetImplemented is straightforward, thanks to the existence of NotYetImplemented.
notYetImplemented
"Announce that this message is not yet implemented"
NotYetImplemented signalFor: thisContext sender selector
Note also that NotYetImplemented is one of the subclasses of SelectorException which model several situations of similar kinds:
SelectorException
NotYetImplemented
PrimitiveFailed
ShouldBeImplemented
ShouldNotImplement
SubclassResponsibility
I found the solution for this by myself 2 days after asking about it, almost accidentally, just using the context menu option jump to test method over a method without any test. Pharo automatically generated an empty test with this:
self flag: #toImplement.
self assert: false`
the first line, which can be used not only on tests, gives me the behavior I expected as it automatically categorizes the method containing it on a flags category marked with a big "!" allowing to easily check at glance which methods are pending.
The second line forces test to fail and be shown on yellow which is pretty useful because if it's empty it will pass and be shown on green, probably leading to believe it's already done when is not the case. A similar effect can be achieved just using self notYetImplemented
I would probably start doing something like this with my incomplete methods:
MyIncompleteMethod
self flag: #toImplement.
self notYetImplemented.`
you also can use pragmas to mark such methods
As Smalltalk provides the origin of agile development, let me provide a different answer. In a failing unit test. As you are not supposed to have a lot of those, it automatically provides the pressure to limit work in progress (the number of open #toDo's).
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 have the following code working in a SpringBoot application, and it does what's I'm expecting.
TypePool typePool = TypePool.Default.ofClassPath();
ByteBuddyAgent.install();
new ByteBuddy()
.rebase(typePool.describe("com.foo.Bar").resolve(), ClassFileLocator.ForClassLoader.ofClassPath())
.implement(typePool.describe("com.foo.SomeInterface").resolve())
.make()
.load(ClassLoader.getSystemClassLoader());
Its makes is so that the class com.foo.Bar implements the interface com.foo.SomeInterface (which has a default implementation)
I would like to . use the above code by referring to the class as Bar.class, not using the string representation of the name. But if I do that I get the following exception.
java.lang.UnsupportedOperationException: class redefinition failed: attempted to change superclass or interfaces
I believe due to the fact that it cause the class to be loaded, prior to the redefinition. I'm just now learning to use ByteBuddy.
I want to avoid some reflection at runtime, by adding the interface and an implementation using ByteBuddy. I've some other code that checks for this interface.
This is impossible, not because of Byte Buddy but no tool is allowed to do this on a regular VM. (There is the so-called dynamic code evolution VM which is capable of that).
If you want to avoid the problem, use redefine rather then rebase. Whenever you instrument a method, you do now however replace the original.
If this is not acceptable, have a look at the Advice class which you can use by the .visit-API to wrap logic around your original code without replacing it.
I'm using NSUserScriptTask to run scripts the user placed in the Application Scripts directory. However, I'm finding it hard to find out which are the known types of scripts that NSUserScriptTask accepts and the docs don't help much either... Any ideas?
So far I've tried these:
.sh
.applescript
.scpt
.scptd
.txt
And coudn't get any of them to work (the initWithURL:error: method returns nil)
EDIT:
I forgot to include the error! Silly me... Here's what gets printed on the log:
Error Domain=NSCocoaErrorDomain Code=259 "The file “Untitled.applescript” couldn’t be opened because it isn’t in the correct format." UserInfo=0x100121f50 {NSURL=file://localhost/Users/path to file/Untitled.applescript, NSFilePath=/Users/path to file/Untitled.applescript}
The documentation for NSUserScriptTask claims that instantiating that class directly will work on any valid file and return the appropriate kind of task:
The returned object will be of one of the specific sub-classes (NSUserUnixTask, NSUserAppleScriptTask, and NSUserAutomatorTask), or nil if the file does not appear to match any of the known types.
If invoked from a subclass, the result will be that class or nil.
In reality, I found that (as of 10.8.2) NSUserScriptTask unconditionally returns nil and a “what is this i dont even” error. It seems that you need to instantiate the correct task subclass yourself. Probably worth filing a bug.
To test whether a file is usable as a script task (e.g., in an Open panel validation method), all I can suggest is to try instantiating each of the three classes, returning YES if any of them succeeds and NO if all of them fail.
In PHPUnit, I want to use methods like verifyText() with an optional message as the last parameter, like I do with assertStringEquals($expected, $actual, $message). It doesn't seem to work. Am I missing something?
I would tell myself to read the code, but I tried and I can't even figure out how any of the verify() methods get called. It must be some __call() function but I don't see it. So that's my follow-up question, how do the verify() methods get called? Then I could override them if I want.
I'm exploring the same question, albeit in the context of Selenium.
I found, grepping the source, an array $autoGeneratedCommands, which is set up in SeleniumTestCase/Driver. The mechanism here implements/maps verifyTextPresent() by a call to verifyCommand(), which calls assertCommand(). Subsequently one of the family assert*() is called... omitting the message in the call. This seems like an inadvertant feature to me. Well, coded bug.