river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michał Kłeczek <michal.klec...@xpro.biz>
Subject Re: River-436 - need some explanation of preferred class provider
Date Thu, 06 Mar 2014 16:16:44 GMT
I am not saying OSGI is prevented. I am saying OSGI class loading model 
_could_ be used to fix class loading issues. Because current River class 
loading is simply broken.

If you look at my example - the Wrapper service is simple and sharing only 
Wrapper interface with its client. And still it is not possible to use it!!!

As per fixing security - may I ask how it is going to be accomplished?

Also... Could you elaborate more on code dynamically generated at the server 
and how does it differ from code downloading? How lambdas change anything 
(since lambdas are only Java _language_ level constructs I really don't see 
how).

The solution to class loading issues is really simple... Use class loading 
model that is good enough :-) - hierarchical is not.

I am actually thinking about jboss-modules library. From their website:
"It implements a thread-safe, fast, and highly concurrent delegating class 
loader model, coupled to an extensible module resolution system, which combine 
to form a unique, simple and powerful system for application execution and 
distribution."

Regards,

On Thursday, March 06, 2014 07:56:13 PM Peter wrote:
> River doesn't prevent using OSGi, in fact, we are making changes to enable
> it, we also want to support Maven, but we don't currently mandate using
> either.
> 
> I'd reccomment keeping services simple and ensure you only share common
> public interfaces and classes (service api) and ensure these shared classes
> are installed locally on your clients.
> 
> As for security that will be fixed in a following release and we are making
> steps towards that.
> 
> Even for OSGi, without River, deserialisation is complex beast.
> 
> With Java 8, we'll be looking at lambda based services where code is
> dynamically generated at the server, it's an inversion of control that will
> allow much more flexibility.  In fact I'd reccommend avoiding downloaded
> code, if it can be avoided, or at least keep it simple and ensure all
> shared classes are installed locally.
> 
> If you have a solution to ClassLoader issues, I'm all ears, honestly though,
> ClassLoaders are a Java issue, we do our best to work around them, I'm not
> aware of a silver bullet.  Beware of complex ClassLoader relationships, as
> these can lead to deadlock.
> 
> Cheers,
> 
> Peter.
> 

-- 
Michał Kłeczek
XPro Sp. z o. o.
ul. Borowskiego 2
03-475 Warszawa
Polska
Mime
View raw message