I'm migrating my project from j2ee-1.3.jar to javaee-api-5.jar.
web.xml used to use http://java.sun.com/dtd/web-app_2_3.dtd DTD for validation now it needs to use the XSD http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd
The original web.xml as usual fails with the current XSD,while trying to install in webLogic
I have following questions -
1. Do i need to compulsory do the correction of all the elements which are not correct according to the new XSD basically servlet tags are rearranged or changed I guess.
2. Is it compulsory to have an XSD in web.xml, can I do away with the XSD definition and hence validation of the XML
Do i need to compulsory do the correction of all the elements which are not correct according to the new XSD basically servlet tags are rearranged or changed I guess.
Yes
Is it compulsory to have an XSD in web.xml, can I do away with the XSD definition and hence validation of the XML
No
References
XML 1.0 Schema: xml.xsd
Related
Apologies if the question is already posted elsewhere. I couldn't find the correct answer yet.
I am using javax.xml.bind.Unmarshaller to unmarshall a XML document into a Java Object. While unmarshalling I need to validate this XML against a pre-defined DTD to ensure the tags in the XML document are correct. Can someone let me know how to do this?
In JSF sources I found the logic of defining character encoding via facelets.Encoding attribute, which can be available in FacesContext.getAttributes()
See FaceletViewHandlingStrategy#getResponseEncoding method for details. How can I define this attribute for instance of FacesContext? I tried to define it via context-param in web.xml, but it's not working. And also I didn't find any reference about it in JSF documentation.
The main reason why I want do this, it is overriding of javax.faces.request.charset value. I don't want define a special filter for my application the order to define not UTF-8 encoding. Because my application contains a lot of WAR packages inside of big EAR.
Is there any way, xsd tags for instance, to unmarshall xsd files to get private fields with accessor methods instead of protected fields which is the default behaviour? I have tried to search in the documentation but no avail.
I am aware of the plugin plugin solution here on stackoverflow but I would like to have a xsd-tag or a built-in solution on existing technologies, not extra things to handle like writing a plugins that requires extra maintenance cost =)
Seems that the /docbook-5.0/catalog.xml (XML catalog) found in the DocBook 5.0 zip ...
http://www.docbook.org/xml/5.0/docbook-5.0.zip
references a xsd/docbookxi.xsd schema file that seems to be missing from that archive.
Is this just a placeholder for some functionality that is yet to exist, or is this a legitimate error/bug/oversight in that catalog file?
Doing some google searching for docbookxi.xsd just turns up hundreds of references to this DocBook xml catalog reference, but no reference to the actual docbookxi.xsd file / definition.
Due to limitations in the environment i'm working with, I cannot use the alternative RELAX NG versions of this schema.
Yes, that's a legitimate bug. I don't actually recall if the toolchain that built the (awful) XSD versions was ever able to produce the XInclude version.
I can try to create an XInclude version of the "by hand" XSD files. However, that will be a version 1.1 XML Schema. Is that good enough, or do you need 1.0?
[Addendum]
After some investigation, it appears to me that the UPA rule in XSD makes creating an XInclude version enormously difficult. Simply allowing XInclude at either the division level (part or reference) and the component level (preface, chapter, et. al.) violates the UPA rule because a book can start with either a division or a component.
Perhaps http://docbook.org/xsd/5.0b2/docbook-xsd10.xsd or http://docbook.org/xsd/5.0b2/docbook.xsd is what you are looking for? Since the XSD schema documents for Docbook are now maintained by hand, it may well be that there are versions of the normative Relax NG schema for which no corresponding XSD schema document is provided.
I am trying to generate java classes from sample xsd using jdk 1.6, xjc command.
But I don't want to use annotations i.e I don't want to generated java classes to contain annotations. How can I do it?
In JAXB (JSR-222) the only standard representation of the XML-binding metadata defined in the standard is JAXB annotations. Therefore an option to generate the classes without these annotations is of limited use.
I'm the EclipseLink JAXB (MOXy) lead an we do offer an XML (and JSON) representation of the JAXB metadata as an extension:
XML - http://blog.bdoughan.com/2010/12/extending-jaxb-representing-annotations.html
JSON - http://blog.bdoughan.com/2012/04/extending-jaxb-representing-metadata-as.html
If you are interested in having the ability to generate this metadata instead of annotations please request an enhancement in our bug database against the MOXy component:
https://bugs.eclipse.org/bugs/enter_bug.cgi?product=EclipseLink
This question has two parts:
In the compile time you have to generate your code differently. You can write an XJC plugin to do this.
In the runtime you have to use the JAXB implementation which works without annotations (see Blaise's answer on this part).
See this question on XJC extensibility:
XJC - is it extensible?
You can write an XJC plugin which completely replaces the code generation. So I can imagine an XJC plugin which generates XML mappings for MOXy instead of annotations in classes. You can also do this with JAXB RI using an extra annotation reader, but it is much trickier as simply using MOXy.
Be warned, however, that writing advanced XJC plugins my be quite complex.