[teiid-designer-dev] Removing dependencies on DQP from Salesforce and Web Service importer.

John Doyle jdoyle at redhat.com
Thu Feb 4 12:28:30 EST 2010


----- "John Verhaeg" <jverhaeg at redhat.com> wrote:

> On Feb 4, 2010, at 9:52 AM, John Doyle wrote:
> 
> > Hey Dan,
> > 
> > We were discussing changing the dependency of the SalesForce and
> WSDL to Relational importers from
> com.metamatrix.modeler.dqp.config.ConfigurationManager to the
> JDBCImportPostProcessor.  When I looked into that class last night I
> found that it's not going to work for me without substantial change
> because its very JDBC specific.  My importers don't set the same
> binding properties as the JDBC importer, and don't have to edit
> classpaths and such.  It seems to me that the ConfigurationManager is
> really the right abstraction for what I need.  It allows me to find
> the right connector type and set any values I want on it.  Each of my
> importers has different values to set in the bindings.  Is there some
> reason that we can't leave ConfigurationManager as the public API
> (assuming that it might change in this release because of the JCA
> changes)?
> 
> 
> John, for now you may want to just comment out all the code that
> touches the dqp-related stuff until we get a chance to go in and fix
> that code to work with the new admin api changes for 7.0.  Ultimately,
> you're probably going to have to mimic what the JDBC importer does,
> which is use the Eclipse extension mechanism to load a class
> reflectively that deals with connection bindings, thus eliminating a
> hard dependency.  

I'm good with this until things settle down to a more stable state.

For the JDBC importer, that class is the
> JDBCImportPostProcessor.  That class, whatever you call it, would give
> you the "right abstraction" and would need to be provided in a
> separate plug-in that is part of our newly proposed "Designer runtime"
> feature (i don't know what we're going to call it yet).  The reason I
> mention just commenting the code out for now is because I doubt if
> this class will still be called "ConfigurationManager" after all the
> changes, and even the "dqp" plug-ins may end up changing names.  But
> what to address now vs. later is obviously up t!
>  o you.
> 
> 
> Thanks,
> 
> JPAV
> 
> 
> 
> 
> _______________________________________________
> teiid-designer-dev mailing list
> teiid-designer-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-designer-dev


More information about the teiid-designer-dev mailing list