9:52 a.m.
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
10:58 a.m.
On Thu, 2010-02-04 at 10:52 -0500, John Doyle wrote:
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)?
Yes. Configuration Manager is going away completely with JCA changes.
The concept of connector type still exists, but Designer will *not*
maintain a copy of the properties that are needed for creating any
particular connector binding. This information is stored in ra.xml file
inside the connector's rar deployment file.
You can ask Teiid admin to give you properties needed to create a
certain connector, based on that you can drive a UI and create Connector
Binding (aka Connection Factory in Container terms) using the Teiid
admin api.
Ramesh..
11:24 a.m.
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. 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 to
you.
Thanks,
JPAV
11:28 a.m.
----- "John Verhaeg" <jverhaeg(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-designer-dev
5453
days inactive
5453
days old
teiid-designer-dev@lists.jboss.org
3 comments
3 participants
participants (3)
-
John Doyle -
John Verhaeg -
Ramesh Reddy