river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: RiverClassLoaderSPI
Date Thu, 08 Nov 2012 23:31:44 GMT
Simon IJskes - QCG wrote:
> On 08-11-12 13:40, Peter Firmstone wrote:
>
>> Yes, but lets play around with it in skunk.  Dan's made some valid
>
> Indeed Dan has made valid remarks, but i really dont like skunk. Tom 
> suggested sub projects once. I did not see any benefits at that time. 
> But i think it might be helpful right now.
>
> We could use the subprojects as 'clients' to the core, and allow 
> requirements of these subprojects drive the modifications of the core.
>
> We can decide whatever status a subproject will have, and we do not 
> make them heavyweight. Just an extra jar, an extra libs and an extra 
> src in a directory together.
>
> I'm thinking about osgi, wan, internet, jmx transports etc. We treat 
> the sub projects as first class citizens, and do proper release 
> management on them. Just not that often.
>
> Am i still thinking too grandiose Dan?
>
> Gr. Simon
>
>
Ok, because it's small I think we can consider it, can you provide the 
hooks to load different providers?  The non default providers themselves 
can be a subproject.  We need to carefully consider security since we're 
making it possible for downloaded code to resolve classes.

My SecurityManager and policy providers were developed in skunk, then 
merged.  URI changes were made in trunk, although this was a big change 
semantically, the code footprint is small.  For large changes to 
foundation code we need skunk, not everything can be bolted on or 
plugged in.

Cheers,

Peter.

Mime
View raw message