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 Tue, 04 Mar 2014 17:18:36 GMT

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

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

ClassLoader complexity and dependency management is something that was 
understood long time ago and solved several times (OSGI or NetBeans module 
system come to mind first).
To be honest I really do not understand why River community does not make use 
of existing solutions and tries to either reinvent the wheel or live with 
broken architecture and develop ad-hoc fixes not really addressing the root 

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

We are discussing service packaging and container implementation while we have 
_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 
simple service composition - as I've shown in my example.
c) we have a whole lot of concurrency issues in the implementation from which 
a lot were fixed by Peter and it is still not decided whether it is worth 
incorporating those fixes!!!.

On the other hand I hear voices that we should drop/deprecate some of River 
a) Phoenix
IMHO _any_ River service container should be _based_ on Phoenix. It has 
capabilities not available in most other containers (JEE containers 
- ability to deploy/execute components in _isolation_ (different virtual 
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 service is 
actually implemented only as a client proxy wrapping other services (no server 
side logic). I would even say we are missing some (simple but important) 
services to make it possible:
- CodeRepository service (I remember one implementation created some time ago)
- ProxyTrustDelegate service (that would allow a service to delegate proxy 
verification logic to another service)

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


On Tuesday, March 04, 2014 09:17:12 PM Peter wrote:
> Thanks Michal,
> Welcome to ClassLoader complexity.
> 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.
> This is an important first step.
> Basically Service API, are interfaces and classes that implementations use
> to communicate with each other.  In this case, because your Util interface
> needs to be shared, it correlates to service api.
> 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)
> To do so however requires new conventions for codebase annotations.
> One restriction is that service api cannot be changed after deployment.
> 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.
> Cheers,
> Peter.

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