[JBoss JIRA] (TEIID-3834) Error during (re) adding connection factory using CLI
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3834?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated TEIID-3834:
-------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1309067
Bugzilla Update: Perform
> Error during (re) adding connection factory using CLI
> -----------------------------------------------------
>
> Key: TEIID-3834
> URL: https://issues.jboss.org/browse/TEIID-3834
> Project: Teiid
> Issue Type: Sub-task
> Components: Server
> Affects Versions: 8.13
> Reporter: Kylin Soong
> Assignee: Ramesh Reddy
> Fix For: 9.0
>
>
> enable datasource command
> {code}
> /subsystem=datasources/data-source=h2:enable
> {code}
> seems redundant, cause datasource add already enable it, so if execute setup.cli
> {code}
> ./bin/jboss-cli.sh --connect --file=setup.cli
> {code}
> will cause a eror
> {code}
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: org.jboss.msc.service.DuplicateServiceException: Service jboss.data-source-config.h2 is already registered",
> "rolled-back" => true
> }
> 14:35:55,436 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 9) WFLYCTL0013: Operation ("enable") failed - address: ([
> ("subsystem" => "datasources"),
> ("data-source" => "h2")
> ]): org.jboss.msc.service.DuplicateServiceException: Service jboss.data-source-config.h2 is already registered
> at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (TEIID-3922) Accumulo translator needs defined dependency to "org.jboss.teiid" module
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3922?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-3922:
------------------------------------------------
Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1301065|https://bugzilla.redhat.com/show_bug.cgi?id=1301065] from NEW to MODIFIED
> Accumulo translator needs defined dependency to "org.jboss.teiid" module
> ------------------------------------------------------------------------
>
> Key: TEIID-3922
> URL: https://issues.jboss.org/browse/TEIID-3922
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.12.3
> Reporter: Jan Stastny
> Assignee: Jan Stastny
> Fix For: 8.13, 8.12.5
>
>
> When using Accumulo translator to query an accumulo instance, following exception appears, when comparing on a column.
> {code}
> Caused by: java.lang.ClassNotFoundException: org.teiid.api.exception.query.ExpressionEvaluationException
> {code}
> Example query:
> {code:sql}
> SELECT * FROM MyTable WHERE MyColumn='string';
> {code}
> The reason is, that the mentioned class ExpressionEvaluationException is placed in module "org.jboss.teiid", but this module is not set as dependency in resulting "org.jboss.teiid.translator.accumulo" module.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (TEIID-3921) Accumulo translator doesn't end query execution when there are no tablet servers
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3921?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-3921:
------------------------------------------------
Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1300987|https://bugzilla.redhat.com/show_bug.cgi?id=1300987] from NEW to MODIFIED
> Accumulo translator doesn't end query execution when there are no tablet servers
> --------------------------------------------------------------------------------
>
> Key: TEIID-3921
> URL: https://issues.jboss.org/browse/TEIID-3921
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.12.3
> Reporter: Jan Stastny
> Assignee: Ramesh Reddy
> Fix For: 9.0, 8.12.5
>
>
> Teiid accumulo translator doesn't interrupt query execution when the accumulo instance is not running.
> There might be a situation that Zookeeper instance is running, but Accumulo is not.
> The translator, even though there is no tablet server entry in zookeeper, for given accumulo instance, executes the query. The query is running until query timeout exceeds. There is no indication of the fact, that accumulo tablet server is not present/responding except for
> {code}
> 09:25:46,539 WARN [org.apache.accumulo.core.client.impl.ServerClient] (Worker3_QueryProcessorQueue21) There are no tablet servers: check that zookeeper and accumulo are running.
> {code}
> There might be even situation, that Accumulo stopped in unusual way and didn't alter the tablet server information in Zookeeper, this way, there is a tablet server entry present in Zookeeper, but the tablet server is in fact not running. So Teiid should check the tablet server's address which received from Zookeeper.
> Interesting to note is the fact, that the same problem can be examined in accumulo's shell:
> {code}
> $ bin/accumulo shell -u root
> Password: ******
> 2016-01-22 10:02:05,604 [impl.ServerClient] WARN : There are no tablet servers: check that zookeeper and accumulo are running.
> {code}
> and then the shell hangs. Teiid needs to overcome this limitation.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (TEIID-3929) Accumulo does not return null values
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3929?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-3929:
------------------------------------------------
Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1301527|https://bugzilla.redhat.com/show_bug.cgi?id=1301527] from NEW to MODIFIED
> Accumulo does not return null values
> ------------------------------------
>
> Key: TEIID-3929
> URL: https://issues.jboss.org/browse/TEIID-3929
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.12.3
> Reporter: Jan Stastny
> Assignee: Ramesh Reddy
> Fix For: 9.0, 8.12.5
>
>
> Accumulo doesn't return null values when a whole 'column' is being selected.
> For a command in accumulo shell like:
> {code:plain}
> scan -c name:BYTENUM
> {code}
> Accumulo returns only non-empty values, this is expected behaviour.
> Equivalent query in Teiid would be:
> {code:sql}
> SELECT ByteNum FROM SmallA
> {code}
> Which returns the same results as Accumulo does. That means, no NULL values, if there are rowids without specified column families/qualifiers missing. But when a user has his schema defined in a vdb, he probably expects, that he will get as many rows as there are in the table.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (TEIID-3933) Accumulo translator: problem comparing number literals
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3933?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-3933:
------------------------------------------------
Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1301665|https://bugzilla.redhat.com/show_bug.cgi?id=1301665] from NEW to MODIFIED
> Accumulo translator: problem comparing number literals
> ------------------------------------------------------
>
> Key: TEIID-3933
> URL: https://issues.jboss.org/browse/TEIID-3933
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.12.3
> Reporter: Jan Stastny
> Assignee: Ramesh Reddy
> Fix For: 9.0, 8.12.5
>
>
> When accessing Accumulo instance using accumulo translator with table DDL defined in the model's metadata, there are problems filtering the output in from clause.
> For example, when there is a comparison between a column of type long with literal value 3, an exception, whose cause is below, is thrown on accumulo's side:
> {code:sql}
> SELECT * FROM accumulo.SmallA WHERE LongNum>3
> {code}
> {code:plain}
> Caused by: java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.Long
> at java.lang.Long.compareTo(Long.java:50)
> at org.teiid.query.sql.symbol.Constant$2.compare(Constant.java:99)
> at org.teiid.query.eval.Evaluator.compare(Evaluator.java:645)
> at org.teiid.query.eval.Evaluator.evaluate(Evaluator.java:373)
> at org.teiid.query.eval.Evaluator.internalEvaluateTVL(Evaluator.java:237)
> at org.teiid.query.eval.Evaluator.evaluateTVL(Evaluator.java:226)
> at org.teiid.query.eval.Evaluator.evaluate(Evaluator.java:220)
> at org.teiid.translator.accumulo.EvaluatorIterator.acceptRow(EvaluatorIterator.java:229)
> at org.teiid.translator.accumulo.EvaluatorIterator.filter(EvaluatorIterator.java:184)
> at org.teiid.translator.accumulo.EvaluatorIterator.prepKeys(EvaluatorIterator.java:180)
> at org.teiid.translator.accumulo.EvaluatorIterator.seek(EvaluatorIterator.java:159)
> at org.apache.accumulo.core.iterators.WrappingIterator.seek(WrappingIterator.java:101)
> at org.apache.accumulo.core.iterators.user.VersioningIterator.seek(VersioningIterator.java:81)
> at org.apache.accumulo.core.iterators.system.SourceSwitchingIterator.readNext(SourceSwitchingIterator.java:116)
> at org.apache.accumulo.core.iterators.system.SourceSwitchingIterator.seek(SourceSwitchingIterator.java:168)
> at org.apache.accumulo.server.tabletserver.Tablet.nextBatch(Tablet.java:1737)
> at org.apache.accumulo.server.tabletserver.Tablet.access$3200(Tablet.java:152)
> at org.apache.accumulo.server.tabletserver.Tablet$Scanner.read(Tablet.java:1879)
> at org.apache.accumulo.server.tabletserver.TabletServer$ThriftClientHandler$NextBatchTask.run(TabletServer.java:945)
> at org.apache.accumulo.trace.instrument.TraceRunnable.run(TraceRunnable.java:47)
> {code}
> but when I provide a value higher, than can be saved in integer, thus the type of the literal is inferred as long, the query runs as expected.
> {code:sql}
> SELECT * FROM accumulo.SmallA WHERE LongNum>30000000000000000000
> {code}
> Similar problems I had with
> ||Column type||Literal||Inferred type||Rootcause message||
> |long|3|Integer|java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.Long|
> |biginteger|3|Integer|java.lang.ClassCastException: java.lang.Integer cannot be cast to java.math.BigInteger|
> |double|3.0|BigDecimal|java.lang.ClassCastException: java.math.BigDecimal cannot be cast to java.lang.Double|
> |float|3.0|BigDecimal|java.lang.ClassCastException: java.math.BigDecimal cannot be cast to java.lang.Float|
> rest of the cause's stacktrace look the same.
> In Squirrel I get:
> {code:plain}
> TEIID30504 Remote org.teiid.core.TeiidProcessingException: TEIID30504 node-one: Error on server 127.0.0.1:9997
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (TEIID-3930) Accumulo translator: select rowid returns empty resultset
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3930?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-3930:
------------------------------------------------
Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1301540|https://bugzilla.redhat.com/show_bug.cgi?id=1301540] from NEW to MODIFIED
> Accumulo translator: select rowid returns empty resultset
> ---------------------------------------------------------
>
> Key: TEIID-3930
> URL: https://issues.jboss.org/browse/TEIID-3930
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.12.3
> Reporter: Jan Stastny
> Assignee: Ramesh Reddy
> Fix For: 9.0, 8.12.5
>
>
> Accumulo translator, according to its [documentation|https://docs.jboss.org/author/display/teiid812final/Apache+...], enables querying accumulo through teiid's vdb with table like:
> {code:xml}
> CREATE FOREIGN TABLE "User" (
> rowid string OPTIONS (UPDATABLE FALSE, SEARCHABLE 'All_Except_Like'),
> name_age string OPTIONS (SEARCHABLE 'All_Except_Like', "teiid_accumulo:CF" 'name', "teiid_accumulo:CQ" 'age', "teiid_accumulo:VALUE-IN" '{VALUE}'),
> name_firstname string OPTIONS (SEARCHABLE 'All_Except_Like', "teiid_accumulo:CF" 'name', "teiid_accumulo:CQ" 'firstname', "teiid_accumulo:VALUE-IN" '{VALUE}'),
> name_lastname string OPTIONS (SEARCHABLE 'All_Except_Like', "teiid_accumulo:CF" 'name', "teiid_accumulo:CQ" 'lastname', "teiid_accumulo:VALUE-IN" '{VALUE}'),
> CONSTRAINT PK0 PRIMARY KEY(rowid)
> ) OPTIONS (UPDATABLE TRUE);
> {code}
> The problem is, that querying for rowid column won't return any results:
> Query
> {code:sql}
> SELECT rowid FROM User;
> {code}
> does return empty resultset.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (TEIID-3944) Accumulo translator: rowid column is compared as string in WHERE clause
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3944?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-3944:
------------------------------------------------
Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1302977|https://bugzilla.redhat.com/show_bug.cgi?id=1302977] from NEW to MODIFIED
> Accumulo translator: rowid column is compared as string in WHERE clause
> -----------------------------------------------------------------------
>
> Key: TEIID-3944
> URL: https://issues.jboss.org/browse/TEIID-3944
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.12.3
> Reporter: Jan Stastny
> Assignee: Ramesh Reddy
> Fix For: 9.0, 8.12.5
>
>
> When in SOURCE model user specifies the required rowid column as integer:
> {code:xml}
> CREATE FOREIGN TABLE "SmallA" (
> rowid integer OPTIONS (UPDATABLE FALSE, SEARCHABLE 'All_Except_Like'),
> .
> .
> .
> {code}
> and performs similar query:
> {code:sql}
> Select rowid, StringKey From accumulo.SmallA WHERE rowid >= 15 ORDER BY rowid
> {code}
> following results are returned:
> || rowid | StringKey ||
> || 2 | 2 ||
> || 3 | 3 ||
> || 4 | 4 ||
> || 5 | 5 ||
> || 6 | 6 ||
> || 7 | 7 ||
> || 8 | 8 ||
> || 9 | 9 ||
> || 15 | 15 ||
> || ... | ... ||
> and given the fact, that rowid is modelled as integer, values 2,3,4,5,6,7,8,9 shouldn't appear in the result set. Interesting to note is that the resultset is then ordered by rowid, but this time correctly as expected.
> Other integer columns, mapped from accumulo's Column Family: Column Qualifier pairs works as expected and are being compared as corresponding types.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (TEIID-3684) RoleBasedCredentialMapIdentityLoginModule throws exception at startup time
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3684?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-3684:
------------------------------------------------
Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1260621|https://bugzilla.redhat.com/show_bug.cgi?id=1260621] from NEW to ASSIGNED
> 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, 10 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:
---------------------------------------
> My worry is web.xml is not the only thing that might require change. In the case of the oauth/saml there were certificates to be added, jboss-web.xml and additional keycloak configuration files etc. I do not like to set a different way to handle this simple case and then do the other way for rest of the usecases.
There are two concerns:
- whatever we do should still work "out of the box"
- modifications to the app, especially context params, should be simplistic
After looking into things more, it does look like https://docs.jboss.org/author/display/AS72/Deployment+Overlays would allow you to override even all of the needed pieces for oauth/saml in a single cli command.
> 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, 10 months
[JBoss JIRA] (TEIID-3684) RoleBasedCredentialMapIdentityLoginModule throws exception at startup time
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3684?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-3684:
------------------------------------------------
Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1260621|https://bugzilla.redhat.com/show_bug.cgi?id=1260621] from CLOSED to NEW
> 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, 10 months