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
Maven/local-repository/org/apache/felix/org.apache.felix.deployment.rp.autoconf/0.1.0/org.apache.felix.deployment.rp.autoconf-0.1.0.jar",
"processorPid": "",
"Bundle-Name": "Apache Felix Autoconf processor",
"Bundle-SymbolicName": "org.apache.felix.deployment.rp.autoconf",
"Bundle-Version": "0.1.0",
"Deployment-ProvidesResourceProcessor" :
"org.osgi.deployment.rp.autoconf"
},
"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
http://localhost:8080/client/work/rest-4/artifact/%28%26%28Bundle-SymbolicName%3Dorg.apache.felix.deployment.rp.autoconf%29%28
Bundle-Version%3D0.1.0%29%29"
* About to connect() to localhost port 8080 (#0)
* Trying 127.0.0.1... connected
* Connected to localhost (127.0.0.1) 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
> HTTP/1.1
> 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
Regards,
Bram
On Mon, Aug 22, 2011 at 2:53 PM, Bram de Kruijff <bdekrui...@gmail.com> wrote:
> 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
>>
>>
>
