[JBoss JIRA] (TEIID-2718) NPE During OData Access
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2718?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-2718.
---------------------------------
> NPE During OData Access
> -----------------------
>
> Key: TEIID-2718
> URL: https://issues.jboss.org/browse/TEIID-2718
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.3
> Reporter: Ramesh Reddy
> Assignee: Ramesh Reddy
> Fix For: 8.4.1, 8.6
>
>
> While issuing a query like
> {code}
> http://localhost:8080/odata/{vdb-name}.1/SYS.Properties
> {code}
> it resulted in
> {code}
> 12:07:38,308 ERROR [org.teiid.ODATA] (http-/127.0.0.1:8080-2) null TEIID16013 Error occured producing OData result.: java.lang.NullPointerException
> at org.teiid.odata.ODataSQLBuilder.selectString(ODataSQLBuilder.java:210) [classes:]
> at org.teiid.odata.TeiidProducer.getNavProperty(TeiidProducer.java:86) [classes:]
> at org.teiid.odata.TeiidProducer.getEntities(TeiidProducer.java:79) [classes:]
> at org.odata4j.producer.resources.EntitiesRequestResource.getEntitiesImpl(EntitiesRequestResource.java:371) [odata4j-core-0.8.0-SNAPSHOT-redhat.jar:]
> at org.odata4j.producer.resources.EntitiesRequestResource.getEntities(EntitiesRequestResource.java:266) [odata4j-core-0.8.0-SNAPSHOT-redhat.jar:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_35]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_35]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_35]
> at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_35]
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167) [resteasy-jaxrs-2.3.6.Final-redhat-1.jar:2.3.6.Final-redhat-1]
> at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269) [resteasy-jaxrs-2.3.6.Final-redhat-1.jar:2.3.6.Final-redhat-1]
> at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227) [resteasy-jaxrs-2.3.6.Final-redhat-1.jar:2.3.6.Final-redhat-1]
> at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:216) [resteasy-jaxrs-2.3.6.Final-redhat-1.jar:2.3.6.Final-redhat-1]
> at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542) [resteasy-jaxrs-2.3.6.Final-redhat-1.jar:2.3.6.Final-redhat-1]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524) [resteasy-jaxrs-2.3.6.Final-redhat-1.jar:2.3.6.Final-redhat-1]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126) [resteasy-jaxrs-2.3.6.Final-redhat-1.jar:2.3.6.Final-redhat-1]
> at org.teiid.odata.ODataServletContainerDispatcher.service(ODataServletContainerDispatcher.java:97) [classes:]
> at org.teiid.odata.ODataServlet.service(ODataServlet.java:61) [classes:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.3.6.Final-redhat-1.jar:2.3.6.Final-red
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (TEIID-2757) XML reserved characters not support in Odata
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2757?page=com.atlassian.jira.plugin... ]
Steven Hawkins edited comment on TEIID-2757 at 12/5/13 1:40 PM:
----------------------------------------------------------------
For the Atom feed odata4j eventually uses StaxXMLWriter2 which hard codes the xml version to 1.0. Just to confirm that not only are raw characters such as these not valid in xml 1.0, but escaping them is also not valid from http://www.w3.org/TR/REC-xml/#NT-Char
Based upon http://jira.codehaus.org/browse/WSTX-293 (which requests to ignore the stream check for xml 1.0 invalid chars) - this is something that they are aware. I locally also see this occurring in the woodstox BufferingXmlWriter which has a similar check with the open issue http://jira.codehaus.org/browse/WSTX-272 that implies even if xml11 is used that the characters would not get properly encoded.
So possible code solutions include:
* Use xml11 (I'm not sure that is valid wrt odata, requires an odata4j change, and may hit other woodstox issues such as WSTX-272)
* Rely on WSTX-293 - a document will be produced, but will be invalid. Will the consumer be able to do anything meaningful with an invalid document?
* Introduce invalid character replacement in Teiid (possibly allowing the replacement to be configurable, etc.). This could/should be an odata4j concern via http://www.cowtowncoder.com/blog/archives/2008/12/entry_106.html or some other mechanism to configure invalid character handling in woodstox.
Workarounds include:
* Have the user introduce views containing appropriate cleansing functions for the affected columns.
* Have the user introduce views that expose the affected columns as varbinary types.
* Use the JSON format instead
was (Author: shawkins):
For the Atom feed odata4j eventually uses StaxXMLWriter2 which hard codes the xml version to 1.0. Just to confirm that not only are raw characters such as these not valid in xml 1.0, but escaping them is also not valid from http://www.w3.org/TR/REC-xml/#NT-Char
Based upon http://jira.codehaus.org/browse/WSTX-293 (which requests to ignore the stream check for xml 1.0 invalid chars) - this is something that they are aware. I locally also see this occurring in the woodstox BufferingXmlWriter which has a similar check with the open issue http://jira.codehaus.org/browse/WSTX-272 that implies even if xml11 is used that the characters would not get properly encoded.
So possible code solutions include:
* Use xml11 (I'm not sure that is valid wrt odata, requires an odata4j change, and may hit other woodstox issues such as WSTX-272)
* Rely on WSTX-293 - a document will be produced, but will be invalid. Will the consumer be able to do anything meaningful with an invalid document?
* Introduce invalid character replacement in Teiid (possibly allowing the replacement to be configurable, etc.). This could/should be an odata4j concern via http://www.cowtowncoder.com/blog/archives/2008/12/entry_106.html or some other mechanism to configure invalid character handling in woodstox.
Workarounds include:
* Have the user introduce views containing appropriate cleansing functions for the affected columns.
* Have the user introduce views that expose the affected columns as varbinary types.
> XML reserved characters not support in Odata
> --------------------------------------------
>
> Key: TEIID-2757
> URL: https://issues.jboss.org/browse/TEIID-2757
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.4
> Environment: EAP version 6.1 with Teiid 8.5
> Reporter: Marc Shirley
> Assignee: Steven Hawkins
> Attachments: TEIID-2757-Webservices-Stacktrace.txt
>
>
> The odata framework sometimes has problems with transforming characters (reserved in XML) from the source data to the XML result. The result is an exception: TEIID16013 Error occured producing OData result.: java.lang.RuntimeException: com.ctc.wstx.exc.WstxIOException: Invalid white space character (0x1b) in text to output (in xml 1.1, could output as a character entity).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (TEIID-2757) XML reserved characters not support in Odata
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2757?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2757:
---------------------------------------
For the Atom feed odata4j eventually uses StaxXMLWriter2 which hard codes the xml version to 1.0. Just to confirm that not only are raw characters such as these not valid in xml 1.0, but escaping them is also not valid from http://www.w3.org/TR/REC-xml/#NT-Char
Based upon http://jira.codehaus.org/browse/WSTX-293 (which requests to ignore the stream check for xml 1.0 invalid chars) - this is something that they are aware. I locally also see this occurring in the woodstox BufferingXmlWriter which has a similar check with the open issue http://jira.codehaus.org/browse/WSTX-272 that implies even if xml11 is used that the characters would not get properly encoded.
So possible code solutions include:
* Use xml11 (I'm not sure that is valid wrt odata, requires an odata4j change, and may hit other woodstox issues such as WSTX-272)
* Rely on WSTX-293 - a document will be produced, but will be invalid. Will the consumer be able to do anything meaningful with an invalid document?
* Introduce invalid character replacement in Teiid (possibly allowing the replacement to be configurable, etc.). This could/should be an odata4j concern via http://www.cowtowncoder.com/blog/archives/2008/12/entry_106.html or some other mechanism to configure invalid character handling in woodstox.
Workarounds include:
* Have the user introduce views containing appropriate cleansing functions for the affected columns.
* Have the user introduce views that expose the affected columns as varbinary types.
> XML reserved characters not support in Odata
> --------------------------------------------
>
> Key: TEIID-2757
> URL: https://issues.jboss.org/browse/TEIID-2757
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.4
> Environment: EAP version 6.1 with Teiid 8.5
> Reporter: Marc Shirley
> Assignee: Steven Hawkins
> Attachments: TEIID-2757-Webservices-Stacktrace.txt
>
>
> The odata framework sometimes has problems with transforming characters (reserved in XML) from the source data to the XML result. The result is an exception: TEIID16013 Error occured producing OData result.: java.lang.RuntimeException: com.ctc.wstx.exc.WstxIOException: Invalid white space character (0x1b) in text to output (in xml 1.1, could output as a character entity).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (TEIID-2759) Unable to import SAP NW-Gateway OData using sap-nw-gateway translator
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-2759?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-2759:
-------------------------------------
Woodstox XML Stax API library used by JBoss AS by default sets the validation of XML document building by default to true; There are options to set the property to false. However, the code that is calling this is embedded in Odata4J libraries and does not provide a way to intercept it, to turn this property false.
The only option is to override the odta4j class in Teiid and set the property to false. The property in question is "com.ctc.wstx.outputValidateStructure".
The similar code is used in XMLSystemFunctions.newXmlOutputFactory() method.
> Unable to import SAP NW-Gateway OData using sap-nw-gateway translator
> ----------------------------------------------------------------------
>
> Key: TEIID-2759
> URL: https://issues.jboss.org/browse/TEIID-2759
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.4.1
> Reporter: Van Halbert
> Assignee: Mark Drilling
> Attachments: ODataVDB.vdb, SAPGateway.ddl
>
>
> "No difference report was found" Error
> I am trying to test SAP NW-GATEWAY OData with DV6-ER4 and JDBS 7.0.1.GA/Designer 8.3.0-CR1
> The following steps will reproduce the error:
> 1. Do an import/Designer/Teiid Connection >> Source Model
> 2. Create a new datasource using webservice from available drivers
> 3. Enter Data Source Properties (can connect to the url in a browser):
> URL: https://sapes1.sapdevcenter.com/sap/opu/odata/IWFND/RMTSAMPLEFLIGHT/
> WebService Security Used: HTTPBasic
> class-name: used prefilled default
> Authentication User Name: P1940027560
> Authentication User Password: Foxrun1004
> 4. Selected the newly created driver and selected "Next"
> 5. Selected sap-nw-gateway translator and named the target model and selected "Next"
> 6. Was presented with a DDL screen and selected "Next"
> 7. The "Select the Differences to Apply" screen shows an Import Message "Error
> encountered while importing the DDL - No difference report was found". screenshot attached.
> java.lang.reflect.InvocationTargetException
> at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:421)
> at org.eclipse.jface.dialogs.ProgressMonitorDialog.run(ProgressMonitorDialog.java:507)
> at org.teiid.designer.ddl.importer.ui.DdlImportDifferencesPage.setVisible(DdlImportDifferencesPage.java:217)
> at org.eclipse.jface.wizard.WizardDialog.updateForPage(WizardDialog.java:1259)
> at org.eclipse.jface.wizard.WizardDialog.access$4(WizardDialog.java:1238)
> at org.eclipse.jface.wizard.WizardDialog$8.run(WizardDialog.java:1227)
> at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
> at org.eclipse.jface.wizard.WizardDialog.showPage(WizardDialog.java:1225)
> at org.eclipse.jface.wizard.WizardDialog.nextPressed(WizardDialog.java:915)
> at org.eclipse.jface.wizard.WizardDialog.buttonPressed(WizardDialog.java:428)
> at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.java:628)
> at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:248)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1392)
> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3742)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3363)
> at org.eclipse.jface.window.Window.runEventLoop(Window.java:826)
> at org.eclipse.jface.window.Window.open(Window.java:802)
> at org.eclipse.ui.internal.handlers.WizardHandler$Import.executeHandler(WizardHandler.java:152)
> at org.eclipse.ui.internal.handlers.WizardHandler.execute(WizardHandler.java:279)
> at org.eclipse.ui.internal.handlers.HandlerProxy.execute(HandlerProxy.java:290)
> at org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(E4HandlerProxy.java:90)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:56)
> at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:243)
> at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:224)
> at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:132)
> at org.eclipse.e4.core.commands.internal.HandlerServiceHandler.execute(HandlerServiceHandler.java:167)
> at org.eclipse.core.commands.Command.executeWithChecks(Command.java:499)
> at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:508)
> at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.executeHandler(HandlerServiceImpl.java:213)
> at org.eclipse.ui.internal.handlers.LegacyHandlerService.executeCommand(LegacyHandlerService.java:420)
> at org.eclipse.ui.internal.actions.CommandAction.runWithEvent(CommandAction.java:157)
> at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:584)
> at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:501)
> at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:411)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1392)
> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3742)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3363)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1113)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:997)
> at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:138)
> at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:610)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
> at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:567)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
> at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
> at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:354)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:181)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:636)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:591)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1450)
> at org.eclipse.equinox.launcher.Main.main(Main.java:1426)
> Caused by: java.lang.NullPointerException
> at org.modeshape.sequencer.ddl.dialect.teiid.CreateTableParser.getColumnNode(CreateTableParser.java:120)
> at org.modeshape.sequencer.ddl.dialect.teiid.CreateTableParser.parseReferenceList(CreateTableParser.java:333)
> at org.modeshape.sequencer.ddl.dialect.teiid.CreateTableParser.parseTableBodyConstraint(CreateTableParser.java:455)
> at org.modeshape.sequencer.ddl.dialect.teiid.CreateTableParser.parseTableBody(CreateTableParser.java:365)
> at org.modeshape.sequencer.ddl.dialect.teiid.CreateTableParser.parse(CreateTableParser.java:198)
> at org.modeshape.sequencer.ddl.dialect.teiid.TeiidDdlParser.parseNextStatement(TeiidDdlParser.java:150)
> at org.modeshape.sequencer.ddl.StandardDdlParser.parse(StandardDdlParser.java:209)
> at org.modeshape.sequencer.ddl.DdlParsers.parseUsing(DdlParsers.java:174)
> at org.teiid.designer.ddl.importer.DdlImporter.importDdl(DdlImporter.java:134)
> at org.teiid.designer.ddl.importer.DdlImporter$1.tryToDo(DdlImporter.java:106)
> at org.teiid.core.designer.util.OperationUtil.perform(OperationUtil.java:40)
> at org.teiid.designer.ddl.importer.DdlImporter.importDdl(DdlImporter.java:90)
> at org.teiid.designer.ddl.importer.ui.DdlImportDifferencesPage$1.run(DdlImportDifferencesPage.java:222)
> at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)
> Root exception:
> java.lang.NullPointerException
> at org.modeshape.sequencer.ddl.dialect.teiid.CreateTableParser.getColumnNode(CreateTableParser.java:120)
> at org.modeshape.sequencer.ddl.dialect.teiid.CreateTableParser.parseReferenceList(CreateTableParser.java:333)
> at org.modeshape.sequencer.ddl.dialect.teiid.CreateTableParser.parseTableBodyConstraint(CreateTableParser.java:455)
> at org.modeshape.sequencer.ddl.dialect.teiid.CreateTableParser.parseTableBody(CreateTableParser.java:365)
> at org.modeshape.sequencer.ddl.dialect.teiid.CreateTableParser.parse(CreateTableParser.java:198)
> at org.modeshape.sequencer.ddl.dialect.teiid.TeiidDdlParser.parseNextStatement(TeiidDdlParser.java:150)
> at org.modeshape.sequencer.ddl.StandardDdlParser.parse(StandardDdlParser.java:209)
> at org.modeshape.sequencer.ddl.DdlParsers.parseUsing(DdlParsers.java:174)
> at org.teiid.designer.ddl.importer.DdlImporter.importDdl(DdlImporter.java:134)
> at org.teiid.designer.ddl.importer.DdlImporter$1.tryToDo(DdlImporter.java:106)
> at org.teiid.core.designer.util.OperationUtil.perform(OperationUtil.java:40)
> at org.teiid.designer.ddl.importer.DdlImporter.importDdl(DdlImporter.java:90)
> at org.teiid.designer.ddl.importer.ui.DdlImportDifferencesPage$1.run(DdlImportDifferencesPage.java:222)
> at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (TEIID-2757) XML reserved characters not support in Odata
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2757?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2757:
---------------------------------------
> but the customer buys an Enterprise solution (subscription) and will not care if the problem is in Teiid or one of the dependencies.
We completely understand that. This being the community issue system though, the perspective is that of the community. The salesforce/bugzilla systems are oriented toward the customer perspective and are better suited for high level customer involvement.
Just to make sure there's an understanding of what we're saying here is that we need to first make sure that the issue is addressed in the proper place. If it cannot be addressed elsewhere, workarounds are not accepted (which will be communicated here and on the salesforce ticket), etc. then we can look at what would be an acceptable resolution inside of Teiid code.
> XML reserved characters not support in Odata
> --------------------------------------------
>
> Key: TEIID-2757
> URL: https://issues.jboss.org/browse/TEIID-2757
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.4
> Environment: EAP version 6.1 with Teiid 8.5
> Reporter: Marc Shirley
> Assignee: Steven Hawkins
> Attachments: TEIID-2757-Webservices-Stacktrace.txt
>
>
> The odata framework sometimes has problems with transforming characters (reserved in XML) from the source data to the XML result. The result is an exception: TEIID16013 Error occured producing OData result.: java.lang.RuntimeException: com.ctc.wstx.exc.WstxIOException: Invalid white space character (0x1b) in text to output (in xml 1.1, could output as a character entity).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (TEIID-2757) XML reserved characters not support in Odata
by Patrick Deenen (JIRA)
[ https://issues.jboss.org/browse/TEIID-2757?page=com.atlassian.jira.plugin... ]
Patrick Deenen commented on TEIID-2757:
---------------------------------------
Delegating the problem to the dependent opensource framework (woodstox is my best guess) is ok when using a community project, but the customer buys an Enterprise solution (subscription) and will not care if the problem is in Teiid or one of the dependencies.
> XML reserved characters not support in Odata
> --------------------------------------------
>
> Key: TEIID-2757
> URL: https://issues.jboss.org/browse/TEIID-2757
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.4
> Environment: EAP version 6.1 with Teiid 8.5
> Reporter: Marc Shirley
> Assignee: Steven Hawkins
> Attachments: TEIID-2757-Webservices-Stacktrace.txt
>
>
> The odata framework sometimes has problems with transforming characters (reserved in XML) from the source data to the XML result. The result is an exception: TEIID16013 Error occured producing OData result.: java.lang.RuntimeException: com.ctc.wstx.exc.WstxIOException: Invalid white space character (0x1b) in text to output (in xml 1.1, could output as a character entity).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (TEIID-2757) XML reserved characters not support in Odata
by Patrick Deenen (JIRA)
[ https://issues.jboss.org/browse/TEIID-2757?page=com.atlassian.jira.plugin... ]
Patrick Deenen updated TEIID-2757:
----------------------------------
Attachment: TEIID-2757-Webservices-Stacktrace.txt
Attached you can find the stacktrace for the same problem, when using the web services interface.
> XML reserved characters not support in Odata
> --------------------------------------------
>
> Key: TEIID-2757
> URL: https://issues.jboss.org/browse/TEIID-2757
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.4
> Environment: EAP version 6.1 with Teiid 8.5
> Reporter: Marc Shirley
> Assignee: Steven Hawkins
> Attachments: TEIID-2757-Webservices-Stacktrace.txt
>
>
> The odata framework sometimes has problems with transforming characters (reserved in XML) from the source data to the XML result. The result is an exception: TEIID16013 Error occured producing OData result.: java.lang.RuntimeException: com.ctc.wstx.exc.WstxIOException: Invalid white space character (0x1b) in text to output (in xml 1.1, could output as a character entity).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (TEIID-2757) XML reserved characters not support in Odata
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2757?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2757:
---------------------------------------
> This should IMHO not be the case. I would expect enterprise reliability from an enterprise product.
I'm not sure this reflects on reliability. This doesn't appear to be a common case given how it is not handled by odata4j/woodstox.
> That said I would settle for a simple configuration option which enables the replacement of invalid characters by white spaces if they cannot be replaced by XML entities.
That would only be a last resort. This could be seen as an issue for woodstox or odata4j. From what I can see even the sun reference stax doesn't handle escaping the forbidden control characters, so this is a general problem for xml frameworks. If workarounds such as using JSON, a binary type, or a view to perform the necessary cleansing aren't acceptable, then we'll want to get something logged further downstream and then determine if there's anything we want to do on our side.
> XML reserved characters not support in Odata
> --------------------------------------------
>
> Key: TEIID-2757
> URL: https://issues.jboss.org/browse/TEIID-2757
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.4
> Environment: EAP version 6.1 with Teiid 8.5
> Reporter: Marc Shirley
> Assignee: Steven Hawkins
>
> The odata framework sometimes has problems with transforming characters (reserved in XML) from the source data to the XML result. The result is an exception: TEIID16013 Error occured producing OData result.: java.lang.RuntimeException: com.ctc.wstx.exc.WstxIOException: Invalid white space character (0x1b) in text to output (in xml 1.1, could output as a character entity).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (TEIID-2757) XML reserved characters not support in Odata
by Patrick Deenen (JIRA)
[ https://issues.jboss.org/browse/TEIID-2757?page=com.atlassian.jira.plugin... ]
Patrick Deenen edited comment on TEIID-2757 at 12/5/13 9:56 AM:
----------------------------------------------------------------
I originally added this issue to the customer portal, which is transferred here by Marc.
I understand that this is a limitation of XML, hence it may not be classified as a bug. But it does limit the use of TEIID in real business scenarios where the source data is not cleaned or prepared for XML as is the case for our current customer.
I do have requested to the customer to update the ETL processing to remove invalid characters, but this still feels not as a comfortable solution because simple characters in the source data can break the system. This should IMHO not be the case. I would expect enterprise reliability from an enterprise product.
That said I would settle for a simple configuration option which enables the replacement of invalid characters by white spaces if they cannot be replaced by XML entities.
was (Author: pdeenen):
I originally added this issue to the customer portal, which is transferred here by Marc.
I understand that this is a limitation of XML, hence it may not be classified as a bug. But it does limit the use of TEIID in real business scenarios where the source data is not cleaned or prepared for XML as is the case for our current customer.
I do have requested to the customer to update the ETL processing to remove invalid characters, but still feels not comfortable because simple characters in the source data can break the system. This should IMHO not be the case. I would expect enterprise reliability from an enterprise product.
That said I would settle for a simple configuration option which enables the replacement of invalid characters by white spaces if they cannot be replaced by XML entities.
> XML reserved characters not support in Odata
> --------------------------------------------
>
> Key: TEIID-2757
> URL: https://issues.jboss.org/browse/TEIID-2757
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.4
> Environment: EAP version 6.1 with Teiid 8.5
> Reporter: Marc Shirley
> Assignee: Steven Hawkins
>
> The odata framework sometimes has problems with transforming characters (reserved in XML) from the source data to the XML result. The result is an exception: TEIID16013 Error occured producing OData result.: java.lang.RuntimeException: com.ctc.wstx.exc.WstxIOException: Invalid white space character (0x1b) in text to output (in xml 1.1, could output as a character entity).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months