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
BEGIN:VCARD
ADR;TYPE=pref;TYPE=work:;;ul. Borowskiego 2;Warszawa;;03-475;Poland
EMAIL:michal.klec...@xpro.biz
FN:Michał Kłeczek
N:Kłeczek;Michał;;;
ORG:XPro Sp. z o. o.
UID:Zp8UeLZmq5
VERSION:3.0
END:VCARD
