Actually it is even worse. Since RMIClassProvider API is stateless the client has only one list of URLs at a time...
Regards, On Sunday, March 09, 2014 10:54:57 PM Michał Kłeczek wrote: > The whole point of my example is that the client has no knowledge of Util > interface - it is simply not interested in it. > > The problem is not that the client cannot plug-in RMIClassProvider > dynamically. It is just that with current format of codebase annotation the > client cannot do anything. It simply does not have enough data to decide > what to do - just two lists of URLs without any dependency information > encoded. > > Regards, > > On Sunday, March 09, 2014 02:33:03 PM Gregg Wonderly wrote: > > All you have to provide in the client is a class loading implementation > > that knows about Util and pins it into a parent class loader from the > > class loaders that proxies load. I netbeans, this happens because meta > > data declares that such a relationship exists. In OSGi, this happens > > because meta data declares that such a relationship exists. All you have > > to do, is create meta data that specifies that such a relationship > > exists, and then plug in a River-336 compatible class loading > > implementation in your client. > > > > My point is no that River-336 provides the answer, but rather it provides > > a > > mechanism that an application can use. Not every application has such a > > need, and not every known implementation uses the same model. Thus, there > > isn’t a single answer that can exist ahead of time. > > > > If you want to use OSGi, plug it in. If you want to use Netbeans, plug it > > in. If you want to use both at the same time, work it out and plug it > > in. > > > > There is room for a single standard to eventually win. But, there isn’t > > a > > > > single standard that is standing alone right now that I see. > > > > Gregg Wonderly -- Michał Kłeczek XPro Sp. z o. o. ul. Borowskiego 2 03-475 Warszawa Polska -- Michał Kłeczek XPro Sp. z o. o. ul. Borowskiego 2 03-475 Warszawa Polska
