I am trying to create Java bindings for EDIFACT messages using Smooks. In particular, I want to automatically generate Java classes and corresponding mappings using Smooks. To this end, Smooks 1.x provides the EDIFACT-to-Java-Compiler (EJC).
With the upcoming version 2, Smooks relies on schemas written in the Data Format Description Language (DFDL) to specify EDIFACT messages instead of Smooks-specific schemas used in v 1.x. To my understanding, this means that EJC v1.x cannot be used to generate EDIFACT bindings for Smooks v2. Is this correct?
If so, what is the preferred way to generate bindings? Will there be an upcoming EJC v2? Or should I use the XML Schema Compiler (XJC) to generate Java classes and then either map them directly in Smooks, or do a two-step transformation EDIFACT -> (Smooks v2) -> XML -> (JAXB) -> Java?
Thanks for your insights!
Is this correct?
Yes.
Or should I use the XML Schema Compiler (XJC) to generate Java classes
and then either map them directly in Smooks, or do a two-step
transformation EDIFACT -> (Smooks v2) -> XML -> (JAXB) -> Java?
That's the recommended approach as discussed in the Smooks user forum. The Java bindings for many of the EDIFACT versions have already been generated ahead of time and can be pulled down from the public Maven repository as shown in one of the Smooks examples.
Related
As far as I can tell, the Terraform SDK does not support an interface type. In my case I'm using a data resource to reach out to an API and pull JSON data. I would like to put that data in an attribute for later use in a resource but the problem is the JSON response has a large dictionary filled with different types. In GoLang this is no problem because you can set the map type to Interface{}. It would seem however that terraform only allows you to set the following types in a schema:
TypeInt
TypeString
TypeBool
TypeFloat
TypeInvalid
TypeList
TypeMap
Without support for interface how would you go about doing this correctly? The very ugly hack I have right now is converting everything to a string and then fixing the type once it is passed to the resource.
I asked on Hashicorp's forums and received a phenomenal answer here.
The synopsis is that casting to a string is currently the best solution. However there is a team working on making a new SDK design which would support newer capabilities to include arguments with dynamically chosen types.
As Karate supports type conversion, I was wondering if it is possible to write a custom type conversion in such a way that I could write something similar to this in my .feature file
customType customTypeResponse = response
which should have the same semantic as
yaml yamlResponse = response
but for customType instead of yaml.
I think I found the code enabling the custom type conversion. But I am not sure about the extensibility.
Thus the shortest way might be to use the Java interop enabling something like this
def customTypeResponse = CustomType.convert(response)
Please let me know of any possibiliy of type conversion.
Yes, I strongly suggest just using Java interop and not complicating it further for now. Maybe in the future we'll have a better way to do contribute custom syntax (hint: look for the Plugin interface and how karate-robot uses it).
In NiFi, I have a flow file with an attribute RSID. I need to generate a UUID v5 based on RSID and add it as an attribute to the flow file. This uuid needs to be based on RSID because some reports will have the same RSID and need to thus have the same UUID5.
I've seen some methods in Groovy that will generate a random uuid, but not v5 nor based on a string. Is this possible to do in Groovy/NiFi? If so, how would this be done? I'm very new to Groovy.
You can indeed do this with Groovy and NiFi using the ExecuteScript processor. This SO post includes the code for generating a UUID v5 which you can apply to your RSID namespace. If you want some pointers on using the NiFi API from ExecuteScript, feel free to check out my cookbook series, hopefully it will help you assemble a working solution.
I have also written a Jira to add a UUID5 function to NiFi Expression Language, to make this easier.
In my current work, I have written code generator using String Template without thinking about Parser ( I am instantiating Template files using direct Java Object). and code generator generator generates nice Java code.
Now, I have started to write Parser. B'coz of some nice editor features of xText, I am thinking to write parser in Xtext.
My question is "Is it possible to use code generator ( written using StringTemplate ) and Parse (written in Xtext) in same project?
Yes that's possible. Xtext offers a typed AST for the parsed files and you could easily pass them to your code generator (directly, iff they fulfil the same contract / interfaces, or indirectly by transforming them to the expected structure). Xtext does not impose any constraints on how you want to use the parsed information.
I have a project that does JAXB generation with framework.xsd. This generates a jar with the xsd and the jaxb objects and other classes around that stuff.
Then another group(two different groups) will be extending framework.xsd and subxmling using the schema extends stuff to extend objects in framework.xsd. They also want to generate jaxb objects BUT they want their SomeClass.java to obviously extend my Framework.java and don't want to end up with a whole new heirarchy.
Is this even possible?
How to do something like this? as the solution would need to
tell the jaxb compiler that the namespace yy is already generated so do not generate
tell the jaxb compiler that it needs to refer to the classes in the package zzzzzz or to look at the xjb file from the framework jar file or something.
Is this possible?
thanks,
Dean
You want to use an episode file : http://weblogs.java.net/blog/kohsuke/archive/2006/09/separate_compil.html when generating JAXB classes for your first schema.
$ xjc -episode framework.episode framework.xsd
Then the other group that consumes your framework.jar should:
1) import your schema in their own schema e.g.:
<xsd:import namespace="http://www.myorg.com/framework" schemaLocation="framework.xsd"/>
2) generate their JAXB classes
$ xjc extend.xsd -b framework.episode
(they'll need a copy of your xsd and episode file at xjc time, as well as the framework.jar in the classpath)
Note that according to the blog post above, you can also place the framework.episode file inside your jar (e.g. /META-INF/sun-jaxb.episode for JAXB RI at least - other JAXB impl may have other ways of accomplishing the same thing), so that the -b framework.episode option can be omitted. I personally find it a bit impractical, you still need the XSD anyway.