Peter,
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
causes.
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
components:
a) Phoenix
IMHO _any_ River service container should be _based_ on Phoenix. It has
capabilities not available in most other containers (JEE containers
specifically):
- 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... :-)
Regards,
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
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
