1:45 p.m.
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..
1:51 p.m.
Attached is schema diagram for easier viewing.
On Mon, 2010-02-01 at 13:45 -0600, Ramesh Reddy wrote:
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..
_______________________________________________
teiid-dev mailing list
teiid-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-dev
9:50 a.m.
New subject: [teiid-designer-dev] Proposed Schema for "ConfigurationInfo.def" file
What do you guys think about extending the same file to add the data
roles specific XML. Right now we have an additional file this in the
VDB.
I am looking at this file like "web.xml" in the web world where all the
run time configuration about the module is in a single file.
Thanks.
On Mon, 2010-02-01 at 13:51 -0600, Ramesh Reddy wrote:
Attached is schema diagram for easier viewing.
On Mon, 2010-02-01 at 13:45 -0600, Ramesh Reddy wrote:
> 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..
10:01 a.m.
New subject: [teiid-designer-dev] Proposed Schema for "ConfigurationInfo.def" file
On Feb 3, 2010, at 9:50 AM, Ramesh Reddy wrote:
What do you guys think about extending the same file to add the data
roles specific XML. Right now we have an additional file this in the
VDB.
I am looking at this file like "web.xml" in the web world where all the
run time configuration about the module is in a single file.
I'm good with the "single configuration" idea, but we don't deal with
data roles in Designer that I'm aware of.
Thanks,
JPAV
11:48 a.m.
New subject: [teiid-designer-dev] Proposed Schema for "ConfigurationInfo.def" file
On Wed, 2010-02-03 at 10:01 -0600, John Verhaeg wrote:
I'm good with the "single configuration" idea, but we
don't deal with data roles in Designer that I'm aware of.
As Console that used to provide this functionality has been deprecated,
we need to think of alternative tooling around this feature. IMO,
Designer is the best as I do not think Teiid's JON based plugin will
have capabilities to provide the same functions in terms of providing
the UI.
Let's start another thread on this.
Ramesh..
12:02 p.m.
New subject: [teiid-designer-dev] Proposed Schema for "ConfigurationInfo.def" file
We should keep Jopr/JON as a possibility. If the data driving UI is User/group/role, we
should be able to code that into our plugin.
Ted
----- Original Message -----
From: "Ramesh Reddy" <rareddy(a)redhat.com>
To: "John Verhaeg" <jverhaeg(a)redhat.com>
Cc: teiid-designer-dev(a)lists.jboss.org, teiid-dev(a)lists.jboss.org
Sent: Wednesday, February 3, 2010 11:48:59 AM GMT -06:00 US/Canada Central
Subject: Re: [teiid-dev] [teiid-designer-dev] Proposed Schema for
"ConfigurationInfo.def" file
On Wed, 2010-02-03 at 10:01 -0600, John Verhaeg wrote:
I'm good with the "single configuration" idea, but we
don't deal with data roles in Designer that I'm aware of.
As Console that used to provide this functionality has been deprecated,
we need to think of alternative tooling around this feature. IMO,
Designer is the best as I do not think Teiid's JON based plugin will
have capabilities to provide the same functions in terms of providing
the UI.
Let's start another thread on this.
Ramesh..
_______________________________________________
teiid-dev mailing list
teiid-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-dev
12:14 p.m.
New subject: Defining Data Roles - was [Re: [teiid-designer-dev] Proposed Schema for "ConfigurationInfo.def" file]
On Wed, 2010-02-03 at 13:02 -0500, Ted Jones wrote:
We should keep Jopr/JON as a possibility. If the data driving UI is
User/group/role, we should be able to code that into our plugin.
Even if we can have rich UI in the JON tool, in order for this to work
we would need to expose the Model's metadata through profile service,
such as Tables, columns, procedures etc. Which IMO is not feasible or
right place to do in a management tool.
There are two distinctive tasks here
1) At design time a data architect is defining the security model for
the data access defined by a VDB
2) Second as the production admin, see which user qualifies for a
particular role and do the role-mapping. As production admin would not
have any clue about your data model.
IMO, Designer is right tool for (1), JON for (2).
Ramesh..
PS: please correct the subject line in your next post. take off "was-*$"
1:37 p.m.
New subject: Defining Data Roles - was [Re: [teiid-designer-dev] Proposed Schema for "ConfigurationInfo.def" file]
So the roles would be defined in the Designer and the users would be created and assigned
to the roles in JON?
If so, that seems like a reasonable approach.
Ted
----- Original Message -----
From: "Ramesh Reddy" <rareddy(a)redhat.com>
To: teiid-designer-dev(a)lists.jboss.org, teiid-dev(a)lists.jboss.org
Sent: Thursday, February 4, 2010 12:14:35 PM GMT -06:00 US/Canada Central
Subject: [teiid-dev] Defining Data Roles - was [Re: [teiid-designer-dev] Proposed Schema
for "ConfigurationInfo.def" file]
On Wed, 2010-02-03 at 13:02 -0500, Ted Jones wrote:
We should keep Jopr/JON as a possibility. If the data driving UI is
User/group/role, we should be able to code that into our plugin.
Even if we can have rich UI in the JON tool, in order for this to work
we would need to expose the Model's metadata through profile service,
such as Tables, columns, procedures etc. Which IMO is not feasible or
right place to do in a management tool.
There are two distinctive tasks here
1) At design time a data architect is defining the security model for
the data access defined by a VDB
2) Second as the production admin, see which user qualifies for a
particular role and do the role-mapping. As production admin would not
have any clue about your data model.
IMO, Designer is right tool for (1), JON for (2).
Ramesh..
PS: please correct the subject line in your next post. take off "was-*$"
_______________________________________________
teiid-dev mailing list
teiid-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-dev
9:14 a.m.
New subject: Defining Data Roles
On Thu, 2010-02-04 at 14:37 -0500, Ted Jones wrote:
So the roles would be defined in the Designer and the users would be
created and assigned to the roles in JON?
If so, that seems like a reasonable approach.
No, the role references will be created in the Designer, and those
references will be mapped to actual roles in the JON/JOPR. In the
absence of this mapping, runtime will try to use the reference name as
actual name. This will help us through testing at design time with out
use of another tool to configure these details.
Creation of a user or creation of role is not the functionality of this
module, those should be handled by who ever handles security domains.
Currently I do not see this in the JOPR tool, that is something we need
to open a dialog with JOPR team and see where this is on their roadmap.
Ramesh..
10:55 a.m.
New subject: Defining Data Roles
Ramesh Reddy wrote:
On Thu, 2010-02-04 at 14:37 -0500, Ted Jones wrote:
> So the roles would be defined in the Designer and the users would be created and
assigned to the roles in JON?
>
> If so, that seems like a reasonable approach.
>
>
No, the role references will be created in the Designer, and those
references will be mapped to actual roles in the JON/JOPR. In the
absence of this mapping, runtime will try to use the reference name as
actual name. This will help us through testing at design time with out
use of another tool to configure these details.
It might be useful for this to be configurable behavior. In dev,
perhaps you want to run without security and no-mapping scenarios should
be ignored or defaulted. In test/prod, you may want an error if a role
reference is not explicitly mapped.
Creation of a user or creation of role is not the functionality of
this
module, those should be handled by who ever handles security domains.
Currently I do not see this in the JOPR tool, that is something we need
to open a dialog with JOPR team and see where this is on their roadmap.
The question is who "owns" the group-role and role->reference
mapping
information, from both a UI and persistence perspective.
Ramesh..
_______________________________________________
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
12:25 p.m.
New subject: Defining Data Roles
On Mon, 2010-02-08 at 11:55 -0500, Ken Johnson wrote:
> No, the role references will be created in the Designer, and
those
> references will be mapped to actual roles in the JON/JOPR. In the
> absence of this mapping, runtime will try to use the reference name
as
> actual name. This will help us through testing at design time with
out
> use of another tool to configure these details.
>
It might be useful for this to be configurable behavior. In dev,
perhaps you want to run without security and no-mapping scenarios
should
be ignored or defaulted. In test/prod, you may want an error if a
role
reference is not explicitly mapped.
Good point, will take this into account.
> Creation of a user or creation of role is not the functionality of
this
> module, those should be handled by who ever handles security
domains.
> Currently I do not see this in the JOPR tool, that is something we
need
> to open a dialog with JOPR team and see where this is on their
roadmap.
>
The question is who "owns" the group-role and role->reference mapping
information, from both a UI and persistence perspective.
Currently general security is container's functionality through
picketlink project. So, in general we would like this functionality
container wide. As per the specific VDB data role mapping Teiid would
own it.
Ramesh..
12:26 p.m.
Attached find updated schema for the configuration file that includes
the changes for including "data-roles". Please take look an let me know
if I need to change anything.
I also attached image of the schema and a sample xml file (generated).
Thanks
Ramesh..
On Mon, 2010-02-01 at 13:51 -0600, Ramesh Reddy wrote:
Attached is schema diagram for easier viewing.
On Mon, 2010-02-01 at 13:45 -0600, Ramesh Reddy wrote:
> 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.
>
3:37 p.m.
New subject: [teiid-designer-dev] Proposed Schema for "ConfigurationInfo.def" file
Is there any interest from the Tooling to merge "vdb-manifest.xmi" that
is in every VDB file into this file. Based on this schema, we can make
it work with single file. Since we already making changes to current
format, I thought I will put this as question.
Currently there are two different files, and Teiid at deployment time
reconciles these two into single entity. The "vdb-manifest.xmi" has
properties such as "model-type", "model-uri", "visibily"
etc. It would
be *nice* to have single file.
I see this same file is being used for defining the "dynamic-vdb" too,
so this will fill in gap between the differences between two versions in
defining some of the same properties.
Ramesh..
On Thu, 2010-02-18 at 12:26 -0600, Ramesh Reddy wrote:
Attached find updated schema for the configuration file that
includes
the changes for including "data-roles". Please take look an let me know
if I need to change anything.
I also attached image of the schema and a sample xml file (generated).
Thanks
Ramesh..
On Mon, 2010-02-01 at 13:51 -0600, Ramesh Reddy wrote:
> Attached is schema diagram for easier viewing.
>
> On Mon, 2010-02-01 at 13:45 -0600, Ramesh Reddy wrote:
> > 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.
> >
_______________________________________________
teiid-designer-dev mailing list
teiid-designer-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-designer-dev
5:27 p.m.
New subject: [teiid-designer-dev] Proposed Schema for "ConfigurationInfo.def" file
Taking second look at the vdb-manifest, Teiid runtime only looks at
1) type - required (for making sure the binding is associated)
2) uri
3) visibility - (required by runtime, but if not available it is assumed
"PUBLIC")
4) path
Another thing the runtime looks for is any problem "markers" with
severity = "error", which avoids VDB from deploying.
I added above to the "model" element as attributes. Also added a new
optional element called "problem-marker" to include the errors. See
attached.
Since there were no oppositions, I will go ahead with the required
changes in Teiid runtime. Let me know if you if want me tweak the schema
any differently.
Ramesh..
On Fri, 2010-02-19 at 15:37 -0600, Ramesh Reddy wrote:
Is there any interest from the Tooling to merge
"vdb-manifest.xmi" that
is in every VDB file into this file. Based on this schema, we can make
it work with single file. Since we already making changes to current
format, I thought I will put this as question.
Currently there are two different files, and Teiid at deployment time
reconciles these two into single entity. The "vdb-manifest.xmi" has
properties such as "model-type", "model-uri", "visibily"
etc. It would
be *nice* to have single file.
I see this same file is being used for defining the "dynamic-vdb" too,
so this will fill in gap between the differences between two versions in
defining some of the same properties.
Ramesh..
On Thu, 2010-02-18 at 12:26 -0600, Ramesh Reddy wrote:
> Attached find updated schema for the configuration file that includes
> the changes for including "data-roles". Please take look an let me know
> if I need to change anything.
>
> I also attached image of the schema and a sample xml file (generated).
>
> Thanks
>
> Ramesh..
>
> On Mon, 2010-02-01 at 13:51 -0600, Ramesh Reddy wrote:
> > Attached is schema diagram for easier viewing.
> >
> > On Mon, 2010-02-01 at 13:45 -0600, Ramesh Reddy wrote:
> > > 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.
> > >
>
> _______________________________________________
> 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
10:41 a.m.
New subject: [teiid-designer-dev] Proposed Schema for "ConfigurationInfo.def" file
Here is another revision to this schema file. I removed the "data-role"
and modified couple names to fit what they mean.
Ramesh..
On Wed, 2010-02-24 at 17:27 -0600, Ramesh Reddy wrote:
Taking second look at the vdb-manifest, Teiid runtime only looks at
1) type - required (for making sure the binding is associated)
2) uri
3) visibility - (required by runtime, but if not available it is assumed
"PUBLIC")
4) path
Another thing the runtime looks for is any problem "markers" with
severity = "error", which avoids VDB from deploying.
I added above to the "model" element as attributes. Also added a new
optional element called "problem-marker" to include the errors. See
attached.
Since there were no oppositions, I will go ahead with the required
changes in Teiid runtime. Let me know if you if want me tweak the schema
any differently.
Ramesh..
On Fri, 2010-02-19 at 15:37 -0600, Ramesh Reddy wrote:
> Is there any interest from the Tooling to merge "vdb-manifest.xmi" that
> is in every VDB file into this file. Based on this schema, we can make
> it work with single file. Since we already making changes to current
> format, I thought I will put this as question.
>
> Currently there are two different files, and Teiid at deployment time
> reconciles these two into single entity. The "vdb-manifest.xmi" has
> properties such as "model-type", "model-uri",
"visibily" etc. It would
> be *nice* to have single file.
>
> I see this same file is being used for defining the "dynamic-vdb" too,
> so this will fill in gap between the differences between two versions in
> defining some of the same properties.
>
> Ramesh..
>
> On Thu, 2010-02-18 at 12:26 -0600, Ramesh Reddy wrote:
> > Attached find updated schema for the configuration file that includes
> > the changes for including "data-roles". Please take look an let me
know
> > if I need to change anything.
> >
> > I also attached image of the schema and a sample xml file (generated).
> >
> > Thanks
> >
> > Ramesh..
> >
> > On Mon, 2010-02-01 at 13:51 -0600, Ramesh Reddy wrote:
> > > Attached is schema diagram for easier viewing.
> > >
> > > On Mon, 2010-02-01 at 13:45 -0600, Ramesh Reddy wrote:
> > > > 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.
> > > >
> >
> > _______________________________________________
> > 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-dev mailing list
teiid-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-dev
5:43 p.m.
New subject: [teiid-designer-dev] Proposed Schema for "ConfigurationInfo.def" file
Based discussions from another thread here is the another revision of
the schema. Let me if this works..
Ramesh..
On Mon, 2010-03-01 at 10:41 -0600, Ramesh Reddy wrote:
Here is another revision to this schema file. I removed the
"data-role"
and modified couple names to fit what they mean.
Ramesh..
On Wed, 2010-02-24 at 17:27 -0600, Ramesh Reddy wrote:
> Taking second look at the vdb-manifest, Teiid runtime only looks at
>
> 1) type - required (for making sure the binding is associated)
> 2) uri
> 3) visibility - (required by runtime, but if not available it is assumed
> "PUBLIC")
> 4) path
>
> Another thing the runtime looks for is any problem "markers" with
> severity = "error", which avoids VDB from deploying.
>
> I added above to the "model" element as attributes. Also added a new
> optional element called "problem-marker" to include the errors. See
> attached.
>
> Since there were no oppositions, I will go ahead with the required
> changes in Teiid runtime. Let me know if you if want me tweak the schema
> any differently.
>
> Ramesh..
>
>
> On Fri, 2010-02-19 at 15:37 -0600, Ramesh Reddy wrote:
> > Is there any interest from the Tooling to merge "vdb-manifest.xmi"
that
> > is in every VDB file into this file. Based on this schema, we can make
> > it work with single file. Since we already making changes to current
> > format, I thought I will put this as question.
> >
> > Currently there are two different files, and Teiid at deployment time
> > reconciles these two into single entity. The "vdb-manifest.xmi" has
> > properties such as "model-type", "model-uri",
"visibily" etc. It would
> > be *nice* to have single file.
> >
> > I see this same file is being used for defining the "dynamic-vdb"
too,
> > so this will fill in gap between the differences between two versions in
> > defining some of the same properties.
> >
> > Ramesh..
> >
> > On Thu, 2010-02-18 at 12:26 -0600, Ramesh Reddy wrote:
> > > Attached find updated schema for the configuration file that includes
> > > the changes for including "data-roles". Please take look an let
me know
> > > if I need to change anything.
> > >
> > > I also attached image of the schema and a sample xml file (generated).
> > >
> > > Thanks
> > >
> > > Ramesh..
> > >
> > > On Mon, 2010-02-01 at 13:51 -0600, Ramesh Reddy wrote:
> > > > Attached is schema diagram for easier viewing.
> > > >
> > > > On Mon, 2010-02-01 at 13:45 -0600, Ramesh Reddy wrote:
> > > > > 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.
> > > > >
> > >
> > > _______________________________________________
> > > 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-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
4:46 p.m.
New subject: [teiid-designer-dev] Proposed Schema for "ConfigurationInfo.def" file
Now comes to the question what we name the XML file inside the VDB
artifact.
some suggestions
teiid-vdb-deployer.xml
teiid-vdb-configuration.xml
any more?
Let me know quick, we are ready to merge..
Thanks
Ramesh..
On Tue, 2010-03-02 at 17:43 -0600, Ramesh Reddy wrote:
Based discussions from another thread here is the another revision
of
the schema. Let me if this works..
Ramesh..
On Mon, 2010-03-01 at 10:41 -0600, Ramesh Reddy wrote:
> Here is another revision to this schema file. I removed the "data-role"
> and modified couple names to fit what they mean.
>
> Ramesh..
>
>
> On Wed, 2010-02-24 at 17:27 -0600, Ramesh Reddy wrote:
> > Taking second look at the vdb-manifest, Teiid runtime only looks at
> >
> > 1) type - required (for making sure the binding is associated)
> > 2) uri
> > 3) visibility - (required by runtime, but if not available it is assumed
> > "PUBLIC")
> > 4) path
> >
> > Another thing the runtime looks for is any problem "markers" with
> > severity = "error", which avoids VDB from deploying.
> >
> > I added above to the "model" element as attributes. Also added a new
> > optional element called "problem-marker" to include the errors. See
> > attached.
> >
> > Since there were no oppositions, I will go ahead with the required
> > changes in Teiid runtime. Let me know if you if want me tweak the schema
> > any differently.
> >
> > Ramesh..
> >
> >
> > On Fri, 2010-02-19 at 15:37 -0600, Ramesh Reddy wrote:
> > > Is there any interest from the Tooling to merge
"vdb-manifest.xmi" that
> > > is in every VDB file into this file. Based on this schema, we can make
> > > it work with single file. Since we already making changes to current
> > > format, I thought I will put this as question.
> > >
> > > Currently there are two different files, and Teiid at deployment time
> > > reconciles these two into single entity. The "vdb-manifest.xmi"
has
> > > properties such as "model-type", "model-uri",
"visibily" etc. It would
> > > be *nice* to have single file.
> > >
> > > I see this same file is being used for defining the
"dynamic-vdb" too,
> > > so this will fill in gap between the differences between two versions in
> > > defining some of the same properties.
> > >
> > > Ramesh..
> > >
> > > On Thu, 2010-02-18 at 12:26 -0600, Ramesh Reddy wrote:
> > > > Attached find updated schema for the configuration file that
includes
> > > > the changes for including "data-roles". Please take look an
let me know
> > > > if I need to change anything.
> > > >
> > > > I also attached image of the schema and a sample xml file
(generated).
> > > >
> > > > Thanks
> > > >
> > > > Ramesh..
> > > >
> > > > On Mon, 2010-02-01 at 13:51 -0600, Ramesh Reddy wrote:
> > > > > Attached is schema diagram for easier viewing.
> > > > >
> > > > > On Mon, 2010-02-01 at 13:45 -0600, Ramesh Reddy wrote:
> > > > > > 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.
> > > > > >
> > > >
> > > > _______________________________________________
> > > > 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-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
_______________________________________________
teiid-dev mailing list
teiid-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-dev
4:59 p.m.
New subject: [teiid-designer-dev] Proposed Schema for "ConfigurationInfo.def" file
On Mar 3, 2010, at 4:46 PM, Ramesh Reddy wrote:
Now comes to the question what we name the XML file inside the VDB
artifact.
some suggestions
teiid-vdb-deployer.xml
teiid-vdb-configuration.xml
As long as we put the file in the META-INF folder, seems like
"configuration.xml" is sufficient.
Thanks,
JPAV
8:34 a.m.
New subject: [teiid-designer-dev] Proposed Schema for "ConfigurationInfo.def" file
Yes, this needs to be placed n the META-INF folder.
After thinking little bit, I like "vdb.xml", this also segways into
defining the dynamic vdb name XML as
books-vdb.xml
bqt-vdb.xml
Remember these two files share same XML format.
This is a pattern JBoss uses with their bean names too, for example if
the bean is in the JAR file they use "jboss-beans.xml" file inside the
META-INF. If the XML file defined out side they are defined as
foo-jboss-beans.xml
bar-boss-beans.xml
Thanks
Ramesh..
On Wed, 2010-03-03 at 16:59 -0600, John Verhaeg wrote:
On Mar 3, 2010, at 4:46 PM, Ramesh Reddy wrote:
> Now comes to the question what we name the XML file inside the VDB
> artifact.
>
> some suggestions
>
> teiid-vdb-deployer.xml
> teiid-vdb-configuration.xml
As long as we put the file in the META-INF folder, seems like
"configuration.xml" is sufficient.
Thanks,
JPAV
4:58 p.m.
New subject: [teiid-designer-dev] Proposed Schema for "ConfigurationInfo.def" file
On Mar 2, 2010, at 5:43 PM, Ramesh Reddy wrote:
Based discussions from another thread here is the another revision
of
the schema. Let me if this works..
From the tooling standpoint, I think we're pretty happy with this
version.
Thanks,
JPAV
5:08 p.m.
The schema and related JAXB classes are available in the Teiid client
JAR. So, if tooling wants to use those it can rather than duplicating.
Ramesh..
On Wed, 2010-03-03 at 16:58 -0600, John Verhaeg wrote:
On Mar 2, 2010, at 5:43 PM, Ramesh Reddy wrote:
> Based discussions from another thread here is the another revision of
> the schema. Let me if this works..
From the tooling standpoint, I think we're pretty happy with this version.
Thanks,
JPAV
5415
days inactive
5446
days old
20 comments
4 participants
participants (4)
-
John Verhaeg -
Ken Johnson -
Ramesh Reddy -
Ted Jones