March 2009 - teiid-issues - Jboss List Archives

[JBoss JIRA] Commented: (TEIID-397) Console Error after changing Root Admin password

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-397?page=com.atlassian.jira.plug... ] Steven Hawkins commented on TEIID-397: -------------------------------------- This is not specific to CCE, moving to Teiid. This is a general problem with the console attempting too many retries based upon cached credentials. It will happen anytime reauthentication is forced and the same console session is used. We should break out of the retry loop when an authentication error happens. > Console Error after changing Root Admin password > ------------------------------------------------ > > Key: TEIID-397 > URL: https://jira.jboss.org/jira/browse/TEIID-397 > Project: Teiid > Issue Type: Bug > Components: Console > Affects Versions: 6.0.0 > Environment: Windows client running against Windows Server > Reporter: Warren Gibson > Fix For: 6.1.0 > > > 1. Went into Security/Summary and changed MetaMatrixAdmin password. > 2. Bounced the server. > 3. Console hung for about 10 minutes and finally returned with the below Error message. > 4. Console was unstable. > 5. Shut down Console and Restarted and everything seemed to be fine with the new password. > com.metamatrix.console.util.ExternalException[0]: com.metamatrix.api.exception.ComponentCommunicationException[0]: com.metamatrix.common.comm.exception.ConnectionException[0]: com.metamatrix.api.exception.security.LogonException[0]: [MetaMatrixAuthenticationException]The username "metamatrixadmin" and/or password and/or payload token could not be authenticated by any membership domain. > at com.metamatrix.platform.security.session.service.SessionServiceImpl.authenticateUser(SessionServiceImpl.java:431) > at com.metamatrix.platform.security.session.service.SessionServiceImpl.createSession(SessionServiceImpl.java:624) > at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at com.metamatrix.platform.service.proxy.SingleInvokationProxy.invoke(SingleInvokationProxy.java:48) > at $Proxy7.createSession(Unknown Source) > at com.metamatrix.platform.security.session.service.LogonHelper.logon(LogonHelper.java:69) > at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at com.metamatrix.platform.service.proxy.ProxyManager$WrappedDelegator.invoke(ProxyManager.java:41) > at $Proxy8.logon(Unknown Source) > at com.metamatrix.common.comm.platform.socket.SocketLogon.logon(SocketLogon.java:133) > at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at com.metamatrix.core.proxy.ServiceInvocation.invokeOn(ServiceInvocation.java:91) > at com.metamatrix.core.proxy.DefaultTerminalServiceInterceptor.invoke(DefaultTerminalServiceInterceptor.java:29) > at com.metamatrix.core.proxy.ServiceInvocation.invokeNext(ServiceInvocation.java:87) > at com.metamatrix.common.comm.platform.server.MessageServiceAgent.receiveLocal(MessageServiceAgent.java:90) > at com.metamatrix.common.comm.platform.server.MessageServiceAgent.receive(MessageServiceAgent.java:114) > at com.metamatrix.common.comm.platform.server.MessageFilterServiceAgent.receive(MessageFilterServiceAgent.java:99) > at com.metamatrix.platform.admin.apiimpl.RuntimeStateListenerAgent.receive(RuntimeStateListenerAgent.java:103) > at com.metamatrix.common.comm.platform.socket.SocketVMController.receive(SocketVMController.java:388) > at com.metamatrix.common.comm.platform.socket.server.ServerSynchronousWorkItem.process(ServerSynchronousWorkItem.java:36) > at com.metamatrix.common.comm.platform.socket.server.SocketServerWorker.process(SocketServerWorker.java:35) > at com.metamatrix.common.queue.QueueWorker.run(QueueWorker.java:64) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 9 months

1
0
0 / 0

[JBoss JIRA] Commented: (TEIID-315) Add JDBC Connector developers guide

by Ramesh Reddy (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-315?page=com.atlassian.jira.plug... ] Ramesh Reddy commented on TEIID-315: ------------------------------------ I added the old document in the doc book format; I removed the sections that are specific to designer and console, where it was talking about creating a JDBC source model or deploying the connector type. > Add JDBC Connector developers guide > ----------------------------------- > > Key: TEIID-315 > URL: https://jira.jboss.org/jira/browse/TEIID-315 > Project: Teiid > Issue Type: Sub-task > Components: Documentation > Affects Versions: 6.0.0 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 6.0.0 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (TEIID-388) When determining kestore algorithm, the logic wasn't considering the setting "ssl.KeyManagerFactory.algorithm" for defining an algorithm to use

by Van Halbert (JIRA)

When determining kestore algorithm, the logic wasn't considering the setting "ssl.KeyManagerFactory.algorithm" for defining an algorithm to use ------------------------------------------------------------------------------------------------------------------------------------------------ Key: TEIID-388 URL: https://jira.jboss.org/jira/browse/TEIID-388 Project: Teiid Issue Type: Bug Components: Common Affects Versions: 6.1.0 Reporter: Van Halbert Assignee: Van Halbert This is a rolled forward change from 5.5.4. The problem was discovered when running on an IBM Z900 machine using the IBM jdk. It uses the Security property "ssl.KeyManagerFactory.algorithm" to specify the algorithm to use, and our logic doesn't include an alternative when the metamatrix algorithm property is not defined, it always defaulted to "SunX509". Therefore, the change is to check the Security property as an override to the default, but the metamatrix property will be the override to all. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 9 months

2
4
0 / 0

[JBoss JIRA] Closed: (TEIID-161) Move common type conversion logic into a centralized facility for connectors

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-161?page=com.atlassian.jira.plug... ] Steven Hawkins closed TEIID-161. -------------------------------- Will update the docs as part of the connector doc issue. > Move common type conversion logic into a centralized facility for connectors > ---------------------------------------------------------------------------- > > Key: TEIID-161 > URL: https://jira.jboss.org/jira/browse/TEIID-161 > Project: Teiid > Issue Type: Sub-task > Components: Connector API, Query Engine > Affects Versions: 6.0.0 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 6.0.0 > > > Since we allow the flexibility for physical model types to not actually match source type (as in not simply the closest runtime type), every connector is currently responsible for not only converting to a known runtime type but potentially converting to the desired runtime type. This logic has been encapsulated behind the typefacility converttoruntimetype and transformvalue. It would be nice however to automatically handle the known conversions. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 9 months

1
0
0 / 0

[JBoss JIRA] Closed: (TEIID-148) Enhancement to allow runtime checking of null values

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-148?page=com.atlassian.jira.plug... ] Steven Hawkins closed TEIID-148. -------------------------------- Fix affected the QueryRewriter and ProcedurePlan primarily. > Enhancement to allow runtime checking of null values > ---------------------------------------------------- > > Key: TEIID-148 > URL: https://jira.jboss.org/jira/browse/TEIID-148 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Affects Versions: 6.0.0 > Environment: All server environments. > Reporter: Jerry Helbling > Assignee: Jerry Helbling > Priority: Minor > Fix For: 6.0.0 > > > Refer to internal case 6395. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 9 months

1
0
0 / 0

[JBoss JIRA] Closed: (TEIID-2) Fix for NPE in isSuperUser method.

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-2?page=com.atlassian.jira.plugin... ] Steven Hawkins closed TEIID-2. ------------------------------ > Fix for NPE in isSuperUser method. > ---------------------------------- > > Key: TEIID-2 > URL: https://jira.jboss.org/jira/browse/TEIID-2 > Project: Teiid > Issue Type: Bug > Components: Server > Affects Versions: 6.0.0 > Reporter: Jerry Helbling > Assignee: Jerry Helbling > Priority: Minor > Fix For: 6.0.0 > > > Refer to internal case 226138. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 9 months

1
0
0 / 0

[JBoss JIRA] Commented: (TEIID-143) Query should 'find' connector types and jars rather than have them predefined in the config.

by Larry O'Leary (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-143?page=com.atlassian.jira.plug... ] Larry O'Leary commented on TEIID-143: ------------------------------------- I wouldn't say that connectors and VDBs are like apples and oranges. After all, VDBs require a connector and connectors are packaged as part of a VDB. I would agree that removal of the DB would be for another JIRA but my point is that synchronization isn't really an issue. If you use a file system for deployment of extension modules then you would simplify the requirements across tools. The only "extra" implementation effort would be a synchronization service for deployment into a server for clustering. The synchronization service simply pulls the files from the file system and puts them in the DB so that other server instances can pull the extension modules into their local file system. The idea is that I would be able to drop a complete self-contained CAF into a directory and make connector types available to the tool or server. I could also drop a CAF and a JAR into a directory and make the connector type available to the tool or server. Now, I think to make the process better we should introduce version information into a connector type and the connector JARs. This is where i think OSGI would give us a lot of power. By introducing version information into these components, you make it possible for the tools to determine the best action for importing the new components. If for example, I deploy a connector JAR (or one within a CAF) that is version 1.0.1 and version 1.0.0 is already deployed, we will know that this is an update. If on the other hand the CAF (or a signle connector JAR) is deployed with version 0.0.9 the tool could give a warning that a newer version already exists and ask the user for replacement confirmation (or if this is the admin API the method could support a update/force parameter). Now, this still will not address version conflicts with all resources as a third-party driver JAR won't have to conform to the version requirement and therefore won't allow us much in the line of smart replacement. I realize that you are looking at patches being hot-deployed but in many instances customers deploy new connectors to the server and will not expect to bounce it. I think this functionality is important. > Query should 'find' connector types and jars rather than have them predefined in the config. > -------------------------------------------------------------------------------------------- > > Key: TEIID-143 > URL: https://jira.jboss.org/jira/browse/TEIID-143 > Project: Teiid > Issue Type: Feature Request > Components: Misc. Connectors > Affects Versions: 6.0.0 > Reporter: John Doyle > Fix For: 6.1.0 > > Original Estimate: 1 week > Remaining Estimate: 1 week > > Currently, dqp as delived with Designer is preconfigured with connector types. I think it should discover the connectors that are available upon startup. This would make it easier to add connectors to a kit. The current process for adding a connector to a kit is manual and error prone. We have problems with it on nearly every release. > This is also an attractive feature for embedding query in other environments. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 9 months

1
0
0 / 0

[JBoss JIRA] Commented: (TEIID-143) Query should 'find' connector types and jars rather than have them predefined in the config.

by Ramesh Reddy (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-143?page=com.atlassian.jira.plug... ] Ramesh Reddy commented on TEIID-143: ------------------------------------ Greg: it is not question of restart of the server; but it is a question of distribution of patch jar; if we use Console or Admin Api, we are now tied to keeping them in sync across cluster (if they are not extension modules). I was trying to see if there was a way around it. In fact, we can possibly provide original modules as libraries and only provide patches as extensions, and that would work in hot-deploy situations. Larry: Although I agree, VDBs and Connectors are like apples and oranges. We never patch a VDB, we re-deploy it. VDB's do not have external dependencies that may conflict, we do not have version concept in the connectors. etc. Your comment about about the DB is for another JIRA, I am strictly worried about packaging and its delivery and updatebility across tools. OSGI and third party jar that is interesting, I do not know. Need to investigate. > Query should 'find' connector types and jars rather than have them predefined in the config. > -------------------------------------------------------------------------------------------- > > Key: TEIID-143 > URL: https://jira.jboss.org/jira/browse/TEIID-143 > Project: Teiid > Issue Type: Feature Request > Components: Misc. Connectors > Affects Versions: 6.0.0 > Reporter: John Doyle > Fix For: 6.1.0 > > Original Estimate: 1 week > Remaining Estimate: 1 week > > Currently, dqp as delived with Designer is preconfigured with connector types. I think it should discover the connectors that are available upon startup. This would make it easier to add connectors to a kit. The current process for adding a connector to a kit is manual and error prone. We have problems with it on nearly every release. > This is also an attractive feature for embedding query in other environments. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 9 months

1
0
0 / 0

[JBoss JIRA] Resolved: (TEIID-2) Fix for NPE in isSuperUser method.

by Jerry Helbling (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-2?page=com.atlassian.jira.plugin... ] Jerry Helbling resolved TEIID-2. -------------------------------- Resolution: Done This problem has already been corrected in teiid. No further action required. (See AuthorizationAdminAPIImpl.isSuperUser( name )) > Fix for NPE in isSuperUser method. > ---------------------------------- > > Key: TEIID-2 > URL: https://jira.jboss.org/jira/browse/TEIID-2 > Project: Teiid > Issue Type: Bug > Components: Server > Affects Versions: 6.0.0 > Reporter: Jerry Helbling > Assignee: Jerry Helbling > Priority: Minor > Fix For: 6.0.0 > > > Refer to internal case 226138. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

1
0
0 / 0

[JBoss JIRA] Commented: (TEIID-143) Query should 'find' connector types and jars rather than have them predefined in the config.

by Larry O'Leary (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-143?page=com.atlassian.jira.plug... ] Larry O'Leary commented on TEIID-143: ------------------------------------- Unfortunately I can not speak for all customers but I do know the customers that I have worked with over the years find it a must to hot-deploy connectors. The connector classes and driver classes, or for that matter any connector configuration changes, should be picked up by the connector service when the connector is initialized or created. Even the ability to apply a connector patch is something that is done outside of normal server maintenance in many cases. I really do not see it as an issue to make connector components available system-wide. A connector should be treated much like a VDB. Now, I suppose you can say the same thing about a VDB but it would not make sense to complicate the deployment and configuration of the system by making it a requirement that a VDB and/or Connector must be deployed to each server instance separately unless the mechanism we use gives the option to deploy server wide. I agree that OSGI for our connector packages is ideal but it still will not address the issue of getting these third-party drivers into the class loader. We still we have the obstacle of third-party drivers being external to the OSGI bundle and can't expect our users to create an OSGI bundle that contains the third-party drivers just so they can make the driver available to our OSGI bundled connector. I am not too familiar with JBoss and its clustering capabilities but I always liked the way WebLogic worked. I deploy my J2EE application to a single instance and the other nodes in the cluster would magically inherit the new application. This is much like we do it now but as we use a DB as our lib repository it may appear to complicate things. Fortunately I do not see the DB repository as a complicated piece. I have always thought that we should get rid of it as it is not really needed but if we want to keep it so that we do not have to move the entire synchronization logic into the server then lets at least make a step in the right direction. Why not just use a push/pull scheme for connector, VDB, and extension module artefacts? Basically, I place a file in a special directory of ServerA and ServerA pushes this file to the DB if it does not already exist or updates it if it does exist and needs updating. ServerB will pick up the change immediately because it receives a configuration change event and pulls the file from the DB to its special directory. So, each server will have the same copy of the file in its file system. This prepares you for the possibility that the DB will go away at some point as each server knows how to manage its local instances of resources. The special directory mentioned above is set via a configuration option/property. This way the code that looks for the files can be re-used in the embedded component as well as Designer. > Query should 'find' connector types and jars rather than have them predefined in the config. > -------------------------------------------------------------------------------------------- > > Key: TEIID-143 > URL: https://jira.jboss.org/jira/browse/TEIID-143 > Project: Teiid > Issue Type: Feature Request > Components: Misc. Connectors > Affects Versions: 6.0.0 > Reporter: John Doyle > Fix For: 6.1.0 > > Original Estimate: 1 week > Remaining Estimate: 1 week > > Currently, dqp as delived with Designer is preconfigured with connector types. I think it should discover the connectors that are available upon startup. This would make it easier to add connectors to a kit. The current process for adding a connector to a kit is manual and error prone. We have problems with it on nearly every release. > This is also an attractive feature for embedding query in other environments. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues March 2009