Details
-
Type:
Bug
-
Status: Closed (View Workflow)
-
Priority:
Minor
-
Resolution: Done
-
Affects Version/s: None
-
Fix Version/s: 0.2
-
Component/s: deployment
-
Labels:None
Description
According to SCA Assembly spec a component element can have zero or more implementation elements as its child. But the method getActivator(component) in Deployment.java you can find the following code:
private Activator getActivator(ComponentModel component) {
|
String type = component.getImplementation().getType();
|
Activator activator = _componentActivators.get(type);
|
|
|
if (activator == null) {
|
throw new RuntimeException("Unknown configuration component type '" + type + "'. No Activator implementation registered for this type.");
|
}
|
|
|
return activator;
|
}
|
I noticed this while working on SWITCHYARD-201 which also contains an example of the config that I'm using (See Keith's last comment)
Gliffy Diagrams
Activity
- All
- Comments
- Work Log
- History
- Activity
- Links Hierarchy
I found this in the spec regarding this:
A component element has zero or one implementation element as its child, which points to the implementation used by the component. A component with no implementation element is not runnable, but components of this kind may be useful during a "top-down" development process as a means of defining the characteristics required of the implementation before the implementation is written.
The only reason that I noticed this was because I had a config where I was missing a implementation for the component. I only had a implementation specified for the service in my configuration which is invalid. So I think we could mark jira as invalid as this should not really effect anyone that knows what they are doing (which obviously does not include me 
)
Daniel Bevenius
added a comment - I found this in the spec regarding this:
A component element has zero or one implementation element as its child, which points to the implementation used by the component. A component with no implementation element is not runnable, but components of this kind may be useful during a "top-down" development process as a means of defining the characteristics required of the implementation before the implementation is written.
The only reason that I noticed this was because I had a config where I was missing a implementation for the component. I only had a implementation specified for the service in my configuration which is invalid. So I think we could mark jira as invalid as this should not really effect anyone that knows what they are doing (which obviously does not include me )
I definitely agree that tooling will want to generate a service view without necessarily calling out the implementation in the design phase. Once we get to the stage of deploying the app, however, we need to know which component is gonna step up and provide the service.
You mentioned that your deployment had an implementation element under service, but not in component. I'm surprised that didn't fail schema validation in the deployer. We should be validating the config passed in, so there may be an issue here after all. 
Which version of the spec are you consulting, btw? I have been going off of the current 1.1 draft, mainly because it's supposed to roll in a bunch of feedback from implementers over 1.0.
Keith Babo
added a comment - I definitely agree that tooling will want to generate a service view without necessarily calling out the implementation in the design phase. Once we get to the stage of deploying the app, however, we need to know which component is gonna step up and provide the service.
You mentioned that your deployment had an implementation element under service, but not in component. I'm surprised that didn't fail schema validation in the deployer. We should be validating the config passed in, so there may be an issue here after all.
Which version of the spec are you consulting, btw? I have been going off of the current 1.1 draft, mainly because it's supposed to roll in a bunch of feedback from implementers over 1.0. Which version of the spec are you consulting, btw?
I've been reading 1.0 spec so this might be outdated info that I've been providing. I'll read up on 1.1 instead.
Daniel Bevenius
added a comment -
Which version of the spec are you consulting, btw?
I've been reading 1.0 spec so this might be outdated info that I've been providing. I'll read up on 1.1 instead. I don't think we want to support this, but we certainly shouldn't throw an NPE if it happens. Need to add some better error reporting for 0.2.
Keith Babo
added a comment - I don't think we want to support this, but we certainly shouldn't throw an NPE if it happens. Need to add some better error reporting for 0.2. pull requests pushed upstream.
Rob Cernich
added a comment - pull requests pushed upstream. 
I wonder what the use case is for allowing a component with no implementation? I took a peek at the latest committee draft of the assembly spec (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sca-assembly) and the spec appears to contradict itself between sections 4 and 4.1. In any case, the schema currently lists it as optional (minOccurs="0"), so I guess we have to go with that.
At this point, I don't see a compelling use case for a component without an implementation in SwitchYard, so I'm going to set the priority of this to Minor. I think it's great that you filed this though; we definitely want to log issues where our behavior diverges from something in the spec.