Van Halbert wrote:
regarding:
>> startConnectorBinding
>> stopConnectorBinding
>>
Are the operations expected to stop/start both the Connector JCA and
the Datasource JCA? I would suggest we only do the Connector JCA,
because stop/start the Datasource would be stepping over into
boundaries of the app server management. Also, and because the
datasource connections are now being used by all parties in the
appserver, I think the appropriate place to trigger the stop/start of
a Datasource connection is using the appserver administration for the
datasources, not thru Teiid admin.
Won't the data source connections be specific to Teiid since the Teiid
semantics (capabilities, metadata) won't be applicable to non-Teiid
apps? Also, regardless of the underlying operation used to
control/stop/start, it would be useful for the API to provide a
wrapper. The user still may be able to control through generic
container mechanisms, but the Teiid administrator should have a
consistent API into all the moving parts of a Teiid system even if they
are "standard" and accessible through other means. They should not have
to context switch (and tool switch) when administering different system
components. I suggest this applies to the admin API as well as admin
console.
On Nov 3, 2009, at 8:30 AM, Ramesh Reddy wrote:
> Van,
>
> Since lot of work is still pending let's not finalize the list of the
> methods to keep just yet. In next couple weeks this will become more
> clear. We know few of the methods that are definitely being removed
> like
> extensions, process, log, configuration etc. I think you are right
> about
> the transactions method, this is one from to keep pile.
>
> Per discussion on the previous thread to keep the identity of the
> Connectors in Teiid, we still need to keep the Connector binding
> specific calls.
>
>
>> setConnectorBindingProperty
>> addConnectorBinding
>> deleteConnectorBinding
>> exportConnectorBinding
>> getConnectorBindings
>> startConnectorBinding
>> stopConnectorBinding
>>
>>
> I would suggest you start with these to start mapping them to the
> profile service. Note
> that supporting the previous file formats is not necessary, they
> should be same as the container's.
>
> Additionally Teiid also needs a method like
>
> "getConnectorPropertyDefinitions" which will describe the properties
> defined inside the "ra.xml" file,
> to be used with tools like designer to define their UI.
>
> Next we will tackle monitoring, then on to VDB specific methods.
>
> Ramesh..
>
>
> _______________________________________________
> teiid-dev mailing list
> teiid-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/teiid-dev
>
Van Halbert
Principal Software Eng.
Red Hat, Inc.
------
vhalbert(a)redhat.com
_______________________________________________
teiid-dev mailing list
teiid-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-dev
--
Ken Johnson
Sr. Product Manager
JBoss Middleware Business Unit
Red Hat, Inc
978.392.3917
ken.johnson(a)redhat.com