Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
Received-SPF: pass (nike.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
From: =?utf-8?B?TWljaGHFgiBLxYJlY3plaw==?= <michal.kleczek@xpro.biz>
To: dev@river.apache.org
Subject: Re: River-436 - need some explanation of preferred class provider
Date: Tue, 04 Mar 2014 18:18:36 +0100
Message-ID: <4794484.jaC2QK7xTF@mkleczek-laptop>
Organization: XPro Sp. z o. o.
User-Agent: KMail/4.11.5 (Linux/3.11.10-7-desktop; KDE/4.11.5; x86_64; ; )
In-Reply-To: <1393931832.5611.12.camel@Nokia-N900>
References: <5313816B.9030703@xpro.biz>
 <CAL2DxM6nvbQbbswh=s1fnT126dgMV9Pa5zCNAe7xsGB8kCWtYw@mail.gmail.com>
 <1393931832.5611.12.camel@Nokia-N900>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="nextPart2600082.b2E4290KvM"
Content-Transfer-Encoding: 7Bit

--nextPart2600082.b2E4290KvM
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

Peter,

I'm going to make some more general comments here.

Actually my question was about making sure I understand how=20
PreferredClassLoader works and that there is no "magic" somewhere that =
I am=20
not aware of.

ClassLoader complexity and dependency management is something that was=20=

understood long time ago and solved several times (OSGI or NetBeans mod=
ule=20
system come to mind first).
To be honest I really do not understand why River community does not ma=
ke use=20
of existing solutions and tries to either reinvent the wheel or live wi=
th=20
broken architecture and develop ad-hoc fixes not really addressing the =
root=20
causes.

It may sound harsh but for me it looks like NIH syndrome.

We are discussing service packaging and container implementation while =
we have=20
_basic_ stuff not working:
a) we have a huge security issue with allowing untrusted code to execut=
e
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=
 which=20
a lot were fixed by Peter and it is still not decided whether it is wor=
th=20
incorporating those fixes!!!.

On the other hand I hear voices that we should drop/deprecate some of R=
iver=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 virtua=
l=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=
 below)

b) Norm/Mercury/Fiddler
These are crucial for creating activatable sevices.
Activation is important in service composition scenarios where a servic=
e is=20
actually implemented only as a client proxy wrapping other services (no=
 server=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 ti=
me ago)
- ProxyTrustDelegate service (that would allow a service to delegate pr=
oxy=20
verification logic to another service)

Just from the top of my head... :-)

Regards,

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 implementation=
s use
> to communicate with each other.  In this case, because your Util inte=
rface
> 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 the
> main application ClassLoader (a URLClassLoader instance that proxy's =
use as
> 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 deploymen=
t.
>=20
> We could allow Service API to be loaded on demand after deployment, i=
f it
> doesn't already exist at the client, but again it cannot be changed a=
fter
> deployment, only added to.
>=20
> Cheers,
>=20
> Peter.
>=20
>=20
>=20
>=20

--=20
Micha=C5=82 K=C5=82eczek
XPro Sp. z o. o.
ul. Borowskiego 2
03-475 Warszawa
Polska
--nextPart2600082.b2E4290KvM
Content-Disposition: attachment;
 filename*=UTF-8''Micha%C5%82%20K%C5%82eczek%20%28XPro%29%2Evcf
Content-Transfer-Encoding: quoted-printable
Content-Type: text/vcard; charset="utf-8";
 name*=utf-8''Micha%C5%82%20K%C5%82eczek%20%28XPro%29%2Evcf

BEGIN:VCARD=0D
ADR;TYPE=3Dpref;TYPE=3Dwork:;;ul. Borowskiego 2;Warszawa;;03-475;Poland=
=0D
EMAIL:michal.kleczek@xpro.biz=0D
FN:Micha=C5=82 K=C5=82eczek=0D
N:K=C5=82eczek;Micha=C5=82;;;=0D
ORG:XPro Sp. z o. o.=0D
UID:Zp8UeLZmq5=0D
VERSION:3.0=0D
END:VCARD=0D
=0D

--nextPart2600082.b2E4290KvM--