<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Dec 18, 2024 at 9:09 AM David Lloyd <<a href="mailto:david.lloyd@redhat.com">david.lloyd@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif"><span style="font-family:Arial,Helvetica,sans-serif">On Wed, Dec 18, 2024 at 3:55 AM Alan Bateman <</span><a href="mailto:alan.bateman@oracle.com" target="_blank" style="font-family:Arial,Helvetica,sans-serif">alan.bateman@oracle.com</a><span style="font-family:Arial,Helvetica,sans-serif">> wrote:</span></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>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.<br></div></blockquote><div><br></div><div><div style="font-family:arial,helvetica,sans-serif"><span class="gmail_default" style="font-family:arial,helvetica,sans-serif">T</span>he 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.</div></div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">- DML • he/him<br></div></div></div>