10:24 a.m.
The <admin-object> and <connection-definition> elements in resource adapters
subsystem have "pool-name" attribute that looks like it isn't used for
anything, which is misleading for users.
It looks that "pool-name" attribute was intended for functionality that
wasn't
implemented. The attributes are only present in XML, and do not exist in
management model.
During resource creation the values are passed into service value objects
(ModifiableAdminObject, ModifiableConnDef), but #getPoolName() methods are not
called from anywhere.
The attributes can't be simply removed because their values are used for
resource addressing, e.g.
/subsystem=resource-adapters/.../admin-objects=test-a-o:add(...)
will produce
<admin-object ... pool-name="test-a-o"/>
so some "name" attribute is still needed.
Unless you think that this is not worth having new schema version (or the
intended functionality that requires "pool-name" attrs is planned to be
implemented), I would create new XSD schema version with "pool-name" renamed to
"name" and update the parser. I suppose the new XSD version should be 6.0,
rather than 5.1, no matter how small the change.
Also, AFAIK this change couldn't be backported to released product streams.
The issue where this was raised is https://issues.jboss.org/browse/JBEAP-15023
--
Tomas Hofman
Software Engineer, JBoss SET
Red Hat
4:38 p.m.
So basically the issue here is that the xml attribute should be called
'name' instead of 'pool-name'?
Sounds like a minor Enhancement not a major Bug. If there's much in the way
of docs out there that use pool-name then the cost of changing it (wrong
docs) may outweigh any benefit.
On Thu, Jul 19, 2018 at 9:24 AM, Tomas Hofman <thofman(a)redhat.com> wrote:
The <admin-object> and <connection-definition> elements
in resource
adapters
subsystem have "pool-name" attribute that looks like it isn't used for
anything, which is misleading for users.
It looks that "pool-name" attribute was intended for functionality that
wasn't
implemented. The attributes are only present in XML, and do not exist in
management model.
During resource creation the values are passed into service value objects
(ModifiableAdminObject, ModifiableConnDef), but #getPoolName() methods are
not
called from anywhere.
The attributes can't be simply removed because their values are used for
resource addressing, e.g.
/subsystem=resource-adapters/.../admin-objects=test-a-o:add(...)
will produce
<admin-object ... pool-name="test-a-o"/>
so some "name" attribute is still needed.
Unless you think that this is not worth having new schema version (or the
intended functionality that requires "pool-name" attrs is planned to be
implemented), I would create new XSD schema version with "pool-name"
renamed to
"name" and update the parser. I suppose the new XSD version should be 6.0,
rather than 5.1, no matter how small the change.
Also, AFAIK this change couldn't be backported to released product streams.
The issue where this was raised is https://issues.jboss.org/
browse/JBEAP-15023
--
Tomas Hofman
Software Engineer, JBoss SET
Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
4:32 a.m.
Yes, that's what I believe should be done.
Adding also Tomasz and Tom :).
I'm yet to asses the impact on documentation, by my feeling from my initial
investigation was that I didn't found very many documents dealing with this.
Am I correct in thinking that if the new parser is able to parse the old config
version, no other migration work is needed?
Tomas
On 19/07/18 22:38, Brian Stansberry wrote:
So basically the issue here is that the xml attribute should be
called 'name'
instead of 'pool-name'?
Sounds like a minor Enhancement not a major Bug. If there's much in the way of
docs out there that use pool-name then the cost of changing it (wrong docs) may
outweigh any benefit.
On Thu, Jul 19, 2018 at 9:24 AM, Tomas Hofman <thofman(a)redhat.com
<mailto:thofman@redhat.com>> wrote:
The <admin-object> and <connection-definition> elements in resource
adapters
subsystem have "pool-name" attribute that looks like it isn't used for
anything, which is misleading for users.
It looks that "pool-name" attribute was intended for functionality that
wasn't
implemented. The attributes are only present in XML, and do not exist in
management model.
During resource creation the values are passed into service value objects
(ModifiableAdminObject, ModifiableConnDef), but #getPoolName() methods are not
called from anywhere.
The attributes can't be simply removed because their values are used for
resource addressing, e.g.
/subsystem=resource-adapters/.../admin-objects=test-a-o:add(...)
will produce
<admin-object ... pool-name="test-a-o"/>
so some "name" attribute is still needed.
Unless you think that this is not worth having new schema version (or the
intended functionality that requires "pool-name" attrs is planned to be
implemented), I would create new XSD schema version with "pool-name"
renamed to
"name" and update the parser. I suppose the new XSD version should be 6.0,
rather than 5.1, no matter how small the change.
Also, AFAIK this change couldn't be backported to released product streams.
The issue where this was raised is
https://issues.jboss.org/browse/JBEAP-15023
<https://issues.jboss.org/browse/JBEAP-15023>
--
Tomas Hofman
Software Engineer, JBoss SET
Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
<https://lists.jboss.org/mailman/listinfo/wildfly-dev>
--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
--
Tomas Hofman
Software Engineer, JBoss SET
Red Hat
4:45 p.m.
On Mon, Jul 30, 2018 at 3:32 AM, Tomas Hofman <thofman(a)redhat.com> wrote:
Yes, that's what I believe should be done.
Adding also Tomasz and Tom :).
I'm yet to asses the impact on documentation, by my feeling from my
initial investigation was that I didn't found very many documents dealing
with this.
Please check with the Teiid folks, as Teiid heavily uses this subsystem.
Am I correct in thinking that if the new parser is able to parse the old
config version, no other migration work is needed?
Right, unless Stefano wants the parser for the new schema version to be
forgiving and allow the old attribute.
Tomas
On 19/07/18 22:38, Brian Stansberry wrote:
> So basically the issue here is that the xml attribute should be called
> 'name' instead of 'pool-name'?
>
> Sounds like a minor Enhancement not a major Bug. If there's much in the
> way of docs out there that use pool-name then the cost of changing it
> (wrong docs) may outweigh any benefit.
>
> On Thu, Jul 19, 2018 at 9:24 AM, Tomas Hofman <thofman(a)redhat.com
> <mailto:thofman@redhat.com>> wrote:
>
> The <admin-object> and <connection-definition> elements in resource
> adapters
> subsystem have "pool-name" attribute that looks like it isn't used
for
> anything, which is misleading for users.
>
> It looks that "pool-name" attribute was intended for functionality
> that wasn't
> implemented. The attributes are only present in XML, and do not exist
> in
> management model.
>
> During resource creation the values are passed into service value
> objects
> (ModifiableAdminObject, ModifiableConnDef), but #getPoolName()
> methods are not
> called from anywhere.
>
> The attributes can't be simply removed because their values are used
> for
> resource addressing, e.g.
>
> /subsystem=resource-adapters/.../admin-objects=test-a-o:add(...)
>
> will produce
>
> <admin-object ... pool-name="test-a-o"/>
>
> so some "name" attribute is still needed.
>
> Unless you think that this is not worth having new schema version (or
> the
> intended functionality that requires "pool-name" attrs is planned to
> be
> implemented), I would create new XSD schema version with "pool-name"
> renamed to
> "name" and update the parser. I suppose the new XSD version should be
> 6.0,
> rather than 5.1, no matter how small the change.
>
> Also, AFAIK this change couldn't be backported to released product
> streams.
>
> The issue where this was raised is
> https://issues.jboss.org/browse/JBEAP-15023
> <https://issues.jboss.org/browse/JBEAP-15023>
>
> -- Tomas Hofman
> Software Engineer, JBoss SET
> Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>
>
>
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> Red Hat
>
--
Tomas Hofman
Software Engineer, JBoss SET
Red Hat
--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
1:38 p.m.
I guess that's Steven Hawkins?
Hello Steven,
we are considering renaming "pool-name" attribute to "name" in
<admin-object>
and <connection-definition> elements of the resource-adapters subsystem in
Wildfly/EAP.
These attributes only exists in the XML (standalone.xml, domain.xml), aren't
accessible in the management model apart from their values being used in
resource addresses. E.g.
<admin-object ... pool-name="test-a-o"/>
would be accessed in CLI as
/subsystem=resource-adapters/resource-adapter=test/admin-objects=test-a-o
So the only thing that would change is the XML attribute "pool-name" being
renamed to "name".
Do you see it as a complication from TEIID point of view, or do you know who
could answer that?
Thanks,
Tomas
On 30/07/18 22:45, Brian Stansberry wrote:
On Mon, Jul 30, 2018 at 3:32 AM, Tomas Hofman <thofman(a)redhat.com
<mailto:thofman@redhat.com>> wrote:
Yes, that's what I believe should be done.
Adding also Tomasz and Tom :).
I'm yet to asses the impact on documentation, by my feeling from my initial
investigation was that I didn't found very many documents dealing with this.
Please check with the Teiid folks, as Teiid heavily uses this subsystem.
Am I correct in thinking that if the new parser is able to parse the old
config version, no other migration work is needed?
Right, unless Stefano wants the parser for the new schema version to be
forgiving and allow the old attribute.
Tomas
On 19/07/18 22:38, Brian Stansberry wrote:
So basically the issue here is that the xml attribute should be called
'name' instead of 'pool-name'?
Sounds like a minor Enhancement not a major Bug. If there's much in the
way of docs out there that use pool-name then the cost of changing it
(wrong docs) may outweigh any benefit.
On Thu, Jul 19, 2018 at 9:24 AM, Tomas Hofman <thofman(a)redhat.com
<mailto:thofman@redhat.com> <mailto:thofman@redhat.com
<mailto:thofman@redhat.com>>> wrote:
The <admin-object> and <connection-definition> elements in
resource adapters
subsystem have "pool-name" attribute that looks like it isn't
used for
anything, which is misleading for users.
It looks that "pool-name" attribute was intended for
functionality
that wasn't
implemented. The attributes are only present in XML, and do not
exist in
management model.
During resource creation the values are passed into service value
objects
(ModifiableAdminObject, ModifiableConnDef), but #getPoolName()
methods are not
called from anywhere.
The attributes can't be simply removed because their values are
used for
resource addressing, e.g.
/subsystem=resource-adapters/.../admin-objects=test-a-o:add(...)
will produce
<admin-object ... pool-name="test-a-o"/>
so some "name" attribute is still needed.
Unless you think that this is not worth having new schema version
(or the
intended functionality that requires "pool-name" attrs is planned
to be
implemented), I would create new XSD schema version with
"pool-name"
renamed to
"name" and update the parser. I suppose the new XSD version
should
be 6.0,
rather than 5.1, no matter how small the change.
Also, AFAIK this change couldn't be backported to released product
streams.
The issue where this was raised is
https://issues.jboss.org/browse/JBEAP-15023
<https://issues.jboss.org/browse/JBEAP-15023>
<https://issues.jboss.org/browse/JBEAP-15023
<https://issues.jboss.org/browse/JBEAP-15023>>
-- Tomas Hofman
Software Engineer, JBoss SET
Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
<mailto:wildfly-dev@lists.jboss.org
<mailto:wildfly-dev@lists.jboss.org>>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
<https://lists.jboss.org/mailman/listinfo/wildfly-dev>
<https://lists.jboss.org/mailman/listinfo/wildfly-dev
<https://lists.jboss.org/mailman/listinfo/wildfly-dev>>
--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
--
Tomas Hofman
Software Engineer, JBoss SET
Red Hat
--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
--
Tomas Hofman
Software Engineer, JBoss SET
Red Hat
3:13 p.m.
Such cosmetic change would require to be documented in migration guide, i.e. effort from
Docs and QE teams, and the old schema would need to be supported too, i.e. effort from Dev
to translate old to new. And that would be the optimistic scenario, where user doesn’t
need to change configs, i.e. no Dev effort for the migration tool…
—E
On 31 Jul 2018, at 18:38, Tomas Hofman <thofman(a)redhat.com>
wrote:
I guess that's Steven Hawkins?
Hello Steven,
we are considering renaming "pool-name" attribute to "name" in
<admin-object>
and <connection-definition> elements of the resource-adapters subsystem in
Wildfly/EAP.
These attributes only exists in the XML (standalone.xml, domain.xml), aren't
accessible in the management model apart from their values being used in
resource addresses. E.g.
<admin-object ... pool-name="test-a-o"/>
would be accessed in CLI as
/subsystem=resource-adapters/resource-adapter=test/admin-objects=test-a-o
So the only thing that would change is the XML attribute "pool-name" being
renamed to "name".
Do you see it as a complication from TEIID point of view, or do you know who
could answer that?
Thanks,
Tomas
On 30/07/18 22:45, Brian Stansberry wrote:
>
>
> On Mon, Jul 30, 2018 at 3:32 AM, Tomas Hofman <thofman(a)redhat.com
<mailto:thofman@redhat.com>
> <mailto:thofman@redhat.com <mailto:thofman@redhat.com>>> wrote:
>
> Yes, that's what I believe should be done.
>
> Adding also Tomasz and Tom :).
>
> I'm yet to asses the impact on documentation, by my feeling from my initial
> investigation was that I didn't found very many documents dealing with this.
>
>
> Please check with the Teiid folks, as Teiid heavily uses this subsystem.
>
>
> Am I correct in thinking that if the new parser is able to parse the old
> config version, no other migration work is needed?
>
>
> Right, unless Stefano wants the parser for the new schema version to be
> forgiving and allow the old attribute.
>
>
> Tomas
>
> On 19/07/18 22:38, Brian Stansberry wrote:
>
> So basically the issue here is that the xml attribute should be called
> 'name' instead of 'pool-name'?
>
> Sounds like a minor Enhancement not a major Bug. If there's much in the
> way of docs out there that use pool-name then the cost of changing it
> (wrong docs) may outweigh any benefit.
>
> On Thu, Jul 19, 2018 at 9:24 AM, Tomas Hofman <thofman(a)redhat.com
<mailto:thofman@redhat.com>
> <mailto:thofman@redhat.com <mailto:thofman@redhat.com>>
<mailto:thofman@redhat.com <mailto:thofman@redhat.com>
> <mailto:thofman@redhat.com>>> wrote:
>
> The <admin-object> and <connection-definition> elements in
> resource adapters
> subsystem have "pool-name" attribute that looks like it
isn't used for
> anything, which is misleading for users.
>
> It looks that "pool-name" attribute was intended for
functionality
> that wasn't
> implemented. The attributes are only present in XML, and do not
> exist in
> management model.
>
> During resource creation the values are passed into service value
> objects
> (ModifiableAdminObject, ModifiableConnDef), but #getPoolName()
> methods are not
> called from anywhere.
>
> The attributes can't be simply removed because their values are
> used for
> resource addressing, e.g.
>
> /subsystem=resource-adapters/.../admin-objects=test-a-o:add(...)
>
> will produce
>
> <admin-object ... pool-name="test-a-o"/>
>
> so some "name" attribute is still needed.
>
> Unless you think that this is not worth having new schema version
> (or the
> intended functionality that requires "pool-name" attrs is
planned
> to be
> implemented), I would create new XSD schema version with
"pool-name"
> renamed to
> "name" and update the parser. I suppose the new XSD version
should
> be 6.0,
> rather than 5.1, no matter how small the change.
>
> Also, AFAIK this change couldn't be backported to released product
> streams.
>
> The issue where this was raised is
> https://issues.jboss.org/browse/JBEAP-15023
<https://issues.jboss.org/browse/JBEAP-15023>
> <https://issues.jboss.org/browse/JBEAP-15023
<https://issues.jboss.org/browse/JBEAP-15023>>
> <https://issues.jboss.org/browse/JBEAP-15023
<https://issues.jboss.org/browse/JBEAP-15023>
> <https://issues.jboss.org/browse/JBEAP-15023
<https://issues.jboss.org/browse/JBEAP-15023>>>
>
> -- Tomas Hofman
> Software Engineer, JBoss SET
> Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
<mailto:wildfly-dev@lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>>
> <mailto:wildfly-dev@lists.jboss.org
<mailto:wildfly-dev@lists.jboss.org> <mailto:wildfly-dev@lists.jboss.org
<mailto:wildfly-dev@lists.jboss.org>>>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
<https://lists.jboss.org/mailman/listinfo/wildfly-dev>
> <https://lists.jboss.org/mailman/listinfo/wildfly-dev
<https://lists.jboss.org/mailman/listinfo/wildfly-dev>>
> <https://lists.jboss.org/mailman/listinfo/wildfly-dev
<https://lists.jboss.org/mailman/listinfo/wildfly-dev>
> <https://lists.jboss.org/mailman/listinfo/wildfly-dev
<https://lists.jboss.org/mailman/listinfo/wildfly-dev>>>
>
>
>
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> Red Hat
>
>
> --
> Tomas Hofman
> Software Engineer, JBoss SET
> Red Hat
>
>
>
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> Red Hat
--
Tomas Hofman
Software Engineer, JBoss SET
Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
<https://lists.jboss.org/mailman/listinfo/wildfly-dev>
2094
days inactive
2106
days old
5 comments
3 participants
participants (3)
-
Brian Stansberry -
Eduardo Martins -
Tomas Hofman