Hmm... I don't think it is an implementation detail - codebase
annotations must be understood by every client - so the format becomes a
part of the spec.
For example Maven based naming
(groupId:artifactId:version:classifier:version) is incompatible with
Eclipse p2 (MANIFEST.MF OSGI metadata - in practice I would say it would
be bundleId:version or bundleId:version-range).
Additionally - just name/version based artifact identification is not
enough - I would much rather see something like "strong names" from .NET
where signature is part of the identifier.
Besides... Maven based provisionning requires every party to agree on a
set of common repositories.
Ideal solution would be to decouple the client from the "how" code is
downloaded. Not having this is one of the problems with current River
architecture - all have to have http and httpmd URL handlers installed.
This decoupling could be achieved if codebase annotations were objects -
that was my proposal discussed some time ago. It allows a service to
provide clients with "code downloaders" as annotations.
Regards,
Michal
W dniu 2014-02-25 18:00, Dennis Reedy pisze:
Michal,
I agree on not standardizing on Maven (or OBR) at this point. I don't
understand why you are against Maven based provisioning (Aether), its
really an implementation detail.
My question is really whether River should support the notion of artifacts
(retrievable from some sort of repository), or just stick with resolved
artifacts in the SAR. There are advantages of having an artifact based
codebase annotation.
Regards
Dennis
On Tue, Feb 25, 2014 at 11:48 AM, Michal Kleczek <michal.klec...@xpro.biz>wrote:
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
--
Michał Kłeczek
XPro Quality Matters
http://www.xpro.biz
