[JBoss JIRA] (TEIID-2605) Optimization substitutes wrong column in where clause
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2605?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-2605.
---------------------------------
> Optimization substitutes wrong column in where clause
> -----------------------------------------------------
>
> Key: TEIID-2605
> URL: https://issues.jboss.org/browse/TEIID-2605
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.1
> Environment: z/OS
> Reporter: Jeff Hayes
> Assignee: Steven Hawkins
> Attachments: query_plan.txt, views.xml
>
>
> Optimization results in a query with a different column in the WHERE clause producing an empty result set.
> Full query plan is attached but the beginning and ending queries are shown below. Note that the subject column of the IN clause is SCOPEID but optimization changes it to AUTHID for some reason.
> USER COMMAND:
> SELECT * FROM SECURITY.SCPXREF AS CHORUS_B WHERE (CHORUS_B.SYSID = 'DE29') AND ((CHORUS_B.SCOPEID IN (SELECT SN5.SCOPEID FROM SECURI
> TY.SCPNEXT AS SN5 WHERE (SYSID = 'DE29') AND (NEXTREC IN (SELECT SN4.SCOPEID FROM SECURITY.SCPNEXT AS SN4 WHERE (SYSID = 'DE29') AND
> (NEXTREC IN (SELECT SN3.SCOPEID FROM SECURITY.SCPNEXT AS SN3 WHERE (SYSID = 'DE29') AND (NEXTREC IN (SELECT SN2.SCOPEID FROM SECURI
> TY.SCPNEXT AS SN2 WHERE (SYSID = 'DE29') AND (NEXTREC = 'CHRDEPT1'))))))))) OR (CHORUS_B.SCOPEID IN (SELECT SN4.SCOPEID FROM SECURIT
> Y.SCPNEXT AS SN4 WHERE (SYSID = 'DE29') AND (NEXTREC IN (SELECT SN3.SCOPEID FROM SECURITY.SCPNEXT AS SN3 WHERE (SYSID = 'DE29') AND
> (NEXTREC IN (SELECT SN2.SCOPEID FROM SECURITY.SCPNEXT AS SN2 WHERE (SYSID = 'DE29') AND (NEXTREC = 'CHRDEPT1'))))))) OR (CHORUS_B.SC
> OPEID IN (SELECT SN3.SCOPEID FROM SECURITY.SCPNEXT AS SN3 WHERE (SYSID = 'DE29') AND (NEXTREC IN (SELECT SN2.SCOPEID FROM SECURITY.S
> CPNEXT AS SN2 WHERE (SYSID = 'DE29') AND (NEXTREC = 'CHRDEPT1'))))) OR (CHORUS_B.SCOPEID IN (SELECT SN2.SCOPEID FROM SECURITY.SCPNEX
> T AS SN2 WHERE (SYSID = 'DE29') AND (NEXTREC = 'CHRDEPT1'))) OR (CHORUS_B.SCOPEID = 'CHRDEPT1'))
> OPTIMIZATION COMPLETE:
> PROCESSOR PLAN:
> AccessNode(10) output=[x.sysid AS sysid, x.scopeid AS authid, x.authid AS scopeid, x.authtype AS authtype] SELECT g_0.SYSID, g_0.SCO
> PEID, g_0.AUTHID, g_0.AUTHTYPE FROM SECURITY_CIA_DB2_D91BPTIB_CIADB01.SCPXREF AS g_0 WHERE (g_0.SYSID = 'DE29') AND ((g_0.AUTHID IN
> (SELECT g_1.SCOPEID FROM SECURITY_CIA_DB2_D91BPTIB_CIADB01.SCPNEXT AS g_1 WHERE (g_1.SYSID = 'DE29') AND (g_1.NEXTREC IN (SELECT g_2
> .SCOPEID FROM SECURITY_CIA_DB2_D91BPTIB_CIADB01.SCPNEXT AS g_2 WHERE (g_2.SYSID = 'DE29') AND (g_2.NEXTREC IN (SELECT g_3.SCOPEID FR
> OM SECURITY_CIA_DB2_D91BPTIB_CIADB01.SCPNEXT AS g_3 WHERE (g_3.SYSID = 'DE29') AND (g_3.NEXTREC IN (SELECT g_4.SCOPEID FROM SECURITY
> _CIA_DB2_D91BPTIB_CIADB01.SCPNEXT AS g_4 WHERE (g_4.SYSID = 'DE29') AND (g_4.NEXTREC = 'CHRDEPT1'))))))))) OR (g_0.AUTHID IN (SELECT
> g_5.SCOPEID FROM SECURITY_CIA_DB2_D91BPTIB_CIADB01.SCPNEXT AS g_5 WHERE (g_5.SYSID = 'DE29') AND (g_5.NEXTREC IN (SELECT g_6.SCOPEI
> D FROM SECURITY_CIA_DB2_D91BPTIB_CIADB01.SCPNEXT AS g_6 WHERE (g_6.SYSID = 'DE29') AND (g_6.NEXTREC IN (SELECT g_7.SCOPEID FROM SECU
> RITY_CIA_DB2_D91BPTIB_CIADB01.SCPNEXT AS g_7 WHERE (g_7.SYSID = 'DE29') AND (g_7.NEXTREC = 'CHRDEPT1'))))))) OR (g_0.AUTHID IN (SELE
> CT g_8.SCOPEID FROM SECURITY_CIA_DB2_D91BPTIB_CIADB01.SCPNEXT AS g_8 WHERE (g_8.SYSID = 'DE29') AND (g_8.NEXTREC IN (SELECT g_9.SCOP
> EID FROM SECURITY_CIA_DB2_D91BPTIB_CIADB01.SCPNEXT AS g_9 WHERE (g_9.SYSID = 'DE29') AND (g_9.NEXTREC = 'CHRDEPT1'))))) OR (g_0.AUTH
> ID IN (SELECT g_10.SCOPEID FROM SECURITY_CIA_DB2_D91BPTIB_CIADB01.SCPNEXT AS g_10 WHERE (g_10.SYSID = 'DE29') AND (g_10.NEXTREC = 'C
> HRDEPT1'))) OR (g_0.AUTHID = 'CHRDEPT1'))
> The view definitions are shown below:
> <view name="SCPNEXT">
> <columns>
> <column name="sysid" type="varchar"/>
> <column name="scopeid" type="varchar"/>
> <column name="nextrec" type="varchar"/>
> </columns>
> <definition>
> #if ($db.count("select count(*) from sys.tables where Name='config' and SchemaName = 'security_db'") > 0)
> #set ($count = 0)
> #foreach($t in $db.query("select DB_TYPE, DB_LOC, DB_QUAL from security_db.config WHERE TYPE = 'CIA'"))
> #if ($db.count("select count(*) from sys.tables where SchemaName = 'SECURITY_CIA_${t.DB_TYPE}_${t.DB_LOC}_${t.DB_QUAL}'") == 0)
> #set ($count = $count + 1)
> #end
> #end
> #if ($count == 0)
> SELECT t.sysid, t.scopeid, t.nextrec
> FROM (
> #foreach($t in $db.query("select DB_TYPE, DB_LOC, DB_QUAL from security_db.config WHERE TYPE = 'CIA'"))
> SELECT n.sysid, n.scopeid, n.nextrec
> FROM SECURITY_CIA_${t.DB_TYPE}_${t.DB_LOC}_${t.DB_QUAL}.SCPNEXT n
> #if( $velocityHasNext ) UNION #end
> #end
> ) AS t
> #end
> #end
> </definition>
> </view>
> <view name="SCPXREF">
> <columns>
> <column name="sysid" type="varchar"/>
> <column name="authid" type="varchar"/>
> <column name="scopeid" type="varchar"/>
> <column name="authtype" type="varchar"/>
> </columns>
> <definition>
> #if ($db.count("select count(*) from sys.tables where Name='config' and SchemaName = 'security_db'") > 0)
> #set ($count = 0)
> #foreach($t in $db.query("select DB_TYPE, DB_LOC, DB_QUAL from security_db.config WHERE TYPE = 'CIA'"))
> #if ($db.count("select count(*) from sys.tables where SchemaName = 'SECURITY_CIA_${t.DB_TYPE}_${t.DB_LOC}_${t.DB_QUAL}'") == 0)
> #set ($count = $count + 1)
> #end
> #end
> #if ($count == 0)
> SELECT sysid, scopeid, authid, authtype
> FROM (
> #foreach($t in $db.query("select DB_TYPE, DB_LOC, DB_QUAL from security_db.config WHERE TYPE = 'CIA'"))
> SELECT x.sysid, x.scopeid, x.authid, x.authtype
> FROM SECURITY_CIA_${t.DB_TYPE}_${t.DB_LOC}_${t.DB_QUAL}.SCPXREF x
> #if( $velocityHasNext ) UNION #end
> #end
> ) AS t
> #end
> #end
> </definition>
> </view>
> I guess the best way to test this is to define these views and run the input query with SHOWPLAN=DEBUG and see if the AUTHID substitution is occurring.
> Thanks!
--
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
1 week, 2 days
[JBoss JIRA] (TEIIDSB-114) Validate vdb-import
by Ramesh Reddy (Jira)
Ramesh Reddy created TEIIDSB-114:
------------------------------------
Summary: Validate vdb-import
Key: TEIIDSB-114
URL: https://issues.jboss.org/browse/TEIIDSB-114
Project: Teiid Spring Boot
Issue Type: Feature Request
Components: core
Reporter: Ramesh Reddy
Fix For: 1.2.0
VDB Import should be supported through the Teiid Spring Boot. The groundwork has been done in the VDB plugin.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 2 months
[JBoss JIRA] (TEIID-5803) Seems to be not possible to POST a new entity via a navigation property to a collection
by Ramesh Reddy (Jira)
[ https://issues.jboss.org/browse/TEIID-5803?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-5803:
-------------------------------------
One thing I want to ask before I look into merge the update into Olingo is this checked against the 4.0 or 4.0.1 spec? because Olingo is at 4.0
> Seems to be not possible to POST a new entity via a navigation property to a collection
> ---------------------------------------------------------------------------------------
>
> Key: TEIID-5803
> URL: https://issues.jboss.org/browse/TEIID-5803
> Project: Teiid
> Issue Type: Bug
> Components: OData
> Reporter: Christoph John
> Assignee: Steven Hawkins
> Priority: Major
>
> Hello Steven,
> I am currently trying to post/create an entity in a collection via a relative binding path. Unfortunately, I always get an error saying
> {"error":{"code":null,"message":"HTTP method 'POST' not allowed for this resource."}}
> I have bound the root view to .../Account(1) from which I have a navigation property to the relevant collection. Currently I have trouble to post to collections via a navigation path.
> As far as I understood from
> http://docs.oasis-open.org/odata/odata/v4.01/csprd04/part1-protocol/odata...
> chapter 11.4.2 this should work according to my tries below.
> Might you tell me if my path via the navigation property should work for post requests or what I am doing wrong?
> Directly writing to the collection is fine, i.e. something like the following:
> curl --user sap:sap -i -X POST -H 'Content-Type: application/json;charset=UTF-8;IEEE754Compatible=true' -d '{"fkProfile":"1","idCode":null,"lc":"de","product_name":"A Product","brands":"A brand","energy_100g":2259,"carbohydrates_100g":60.08,"sugars_100g":10.1,"proteins_100g":24.03,"fat_100g":15.89,"saturated_fat_100g":10.0,"salt_100g":1.0}' http://localhost:18080/odata4/svc/my_nutri_diary/UserDefinedProducts
> and a GET request via a navigation property path (given below) also works, but a path via a navigation property does not work when using the path in a POST request. I.e. when going via the navigation property. Example:
> curl --user sap:sap -i -X POST -H 'Content-Type: application/json;charset=UTF-8;IEEE754Compatible=true' -d '{"fkProfile":"1","idCode":null,"lc":"de","product_name":"A Product","brands":"A brand","energy_100g":2259,"carbohydrates_100g":60.08,"sugars_100g":10.1,"proteins_100g":24.03,"fat_100g":15.89,"saturated_fat_100g":10.0,"salt_100g":1.0}' http://localhost:18080/odata4/svc/my_nutri_diary/Account\(1\)/UserDefined...
> Here you find the backend metadata. They show that UserDefinedProducts_fKUserDefinedProductToAccount is simply a navigaton path from Account(xxx) to the UserDefinedProducts collection.
> https://ecubed-solutions.ddnss.de/odata4/svc/my_nutri_diary/$metadata
> user: sap
> password: sap
> Thanks a lot for your help!
> Note: I am currently trying to add data via a navigation property path because my frontend library sapui5 only caches and syncs data queried via a single context binding. Hence, to be consistent via all views in my app which bind to the odata model, I need to use only one absolute binding and have to query/update other contexts via relative binding paths from this single absolute path, to allow for all frontend views to maintain data consistency
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 2 months
[JBoss JIRA] (TEIID-5803) Seems to be not possible to POST a new entity via a navigation property to a collection
by Christoph John (Jira)
[ https://issues.jboss.org/browse/TEIID-5803?page=com.atlassian.jira.plugin... ]
Christoph John edited comment on TEIID-5803 at 8/31/19 10:04 AM:
-----------------------------------------------------------------
Hello Steven,
>> This can addressed without adding general navigation binding support on create - that should be addressed in a separate issue.
I am not sure now what is addressed here and what shall be addressed in an additional issue.
You mean I should add an additional issue?
Or is the additional issue what you references as:
https://jira.apache.org/jira/browse/OLINGO-1389
One further note on the discussion. I will also need to be able to address updates of an existing entity via a navigation binding. I have not tried yet if this does work. From your previous comments I assume you will interpret this issue here for updates on an item via navigation property and the OLINGO one for create? Is my interpretation correct?
was (Author: cjohn001):
Hello Steven,
>> This can addressed without adding general navigation binding support on create - that should be addressed in a separate issue.
I am not sure now what is addressed here and what shall be addressed in an additional issue.
You mean I should add an additional issue or is the additional issue what you references as:
https://jira.apache.org/jira/browse/OLINGO-1389
One further note on the discussion. I will also need to be able to address updates of an existing entity via a navigation binding. I have not tried yet if this does work. From your previous comments I assume you will interpret this issue here for updates on an item via navigation property and the OLINGO one for create? Is my interpretation correct?
> Seems to be not possible to POST a new entity via a navigation property to a collection
> ---------------------------------------------------------------------------------------
>
> Key: TEIID-5803
> URL: https://issues.jboss.org/browse/TEIID-5803
> Project: Teiid
> Issue Type: Bug
> Components: OData
> Reporter: Christoph John
> Assignee: Steven Hawkins
> Priority: Major
>
> Hello Steven,
> I am currently trying to post/create an entity in a collection via a relative binding path. Unfortunately, I always get an error saying
> {"error":{"code":null,"message":"HTTP method 'POST' not allowed for this resource."}}
> I have bound the root view to .../Account(1) from which I have a navigation property to the relevant collection. Currently I have trouble to post to collections via a navigation path.
> As far as I understood from
> http://docs.oasis-open.org/odata/odata/v4.01/csprd04/part1-protocol/odata...
> chapter 11.4.2 this should work according to my tries below.
> Might you tell me if my path via the navigation property should work for post requests or what I am doing wrong?
> Directly writing to the collection is fine, i.e. something like the following:
> curl --user sap:sap -i -X POST -H 'Content-Type: application/json;charset=UTF-8;IEEE754Compatible=true' -d '{"fkProfile":"1","idCode":null,"lc":"de","product_name":"A Product","brands":"A brand","energy_100g":2259,"carbohydrates_100g":60.08,"sugars_100g":10.1,"proteins_100g":24.03,"fat_100g":15.89,"saturated_fat_100g":10.0,"salt_100g":1.0}' http://localhost:18080/odata4/svc/my_nutri_diary/UserDefinedProducts
> and a GET request via a navigation property path (given below) also works, but a path via a navigation property does not work when using the path in a POST request. I.e. when going via the navigation property. Example:
> curl --user sap:sap -i -X POST -H 'Content-Type: application/json;charset=UTF-8;IEEE754Compatible=true' -d '{"fkProfile":"1","idCode":null,"lc":"de","product_name":"A Product","brands":"A brand","energy_100g":2259,"carbohydrates_100g":60.08,"sugars_100g":10.1,"proteins_100g":24.03,"fat_100g":15.89,"saturated_fat_100g":10.0,"salt_100g":1.0}' http://localhost:18080/odata4/svc/my_nutri_diary/Account\(1\)/UserDefined...
> Here you find the backend metadata. They show that UserDefinedProducts_fKUserDefinedProductToAccount is simply a navigaton path from Account(xxx) to the UserDefinedProducts collection.
> https://ecubed-solutions.ddnss.de/odata4/svc/my_nutri_diary/$metadata
> user: sap
> password: sap
> Thanks a lot for your help!
> Note: I am currently trying to add data via a navigation property path because my frontend library sapui5 only caches and syncs data queried via a single context binding. Hence, to be consistent via all views in my app which bind to the odata model, I need to use only one absolute binding and have to query/update other contexts via relative binding paths from this single absolute path, to allow for all frontend views to maintain data consistency
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 2 months
[JBoss JIRA] (TEIID-5803) Seems to be not possible to POST a new entity via a navigation property to a collection
by Christoph John (Jira)
[ https://issues.jboss.org/browse/TEIID-5803?page=com.atlassian.jira.plugin... ]
Christoph John commented on TEIID-5803:
---------------------------------------
Hello Steven,
>> This can addressed without adding general navigation binding support on create - that should be addressed in a separate issue.
I am not sure now what is addressed here and what shall be addressed in an additional issue.
You mean I should add an additional issue or is the additional issue what you references as:
https://jira.apache.org/jira/browse/OLINGO-1389
One further note on the discussion. I will also need to be able to address updates of an existing entity via a navigation binding. I have not tried yet if this does work. From your previous comments I assume you will interpret this issue here for updates on an item via navigation property and the OLINGO one for create? Is my interpretation correct?
> Seems to be not possible to POST a new entity via a navigation property to a collection
> ---------------------------------------------------------------------------------------
>
> Key: TEIID-5803
> URL: https://issues.jboss.org/browse/TEIID-5803
> Project: Teiid
> Issue Type: Bug
> Components: OData
> Reporter: Christoph John
> Assignee: Steven Hawkins
> Priority: Major
>
> Hello Steven,
> I am currently trying to post/create an entity in a collection via a relative binding path. Unfortunately, I always get an error saying
> {"error":{"code":null,"message":"HTTP method 'POST' not allowed for this resource."}}
> I have bound the root view to .../Account(1) from which I have a navigation property to the relevant collection. Currently I have trouble to post to collections via a navigation path.
> As far as I understood from
> http://docs.oasis-open.org/odata/odata/v4.01/csprd04/part1-protocol/odata...
> chapter 11.4.2 this should work according to my tries below.
> Might you tell me if my path via the navigation property should work for post requests or what I am doing wrong?
> Directly writing to the collection is fine, i.e. something like the following:
> curl --user sap:sap -i -X POST -H 'Content-Type: application/json;charset=UTF-8;IEEE754Compatible=true' -d '{"fkProfile":"1","idCode":null,"lc":"de","product_name":"A Product","brands":"A brand","energy_100g":2259,"carbohydrates_100g":60.08,"sugars_100g":10.1,"proteins_100g":24.03,"fat_100g":15.89,"saturated_fat_100g":10.0,"salt_100g":1.0}' http://localhost:18080/odata4/svc/my_nutri_diary/UserDefinedProducts
> and a GET request via a navigation property path (given below) also works, but a path via a navigation property does not work when using the path in a POST request. I.e. when going via the navigation property. Example:
> curl --user sap:sap -i -X POST -H 'Content-Type: application/json;charset=UTF-8;IEEE754Compatible=true' -d '{"fkProfile":"1","idCode":null,"lc":"de","product_name":"A Product","brands":"A brand","energy_100g":2259,"carbohydrates_100g":60.08,"sugars_100g":10.1,"proteins_100g":24.03,"fat_100g":15.89,"saturated_fat_100g":10.0,"salt_100g":1.0}' http://localhost:18080/odata4/svc/my_nutri_diary/Account\(1\)/UserDefined...
> Here you find the backend metadata. They show that UserDefinedProducts_fKUserDefinedProductToAccount is simply a navigaton path from Account(xxx) to the UserDefinedProducts collection.
> https://ecubed-solutions.ddnss.de/odata4/svc/my_nutri_diary/$metadata
> user: sap
> password: sap
> Thanks a lot for your help!
> Note: I am currently trying to add data via a navigation property path because my frontend library sapui5 only caches and syncs data queried via a single context binding. Hence, to be consistent via all views in my app which bind to the odata model, I need to use only one absolute binding and have to query/update other contexts via relative binding paths from this single absolute path, to allow for all frontend views to maintain data consistency
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 2 months
[JBoss JIRA] (TEIID-5810) .vdb can't be modified connection type via change-vdb-connection-type of cli by NPE
by Hiroki Daicho (Jira)
[ https://issues.jboss.org/browse/TEIID-5810?page=com.atlassian.jira.plugin... ]
Hiroki Daicho updated TEIID-5810:
---------------------------------
Description:
NullPointerException occurred when trying to change connection-type via cli.
It can be occurred with VDB (.vdb) has empty description for data role.
dynamic vdb would not be occur this issue.
{code}
[standalone@localhost:9999 /] /subsystem=teiid:change-vdb-connection-type(vdb-name=proc,vdb-version=1,connection-type=ANY)
{
"outcome" => "failed",
"failure-description" => "JBAS014749: Operation handler failed: java.lang.NullPointerException",
"rolled-back" => true
}
{code}
{code}
ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) JBAS014612: Operation ("change-vdb-connection-type") failed - address: ([("subsystem" => "teiid")]): java.lang.NullPointerException
at com.ctc.wstx.sw.BaseStreamWriter.writeCharacters(BaseStreamWriter.java:451)
at org.teiid.adminapi.impl.VDBMetadataParser.writeElement(VDBMetadataParser.java:654)
at org.teiid.adminapi.impl.VDBMetadataParser.writeDataPolicy(VDBMetadataParser.java:521)
at org.teiid.adminapi.impl.VDBMetadataParser.writeVDB(VDBMetadataParser.java:492)
at org.teiid.adminapi.impl.VDBMetadataParser.marshell(VDBMetadataParser.java:451)
at org.teiid.jboss.VDBService.save(VDBService.java:512)
at org.teiid.jboss.VDBService.access$300(VDBService.java:81)
at org.teiid.jboss.VDBService$2.connectionTypeChanged(VDBService.java:204)
at org.teiid.deployers.RuntimeVDB.changeConnectionType(RuntimeVDB.java:119)
at org.teiid.jboss.ChangeVDBConnectionType.executeOperation(TeiidOperationHandler.java:1261)
at org.teiid.jboss.ChangeVDBConnectionType.executeOperation(TeiidOperationHandler.java:1247)
at org.teiid.jboss.BaseOperationHandler$1.execute(BaseOperationHandler.java:79)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:710) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:545) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:338) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:314) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1152) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:335) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:204) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:209) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:158) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:154) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0_131]
at javax.security.auth.Subject.doAs(Subject.java:422) [rt.jar:1.8.0_131]
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:154) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:364) [jboss-as-protocol-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:473) [jboss-as-protocol-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
{code}
was:
NullPointerException occurred when connection-type is changed.
It can be occurred with VDB (.vdb) has empty description for data role.
dynamic vdb would not be occur this issue.
{code}
[standalone@localhost:9999 /] /subsystem=teiid:change-vdb-connection-type(vdb-name=proc,vdb-version=1,connection-type=ANY)
{
"outcome" => "failed",
"failure-description" => "JBAS014749: Operation handler failed: java.lang.NullPointerException",
"rolled-back" => true
}
{code}
{code}
ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) JBAS014612: Operation ("change-vdb-connection-type") failed - address: ([("subsystem" => "teiid")]): java.lang.NullPointerException
at com.ctc.wstx.sw.BaseStreamWriter.writeCharacters(BaseStreamWriter.java:451)
at org.teiid.adminapi.impl.VDBMetadataParser.writeElement(VDBMetadataParser.java:654)
at org.teiid.adminapi.impl.VDBMetadataParser.writeDataPolicy(VDBMetadataParser.java:521)
at org.teiid.adminapi.impl.VDBMetadataParser.writeVDB(VDBMetadataParser.java:492)
at org.teiid.adminapi.impl.VDBMetadataParser.marshell(VDBMetadataParser.java:451)
at org.teiid.jboss.VDBService.save(VDBService.java:512)
at org.teiid.jboss.VDBService.access$300(VDBService.java:81)
at org.teiid.jboss.VDBService$2.connectionTypeChanged(VDBService.java:204)
at org.teiid.deployers.RuntimeVDB.changeConnectionType(RuntimeVDB.java:119)
at org.teiid.jboss.ChangeVDBConnectionType.executeOperation(TeiidOperationHandler.java:1261)
at org.teiid.jboss.ChangeVDBConnectionType.executeOperation(TeiidOperationHandler.java:1247)
at org.teiid.jboss.BaseOperationHandler$1.execute(BaseOperationHandler.java:79)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:710) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:545) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:338) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:314) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1152) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:335) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:204) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:209) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:158) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:154) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0_131]
at javax.security.auth.Subject.doAs(Subject.java:422) [rt.jar:1.8.0_131]
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:154) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:364) [jboss-as-protocol-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:473) [jboss-as-protocol-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
{code}
> .vdb can't be modified connection type via change-vdb-connection-type of cli by NPE
> -----------------------------------------------------------------------------------
>
> Key: TEIID-5810
> URL: https://issues.jboss.org/browse/TEIID-5810
> Project: Teiid
> Issue Type: Bug
> Components: VDB
> Affects Versions: 8.12.18.6_4
> Environment: jdv 6.4.7
> Reporter: Hiroki Daicho
> Assignee: Barry LaFond
> Priority: Major
> Attachments: cli.log, proc.vdb, server.log
>
>
> NullPointerException occurred when trying to change connection-type via cli.
> It can be occurred with VDB (.vdb) has empty description for data role.
> dynamic vdb would not be occur this issue.
> {code}
> [standalone@localhost:9999 /] /subsystem=teiid:change-vdb-connection-type(vdb-name=proc,vdb-version=1,connection-type=ANY)
> {
> "outcome" => "failed",
> "failure-description" => "JBAS014749: Operation handler failed: java.lang.NullPointerException",
> "rolled-back" => true
> }
> {code}
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) JBAS014612: Operation ("change-vdb-connection-type") failed - address: ([("subsystem" => "teiid")]): java.lang.NullPointerException
> at com.ctc.wstx.sw.BaseStreamWriter.writeCharacters(BaseStreamWriter.java:451)
> at org.teiid.adminapi.impl.VDBMetadataParser.writeElement(VDBMetadataParser.java:654)
> at org.teiid.adminapi.impl.VDBMetadataParser.writeDataPolicy(VDBMetadataParser.java:521)
> at org.teiid.adminapi.impl.VDBMetadataParser.writeVDB(VDBMetadataParser.java:492)
> at org.teiid.adminapi.impl.VDBMetadataParser.marshell(VDBMetadataParser.java:451)
> at org.teiid.jboss.VDBService.save(VDBService.java:512)
> at org.teiid.jboss.VDBService.access$300(VDBService.java:81)
> at org.teiid.jboss.VDBService$2.connectionTypeChanged(VDBService.java:204)
> at org.teiid.deployers.RuntimeVDB.changeConnectionType(RuntimeVDB.java:119)
> at org.teiid.jboss.ChangeVDBConnectionType.executeOperation(TeiidOperationHandler.java:1261)
> at org.teiid.jboss.ChangeVDBConnectionType.executeOperation(TeiidOperationHandler.java:1247)
> at org.teiid.jboss.BaseOperationHandler$1.execute(BaseOperationHandler.java:79)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:710) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:545) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:338) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:314) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1152) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:335) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:204) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:209) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:158) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:154) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0_131]
> at javax.security.auth.Subject.doAs(Subject.java:422) [rt.jar:1.8.0_131]
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:154) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:364) [jboss-as-protocol-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:473) [jboss-as-protocol-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
> {code}
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 2 months
[JBoss JIRA] (TEIID-5810) .vdb can't be modified connection type via change-vdb-connection-type of cli by NPE
by Hiroki Daicho (Jira)
Hiroki Daicho created TEIID-5810:
------------------------------------
Summary: .vdb can't be modified connection type via change-vdb-connection-type of cli by NPE
Key: TEIID-5810
URL: https://issues.jboss.org/browse/TEIID-5810
Project: Teiid
Issue Type: Bug
Components: VDB
Affects Versions: 8.12.18.6_4
Environment: jdv 6.4.7
Reporter: Hiroki Daicho
Assignee: Barry LaFond
Attachments: cli.log, proc.vdb, server.log
NullPointerException occurred when connection-type is changed.
It can be occurred with VDB (.vdb) has empty description for data role.
dynamic vdb would not be occur this issue.
{code}
[standalone@localhost:9999 /] /subsystem=teiid:change-vdb-connection-type(vdb-name=proc,vdb-version=1,connection-type=ANY)
{
"outcome" => "failed",
"failure-description" => "JBAS014749: Operation handler failed: java.lang.NullPointerException",
"rolled-back" => true
}
{code}
{code}
ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) JBAS014612: Operation ("change-vdb-connection-type") failed - address: ([("subsystem" => "teiid")]): java.lang.NullPointerException
at com.ctc.wstx.sw.BaseStreamWriter.writeCharacters(BaseStreamWriter.java:451)
at org.teiid.adminapi.impl.VDBMetadataParser.writeElement(VDBMetadataParser.java:654)
at org.teiid.adminapi.impl.VDBMetadataParser.writeDataPolicy(VDBMetadataParser.java:521)
at org.teiid.adminapi.impl.VDBMetadataParser.writeVDB(VDBMetadataParser.java:492)
at org.teiid.adminapi.impl.VDBMetadataParser.marshell(VDBMetadataParser.java:451)
at org.teiid.jboss.VDBService.save(VDBService.java:512)
at org.teiid.jboss.VDBService.access$300(VDBService.java:81)
at org.teiid.jboss.VDBService$2.connectionTypeChanged(VDBService.java:204)
at org.teiid.deployers.RuntimeVDB.changeConnectionType(RuntimeVDB.java:119)
at org.teiid.jboss.ChangeVDBConnectionType.executeOperation(TeiidOperationHandler.java:1261)
at org.teiid.jboss.ChangeVDBConnectionType.executeOperation(TeiidOperationHandler.java:1247)
at org.teiid.jboss.BaseOperationHandler$1.execute(BaseOperationHandler.java:79)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:710) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:545) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:338) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:314) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1152) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:335) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:204) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:209) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:158) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:154) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0_131]
at javax.security.auth.Subject.doAs(Subject.java:422) [rt.jar:1.8.0_131]
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:154) [jboss-as-controller-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:364) [jboss-as-protocol-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:473) [jboss-as-protocol-7.5.18.Final-redhat-1.jar:7.5.18.Final-redhat-1]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
{code}
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 2 months