yes and it was done by design to avoid loading an entire domain.xml when you only care about one config (yours).
what you need to do is not fix it but enhance it so :
1. you have control which config is parsed (I think it's already in place but verify).
2. introduce a mode where we indeed load all configs (for the DAS maybe).
3. introduce a mode where we bring extra config on demand (should not be hard to tell the stax parser to re-parse a particular config and add it to the domain instance).
I believe we must have 1 and 2, 3 is an extra credit.
jerome
On Mar 16, 2010, at 12:27 AM, Byron Nevins wrote:
> I finally figured out why V3 will always produce a list of one and only one config item in the list that an injected "Configs" returns. All other configs are ignored. Interestingly enough -- a stock domain.xml has more than one config element in it. The extras are vestigial and are not parsed. They are not accessible at runtime.
>
> To get clustering going we need to fix this right away since we'll need to support many config elements. It looks like it will not be a big deal to fix.
>
> Jerome -- are you going to do this or shall I?
>
> For details look at [1]
> [1] http://wiki.glassfish.java.net/Wiki.jsp?page=3.1BasicClustering
>
>
> --
> Byron Nevins - Sun Microsystems, Inc.
> Home: 650-359-1290
> Cell: 650-784-4123
> Sierra: 209-295-2188
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>