[JBoss JIRA] (TEIID-3958) NPE Executing Against Web Service Source using invokeHttp() procedure without stream parameter
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3958?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-3958:
------------------------------------------------
Alex Szczuczko <aszczucz(a)redhat.com> changed the Status of [bug 1305902|https://bugzilla.redhat.com/show_bug.cgi?id=1305902] from MODIFIED to ON_QA
> NPE Executing Against Web Service Source using invokeHttp() procedure without stream parameter
> ----------------------------------------------------------------------------------------------
>
> Key: TEIID-3958
> URL: https://issues.jboss.org/browse/TEIID-3958
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.7.1, 8.7.1.6_2
> Environment: Migrated web services model from EDS 5.3.1 that does not include 'stream' parameter in the invokeHttp() procedure
> DV 6.1 - translator-ws-8.7.1.redhat-8.jar
> DV 6.2 - translator-ws-8.7.1.6_2-redhat-6.jar
> Reporter: Marc Shirley
> Assignee: Steven Hawkins
> Fix For: 9.0, 8.12.5, 8.7.3.6_2
>
> Attachments: testStream.vdb
>
>
> Appears to still be an issue similar to TEIID 2537. Executing against the invokeHttp() procedure generated by JBDS 5 for Teiid Designer 7.7.3 without a stream parameter results in a slightly different stack trace, but appears to be the same issue.
> 2016-01-21 12:53:50,297 ERROR \[org.teiid.PROCESSOR\] (Worker22_QueryProcessorQueue117472) TEIID30019 Unexpected exception for request FzkQneotrSUs.5: java.lang.NullPointerException
> at org.teiid.translator.ws.BinaryWSProcedureExecution.getOutputParameterValues(BinaryWSProcedureExecution.java:174)
> at org.teiid.dqp.internal.datamgr.ProcedureBatchHandler.getParameterRow(ProcedureBatchHandler.java:86) [teiid-engine-8.7.2.6_2-redhat-1.jar:8.7.2.6_2-redhat-1]
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.handleBatch(ConnectorWorkItem.java:435) [teiid-engine-8.7.2.6_2-redhat-1.jar:8.7.2.6_2-redhat-1]
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.more(ConnectorWorkItem.java:207) [teiid-engine-8.7.2.6_2-redhat-1.jar:8.7.2.6_2-redhat-1]
> at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:301) [teiid-engine-8.7.2.6_2-redhat-1.jar:8.7.2.6_2-redhat-1]
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:110) [teiid-engine-8.7.2.6_2-redhat-1.jar:8.7.2.6_2-redhat-1]
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:107) [teiid-engine-8.7.2.6_2-redhat-1.jar:8.7.2.6_2-redhat-1]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_65]
> at org.teiid.dqp.internal.process.FutureWork.run(FutureWork.java:58) [teiid-engine-8.7.2.6_2-redhat-1.jar:8.7.2.6_2-redhat-1]
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:274) [teiid-engine-8.7.2.6_2-redhat-1.jar:8.7.2.6_2-redhat-1]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119) [teiid-engine-8.7.2.6_2-redhat-1.jar:8.7.2.6_2-redhat-1]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210) [teiid-engine-8.7.2.6_2-redhat-1.jar:8.7.2.6_2-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_65]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_65]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_65]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (TEIID-3948) Provide a different mechanism to update odata wars
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3948?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3948:
---------------------------------------
> teaching one to do the CLI scripts
The cli scripts are already in charge of doing the war deployments and a modification to override the web.xml would be a copy/paste exercise (or just commented out in the cli script file).
> migration issues
Can you elaborate on that? Do you mean that it's better to have a self contained artifact?
> Have this separate from main line Teiid code (not sure much benefit, I also was thinking to move away from query.lang classes as we talked before)
We should separate that from this issue. Having a completely separate odata offering is appealing, but is a lot of work. As you say the simplest initial cut would be to incorporate Teiid embedded in the war.
> if we go this route, then we can bring all these together under single repo, possibly with no duplicates.
You mean if you rely on embedded and have a separate kitting option for EAP/AS. It still seems heavy weight for users to then do a git checkout, modification, and maven build to just update properties in the web.xml.
I'm fine if you want to produce the war from a separate project, but to just override the web.xml it seems like there is a perfectly valid eap mechanism to do that already. For all other containers/scenarios you'll need a separate build anyway as you'll need to incorporate embedded and not rely on modules.
> Provide a different mechanism to update odata wars
> --------------------------------------------------
>
> Key: TEIID-3948
> URL: https://issues.jboss.org/browse/TEIID-3948
> Project: Teiid
> Issue Type: Quality Risk
> Components: Server
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 9.0, 8.12.5
>
>
> Directly modifying the wars under the base modules is a bad practice. We need to have users modify non-kit artifact files in a different location.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (TEIID-3948) Provide a different mechanism to update odata wars
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-3948?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-3948:
-------------------------------------
The concern with that for me is two fold.
- teaching one to do the CLI scripts
- migration issues
I much rather have this self-contained, so that we do not need to handle above. The down side is, we will be maintaining the web.xml in two separate projects, which are copies. I am already doing that for different security profiles.
Ideally I want to move the whole "odata" project into separate repo and pull into kit during the kitting time. The desire is two fold again
- Have this separate from main line Teiid code (not sure much benefit, I also was thinking to move away from query.lang classes as we talked before)
- I want build WAR files based on the Teiid Embedded. This is so that it will be a drop in odata access to any data source.
if we go this route, then we can bring all these together under single repo, possibly with no duplicates.
> Provide a different mechanism to update odata wars
> --------------------------------------------------
>
> Key: TEIID-3948
> URL: https://issues.jboss.org/browse/TEIID-3948
> Project: Teiid
> Issue Type: Quality Risk
> Components: Server
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 9.0, 8.12.5
>
>
> Directly modifying the wars under the base modules is a bad practice. We need to have users modify non-kit artifact files in a different location.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (TEIID-3948) Provide a different mechanism to update odata wars
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3948?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3948:
---------------------------------------
If all we want is to be able to override the web.xml it looks like AS7-4296 provides a cli mechanism for that. So we would just document how to script the override and suggest where to put the new web.xml.
> Provide a different mechanism to update odata wars
> --------------------------------------------------
>
> Key: TEIID-3948
> URL: https://issues.jboss.org/browse/TEIID-3948
> Project: Teiid
> Issue Type: Quality Risk
> Components: Server
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 9.0, 8.12.5
>
>
> Directly modifying the wars under the base modules is a bad practice. We need to have users modify non-kit artifact files in a different location.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (TEIID-3948) Provide a different mechanism to update odata wars
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-3948?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-3948:
-------------------------------------
It will not work OOB. There are manual steps involved. One needs to remove the auto deployed war file from the server, then re-generate the WAR in this separate project with modified configuration and then redeploy it.
> Provide a different mechanism to update odata wars
> --------------------------------------------------
>
> Key: TEIID-3948
> URL: https://issues.jboss.org/browse/TEIID-3948
> Project: Teiid
> Issue Type: Quality Risk
> Components: Server
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 9.0, 8.12.5
>
>
> Directly modifying the wars under the base modules is a bad practice. We need to have users modify non-kit artifact files in a different location.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (TEIID-3948) Provide a different mechanism to update odata wars
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3948?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3948:
---------------------------------------
It's fine if you take it. I just want make sure of how it would work. If it's a separate project, would odata still work out of the box or would there be a manual step to first generate the war?
> Provide a different mechanism to update odata wars
> --------------------------------------------------
>
> Key: TEIID-3948
> URL: https://issues.jboss.org/browse/TEIID-3948
> Project: Teiid
> Issue Type: Quality Risk
> Components: Server
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 9.0, 8.12.5
>
>
> Directly modifying the wars under the base modules is a bad practice. We need to have users modify non-kit artifact files in a different location.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (TEIID-3684) RoleBasedCredentialMapIdentityLoginModule throws exception at startup time
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-3684?page=com.atlassian.jira.plugin... ]
Van Halbert commented on TEIID-3684:
------------------------------------
Deprecation for 6.3 sounds good.
> RoleBasedCredentialMapIdentityLoginModule throws exception at startup time
> --------------------------------------------------------------------------
>
> Key: TEIID-3684
> URL: https://issues.jboss.org/browse/TEIID-3684
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.7.1.6_2
> Reporter: Juraj Duráni
> Assignee: Ramesh Reddy
> Fix For: 9.0, 8.12.5
>
>
> If a data source is configured to use RoleBasedCredentialMapIdentityLoginModule, then exception is thrown at startup \[1\], because default username and password are null. Please, add module options "username" and "password" to set up default user (similar functionality have e.g. CallerIdentityLoginModule and PassthroughIdentityLoginModule), so DV is able to properly load data source at startup when no user is authenticated and therefore no mapping could be performed.
> Example configuration \[2\]. Note, there is no exception if UsersRoles login module is used instead of RealDirect. However, it means that EAP users are separate from DV users.
> *FYI:*
> - credentialMap module option should be defined as URL (file://...). It would be nice to have this information in the documentation.
> - I tried to use unauthenticatedIdentity module option for RealmDirect, but same exception has been thrown with different root cause (realm 'ApplicationRealm' not found). I do not know why.
> \[1\]
> ERROR [org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer] (MSC service thread 1-5) Exception during createSubject()PBOX000016: Access denied: authentication failed: java.lang.SecurityException: PBOX000016: Access denied: authentication failed
> at org.jboss.security.plugins.JBossSecuritySubjectFactory.createSubject(JBossSecuritySubjectFactory.java:84)
> at org.jboss.jca.deployers.common.AbstractDsDeployer$1.run(AbstractDsDeployer.java:1084)
> at org.jboss.jca.deployers.common.AbstractDsDeployer$1.run(AbstractDsDeployer.java:1079)
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0_40]
> at org.jboss.jca.deployers.common.AbstractDsDeployer.createSubject(AbstractDsDeployer.java:1078)
> at org.jboss.jca.deployers.common.AbstractDsDeployer.deployDataSource(AbstractDsDeployer.java:600)
> at org.jboss.jca.deployers.common.AbstractDsDeployer.createObjectsAndInjectValue(AbstractDsDeployer.java:282)
> at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer.deploy(AbstractDataSourceService.java:316)
> at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService.start(AbstractDataSourceService.java:120)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913)
> 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]
> \[2\]
> {code:xml}
> <security-domain name="my-sec">
> <authentication>
> <login-module code="RealmDirect" flag="required">
> <module-option name="password-stacking" value="tryFirstPass"/>
> <!--<module-option name="unauthenticatedIdentity" value="guest"/>-->
> </login-module>
> <login-module code="org.teiid.jboss.RoleBasedCredentialMapIdentityLoginModule" module="org.jboss.teiid" flag="required">
> <module-option name="password-stacking" value="useFirstPass"/>
> <module-option name="credentialMap" value="file://${jboss.server.config.dir}/teiid-credentialmap.properties"/>
> </login-module>
> </authentication>
> </security-domain>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (TEIID-3684) RoleBasedCredentialMapIdentityLoginModule throws exception at startup time
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3684?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3684:
---------------------------------------
Sounds like it needs to be deprecated for 6.3 and removed in Teiid 9.
> RoleBasedCredentialMapIdentityLoginModule throws exception at startup time
> --------------------------------------------------------------------------
>
> Key: TEIID-3684
> URL: https://issues.jboss.org/browse/TEIID-3684
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.7.1.6_2
> Reporter: Juraj Duráni
> Assignee: Ramesh Reddy
> Fix For: 9.0, 8.12.5
>
>
> If a data source is configured to use RoleBasedCredentialMapIdentityLoginModule, then exception is thrown at startup \[1\], because default username and password are null. Please, add module options "username" and "password" to set up default user (similar functionality have e.g. CallerIdentityLoginModule and PassthroughIdentityLoginModule), so DV is able to properly load data source at startup when no user is authenticated and therefore no mapping could be performed.
> Example configuration \[2\]. Note, there is no exception if UsersRoles login module is used instead of RealDirect. However, it means that EAP users are separate from DV users.
> *FYI:*
> - credentialMap module option should be defined as URL (file://...). It would be nice to have this information in the documentation.
> - I tried to use unauthenticatedIdentity module option for RealmDirect, but same exception has been thrown with different root cause (realm 'ApplicationRealm' not found). I do not know why.
> \[1\]
> ERROR [org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer] (MSC service thread 1-5) Exception during createSubject()PBOX000016: Access denied: authentication failed: java.lang.SecurityException: PBOX000016: Access denied: authentication failed
> at org.jboss.security.plugins.JBossSecuritySubjectFactory.createSubject(JBossSecuritySubjectFactory.java:84)
> at org.jboss.jca.deployers.common.AbstractDsDeployer$1.run(AbstractDsDeployer.java:1084)
> at org.jboss.jca.deployers.common.AbstractDsDeployer$1.run(AbstractDsDeployer.java:1079)
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0_40]
> at org.jboss.jca.deployers.common.AbstractDsDeployer.createSubject(AbstractDsDeployer.java:1078)
> at org.jboss.jca.deployers.common.AbstractDsDeployer.deployDataSource(AbstractDsDeployer.java:600)
> at org.jboss.jca.deployers.common.AbstractDsDeployer.createObjectsAndInjectValue(AbstractDsDeployer.java:282)
> at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer.deploy(AbstractDataSourceService.java:316)
> at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService.start(AbstractDataSourceService.java:120)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913)
> 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]
> \[2\]
> {code:xml}
> <security-domain name="my-sec">
> <authentication>
> <login-module code="RealmDirect" flag="required">
> <module-option name="password-stacking" value="tryFirstPass"/>
> <!--<module-option name="unauthenticatedIdentity" value="guest"/>-->
> </login-module>
> <login-module code="org.teiid.jboss.RoleBasedCredentialMapIdentityLoginModule" module="org.jboss.teiid" flag="required">
> <module-option name="password-stacking" value="useFirstPass"/>
> <module-option name="credentialMap" value="file://${jboss.server.config.dir}/teiid-credentialmap.properties"/>
> </login-module>
> </authentication>
> </security-domain>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months