On Tue, 2010-04-13 at 16:44 -0400, Steven Hawkins wrote:
It doesn't seem like we have yet reached a consensus, but it does
1. people do like having a SQL oriented interactive command line tool.
2. most see the SQL functionality as separable from the admin/test.
I'd also like to relay a local discussion with Ramesh. His
premise was that if we decouple the admin/test aspects and promote an
alternative command line SQL tool, then we should just forgo offering
any built-in environment for administrative scripting. In this case
the approach would be to just document which class/classes could be
imported (as shown in the previous Groovy example with the static
import of AdminShell methods) into your java scripting language of
Not sure about this. Although I agree that we want to make the Admin
API easier to maintain, the entire reason for exposing it was so that
non-development users could use it. Originally this was to be
accomplished via a SQL extension (provided by the Admin VDB). A user
wants to find out what the state of a connector is or what the state of
a VDB is by simply executing a query. The concept of the Admin Shell
provided this. A user needs the ability to write simple commands (no
need for reading an API or JavaDoc) to accomplish simple tasks regarding
--- pseudo ---
Connect To MMServerA
Get Status of Connector ConnectorA
Get Status of Connector ConnectorB
If Either ConnectorA or ConnectorB Status is Unavailable, Exit With
Error Code 2
Exit With No Error Code
--- pseudo ---
So, even though we may have falling short in this within Admin Shell,
the concept was still there and an Admin Shell script could be easily
integrated with a user shell script (bash, cmd, etc). By utilizing the
Admin API, it also allowed this type of scripting to be done remotely
allowing for a single script/instance to monitor or perform operations
on many server instances.
I am not so sure it is an issue of the "shell" being present as it is
that a simple set of functions be provided that wrap the more complex
operations offered through the API.
Although, now that we will be living in the container, I am sure that we
can expose these simple functions/operations through other methods. For
example, in the MBean world, I can invoke operations using Twiddle. So,
if these common administrative and monitoring tasks can be exposed via a
remote operation, then maybe the container could provide the missing
----- Original Message -----
From: "Ramesh Reddy" <rareddy(a)redhat.com>
To: "John Doyle" <jdoyle(a)redhat.com>
Cc: "Steven Hawkins" <shawkins(a)redhat.com>, "teiid-users"
<teiid-dev(a)lists.jboss.org>, "Paul Nittel" <pnittel(a)redhat.com>
Sent: Tuesday, April 13, 2010 9:41:49 AM GMT -06:00 US/Canada Central
Subject: Re: [teiid-users] [teiid-dev] Alternative scripting envrionment for AdminShell
On Tue, 2010-04-13 at 09:27 -0400, John Doyle wrote:
> You nailed my concern Steve. I've never actually used AdminShell for
> admin tasks, I use it like
> SQL*PLUS. I think there are probably more reasons to separate these
> concerns than to combine them. I haven't looked at either of the two
> tools you linked to, but if we can validate that one of them works
> well enough then I think that should be sufficient for a query tool
> for Teiid.
> I think the added verbosity of the groovy solution is more acceptable
> for an admin tool than for a query tool, and is worth it given the
> added capabilities that multiple connections offer.
Please take integration test and write using this tool, and you will see
the reasons for this added verbosity.
teiid-users mailing list
Middleware Support Engineering Group
Global Support Services
Red Hat, Inc.
1.866.LINUX70 (+1.314.336.2990) xt 81-62909
Looking to carve out IT costs?