Guys,
I don't think River should standardize or promote Maven based provisioning.
Depending on environment there are different ways of doing it. Eclipse
p2 or OBR in OSGI for example.
Regards,
Michal
W dniu 2014-02-25 10:04, Peter pisze:
So Aether standardises obtaining codebases from repository's, and there is no
dependency on Maven. It also appears to solve some big security issues.
So this begs the question, shouldn't River be adopting this approach?
Is it possible to use a repository, in place of the old http codebase server
for the new River single archive container standard?
Regards,
Peter.
----- Original message -----
On Feb 22, 2014, at 1205AM, Peter <j...@zeus.net.au> wrote:
Maven or OSGi can provision for maximum compatibility among
services and proxy's.
Maven does absolutely nothing in this regard, and in the case of
OSGi, we are dealing with a completely different class loading
animal. Provisioning systems that either use Maven's dependency
resolution (Aether) to make resolved artifacts loadable as local
jars are a different story.
Ok, sorry, wrong assumption, can you explain a little more about how
you're using Maven with Rio?
I'm not using Maven per se, I am using Aether
(https://eclipse.org/aether/). There are 2 cases here:
1. When a Cybernode is told to instantiate a service, and that service's
classpath is an artifact URL
(artifact:groupId/artifactId/version[/type[/classifier]][;repository[@repositoryId]]),
the artifact is resolved (direct and transitive dependencies) to local
jars (jars are downloaded as needed). This forms that search path for
the classloader created to load the service's implementation class.
2. When a service's codebase annotation is an artifact URL, an
implementation of a RMIClassLoaderSpi is used to resolve (along with
it's dependencies and transitive dependencies) the artifact, and install
jars locally. This step is neat, because you can have secure
repositories that require authentication before you can download jars
(the configuration for these sorts of things are in ~/.m2/settings.xml).
All of this happens for downloading, and especially before class loaders
are created and proxy classes loaded. The installed artifact location(s)
are then passed to the default RMIClassLoader provider instance (as file
based URLs), where a class loader is created.
I think this is a win from multiple points of view:
- From a performance point of view, instead of accessing classes
remotely (using http(s)), you load them from the file system.
Additionally, if you buy off on version management conventions (where
versions are immutable), once you have downloaded jars, you never have
to download them again. So you pay the price once, not every time you
have to load a service's codebase.
- You get rid of the lost codebase issue. Once the jars are installed
locally, you have them even if the repository goes down.
- We trust local code correct? If you can verify the authenticity of the
jars before you download them, verify that the download has not been
tampered with, how far does that go to address trust issues?
HTH
Dennis
Regards,
Peter.
But because these systems also can use non hirarchical
relationships among ClassLoaders, they can experience class
loading deadlock, when complex ClassLoader relationships are
employed, which parallel class loading in Java 7 tries to
address. Unfortunately parallel class loading is a naive attempt
to solve this problem, causing a memory consumption explosion
with a map based locking system, hopefully a non blocking
concurrent class loading system will be implemented in Java 9 to
fix class loading deadlock, once and for all.
Thankfully class loading relationships among service api, services
and proxy's are simple, a hierarchical parent child relationship
suffices. Only complex class relationships cause class loading
deadlock.
Regards,
Peter.
----- Original message -----
[
https://issues.apache.org/jira/browse/RIVER-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13908727#comment-13908727
]
Dennis Reedy commented on RIVER-435:
------------------------------------
I'm not sure what the real consequences are if a classloader
that loads service implementation classes and then is a parent
to a classloader then then is used to load either a discovered
service (or receives a remote object as a parameter) is.
There will be another classloader created by underlying RMI
infrastructure to load the class (since the service classloader)
will not have the other service's proxy classes in it's search
path). I may be missing something, but what are the issues
here?
Proposed Standard for Single-Archive Service Deployment
Packaging
-----------------------------------------------------------------
Key: RIVER-435
URL: https://issues.apache.org/jira/browse/RIVER-435
Project: River
Issue Type: Improvement
Components: com_sun_jini_start
Reporter: Greg Trasuk
Attachments: SingleArchiveServiceDeployment.docx,
SingleArchiveServiceDeployment.pdf
The attached document proposes the layout and general
requirements for an archive file to support simplified
"drag-and-drop" deployment for services that adhere to the
Service Starter conventions.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
--
Michał Kłeczek
XPro Quality Matters
http://www.xpro.biz
