5:31 p.m.
Using Ramesh's list of which methods to keep/throw away for the 6.3
release, I only found 1 change that I thought was needed. That was
the "getTransactions" was in the throw away list. This is because,
if the "terminateTransaction" method is to remain, doesn't it need a
corresponding method to return the transactions in order to know/find
which transaction to terminate?
Other than that, nothing else.
Also, I started commenting on why the throwaway list of methods will
be gone to help explain/insight to the changes that are occurring.
//*******************
// methods to keep
//******************
configuration:
addVDB
changeVDBStatus
deleteVDB
exportVDB
getVDBs (from a vdb, the models can be obtained, and from a model,
the connector(s) can be found)
assignBindingToModel
importDataRoles
exportDataRoles
addUDF
deleteUDF
monitoring:
getQueueWorkerPools
getCaches
getSessions
getRequests (also enable monitor long running queries)
getSourceRequests
getTransactions
clearCache
terminateSession
cancelRequest
cancelSourceRequest
terminateTransaction
Others:
authenticateUser
//*****************
// Can these me removed?
//*********************
getRolesForGroup
getGroupsForUser
getGroups
assignRoleToGroup
removeRoleFromGroup
getDomainNames
getGroupsForDomain
//*******************
// Can be removed
//*********************
1. the connector type information will be defined in the ra.xml for
its respective connector rar file.
addConnectorType
deleteConnectorType
exportConnectorType
getConnectorTypes
getConnectorTypePropertyDefinitions
addConnectorArchive
exportConnectorArchive
2. JCA connectors will now be managed by the app server
setConnectorBindingProperty
addConnectorBinding
addConnectorBinding
deleteConnectorBinding
exportConnectorBinding
getConnectorBindings
getConnectorBindingsInVDB
startConnectorBinding
stopConnectorBinding
getConnectionPoolStats
3. Extension modules will now be deployed as part of the connector
rar file.
addExtensionModule
deleteExtensionModule
exportExtensionModule
getExtensionModules
extensionModuleModified
4. There is no longer be a configuration file, as in the past.
exportConfiguration
5. Process management is no longer part of Teiid
setProcessProperty
getProcesses
6. Start / Stop /Restart of Teiid engine is managed by the app
servers' management of JCA
shutdown
restart
7. Change in logging infrastrucure
getLogConfiguration
setLogConfiguration
setLogListener
Van Halbert
Principal Software Eng.
Red Hat, Inc.
------
vhalbert(a)redhat.com
8:30 a.m.
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..
9:05 a.m.
The mapping to the profile service is outside of Teiid. I hope your
not suggesting that adminapi have a dependency on the profile service.
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
9:44 a.m.
On Tue, 2009-11-03 at 09:05 -0600, Van Halbert wrote:
The mapping to the profile service is outside of Teiid. I hope your
not suggesting that adminapi have a dependency on the profile service.
No, not at all. The implementation of the Admin API will be different
for different containers. Teiid will provide JBoss container support at
a minimum.
11 a.m.
What behavior are thinking is different based on api
implementation? If its to use a different communication protocol,
that's one thing, but what teiid behavior is to be different?
On Nov 3, 2009, at 9:44 AM, Ramesh Reddy wrote:
On Tue, 2009-11-03 at 09:05 -0600, Van Halbert wrote:
> The mapping to the profile service is outside of Teiid. I hope your
> not suggesting that adminapi have a dependency on the profile
> service.
No, not at all. The implementation of the Admin API will be different
for different containers. Teiid will provide JBoss container support
at
a minimum.
_______________________________________________
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
1:08 p.m.
On Tue, 2009-11-03 at 11:00 -0600, Van Halbert wrote:
What behavior are thinking is different based on api
implementation? If its to use a different communication protocol,
that's one thing, but what teiid behavior is to be different
The management API between different containers will be different. So,
the way you manage to create/start/stop a connector in JBoss is
different from that of Glassfish. In JBoss you can control these through
profile service, in Glassfish this is entirely different. So, we need to
write these methods in isolation where they can used in pluagable
fashion.
As per the Teiid specific methods like vdb management and monitoring
etc, *should* be same across all the environments. To do that, we need
to manage these resources in a container independent way. For this we
may depend upon MC, but not JBoss container to use JBoss frameworks
where there is support for interfaces like @ManagedObject or @JMX or use
our own like we are doing now.
Ramesh..
10:50 a.m.
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.
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
11:05 a.m.
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
11:12 a.m.
Won't the data source connections be specific to Teiid ?
The datasources will be created like any other datasource and managed
by the app server and available to all those in the appserver who wish
to use them.
On Nov 3, 2009, at 11:05 AM, Ken Johnson wrote:
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
Van Halbert
Principal Software Eng.
Red Hat, Inc.
------
vhalbert(a)redhat.com
1:32 p.m.
On Tue, 2009-11-03 at 12:05 -0500, Ken Johnson wrote:
Won't the data source connections be specific to Teiid since the
Teiid
semantics (capabilities, metadata) won't be applicable to non-Teiid
apps?
For the JDBC Connectors, the data source and connector parts are defined
in separate JCA entities. One would be Teiid specific and another is
generic to the container. Teiid connector internally looks up and uses
the JCA data source as its physical connection to the source.
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.
This is where the your argument about Teiid based identity comes into
picture. Yes, I am looking into providing those hooks. This may span
into new API methods as I was eluding to in the previous email. I will
post what they may be in coming days.
7:32 p.m.
Here is the list of the Admin methods currently made it in so far with
the container integration.
Look at this class for the current methods:
http://anonsvn.jboss.org/repos/teiid/branches/JCA/client/src/main/java/or...
If you notice couple of the methods, I simplified signature from before,
for example:
getSesions(String identifier) --> getSessions();
Where "identifier" was little verbose, in majority of usage pattern it
always being used as
getSessions("*");
So, I just removed it and made it simple on part of the user.
The below methods are to be removed from previous Admin API. I see there
is no good way to provide "export" kind of functionality with
container's management API, so you see all export functions in this
list. The others are no longer viable concepts in a container world.
addConnectorArchive
getLogConfiguration
setLogConfiguration
setLogListener
addExtensionModule
deleteExtensionModule
exportExtensionModule
exportConfiguration
exportConnectorBinding
exportConnectorType
exportConnectorArchive
extensionModuleModified
getExtensionModules
getRolesForGroup
getGroupsForUser
getGroups
assignRoleToGroup
removeRoleFromGroup
getDomainNames
getGroupsForDomain
exportVDB
exportDataRoles
getSourceRequests
cancelSourceRequest
assignBindingToModel
assignBindingsToModel
changeVDBStatus
importDataRoles
If you think some of the functionality is must have please let's
discuss.
Thanks
Ramesh..
12:54 p.m.
On Tue, 2009-11-03 at 10:50 -0600, 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.
Yes, you are correct. Note that data source are currently only used by
the Relational sources. Other sources only consist of just
jca-connector.
For datasource support, I was also thinking, what if we provide few
methods like
addDataSource(name, properties)
deleteDataSource(name)
startDatasource(name);
stopDataSource(name);
That will complete the full functionality as before.
Ramesh..
5459
days inactive
5528
days old
11 comments
3 participants
participants (3)
-
Ken Johnson -
Ramesh Reddy -
Van Halbert