January 2016 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-3894) Teiid transport ssl attributes should add some default values

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3894?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-3894: --------------------------------------- ssl-mode, ssl-authentication-mode, ssl-ssl-protocol, keystore-type do have default values defined. ssl-mode and ssl-authentication-mode look like they could be updated with allowed values. ssl-keymanagement-algorithm could be defaulted to the sun/oracle default - but it can be different on other JREs ssl-enabled-cipher-suites doesn't expect a default value currently, so a change is not needed there. > Teiid transport ssl attributes should add some default values > ------------------------------------------------------------- > > Key: TEIID-3894 > URL: https://issues.jboss.org/browse/TEIID-3894 > Project: Teiid > Issue Type: Feature Request > Components: Server > Affects Versions: 9.x > Reporter: Kylin Soong > Assignee: Steven Hawkins > Fix For: 9.x > > > Execute the following cli > {code} > /subsystem=teiid/transport=jdbc:write-attribute(name=ssl-mode,value=enabled) > /subsystem=teiid/transport=jdbc:write-attribute(name=ssl-authentication-mode,value=1-way) > /subsystem=teiid/transport=jdbc:write-attribute(name=ssl-ssl-protocol,value=TLSv1) > /subsystem=teiid/transport=jdbc:write-attribute(name=ssl-keymanagement-algorithm,value=SunX509) > /subsystem=teiid/transport=jdbc:write-attribute(name=ssl-enabled-cipher-suites,value="SSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA") > /subsystem=teiid/transport=jdbc:write-attribute(name=keystore-type,value=JKS) > {code} > no suggested value pop up, some values only allow existed value, so I think add some default value is necessary. > h3. ssl-mode allowed value > * enabled > * login > * enabled > h3. ssl-authentication-mode allowed value > * 1-way > * 2-way > * anonymous > h3. ssl-ssl-protocol default value > * TLSv1 > h3. ssl-keymanagement-algorithm default value > * SunX509 > h3. ssl-enabled-cipher-suites default value > * SSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA > h3. keystore-type default value > * JKS -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3869) Enable Teiid to be exposed as a GIS compliant data source

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3869?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-3869. ----------------------------------- Resolution: Done Marking as resolved. See the previous comment on what additional work could be done. > Enable Teiid to be exposed as a GIS compliant data source > --------------------------------------------------------- > > Key: TEIID-3869 > URL: https://issues.jboss.org/browse/TEIID-3869 > Project: Teiid > Issue Type: Feature Request > Components: Grammar, JDBC Driver, OData, ODBC > Reporter: Van Halbert > Assignee: Steven Hawkins > Fix For: 9.0, 8.12.5 > > > See > http://www.esri.com/~/media/Files/Pdfs/library/whitepapers/pdfs/supported... > WMS - http://www.opengeospatial.org/standards/wms > WFS - http://www.opengeospatial.org/standards/wfs > Using MapViewer to show maps based on WMS services. The WMS services are provided by a GeoServer like ArcGIS or GeoServer. > OData has also some capabilities in the Geo space especially on the .Net libraries side. > See http://www.odata.org/libraries/ for Microsoft.Spatial (OData v4) and System.Spatial (OData v1-3) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3871) moving documentation from confluence to gitbook

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3871?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-3871: --------------------------------------- Kylin can you add me to teiid.gitbooks.io and we need to get the site pointed over to teiid/teiid-documents as it still seems to be feed off of teiiddocs - https://www.gitbook.com/book/teiid/reference-guide/details > moving documentation from confluence to gitbook > ------------------------------------------------- > > Key: TEIID-3871 > URL: https://issues.jboss.org/browse/TEIID-3871 > Project: Teiid > Issue Type: Task > Components: Documentation > Affects Versions: 9.x > Reporter: Kylin Soong > Assignee: Kylin Soong > Fix For: 9.x > > > From Teiid DV 7 F2F Notes, > " In the Teiid 9.x timeframe we should look toward moving everything to gitbook / markdown. We should start by migrating the documentation and solicit help with the website if possible." > This issue will address this. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3938) EdmDate and EdmTimeOfDay output in local timezone

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-3938?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-3938: ------------------------------------- These are comments from OData TC not Olingo folks. So, we need to generate respective JIRA in Olingo JIRA. > EdmDate and EdmTimeOfDay output in local timezone > ------------------------------------------------- > > Key: TEIID-3938 > URL: https://issues.jboss.org/browse/TEIID-3938 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Reporter: Steven Hawkins > Assignee: Steven Hawkins > > EdmDate and EdmTimeOfDay both assume GMT for incoming string values - however when the convert from Java objects to string they use the local/default Calendar. So when Teiid is on a server not in GMT date and time value sent via the odata4 translator will likely be wrong. > Ramesh: > I have posted a question to the Olingo development group here http://markmail.org/search/list:org.apache.olingo.dev#query:list%3Aorg.ap... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3938) EdmDate and EdmTimeOfDay output in local timezone

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3938?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-3938: --------------------------------------- > No, they are saying the parsing Date or Time should be exactly same in every time zone Their own code seems to contradict that, as the assume GMT for parsing. To highlight the issue: TimeZone.setDefault(TimeZone.getTimeZone("GMT+1")); Date date = EdmTimeOfDay.getInstance().valueOfString("11:11:11", true, 4000, 0, 0, true, Date.class); assertEquals("Thu Jan 01 12:11:11 GMT+01:00 1970", date.toString()); String val = EdmTimeOfDay.getInstance().valueToString(date, true, 4000, 0, 0, true); assertEquals("11:11:11", val); The last line will fail because the output will be 12:11:11 instead - which means that the string parse->Java->string cycle is inconsistent when the default timezone is not GMT. This may just be a misunderstanding of Java Date/Time - see EdmDateTimeOffset.createDateTime the case with value instanceOf Date uses Calendar.getInstance(), but has some comment about UTC - which is not meaningful and should not be different than the java.sql.Time handling. They should be using Calendar.getInstance("GMT"). The Calendar case has a similar issue. EdmTimeOfDay and EdmDate only work correctly when represented by either java.sql.Time or Long. So this shouldn't affect us in the TimeOfDay case as the runtime type will be java.sql.Time. However it will be an issue with EdmDate that we either have to workaround by converting our runtime values to longs or get them to fix this. > EdmDate and EdmTimeOfDay output in local timezone > ------------------------------------------------- > > Key: TEIID-3938 > URL: https://issues.jboss.org/browse/TEIID-3938 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Reporter: Steven Hawkins > Assignee: Steven Hawkins > > EdmDate and EdmTimeOfDay both assume GMT for incoming string values - however when the convert from Java objects to string they use the local/default Calendar. So when Teiid is on a server not in GMT date and time value sent via the odata4 translator will likely be wrong. > Ramesh: > I have posted a question to the Olingo development group here http://markmail.org/search/list:org.apache.olingo.dev#query:list%3Aorg.ap... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3942) Accumulo translators should use LexiCoders to preserve the native ordering

by Ramesh Reddy (JIRA)

Ramesh Reddy created TEIID-3942: ----------------------------------- Summary: Accumulo translators should use LexiCoders to preserve the native ordering Key: TEIID-3942 URL: https://issues.jboss.org/browse/TEIID-3942 Project: Teiid Issue Type: Enhancement Components: Misc. Connectors Affects Versions: 8.12.4 Reporter: Ramesh Reddy Assignee: Ramesh Reddy Accumulo translator currently converts all the data to string based byte array and management of the data types is done at the translator level. In 1.6 version, there is support for LexiCoders which is standard way to encode/decode Java data types. The translator must be changed to make use of these. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3941) Upgrade Accumulo libraries to 1.6.4 version

by Ramesh Reddy (JIRA)

Ramesh Reddy created TEIID-3941: ----------------------------------- Summary: Upgrade Accumulo libraries to 1.6.4 version Key: TEIID-3941 URL: https://issues.jboss.org/browse/TEIID-3941 Project: Teiid Issue Type: Enhancement Components: Misc. Connectors Affects Versions: 8.12.4 Reporter: Ramesh Reddy Assignee: Ramesh Reddy Fix For: 8.12.5 The latest version of the Accumulo is 1.6.4 and 1.7.0, the version Teiid supports is 1.5, which was chosen from 2 years ago. We should upgrade to 1.6.4. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3938) EdmDate and EdmTimeOfDay output in local timezone

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-3938?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-3938: ------------------------------------- No, they are saying the parsing Date or Time should be exactly same in every time zone irrespective if TZ > EdmDate and EdmTimeOfDay output in local timezone > ------------------------------------------------- > > Key: TEIID-3938 > URL: https://issues.jboss.org/browse/TEIID-3938 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Reporter: Steven Hawkins > Assignee: Steven Hawkins > > EdmDate and EdmTimeOfDay both assume GMT for incoming string values - however when the convert from Java objects to string they use the local/default Calendar. So when Teiid is on a server not in GMT date and time value sent via the odata4 translator will likely be wrong. > Ramesh: > I have posted a question to the Olingo development group here http://markmail.org/search/list:org.apache.olingo.dev#query:list%3Aorg.ap... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3938) EdmDate and EdmTimeOfDay output in local timezone

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-3938?page=com.atlassian.jira.plugin... ] Ramesh Reddy edited comment on TEIID-3938 at 1/28/16 1:55 PM: -------------------------------------------------------------- No, they are saying the parsing Date or Time should be exactly same in every time zone was (Author: rareddy): No, they are saying the parsing Date or Time should be exactly same in every time zone irrespective if TZ > EdmDate and EdmTimeOfDay output in local timezone > ------------------------------------------------- > > Key: TEIID-3938 > URL: https://issues.jboss.org/browse/TEIID-3938 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Reporter: Steven Hawkins > Assignee: Steven Hawkins > > EdmDate and EdmTimeOfDay both assume GMT for incoming string values - however when the convert from Java objects to string they use the local/default Calendar. So when Teiid is on a server not in GMT date and time value sent via the odata4 translator will likely be wrong. > Ramesh: > I have posted a question to the Olingo development group here http://markmail.org/search/list:org.apache.olingo.dev#query:list%3Aorg.ap... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3938) EdmDate and EdmTimeOfDay output in local timezone

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3938?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-3938: --------------------------------------- Meaning GMT correct? > EdmDate and EdmTimeOfDay output in local timezone > ------------------------------------------------- > > Key: TEIID-3938 > URL: https://issues.jboss.org/browse/TEIID-3938 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Reporter: Steven Hawkins > Assignee: Steven Hawkins > > EdmDate and EdmTimeOfDay both assume GMT for incoming string values - however when the convert from Java objects to string they use the local/default Calendar. So when Teiid is on a server not in GMT date and time value sent via the odata4 translator will likely be wrong. > Ramesh: > I have posted a question to the Olingo development group here http://markmail.org/search/list:org.apache.olingo.dev#query:list%3Aorg.ap... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues January 2016