[JBoss JIRA] (TEIID-3911) Nearly all odata4 errors reported as internal server errors
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-3911?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-3911:
-------------------------------------
You are correct, without the change we can handle all the ODataApplicationException based exceptions and write to the log and response. However the ODataLibraryExceptions, unchecked exceptions will still be an issue. The above change will consolidate both into single place for handling. I will add back the unchecked exception handling, …
[View More]and push upstream.
> Nearly all odata4 errors reported as internal server errors
> -----------------------------------------------------------
>
> Key: TEIID-3911
> URL: https://issues.jboss.org/browse/TEIID-3911
> Project: Teiid
> Issue Type: Quality Risk
> Components: OData
> Affects Versions: 8.12
> Reporter: Steven Hawkins
> Fix For: 9.0
>
>
> From the TeiidServiceHandler we generally rethrow our exceptions as ODataApplicationExceptions that have a status code of 500 - however even using a different status code still results in a 500 error as the Olingo framework expects exception subclasses to be used (see ErrorHandler.handleException - a general application exception is always a 500 error).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
[View Less]
9 years, 2 months
[JBoss JIRA] (TEIID-3911) Nearly all odata4 errors reported as internal server errors
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3911?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3911:
---------------------------------------
So without the changes you are suggesting that we convert all of our exceptions to writeError and add a server side log there as well? Then the only thing would be to handled unchecked exceptions from us and exceptions from the OData framework itself (for example if we provide an incompatible value, then olingo effectively swallows …
[View More]the SerializerException on the server side).
With the changes it would still probably be good to have a general catch (Exception ) to ensure that a proper message is sent to the client even with unchecked exceptions.
> Nearly all odata4 errors reported as internal server errors
> -----------------------------------------------------------
>
> Key: TEIID-3911
> URL: https://issues.jboss.org/browse/TEIID-3911
> Project: Teiid
> Issue Type: Quality Risk
> Components: OData
> Affects Versions: 8.12
> Reporter: Steven Hawkins
> Fix For: 9.0
>
>
> From the TeiidServiceHandler we generally rethrow our exceptions as ODataApplicationExceptions that have a status code of 500 - however even using a different status code still results in a 500 error as the Olingo framework expects exception subclasses to be used (see ErrorHandler.handleException - a general application exception is always a 500 error).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
[View Less]
9 years, 2 months
[JBoss JIRA] (TEIID-3958) NPE Executing Against Web Service Source using invokeHttp() procedure without stream parameter
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3958?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3958:
---------------------------------------
This may have been addressed by TEIID-3107. Can you validate that this still occurs with Teiid 8.9 and later, or provide a reproducing vdb?
> NPE Executing Against Web Service Source using invokeHttp() procedure without stream parameter
> -----------------------------------------------------------------------------------------…
[View More]-----
>
> Key: TEIID-3958
> URL: https://issues.jboss.org/browse/TEIID-3958
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.7.1, 8.7.1.6_2
> Environment: Migrated web services model from EDS 5.3.1 that does not include 'stream' parameter in the invokeHttp() procedure
> DV 6.1 - translator-ws-8.7.1.redhat-8.jar
> DV 6.2 - translator-ws-8.7.1.6_2-redhat-6.jar
> Reporter: Marc Shirley
> Assignee: Steven Hawkins
>
> Appears to still be an issue similar to TEIID 2537. Executing against the invokeHttp() procedure generated by JBDS 5 for Teiid Designer 7.7.3 without a stream parameter results in a slightly different stack trace, but appears to be the same issue.
> 2016-01-21 12:53:50,297 ERROR \[org.teiid.PROCESSOR\] (Worker22_QueryProcessorQueue117472) TEIID30019 Unexpected exception for request FzkQneotrSUs.5: java.lang.NullPointerException
> at org.teiid.translator.ws.BinaryWSProcedureExecution.getOutputParameterValues(BinaryWSProcedureExecution.java:174)
> at org.teiid.dqp.internal.datamgr.ProcedureBatchHandler.getParameterRow(ProcedureBatchHandler.java:86) [teiid-engine-8.7.2.6_2-redhat-1.jar:8.7.2.6_2-redhat-1]
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.handleBatch(ConnectorWorkItem.java:435) [teiid-engine-8.7.2.6_2-redhat-1.jar:8.7.2.6_2-redhat-1]
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.more(ConnectorWorkItem.java:207) [teiid-engine-8.7.2.6_2-redhat-1.jar:8.7.2.6_2-redhat-1]
> at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:301) [teiid-engine-8.7.2.6_2-redhat-1.jar:8.7.2.6_2-redhat-1]
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:110) [teiid-engine-8.7.2.6_2-redhat-1.jar:8.7.2.6_2-redhat-1]
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:107) [teiid-engine-8.7.2.6_2-redhat-1.jar:8.7.2.6_2-redhat-1]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_65]
> at org.teiid.dqp.internal.process.FutureWork.run(FutureWork.java:58) [teiid-engine-8.7.2.6_2-redhat-1.jar:8.7.2.6_2-redhat-1]
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:274) [teiid-engine-8.7.2.6_2-redhat-1.jar:8.7.2.6_2-redhat-1]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119) [teiid-engine-8.7.2.6_2-redhat-1.jar:8.7.2.6_2-redhat-1]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210) [teiid-engine-8.7.2.6_2-redhat-1.jar:8.7.2.6_2-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_65]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_65]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_65]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
[View Less]
9 years, 2 months
[JBoss JIRA] (TEIID-3962) remove invalid character handling from Teiid odata4 logic
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-3962:
-------------------------------------
Summary: remove invalid character handling from Teiid odata4 logic
Key: TEIID-3962
URL: https://issues.jboss.org/browse/TEIID-3962
Project: Teiid
Issue Type: Quality Risk
Components: OData
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Since we now have a better influence over the odata framework, we should remove …
[View More]the replacement character logic from Teiid and let that be handled by the serializers - as the current handling is intended for XML but will affect both JSON and XML results.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
[View Less]
9 years, 2 months