You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "Aaron Mulder (JIRA)" <de...@geronimo.apache.org> on 2006/04/14 23:37:00 UTC

[jira] Created: (GERONIMO-1849) Attribute Manager broken WRT Reference

Attribute Manager broken WRT Reference
--------------------------------------

         Key: GERONIMO-1849
         URL: http://issues.apache.org/jira/browse/GERONIMO-1849
     Project: Geronimo
        Type: Bug
    Security: public (Regular issues) 
  Components: kernel  
    Versions: 1.1    
    Reporter: Aaron Mulder
    Priority: Blocker
     Fix For: 1.1


Discovered for a new GBean generated at runtime with a reference.  For a reference to ServerInfo (a single-valued reference, which can use the exact abstract name of the target), you get this:

AbstractName used as the value of the reference:

geronimo/j2ee-system/1.1-SNAPSHOT/car?ServiceModule=geronimo/j2ee-system/1.1-SNAPSHOT/car,j2eeType=GBean,name=ServerInfo

Reference to ServerInfo written into the GBean definition in config.xml:

      <reference name="ServerInfo">
          <pattern>
              <groupId>geronimo</groupId>
              <artifactId>j2ee-system</artifactId>
              <version>1.1-SNAPSHOT</version>
              <type>car</type>
              <name>ServerInfo</name>
geronimo/j2ee-system/1.1-SNAPSHOT/car?ServiceModule=geronimo/j2ee-system/1.1-SNAPSHOT/car,j2eeType=GBean,name=ServerInfo#</pattern>
      </reference>

Note these things:
 - The AbstractNameQuery is written as plain text after the </name> with a # on the end
 - The pattern chunks do not hold the ServiceModule (though it could be calculated) or j2eeType (which would just be lost), so they cannot be used to reconstruct the full AbstractName / AbstractNameQuery / Pattern
 - The code also looks for a "module" in the AbstractName to write a <module> element in the pattern, but there is not "module" in the AbstractName in question (should that be the ServiceModule?)
 - Many abstract names hold significantly more components than the ServiceName does due to JSR-77 requirements (application name, parent component name, parent component type, etc.), so it's not clear that any hardcoded set of elements can capture the variety of possible abstract names
 - The schema at modules/system/src/schema/local-attribute.xsd bears little relation to the syntax currently used in the generated config.xml file, which is not validated when written or read


To reproduce this, start Geronimo, go to the "Keystores" portlet in the console, click "New Keystore", enter a file name and password, submit it, and wait a few seconds for it to be written to config.xml (there will be a new FileKeystoreInstance GBean in the j2ee-security configuration).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Resolved: (GERONIMO-1849) Attribute Manager broken WRT Reference

Posted by "Aaron Mulder (JIRA)" <de...@geronimo.apache.org>.
     [ http://issues.apache.org/jira/browse/GERONIMO-1849?page=all ]
     
Aaron Mulder resolved GERONIMO-1849:
------------------------------------

    Resolution: Fixed
     Assign To: Aaron Mulder

I think we fixed the most important parts of this (removing the junk text from the XML file, making the schema match the file, and validating on load).

It is still not possible to fully recreate an abstract name from the elements provided, but "knock on wood" they should be enough to uniquely identify a target.

In the future as we review the syntax for patterns and object references in general, we'll just have to remember to review the config.xml syntax accordingly.

> Attribute Manager broken WRT Reference
> --------------------------------------
>
>          Key: GERONIMO-1849
>          URL: http://issues.apache.org/jira/browse/GERONIMO-1849
>      Project: Geronimo
>         Type: Bug
>     Security: public(Regular issues) 
>   Components: kernel
>     Versions: 1.1
>     Reporter: Aaron Mulder
>     Assignee: Aaron Mulder
>     Priority: Blocker
>      Fix For: 1.1

>
> Discovered for a new GBean generated at runtime with a reference.  For a reference to ServerInfo (a single-valued reference, which can use the exact abstract name of the target), you get this:
> AbstractName used as the value of the reference:
> geronimo/j2ee-system/1.1-SNAPSHOT/car?ServiceModule=geronimo/j2ee-system/1.1-SNAPSHOT/car,j2eeType=GBean,name=ServerInfo
> Reference to ServerInfo written into the GBean definition in config.xml:
>       <reference name="ServerInfo">
>           <pattern>
>               <groupId>geronimo</groupId>
>               <artifactId>j2ee-system</artifactId>
>               <version>1.1-SNAPSHOT</version>
>               <type>car</type>
>               <name>ServerInfo</name>
> geronimo/j2ee-system/1.1-SNAPSHOT/car?ServiceModule=geronimo/j2ee-system/1.1-SNAPSHOT/car,j2eeType=GBean,name=ServerInfo#</pattern>
>       </reference>
> Note these things:
>  - The AbstractNameQuery is written as plain text after the </name> with a # on the end
>  - The pattern chunks do not hold the ServiceModule (though it could be calculated) or j2eeType (which would just be lost), so they cannot be used to reconstruct the full AbstractName / AbstractNameQuery / Pattern
>  - The code also looks for a "module" in the AbstractName to write a <module> element in the pattern, but there is not "module" in the AbstractName in question (should that be the ServiceModule?)
>  - Many abstract names hold significantly more components than the ServiceName does due to JSR-77 requirements (application name, parent component name, parent component type, etc.), so it's not clear that any hardcoded set of elements can capture the variety of possible abstract names
>  - The schema at modules/system/src/schema/local-attribute.xsd bears little relation to the syntax currently used in the generated config.xml file, which is not validated when written or read
> To reproduce this, start Geronimo, go to the "Keystores" portlet in the console, click "New Keystore", enter a file name and password, submit it, and wait a few seconds for it to be written to config.xml (there will be a new FileKeystoreInstance GBean in the j2ee-security configuration).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (GERONIMO-1849) Attribute Manager broken WRT Reference

Posted by "David Jencks (JIRA)" <de...@geronimo.apache.org>.
    [ http://issues.apache.org/jira/browse/GERONIMO-1849?page=comments#action_12414295 ] 

David Jencks commented on GERONIMO-1849:
----------------------------------------

The actual broken part of including the pattern name in the reference was fixed in rev 374819.  I think we will have to worry about the other stuff after 1.1.

> Attribute Manager broken WRT Reference
> --------------------------------------
>
>          Key: GERONIMO-1849
>          URL: http://issues.apache.org/jira/browse/GERONIMO-1849
>      Project: Geronimo
>         Type: Bug
>     Security: public(Regular issues) 
>   Components: kernel
>     Versions: 1.1
>     Reporter: Aaron Mulder
>     Priority: Blocker
>      Fix For: 1.1

>
> Discovered for a new GBean generated at runtime with a reference.  For a reference to ServerInfo (a single-valued reference, which can use the exact abstract name of the target), you get this:
> AbstractName used as the value of the reference:
> geronimo/j2ee-system/1.1-SNAPSHOT/car?ServiceModule=geronimo/j2ee-system/1.1-SNAPSHOT/car,j2eeType=GBean,name=ServerInfo
> Reference to ServerInfo written into the GBean definition in config.xml:
>       <reference name="ServerInfo">
>           <pattern>
>               <groupId>geronimo</groupId>
>               <artifactId>j2ee-system</artifactId>
>               <version>1.1-SNAPSHOT</version>
>               <type>car</type>
>               <name>ServerInfo</name>
> geronimo/j2ee-system/1.1-SNAPSHOT/car?ServiceModule=geronimo/j2ee-system/1.1-SNAPSHOT/car,j2eeType=GBean,name=ServerInfo#</pattern>
>       </reference>
> Note these things:
>  - The AbstractNameQuery is written as plain text after the </name> with a # on the end
>  - The pattern chunks do not hold the ServiceModule (though it could be calculated) or j2eeType (which would just be lost), so they cannot be used to reconstruct the full AbstractName / AbstractNameQuery / Pattern
>  - The code also looks for a "module" in the AbstractName to write a <module> element in the pattern, but there is not "module" in the AbstractName in question (should that be the ServiceModule?)
>  - Many abstract names hold significantly more components than the ServiceName does due to JSR-77 requirements (application name, parent component name, parent component type, etc.), so it's not clear that any hardcoded set of elements can capture the variety of possible abstract names
>  - The schema at modules/system/src/schema/local-attribute.xsd bears little relation to the syntax currently used in the generated config.xml file, which is not validated when written or read
> To reproduce this, start Geronimo, go to the "Keystores" portlet in the console, click "New Keystore", enter a file name and password, submit it, and wait a few seconds for it to be written to config.xml (there will be a new FileKeystoreInstance GBean in the j2ee-security configuration).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira