I'm using kXML2 on a legacy JavaME project.
I'm receiving an XML where some attributes contain encoded entites. When I retrieve that attribute value with the call:
parser.getAttributeValue
It throws an Exception:
XmlPullParserException: unresolved
I have downloaded the last version of this parser, but it still shows this behavior.
If I remove the problematic line from XML, then there are no errors.
Ok, here is what is happening:
The parser must decode entities in attributes, unless you set this property:
parser.setFeature(KXmlParser.FEATURE_PROCESS_DOCDECL, true);
But this implementation throws an exception when that line is called. Allright, so I debugged into the parser source code and I found out that this pull-parser implementation has trouble with entities that are not very common.
So I must inflate the parser entity replacement map with my own "odd" entities for it to work, like this:
parser.defineEntityReplacementText("Ntilde", "Ñ");
And then everything works fine.
Related
I'm trying to generate a report with Jasper Reports 5.6.0 but I always end up getting two exceptions of the following sort:
UIDefaults.getUI() failed: no ComponentUI class for: javax.swing.JEditorPane[,0,0,0x0,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=0,maximumSize=,minimumSize=,preferredSize=,caretColor=,disabledTextColor=,editable=true,margin=,selectedTextColor=,selectionColor=,kit=,typeHandlers=]
java.lang.Error
at javax.swing.UIDefaults.getUIError(UIDefaults.java:731)
at javax.swing.MultiUIDefaults.getUIError(MultiUIDefaults.java:130)
at javax.swing.UIDefaults.getUI(UIDefaults.java:761)
at javax.swing.UIManager.getUI(UIManager.java:1016)
at javax.swing.text.JTextComponent.updateUI(JTextComponent.java:338)
at javax.swing.text.JTextComponent.<init>(JTextComponent.java:312)
at javax.swing.JEditorPane.<init>(JEditorPane.java:196)
at javax.swing.JEditorPane.<init>(JEditorPane.java:288)
at net.sf.jasperreports.engine.util.JEditorPaneHtmlMarkupProcessor.convert(JEditorPaneHtmlMarkupProcessor.java:80)
at net.sf.jasperreports.engine.fill.JRFillTextElement.processMarkupText(JRFillTextElement.java:1018)
at net.sf.jasperreports.engine.fill.JRFillTextField.evaluateText(JRFillTextField.java:546)
at net.sf.jasperreports.engine.fill.JRFillTextField.evaluate(JRFillTextField.java:488)
at net.sf.jasperreports.engine.fill.JRFillElementContainer.evaluate(JRFillElementContainer.java:259)
at net.sf.jasperreports.engine.fill.JRFillBand.evaluate(JRFillBand.java:456)
at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillColumnBand(JRVerticalFiller.java:2067)
at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillDetail(JRVerticalFiller.java:788)
at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillReportStart(JRVerticalFiller.java:298)
at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillReport(JRVerticalFiller.java:152)
at net.sf.jasperreports.engine.fill.JRBaseFiller.fill(JRBaseFiller.java:963)
at net.sf.jasperreports.engine.fill.JRBaseFiller.fill(JRBaseFiller.java:892)
at net.sf.jasperreports.engine.fill.JRFiller.fill(JRFiller.java:114)
at net.sf.jasperreports.engine.JasperFillManager.fill(JasperFillManager.java:668)
at net.sf.jasperreports.engine.JasperFillManager.fill(JasperFillManager.java:649)
at net.sf.jasperreports.engine.JasperFillManager.fillReport(JasperFillManager.java:971)
Despite the exceptions, the report is generated, but with two missing fields, both of which should be filled with the value of the same object property. And since I have two exceptions that are exactly the same, I suspect the exceptions are the reason these fields are missing.
I have checked the object passed to Jasper Reports and the property that fills the missing fields has a value, so I believe it's not a coding problem.
I know that it'd be easier if I put the content of the .jrxml file in here but it belongs to a client, so that will not be possible. Still, any help would be appreciated.
The application is an API running on Fuse Karaf 7.3.
I am trying to update UCLASS field value using "BAPI_USER_CHANGE" through JCO, but getting below error:
com.sap.conn.jco.JCoRuntimeException: Field UCLASS is not a member of BAPIUCLASS
Here is my code to set the value:
JCoStructure license = params.getStructure("UCLASS");
license.setValue("UCLASS", changes.get(0).getCurrent());
JCoStructure licenseX = params.getStructure("UCLASSX");
licenseX.setValue("UCLASS", 'X');
Can you please tell me this comes under which Structure? tried also with "LOGONDATA" and "ADDRESS".
Logon with a SAP GUI and use transaction SE37 to display the parameters and structures of the RFM BAPI_USER_CHANGE.
The ABAP workbench offers forward navigation. So if you would like to see how this UCLASS structure looks like, go to the Import tab of the RFM BAPI_USER_CHANGE and double-click on the Associated Type BAPIUCLASS.
You are correctly getting the error message because there is no field with name UCLASS in the RFM parameter UCLASS (which is a JCoStructure).
Instead of this, license.setValue("LIC_TYPE", "XY"); would be valid here, for example.
If you want to set another structure as a whole, you would have to use
params.setValue("UCLASS", myJCoStructure);.
Solr version is 5.4.1
I posted this to http://localhost:8983/solr/default-collection/update and it treated it like I was adding a whole document, not a partial update:
{
"id": "0be0daa1-a6ee-46d0-ba05-717a9c6ae283",
"tags": {
"add": [ "news article" ]
}
}
In the logs, I found this:
2016-02-26 14:07:50.831 ERROR (qtp2096057945-17) [c:default-collection s:shard1_1 r:core_node21 x:default-collection] o.a.s.h.RequestHandlerBase org.apache.solr.common.SolrException: [doc=0be0daa1-a6ee-46d0-ba05-717a9c6ae283] missing required field: data_type
at org.apache.solr.update.DocumentBuilder.toDocument(DocumentBuilder.java:198)
at org.apache.solr.update.AddUpdateCommand.getLuceneDocument(AddUpdateCommand.java:83)
at org.apache.solr.update.DirectUpdateHandler2.doNormalUpdate(DirectUpdateHandler2.java:273)
at org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:207)
at org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:169)
at org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:69)
Does this make any sense? I sent updates just fine a day or two ago like that, now it is acting like the update request is a whole new document.
UPDATE The answer I selected put me in the right direction. What I had to do to correct it was load all of the existing fields that are required fields and add them to the payload myself. It then worked for me. It was not automatic, which suggests that it might be a bug in Solr 5.4.1
If I'm not wrong, an update request always ends up in add operation. The difference with partial update is that Solr initially get the document from the index, then overrides fields according to the request parameters, and finally performs a usual document indexing.
The document is rejected because required field data_type is missing: it should be defined as stored=true in schema.xml or added to the partial document fields every time a partial update occurs. Actually the same applies to all fields.
EDIT : This is not true anymore since Solr introduced In-Place Updates.
My problem is with parsing an XSD Schema that has elements with maxOccurs larger than 5000 (but not unbounded).
This is actually a know issue in either Xerces (which I'm using, version 2.9.1) or JAXP, as described here: http://bugs.sun.com/view_bug.do;jsessionid=85335466c2c1fc52f0245d20b2e?bug_id=4990915
I already know that if I changed the maxOccurs numbers in my XSD from numbers larger than 5000 to unbounded all works well. Sadly, this is not an option in my case (I cannot meddle with the XSD file).
My question is:
Does someone know some other workaround in Xerces for this issue? Or
Can someone recommend another XML parser that does not have this limitation?
Thanks!
I had the same problem. I used this:
System.setProperty("jdk.xml.maxOccurLimit", "XXXXX");
I have found a solution that doesn't require changing the parser.
There is a FEATURE_SECURE_PROCESSING feature which puts that 5000 limitation on maxOccurs (along with several others).
And here is the document describing the limitations: http://docs.oracle.com/javase/7/docs/technotes/guides/xml/jaxp/JAXP-Compatibility_160.html#JAXP_security
I came across this thread when looking for solutions for this problem when using xjc command in console.
For anyone who is using xjc command to parse xsd, this works for me:
$ xjc -nv foo.xsd
Be aware though:
By default, the XJC binding compiler performs strict validation of the source schema before processing it. Use this option to disable strict schema validation. This does not mean that the binding compiler will not perform any validation, but means that it will perform a less-strict validation.
So if you think your xsd is from a good source, using less strict validation should not be a problem.
If you use Eclipse IDE with the Dali plugin for JAXB you may obtain the aforementioned error in the console.
Such error can be avoided if you uncheck 'Use strict validation' on panel 'Classes Generator Options' when establishing the options for JAXB generation from a XSD file.
Such panel is the third one after 'Java Project' and 'Generate classes from Schema'.
Adding the additional argument -nv suggested by #minjun-yu also works. Instead of applying my first suggestion, you can set such argument in the fourth panel labeled 'Classes Generator Extension Configurations'
On parsing data to load the JAXB generated classes, if you are validating against a schema, you still may obtain the SAXException. As pointed by #mzywiol and #marioosh, the exception is avoided setting a special feature on creating the SchemaFactory
SchemaFactory sf = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
// Avoid SAXParseException on maxOccurs > 5000
sf.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, false);
URL xsdURL = TestParse.class.getResource(xsdLocation);
Schema schema = sf.newSchema(xsdURL);
JAXBContext ctx = JAXBContext.newInstance(MyJAXBClass.class.getPackage().getName());
Unmarshaller unmarshaller = ctx.createUnmarshaller();
unmarshaller.setSchema(schema);
I want to persist a fix4.2 message to database by retrieving the value of each tag. I am having the ExecutionReport object of the fix message.
I am retrieving the tag value of account using exec.getString(1) and this tag value is not present in the message so it is throwing FieldNotFound exception.
In Fiximate I found that account is not a mandatory field.
I also tried with exec.getAccount().getValue() but got same exception.
I found that every all these method throws FieldNotFound exception.
Is there any way to retrieve the tag value as null if that non-mandatory field is not present in the fix message.
Any help will be highly appreciated.
Thanks in advance.
Regards,
Shadab
You didn't say which QuickFIX port you are using (e.g. the original QF for C++, QF/J for Java, QF/n for C#).
If a field is not required, you simply need to test for its presence first.
C++: exec.isSetField(1) or exec.isSetField(field)
(there might also be a exec.isSetAccount(), not sure)
Java: exec.isSetField(1) or exec.isSetAccount() or exec.isSetField(field)
C#: exec.IsSet(1) or exec.IsSetAccount() or exec.IsSetField(field)