Dependency resolution only considers service interface artifacts?

[Dawid Loubser]

Hi,

Some strange artifact resolution behaviour is driving me crazy, and
after about three days of struggling I think I have the symptoms
figured out. First of all, if trying to deploy an opstring that
specifies only a JavaSpace (outrigger) instance to be deployed, does
not work. For example:

deployment(name: 'Standalone space')
{
groups System.getProperty(Constants.GROUPS_PROPERTY_NAME,
System.getProperty('user.name'))

artifact id: 'outrigger-impl', 'com.sun.jini:outrigger:2.1'
artifact id: 'outrigger-dl', 'com.sun.jini:outrigger:jar:dl:2.1'

service(name: 'Space')
{
interfaces {
classes 'net.jini.space.JavaSpace05'
artifact ref: 'outrigger-dl'
}
implementation(class:
'com.sun.jini.outrigger.TransientOutriggerImpl') {
artifact ref: 'outrigger-impl'
}
maintain 1
}
}

Always fails with (even though outrigger is present in my local
repository):

org.rioproject.resolver.ResolverException: Could not find artifact
com.sun.jini:outrigger:jar:2.1 in central (http://repo1.maven.org/
maven2/)
at
org.rioproject.resolver.aether.AetherResolver.getClassPathFor(AetherResolver.java:
92)
at org.rioproject.resolver.ResolverHelper.resolve(ResolverHelper.java:
99)
at org.rioproject.resolver.ResolverHelper.resolve(ResolverHelper.java:
75)
at
org.rioproject.cybernode.ServiceBeanLoader.provisionService(ServiceBeanLoader.java:
507)
at
org.rioproject.cybernode.ServiceBeanLoader.load(ServiceBeanLoader.java:
259)
at org.rioproject.cybernode.JSBDelegate$1.run(JSBDelegate.java:534)


I don't fully understand the artifact resolution yet, but here is my
take on it: If, in addition to my space, I deploy a number of workers
(via something like:)

service(name: 'Worker')
{
implementation(class: "foo.bar.Worker") {
artifact ref: 'worker-impl'
}

association(type: "requires",
serviceType: JavaSpace05.name,
property: "javaSpace", name: "Space")

maintain 1
}

The space does still not deploy. The POM for the maven artifact
'worker-impl' in this case, does have a reference to the Rio
repository (that hosts outrigger) but it is ignored. However, as soon
as I deploy something that exposes an interface, e.g.:

service(name: 'Master')
{
interfaces {
classes 'org.rioproject.examples.workflow.Master'
artifact ref: 'master-dl'
}

implementation(class:
"org.rioproject.examples.workflow.MasterImpl") {
artifact ref: 'master-impl'
}

association(type: "requires",
serviceType: JavaSpace05.name,
property: "javaSpace", name: "Space")

maintain 1
}

where the POM for the artifact used in the 'interfaces' section -
'master-dl' - refers to the Rio Maven Repo, then the space deploys
fine. Even if I modify the above, and simply comment out the
'interfaces' section (but still launching the component), dependency
resolution for outrigger (and I suspect anything similar) again does
not work. In all cases, the declarations of the artifacts in the
deployment are left intact, i.e. even though they are not used, they
are still defined as children of the deployment.

This is very very subtle and non-intuitive, it seems that dependency
resolution (for unrelated services, e.g. such as for Outrigger) is
performed solely based on the POMs of artifacts containing the
interfaces that are exposed? I would have expected all declared
artifacts to have been taken into account, and not just the ones
actually used for exposed interfaces.

If I am missing some other mechanism to specify this, I would much
appreciate some guidance :-) This is on Rio 5.0-SNAPSHOT, of course.
This problem can easily be replicated by taking the standard Rio
workflow example opstring, and simply commenting out the Master
service (leaving the worker and space intact).

regards,
Dawid

[Dennis Reedy]

This issue is similar to the testing issue I'm working through where the artifact for com.sun.jini:reggie-dl is not found. The key message here is:

> org.rioproject.resolver.ResolverException: Could not find artifact com.sun.jini:outrigger:jar:2.1 in central (http://repo1.maven.org/maven2/)

Although the artifact exists on your local file system, the underlying resolver sees it and wants to verify that the cached artifact does not need to be updated. A better explanation for this can be found here:

http://dev.eclipse.org/mhonarc/lists/aether-users/msg00009.html

This is the issue I'm working currently, and will hope to have some resolution shortly.

Dennis

[Dawid Loubser]

Oh - I didn't realise it's the same issue. That's great (at least it's
not a new issue)!

What really interests me is that, for example, the workflow example
deploys (or does not deploy) the space simply because I comment /
uncomment the interface declaration of the Master. Is my basic
statement correct - that only the artifacts for the interfaces of
services are used for dependency resolution, or is the intent that all
declared artifacts would be used (and that the really odd behaviour is
being caused by the bug)?

shout if you need any help -
Dawid

[Dennis Reedy]

On Mar 2, 2012, at 324PM, Dawid Loubser wrote:

> Oh - I didn't realise it's the same issue. That's great (at least it's
> not a new issue)!
>
> What really interests me is that, for example, the workflow example
> deploys (or does not deploy) the space simply because I comment /
> uncomment the interface declaration of the Master. Is my basic
> statement correct - that only the artifacts for the interfaces of
> services are used for dependency resolution,

When the Monitor is deploying the service all it cares about is the ability to load the service interfaces. As I look into RIO-344, that may change, I'm not sure yet.

Dennis

[Dawid Loubser]

If I understand you correctly, I find that rather unusual.

For example, the service interface(s) might have few or no
dependencies, but the service implementation may have a great number
of complex dependencies. Rio's dependency mechanism clearly works well
(in 4.2, I easily deployed a service that is also exposed as a JAX-WS
web service, and uses JPA to store information in a postgres database,
as well as map java objects to XML). It's unusual that the
dependencies / repos for a service with complex dependencies is
entirely subject to the POM tree of the *interface* containing the
references to the relevant repose, etc.

Consider a JavaSpaces-based system, where the workers have no
interfaces, but the implementation artifact has a great number of
dependencies to various technologies. Are you saying that I have to
have to expose at least one interface, which refers to an artifact
that has all the maven repo information such that the workers'
dependencies can be resolved?

Dawid

[Dennis Reedy]

I dont think I understood your original question, and/or I explained myself poorly (probably both).

The Monitor is only concerned with resolving the artifact associated to the interfaces element. The Cybernode deals with the artifact associated to the service implementation.

I hope that helps, sorry for the confusion.

[Dawid Loubser]

Hi Dennis,

No confusion, no problem :-) Here is the behaviour I am experiencing -
I'd love if you could shed some light on it. This opstring deploys:


import net.jini.space.JavaSpace05
import org.rioproject.config.Constants

deployment(name: 'Dependency Resolution Problem')

{
groups System.getProperty(Constants.GROUPS_PROPERTY_NAME,
System.getProperty('user.name'))

artifact id: 'service-impl', 'com.foo.bar:workflow-service:1.0'
artifact id: 'service-dl', 'com.foo.bar:workflow-api:1.0'

artifact id: 'outrigger-impl', 'com.sun.jini:outrigger:2.1'
artifact id: 'outrigger-dl', 'com.sun.jini:outrigger:jar:dl:2.1'

service(name: 'Master')
{

interfaces {
classes 'org.rioproject.examples.workflow.Master'

artifact ref: 'service-dl'
}

implementation(class:
"org.rioproject.examples.workflow.MasterImpl") {
artifact ref: 'service-impl'

}

association(type: "requires",
serviceType: JavaSpace05.name,
property: "javaSpace", name: "Space")

maintain 1
}

service(name: 'Space')
{
interfaces {
classes 'net.jini.space.JavaSpace05'
artifact ref: 'outrigger-dl'
}

implementation(class:
'com.sun.jini.outrigger.TransientOutriggerImpl') {
artifact ref: 'outrigger-impl'
}

maintain 1

}
}

Whereas if I simply remove the 'interface' the Master is published as
(which is no inherent problem, it just means nothing will be able to
look it up - but it could still interact via the space, etc) the
Master deploys fine, but the Outrigger (JavaSpace) no longer does,
because of a complaint that it cannot find outrigger in the central
repo. I understand this is linked to the bug you are working on (using
artifacts already in the local repo, and not looking in central again)
but why does a change to the *interface* of another service (which
outrigger has no dependency on) change the fact that outrigger deploys
or not? That's the issue that's been driving me crazy the past three
days. Here is the opstring that does not deploy:

import net.jini.space.JavaSpace05
import org.rioproject.config.Constants

deployment(name: 'Dependency Resolution Problem')

{
groups System.getProperty(Constants.GROUPS_PROPERTY_NAME,
System.getProperty('user.name'))

artifact id: 'service-impl', 'com.foo.bar:workflow-service:1.0'
artifact id: 'service-dl', 'com.foo.bar:workflow-api:1.0'

artifact id: 'outrigger-impl', 'com.sun.jini:outrigger:2.1'
artifact id: 'outrigger-dl', 'com.sun.jini:outrigger:jar:dl:2.1'

service(name: 'Master')
{

implementation(class:
"org.rioproject.examples.workflow.MasterImpl") {
artifact ref: 'service-impl'

}

association(type: "requires",
serviceType: JavaSpace05.name,
property: "javaSpace", name: "Space")

maintain 1
}

service(name: 'Space')
{
interfaces {
classes 'net.jini.space.JavaSpace05'
artifact ref: 'outrigger-dl'
}

implementation(class:
'com.sun.jini.outrigger.TransientOutriggerImpl') {
artifact ref: 'outrigger-impl'
}

maintain 1

}
}

Note: com.foo.bar is fictitious, but you can modify the standard rio
workflow example to illustrate the problem easily. My guess is that
the cybernode only looks at the aggregate maven metadata of all
*interfaces* (instead of implementation) artifacts to resolve
*implementation* artifacts (since 'service-impl' and 'service-dl' both
indirectly contain the link to the rio repository, but the cybernode
doesn't find it in the service-impl, only when service-dl is present.
When service-dl is not used to expose an (unrelated) interface, it
falls back to the standard 'look in central repo' mode, I am guessing.
Very odd behaviour - you should try it. We have a lot of opstrings
that don't expose any interfaces (only space-based workers) and I
could for the life of me not figure out why the space would not
deploy.

regards,
Dawid