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@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@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@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@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
_______________________________________________
wildfly-dev mailing list
wildfly-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev