Bug 1315397

couple of questions:

1. which version of EAP is this happening on ? (the root exception is something related to ISPN and the DV installer does not install EAP anymore)

2. are there any other exception in the server log ? For example: if the new Teiid-Modeshape sequencers don't work correctly, then ModeShape.vdb cannot be sequenced meaning that some exceptions are to be expected when querying ModeShape through Teiid....

Attached is the server log, which doesn't show any other exceptions prior to trying to import.   However, there is another teiid sequencer issue [1] which may have direct impact.


[1]   https://bugzilla.redhat.com/show_bug.cgi?id=1315401

(In reply to Van Halbert from comment #4)
> Attached is the server log, which doesn't show any other exceptions prior to
> trying to import.   However, there is another teiid sequencer issue [1]
> which may have direct impact.
> 
> 
> [1]   https://bugzilla.redhat.com/show_bug.cgi?id=1315401

@vhalbert: the bug is caused by a lack of CP visibility in EAP (i.e. among modules), which requires both Teiid and ModeShape changes:

1. the "org.modeshape.jdbc" module (which is what Teiid uses when issuing queries locally against ModeShape) has to export modeshape.main's dependencies to the outside world (in this particular case the fact that the ISPN CP is not exported causes this issue)

2. the "org.jboss.teiid.translator.jdbc" module (where the query originates from) has to list "org.modeshape.jdbc" as a dependency so that ModeShape's CP can be accessible.

Once I commit the fix for (1) I'll reassign this to you so (2) can be resolved as well.

Committed the change for (1) to jboss-integration/modeshape (should be part of ER2)

Reassigning as per the above comment.

>2. the "org.jboss.teiid.translator.jdbc" module (where the query originates from) has to list "org.modeshape.jdbc" as a dependency so that ModeShape's CP can be accessible.

This has not been fixed in ER2. Teiid needs to make this change.

Note that testing with ER2, after manually fixing the module dependency from above, querying the VDB after installing DV with the same master-password for everything, will not work because Teiid passes ModeShape some invalid credentials:

- the username it passes is "modeshapeUser" (which is fine according to the installer)
- the password though is ":modeshape::modeshape.password::1" which isn't valid in this particular case.

The same problem (invalid credentials) occurs when installing DV with separate passwords for ModeShape and Teiid: the Teiid JDBC translator always passes down to ModeShape the ":modeshape::modeshape.password::1" password to session.login() which isn't valid.

The full stack looks like this:

1008:TEIID11004 Error executing statement(s): [SQL: SELECT g_0."jcr:name", g_0."jcr:path" FROM "nt:base" AS g_0 WHERE g_0."jcr:path" = '/queryNode' ORDER BY g_0."jcr:path"]
       at org.teiid.translator.jdbc.JDBCQueryExecution.execute(JDBCQueryExecution.java:131) [translator-jdbc-8.12.5.redhat-3.jar:8.12.5.redhat-3]
       at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.execute(ConnectorWorkItem.java:359)
       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_66]
       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_66]
       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_66]
       at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_66]
       at org.teiid.dqp.internal.datamgr.ConnectorManager$1.invoke(ConnectorManager.java:211)
       at com.sun.proxy.$Proxy137.execute(Unknown Source)
       at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:306)
       at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:112)
       at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:108)
       at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_66]
       at org.teiid.dqp.internal.process.FutureWork.run(FutureWork.java:65)
       at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:276)
       at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119)
       at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210)
       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66]
       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66]
       at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]
aused by: java.sql.SQLException: Unable to create session for workspace default in repository dv: authentication or authorization failed. Check credentials.
       at org.modeshape.jdbc.JcrStatement.execute(JcrStatement.java:433)
       at org.modeshape.jdbc.JcrStatement.executeQuery(JcrStatement.java:479)
       at org.jboss.jca.adapters.jdbc.WrappedStatement.executeQuery(WrappedStatement.java:344)
       at org.teiid.translator.jdbc.JDBCQueryExecution.execute(JDBCQueryExecution.java:119) [translator-jdbc-8.12.5.redhat-3.jar:8.12.5.redhat-3]
       ... 18 more
aused by: javax.jcr.LoginException: Unable to create session for workspace default in repository dv: authentication or authorization failed. Check credentials.
       at org.modeshape.jcr.JcrRepository.login(JcrRepository.java:688)
       at org.modeshape.jcr.JcrRepository.login(JcrRepository.java:620)
       at org.modeshape.jcr.JcrRepository.login(JcrRepository.java:156)
       at org.modeshape.jdbc.delegate.LocalSession.getLocalSession(LocalSession.java:74)
       at org.modeshape.jdbc.delegate.LocalRepositoryDelegate.getLocalSession(LocalRepositoryDelegate.java:91)
       at org.modeshape.jdbc.delegate.LocalRepositoryDelegate.execute(LocalRepositoryDelegate.java:139)
       at org.modeshape.jdbc.JcrStatement.execute(JcrStatement.java:429)
       ... 21 more

@Van: this probably requires some investigation into the Teiid translator as to what/how the password is passed down to ModeShape.

Steven Hawkins <shawkins> updated the status of jira TEIID-4148 to Resolved

@Van: if you read my previous 2 comments, the fix for https://issues.jboss.org/browse/TEIID-4148 is not enough to solve this issue: Teiid still passes down to ModeShape some weird password in the form of credentials to the session.login method.

good point; then is this an installer issue or something else ?

The current script passes in the following value: --password="${VAULT::modeshape::modeshape.password::1}" which after the 

installation process is translated to 

<security>
  <user-name>modeshapeUser</user-name>
  <password>:modeshape::modeshape.password::1</password>
</security>

regardless of the way in which the installer was run.

This is obviously wrong...

(In reply to Van Halbert from comment #13)
> it should be:  ${VAULT::modeshape::modeshape.password::1}

that's what the current script does (see my previous comment)

Hi,

The bit of code executing the scripts was set to resolve variables. I've set the variable resolution flag to false when executing the ModeShape-domain/standalone.cli scritps to stop this behavior.

Thanks,

Emmett Underhill

Steven Hawkins <shawkins> updated the status of jira TEIID-4148 to Closed