On Mar 12, 2008, at 10:45 AM, Jarek Gawor wrote:
2) The AdminObjectRefBuilder is always trying to process _all_
resource-env-ref entries (AdminObjectRefBuilder is just an
example in
this case). However, as things evolve (Java EE 5 -> 6) and new
resource env. types are added, it does not scale to keep updating
the
AdminObjectRefBuilder to handle these new types. So I think it
would
be nice to install a new builder that would handle these new types
only. But that would require communicating with the
AdminObjectRefBuilder and somehow telling it to ignore the new
types.
The question is, what would be the best way of doing it? Or
maybe we
need a different way of processing the DDs?
This is kind of a tricky problem and I don't know the best way to
handle it. I doubt you want to get into rewriting the entire way we
resolve resource-env-refs at this point -- let me know if you do --
so I would look into exactly what is keeping the current
AdminObjectRefBuilder from handling your new kinds of refs and
whether there is an easy way to exclude them.
Some possibilities....
- the AdminObjectRefBuilder.AdminObjectRefProcessor picks out the
annotations we will look at. If the new stuff can only be referred
to as @Resource you can have the AdminObjectRefProcessor skip the
new
kinds.
- basically the AdminObjectRefBuilder works by finding a gbean that
corresponds to the name information and type information supplied,
around line 373. We could expand the choices for how we look for
target gbeans.
- we might be able to make the NamingBuilderCollection ordered and
have the builders not try to deal with questionable items that have
already been processed.
I tried the last option. Specifically, I modified the
AdminObjectRefBuilder to ignore elements that were already added to
the jndi context map (assuming the NamingBuilderCollection would be
ordered and that my builder would execute before the
AdminObjectRefBuilder). However, since both Builders process the same
type of elements in the DDs the NamingBuilderCollection did not like
that and I got the following exception:
3:01:30,421 ERROR [ProxyCollection] Listener threw exception
java.lang.IllegalArgumentException: Duplicate builderSpecQNames in
builder set: QNameSet+([EMAIL PROTECTED]://java.sun.com/xml/ns/
javaee,
[EMAIL PROTECTED]://java.sun.com/xml/ns/j2ee) and duplicate
builderPlanQNames in builder set :
QNameSet+([EMAIL PROTECTED]://geronimo.apache.org/xml/ns/
naming-1.2)
So this option would work only if I disabled this check or returned
some other qnames for builderSpecQNames and builderPlanQNames in my
builder.
Also, I could create a new switching builder for processing the
resource-env-ref elements and have it just basically redirect the
calls to the AdminObjectRefBuilder and my builder (to avoid the above
error) and combine it with the last option you described.
<mumbles things about hoist by own petard, too clever by half, etc etc>
I think you can avoid this problem by cheating and not registering
any qnames in your builder. This might be sort of plausible since
its not the "main" builder for the qnames. However we might want to
rethink the entire collision avoidance theory altogether.
thanks
david jencks
Jarek
