March 2016 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-4039) Resolving of entityid with additional system options fail

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-4039?page=com.atlassian.jira.plugin... ] Ramesh Reddy resolved TEIID-4039. --------------------------------- Fix Version/s: 9.0 8.12.5 Resolution: Done Reworked in upstream to treat the additional queries on original query as additional query path on $id path. > Resolving of entityid with additional system options fail > --------------------------------------------------------- > > 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 > Fix For: 9.0, 8.12.5 > > > *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)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4059) OData - $ref after $expand does not work

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-4059?page=com.atlassian.jira.plugin... ] Ramesh Reddy resolved TEIID-4059. --------------------------------- Fix Version/s: 9.0 8.12.5 Resolution: Done Labels: Beta1 (was: ) > OData - $ref after $expand does not work > ---------------------------------------- > > Key: TEIID-4059 > URL: https://issues.jboss.org/browse/TEIID-4059 > Project: Teiid > Issue Type: Sub-task > Components: OData > Reporter: Juraj Duráni > Assignee: Ramesh Reddy > Labels: Beta1 > Fix For: 9.0, 8.12.5 > > > If user declares $ref after $expand, OData service should return inline references to entities instead of whole entities. > *URL:* http://localhost:8080/odata4/olingo_basic/Source/Customers/?$expand=Order... > *Result:* > {code:xml} > ... > <a:link rel="http://docs.oasis-open.org/odata/ns/related/Orders_FK0" title="Orders_FK0" href="http://localhost:8080/odata4/olingo_basic/Source/Customers(1)/Orders_FK0"> > <m:inline> > <a:feed> > <a:entry> > ... > {code} > *Expected result:* > {code:xml} > <a:link rel="http://docs.oasis-open.org/odata/ns/related/Orders_FK0" title="Orders_FK0" href="http://localhost:8080/odata4/olingo_basic/Source/Customers(1)/Orders_FK0"> > <m:inline> > <a:feed> > <m:ref id="http://localhost:8080/odata4/olingo_basic/Source/Orders(1)"/> > ... > {code} > See http://docs.oasis-open.org/odata/odata/v4.0/errata02/os/complete/part1-pr... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4060) OData - $count after $expand does not work

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-4060?page=com.atlassian.jira.plugin... ] Ramesh Reddy resolved TEIID-4060. --------------------------------- Fix Version/s: 9.0 8.12.5 Resolution: Done > OData - $count after $expand does not work > ------------------------------------------ > > Key: TEIID-4060 > URL: https://issues.jboss.org/browse/TEIID-4060 > Project: Teiid > Issue Type: Sub-task > Components: OData > Reporter: Juraj Duráni > Assignee: Ramesh Reddy > Fix For: 9.0, 8.12.5 > > > If user declares $count after $expand, OData service should return count if referenced entities instead of whole entities. > *URL:* http://localhost:8080/odata4/olingo_basic/Source/Customers/?$expand=Order... > *Result:* > {code:xml} > ... > <a:link rel="http://docs.oasis-open.org/odata/ns/related/Orders_FK0" title="Orders_FK0" href="http://localhost:8080/odata4/olingo_basic/Source/Customers(1)/Orders_FK0"> > <m:inline> > <a:feed> > <a:entry> > ... > {code} > *Expected result:* > {code:xml} > <a:link rel="http://docs.oasis-open.org/odata/ns/related/Orders_FK0" title="Orders_FK0" href="http://localhost:8080/odata4/olingo_basic/Source/Customers(1)/Orders_FK0"> >  > <m:count>4</m:count> > ... > {code} > See http://docs.oasis-open.org/odata/odata/v4.0/errata02/os/complete/part1-pr... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3962) remove invalid character handling from Teiid odata4 logic

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-3962?page=com.atlassian.jira.plugin... ] Ramesh Reddy resolved TEIID-3962. --------------------------------- Fix Version/s: 9.0 8.12.5 Resolution: Done Updated logic using annotation based logic. Updated the tests > remove invalid character handling from Teiid odata4 logic > --------------------------------------------------------- > > Key: TEIID-3962 > URL: https://issues.jboss.org/browse/TEIID-3962 > Project: Teiid > Issue Type: Sub-task > Components: OData > Reporter: Steven Hawkins > Assignee: Ramesh Reddy > Fix For: 9.0, 8.12.5 > > > Since we now have a better influence over the odata framework, we should remove 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)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3177) Enforce SSL connections over ODBC when Encryption Mode is enabled

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3177?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-3177: --------------------------------------- Added John Lee as a watcher. John see the above - as a patch for those using the old default configuration this would require a configuration change (to explicitly set the ssl mode to disable) unless another change is made to keep the legacy behavior of ssl mode login. > Enforce SSL connections over ODBC when Encryption Mode is enabled > ----------------------------------------------------------------- > > Key: TEIID-3177 > URL: https://issues.jboss.org/browse/TEIID-3177 > Project: Teiid > Issue Type: Feature Request > Components: ODBC > Affects Versions: 8.8 > Reporter: Cristiano Nicolai > Assignee: Steven Hawkins > Priority: Critical > Fix For: 8.9, 8.7.5.6_2 > > > When connecting via ODBC transport, even if the encryption mode is set to enabled is still possible to establish non ssl connections. This allows clients to connect via insecure method. We would like that the Teiid transport could reject connections if they are not properly set up using SSL transport. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4108) Embedded examples need to mention the Teiid project version

by Steven Hawkins (JIRA)

Steven Hawkins created TEIID-4108: ------------------------------------- Summary: Embedded examples need to mention the Teiid project version Key: TEIID-4108 URL: https://issues.jboss.org/browse/TEIID-4108 Project: Teiid Issue Type: Quality Risk Components: Embedded Reporter: Steven Hawkins Assignee: Steven Hawkins The embedded examples currently default to a snapshot version - this should be a released version instead. Also the example docs should mention retargeting the version. It may also be needed for each of the examples to reference the parent settings.xml. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3177) Enforce SSL connections over ODBC when Encryption Mode is enabled

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3177?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-3177: --------------------------------------- > It is quite braking change for the patch, isn't it? That is why it wasn't done as a patch initially - it's a large change and it changes the meaning of login mode ssl for odbc. However that is a logical consequence - and in all of our docs we warn that cleartext is being used by default and needs to be done so with caution. As for whether GSS wants to keep the this change in tact or add a backwards compatibility property, that will be up to them. > But It means, that user cannot use username:password authentication while connecting to Teiid ODBC transport OOB That is not correct. OOB the configuration moving forward is: <transport name="odbc" protocol="pg" socket-binding="teiid-odbc"> <authentication security-domain="teiid-security"/> <ssl mode="disabled"/> </transport> Which is explicit about the default mode being disabled. > Enforce SSL connections over ODBC when Encryption Mode is enabled > ----------------------------------------------------------------- > > Key: TEIID-3177 > URL: https://issues.jboss.org/browse/TEIID-3177 > Project: Teiid > Issue Type: Feature Request > Components: ODBC > Affects Versions: 8.8 > Reporter: Cristiano Nicolai > Assignee: Steven Hawkins > Priority: Critical > Fix For: 8.9, 8.7.5.6_2 > > > When connecting via ODBC transport, even if the encryption mode is set to enabled is still possible to establish non ssl connections. This allows clients to connect via insecure method. We would like that the Teiid transport could reject connections if they are not properly set up using SSL transport. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3177) Enforce SSL connections over ODBC when Encryption Mode is enabled

by Juraj Duráni (JIRA)

[ https://issues.jboss.org/browse/TEIID-3177?page=com.atlassian.jira.plugin... ] Juraj Duráni commented on TEIID-3177: ------------------------------------- It is quite braking change for the patch, isn't it? > Enforce SSL connections over ODBC when Encryption Mode is enabled > ----------------------------------------------------------------- > > Key: TEIID-3177 > URL: https://issues.jboss.org/browse/TEIID-3177 > Project: Teiid > Issue Type: Feature Request > Components: ODBC > Affects Versions: 8.8 > Reporter: Cristiano Nicolai > Assignee: Steven Hawkins > Priority: Critical > Fix For: 8.9, 8.7.5.6_2 > > > When connecting via ODBC transport, even if the encryption mode is set to enabled is still possible to establish non ssl connections. This allows clients to connect via insecure method. We would like that the Teiid transport could reject connections if they are not properly set up using SSL transport. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3177) Enforce SSL connections over ODBC when Encryption Mode is enabled

by Juraj Duráni (JIRA)

[ https://issues.jboss.org/browse/TEIID-3177?page=com.atlassian.jira.plugin... ] Juraj Duráni commented on TEIID-3177: ------------------------------------- But It means, that user cannot use username:password authentication while connecting to Teiid ODBC transport OOB. > Enforce SSL connections over ODBC when Encryption Mode is enabled > ----------------------------------------------------------------- > > Key: TEIID-3177 > URL: https://issues.jboss.org/browse/TEIID-3177 > Project: Teiid > Issue Type: Feature Request > Components: ODBC > Affects Versions: 8.8 > Reporter: Cristiano Nicolai > Assignee: Steven Hawkins > Priority: Critical > Fix For: 8.9, 8.7.5.6_2 > > > When connecting via ODBC transport, even if the encryption mode is set to enabled is still possible to establish non ssl connections. This allows clients to connect via insecure method. We would like that the Teiid transport could reject connections if they are not properly set up using SSL transport. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3948) Provide a different mechanism to update odata wars

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3948?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3948: ------------------------------------------------ Juraj Duráni <jdurani(a)redhat.com> changed the Status of [bug 1305039|https://bugzilla.redhat.com/show_bug.cgi?id=1305039] from ON_QA to VERIFIED > Provide a different mechanism to update odata wars > -------------------------------------------------- > > Key: TEIID-3948 > URL: https://issues.jboss.org/browse/TEIID-3948 > Project: Teiid > Issue Type: Quality Risk > Components: Server > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.0, 8.12.5 > > > Directly modifying the wars under the base modules is a bad practice. We need to have users modify non-kit artifact files in a different location. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 9 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues March 2016