[ 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. -- 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