In general I have my dsl as plugin and I want to create a new app that use my dsl
so i tried to write this code:
JsonParser p = new JsonParser();
IParseResult r = p.parse(new StringReader("{}"));
//once that work it will be the file data instead of {}
but when i do the parse the node model builder is null and the following line has exception:
return doParse(ruleName, in, nodeModelBuilder.get(), 0);
and i'm not sure how to init nodeModelBuilder
i'm sure i missing some steps but i'm not quite familiar with the xtext process.
thanks!
You already read the following answer on Eclipse Forum. You need to create an IParser instance by injecting it. All dependencies gets also injected. The necessary bindings are described in your JsonRuntimeModule. Xtext uses Guice and theses Modules to glue everything together. This pattern is called Dependency Injection.
... I want to create a new app that use my dsl
So you want to use your Json DSL in standalone mode.
My suggestion:
Create a minimum Eclipse IApplication with CLI that reads and parses an input file. The advantage of an Eclipse IApplication is that you can easily deploy an headless version of your DSL runtime. [1]
Have a look at your JsonInjectorProvider and the ParseHelper [2] from Xtext's JUnit support for examples how to use your DSL and Xtext runtime in standalone mode.
[1] http://www.eclipsezone.com/eclipse/forums/t99762.html
[2] org.eclipse.xtext.junit.util.ParseHelper
You are not supposed to call parser directly. See:
http://wiki.eclipse.org/Xtext/FAQ#How_do_I_load_my_model_in_a_standalone_Java_application.C2.A0.3F
The code should look like:
Injector injector = new MyDslStandaloneSetup().createInjectorAndDoEMFRegistration();
XtextResourceSet resourceSet = injector.getInstance(XtextResourceSet.class);
resourceSet.addLoadOption(XtextResource.OPTION_RESOLVE_ALL, Boolean.TRUE);
Resource resource = resourceSet.getResource(new File("/../../some.json").toURI(), true);
Model modelRootElement = (Model) resource.getContents().get(0);
Replace MyDsl with 'JsonParser' or 'Json' or whatever is your DSL name. Look for class JsonStandaloneSetup or JsonParserStandaloneSetup in your DSL source code. This class is generated when you start the Xtext project (or when you run workflow for the first time, not sure now). Replace Model with whatever is your root element type. It must be EObject subclass.
The parsing/validation/buidling AST is done resource.getContents() command. Not very intuitive, I know. It is because you have to initialize context, all sorts of contexts i fact, Guice context, EMF context, and perhaps other, all encapsulated in the StandaloneSetup (and RuntimeModule). The context is similar to Spring Application Context.
You need to use StandaloneSetup to run in standalone mode.
See this tutorial for help
Related
I recently switched my logback configuration file from logback.xml to logback.groovy. Using a DSL with Groovy is more versatile than XML for this sort of thing.
I need to analyse this file programmatically, like I analysed the previous XML file (any of innumerable parsing tools). I realise that this will be imperfect, as a DSL config file sits on top of an object which it configures and must be executed, so its results are inevitably dynamic, whereas an XML file is static.
If you want to include one Groovy file in another file there are solutions. This one worked for me.
But I'm struggling to find what I need from the results.
If I put a function like this in the DSL file ...
def greet(){
println "hello world"
}
... not only can I execute it (config.greet() as below), but I can also see it listed when I go
GroovyShell shell = new GroovyShell()
def config = shell.parse( logfileConfigPath.toFile() )
println "config.class.properties ${config.class.properties}"
But if I put a line like this in the DSL file...
def MY_CONSTANT = "XXX"
... I have no idea how to find it and get its value (it is absent from the confusing and copious output from config.class.properties).
PS printing out config.properties just gives this:
[class:class logback, binding:groovy.lang.Binding#564fa2b]
... and yes, I did look at config.binding.properties: there was nothing.
further thought
My question is, more broadly, about what if any tools are available for analysis of Groovy DSL configuration files. Given that such a file is pretty meaningless without the underlying object it is configuring (an object implementing org.gradle.api.Project in the case of Gradle; I don't know what class it may be in the case of logback), you would have thought there would need to be instrumentation to kind of hitch up such an object and then observe the effects of the config file in a controlled, observable way. If Groovy DSL config files are to be as versatile as their XML counterparts surely you need something along those lines? NB I have a suspicion that org.gradle.tooling.model.GradleProject or org.gradle.tooling.model.ProjectModel might serve that purpose. Unfortunately, at the current time I am unable to get GradleConnector working, as detailed here.
I presume there is nothing of this kind for logback, and at the moment I have no knowledge of its DSL or configurable object, or the latter's class or interface...
The use of def creates a local variable in the execution of the script that is not available in the binding of the script; see this. Even dropping def will not expose MY_CONSTANT in the binding because parsing the script via GroovyShell.parse() does not interpret/execute the code.
To expose MY_CONSTANT in config's binding, change def MY_CONSTANT = "XXX" to MY_CONSTANT = "XXX" and execute the config script via config.run().
Unlike inclusion of global.jsp with every component jsp in CQ5, sightly does not include any such dependency. How does it actually access all the global objects. What is the backend process of it. And how sightly code compiles to java??
how sightly code compiles to java?
Sling sightly API has two bundles to support this, the first step is to compile sightly into Abstract Syntax Tree (The Abstract Syntax Tree maps plain Java source code in a tree form. This tree is more convenient and reliable to analyse and modify programmatically than text-based source.) This is done by Apache Sling Scripting Sightly Compiler
Next is to convert (transpile) the Abstract Syntax Tree into java source code. This is achieved in bundle Java Compiler
How does it actually access all the global objects.
To understand this you need to understand how script resolution occurs in Sling and how are resource resolved to scripts which is core to Sling Scripting engine. To understand basics of ScriptEngine look at java docs here, implementation of this is SightlyScriptEngine
The way script resolution works is that the resource is adapted to DefaultSlingScript , this is done by SlingScriptAdapterFactory.
SlingScriptAdapterFactory has references to BindingsValuesProvider which is passed to the DefaultSlingScript. One of the implementation of BindingsValuesProvider is AEMSightlyBindingsValuesProvider (you can see this as a service in /system/console/services) which provides the default objects.
The DefaultSlingScript then responsible for invoking SightlyScriptEngine and calling its method eval which populates the default objects in binding and then setting this binding as request attribute.
As described in Can't call one closure from another, I am using a pluggable script from within a Grails app.
Unfortunately, I've found that I can't use log4j from within these scripts. I am forced to use println.
I tried using
import org.apache.commons.logging.LogFactory
def Log log = LogFactory.getLog(getClass())
but I got no output. When I print out the result of the call to getClass(), I get something like
myscript$_run_closure5
So I'm thinking the issue is that there is no configuration in my Grails Config.groovy file for this class.
Is there a way for me to programmatically add these pluggable scripts to the log4j configuration? Keep in mind that I do not know in advance what the names of the scripts are, so this has to happen at runtime.
Consider the following code:
import org.apache.log4j.Logger
// ...
Logger log = Logger.getLogger('MyPlugin')
new File( grailsApplication.config.externalFiles ).eachFile { file ->
Binding binding = new Binding()
binding.variables.log = log
GroovyShell shell = new GroovyShell(binding)
shell.evaluate(file)
strategies.put( binding.variables.key, binding.variables )
}
Explanation:
It is not obligatory to pass class name to getLogger, it can be actually any string. You just need to make sure that this string is matched in log4j.properties of the main program.
You pass once created log to plugin scripts via binding variable "log". Then plugin scripts can access it simply as log.info('test123')
My personal recommendation would be to use logback instead of log4j. Both libraries were developed by the same guy and it is stated that logback supersedes log4j.
I developed a DSL which I use together with standard java code.
In my DSL I can write things like this:
package: packagename;
method: void testMethod (int, double);
What I want to do, is that the user of the DSL can only write package names and method signatures which already exist in the Java project.
Example:
When my project only consists of one package e.g. “TestPackage”, the user of the DSL should only be able to write:
package: TestPackage
the name “TestPackage” should also be suggested by the code completor. The same shall also work with the methods.
Is it possible? And how can I do this with Xtext?
I've not used it (yet), but take a look at the relevant Xtext documentation on this. Also, I'd look through the "7 Languages", find one that does what you want (which I think you'll find), and study the source.
Update: as of Grails 1.3.6 one has access to the full domain from Gant scripts.
From the Grails 1.3.6 release notes:
You can now run one or more Groovy scripts from the commandline using the run-script command, e.g.
grails run-script [path-to-script-1] [path-to-script-2]...[path-to-script-n]
This works around the issue in Gant scripts where you can't conveniently access application classes since they're not available in the classpath when the scripts start.
Hi all,
I am new to using Grails (in a real project) and I have a one-off script I need to execute that reads a file and then populates my database.
I wanted the script to run in the context of my grails app, so I used the create-script command. I now understand that makes it a 'Gant' script. The reason for doing so was that I thought it would allow me easy access to all the grails domain good-ness, so that i would be able to do something like this easily:
Car car = new Car(model: 'bar', brand: 'Ford')
car.save()
Here, Car is one of my domain classes and the strings 'bar' and 'Ford' I have retrieved from my file.
The start of my script looks like this:
import com.foo.Car
grailsHome = Ant.project.properties."environment.GRAILS_HOME"
includeTargets << new File ( "${grailsHome}/scripts/Bootstrap.groovy" )
target(main: "a script for storing cars") {
depends(bootstrap, classpath) // code dealing with the file with cars follows
Surprisingly, groovy gives me a java.lang.NoClassDefFoundError: com.foo.Car when I execute the script with the command grails LoadCars
Am I taking the wrong approach, or is there something more simple I am doing wrong?
Any help is appreciated
i know the scripts are useful, and I will probably get hate mail for even suggesting it, but I have just incorporating this kinda of stuff directly into my application in the past.
I have a flag set in my configuration which indicates if the data should be bootstrapped, if so, the bootstrap code looks for a comma delimited file at startup and calls a service method to load up the data.
I've updated the grails run-script Gant script (referred to by Jared above) to work with grails 1.3.5. I'd been meaning to do it for a while, but this question nudged me into finally getting around to it).
Just download the script described in the post, save it in your grails "scripts" directory and you can then run your own groovy script to bootstrap data with:
grails run-script script-path/boostrapMyDataIntoApp.groovy
I've had to do this and you have to create a special script to allow you to access GORM from a standard grails script. See this question for more info. I'm not sure what the current status of the script is under grails 1.3 but the author of the script posted in the comments.
Hans, there are several choices here, assuming you are not out to polish the GANT scripting chops 8^)
So assume that you are doing some integration-mode TDD, correct?
Have you looked into the db-stuff plugin? Actually that one leverages the open source package (extension of the JUnit project) called dbUnit, which is also an outstanding choice, for both Java and Groovy projects.
*db-stuff <0.3.0> -- db schema managment and data import/export. Generate generic schema files and import or export base/seed/test data into your database.
I have traditionally done this as well in the BootStrap depending on the environment - and I try to never let those domain assumptions / constraints get too far out of synch. with my schema.
Here's the canon I'm talking about :
class BootStrap {
def init = { servletContext ->
if (GrailsUtil.environment.equals( GrailsApplication.ENV_DEVELOPMENT )) {
log.info( "Loading sample data for 2010 models..." );
new Car( manufacturer: new Manufacturer( name: "Toyota" ), model: "Prius" )
new Car( manufacturer: new Manufacturer( name: "GM" ), model: "Volt" )
//...