[ https://issues.jboss.org/browse/TEIID-2062?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-2062: --------------------------------------- My initial approach is to refactor the FakeServer into a class usable from the runtime module. We would keep several simplifications from the FakeServer, such as a single shared ConnectorManagerRepository (rather than VDB scoping), limited configurablity, and no socket transports by default. For now I am leaving out a default system vdb, although that would be easy to add. VDB deployment is target at dynamic scenarios, see EmbeddedServer.deployVDB, and ExectionFactories are expected to be manually added via EmbeddedServer.addTranslator Enhancements include: -a named connection factory lookup override (EmbeddedServer.addConnectionFactoryProvider) rather than just relying on the default JNDI strategy. -switching the engine thread pool to a WorkManager based implementation, which allows for context propagation without setting a SecurityHelper. Issues include: -Some functionality may be needed from jboss integration. Replication requires setting an ObjectReplicator, which is too complicated to expect alternative implementations. Also resultset caching key distribution could be done using infinispan, rather than replication. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-2062?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-2062: --------------------------------------- To answer each: - There's no need to limit to 1. Unless we simplify surrounding APIs to not have name/version, there's no real benefit to doing that. - That's just a simplification of the deployment method and there's no expectation that designer will be used. Designer vdbs could be added if needed we would just have to add more complete handling for the notion of a vdb.xml (currently there is no need) and call to the index loading logic. - Yes, we are using the calling thread by default, but we are still allowing for parallelization in non-transactional and XMLTable scenarios. And yes if userRequestSourceConcurrency is set to one, when we could set the engine thread pool to just a direct executor. - Yes, it's generally helpful to have that for our unit testing as well. - Yes, there's no reason why an app cluster couldn't share their cache entries, replicate events, etc. However like I say unless we pull out jgroups/infinispan related service code from jboss integration I don't expect that this would actually be used. The EmbeddedServer currently allows for setting an ObjectReplicator at the very least so that the replication integration test can still run. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-2062?page=com.atlassian.jira.plugin... ] Ramesh Reddy edited comment on TEIID-2062 at 8/2/12 4:43 PM: ------------------------------------------------------------- Adding way to submit query in object form using the internal Teiid language objects. This lets user to skip the whole JDBC layer and directly submit the query to the engine and also skips the parsing of the SQL from string form. {code} public ExecutionResults executeQuery(final String vdbName, final int version, final QueryCommand command, final long timoutInMilli) throws TeiidException; {code} on EmbeddedServer class was (Author: rareddy): Adding way to submit query in object form using the internal Teiid language objects. This lets user to skip the whole JDBC layer and directly submit the query to the engine and also skips the parsing of the SQL from string form. {code} public ExecutionResults executeQuery(final String vdbName, final int version, final QueryCommand command, final long timoutInMilli) throws TeiidException; {code} on EmbeddedServer class -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-2062?page=com.atlassian.jira.plugin... ] Steven Hawkins closed TEIID-2062. --------------------------------- -- 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