+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.
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
