[JBoss JIRA] (TEIID-3968) OData 4 array type handling
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-3968?page=com.atlassian.jira.plugin... ]
Ramesh Reddy resolved TEIID-3968.
---------------------------------
Resolution: Done
> OData 4 array type handling
> ---------------------------
>
> Key: TEIID-3968
> URL: https://issues.jboss.org/browse/TEIID-3968
> Project: Teiid
> Issue Type: Sub-task
> Components: OData
> Reporter: Steven Hawkins
> Assignee: Ramesh Reddy
> Fix For: 9.0, 8.12.5
>
>
> To ensure we are appropriate returning the correct error messages, creating the right upstream changes, etc. we have several paths to validate wrt array handling. There are:
> In the translator - ODataProcedureExecution.getQueryParameters, ODataFilterVisitor.visit(Function) and ODataFilterVisitor.visit(ColumnReference), ODataExpressionToSQLVisitor.visitAlias, ODataUpdateVisitor.visit(Update)
> In the OData service - ODataExpressionToSQLVisitor.visit(Alias)
> From the spec it appears that a uri should be able to specify arrays, but olingo and other frameworks may have limitations. For example it should be possible to have an array argument to a function, but the olingo framework will complain that arrays are not allowed in the resource part of the uri.
> At the very least we'll capture what won't work with this issue.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (TEIID-4089) Teiid JDBC driver does not reset the update count when calling getMoreResults(int)
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4089?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-4089:
----------------------------------
Fix Version/s: 9.0
8.12.5
8.13.3
Yes, this is an issue. Not sure why this method was effectively commented out.
> Teiid JDBC driver does not reset the update count when calling getMoreResults(int)
> ----------------------------------------------------------------------------------
>
> Key: TEIID-4089
> URL: https://issues.jboss.org/browse/TEIID-4089
> Project: Teiid
> Issue Type: Feature Request
> Components: JDBC Driver
> Affects Versions: 8.11.2
> Environment: Windows 7 Pro 64bit
> Java 8u66 64bit
> Reporter: Jesse Shaffer
> Assignee: Steven Hawkins
> Fix For: 9.0, 8.12.5, 8.13.3
>
>
> I have run across a situation with the JDBC driver. Looking at {{StatementImpl.getMoreResults(int)}}, it does not clear the update counts, whereas {{StatementImpl.getMoreResults()}} does. Long story short, this is preventing me from integrating the JDBC driver properly into my application, due to the runtime's (3rd party) handling of statements. It gets stuck in an infinite loop because to close the statement, they call {{StatementImpl.getMoreResults(Statement.CLOSE_CURRENT_RESULT);}}, but then they have a check for a -1 value to be returned from {{getUpdateCount()}} before exiting the loop. In my case, that value is always 1, and thus the infinite loop.
> It seems logical to me that {{getMoreResults(int)}} should behave the same as {{getMoreResults()}} seeing as they both always return false, only the latter is the only one that closes the resultset/clearing the update count.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (TEIID-4080) Prevent expired client/server certificates from being accepted
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4080?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-4080:
----------------------------------
Summary: Prevent expired client/server certificates from being accepted (was: SSL - client accepts server's certificate even if server's root CA is expired)
> Prevent expired client/server certificates from being accepted
> --------------------------------------------------------------
>
> Key: TEIID-4080
> URL: https://issues.jboss.org/browse/TEIID-4080
> Project: Teiid
> Issue Type: Enhancement
> Affects Versions: 8.12.5
> Reporter: Juraj Duráni
> Assignee: Steven Hawkins
> Attachments: keystore_client.jks, keystore_server_root_expired.jks, truststore.jks, truststore_expired.jks
>
>
> If SSL is enabled (1-way or 2-way) server provides to the client certificate which must be signed by valid certificate of trusted CA.
> If server provides certificate which is signed by certificate of root CA which already expired client accepts this certificate. Client should not accept such certificate.
> This affects 1-way and 2-way authentication modes.
> On the client side, paths are set using teiid-specific properties:
> {code:java}
> System.setProperty("org.teiid.ssl.keyStore", clientKeystorePath);
> System.setProperty("org.teiid.ssl.keyStorePassword", "keystorepswd");
> System.setProperty("org.teiid.ssl.keyAlias", "client");
> System.setProperty("org.teiid.ssl.keyPassword", "keystorepswd");
> System.setProperty("org.teiid.ssl.trustStore", clientTruststorePath);
> System.setProperty("org.teiid.ssl.trustStorePassword", "truststorepswd");
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (TEIID-4039) Resolving of entityid with $expand or $select fails
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-4039?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-4039:
-------------------------------------
[~jdurani] You are correct, your first comment is is right. More explanation here https://issues.apache.org/jira/browse/OLINGO-907
So essentially, if I treat the first & in $id as ? then I will have the right URI to process.
> Resolving of entityid with $expand or $select fails
> ---------------------------------------------------
>
> Key: TEIID-4039
> URL: https://issues.jboss.org/browse/TEIID-4039
> Project: Teiid
> Issue Type: Sub-task
> Components: OData
> Reporter: Juraj Duráni
> Assignee: Ramesh Reddy
>
> *URL:* http://localhost:8080/odata4/olingo_basic/Source/$entity/?$id=Customers(1...
> *Returned status code:* 404
> *URL:* http://localhost:8080/odata4/olingo_basic/Source/$entity/?$id=Customers(1...
> *Returned status code:* 500
> In this case response does not contain mandatory OData-version header and server throws exception:
> {code:plain}
> 12:20:40,911 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/odata4].[odata4]] (http-/127.0.0.1:8080-1) JBWEB000236: Servlet.service() for servlet odata4 threw exception: java.util.EmptyStackException
> at java.util.Stack.peek(Stack.java:102) [rt.jar:1.8.0-internal]
> at org.apache.olingo.server.core.uri.parser.UriParseTreeVisitor.visitSelectSegment(UriParseTreeVisitor.java:2195)
> at org.apache.olingo.server.core.uri.antlr.UriParserParser$SelectSegmentContext.accept(UriParserParser.java:3611)
> at org.apache.olingo.server.core.uri.parser.UriParseTreeVisitor.visitSelectItem(UriParseTreeVisitor.java:2168)
> at org.apache.olingo.server.core.uri.antlr.UriParserParser$SelectItemContext.accept(UriParserParser.java:3541)
> at org.apache.olingo.server.core.uri.parser.UriParseTreeVisitor.visitSelectEOF(UriParseTreeVisitor.java:2153)
> at org.apache.olingo.server.core.uri.parser.Parser.parseUri(Parser.java:228)
> at org.apache.olingo.server.core.ErrorHandler.handleServerError(ErrorHandler.java:93)
> at org.apache.olingo.server.core.ErrorHandler.handleException(ErrorHandler.java:85)
> at org.apache.olingo.server.core.OData4HttpHandler.process(OData4HttpHandler.java:70)
> at org.teiid.olingo.web.ODataServlet.service(ODataServlet.java:50) [teiid-olingo-8.12.5.redhat-2.jar:8.12.5.redhat-2]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-2.jar:1.0.2.Final-redhat-2]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.teiid.olingo.web.ODataFilter.doFilter(ODataFilter.java:194) [teiid-olingo-8.12.5.redhat-2.jar:8.12.5.redhat-2]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:512) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.5.4.Final-redhat-4.jar:7.5.4.Final-redhat-4]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:150) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0-internal]
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (TEIID-4039) Resolving of entityid with $expand or $select fails
by Juraj Duráni (JIRA)
[ https://issues.jboss.org/browse/TEIID-4039?page=com.atlassian.jira.plugin... ]
Juraj Duráni commented on TEIID-4039:
-------------------------------------
No Ramesh. You probably misunderstood me. http://localhost:8080/odata4/olingo_basic/Source/$entity?$id=Customers(1)... is *not* valid request URI.
I believe, you are looking at this from point of your implementation:
* get anything from "$id=" to the end of original URI
** BTW - at this point Teiid should fail and return 4xx to the client because neither Customers(1)&$expand=Orders_FK0 nor Customers(1)?$expand=Orders_FK0 is valid *ID* of the entity - *ID* of the entity is only Customers(1)
* append the root context before the string
* redirect user's request and return the result
But it is wrong.
Here is how you think about the request URI (I believe):
{color:red}URI and passed parameter{color}
{color:blue}value of the parameter{color}
*URI:* {color:red}localhost:8080/odata4/olingo_basic/Source/$entity?$id={color}{color:blue}Customers(1)&$expand=Orders_FK0{color}
So there is only *one* parameter in the URI which is being passed to resource $entity:
* *parameter 1:* {color:red}$id={color}{color:blue}Customers(1)&$expand=Orders_FK0{color}
But I believe that specification thinks about the URI differently:
{color:red}URI and passed parameters{color}
{color:blue}value of the parameter 1{color}
{color:green}value of the parameter 2{color}
*URI:* {color:red}localhost:8080/odata4/olingo_basic/Source/$entity?$id={color}{color:blue}Customers(1){color}{color:red}&$expand={color}{color:green}Orders_FK0{color}
Therefore, there are *2* parameters which are being passed to resource $entity:
* *parameter 1:* {color:red}$id={color}{color:blue}Customers(1){color}
* *parameter 2:* {color:red}$expand={color}{color:green}Orders_FK0{color}
So from point of the specification it should be more like:
* get value of the parameter $id
* resolve URI for supplied entity's ID
* get value of the parameter $expand
* expand navigation property of the resolved entity
* return result
Your implementation forces the client to make your work and supply URI which you can use to simply redirect the user and return the result.
So I still think that there is *no* typo in the documentation and that there is a bug in the Teiid's OData V4 service.
> Resolving of entityid with $expand or $select fails
> ---------------------------------------------------
>
> Key: TEIID-4039
> URL: https://issues.jboss.org/browse/TEIID-4039
> Project: Teiid
> Issue Type: Sub-task
> Components: OData
> Reporter: Juraj Duráni
> Assignee: Ramesh Reddy
>
> *URL:* http://localhost:8080/odata4/olingo_basic/Source/$entity/?$id=Customers(1...
> *Returned status code:* 404
> *URL:* http://localhost:8080/odata4/olingo_basic/Source/$entity/?$id=Customers(1...
> *Returned status code:* 500
> In this case response does not contain mandatory OData-version header and server throws exception:
> {code:plain}
> 12:20:40,911 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/odata4].[odata4]] (http-/127.0.0.1:8080-1) JBWEB000236: Servlet.service() for servlet odata4 threw exception: java.util.EmptyStackException
> at java.util.Stack.peek(Stack.java:102) [rt.jar:1.8.0-internal]
> at org.apache.olingo.server.core.uri.parser.UriParseTreeVisitor.visitSelectSegment(UriParseTreeVisitor.java:2195)
> at org.apache.olingo.server.core.uri.antlr.UriParserParser$SelectSegmentContext.accept(UriParserParser.java:3611)
> at org.apache.olingo.server.core.uri.parser.UriParseTreeVisitor.visitSelectItem(UriParseTreeVisitor.java:2168)
> at org.apache.olingo.server.core.uri.antlr.UriParserParser$SelectItemContext.accept(UriParserParser.java:3541)
> at org.apache.olingo.server.core.uri.parser.UriParseTreeVisitor.visitSelectEOF(UriParseTreeVisitor.java:2153)
> at org.apache.olingo.server.core.uri.parser.Parser.parseUri(Parser.java:228)
> at org.apache.olingo.server.core.ErrorHandler.handleServerError(ErrorHandler.java:93)
> at org.apache.olingo.server.core.ErrorHandler.handleException(ErrorHandler.java:85)
> at org.apache.olingo.server.core.OData4HttpHandler.process(OData4HttpHandler.java:70)
> at org.teiid.olingo.web.ODataServlet.service(ODataServlet.java:50) [teiid-olingo-8.12.5.redhat-2.jar:8.12.5.redhat-2]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-2.jar:1.0.2.Final-redhat-2]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.teiid.olingo.web.ODataFilter.doFilter(ODataFilter.java:194) [teiid-olingo-8.12.5.redhat-2.jar:8.12.5.redhat-2]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:512) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.5.4.Final-redhat-4.jar:7.5.4.Final-redhat-4]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:150) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0-internal]
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (TEIID-4089) Teiid JDBC driver does not reset the update count when calling getMoreResults(int)
by Jesse Shaffer (JIRA)
Jesse Shaffer created TEIID-4089:
------------------------------------
Summary: Teiid JDBC driver does not reset the update count when calling getMoreResults(int)
Key: TEIID-4089
URL: https://issues.jboss.org/browse/TEIID-4089
Project: Teiid
Issue Type: Feature Request
Components: JDBC Driver
Affects Versions: 8.11.2
Environment: Windows 7 Pro 64bit
Java 8u66 64bit
Reporter: Jesse Shaffer
Assignee: Steven Hawkins
I have run across a situation with the JDBC driver. Looking at {{StatementImpl.getMoreResults(int)}}, it does not clear the update counts, whereas {{StatementImpl.getMoreResults()}} does. Long story short, this is preventing me from integrating the JDBC driver properly into my application, due to the runtime's (3rd party) handling of statements. It gets stuck in an infinite loop because to close the statement, they call {{StatementImpl.getMoreResults(Statement.CLOSE_CURRENT_RESULT);}}, but then they have a check for a -1 value to be returned from {{getUpdateCount()}} before exiting the loop. In my case, that value is always 1, and thus the infinite loop.
It seems logical to me that {{getMoreResults(int)}} should behave the same as {{getMoreResults()}} seeing as they both always return false, only the latter is the only one that closes the resultset/clearing the update count.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (TEIID-3952) Update to updatable internal materialized view should update the materialized view as well as the database
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-3952?page=com.atlassian.jira.plugin... ]
Kylin Soong reassigned TEIID-3952:
----------------------------------
Assignee: Kylin Soong (was: Steven Hawkins)
> Update to updatable internal materialized view should update the materialized view as well as the database
> ----------------------------------------------------------------------------------------------------------
>
> Key: TEIID-3952
> URL: https://issues.jboss.org/browse/TEIID-3952
> Project: Teiid
> Issue Type: Enhancement
> Components: VDB
> Affects Versions: 8.7
> Environment: Red Hat JBoss Data Virtualization 6.2 based on Teiid 8.7.x
> Reporter: Andy Yuen
> Assignee: Kylin Soong
> Labels: jboss
> Fix For: 9.0
>
>
> Updating an updatable internal materized view updates the database but not the materialized view at present. The requested enhancement is that they, both, should be updated.
> Setup
> Client - SquirrelSQL to access JDV
> JDV 6.2 - with an updatable nternal materialized view of one table from the data source
> Data Source - just one data source: MySQL
> I can see from the console that the target table/view has been materialized
> Then I did the following:
> 1) select a row from the materialized table
> 2) update a field in a row in the materialized view
> 3) select that row (value unchanged ie, same as int 1) - tried multiple times
> 4) issue EXEC SYSADMIN.refreshMatViewRow(...) using primary key for the row that has been changed
> 5) select that row (value unchanged) - now I can see the changed data
> This behaviour is counter-intuitive because I was expecting that since it is an updatable materialized view, my change will write through the materialized view ie, change both the materialized view as well as the database. But in this case, it changed the database and not the materialized view?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years