Running application in Intellij fails to compile domain - but bootRun works - intellij-idea

I keep getting problems with Grails domain classes and using run action on Application
It appears as though the domain traits and transformations don't seem to pick up or process gorm traits correctly and compiler fails (had problems with columns without sufficient type data or bootstrap failing when I load a value into a property and it says the property doesn't exist etc.
Essentially I can't trust using the run on Application in the IDE and I don't know whether my domain classes are working or not.
However if I go to gradle view and 'bootRun' the same code it will compile and run successfully!
I've had this before and I don't know if its a grails failure or Intellij issue with Grails projects.
When I right click Application and run the command terminal shows it running like this
"D:\Program Files\Java\jdk1.8.0_181\bin\java.exe" "-javaagent:C:\Program Files\JetBrains\IntelliJ IDEA 2018.3\lib\idea_rt.jar=7620:C:\Program Files\JetBrains\IntelliJ IDEA 2018.3\bin" -Dfile.encoding=UTF-8 -classpath C:\Users\willw\AppData\Local\Temp\classpath1951982944.jar lcm.network.app.Application
In my latest iteration this throws a compile error on the bootstrap (as opposed to an error on domain class) with this
groovy.lang.MissingPropertyException: No such property: maintainer for class: com.softwood.domain.MaintenanceAgreement
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:66)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.setGroovyObjectProperty(ScriptBytecodeAdapter.java:547)
at lcm.network.app.BootStrap$_closure1.doCall(BootStrap.groovy:37)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:98)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:264)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1034)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1099)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1034)
at groovy.lang.Closure.call(Closure.java:418)
at groovy.lang.Closure.call(Closure.java:412)
at grails.util.Environment.evaluateEnvironmentSpecificBlock(Environment.java:541)
at g
However that domain class absolutely does have that property - see below
class MaintenanceAgreement extends Agreement {
String level
Map category = [:] //p1 to p5 and sla details
//static belongsTo = [serviceProvider : OrgRoleInstance, maintainer: OrgRoleInstance]
// implemented as unidirectional many to one ! mag point to org
static belongsTo = [maintainer: OrgRoleInstance]
static constraints = {
level nullable:false
//serviceProvider nullable:true
maintainer nullable:false //ref to maintainer party
category nullable:false
}
}
So you spend hours trying to sort spurious problems in your code using right click /run on Application.
I'm forced to have to use grails bootRun - which in this case runs the app just fine.
You lose some details when working this way as the stack trace for compile errors is not so clear.
Has anyone else had this problem with gorm traits processing domain objects in Intellij? Moreover how can I 'fix' the Application run action to fire all the right behaviours as bootRun seems to do?

Mike W's answer seems to be the easiest fix. When you're in IntelliJ and edit your domain models it seems to get confused and app won't compile/run as expecting.
So if bootRun works, but running application from the IDE does not, then doing this tweak seems to get things back to steady state.
If you make edits to your domain models, right click on the domain folder. Then click rebuild 'default' about half way down the menu. Wait till complete, then run your Application instance again by right click RunApplication <main> in the menu and the app should start successfully (or with debug) from within IDE.
This is easiest answer and gives best feedback to the developer with minimal extra rebuild action to remember.

Related

How can I build an Agroal connection at runtime with native support

I'm trying to build a dynamic database connection via Agroal inside a native image. It's not possible to use the default config params because I don't know the connection params at compile time. Is that even possible right now?
The connection is built like this at runtime:
AgroalDataSource.from(
AgroalDataSourceConfigurationSupplier()
...)
I'm currently seeing this error:
Class io.agroal.pool.ConnectionHandler[] is instantiated reflectively but was never registered.
Register the class by using org.graalvm.nativeimage.hosted.RuntimeReflection
The installed features include: [agroal, cdi, jdbc-h2, jdbc-mysql, jdbc-postgresql, kotlin, narayana-jta, resteasy, resteasy-jackson]
It runs fine on the JVM, but not using Graal. It feels like it should be possible and I'm probably missing something here. I was hoping adding agraol extension would be sufficient but obviously isn't picked up correctly.
The current situation is that we configure Agroal for native images only if you have a datasource defined using Quarkus configuration.
Thus for your use case, for now, you will have to do what we do automatically manually. What we do being registering some classes for reflection and including some resources in the native image.
See https://github.com/quarkusio/quarkus/blob/master/extensions/agroal/deployment/src/main/java/io/quarkus/agroal/deployment/AgroalProcessor.java#L91 and https://quarkus.io/guides/writing-native-applications-tips#using-a-configuration-file.
Obviously, that's not ideal. Could you open an issue on our GitHub so that we can discuss it internally and see if we should/can improve the situation?
In the end, you would still need some reflection registration for your JDBC driver though.

How to find my own functions in a ClojureScript error message?

I am a new ClojureScript user and I'm writing an application using Re-frame. When I get an error message (from ClojureScript), in most cases, I get a call stack ending in JavaScript code from a library. That is expected, but I don't get a function from my own code in the stack! Sometimes, I don't get any ClojureScript function calls at all, just JavaScript's. Is there a way to see the top of the stack in these error messages? Or to see the last function from my code/namespace in the stack?
That could be a huge help to me. Even small mistakes (such as, swapping operator's positions in a map call) are very hard to track. I should be doing something wrong.
It is said that ClojureScript error messages are an acquired taste. Because of the way the compiler works error messages can be cryptic.
What can help make ClojureScript error messages more readable is installing cljs-devtools or the fork Dirac. This has among other things:
The :hints feature.
The :hints feature is an attempt to augment uncaught exceptions and error object to include a bit of additional knowledge related to such errors. It tries to fetch the original source file, extract relevant part to show you more context and mark the javascript error there. This is expected to work only with :optimizations none compiler mode and it is disabled by default because it relies on monkey patching.
Better display of ClojureScript function names.
Example of nicer stack trace (from Dirac, but cljs-webtools already improves it a lot)
Installation
Enable custom formatters
Open DevTools with CMD-ALT-J
Go to Settings with F1 or by pressing the three dots
Check "Enable custom formatters" under Console
cljs-webtools
(See Installation):
Add configuration to the compiler in project.clj
{:builds
[{:id "dev"
:source-paths ["src/cljs"]
:figwheel {:on-jsload "blabla.core/reload"}
:compiler {(...)
:preloads [devtools.preload]
:external-config {:devtools/config {:features-to-install :all}}}}
Dirac
Install the Dirac Chrome extension.
Run Chrome with remote debugging enabled.
/Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary \
--remote-debugging-port=9222 \
--no-first-run \
--user-data-dir=$A_PATH_TO_YOUR_USER_PROFILE_DIRECTORY
Add binaryage/dirac to dependencies in your project.clj
:dependencies [[binaryage/dirac "RELEASE"]]
(or use another one of the installation instructions).
If you use the re-frame Leiningen template the cljs-devtools are included by default

ServiceLoader issue in WebLogic12c

I have been trying to refactor our Activiti implementation into using CDI but ran into a number of problems. I've spent way too much time trying to resolve this already, but I just can't let it go...I think I've pinned the problem down now, setting up a clean structured war without involving Activiti and have been able to reproduce what I think is the main problem.
Basically I have jar1 and jar2, both CDI enabled by including META-INF/beans.xml. Both jars specify a class in META-INF/services/test.TheTest pointing to implementations local to respective jar. jar1 depends on jar2. Also, both jars point to an implementation of javax.enterprise.inject.spi.Extension, triggering the scenario. In each implementation of Extension, I have a method like:
public void afterDeploymentValidation(
#Observes AfterDeploymentValidation event, BeanManager beanManager) {
System.out.println("In jar1 extension");
ServiceLoader<TheTest> loader = ServiceLoader.load(TheTest.class);
Iterator<TheTest> serviceIterator = loader.iterator();
List<TheTest> discoveredLookups = new ArrayList<TheTest>();
while (serviceIterator.hasNext()) {
TheTest serviceInstance = (TheTest) serviceIterator.next();
discoveredLookups.add(serviceInstance);
System.out.println(serviceInstance.getClass().getName());
}
}
Now, my problem is that the ServiceLoader does not see any implementations in either case when running WebLogic12c. The same code works perfectly fine in both Jboss 7.1.1 and Glassfish , listing both implementations of the test.TheTest interface.
Is it fair to assume that this is indeed a problem in WebLogic 12c or am I doing something wrong? Please bare in mind that I am simply trying to emulate the production setup we use when incorporating Activiti.
Regards,
/Petter
There is a Classloader Analysis Tool provided with WLS, have you seen if this will help with the diagnosis of your issue.
You can access this tool by going to ip:port/wls-cat/index.jsp
Where port will be the port of the managed server where your application is deployed.

VB.net NUnit (2.5) Windows forms Testing - Is this possible

I am retrofitting unit testing into a fairly complex system designed and written by other developers in VB.net. I am trying to develop unit tests for the GUI forms using NUnit and the NUnit Forms extension. (I've been looking at c# examples that are fairly easy to port over if you have a solution but don't know VB syntax as long as it uses NUnit classes)
I will try and explain what I am doing but first a brief description of the program. It basically monitors server activity. You need to connect to a server via a modal form with IP and Port fields(amongst others). Once you have connected to a server other parts of the program unlock and become usable (such as configuration of the server).
Desired process: Load program > click connect button > modal connect form loads > enter details > click OK to connect > main form updates to logged-in state > other functionality
The problem is that I cannot test the functionality of the connect form and then the logged-in functionality of the program. I can test that it loads the modal connect form correctly; enters the details and clicks OK (all fine so-far) but it does not appear to logically progress the program. The modal form just closes again seemingly without running the connect code from the program back-end and I’m back at the main menu not logged in to anything.
I have a feeling that I’ve either missed something really obvious or that it’s simply not doable in NUnit. I have trawled the internet in search of anything similar but the closest was another SO thread that was really generic. Without being able to actually test the logged-in version of the program, I'm at a major hurdle.
Another issue is handling message boxes that don’t have unique identifiers (e.g. “are you sure you want to exit?”); these also seem to be a major pain in the arse with NUnit
(If it makes any difference, I’m running the tests as a stand-alone project using a reference to the executable file of the built project, not the actual source)
Can post some of my testing code if required.
IMHO the best approach to make GUI classes feasible for unit tests is to apply the Model-View-Presenter pattern and factor almost every program logic out of the form (=View) class to a separate Presenter class. Then you can unit test the Presenter class without the need for tools like "NUnit Forms".
Read Michael Feathers' article "The Humble Dialog Box" for an example in C++, you can easily apply that to Winforms, I guess.
I'm not sure about NUnit forms, but using the White library (which also works with NUnit), you're able to test the application by running the exe and mimicking user actions. The application runs normally so all application logic is performed.
Here's some example code for launching an app with White:
Dim app = White.Core.Application.Launch("MyApp.exe")
Accessing a form from your app:
Dim mainForm = app.GetWindow(SearchCriteria.ByAutomationId("MainForm"),
InitializeOption.NoCache)
Performing an action such as clicking a menu item:
mainForm.MenuBar.MenuItem("Edit", "Jobs...").Click()
Getting a control and validating its state:
Dim someTextBox = mainForm.Get(Of TextBox)(SearchCriteria.ByAutomationId("txtValue"))
Assert.IsTrue(someTextBox.Text = "12345")
I'm not sure if NUnit Forms has similar capabilities, but if not, maybe you should look into White. I ran into some issues setting it up so make sure to read the documentation carefully (not very exhaustive unfortunately) before setting it up.

Issues with M:1 relations using Objectify 1.1rc and CRUD on Play 1.1

I'm having a really odd issue and maybe one of you can shed some light
on it. I would appreciate it :)
I'm developing an application using Objectify 1.1rc module for Play! Framework 1.1. I have 2 related objects whose relevant parts are:
public class User extends ObjectifyModel<User> {
[...]
public List<Key<Theatre>> theatres;
[...]
}
public class Theatre extends ObjectifyModel<Theatre> {
[...]
}
Some background:
I'm using Objectify 1.1rc from the Google code repository (the module in Play repository seems to fail with Play! 1.1) The sample application works fine
I based the objects in existing objects working properly on the sample application provided with the Objectify-1.1rc module for Play Framework (Showcase).
I did debugging and testing by pointing my application and the sample application (Showcase) to the same CRUD module.
I can link them using Java code without any problem.
Presently I have 2 issues that I cannot solve, which are:
M:1 relation not being saved
I have an issue with the 'theatres' relation from the User class. When editing an
object of type User via CRUD, I can see the multi-select control to relate Theatre instances to the User, When I click on some (one or more) of them and save the object, the relation is not saved, making it impossible to link the objects via the CRUD interface.
How can make it work?
CRUD code not being accessed by one application but accessed by the other
The sample application from Objectify module (Showcase) allows me to save M:1 relations using CRUD. As I mentioned before, both my application and showcase point to the same CRUD module, so they should use exactly the same code. What I noticed, by debugging via Log outputs, is that my application uses CRUD, but the sample application uses all the code up to a certain point.
The CRUD module traverses to 'tag/form.html', finds a field of type 'relation' (in both my code and the sample application) but when calling the tag '#{crud.relationField}' something odd happens: my application goes into the tag defined in the CRUD module. The sample application doesn't access that code, no logs added to that tag are triggered (at any point of the file).
I've searched for any replacement of the tag in the sample application, but I'm unable to find one. As you can guess, it's driving em crazy and making me start believing in green leprechauns living in my desktop (without giving me the gold, damn them!)
Anyone knows why does this happen? And were can I find the code being executed by the sample application? Finding it would most likely solve the issue #1
Thanks a lot!
Ok, found the issue to #1. I had a method called "getTheatres()" (should have had another name, was an error) and that was breaking the CRUD. Renaming the method solve issue #1.
I still didn't find why #2 was happening, but I believe I'll leave as one of those "worked in my computer" issues so common in our world...