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 Tue, 23 Aug 2011 16:49:36 GMT
Two more fun facts on resource processors for future reference :)

1) You can create them through the client API, but you need to add an
Deployment-ProvidesResourceProcessor attribute. Eg from my client the
artifact representation looks...

        "attributes": {
          "artifactName": "Apache Felix Autoconf processor",
          "artifactDescription": "Autoconf processor",
          "mimetype": "application/vnd.osgi.bundle",
          "url": "file:///C:/bramk/Apache
          "processorPid": "",
          "Bundle-Name": "Apache Felix Autoconf processor",
          "Bundle-SymbolicName": "org.apache.felix.deployment.rp.autoconf",
          "Bundle-Version": "0.1.0",
          "Deployment-ProvidesResourceProcessor" :
        "tags": {

2) You can't see them from the client side but it appears you can delete them...

C:\bramk\Amdatu>curl -v -X DELETE
* About to connect() to localhost port 8080 (#0)
*   Trying connected
* Connected to localhost ( port 8080 (#0)
> DELETE /client/work/rest-4/artifact/%28%26%28Bundle-SymbolicName%3Dorg.apache.felix.deployment.rp.autoconf%29%28Bundle-Version%3D0.1.0%29%29
> User-Agent: curl/7.21.4 (i386-pc-win32) libcurl/7.21.4 zlib/1.2.5
> Host: localhost:8080
> Accept: */*
< HTTP/1.1 200 OK
< Transfer-Encoding: chunked
< Server: Jetty(6.1.x)
* Connection #0 to host localhost left intact
* Closing connection #0


On Mon, Aug 22, 2011 at 2:53 PM, Bram de Kruijff <> wrote:
> 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 :)
> Regard.
> Bram
>> Greetings, Marcel

View raw message