Sahoo wrote:
> Richard S. Hall wrote:
>> If that is the case, then I am in agreement with you, it doesn't make
>> sense that it could not load private classes from the bundle.
>>
>> Still, I do have some concerns about loading from exported packages.
>> Does this mean that it uses DynamicImport-Package or is it just
>> analyzing the bundle export metadata?
> DynamicImport-Package.
Hmm. Well, that is not what I would recommend, because this will limit
what it can see, for example, it could not deal with two different
versions of the same package since this approach actually creates a wire
to the exporter. Although this might not be a current use case, you
never know about future use cases. Further, this means that the extender
becomes dependent upon the exporter so if the exporter is uninstalled or
updated and then refreshed, then the extender bundle will have to be
refreshed too.
Following the extender approach, you could probe for exported packages
too and then delegate to Bundle.loadClass() based on who exports what,
this won't create a wire to the exporting bundle.
Just some thoughts.
-> richard
>
> Thanks,
> Sahoo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>