August 2019 - teiid-issues - Jboss List Archives

[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)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-114) Validate vdb-import

by Ramesh Reddy (Jira)

[ https://issues.jboss.org/browse/TEIIDSB-114?page=com.atlassian.jira.plugi... ] Ramesh Reddy reassigned TEIIDSB-114: ------------------------------------ Assignee: Ramesh Reddy > 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 > Assignee: Ramesh Reddy > Priority: Major > 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)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-108) Add support for swagger/openapi sources

by Ramesh Reddy (Jira)

[ https://issues.jboss.org/browse/TEIIDSB-108?page=com.atlassian.jira.plugi... ] Ramesh Reddy reassigned TEIIDSB-108: ------------------------------------ Assignee: Ramesh Reddy > Add support for swagger/openapi sources > --------------------------------------- > > Key: TEIIDSB-108 > URL: https://issues.jboss.org/browse/TEIIDSB-108 > Project: Teiid Spring Boot > Issue Type: Feature Request > Components: datasource > Reporter: Steven Hawkins > Assignee: Ramesh Reddy > Priority: Major > Fix For: 1.2.0 > > > There should be source support for swagger/openapi. If we don't want swagger 1 support, then this can just add support for the openapi translator. -- This message was sent by Atlassian Jira (v7.13.5#713005)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-108) Add support for swagger/openapi sources

by Ramesh Reddy (Jira)

[ https://issues.jboss.org/browse/TEIIDSB-108?page=com.atlassian.jira.plugi... ] Ramesh Reddy updated TEIIDSB-108: --------------------------------- Fix Version/s: 1.2.0 (was: 1.3.0) > Add support for swagger/openapi sources > --------------------------------------- > > Key: TEIIDSB-108 > URL: https://issues.jboss.org/browse/TEIIDSB-108 > Project: Teiid Spring Boot > Issue Type: Feature Request > Components: datasource > Reporter: Steven Hawkins > Priority: Major > Fix For: 1.2.0 > > > There should be source support for swagger/openapi. If we don't want swagger 1 support, then this can just add support for the openapi translator. -- This message was sent by Atlassian Jira (v7.13.5#713005)

4 years, 9 months

1
0
0 / 0

[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)

4 years, 9 months

1
0
0 / 0

[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)

4 years, 9 months

1
0
0 / 0

[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)

4 years, 9 months

1
0
0 / 0

[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)

4 years, 9 months

1
0
0 / 0

[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)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5803) Seems to be not possible to POST a new entity via a navigation property to a collection

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5803?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-5803: --------------------------------------- > I assume the second option will not work for me, as I do not have an appropriate primary key at hand which I could send with a POST to create a new child element. Is my assumption right? Just ignore what I was saying. This can addressed without adding general navigation binding support on create - that should be addressed in a separate issue. [~rhn-engineering-rareddy] see https://jira.apache.org/jira/browse/OLINGO-1389 - that will allow posts like theses to proceed. > 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)

4 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues August 2019