[JBoss JIRA] (TEIID-3686) OData DELETE nonexisting row - wrong response code
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3686?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-3686:
------------------------------------------------
jolee(a)redhat.com changed the Status of [bug 1261027|https://bugzilla.redhat.com/show_bug.cgi?id=1261027] from NEW to MODIFIED
> OData DELETE nonexisting row - wrong response code
> --------------------------------------------------
>
> Key: TEIID-3686
> URL: https://issues.jboss.org/browse/TEIID-3686
> Project: Teiid
> Issue Type: Bug
> Components: OData
> Affects Versions: 8.7.1.6_2
> Reporter: Michal Sanitrak
> Assignee: Ramesh Reddy
> Labels: CR1
> Fix For: 8.12
>
>
> I deployed VDB that can be accessed with OData. When I perform DELETE request to remove row for first time response code is 200 OK (maybe it should be 204) but when I repeat the same DELETE request and tried to delete already deleted entry, response is again 200 OK, but it should be 404 Not Found. Same thing happens even I when tried to delete entry with id that doesn't exist at all.
> Only indication of this problem is in the server log:
> {code:plain}INFO [org.teiid.ODATA] (http-/127.0.0.1:8080-1) no entity to delete in = BooksMySQL.BOOKS with key= ('1')
> {code}
> I think that response code for deleting row that doesn't exist should be different than 200 OK.
> For example the service at odata.org returns following content with response code 404 Not Found:
> {code:xml}
> <?xml version="1.0" encoding="utf-8" standalone="yes"?>
> <error xmlns="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata">
> <code></code>
> <message xml:lang="en-US">Resource not found for the segment 'Products'.</message>
> </error>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (TEIID-3685) org.teiid.padSpace does not affect to the "IN" operator
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3685?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-3685:
------------------------------------------------
jolee(a)redhat.com changed the Status of [bug 1260874|https://bugzilla.redhat.com/show_bug.cgi?id=1260874] from NEW to MODIFIED
> org.teiid.padSpace does not affect to the "IN" operator
> -------------------------------------------------------
>
> Key: TEIID-3685
> URL: https://issues.jboss.org/browse/TEIID-3685
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.7.1
> Environment: JBoss DV 6.1.2
> Reporter: hisao furuichi
> Assignee: Steven Hawkins
> Fix For: 8.12, 8.11.4
>
> Attachments: datasert.csv, INTERNAL_TEST.zip
>
>
> org.teiid.padSpace does affect to "=" operator. But does not affect to "IN" operator.
> [data for a column named "id"]
> {noformat}
> "test1 "
> {noformat}
> ["=" operator] I can get a result
> {noformat}
> SELECT * FROM ViewModel.originalViewTable WHERE ViewModel.originalViewTable.id ='TEST1';
> {noformat}
> ["IN" operator] I can not get a result
> {noformat}
> SELECT * FROM ViewModel.originalViewTable WHERE ViewModel.originalViewTable.id IN ('TEST1', 'TEST2');
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (TEIID-3559) Refactor Object and Infinispan translator / connectors
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3559?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3559:
---------------------------------------
Ok, that has been reverted back to dv. So we just have the failing tests on the build box to resolve.
> Refactor Object and Infinispan translator / connectors
> ------------------------------------------------------
>
> Key: TEIID-3559
> URL: https://issues.jboss.org/browse/TEIID-3559
> Project: Teiid
> Issue Type: Task
> Components: Misc. Connectors
> Reporter: Van Halbert
> Assignee: Van Halbert
> Priority: Optional
>
> Now that JDG has reworked its remote-cache and changed (reduced) what dependencies its exposed, there's now more common code between the object/infinispan-cache translator/connector and the infinispan-cache-dsl translator/connector. I think refactoring can eliminate issues with support and ensure common behavior across all the code.
> Where is common code seen:
> - searching (i.e., DSLSearch)
> - updates (InfinispanUpdateExecution)
> - ClassRegistry
> (for starters)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (TEIID-3731) Introduce an alternative protocol to lessen the usage of java serialization
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-3731:
-------------------------------------
Summary: Introduce an alternative protocol to lessen the usage of java serialization
Key: TEIID-3731
URL: https://issues.jboss.org/browse/TEIID-3731
Project: Teiid
Issue Type: Feature Request
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 9.0
Even with heavy usage of externalizable there is still an overhead to java serialization blocking and reference tracking. With custom object input/output we can eliminate the need for java serialization with most messages.
This however would need to work beside the existing java serialization protocol for backwards compatibility.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (TEIID-3643) VDB based kerberos authentication does not work with ODBC
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3643?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-3643:
------------------------------------------------
jolee(a)redhat.com changed the Status of [bug 1254532|https://bugzilla.redhat.com/show_bug.cgi?id=1254532] from NEW to MODIFIED
> VDB based kerberos authentication does not work with ODBC
> ---------------------------------------------------------
>
> Key: TEIID-3643
> URL: https://issues.jboss.org/browse/TEIID-3643
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.7.1.6_2
> Reporter: Juraj Duráni
> Assignee: Steven Hawkins
> Fix For: 8.12, 8.11.3
>
>
> I have a VDB configured to use GSS authentication. Both, JDBC and ODBC ports are configured to use default "teiid-security" security domain. Accessing the VDB through JDBC works fine, but ODBC throws exception [1], [2]. If the ODBC port is configured to use GSS authentication, connection is successful.
> [1]
> isql -v krb
> [08001][unixODBC]could not connect to server: Spojenie odmietnut
> Is the server running on host "localhost" (::1) and accepting
> TCP/IP connections on port 35432?
> ERROR: TEIID40055 Wrong logon method is being used. Server is not set up for Kerberos based authentication.
> DETAIL: org.teiid.jdbc.TeiidSQLException: TEIID40055 Wrong logon method is being used. Server is not set up for Kerberos based authentication.
> [ISQL]ERROR: Could not SQLConnect
> [2]
> 11:49:56,470 ERROR [org.teiid.ODBC] (New I/O worker #3) TEIID40015 Unexpected error occurred: org.teiid.client.security.LogonException: TEIID40055 Wrong logon method is being used. Server is not set up for Kerberos based authentication.
> at org.teiid.transport.LogonImpl.neogitiateGssLogin(LogonImpl.java:168) [teiid-runtime-8.7.1.6_2-redhat-4.jar:8.7.1.6_2-redhat-4]
> at org.teiid.odbc.ODBCServerRemoteImpl.logon(ODBCServerRemoteImpl.java:237) [teiid-runtime-8.7.1.6_2-redhat-4.jar:8.7.1.6_2-redhat-4]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_40]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_40]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_40]
> at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_40]
> at org.teiid.transport.ODBCClientInstance.processMessage(ODBCClientInstance.java:127) [teiid-runtime-8.7.1.6_2-redhat-4.jar:8.7.1.6_2-redhat-4]
> at org.teiid.transport.ODBCClientInstance.receivedMessage(ODBCClientInstance.java:116) [teiid-runtime-8.7.1.6_2-redhat-4.jar:8.7.1.6_2-redhat-4]
> at org.teiid.transport.SSLAwareChannelHandler.messageReceived(SSLAwareChannelHandler.java:211) [teiid-runtime-8.7.1.6_2-redhat-4.jar:8.7.1.6_2-redhat-4]
> at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:88) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:296) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:462) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:443) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:303) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:109) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:328) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:90) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_40]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_40]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_40]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months