[JBoss JIRA] (TEIID-2920) Certain Translator Override Definitions for JDBC have identical display names
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-2920?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-2920:
-------------------------------------
Yes, you are correct. Ok will make the description on them with deprecated note.
> Certain Translator Override Definitions for JDBC have identical display names
> -----------------------------------------------------------------------------
>
> Key: TEIID-2920
> URL: https://issues.jboss.org/browse/TEIID-2920
> Project: Teiid
> Issue Type: Bug
> Reporter: Barry LaFond
> Assignee: Ramesh Reddy
> Fix For: 8.7
>
>
> In VDB editor, noticed that their are duplicate display names for certain JDBC translator properties. Confusing...
> Debugged a little and here are the culprits I found:
> ID = supportsDirectQueryProcedure
> * Display Name = *Supports direct query procedure*
> ID = supportsNativeQueries
> * Display Name = *Supports direct query procedure*
> ID = DirectQueryProcedureName
> * Display Name = *Name of the direct query procedure*
> ID = NativeQueryProcedureName
> * Display Name = *Name of the direct query procedure*
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 6 months
[JBoss JIRA] (TEIID-2906) bind variables and sql appear when exception thrown
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2906?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2906:
---------------------------------------
> I was wondering if you could fix again that only the exception message of stack trace bottom layer exception outputs to log when it is not TeiidException or TeiidRuntimeExceptio.
That would be unpredictable as to whether source sql/values would be present there as it would be up to the source system exception.
> bind variables and sql appear when exception thrown
> ---------------------------------------------------
>
> Key: TEIID-2906
> URL: https://issues.jboss.org/browse/TEIID-2906
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Affects Versions: 8.4
> Environment: - JDV 6.0.0
> Reporter: Hisanobu Okuda
> Assignee: Steven Hawkins
> Fix For: 8.7
>
> Attachments: PreparedStatementTest.java, test.vdb
>
>
> When a query causes an exception, bind variables and sql are written in teiid-command.log and are sent to a client.
> teiid-command.log:-
> {code}
> 19:36:19,942 WARN [org.teiid.PROCESSOR] (Worker8_QueryProcessorQueue29) TEIID30020 Processing exception for request 6jFRdyvDG5bU.0
> 'TEIID30504 New_MySQL: 0 TEIID11008:TEIID11004 Error executing statement(s): [Prepared Values: ['hokuda'] SQL: SELECT g_0.`USERNAM
> E`, g_0.`PASSWORD`, g_0.`USERROLE` FROM `LOGIN`.`USERS` AS g_0 WHERE g_0.`USERNAME` = ?]'. Originally TeiidProcessingException 'Can
> not read response from server. Expected to read 4 bytes, read 0 bytes before connection was unexpectedly lost.' MysqlIO.java:3039.
> Enable more detailed logging to see the entire stacktrace.
> {code}
> printStackTrace() at client side:-
> {code}
> org.teiid.jdbc.TeiidSQLException: TEIID30504 Remote org.teiid.core.TeiidProcessingException: TEIID30504 New_MySQL: 0 TEIID11008:TEI
> ID11004 Error executing statement(s): [Prepared Values: ['hokuda'] SQL: SELECT g_0.`USERNAME`, g_0.`PASSWORD`, g_0.`USERROLE` FROM
> `LOGIN`.`USERS` AS g_0 WHERE g_0.`USERNAME` = ?]
> at org.teiid.jdbc.TeiidSQLException.create(TeiidSQLException.java:135)
> at org.teiid.jdbc.TeiidSQLException.create(TeiidSQLException.java:71)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 6 months
[JBoss JIRA] (TEIID-2920) Certain Translator Override Definitions for JDBC have identical display names
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2920?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2920:
---------------------------------------
No, we get the methods to set based upon the annotations.
> Certain Translator Override Definitions for JDBC have identical display names
> -----------------------------------------------------------------------------
>
> Key: TEIID-2920
> URL: https://issues.jboss.org/browse/TEIID-2920
> Project: Teiid
> Issue Type: Bug
> Reporter: Barry LaFond
> Assignee: Ramesh Reddy
> Fix For: 8.7
>
>
> In VDB editor, noticed that their are duplicate display names for certain JDBC translator properties. Confusing...
> Debugged a little and here are the culprits I found:
> ID = supportsDirectQueryProcedure
> * Display Name = *Supports direct query procedure*
> ID = supportsNativeQueries
> * Display Name = *Supports direct query procedure*
> ID = DirectQueryProcedureName
> * Display Name = *Name of the direct query procedure*
> ID = NativeQueryProcedureName
> * Display Name = *Name of the direct query procedure*
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 6 months
[JBoss JIRA] (TEIID-2920) Certain Translator Override Definitions for JDBC have identical display names
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-2920?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-2920:
-------------------------------------
No they would just not get reported as exposed properties through the API, but if one sets the property anyway it should works as is
> Certain Translator Override Definitions for JDBC have identical display names
> -----------------------------------------------------------------------------
>
> Key: TEIID-2920
> URL: https://issues.jboss.org/browse/TEIID-2920
> Project: Teiid
> Issue Type: Bug
> Reporter: Barry LaFond
> Assignee: Ramesh Reddy
> Fix For: 8.7
>
>
> In VDB editor, noticed that their are duplicate display names for certain JDBC translator properties. Confusing...
> Debugged a little and here are the culprits I found:
> ID = supportsDirectQueryProcedure
> * Display Name = *Supports direct query procedure*
> ID = supportsNativeQueries
> * Display Name = *Supports direct query procedure*
> ID = DirectQueryProcedureName
> * Display Name = *Name of the direct query procedure*
> ID = NativeQueryProcedureName
> * Display Name = *Name of the direct query procedure*
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 6 months
[JBoss JIRA] (TEIID-2920) Certain Translator Override Definitions for JDBC have identical display names
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2920?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2920:
---------------------------------------
That would cause the old properties to not work at all right?
> Certain Translator Override Definitions for JDBC have identical display names
> -----------------------------------------------------------------------------
>
> Key: TEIID-2920
> URL: https://issues.jboss.org/browse/TEIID-2920
> Project: Teiid
> Issue Type: Bug
> Reporter: Barry LaFond
> Assignee: Ramesh Reddy
> Fix For: 8.7
>
>
> In VDB editor, noticed that their are duplicate display names for certain JDBC translator properties. Confusing...
> Debugged a little and here are the culprits I found:
> ID = supportsDirectQueryProcedure
> * Display Name = *Supports direct query procedure*
> ID = supportsNativeQueries
> * Display Name = *Supports direct query procedure*
> ID = DirectQueryProcedureName
> * Display Name = *Name of the direct query procedure*
> ID = NativeQueryProcedureName
> * Display Name = *Name of the direct query procedure*
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 6 months
[JBoss JIRA] (TEIID-2911) Guard against external entity resolving
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-2911?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated TEIID-2911:
-------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1085557, https://bugzilla.redhat.com/show_bug.cgi?id=1085554, https://bugzilla.redhat.com/show_bug.cgi?id=1085555, https://bugzilla.redhat.com/show_bug.cgi?id=1085556 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1085557, https://bugzilla.redhat.com/show_bug.cgi?id=1085554, https://bugzilla.redhat.com/show_bug.cgi?id=1085555)
> Guard against external entity resolving
> ---------------------------------------
>
> Key: TEIID-2911
> URL: https://issues.jboss.org/browse/TEIID-2911
> Project: Teiid
> Issue Type: Bug
> Components: OData, Query Engine
> Affects Versions: 7.7, 8.4
> Reporter: Van Halbert
> Assignee: Steven Hawkins
> Priority: Critical
> Fix For: 8.4.2, 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 6 months
[JBoss JIRA] (TEIID-2911) Guard against external entity resolving
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-2911?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated TEIID-2911:
-------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1085557, https://bugzilla.redhat.com/show_bug.cgi?id=1085554 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1085557)
> Guard against external entity resolving
> ---------------------------------------
>
> Key: TEIID-2911
> URL: https://issues.jboss.org/browse/TEIID-2911
> Project: Teiid
> Issue Type: Bug
> Components: OData, Query Engine
> Affects Versions: 7.7, 8.4
> Reporter: Van Halbert
> Assignee: Steven Hawkins
> Priority: Critical
> Fix For: 8.4.2, 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 6 months
[JBoss JIRA] (TEIID-2911) Guard against external entity resolving
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-2911?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated TEIID-2911:
-------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1085557, https://bugzilla.redhat.com/show_bug.cgi?id=1085554, https://bugzilla.redhat.com/show_bug.cgi?id=1085555 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1085557, https://bugzilla.redhat.com/show_bug.cgi?id=1085554)
> Guard against external entity resolving
> ---------------------------------------
>
> Key: TEIID-2911
> URL: https://issues.jboss.org/browse/TEIID-2911
> Project: Teiid
> Issue Type: Bug
> Components: OData, Query Engine
> Affects Versions: 7.7, 8.4
> Reporter: Van Halbert
> Assignee: Steven Hawkins
> Priority: Critical
> Fix For: 8.4.2, 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 6 months
[JBoss JIRA] (TEIID-2911) Guard against external entity resolving
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-2911?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated TEIID-2911:
-------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1085557
> Guard against external entity resolving
> ---------------------------------------
>
> Key: TEIID-2911
> URL: https://issues.jboss.org/browse/TEIID-2911
> Project: Teiid
> Issue Type: Bug
> Components: OData, Query Engine
> Affects Versions: 7.7, 8.4
> Reporter: Van Halbert
> Assignee: Steven Hawkins
> Priority: Critical
> Fix For: 8.4.2, 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 6 months
[JBoss JIRA] (TEIID-2920) Certain Translator Override Definitions for JDBC have identical display names
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-2920?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-2920:
-------------------------------------
Can I delete the Annotation on the deprecated methods to avoid the issue?
> Certain Translator Override Definitions for JDBC have identical display names
> -----------------------------------------------------------------------------
>
> Key: TEIID-2920
> URL: https://issues.jboss.org/browse/TEIID-2920
> Project: Teiid
> Issue Type: Bug
> Reporter: Barry LaFond
> Assignee: Ramesh Reddy
> Fix For: 8.7
>
>
> In VDB editor, noticed that their are duplicate display names for certain JDBC translator properties. Confusing...
> Debugged a little and here are the culprits I found:
> ID = supportsDirectQueryProcedure
> * Display Name = *Supports direct query procedure*
> ID = supportsNativeQueries
> * Display Name = *Supports direct query procedure*
> ID = DirectQueryProcedureName
> * Display Name = *Name of the direct query procedure*
> ID = NativeQueryProcedureName
> * Display Name = *Name of the direct query procedure*
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 6 months