Hi Marcel,
On Mon, Aug 22, 2011 at 1:11 PM, Marcel Offermans
<marcel.offerm...@luminis.nl> 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(StatefulGatewayRepositoryImpl.java:495)
>>
>>
>> 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(DeploymentArtifactImpl.java:98)
>
> 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
>> http://incubator.apache.org/ace/template-mechanism.html, 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 :)
Regard.
Bram
> Greetings, Marcel
>
>
