On May 23, 2006, at 11:26 PM, David Jencks wrote:
On May 23, 2006, at 11:04 PM, David Jencks wrote:
+1 on excluding this from 1.1. I agree it's not a blocker.
I think client-corba needs a dependency on client-security, I
thought it was there. I'll try to investigate on the plane tomorrow.
I expected you to fix this by modifying the ServiceConfigBuilder
to check that the gbean reference was satisfied in the ancestor
set when it is reading the xml. This is what the other builders
do for e.g. resource-refs, and I think it would be simple and non-
invasive. However, in any case I don't think this is a
blocker.... the worst that can happen is that you get an error
later rather than sooner, you get essentially the same effect
either way.
Umm, re this comment, I should think before writing :-)
A moment's further thought reminded me that the reason we can check
e.g. resource-refs when we process them is that we have a multistep
process in the j2ee module builders and when we resolve the
references we already know all the gbeans. This is not the case
for service modules so the verify method you added or some other
way of introducing 2 steps would be necessary.
Bingo! It took me a few tries to get this patch right. My first
attempt worked just as you suggested above (verify as reading the
xml), and I ran into the problem where beans were referring to stuff
further down in the file. My second attempt was to modify the
ServiceConfigBuilder to verify after all beans had been added, but I
ran into the problem where beans were referring to stuff in modules
that hadn't been processed yet. My final attempt was to put the
verify method in DeploymentContext and set it to verify when we call
getConfigurationData(). Since this method is only called when the
deployment is complete, all gbeans should be available. The patch
does appear to work, but complexity of writing it made me nervous
about putting it into 1.1.
-dain
