Teiid host resolution change after the M3
by Ramesh Reddy
Teiid uses host name resolution to figure out the bind address where it
can open a socket to listen for the incoming JDBC and Admin connections.
The host name resolution in Teiid has changed. See
https://jira.jboss.org/jira/browse/TEIID-1047
Previously, if user did not specify any bind address, Teiid by default
used to resolve "localhost" to WAN or LAN address and tried to
explicitly avoid the loopback (127.0.0.1) address.
The new host resolution logic does not impose any preferences, it
defaults to JDK class "InetAddress" behavior. This mimics the JBoss AS
behavior.
In most cases on individual's desktops/development stations this will
resolve to 127.0.0.1. However, if the JBoss AS is started with "-b
<host-name or ip>, then Teiid will also pick up this host name or IP
and bind to that address.
So, if you are installing Teiid on a different machine than the local,
then please start it will correct bind address/host name, such that your
remote JDBC client can connect to the server. Otherwise you will see
"connection refused" exceptions upon connect.
Let us know, if you have any questions.
Thanks.
Ramesh..
14 years
[ANN]VTD-XML 2.8
by Jimmy Zhang
VTD-XML 2.8 has been released. Please visit https://sourceforge.net/projects/vtd-xml/files/ to download the latest version.
a.. Expansion of Core VTD-XML API
a.. VTDGen adds support for capturing white spaces
b.. VTDNav adds support for suport for getContentFragment(), recoverNode() and cloneNav()
c.. XMLModifier adds support for update and reparse feature
d.. AutoPilot adds support for retrieving all attributes
e.. BookMark is also enhanced.
b.. Expansion of Extended VTD-XML API
a.. Add content extraction ability to extended VTD-XML
b.. VTDNavHuge now can call getElementFragment() and getElementFragmentNs()
c.. VTDGenHuge adds support for capturing white spaces
c.. XPath
a.. Adds comment and processing instruction support for nodes, and performance enhancement
b.. Adds namespace axis support .
c.. Adds round-half-to-even()
d.. A number of bug fixes and code enhancement
14 years
Re: [teiid-users] [teiid-dev] Alternative scripting environment for AdminShell
by Steven Hawkins
https://jira.jboss.org/jira/browse/TEIID-1052 is the issue to track the approach below. The initial changes have been checked-in, so new shell and console executables and docs are available with a fresh build.
Yes, SQuirreL can display our query plan it just takes a Teiid specific SQuirrel plugin.
----- Original Message -----
From: "Ken Johnson" <kejohnso(a)redhat.com>
To: "Steven Hawkins" <shawkins(a)redhat.com>
Cc: rareddy(a)redhat.com, "teiid-users" <teiid-users(a)lists.jboss.org>, "teiid-dev" <teiid-dev(a)lists.jboss.org>
Sent: Thursday, April 15, 2010 1:10:08 PM GMT -06:00 US/Canada Central
Subject: Re: [teiid-users] [teiid-dev] Alternative scripting environment for AdminShell
Steven Hawkins wrote:
> So one possible approach is:
>
> - provide a Groovy based AdminShell for admin scripting, but document how the classes can be used in you JVM scripting language of choice. It can retain our contextual admin logic, and while SQL execution via Groovy (not through parser interception) would be possible in these scripts, it would not be a primary function of the tool.
> - promote the use of SQuirreL/Execute Query/etc. for graphical and Henplus/SQLShell/etc. for a command line SQL tool
>
I agree with this approach. BTW, is there a way for SQuirreL to display
a Teiid query plan?
> ----- Original Message -----
> From: "Ken Johnson" <kejohnso(a)redhat.com>
> To: "Steven Hawkins" <shawkins(a)redhat.com>
> Cc: rareddy(a)redhat.com, "teiid-users" <teiid-users(a)lists.jboss.org>, "teiid-dev" <teiid-dev(a)lists.jboss.org>
> Sent: Tuesday, April 13, 2010 4:15:41 PM GMT -06:00 US/Canada Central
> Subject: Re: [teiid-users] [teiid-dev] Alternative scripting envrionment for AdminShell
>
> Steven Hawkins wrote:
>
>> It doesn't seem like we have yet reached a consensus, but it does seem like:
>> 1. people do like having a SQL oriented interactive command line tool.
>> 2. most see the SQL functionality as separable from the admin/test.
>>
>> Agreed?
>>
>> I'd also like to relay a local discussion with Ramesh. His basic 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 choice.
>>
>>
> I think this falls short on "out-of-the-box" experience. I like the
> idea of a Groovy-based shell for Admin and a separate utility for ad-hoc
> SQL without the user being required to configure their environment. Of
> course, it would be nice if we *also* provided the option to
> import/extend your java scripting environment of choice.
>
>
>> ----- 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-users(a)lists.jboss.org>, "teiid-dev" <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.
>>
>> Ramesh..
>>
>> _______________________________________________
>> teiid-users mailing list
>> teiid-users(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/teiid-users
>>
>>
>
>
>
--
Ken Johnson
Sr. Product Manager
JBoss Middleware Business Unit
Red Hat, Inc
978.392.3917
ken.johnson(a)redhat.com
14 years
Re: [teiid-users] [teiid-dev] Alternative scripting environment for AdminShell
by Steven Hawkins
So one possible approach is:
- provide a Groovy based AdminShell for admin scripting, but document how the classes can be used in you JVM scripting language of choice. It can retain our contextual admin logic, and while SQL execution via Groovy (not through parser interception) would be possible in these scripts, it would not be a primary function of the tool.
- promote the use of SQuirreL/Execute Query/etc. for graphical and Henplus/SQLShell/etc. for a command line SQL tool
----- Original Message -----
From: "Ken Johnson" <kejohnso(a)redhat.com>
To: "Steven Hawkins" <shawkins(a)redhat.com>
Cc: rareddy(a)redhat.com, "teiid-users" <teiid-users(a)lists.jboss.org>, "teiid-dev" <teiid-dev(a)lists.jboss.org>
Sent: Tuesday, April 13, 2010 4:15:41 PM GMT -06:00 US/Canada Central
Subject: Re: [teiid-users] [teiid-dev] Alternative scripting envrionment for AdminShell
Steven Hawkins wrote:
> It doesn't seem like we have yet reached a consensus, but it does seem like:
> 1. people do like having a SQL oriented interactive command line tool.
> 2. most see the SQL functionality as separable from the admin/test.
>
> Agreed?
>
> I'd also like to relay a local discussion with Ramesh. His basic 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 choice.
>
I think this falls short on "out-of-the-box" experience. I like the
idea of a Groovy-based shell for Admin and a separate utility for ad-hoc
SQL without the user being required to configure their environment. Of
course, it would be nice if we *also* provided the option to
import/extend your java scripting environment of choice.
> ----- 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-users(a)lists.jboss.org>, "teiid-dev" <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.
>
> Ramesh..
>
> _______________________________________________
> teiid-users mailing list
> teiid-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-users
>
--
Ken Johnson
Sr. Product Manager
JBoss Middleware Business Unit
Red Hat, Inc
978.392.3917
ken.johnson(a)redhat.com
14 years
Re: [teiid-users] [teiid-dev] Alternative scripting envrionment for AdminShell
by John Doyle
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.
~jd
----- "Steven Hawkins" <shawkins(a)redhat.com> wrote:
> As a separate tool it is focused enough to support features such as
> sql command completion and other much beyond what we can offer :)
>
> Integration with Groovy isn't really the right path coming from this
> direction. You would rather see us support more functionality through
> sql, like the old admin vdb - which could be added back easily with
> the reduced admin logic and admin objects that map to xml (sqlxml).
> We should even support in line definition of procedures, which may
> require changes in the tool to support, but would mitigate the need
> for introducing another language.
>
> ----- Original Message -----
> From: "Ramesh Reddy" <rareddy(a)redhat.com>
> To: "Steven Hawkins" <shawkins(a)redhat.com>
> Cc: "Paul Nittel" <pnittel(a)redhat.com>, "teiid-users"
> <teiid-users(a)lists.jboss.org>, "teiid-dev"
> <teiid-dev(a)lists.jboss.org>
> Sent: Monday, April 12, 2010 6:31:27 PM GMT -06:00 US/Canada Central
> Subject: Re: [teiid-dev] Alternative scripting envrionment for
> AdminShell
>
> On Mon, 2010-04-12 at 17:22 -0400, Steven Hawkins wrote:
> > Even with those limitations I understand that it does serve as a
> > reasonable approximation to something like SQL*Plus. I question
> > whether we need to support specialized tooling for this purpose
> (over
> > just using what's available in Groovy). We could just as well
> promote
> > the use of http://sourceforge.net/projects/sqlshell/ or the older
> > http://henplus.sourceforge.net/.
>
> As separate tool it seems verbose and fragmented offering. If we can
> integrate these tools into groovy or add missing features as pulgins
> into these tools seems like the right path. The both tools above have
> their own shell environments, integrating with them or into groovy,
> both
> may be challenging.
>
> Henplus, seems to have extensive features, and seems to have the
> simultaneous name based connections, so it definitely gets my vote if
> we
> decide go this route.
>
> Ramesh..
>
> _______________________________________________
> teiid-users mailing list
> teiid-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-users
14 years
Teiid 7.0 M3
by Steven Hawkins
Hello all,
The long awaited Teiid 7.0 MS3 is now available - http://www.jboss.org/teiid/downloads.html. This milestone represents the next-generation of the Teiid runtime with deep integration into JBoss AS / JCA functionality. Check out the web based admin console, which is now available after installing the main dist, that shows off the marriage of these great technologies.
While not much will seem to have changed from a query feature standpoint, keep in mind that nearly all of our runtime and configuration and management logic has been rewritten for this release. With this major work out of the way, we should be able to deliver additional milestones, then betas/rc on a much better schedule.
Please give this milestone a try - and as always keep the issues coming if something needs addressed.
The Teiid Team
14 years
Re: [teiid-users] [teiid-dev] Alternative scripting envrionment for AdminShell
by Steven Hawkins
As a separate tool it is focused enough to support features such as sql command completion and other much beyond what we can offer :)
Integration with Groovy isn't really the right path coming from this direction. You would rather see us support more functionality through sql, like the old admin vdb - which could be added back easily with the reduced admin logic and admin objects that map to xml (sqlxml). We should even support in line definition of procedures, which may require changes in the tool to support, but would mitigate the need for introducing another language.
----- Original Message -----
From: "Ramesh Reddy" <rareddy(a)redhat.com>
To: "Steven Hawkins" <shawkins(a)redhat.com>
Cc: "Paul Nittel" <pnittel(a)redhat.com>, "teiid-users" <teiid-users(a)lists.jboss.org>, "teiid-dev" <teiid-dev(a)lists.jboss.org>
Sent: Monday, April 12, 2010 6:31:27 PM GMT -06:00 US/Canada Central
Subject: Re: [teiid-dev] Alternative scripting envrionment for AdminShell
On Mon, 2010-04-12 at 17:22 -0400, Steven Hawkins wrote:
> Even with those limitations I understand that it does serve as a
> reasonable approximation to something like SQL*Plus. I question
> whether we need to support specialized tooling for this purpose (over
> just using what's available in Groovy). We could just as well promote
> the use of http://sourceforge.net/projects/sqlshell/ or the older
> http://henplus.sourceforge.net/.
As separate tool it seems verbose and fragmented offering. If we can
integrate these tools into groovy or add missing features as pulgins
into these tools seems like the right path. The both tools above have
their own shell environments, integrating with them or into groovy, both
may be challenging.
Henplus, seems to have extensive features, and seems to have the
simultaneous name based connections, so it definitely gets my vote if we
decide go this route.
Ramesh..
14 years
Re: [teiid-users] [teiid-dev] Alternative scripting environment for AdminShell
by Steven Hawkins
The full lineage from 4/5.x is:
svcmgr -> AdminShell T1
jdbcisql -> AdminShell T2
CommandShell -> AdminShell T3
And yes, something like:
connect(user, passwd)
exportConnectionFactory("TPCR_S2k", "test.xml")
...
is possible for admin logic. It's just not as technically appealing as using variables, since it requires making all of the contextual methods static, adding context management, internal methods to check the context state, etc. Also, by design, all of the Groovy Sql logic are designed to not leak statements or resultsets, which doesn't map very well to our logic that still try to hide them but made them available for possibly multiple operations (although they were likely to fail since we didn't typically reset the result set to the first row). The example highlighted that - where it was one call in Groovy to execute and print the results, but 2 in adminshell.
Let me restate something, we could support our old style sql iff:
- we reintroduced the context management logic (noting that we have a problem with denoting both the current sql and admin connections in a single prompt)
- re-implement all of our old sql handling logic and associated result set methods
- override the groovy shell line evaluation method to check for statements that look like sql (noting that the current logic has a lot of limitations)
Which in my mind is that same as saying that we should do it.
----- Original Message -----
From: "Larry O'Leary" <loleary(a)redhat.com>
To: "Steven Hawkins" <shawkins(a)redhat.com>
Cc: "Paul Nittel" <pnittel(a)redhat.com>, "teiid-users" <teiid-users(a)lists.jboss.org>, "teiid-dev" <teiid-dev(a)lists.jboss.org>
Sent: Monday, April 12, 2010 6:03:25 PM GMT -06:00 US/Canada Central
Subject: Re: [teiid-users] [teiid-dev] Alternative scripting envrionment for AdminShell
On Mon, 2010-04-12 at 17:22 -0400, Steven Hawkins wrote:
> Eliminating C. is the difference between offering a scripting language with hooks vs. a "query tool". That's probably worth exploring more. I would say that there are 3 distinctly different tools we were trying to satisfy with AdminShell:
>
> T1. an interactive/scriptable administrative console
> T2. an interactive/scriptable query tool
> T3. an scriptable test tool for both 1 and 2.
>
> Arguably we were the only ones interested in T3, and as mentioned in the last email that functionality can be ported over quite easily regardless.
> For T1 the difference between the Groovy solution and the BeanShell solution is minimal (function syntax is the same, java can be imported and called in the same ways, etc.) and the Groovy solution can be changed to be contextual as well - although it is worth noting that our context is more complicated than before since your admin and sql connections are separate, which is not yet reflected in the old adminshell prompt. So to perform admin logic you don't need to be any more of a Java developer than you did with the BeanShell based tooling.
>
> For me the only real difference comes down to T2. From a technical perspective, the manner in which we extend the host grammar to support T2 is brittle and has limitations such as multiline handling or leading comments, etc. that are not handled by our hook. Even with those limitations I understand that it does serve as a reasonable approximation to something like SQL*Plus. I question whether we need to support specialized tooling for this purpose (over just using what's available in Groovy). We could just as well promote the use of http://sourceforge.net/projects/sqlshell/ or the older http://henplus.sourceforge.net/.
The original intention of the AdminShell was to give an administrator a
simple means of checking state/services within a server. It was a
replacement and great improvement to the old svcmgr. The idea was that
a user could execute the shell in interactive mode or non-interactive
mode and execute state and admin commands against the server.
Honestly, I am not sure where the SQL / query-execution came into play.
Seems like AdminShell was a bad place for this in the first place. This
should have lived in QueryShell or JDBCiSQL... oh wait!
So, as for the SQL / query-execution we should basically forget about
it. If a user wants to execute SQL, then they can write a Java
application to do so... or better yet, use one of the many
third-party/OSS solutions that allow a person to execute a query against
a JDBC data-source... I wonder if Eclipse has such a tool.
As for the AdminShell's administrative functions, as long as we provide
an out-of-the-box list of pre-defined or wrapped API commands to do
common tasks, it will suffice. From looking at your example, it appears
that nothing has really changed but I would like to see it simplified
further:
connect(user, passwd)
exportConnectionFactory("TPCR_S2k", "test.xml")
...
Basically, adminConn would implicitly contain the reference to the
connection if one was not given. For example:
myConn = connect(user, passwd)
exportConnectionFactory("TPCR_S2k", "test.xml")
...
Would result in an error because adminConn is still NULL.
However,
myConn = connect(user, passwd)
myConn.exportConnectionFactory("TPCR_S2k", "test.xml")
...
Would work just fine.
> ----- Original Message -----
> From: "Paul Nittel" <pnittel(a)redhat.com>
> To: "Steven Hawkins" <shawkins(a)redhat.com>
> Cc: "teiid-users" <teiid-users(a)lists.jboss.org>, "teiid-dev" <teiid-dev(a)lists.jboss.org>
> Sent: Monday, April 12, 2010 12:37:21 PM GMT -06:00 US/Canada Central
> Subject: Re: [teiid-dev] Alternative scripting envrionment for AdminShell
>
> A good thing about AdminShell and its predecessors, is the user needn't be Java developer to use it. If you eliminate 'C', aren't we doing a disservice to our users?
>
> Cheers,
> -------
> Paul Nittel
> JBoss Sr. Quality Assurance Engineer
> Red Hat, Inc.
> 314-336-2907 (81-62907)
>
> Delivering value year after year.
> Red Hat ranks #1 in value among software vendors.
> http://www.redhat.com/promo/vendor/
>
>
>
> ----- Original Message -----
> From: "Steven Hawkins" <shawkins(a)redhat.com>
> To: "teiid-users" <teiid-users(a)lists.jboss.org>, "teiid-dev" <teiid-dev(a)lists.jboss.org>
> Sent: Monday, April 12, 2010 10:32:12 AM GMT -06:00 US/Canada Central
> Subject: [teiid-dev] Alternative scripting envrionment for AdminShell
>
> Hello all,
>
> Before we get to a 7.0 RC, I would like to propose replacing our BeanShell based Adminshell with one based upon Groovy. The rationale for this change is:
> 1. BeanShell is no longer maintained
> 2. BeanShell interactive and graphical tools have usability issues (for example script development with AdminShell typically involves opening a separate text editor)
> 3. We have deep hooks into the scripting language for the admin shell that are difficult to maintain.
>
> While we could stay with BeanShell and address 2/3 it does not seem worth the effort given that we have the opportunity of a major release to make major changes. If we fully reduce our hooks into the scripting language/shell (which would move all relevant logic into Java), then the things we could loose are:
>
> A. A help system based upon the script source
> B. A contextual (where the connection context is shown on the prompt) command system
> C. Grammar extension for SQL, such that just entering a SQL is all that is required for execution.
>
> The things we would immediately gain with Groovy are:
>
> A command line shell that has a command history, maintains an editable buffer, and supports built-in script recording.
> A graphical console that functions as a simple text editor based IDE (with syntax highlighting) and supports full script and selected text execution.
> Built-in support for simplifying JDBC execution (which is extensible to support getting our debug logs, query plans, etc.), see http://groovy.codehaus.org/Tutorial+6+-+Groovy+SQL.
> And a wealth of other built-in Groovy modules for common activities, such as XML handling.
>
> To address A we would want to expose our relevant JavaDocs via help extensions in both the command line and graphical tools.
> I would argue that it's a matter of developer preference as to whether we address B. See the below example scipts.
>
> Example Groovy script:
>
> import static org.teiid.adminshell.AdminShell.* //optional - we could just as easily add this into the shell context automatically
>
> admin = connectAsAdmin()
>
> admin.exportConnectionFactory("TPCR_S2k", "test.xml")
>
> sql = connect()
>
> sql.eachRow("select * from tables", { println it })
>
>
>
> Current AdminShell script:
>
> connectAsAdmin();
>
> exportConnectionFactory("TPCR_S2k", "test.xml");
>
> connect();
>
> select * from tables;
>
> printResultSet();
>
>
> With the Groovy script (note ending ; are optional) explicit admin and sql objects are used to represent their respective connections. If additional connections are needed, then additional variables are introduced. In AdminShell the current connection is contextually bound so that functions may be called without explicitly identifying which connection is used. The same logic could be introduced in the Groovy hooks by providing static hooks to all the methods available on the Admin and Sql objects.
>
> I would propose that we would need to drop support for C completely, since it requires both the notion of a contextual connection and extending the host grammar (which cannot be done without deep hooks).
>
> Any thoughts?
>
> Steve
>
> _______________________________________________
> teiid-dev mailing list
> teiid-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-dev
> _______________________________________________
> teiid-users mailing list
> teiid-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-users
--
Larry O'Leary
Middleware Support Engineering Group
Global Support Services
Red Hat, Inc.
loleary(a)redhat.com
1.866.LINUX70 (+1.314.336.2990) xt 81-62909
Office: +1.314.336.2909
Mobile: +1.618.420.7623
--
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
14 years
Re: [teiid-users] [teiid-dev] Alternative scripting envrionment for AdminShell
by Steven Hawkins
Eliminating C. is the difference between offering a scripting language with hooks vs. a "query tool". That's probably worth exploring more. I would say that there are 3 distinctly different tools we were trying to satisfy with AdminShell:
T1. an interactive/scriptable administrative console
T2. an interactive/scriptable query tool
T3. an scriptable test tool for both 1 and 2.
Arguably we were the only ones interested in T3, and as mentioned in the last email that functionality can be ported over quite easily regardless.
For T1 the difference between the Groovy solution and the BeanShell solution is minimal (function syntax is the same, java can be imported and called in the same ways, etc.) and the Groovy solution can be changed to be contextual as well - although it is worth noting that our context is more complicated than before since your admin and sql connections are separate, which is not yet reflected in the old adminshell prompt. So to perform admin logic you don't need to be any more of a Java developer than you did with the BeanShell based tooling.
For me the only real difference comes down to T2. From a technical perspective, the manner in which we extend the host grammar to support T2 is brittle and has limitations such as multiline handling or leading comments, etc. that are not handled by our hook. Even with those limitations I understand that it does serve as a reasonable approximation to something like SQL*Plus. I question whether we need to support specialized tooling for this purpose (over just using what's available in Groovy). We could just as well promote the use of http://sourceforge.net/projects/sqlshell/ or the older http://henplus.sourceforge.net/.
----- Original Message -----
From: "Paul Nittel" <pnittel(a)redhat.com>
To: "Steven Hawkins" <shawkins(a)redhat.com>
Cc: "teiid-users" <teiid-users(a)lists.jboss.org>, "teiid-dev" <teiid-dev(a)lists.jboss.org>
Sent: Monday, April 12, 2010 12:37:21 PM GMT -06:00 US/Canada Central
Subject: Re: [teiid-dev] Alternative scripting envrionment for AdminShell
A good thing about AdminShell and its predecessors, is the user needn't be Java developer to use it. If you eliminate 'C', aren't we doing a disservice to our users?
Cheers,
-------
Paul Nittel
JBoss Sr. Quality Assurance Engineer
Red Hat, Inc.
314-336-2907 (81-62907)
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
----- Original Message -----
From: "Steven Hawkins" <shawkins(a)redhat.com>
To: "teiid-users" <teiid-users(a)lists.jboss.org>, "teiid-dev" <teiid-dev(a)lists.jboss.org>
Sent: Monday, April 12, 2010 10:32:12 AM GMT -06:00 US/Canada Central
Subject: [teiid-dev] Alternative scripting envrionment for AdminShell
Hello all,
Before we get to a 7.0 RC, I would like to propose replacing our BeanShell based Adminshell with one based upon Groovy. The rationale for this change is:
1. BeanShell is no longer maintained
2. BeanShell interactive and graphical tools have usability issues (for example script development with AdminShell typically involves opening a separate text editor)
3. We have deep hooks into the scripting language for the admin shell that are difficult to maintain.
While we could stay with BeanShell and address 2/3 it does not seem worth the effort given that we have the opportunity of a major release to make major changes. If we fully reduce our hooks into the scripting language/shell (which would move all relevant logic into Java), then the things we could loose are:
A. A help system based upon the script source
B. A contextual (where the connection context is shown on the prompt) command system
C. Grammar extension for SQL, such that just entering a SQL is all that is required for execution.
The things we would immediately gain with Groovy are:
A command line shell that has a command history, maintains an editable buffer, and supports built-in script recording.
A graphical console that functions as a simple text editor based IDE (with syntax highlighting) and supports full script and selected text execution.
Built-in support for simplifying JDBC execution (which is extensible to support getting our debug logs, query plans, etc.), see http://groovy.codehaus.org/Tutorial+6+-+Groovy+SQL.
And a wealth of other built-in Groovy modules for common activities, such as XML handling.
To address A we would want to expose our relevant JavaDocs via help extensions in both the command line and graphical tools.
I would argue that it's a matter of developer preference as to whether we address B. See the below example scipts.
Example Groovy script:
import static org.teiid.adminshell.AdminShell.* //optional - we could just as easily add this into the shell context automatically
admin = connectAsAdmin()
admin.exportConnectionFactory("TPCR_S2k", "test.xml")
sql = connect()
sql.eachRow("select * from tables", { println it })
Current AdminShell script:
connectAsAdmin();
exportConnectionFactory("TPCR_S2k", "test.xml");
connect();
select * from tables;
printResultSet();
With the Groovy script (note ending ; are optional) explicit admin and sql objects are used to represent their respective connections. If additional connections are needed, then additional variables are introduced. In AdminShell the current connection is contextually bound so that functions may be called without explicitly identifying which connection is used. The same logic could be introduced in the Groovy hooks by providing static hooks to all the methods available on the Admin and Sql objects.
I would propose that we would need to drop support for C completely, since it requires both the notion of a contextual connection and extending the host grammar (which cannot be done without deep hooks).
Any thoughts?
Steve
_______________________________________________
teiid-dev mailing list
teiid-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-dev
14 years
