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.
thanks
david jencks
thanks
david jencks
On May 23, 2006, at 7:55 PM, Dain Sundstrom wrote:
I finished the patch for GERONIMO-1960 (http://issues.apache.org/
jira/browse/GERONIMO-1960), but I think it may be destabilizing
and should be move to 1.1.1.
I added a verify method to Deployment context which is called from
getConfigurationData(). This method verifies the references and
dependencies on can be resolved. I only try to resolve
dependencies and single valued references. Further, only
unresolved reference patterns are resolved, under the assumption
that the deployer created a resolved pattern correctly. We can
not absolute references to beans in external modules.
A couple of the client plans threw exceptions so I had to patch
them also, which is why I am concerned. The client-security has
unnecessary and possibly incorrect module declarations and the
client-corba plan has a dependency on SecurityService which can't
be resolved since there is no dependency on client-security. I
removed the former and commented out the latter. I am not sure if
we need the dependency on SecurityService in client-corba, and if
so, I'm not sure if we can add a dependency from client-corba to
client-security. David Jencks any help here would be appreciated.
Anyway, I don't think this is issue actually a blocker issue, and
think we can safely move it to 1.1.1 (or 1.2 if my 1.1.1 proposal
flops).
-dain
