I've suddenly started getting a MissingMethodException in my Grails 2.2.5 app, without any change in code and the error is seemingly spurious, so I'm suspecting corruption somewhere. I'm getting this error:
No signature of method: arthurs.Sale.findByCustomerAndComplete() is applicable for argument types: (arthurs.Customer, java.lang.Boolean) values: [arthurs.Customer : 59, false]
Possible solutions: findByCustomerAndComplete([Ljava.lang.Object;). Stacktrace follows:
Message: No signature of method: arthurs.Sale.findByCustomerAndComplete() is applicable for argument types: (arthurs.Customer, java.lang.Boolean) values: [arthurs.Customer : 59, false]
Possible solutions: findByCustomerAndComplete([Ljava.lang.Object;)
This worked fine until yesterday. The Sale class does in fact have 'customer' (Customer class) and 'complete' (Boolean) properties, and I've checked that what I'm passing are valid parameters. In any case, the error message does specify the argument types and these are correct.
So why might my dynamic 'findBy...' method suddenly stop working? In the past I've often found doing a 'grails clean' often sorts such things out but it doesn't seem to have helped with this one.
Is there something else I should clear out, to give myself a blank slate?
Well, don't know what had happened there but deleting the project folder from '.grails/2.2.5/projects' did the trick.
LATER: No, the problem has returned. Very puzzled by this now.
LATER STILL: Well, I've now determined what it is that triggers the problem, although I am completely baffled as to why it does so. If I add a 'created' property of type Date to my Sale class, the problem recurs and remains until I remove the property, remove the column from the MySQL table, and delete the project folder. If, however, I mark this property as nullable in constraints, it works OK. ???
Related
After upgrading to Vaadin 23.0.x (from former 22.0.2) I now keep getting the following error when opening a certain dialog:
2022-08-01 18:56:25,977 ERROR [http-nio-8085-exec-5] net.mmo.utils.kism.ui.views.nodes.NodeView: java.lang.IllegalStateException: All bindings created with forField must be completed before calling readBean
at com.vaadin.flow.data.binder.Binder.checkBindingsCompleted(Binder.java:3070)
at com.vaadin.flow.data.binder.Binder.readBean(Binder.java:2110)
at net.mmo.utils.kism.ui.views.nodes.NodeForm.readBean(NodeForm.java:487)
at net.mmo.utils.kism.ui.views.nodes.NodeForm.setNode(NodeForm.java:211)
This dialog has worked perfectly fine since I wrote it (using version 18.0.x about 2 years ago) and up to v22.0.2. I can't make sense of that error message and I don't understand what the issue could be here. I verified that issue going back and forth and the difference is really only the Vaadin version upgrade. Before it, the dialog works just fine and after it I get the above Exception when opening it.
I also can't quite believe what I think the message is stating here: if it would indeed check that I define or complete any bindings AFTER calling Binder.readBean() - how could it know that already in that very moment, i.e. when the code calls readBean() - as indicated by the stacktrace?
If there would indeed be any bindings being defined afterwards, IMHO it could only find that out AFTER said readBean()-call, i.e. when any additional bindings were actually defined, couldn't it?
So, could someone please try to "translate" or explain that issue or the background behind it to me?
The error basically states the problem: in the process of binding a field to a property (or getter/setter in general), the finishing step of actually binding was not undertaken. So the process was started with .forField() but never finished by .bind().
Since the error message as of now only states the fact, but not the culprit, a developer would be in need of a debugger to inspect the private state of the Binder, where the map incompleteBindings holds the current state of the Binder. The content of this map may help to find the culprit, e.g. by only holding one entry and by inspecting the flow of the program so far, that would conclude, what binding attempt failed. Or e.g. via the included field types.
Other than plain "bugs" by the developer, there are some potential reasons, why this suddenly happens by like an update or what places to look for:
multiple (re-)binding was recently added (e.g. to first bind "automatically" and then hand-tune the result); this holds potential, that older versions of the code just kept the initial binding and ignored the dangling second process.
the binding process uses a builder pattern; builder must build up on the result of the previous steps. This means, that in imperative code, there is the chance, that this chained call miss reassigning the build step. E.g.
var b = binder.forField(field)
if (predicate)
b.asRequired() // XXX: should be `b = b.asRequired()`
b.bind(...)
(this may or may not be a source for this kind of problem, but it's good to point out here, since the binder builder implementation actually switche(s|d) the builder (in the past)
We have an issue on our production system and some of our test systems. We have an intermittent Grails Exception which occurs in a view.
No signature of method: static org.apache.commons.lang.StringUtils.isNotBlank() is applicable for argument types: (null) values: [null] Possible solutions: isNotBlank(java.lang.String), isBlank(java.lang.String)
The error seems to suggest that Grails can't seem to figure out that it should use StringUtils.isNotBlank(String) should be used when null is passed to it.
We noticed that:
on production, the issue appeared and took more than 12 hours before it seemed to magically disappear. A search of logs seems to suggest that no reboot took place.
a developer saw no issue on a test system in the morning. After a few hours, he was able to reproduce it. To resolve, we rebooted Tomcat.
I'm not sure what the Grails version is or how to check it. If you comment below on how to find that, I'd be happy to edit the question with the Grails version.
What causes this and is there a way we can reliably reproduce it?
Is there a reliable way to work around it?
I can reproduce this in the console by running:
org.apache.commons.lang.StringUtils.isNotBlank((Object)null) => Your Error
Passing just null allows the compiler to coerce the null to a String:
org.apache.commons.lang.StringUtils.isNotBlank(null) => false
It's possible whatever you are passing in is strictly typed to be something other than a String but is null. The Groovy compiler is pretty smart of coercing types, but I have seen it blow up on some easy cases. This is especially true if using #CompileStatic and/or using native Java objects.
A reliable workaround is that we restart the application.
Horrible answer, I know. I feel dirty every time.
I recently experienced this as well. Turns out, we had a piece of code that was passing in a Long to StringUtils.isNotEmpty(). Every subsequent call made to this method having a String value of null, errored with the same MissingMethodException.
You can replicate this pretty easily by executing...
String string = null
Long longVal = new Long("1103384")
try{
StringUtils.isNotEmpty(longVal)
}catch(Exception e){
e.printStackTrace()
}
try{
if(!StringUtils.isNotEmpty(string)){
println("............EMPTY. Good.")
}
}catch(Exception e){
e.printStackTrace()
}
In the snipped above BOTH calls with error out.
I am running into a bizarre situation where a unit test's execution is behaving differently than the normal execution of a piece of code.
In particular, I am using a library called JSONModel, and when I am attempting to deserialize an object from a JSON string, one line in particular is causing problems when I step through the executing test case:
if ( [[property.type class] isSubclassOfClass:[JSONModel class]] ) ...
If I put a breakpoint before (or after) this line and execute:
expr [[property.type class] isSubclassOfClass:[JSONModel class]]
...in the debugger, it prints \x01 as the value (i.e. true), however when I actually step the instruction pointer, it behaves as though it is false, going instead into the else block. Again, typing the expression into the debugger again shows it as true even still.
I'm curious if anyone has seen similar behavior before and has any suggestions as to what could possibly be going wrong. I'm quite certain I'm not including different definitions for anything, unless Xcode has different internal cocoa class implementations for testing.
Update: Here's some even weirder evidence: I've added some NSLog statements to get an idea for how the execution is seeing things. If I log property.type.superclass I get JSONModel back (as expected); however if I log property.type.superclass == [JSONModel class] I get false!
To me this is indicating that the JSONModel the unit test execution is seeing is somehow a different JSONModel class that I'm seeing at runtime (and what it should be seeing). However, how that is happening I can't figure out.
Could this be caused by a forward class declaration or something like that?
Well I seem to have discovered a "solution" by experimentation. It turns out if I replace [JSONModel class] with NSClassFromString(#"JSONModel") it works swimmingly!
Now why this is I cannot say, and will give the answer to whoever can explain it!
I had the exact same problem, here's what was happening.
As expected with this kind of behaviour, it was an issue with the class being duplicated. As with you, [instance class] and NSClassFromString would return different values. However, the class were identical in all points : same ivar, same methods (checked with the obj runtime). No warning was displayed at compile, link and/or runtime
In my case, the tests were about a static library used in my main application (Bar.app).
Basically, I had 3 targets:
libFoo
libFooTests
Bar.app
The tests were performing on the device, and not on simulator. As such, they needed to be logic tests, and not unit tests, and had to be loaded into an application. The bundle loader was my main app, Bar.app.
Only additional linker flag was -ObjC
Now, Bar.app was linking libFoo.
It turns out, libFooTests was also linking libFoo.
When injecting libFooTests in the test host (Bar.app), symbols were duplicated, but no warning were presented to me. This is how this particular class got duplicated.
Simply removing libFoo from the list of libraries to link against in libFooTests did the trick.
I am trying to create a setup project for a Windows Service. I've followed the directions at http://support.microsoft.com/kb/816169 to create the setup project with no trouble.
I want to be able to get a value during the installation in order to update the app.config with the user's desired settings. I added a Textboxes (A) dialog to retrieve the values. I set the Edit1Property property to "TIMETORUN", and in my Primary Output action's CustomActionData property I put in the following: /TimeToRun="[TIMETORUN]\". So far so good. Running the setup I can retrieve the TimeToRun value from the Context.Parameters collection without issue.
In order to locate the app.config I need to also pass in the value of the TARGETDIR Windows Installer Property to my custom action. This is where things begin to fall apart. In order to achieve this, the above CustomActionData must be altered like so: /TimeToRun="[TIMETORUN]\" /TargetDir="[TARGETDIR]\". Now when I run the setup I get the following error message:
Error 1001. Exception occurred while initializing the installation.
System.IO.FileNotFoundException: Could not load file or assembly 'file:///C:\Windows\SysWOW64\Files' or one of its dependencies. The system cannot
find the file specified.
If you google this problem you will inevitably find people having tremendous success by simply adding the trailing slash to the /TargetDir="[TARGETDIR]\" portion of the CustomActionData. This unfortunately does not solve my issue.
I tried so many different variations of the CustomActionData string and none of them worked. I tried logging to a file from my overridden Install method to determine where the breakage was, but no log file is created because it's not even getting that far. As the error indicates, the failure is during the Initialization step.
I have a hunch that it could be one of the dependencies that the setup project is trying to load. Perhaps somehow something is being appended to the CustomActionData string and isn't playing well with the TARGETDIR value (which contains spaces, i.e. "C:\Program Files\My Company\Project Name"). Again, this is another hunch that I cannot seem to confirm due to my inability to debug the setup process.
One further thing to mention, and yes it's another hunch, could this be an issue with Setup Projects on 64-bit version of Windows? I'm running Windows 7 Professional.
I'll provide names of the dependencies in case it helps:
Microsoft .NET Framework
Microsoft.SqlServer.DtsMsg.dll
Microsoft.SqlServer.DTSPipelineWrap.dll
Microsoft.SqlServer.DTSRuntimeWrap.dll
Microsoft.SQLServer.ManagedDTS.dll
Microsoft.SqlServer.msxml6_interop.dll
Microsoft.SqlServer.PipelineHost.dll
Microsoft.SqlServer.SqlTDiagM.dll
As you may glean from the dependencies, the Windows Service is scheduling a call to a DTSX package.
Sorry for the long rant. Thanks for any help you can provide.
The answer is so maddeningly simple. If the last argument in the CustomActionData is going to contain spaces and thus you have to surround it with quotes and a trailing slash, you must also have a space following the trailing slash, like this:
/TimeToRun="[TIMETORUN]\" /TargetDir="[TARGETDIR]\ "
The solution and explanation can be found here.
Had a similar issue. In my case, it was odd because my installer had ran successfully once, then I uninstalled my app via Add/Remove Programs successfully, did some coding (did NOT touch my CustomActionData string), and rebuilt my project and setup project. It was when I re-ran my MSI that I got this error.
The coding I had done was to bring in more values of more parameters I had been specifying in my CustomActionData string. That syntax for getting the parameter values (i.e. string filepath = Context.Paramenters["filepath"]), which was in my Installer class, was actually fine, but as I found out, the syntax of the later parameters I was now trying to get from my CustomActionData string had not been correct, from the very beginning. I had failed to add a second quote around one of those parameters, so nothing else could be obtained.
I was using the "Textboxes (A)" and "Textboxes (B)" windows in the User Interface section. A has 1 box, EDITA1, where I get the path to a file, and B has 2 boxes, EDITB1 and EDITB2, for some database parameters. My CustomActionData string looked like this:
/filepath="[EDITA1]" /host="[EDITB1] /port="[EDITB2]"
It should have been:
/filepath="[EDITA1]" /host="[EDITB1]" /port="[EDITB2]"
(closing quote on [EDITB1])
I've just created my first Preview 5 error and it doesn't seem to place nice with Resharper. All the C# in the Views are coming up with errors, things like <%= Html.Password("currentPassword") %> has the "currentPassword" highlighted with the following error: Argument type "System.String" is not assignable parameter type "string".
IList errors = ViewData["errors"] as IList; has the IList highlighted as "Can not resole symbol 'string'"
Has anyone seen this?
Did you try latest nightly build of ReSharper 4.1? In some cases the bug in 4.1 manifests itself with numerous ambiguity errors, and it has been fixed within the follow up build.
If anyone finds this blog, the fix suggested above worked for me - I downloaded the latest 4.1 build, and the ambiguous reference problem is gone.
Sometimes this can occur when you don't fully qualify your Inherits attribute of your #Page directive. Even if it is in your web.config be sure and fully qualify your Inherits directive for R#. (At least as of build 4.1.943).
This bug has been reported here:
http://www.jetbrains.net/jira/browse/RSRP-96241