ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bram de Kruijff <>
Subject Re: Is there a configuration resourceprocessor?
Date Mon, 22 Aug 2011 12:53:42 GMT
Hi Marcel,

On Mon, Aug 22, 2011 at 1:11 PM, Marcel Offermans
<> wrote:
> Hello Bram,
> On 18 Aug 2011, at 21:13 , Bram de Kruijff wrote:
>> a couple more notes/questions on the configuration mechanism.
>> 1) Seems that (at least) using the REST api I am required to set
>> "processorPid" : "org.osgi.deployment.rp.autoconf". Without it the
>> artifact will be created, but once associated to a target things fail
>> (exception below). From an api user perspective this feels
>> inconsistent (as it is different form bundles where you can leave it
>> empty or commit it altogether) and/or at least I'd expect an error on
>> creation because it apparently is required.
> Here I can safely say I was not done yet with the REST API, and I agree we could help
the user a bit more!
>> From an implementation
>> perspective I am wondering why it needs to be specified at all as the
>> helpers map mimetypes to processors anyway.
> I'd have to take a closer look to see why we did this. Perhaps Angelo remembers? :)
>> Server side logged exception when leaving the attribute empty string:
>> (note the empty string in the message ;)
>> [Warn ] [012]org.apache.ace.client.repository.stateful.StatefulGatewayRepository;org.osgi.service.event.EventHandler:
>> EventAdmin: Exception during event dispatc
>> h [org.osgi.service.event.Event
>> [topic=org/apache/ace/client/repository/public/Group2LicenseAssociation/ADDED]
>> | [org.apache.ace.client.repository.stateful.Stat
>> efulGatewayRepository, org.osgi.service.event.EventHandler] |
>> Bundle(org.apache.ace.client.repository.impl [12])]
>> java.lang.IllegalStateException: Unable to create deployment version:
>> there is no resource processing bundle available that publishes
>>        at org.apache.ace.client.repository.stateful.impl.StatefulGatewayRepositoryImpl.getNecessaryDeploymentArtifacts(
>> Server side logged exception when omitting the attribute:
>> g! java.lang.IllegalArgumentException: Neither the key nor the value
>> should be null.[Warn ]
>> [012]org.apache.ace.client.repository.stateful.StatefulGatewayReposi
>> tory;org.osgi.service.event.EventHandler: EventAdmin: Exception during
>> event dispatch [org.osgi.service.event.Event
>> [topic=org/apache/ace/client/repository/publ
>> ic/Group2LicenseAssociation/ADDED] |
>> [org.apache.ace.client.repository.stateful.StatefulGatewayRepository,
>> org.osgi.service.event.EventHandler] | Bundle(org.apa
>> che.ace.client.repository.impl [12])]
>>        at org.apache.ace.client.repository.impl.DeploymentArtifactImpl.addDirective(
> Point taken, we can make this a lot less cryptic!
>> 2) The velocity based properties substituion in metatype works once
>> you find out you need to wrap the in "${context.<tag>}". Documenting
>> this will save a lot of people a lot of searching and frustration ;)
>> As of yet I am unclear whether I can use the more powerful stuff such
>> as "foreach( $license in $gateway.children)" as described at
>>, but from the
>> implementation I guess not?
> Agreed, part of that document is still "wishful thinking". It needs an update. Do you
need the "more powerful stuff"?

Not sure/guess not as I do not yet fully understand what
"gateway.children" means anyway. As mentioned below I'm not convinced
the velocity model fits our use case best anyway, so no +1 from my
end. Just noticed that it was not on the context passed into velocity

>> Furthermote I am wondering about why velocity is used at all. The
>> metatype provides us with declarative attributes descriptions that
>> allows UIs to provide appropriate input fields (eg felix webconsole) .
>> It could allow webui for example to spawn a "specify required missing
>> attributes" dialog upon association to a target. The velocity model is
>> non declarative making this stuff harder?
> There are a couple of reasons why we used Velocity for this:
> 1) Not every bundle that has configuration data uses the metatype specification, so we
cannot rely exclusively on it.
> 2) When we implemented this, webconsole did not exist yet, and I had not seen many people
use metatype.
> I do think it's a nice idea to add support for metatype to allow you to create configurations
for the bundles you want to deploy. I don't see how we can ever determine that if you associate
a bundle to a target that nobody already specifies properties for a bundle, so I don't think
we can spawn a dialog when you associate a bundle with a target. However, we can recognize
that a bundle has static metatype information associated with it, and we can create a dialog
to provide that data and store it in the OBR so you can deploy it alongside the bundle.

Clear. Something like that yes. Thanks for the insights. Thinking some
more about it :)


> Greetings, Marcel

View raw message