Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
Received-SPF: pass (athena.apache.org: domain of
 SRS0=b5fI3B=YG=wonderly.org=gregg@yourhostingaccount.com designates
 65.254.253.145 as permitted sender)
From: Gregg Wonderly <gregg@wonderly.org>
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Subject: Re: River-436 - need some explanation of preferred class provider
Message-Id: <41B88C5E-EC9C-43B4-8DA0-935720F0748F@wonderly.org>
Date: Tue, 4 Mar 2014 22:24:33 -0600
References: <5313816B.9030703@xpro.biz>
 <CAL2DxM6nvbQbbswh=s1fnT126dgMV9Pa5zCNAe7xsGB8kCWtYw@mail.gmail.com>
 <1393931832.5611.12.camel@Nokia-N900> <4794484.jaC2QK7xTF@mkleczek-laptop>
In-Reply-To: <4794484.jaC2QK7xTF@mkleczek-laptop>
To: "dev@river.apache.org" <dev@river.apache.org>
Sender: Gregg Wonderly <gregg@wonderly.org>


> On Mar 4, 2014, at 11:18 AM, Micha=C5=82 K=C5=82eczek <michal.kleczek@xpro=
.biz> wrote:
>=20
> ClassLoader complexity and dependency management is something that was=20
> understood long time ago and solved several times (OSGI or NetBeans module=
=20
> system come to mind first).

First thing to understand is that these two along with others each have a sp=
ecific focused problem that they are addressing.

Netbeans is about isolation, not sharing.

OSGi is about versioning and isolation based on versioning.

OSGi supporters, proponents and developers have fought a long to try and cre=
ate a remoting specification which worked with what they already had.

> To be honest I really do not understand why River community does not make u=
se=20
> of existing solutions and tries to either reinvent the wheel or live with=20=

> broken architecture and develop ad-hoc fixes not really addressing the roo=
t=20
> causes.
>=20
> It may sound harsh but for me it looks like NIH syndrome.

It's certainly possible to feel like that's the way it is, but remember that=
   RMI and JRMP existed before these did.

Is it a great and perfect thing?  By no means would I say that. =20

But, there are good things amongst all if these and rather then mash togethe=
r all of it into a new thing, why can't we just provide pluggable interfaces=
 and implementations that let them all coexist?

There are, in my mind, some pretty powerful abstractions that should make it=
 possible.

Gregg

>=20
> We are discussing service packaging and container implementation while we h=
ave=20
> _basic_ stuff not working:
> a) we have a huge security issue with allowing untrusted code to execute
> b) we have a class loading issue that makes it impossible to use River for=
=20
> simple service composition - as I've shown in my example.
> c) we have a whole lot of concurrency issues in the implementation from wh=
ich=20
> a lot were fixed by Peter and it is still not decided whether it is worth=20=

> incorporating those fixes!!!.
>=20
> On the other hand I hear voices that we should drop/deprecate some of Rive=
r=20
> components:
> a) Phoenix
> IMHO _any_ River service container should be _based_ on Phoenix. It has=20=

> capabilities not available in most other containers (JEE containers=20
> specifically):
> - ability to deploy/execute components in _isolation_ (different virtual=20=

> machines - instantiated on demand)
> - watchdog functionality
> - easily accessible API (since Phoenix _is_ a River service)
> - on-demand component activation (which I think is underestimated - see be=
low)
>=20
> b) Norm/Mercury/Fiddler
> These are crucial for creating activatable sevices.
> Activation is important in service composition scenarios where a service i=
s=20
> actually implemented only as a client proxy wrapping other services (no se=
rver=20
> side logic). I would even say we are missing some (simple but important)=20=

> services to make it possible:
> - CodeRepository service (I remember one implementation created some time a=
go)
> - ProxyTrustDelegate service (that would allow a service to delegate proxy=
=20
> verification logic to another service)
>=20
> Just from the top of my head... :-)
>=20
> Regards,
>=20
>> On Tuesday, March 04, 2014 09:17:12 PM Peter wrote:
>> Thanks Michal,
>>=20
>> Welcome to ClassLoader complexity.
>>=20
>> We've more recently encouraged the separation of Service API, from
>> implementation at the development stage, instead of relying on tools like=

>> classdep.  Rio, uses these conventions.
>>=20
>> This is an important first step.
>>=20
>> Basically Service API, are interfaces and classes that implementations us=
e
>> to communicate with each other.  In this case, because your Util interfac=
e
>> needs to be shared, it correlates to service api.
>>=20
>> If all application code was loaded into URLClassLoader instances as
>> suggested previously some time ago by Nic on this list, then we could
>> ensure that all Service API is loaded into it's own ProtectionDomain in t=
he
>> main application ClassLoader (a URLClassLoader instance that proxy's use a=
s
>> their parent loader)
>>=20
>> To do so however requires new conventions for codebase annotations.
>>=20
>> One restriction is that service api cannot be changed after deployment.
>>=20
>> We could allow Service API to be loaded on demand after deployment, if it=

>> doesn't already exist at the client, but again it cannot be changed after=

>> deployment, only added to.
>>=20
>> Cheers,
>>=20
>> Peter.
>=20
> --=20
> Micha=C5=82 K=C5=82eczek
> XPro Sp. z o. o.
> ul. Borowskiego 2
> 03-475 Warszawa
> Polska
> <Micha=C5=82 K=C5=82eczek (XPro).vcf>