river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <ge...@cox.net>
Subject Re: RiverClassLoaderSpi
Date Fri, 26 Oct 2012 15:41:28 GMT
I believe the patches shown there have been put in place now have they not?  Peter was working
on this a while back, and I thought that as least one person had put the changes into place
for his private code base so that he could now trivially integrate with a JavaEE container.

What I did was all that was strictly necessary to make it possible to replace the use of RMIClassLoaderSPI
with similar behavior, but that behavior could be plugged in at runtime, with appropriate
permissions.  Since I just patched over the present logic, it doesn't change how things work,
just where the software that processes the "events" can come from.

It can also allow the "annotation" to change use/behavior on JVMs which share a common behavior
plugged in with this facility.  This implies that things as "elegant" as Maven, could actually
be used for codebase resolution.

Gregg Wonderly

On Oct 26, 2012, at 7:58 AM, Simon IJskes - QCG <simon@qcg.nl> wrote:

> On 26-10-12 01:07, Simon IJskes - QCG wrote:
>> On 26-10-12 00:56, Greg Trasuk wrote:
>>> 
>>> Isn't there already java.rmi.server.RMIClassLoaderSpi that
>>> net.jini.loader.pref.PreferredClassProvider implements?  What would a
>>> River-specific provider interface add?
>> 
>> RMIClassLoaderSpi is used for instance in java webstart (javafx) to
>> initialize if with the default implementation. I see no way to
> .............it
>> circumvent this. I havent looked in detail to RIVER-336 [1] but it looks
>> like it asked for a similar seperation possibility. Maybe other
>> solutions can be made pluggable?
>> 
>> [1] https://issues.apache.org/jira/browse/RIVER-336
>> 
> 
> Anybody?
> 


Mime
View raw message