On Wed, Dec 18, 2024 at 9:09 AM David Lloyd <david.ll...@redhat.com> wrote:
> On Wed, Dec 18, 2024 at 3:55 AM Alan Bateman <alan.bate...@oracle.com> > wrote: > >> Finally, just to say that your prototype addProvides doesn't specify any >> validation. It looks like it can be used to add any random class and >> implementation class. If a method were to be added then it would minimally >> need to check that the implementation class is in the module and that it >> extends the service class. >> > > The services are actually internally registered by class *name* rather > than class object, which seems weaker than necessary (maybe to avoid a > strong class reference?) and might allow any validation to be tricked or > bypassed somehow: there's only an imperfect guarantee that the service and > provider will actually be the *same* as what was registered. This seems to > undermine any validation, though we could just do it anyway I suppose. > Actually after further analysis I've found that I'm incorrect about this, in part: the module does seem to get recorded and its class loader is then used to locate the provider. So, this validation would not realistically be bypassable, and dropping the `Module` argument would not be useful. That said, I would be inclined to drop the restriction that the provider module (or class) or the server module (or class) must be located within the layer. It would be the layer catalog which is updated, and this would allow layers to locate services outside of their parent hierarchy, which is basically the point of adding the API to begin with. -- - DML • he/him
