Admin API Methods
by Van Halbert
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
13 years, 11 months
ra.xml specific
by Sanjay Chaudhuri
Hi Ramesh,
Would need some details on the use-cases for ra.xml in order to complete
that. Here is a list; please confirm or make any changes:
1. <config-property> is defined as: *description**, *config-property-name*,
*config-property-type*, *config-property-value?*
Will the ra.xml editor show a 4 column table only with the *config-properties
*? This would mean that we DO NOT show the whole xml in a nested tree.
2. Capability to add/delete description, property-name, property-type,
property-value which would update ra.xml on the fly.
3. Do we need to validate schema restrictions ?
4. Which properties class the get/set to be added ? Is the properties class
generated if it's not in the workspace ?
5. How to use the optional <config-property-value> attribute in the
properties class ?
Thanks
Sanjay
13 years, 11 months
Re: [teiid-dev] 7.0 release progress
by Steven Hawkins
There's no problem with moving the date. We're already off of our time-box, but that's ok for a major release. Since we're off by weeks instead of months and will be releasing milestones, there doesn't seem like there's a need for 6.3.
----- Original Message -----
From: "Ramesh Reddy" <rareddy(a)redhat.com>
To: "Steven Hawkins" <shawkins(a)redhat.com>
Cc: "John Doyle" <jdoyle(a)redhat.com>, "teiid-dev" <teiid-dev(a)lists.jboss.org>
Sent: Thursday, December 10, 2009 10:35:55 AM GMT -06:00 US/Canada Central
Subject: Re: [teiid-dev] 7.0 release progress
Based on the amount changes coming from container integration and level
of effort still needed to make Teiid work I am not sure about reaching
the goal to release 7.0 on Jan 8th, towards the end of January may be
more attainable goal. This adds 3 more weeks to release cycle.
If we want to time box the release I am open to do the v6.3 release from
trunk on Jan 8th, and target a quick later date for v7.0 with container
integration. This may be better option.
IMO, this will also let the tooling catch up to the container changes
and let more testing on the part of Teiid.
Ramesh..
On Thu, 2009-12-10 at 11:11 -0500, Steven Hawkins wrote:
> I would guess we'll need at least two more. MS3 should bring in the container changes and we'll need another one after that to tie everything together and be our RC1.
>
> ----- Original Message -----
> From: "John Doyle" <jdoyle(a)redhat.com>
> To: "Steven Hawkins" <shawkins(a)redhat.com>
> Cc: "teiid-dev" <teiid-dev(a)lists.jboss.org>
> Sent: Thursday, December 10, 2009 10:09:07 AM GMT -06:00 US/Canada Central
> Subject: Re: [teiid-dev] 7.0 release progress
>
> Hi Steve,
>
> Is this the last planned MS?
>
> ~jd
> ----- "Steven Hawkins" <shawkins(a)redhat.com> wrote:
>
> > Hello all,
> >
> > We're making good strides toward the 7.0 release. However the 7.0
> > release still has far too many JIRA issues targeted to it. If you
> > have something that should be resolved or retargeted, please do so.
> >
> > We should also be thinking about a next milestone that is coordinated
> > with an initial Designer milestone. Hopefully that can be as soon as
> > next week.
> >
> > Thanks,
> > Steve
> > _______________________________________________
> > teiid-dev mailing list
> > teiid-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/teiid-dev
> _______________________________________________
> teiid-dev mailing list
> teiid-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-dev
13 years, 12 months
7.0 release progress
by Steven Hawkins
Hello all,
We're making good strides toward the 7.0 release. However the 7.0 release still has far too many JIRA issues targeted to it. If you have something that should be resolved or retargeted, please do so.
We should also be thinking about a next milestone that is coordinated with an initial Designer milestone. Hopefully that can be as soon as next week.
Thanks,
Steve
13 years, 12 months
Re: [teiid-dev] Re-working VDBService in JCA branch
by Steven Hawkins
Just to make sure, the real service methods are getAvailableVDBs, getVDB, and possibly changeVDBStatus which can move to ConfigurationService. All the other methods are moving to VDBMetadata. I would be in favor of the threadlocal/session approach. VDBArchive/VDBMetadata objects should be heavily shared, so there is only an incremental memory cost. And as long as we are cleaning up our context appropriately there's no danger of a leak.
----- Original Message -----
From: "Ramesh Reddy" <rareddy(a)redhat.com>
To: teiid-dev(a)lists.jboss.org
Sent: Thursday, December 3, 2009 11:52:11 AM GMT -06:00 US/Canada Central
Subject: [teiid-dev] Re-working VDBService in JCA branch
Steve,
I am trying to see feasibility of getting rid of the VDB Service,
metadata service and make the logged in user's VDBMetaData available in
all the places that VDBService was used in JCA branch so that it is
inline with other services in JCA branch. For its access I could use
- static access (yuck..)
- bean injection (like parameter passing, like now)
- JNDI lookup
- ThreadLocal (in the DQPWorkContext)
where VDBMetadata will give you all the info needed on the VDB user
logged in. I am leaning toward ThreadLocal, as it is non-intrusive on
the APIs, not sure if increases any memory requirements.
What do you think?
Thanks
Ramesh..
_______________________________________________
teiid-dev mailing list
teiid-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-dev
14 years
Cdk Plugin - Export Feature added
by Sanjay Chaudhuri
Hi Ramesh,
I have uploaded the changes to take care of the functionality.
What's New:
- Connector can be exported as RAR to any directory. Application remembers
the exported directory
- Projects with errors are not exported; users are notified using an error
dialog.
- Cdk nature has been added which will give a custom icon to any Cdk
Connector projects.
- Temporary files are deleted.
- Runtime errors had been notified using dialog box,
Let me know if you would like to me change something or you come across any
bug.
Thanks
Sanjay
14 years
Re-working VDBService in JCA branch
by Ramesh Reddy
Steve,
I am trying to see feasibility of getting rid of the VDB Service,
metadata service and make the logged in user's VDBMetaData available in
all the places that VDBService was used in JCA branch so that it is
inline with other services in JCA branch. For its access I could use
- static access (yuck..)
- bean injection (like parameter passing, like now)
- JNDI lookup
- ThreadLocal (in the DQPWorkContext)
where VDBMetadata will give you all the info needed on the VDB user
logged in. I am leaning toward ThreadLocal, as it is non-intrusive on
the APIs, not sure if increases any memory requirements.
What do you think?
Thanks
Ramesh..
14 years
