Re: [teiid-designer-dev] VDB configuration
by John Doyle
Perhaps I'm missing some complications. Are we talking about syncing the file on disk with the various views, or the file on disk with the deployed VDB?
And I do mean for the user to edit, otherwise, like Dan, I see no point. The plugin.xml (MANIFEST.MF, build.properties) is the model I have in mind.
As far as the typical user of Designer goes, I'm actually trying to build a bridge between the 'historical' user of Designer, for whom we want to maintain our high level of usability and the ability to 'just click the button', and what I perceive as the typical JBoss user, who edits configuration files by hand and doesn't like that things they don't understand happen when they 'just click the button. It will certainly be more work for us to provide both of these paradigms, maybe even double the work, and I'm not arguing that we do it today, but I think it's the right direction.
~jd
----- "Daniel Florian" <dflorian(a)redhat.com> wrote:
> I'm not crazy about it. I'm not sure if the typical user of Designer
> cares about that file or even knows one exists inside a VDB. But you
> can correct me on that one. It seems silly to have that tab if you
> can't edit it. And if you do allow editing, as stated below, it
> complicates the editor quite a bit. Not only the framework to sync
> editors would be needed, but editor validation and a way for the user
> to overwrite with an auto-generated file may also be needed. I'm just
> not sure the cost/benefit is worth it right now.
>
> ----- Original Message -----
> From: "Ramesh Reddy" <rareddy(a)redhat.com>
> To: "John Doyle" <jdoyle(a)redhat.com>
> Cc: "teiid-designer-dev" <teiid-designer-dev(a)lists.jboss.org>
> Sent: Monday, March 22, 2010 1:41:28 PM GMT -06:00 US/Canada Central
> Subject: Re: [teiid-designer-dev] VDB configuration
>
> I like it. The only issue is whether you want to let the users edit
> it
> or not. If you do, then syncing is the issue.
>
> Ramesh..
>
> On Mon, 2010-03-22 at 13:21 -0400, John Doyle wrote:
> > I've been working on the VDB UI to stub out the changes for Teiid 7
> and wanted to float an idea. How about adding an additional tab to
> the VDB editor view that showed the configuration.def file in a raw
> XML view? This seems like a pretty standard eclipse paradigm and I
> think plays into the way the typical JBoss user expects to interaction
> with their tools.
> >
> > ~jd
> > _______________________________________________
> > teiid-designer-dev mailing list
> > teiid-designer-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/teiid-designer-dev
>
> _______________________________________________
> teiid-designer-dev mailing list
> teiid-designer-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-designer-dev
> _______________________________________________
> teiid-designer-dev mailing list
> teiid-designer-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-designer-dev
16 years, 1 month
Re: [teiid-designer-dev] VDB configuration
by Daniel Florian
I'm not crazy about it. I'm not sure if the typical user of Designer cares about that file or even knows one exists inside a VDB. But you can correct me on that one. It seems silly to have that tab if you can't edit it. And if you do allow editing, as stated below, it complicates the editor quite a bit. Not only the framework to sync editors would be needed, but editor validation and a way for the user to overwrite with an auto-generated file may also be needed. I'm just not sure the cost/benefit is worth it right now.
----- Original Message -----
From: "Ramesh Reddy" <rareddy(a)redhat.com>
To: "John Doyle" <jdoyle(a)redhat.com>
Cc: "teiid-designer-dev" <teiid-designer-dev(a)lists.jboss.org>
Sent: Monday, March 22, 2010 1:41:28 PM GMT -06:00 US/Canada Central
Subject: Re: [teiid-designer-dev] VDB configuration
I like it. The only issue is whether you want to let the users edit it
or not. If you do, then syncing is the issue.
Ramesh..
On Mon, 2010-03-22 at 13:21 -0400, John Doyle wrote:
> I've been working on the VDB UI to stub out the changes for Teiid 7 and wanted to float an idea. How about adding an additional tab to the VDB editor view that showed the configuration.def file in a raw XML view? This seems like a pretty standard eclipse paradigm and I think plays into the way the typical JBoss user expects to interaction with their tools.
>
> ~jd
> _______________________________________________
> teiid-designer-dev mailing list
> teiid-designer-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-designer-dev
_______________________________________________
teiid-designer-dev mailing list
teiid-designer-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-designer-dev
16 years, 1 month
VDB configuration
by John Doyle
I've been working on the VDB UI to stub out the changes for Teiid 7 and wanted to float an idea. How about adding an additional tab to the VDB editor view that showed the configuration.def file in a raw XML view? This seems like a pretty standard eclipse paradigm and I think plays into the way the typical JBoss user expects to interaction with their tools.
~jd
16 years, 1 month
7.0 Designer Tasks - 4 March, 2010
by Barry Lafond
All,
Wanted to get you all up to speed on the scope of what is needed for Teiid Designer to maintain 6.3 feature functionality.
The attached doc categorizes several areas, some of which have already been started as part of the 7.0 Teiid Integration JIRA (TEIIDDES-255). This list has been growing as a result of fixing errors, implementing Teiid API changes.
The doc highlights various JIRA's corresponding to these tasks. Feel free to comment. There's a lot of work to do and we'll need and welcome everyone's input.
Thx
Barry LaFond
Teiid Designer Project
16 years, 1 month
Proposed Schema for "ConfigurationInfo.def" file
by Ramesh Reddy
Based on the JCA changes to the VDB artifact and its configuration the
current "ConfigurationInfo.def" file needs to be modified.
I have attached the XML schema and a sample XML file showing the new
format of this file. This format closely resembles the old format with
few additions to lot of removal of other elements.
This same XML file will serve as
1) Configuration for the VDB
2) Configuration to define a "Dynamic VDB"
3) Will serve as the persisted format in the container, when a user
modifies the associated connector bindings to a model using any
administrative tools.
Please take look at this and let me know if there are any suggestions to
improve upon.
Thank you.
Ramesh..
16 years, 1 month
Re: [teiid-designer-dev] [teiid-dev] vdb connector binding names
by Steven Hawkins
All this is making me like the alternative scenario more. The only time an explicit source name (aka vdb specific connector binding name) other than the model name comes into place is with multi-source. And in that case we assume source name == connector binding name.
That gives us updated terminology:
a connector / connetor type - scope deployment wide
a connector binding / connector binding name == source name / jndi name - scope deployment wide
a model name - scope vdb
The additional requirement for multi-source is that they must keep connector binding names consistent across environments.
----- Original Message -----
From: "Ken Johnson" <kejohnso(a)redhat.com>
To: "Steven Hawkins" <shawkins(a)redhat.com>
Cc: "Ramesh Reddy" <rareddy(a)redhat.com>, "teiid-designer-dev" <teiid-designer-dev(a)lists.jboss.org>, "teiid-dev" <teiid-dev(a)lists.jboss.org>
Sent: Tuesday, March 2, 2010 10:50:12 AM GMT -06:00 US/Canada Central
Subject: Re: [teiid-dev] vdb connector binding names
I think I agree with this but have few clarifying questions points below.
Steven Hawkins wrote:
> We should be clearer on our terms. There are:
>
> a connector / connetor type - scope deployment wide
> a connector binding / connector binding name / jndi name - scope deployment wide
> a vdb specific connector binding name (aka source name) - scope vdb
>
> I'm suggesting that in non-multisource scenarios that model name == vdb specific connector binding name. If there are two models sharing the same connector that's fine.
>
Right. Each model is bound to the same connector but each has it's own
binding and thus it's own binding name.
The terminology is letting us down here again. To clarify the models are using the same connector binding. This is not the same as having the same connector and two connector bindings assigned to two different models.
> At deployment time assigning a connector binding to a model is sufficient for the non-multisource case. For
Here, will the vdb-specific-connector-binding-name come into play? That
is, will the binding gesture be a mapping of the
vdb-specific-connector-binding-name to the deployment-wide connector
binding name? Or will it be a binding of the model name to the
deployment wide connector binding name? I assume the latter but want to
be sure.
> multisource connector binding association, an additional "source name" attribute would be required. If the deployer has multiple multi-source models associated to the same set of connector bindings, it would be up to them to ensure that the source name was consistent.
>
This could potentially be managed by convention. That is, when using
multi-source models, those connector bindings need to be dedicated to
the multi-source models. They cannot be shared with standard,
single-source models or other multi-source models. It's a restriction
but should be have minimal impact on the broad user community.
> Alternatively we can infer the source name to be the connector binding name. This removes the need of having a vdb specific source name (which removes some desirable indirection), but this is how it worked in MMX anyway.
>
> ----- Original Message -----
> From: "Ramesh Reddy" <rareddy(a)redhat.com>
> To: "Steven Hawkins" <shawkins(a)redhat.com>
> Cc: "teiid-dev" <teiid-dev(a)lists.jboss.org>, "teiid-designer-dev" <teiid-designer-dev(a)lists.jboss.org>
> Sent: Tuesday, March 2, 2010 9:32:49 AM GMT -06:00 US/Canada Central
> Subject: Re: [teiid-dev] vdb connector binding names
>
> Using the model name as the connector name is fine for default scenario,
> unless there are two models that are associated with same connector.
>
> On Tue, 2010-03-02 at 10:11 -0500, Steven Hawkins wrote:
>
>> Hello all,
>>
>> There seems to be some confusion over what's needed for connector binding names. To simplify things, there are two basic requirements - we need a known/stable/not environmentally dependent name for each connector binding used in a vdb and there also needs to be a way to associate that name with an actual JNDI resource. In the case of non-multisource models, the model name itself satisfies the first part. Only in the multisource scenario do we have an issue with needing an additional vdb specific name for the connector binding. As a first cut it seems fine to say that both the JNDI mapping and the vdb specific naming of multi-source connector bindings is a deployment time concern. Then the only design-time concerns become the model name and optionally marking a model multi-source enabled.
>>
>> Any thoughs?
>>
>> 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
>
16 years, 1 month
Re: [teiid-designer-dev] [teiid-dev] vdb connector binding names
by Steven Hawkins
We should be clearer on our terms. There are:
a connector / connetor type - scope deployment wide
a connector binding / connector binding name / jndi name - scope deployment wide
a vdb specific connector binding name (aka source name) - scope vdb
I'm suggesting that in non-multisource scenarios that model name == vdb specific connector binding name. If there are two models sharing the same connector that's fine.
At deployment time assigning a connector binding to a model is sufficient for the non-multisource case. For multisource connector binding association, an additional "source name" attribute would be required. If the deployer has multiple multi-source models associated to the same set of connector bindings, it would be up to them to ensure that the source name was consistent.
Alternatively we can infer the source name to be the connector binding name. This removes the need of having a vdb specific source name (which removes some desirable indirection), but this is how it worked in MMX anyway.
----- Original Message -----
From: "Ramesh Reddy" <rareddy(a)redhat.com>
To: "Steven Hawkins" <shawkins(a)redhat.com>
Cc: "teiid-dev" <teiid-dev(a)lists.jboss.org>, "teiid-designer-dev" <teiid-designer-dev(a)lists.jboss.org>
Sent: Tuesday, March 2, 2010 9:32:49 AM GMT -06:00 US/Canada Central
Subject: Re: [teiid-dev] vdb connector binding names
Using the model name as the connector name is fine for default scenario,
unless there are two models that are associated with same connector.
On Tue, 2010-03-02 at 10:11 -0500, Steven Hawkins wrote:
> Hello all,
>
> There seems to be some confusion over what's needed for connector binding names. To simplify things, there are two basic requirements - we need a known/stable/not environmentally dependent name for each connector binding used in a vdb and there also needs to be a way to associate that name with an actual JNDI resource. In the case of non-multisource models, the model name itself satisfies the first part. Only in the multisource scenario do we have an issue with needing an additional vdb specific name for the connector binding. As a first cut it seems fine to say that both the JNDI mapping and the vdb specific naming of multi-source connector bindings is a deployment time concern. Then the only design-time concerns become the model name and optionally marking a model multi-source enabled.
>
> Any thoughs?
>
> Steve
>
> _______________________________________________
> teiid-dev mailing list
> teiid-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-dev
16 years, 1 month
vdb connector binding names
by Steven Hawkins
Hello all,
There seems to be some confusion over what's needed for connector binding names. To simplify things, there are two basic requirements - we need a known/stable/not environmentally dependent name for each connector binding used in a vdb and there also needs to be a way to associate that name with an actual JNDI resource. In the case of non-multisource models, the model name itself satisfies the first part. Only in the multisource scenario do we have an issue with needing an additional vdb specific name for the connector binding. As a first cut it seems fine to say that both the JNDI mapping and the vdb specific naming of multi-source connector bindings is a deployment time concern. Then the only design-time concerns become the model name and optionally marking a model multi-source enabled.
Any thoughs?
Steve
16 years, 1 month
