I want to marshall and unmarshall a xsd. I have a jar say A.jar which contains one xsd file say 1.xsd. I am trying to validate it by using JAXB but it fails. 1.xsd is importing 3 more schema that is present in different jar (B. jar). How can I validate such that while validating it the 1.xsd could read the imported files that belongs to different jar (B.jar).
Assuming both jars are available on the classpath, it doesn't really matter that much whether the schema files are spread over different jars or not. If one schema imports or includes another schema, what matters is that the path can be resolved.
Suppose you have a package my.project.schemas which exists in A.jar and B.jar. In A.jar that package contains 1.xsd, which imports 2.xsd in the same package in B.jar. If the import element in 1.xsd looks like this...
<xs:import namespace="https://www.example.com" schemaLocation="2.xsd" />
then it should work. A resolver takes care of locating the other schema, and since the given schemaLocation is relative, the resolver will find it because it considers the same package across different jar files as the same location.
Things can get more complicated if there's different packages. In that case you'd need to use a relative path which may need to go up or down the package hierarchy to refer to the correct file (example: additional/2.xsd if package additional is a member of package my.project.schemas). Another option is to use a custom resolver. This lets you intercept the calls for external resources and resolve them programmatically.
Finally, note that the SchemaFactory used for creating a Schema object has a method that accepts an array of sources. If you create a Source for each schema file and supply all of them to the factory for creating a Schema object, this can avoid trouble with locations. In fact, you can just omit the schemaLocation attribute because the necessary references can be found among all the provided schemas.
In the past I've used JAXB with validating marshallers/unmarshallers that had to use schemas across different packages importing each other, which could also be across different jars. The last solution, providing a Source per schema to the factory method, was my preferred approach.
Related
In the intelliJ suite, xsd validation is performed automatically and you get an error if a given schema is not found. I tried to find an xsd file for the w3c widgets namespace but i couldn't.
If there is no such thing, what is the best practice here? Just add a rule to each file to ignore the error? (that is not a good one imo)
Generate a schema automatically from the file? (but if i add something i need to regenerate it?)
I have a number of XSDs that are part of the enterprise definitions for several services at the client.
I would like to be able to take a single XSD and generate a DDIC structure from it (without the use of PI!)
Seeing as you can generate proxies directly from a WSDL, and this also generates structures and data elements from the XSD definitions inside the WSDL, there is obviously already ABAP code that does this.
But do you know what classes/function modules to use to achieve this? Perhaps there is a convenient utility function or class method that takes the XSD as input and generates the relevant DDIC objects?
Some background on why I need this:
Some of the services include variable sections that include a piece of XML containing the data for one of the enterprise XSD entities; I am hoping to have a DDIC representation of these, which I can fill at runtime and then convert to XML to include in the message.
There is a program on the system called SPROX_XSD2PROXY with which you can upload one or more XSD files which will generate proxy objects for you.
You also end up with a service consumer with a corresponding class and what looks like a dummy operation.
The program is fairly short; it uploads the files(s) to an XSTRING, then converts the XSD(s) to WSDL(s) and finally the WSDL(s) to proxy objects using methods of a class called CL_PROXY_TEST_UTILS.
However, the result is satisfactory as it does give me a structure I can work with. And by examining the contents of those methods, it may be possible to build a more fine-tuned tool if I need one.
Is there a way to generate an XSD document automatically from the binding.xml used by JIBx? This is mainly to allow offline validation of the XML documents will be unmarshalled eventually.
I checked the JIBx homepage, it mentioned a tool called Schema Generator:
http://jibx.sourceforge.net/jibxtools/schema-example.html
but looks like the jibx-genschema.jar file is no longer part of the package anymore, as such I was wondering if there is any alternative
Thanks!
Here is the link to the original package.
http://mirrors.ibiblio.org/pub/mirrors/maven2/org/codehaus/xfire/jibx/genschema/jibx-genschema.jar
Schema generator main class is org.jibx.binding.Compile. It is available in jibx-bind.jar.
This jar can be added to your project with maven dependency org.jibx:jibx-bind:1.2.3 (for example).
The SchemaGen tool has been included in the jibx-tools.jar file for some time. See the JiBX Binding Generator page for instructions on running tools in the jar, just substitute the target class org.jibx.schema.generator.SchemaGen to run the schema generator.
I'm attempting to use svcutil.exe to generate -only- the service contracts (interfaces) from a set of .wsdl files. When I do this (from an http-hosted wsdl), it picks up the included schemas and generates all the code for them.
Great.
What I would REALLY like to do, however, is to use a set of classes already generated from the schema files using the xsd.exe tool (the reasons for this are not important, suffice it to say that I need to have the types in one assembly, and the service contracts in another). I was successful in generating an assembly containing all the types.
The problem occurs when I attempt to get svcutil.exe to use the types in that assembly. My command line looks something like this:
svcutil /target:code /noconfig /reference:my_types.dll http://path/to/wsdl
This works fine, but the generated code contains duplicates of all the types in the my_types.dll file. It is my understanding from the documentation for svcutil.exe that this is the exact problem that the /reference: parameter is meant to overcome. In my case, however, it is not working.
Why?
Apparently it only works for DataContract types and not XmlSerializer types.
Link
I had this problem. Something in a binary that I was referencing with /r was still being built again in the generated code. One of the objects being returned from one of the service functions was returning a datatable or some other horrid thing like that. I added a /r to the whole path to System.Data and that fixed it.
/r:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5.2\System.Data.dll"
When generating my DAL files with SubSonic, I'd like the names of the files to be .gen.cs. The main reason for this is that the files are partial classes, and I would like to add some additional implementation details into another source file for the table called .cs. This is somewhat the standard pattern for generated source files , and I'm wondering if its possible with SubSonic? I'm using SubSonic 2.2.
I thought you might be able to do this by using a set of custom templates, but the CS_ClassTemplate.aspx (or VB_ClassTemplate.aspx) doesn't control the file name of the class.
I don't think this is possible.
As an alternative, you can do what I do. I have a "generated" directory, such as \database\generated and then I put my partial classes at \database\custom. As long as the namespaces of the files in the two different directories match (like .database or whatever), then it works fine. By using two different directories, it's easier to find your custom files without looking at the generated ones.