From what I believe and have read online. Sun has decided to include Xalan in JDK 1.5. I am trying to take advantage of this and try to perform an XSLT to spit out multiple files. The problem I encounter:
'Unrecognized XSLTC extension 'org.apache.xalan.xslt.extensions.Redirect:write''"
From what I have read on google that i needed to change:
xmlns:redirect="org.apache.xalan.xslt.extensions.Redirect"
to
xmlns:redirect="http://xml.apache.org/xalan/redirect"
in XSL transforms
When I apply this change to my .XSL File, I appear to be getting the same error. Need to get this working ASAP and can't seem to find an answer online. Any help will be greatly appreciated.
Just ignored the JDK's default Xalan. I just added the files from Xalan. Better, that way I can just use that rather than depending on a single JDK.
Related
I'm writing documentation for my java file. In that documentation, I want to add some html links at the end of each generated file. For that, what I have to use while writing java documentation?
If you are using Eclipse as IDE, you can use the plugin JAutodoc:
http://jautodoc.sourceforge.net/
To add a default text at the beggining of each text file.
According to the javadoc manual (can't find a newer version right now), you should use -footer when you generate your java API documentation from the CLI, for instance:
javadoc -footer "<b>Copyright 2015 Lakshmi Prasanna</b><br>" com.mypackage
Here's a similar example, but that uses -header instead.
Now, if you use a good IDE, at the very least it should allow you to type that somewhere in the project settings. Back in the day Eclipse wasn't very flexible, so I had to make an Ant script (yuck).
EDIT:
One limitation with this approach is that the CLI -options depend on the tool. This works with the standard javadoc command but might not work with another vendor's doclet. However I'm not sure there's a universal way to achieve what the OP asked.
Anyway, it seems to be: NOT -footer but -bottom.
I'm running a webapp in Tomcat 8 that uses OpenSAML. I've endorsed Xerces within Tomcat, I've checked that the endorsed dir path is set right, it appears that everything is working fine:
[ajp-apr-8009-exec-22] DEBUG org.opensaml.xml.Configuration - VM using JAXP parser org.apache.xerces.jaxp.DocumentBuilderFactoryImpl
I get several requests that work just fine, everything seems great, I can run through that section of code without error, then all of a sudden, I start getting this error:
OpenSAML requires an xml parser that supports JAXP 1.3 and DOM3.
The JVM is currently configured to use the Sun XML parser, which is known
to be buggy and can not be used with OpenSAML. Please endorse a functional
JAXP library(ies) such as Xerces and Xalan. For instructions on how to endorse
a new parser see http://java.sun.com/j2se/1.5.0/docs/guide/standards/index.html
at org.opensaml.xml.Configuration.validateNonSunJAXP(Configuration.java:278)
at org.opensaml.xml.parse.BasicParserPool.<init>(BasicParserPool.java:126)
Once I start getting the error, I will get an error every time but I haven't been able to isolate what it takes to trigger the problem. (Edit: it appears that this may be related in some way to docx4j usage, the errors start after a request that uses docx4j to generate a file as a word document. Since docx4j is so reliant on XML, this maybe makes some sense.)
Basically, what validateNonSunJAXP() does is pretty simple. All it does is check the class name for the DocumentBuilderFactory and if it starts with "com.sun", it throws the error.
Any ideas on what could be going on that would cause the VM to stop using the endorsed library?
docx4j manipulates:
javax.xml.parsers.SAXParserFactory
javax.xml.parsers.DocumentBuilderFactory
javax.xml.transform.TransformerFactory
You can see what it does, at https://github.com/plutext/docx4j/blob/master/src/main/java/org/docx4j/XmlUtils.java
javax.xml.parsers.SAXParserFactory
In summary, you can prevent docx4j from touching this value via a docx4j properties setting.
We found Crimson fails to parse docx4j XSLT files, which is why docx4j by default tries to use Xerces, where it is included in the JDK. (Things may be better in more recent JDKs)
If you don't want this, you can specify different behaviour via docx4j.properties:
docx4j.javax.xml.parsers.SAXParserFactory.donotset=true stops docx4j from changing the setting, or
javax.xml.parsers.SAXParserFactory allows you to specify what you want
Note that we don't restore the value to its original setting since we want to avoid Crimson being used for the life of the application.
javax.xml.parsers.DocumentBuilderFactory
This works similarly to SAXParserFactory
The relevant docx4j properties are as follows:
docx4j.javax.xml.parsers.DocumentBuilderFactory.donotset
javax.xml.parsers.DocumentBuilderFactory
We don't restore the value to its original setting (though maybe we could; would need to review whether docx4j always uses XmlUtils.getNewDocumentBuilder() )
I tried to use CEDET to get auto completion in Emacs and that works fine for C/C++. But I cannot find anything about how to use CEDET with Java without the help of JDEE, which is thought out of date and not compatible to CEDET 1.1. I got a tags file using utility found here but I don't know how to integrate that into CEDET system. According to CEDET's website, that's possible. But they don't explain how to do it. Is there someone willing to answer this question?
Here is some sample of the tags file generated by that utility:
java.applet.Applet$AccessibleApplet
protected java.applet.Applet$AccessibleApplet(java.applet.Applet)
public java.applet.Applet$AccessibleApplet.getAccessibleRole() returns javax.accessibility.AccessibleRole
public java.applet.Applet$AccessibleApplet.getAccessibleStateSet() returns javax.accessibility.AccessibleStateSet
It is possible to have CEDET pull in tags from a .jar file. It works by using javap to extract the tags in text form, and then it parses that data.
It isn't very easy to set up since in CEDET, the concept of where to find your library files is part of EDE, the project management system, not the parser and smart completion system. The only Java based project supported in CEDET 1.1 is Android.
The basics is to first enable the javap database by loading it with (require 'semanticdb-javap) in CEDET 1.1, or (require 'semantic/db-javap) in the bzr version of CEDET.
Once you've done that, you can configure it via the cedet-java-classpath-extension. I'm a little fuzzy on the details of what happens next, but folks have reported success on the mailing list.
If you use CEDET from the bzr repository, there is the ede-java-root project, which is similar to the ede-cpp-root project. That project type lets you configure what your library path is. The doc for that is in the ede/java-root.el file with the project type, and shows you the basics of how to use it.
My issue is summed up nicely here, http://tech.groups.yahoo.com/group/jena-dev/message/33894 which also proposes a solution. Problem is stated solution requires access to the code, and I'm only working with a binary distribution of the software. Anyone know what else I can do, if there's a jar file I can download from somewhere/add to classpath? There's various versions of XercesImpl.jar that I've tried, all resulting in various other errors. Any help greatly appreciated!
Apache Jena currently depends (at compile and runtime) on Apache Xerces (i.e. xerces:xercesImpl:2.10.0) therefore Apache Xerces cannot be removed without source code changes.
Xerces is used for RDF/XML parsing and for Datatypes.
In an ideal world, the RDF/XML parsing could be in a separate module (i.e. jena-rdfxml) which would continue to depend on Apache Xerces and the Datatypes would need to be reimplemented without relying on Apache Xerces. This way, you could use a jena-core module with no support for RDF/XML and not dependency on Apache Xerces.
May I ask you why you need or want to remove xercesImpl.jar from your classpath?
See also:
https://issues.apache.org/jira/browse/JENA-189
https://issues.apache.org/jira/browse/JENA-191
Since 3.8.0, Jena no longer depends on Xerces: https://issues.apache.org/jira/browse/JENA-1537
I was just wondering if anyone had any success in getting XMLBeans (or any other generator) to work on android. It would be very nice if I could use it because I have a very large schema that I would rather not write all the classes by hand.
I had asked about this on the android developers mailing list, but no one responded. This tells me that either they don't care, or no one feels like telling me its not possible.
If anyone knows of anything else like XMLBeans that works for android, please let me know. It would be very helpful.
Thanks,
Robbie
If you're looking to do class generation and DOM parsing, XMLBeans is probably pretty heavy-weight for a mobile device running android. All of the code generated by XMLBeans makes synchronized calls into an underlying data store that I've seen as a hot spot several times when profiling.
I can't suggest any alternatives, but I would be wary of using this even if you could get it to work, because of the afore mentioned performance issue.
You can use Castor . Just be sure, in Android 2.1, not to use default android SAXParser. You'll get namespace errors. You do this by defining the parser to be, for example, Xerces (and the you add the required JARS), in core.properties .
In android 2.2 it may be ok.
Note that if you create an xmlcontext for the unmarsheler with xerces, it still won't work, as the mapping itself would be parsed with android's SAX. It must be done at core (top level properties file) so that even the mapping is parsed by xerces.
finally - performance is as slow as you can expect... :(
Good luck
SM
I got JAXB working on Android.