You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "David Jencks (JIRA)" <ji...@apache.org> on 2009/05/28 21:47:45 UTC

[jira] Updated: (GERONIMO-2246) Why resource-env-ref:admin-object-module?

     [ https://issues.apache.org/jira/browse/GERONIMO-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Jencks updated GERONIMO-2246:
-----------------------------------

    Fix Version/s:     (was: 2.2)
                   Wish List
         Assignee:     (was: David Jencks)

Although I think you are right that its redundant I'm really not inclined to remove the ability to interpret historical xml just because there's another way to do it.  Maybe if/when we move to jaxb to read plans would be a better time to revisit this.

> Why resource-env-ref:admin-object-module?
> -----------------------------------------
>
>                 Key: GERONIMO-2246
>                 URL: https://issues.apache.org/jira/browse/GERONIMO-2246
>             Project: Geronimo
>          Issue Type: Bug
>      Security Level: public(Regular issues) 
>          Components: connector, deployment
>    Affects Versions: 1.1, 2.0.x, 2.1, 2.1.1
>            Reporter: Aaron Mulder
>             Fix For: Wish List
>
>
> When mapping resource-env-refs (or a message-destination), It doesn't seem like admin-object-module is necessary.  It can be provided alongside admin-object-name in order to narrow the search down to a specific module within an EAR (the current EAR or any EAR in the dependency graph that has a module with that name).  However, if you need to specify a module, you can just use:
> <pattern>
>     <module>jms.rar</module>
>     <name>foo</name>
> </pattern>
> Instead of using admin-object-module and admin-object-name.  It doesn't seem like this redundancy gets us anything, so I'd rather remove admin-object-module and make admin-object-link work like any other resource/EJB link (name only -- use "pattern" for more complex stuff).
> If we proceed, I don't think we necessarily want to remove it in 1.1.x (breaking backward compatibility with 1.1.0) -- we can remove it in 1.2 and remove message-destination-link at the same time.
> David J, could you comment?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.