July 2014 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-3010) odata webapp missing joda time dependency

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-3010?page=com.atlassian.jira.plugin... ] Johnathon Lee updated TEIID-3010: --------------------------------- Fix Version/s: 8.4.3 > odata webapp missing joda time dependency > ----------------------------------------- > > Key: TEIID-3010 > URL: https://issues.jboss.org/browse/TEIID-3010 > Project: Teiid > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: OData > Affects Versions: 8.7 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.7.1, 8.4.3, 8.8 > > > Usage of a datetime literal (datetime'2000-01-01T00:00:00) in a query, results in a no class def error: > Caused by: java.lang.NoClassDefFoundError: org/joda/time/LocalDateTime > at org.teiid.odata.ODataSQLBuilder.visit(ODataSQLBuilder.java:454) [classes:] -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3010) odata webapp missing joda time dependency

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3010?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3010: ------------------------------------------------ jolee(a)redhat.com changed the Status of [bug 1110399|https://bugzilla.redhat.com/show_bug.cgi?id=1110399] from NEW to MODIFIED > odata webapp missing joda time dependency > ----------------------------------------- > > Key: TEIID-3010 > URL: https://issues.jboss.org/browse/TEIID-3010 > Project: Teiid > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: OData > Affects Versions: 8.7 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.7.1, 8.4.3, 8.8 > > > Usage of a datetime literal (datetime'2000-01-01T00:00:00) in a query, results in a no class def error: > Caused by: java.lang.NoClassDefFoundError: org/joda/time/LocalDateTime > at org.teiid.odata.ODataSQLBuilder.visit(ODataSQLBuilder.java:454) [classes:] -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3011) rewrite skipped

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-3011?page=com.atlassian.jira.plugin... ] Johnathon Lee closed TEIID-3011. -------------------------------- Resolution: Done > rewrite skipped > --------------- > > Key: TEIID-3011 > URL: https://issues.jboss.org/browse/TEIID-3011 > Project: Teiid > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Query Engine > Affects Versions: 7.7 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.7.1, 8.4.3, 8.7 > > > The rewrite of a set predicate is being bypassed when all of the in values are constants, but when pushed through a view with a convert on the left expression there is still optimizations that can be performed. > For example: > select * from (select e1, e2 from pm1.g1 union all select convert(e2, string), e2 from pm1.g2) x where e1 in ('1', '2') > such that e1 is string and e2 is integer, we expect that the second branch will have criteria of the form "e2 in (1, 2)" - with no conversion. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3011) rewrite skipped

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-3011?page=com.atlassian.jira.plugin... ] Johnathon Lee reopened TEIID-3011: ---------------------------------- re-open for fix version > rewrite skipped > --------------- > > Key: TEIID-3011 > URL: https://issues.jboss.org/browse/TEIID-3011 > Project: Teiid > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Query Engine > Affects Versions: 7.7 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.7, 8.7.1 > > > The rewrite of a set predicate is being bypassed when all of the in values are constants, but when pushed through a view with a convert on the left expression there is still optimizations that can be performed. > For example: > select * from (select e1, e2 from pm1.g1 union all select convert(e2, string), e2 from pm1.g2) x where e1 in ('1', '2') > such that e1 is string and e2 is integer, we expect that the second branch will have criteria of the form "e2 in (1, 2)" - with no conversion. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3011) rewrite skipped

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-3011?page=com.atlassian.jira.plugin... ] Johnathon Lee updated TEIID-3011: --------------------------------- Fix Version/s: 8.4.3 > rewrite skipped > --------------- > > Key: TEIID-3011 > URL: https://issues.jboss.org/browse/TEIID-3011 > Project: Teiid > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Query Engine > Affects Versions: 7.7 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.7, 8.7.1, 8.4.3 > > > The rewrite of a set predicate is being bypassed when all of the in values are constants, but when pushed through a view with a convert on the left expression there is still optimizations that can be performed. > For example: > select * from (select e1, e2 from pm1.g1 union all select convert(e2, string), e2 from pm1.g2) x where e1 in ('1', '2') > such that e1 is string and e2 is integer, we expect that the second branch will have criteria of the form "e2 in (1, 2)" - with no conversion. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3011) rewrite skipped

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3011?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3011: ------------------------------------------------ jolee(a)redhat.com changed the Status of [bug 1110409|https://bugzilla.redhat.com/show_bug.cgi?id=1110409] from NEW to MODIFIED > rewrite skipped > --------------- > > Key: TEIID-3011 > URL: https://issues.jboss.org/browse/TEIID-3011 > Project: Teiid > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Query Engine > Affects Versions: 7.7 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.7, 8.7.1, 8.4.3 > > > The rewrite of a set predicate is being bypassed when all of the in values are constants, but when pushed through a view with a convert on the left expression there is still optimizations that can be performed. > For example: > select * from (select e1, e2 from pm1.g1 union all select convert(e2, string), e2 from pm1.g2) x where e1 in ('1', '2') > such that e1 is string and e2 is integer, we expect that the second branch will have criteria of the form "e2 in (1, 2)" - with no conversion. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3021) Serialization of long sqlexception/warning next chains can lead to oom

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-3021?page=com.atlassian.jira.plugin... ] Johnathon Lee reopened TEIID-3021: ---------------------------------- re-open for fix version > Serialization of long sqlexception/warning next chains can lead to oom > ---------------------------------------------------------------------- > > Key: TEIID-3021 > URL: https://issues.jboss.org/browse/TEIID-3021 > Project: Teiid > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Server > Affects Versions: 8.1 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.7.1, 8.8 > > > The serialization logic for exception chains is not correct and will output exponentially too many instances of chained exceptions, which can lead to out of memory conditions. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3021) Serialization of long sqlexception/warning next chains can lead to oom

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-3021?page=com.atlassian.jira.plugin... ] Johnathon Lee updated TEIID-3021: --------------------------------- Fix Version/s: 8.4.3 > Serialization of long sqlexception/warning next chains can lead to oom > ---------------------------------------------------------------------- > > Key: TEIID-3021 > URL: https://issues.jboss.org/browse/TEIID-3021 > Project: Teiid > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Server > Affects Versions: 8.1 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.7.1, 8.4.3, 8.8 > > > The serialization logic for exception chains is not correct and will output exponentially too many instances of chained exceptions, which can lead to out of memory conditions. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2911) Guard against external entity resolving

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-2911?page=com.atlassian.jira.plugin... ] Johnathon Lee closed TEIID-2911. -------------------------------- Resolution: Done > Guard against external entity resolving > --------------------------------------- > > Key: TEIID-2911 > URL: https://issues.jboss.org/browse/TEIID-2911 > Project: Teiid > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: OData, Query Engine > Affects Versions: 7.7, 8.4 > Reporter: Van Halbert > Assignee: Steven Hawkins > Priority: Critical > Fix For: 8.4.3, 8.7 > > Attachments: org.odata4j.stax2.staximpl.StaxXMLFactoryProvider2.diff > > > if applications that expose RESTEasy XML endpoints, add the following snippet to their web.xml file to disable entity expansion in RESTEasy: > <context-param> > <param-name>resteasy.document.expand.entity.references</param-name> > <param-value>false</param-value> > </context-param> > Note that this <context-param> setting has precedence over <init-param>, and will override a contrary setting in an <init-param> element. > However this is not sufficient for OData as OData4j is responsible for parsing the Atom feed. StaxXMLFactoryProvider2 simply creates XMLInputFactories without any options, thus they will perform external entity resolving by default. An issue will need to be opened against OData4j. > For SQL/XML, the XMLType input factory needs to disable external entity resolving (via experimentation just setting the relevant property doesn't always work, so like other projects we'll set an XMLResolver, which does work). -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2911) Guard against external entity resolving

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-2911?page=com.atlassian.jira.plugin... ] Johnathon Lee reopened TEIID-2911: ---------------------------------- re-open for fix version > Guard against external entity resolving > --------------------------------------- > > Key: TEIID-2911 > URL: https://issues.jboss.org/browse/TEIID-2911 > Project: Teiid > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: OData, Query Engine > Affects Versions: 7.7, 8.4 > Reporter: Van Halbert > Assignee: Steven Hawkins > Priority: Critical > Fix For: 8.7 > > Attachments: org.odata4j.stax2.staximpl.StaxXMLFactoryProvider2.diff > > > if applications that expose RESTEasy XML endpoints, add the following snippet to their web.xml file to disable entity expansion in RESTEasy: > <context-param> > <param-name>resteasy.document.expand.entity.references</param-name> > <param-value>false</param-value> > </context-param> > Note that this <context-param> setting has precedence over <init-param>, and will override a contrary setting in an <init-param> element. > However this is not sufficient for OData as OData4j is responsible for parsing the Atom feed. StaxXMLFactoryProvider2 simply creates XMLInputFactories without any options, thus they will perform external entity resolving by default. An issue will need to be opened against OData4j. > For SQL/XML, the XMLType input factory needs to disable external entity resolving (via experimentation just setting the relevant property doesn't always work, so like other projects we'll set an XMLResolver, which does work). -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues July 2014