In Acceleo, when I edit and save, say, generate.mtl, Acceleo automatically generates Generate.java class. From this java class I can call doGenerate method from an external class to generate my model-based stuff.
However, if there is some exception during execution, this exception is handled by the Acceleo engine. I would like to tell Acceleo engine not to handle exceptions, and thus realize that an error occurred.
How is it possible?
I've been thinking for a long time about this, without success. Last week, I successfully ran Acceleo in standalone mode, from a Java class instead of using the pluging.
It made me spend a lot of time with issues with libraries, problems with dependencies etc. but I finally got it (I mean, it's a hard work, be patient).
My surprise: When I ran Acceleo standalone it failed, but the templates were the same. I was having many errors, but the plugin was managing then and the plugin was printing an empty String as a result! Running Acceleo standalone, those errors raise an exception and my main class prints the stacktrace.
So, if you want to manage the errors by yourself, I recommend you to run it standalone but... good luck! :)
I hope this would help you :)
Related
So Im currently in a project where we are using Java playframework 2.3.7 with activator.
One of the things I liked about playframework is the hot-reloading feature. I can modify java files save and the changes are compiled and refreshed on runtime.
How do I get that functionality but for testing? I want to be able to run a single test with this hot reloading feature, so that when I save. Tests for the given file (specified by test-only) is re-runned automatically.
There is not such a solution, however you have two choices:
Use IntellJ: To re-run the previous test(s) in IntellJ, you press shift + F10.
Write a watcher: Write a file/directory watcher such as this question/answer here, and then as soon as there are changes, the program, re-runs the test command, such as sbt clean compile test or activator compile test.
Little advice auto running tests: I don't know how complicated your application is, but as soon as you have couple of injections here and there and with additional concurrency; you do not want to run the tests as soon as you put a char in.
Little advice on Test Driven Development: Your approach should be the other way around! You write a test, which fails because there is no implementation; then you leave it alone. You go and write the implementation, then rerun the test to pass it or to get a feedback. Again, you need your cpu/memory power to focus on one thing, you don't want to brute force your implementation. Hope this makes sense!.
Little advice on your Play version: The Play 2.6 is way much better than Play 2.3; you should slowly but surely update your application; at least for the sake of security.
Ok so I found what I was looking for.
For anybody in need of this particular feature in that particular version of play (I'm not sure about other versions) what you need to do is really simple. run activator and put the ~ prefix before test. for example
#activator
[my-cool-project]~test
That will reload your tests when you make a change. if you want to do this for a particular test then you have to do the same but with test-only
#activator
[my-cool-project]~test-only MyCoolTest
hope it helps anyone looking for the same thing
I've started working with jHipster on a recent project which is a tool you can use to autogenerate the full stack of a REST api application using a Spring Boot back end. Which should save a great deal of time writing boilerplate code...
Unfortunately, at my work we have coding standards to adhere to in the form of a set of CheckStyle rules. Any code that does not adhere to these rules causes the build to fail. What I am experiencing at the moment is that this autogenerated code is failing the CheckStyle rules in a large number of places. Currently I am handling this by manually trawling through the code fixing each of the issues.
I can't help feeling in the back of my mind there must be a better way of doing this e.g.:
Configuring the IDE (intelliJ) to ensure the generated code matches the CheckStyle rules. This is certainly possible when coding directly into the IDE.
Configuring jHipster to be aware of the CheckStyle rules before autogenerating the code.
Running a script afterwards which can automatically fix any CheckStyle failures. (I'm sure this must be doable!)
It would be good to hear if anyone knows what the best way to address this issue might be and if anyone has done something similar in the past.
Suppress violations on all auto-generated files as it is out of your control.
http://checkstyle.sourceforge.net/config_filters.html#SuppressionFilter
If you have auto-generated code inside a file with non-generated code that you maintain manually, use comment suppressions.
http://checkstyle.sourceforge.net/config_filters.html#SuppressionCommentFilter
You shouldn't be styling code you don't write for this exact purpose, you aren't writing it and some utility is and it wasn't built to your style specifications. If you generate the files again, it will undo any manual changes you made.
We are experiencing a problem with our Jenkins CI server.
Our CI implementation relies on several Groovy scripts, which we execute in Jenkins as "System Groovy scripts". This has been this way for years, and the scripts have undergone no recent modifications, and implement build flows, business logic steps such as version checking, etc.
Yesterday we started experiencing an exception in every Jenkins job that we tried to lauch that, one way or another, tried to execute Groovy scripts. The exception is:
java.lang.StackOverflowError
at org.codehaus.groovy.antlr.parser.GroovyRecognizer.additiveExpression(GroovyRecognizer.java:12478)
at org.codehaus.groovy.antlr.parser.GroovyRecognizer.shiftExpression(GroovyRecognizer.java:9695)
at org.codehaus.groovy.antlr.parser.GroovyRecognizer.relationalExpression(GroovyRecognizer.java:12383)
at org.codehaus.groovy.antlr.parser.GroovyRecognizer.equalityExpression(GroovyRecognizer.java:12307)
at org.codehaus.groovy.antlr.parser.GroovyRecognizer.regexExpression(GroovyRecognizer.java:12255)
at org.codehaus.groovy.antlr.parser.GroovyRecognizer.andExpression(GroovyRecognizer.java:12223)
at org.codehaus.groovy.antlr.parser.GroovyRecognizer.exclusiveOrExpression(GroovyRecognizer.java:12191)
hundreds of similar lines
at org.codehaus.groovy.antlr.parser.GroovyRecognizer.compoundStatement(GroovyRecognizer.java:7510)
at org.codehaus.groovy.antlr.parser.GroovyRecognizer.compatibleBodyStatement(GroovyRecognizer.java:8834)
at org.codehaus.groovy.antlr.parser.GroovyRecognizer.statement(GroovyRecognizer.java:899)
at org.codehaus.groovy.antlr.parser.GroovyRecognizer.compilationUnit(GroovyRecognizer.java:757)
at org.codehaus.groovy.antlr.AntlrParserPlugin.transformCSTIntoAST(AntlrParserPlugin.java:131)
at org.codehaus.groovy.antlr.AntlrParserPlugin.parseCST(AntlrParserPlugin.java:108)
at org.codehaus.groovy.control.SourceUnit.parse(SourceUnit.java:236)
at org.codehaus.groovy.control.CompilationUnit$1.call(CompilationUnit.java:161)
at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:846)
at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:550)
at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:526)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:503)
at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:302)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:281)
at groovy.lang.GroovyShell.parseClass(GroovyShell.java:731)
at groovy.lang.GroovyShell.parse(GroovyShell.java:743)
at groovy.lang.GroovyShell.parse(GroovyShell.java:770)
at groovy.lang.GroovyShell.parse(GroovyShell.java:761)
at groovy.lang.GroovyShell$parse.call(Unknown Source)
at com.cloudbees.plugins.flow.FlowDSL.executeFlowScript(FlowDSL.groovy:80)
at com.cloudbees.plugins.flow.FlowRun$FlyweightTaskRunnerImpl.run(FlowRun.java:219)
at hudson.model.Run.execute(Run.java:1759)
at com.cloudbees.plugins.flow.FlowRun.run(FlowRun.java:155)
at hudson.model.ResourceController.execute(ResourceController.java:89)
at hudson.model.Executor.run(Executor.java:240)
at hudson.model.OneOffExecutor.run(OneOffExecutor.java:43)
This looks like that the Groovy parser inside Jenkins is reaching the top of the stack while trying to parse the groovy script (as I have said, this abruptly started to happen with many scripts that worked perfectly before and had undergone no recent modification).
Currently our Jenkins installation (v1.594) runs on a Websphere 8.5.5.2 application server on AIX v7.1 (don't know exactly the fix pack level and / or if it has recently suffered any kind of update, still trying to gather the info).
After a restart, we returned to normal behavior (all the scripts were working as usual again without any modification to them).
Does anyone know about some incompatibility of any underlying library with Jenkins Groovy parsing?
There is a problem with the groovy code; causing the parser to go nuts:
java.lang.StackOverflowError
at org.codehaus.groovy.antlr.parser.GroovyRecognizer.additiveExpression(GroovyRecognizer.java:12478)
Based on a similar ticket:
https://issues.apache.org/jira/browse/GROOVY-1783,
it is possible that your code has circular references; or creating too many functions on the fly. You can take the approach of analyzing your code and trying to put anything that is going to make allocations outside of loops; in particular complex inline functions.
Another approach is to go look at the Build Flow plugin and scroll down the documentation and see how you could write an extension point rather than use groovy. This may not be easy to do and requires effort; but you can write a lot of tests for your code that way. You would still use groovy for the glue; but use java directly for the hot spots.
A third approach would be to file a ticket on the Groovy issue tracker; and see what the experts find out.
This question came to me when developing using Eclipse.
I use JBoss Application Server and use hot code replacement. But this option requires that the 'build automatically' option to be enabled. This makes Eclipse build the workspace automatically (periodically or when a file is saved?) and for a large code base this takes too much time and processing which makes the machine freeze for a while. Also sometimes an error message is shown saying that hot code replacement failed.
The question that I have is: is there a better way to see the result of a code change?
Currently I have the following two suggestions:
Have unit tests - this will allow to run a single test and see the result of a code change. ( But for a JavaEE application that uses EJBs is it easy to setup unit tests?)
Use OSGi - which allows to add jars to the running system without bringing down the JVM.
Any ideas on above suggestions or any other suggestion or a framework that allows to do this is welcome.
Did you take a look at http://zeroturnaround.com/jrebel/?
I tell you how I work. I hope it is useful. First of all, I disable "Build Automatically". Maybe it is better if you do a simple ANT script to compile and see errors/exceptions. Also, I make jar file with the same script. Afterwards, I use OSGi to check the application. Yo do not need to stop server, only you need to change versions in deployed bundles. Intead of JBoss Server I use Equinox which includes Jetty Web Server.
May you have a nice day!
With JRebel, you wouldn't have to build your project (skip the build totally). Plus, only the changed resources will be reloaded so the update happens instantly. Plus, session is preserved so you do not have re-login to the application after the update was performed.
Even though the question I asked was quite specific to Java, I thought that mentioning using an interpreted programming language that avoids the compilation step is anther way of seeing result of a code change faster.
We have a web application which sometimes (quite rarely, several times a day) gives an
error in production. It is deployed on Tomcat, uses Spring+Hibernate, the error is caused
by a Hibernate exception which is hard to understand without actually logging the
parameters passed to the method of the Hibernate class. It is not possible to replace
the Hibernate library with a modified version which logs the parameters, and spring-aop
cannot be used since the "beans" are not managed. I have seen an example of byte code
instrumentation using javassist, on http://today.java.net/pub/a/today/2008/04/24/add-logging-at-class-load-time-with-instrumentation.html, however trying to run it under
tomcat, the instrumented code does not seem to run, probably due to classloader problems
which I currently don't understand.
What I am asking then, is this: does anyone know of a more or less simple way to instrument
the byte code under tomcat for such a task as logging the parameters of methods in
external libraries? is there some further insight you may give on this problem?
Have a look at BTrace.
It will allow you to log calls to other classes/functions without slowing down the main application.
You could (temporarily) enable JDWP on the production Tomcat, attach a debugger, and place a breakpoint on the offending code. But I'd recommend avoiding doing that on the actual production machine -- better to clone the production environment to another machine that you can tinker with.