You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ace.apache.org by "John E. Conlon" <jc...@verticon.com> on 2010/01/27 18:42:43 UTC
Getting Started problems with Ace WebUI
Hi Ace Team,
I'm a new user trying to come up to speed on ACE and OSGi's Deployment
Admin and have a few new user questions regarding the getting started on
the web ui and Ace/DeployAdmin.
Test drive File based - ok
Was able to startup the file based server (target/dev-server-filebased)
and the 'target' (deploy/target/dev-gateway) and see bundle resources
installed, updated, and deleted as artifacts on the target. Cool stuff.
Test drive WebUI - problems
Had problems when I tested out the target/dev-server-webui though.
While I could add an artifact, feature, and distribution and I could see
my target, I could not associate artifacts with features, nor features
with distributions, nor distributions with my target. Dragging one to
the other does not seem to work on my Ubuntu Firefox 3.5.7 browser. Any
tips on how I can get this working?
Ace and Deployment Admin
Besides bundle resources (aka artifacts) how can I deploy autoconf
processed resources or more generic processed resources and customizer
bundles?
thanks for any help,
John
Re: Getting Started problems with Ace WebUI
Posted by "John E. Conlon" <jc...@verticon.com>.
Hi Marcel,
Marcel Offermans wrote:
> Hello John,
>
> On Jan 29, 2010, at 0:52 , John E. Conlon wrote:
>
>
>> Marcel Offermans wrote:
>>
>>> No, I meant adding the resource processor bundle to the list of bundles you want installed on the target.
>>>
>
>
>> I thought you may have meant this, but if one does add it to the list of bundles, how will ACE distinguish this 'Customizer bundle' from others bundle resources that are part of the Deployment Package? Will need to specify this somehow as a "DeploymentPackage-Customizer: true".
>>
>
> If you stick to the spec, then "customizer bundles" don't provide any mandatory metadata to recognize them.
When you say 'mandatory metadata' I think you must be referring to the
customizer 'bundle's MANIFEST.MF' versus the Deployment Packages
MANIFEST.MF. Right?
> However, for ACE we decided that it would be very convenient if a user could just drop it in, so we add a header of the following form:
>
> Deployment-ProvidesResourceProcessor: org.osgi.deployment.rp.autoconf
>
> (in this example for a processor that can process resources tagged with that PID)
>
Makes sense.
Took a look to see if there was anything special in the MANIFEST.MF for
the org.apache.felix.deployment.rp.autoconf-0.1.0-SNAPSHOT.jar and I see
only the header DeploymentPackage-Customizer: true
Which is interesting because that header is for the Deployment Packages
MANIFEST.MF, but not is not required by the spec to be in the actual
bundle MANIFEST.MF.
I also guess that since it does not have a
Deployment-ProvidesResourceProcessor: org.osgi.deployment.rp.autoconf
it is something that the ACE team has just not gotten around to adding
as of yet.
>
>> Also same question for other customizers. How to distinguish them from bundles that are part of the list?
>>
>
>
>> Same as well for 'processed resources'. How to tell ACE their resource processor's pid?
>>
>
> There are a couple of other bits that we have to add to ACE to make this whole process work. You have to provide an implementation of both ArtifactRecognizer and ArtifactHelper, which provide support services to the client.
>
This must be where the decoration/annotation of the resources will come in.
> As said before by Angelo, the current UI does not expose enough features yet to make it work.
>
> Some background information about this can be found on the following page:
>
> http://incubator.apache.org/ace/object-graph-in-client.html
>
>
>
Thanks that helps.
>>>> (Seems to me that it should work because it is not associated with a
>>>> foriegn deployment package it is just installed normally on the framework. )
>>>>
>>>>
>>> As far as I understood it, it has to be in the same DP, but it's been a while since I read the spec. Could you point me to the part of the spec that states that?
>>>
>>>
>>
>> Deployment Admin 114.16.4
>> "Bundles exporting the service may arrive in
>> the deployment package (customizers) or may be preregistered (they are
>> installed prevoiusly). Resource processors has to define the service.pid
>> standard OSGi service property which should be a unique string."
>>
>
> Thanks, that's a bug.
>
>
>> Actually I sort of like it as a Customizer Bundle although, it makes the Deployment Package larger.
>>
>
> Indeed, but it does make the whole process more flexible.
>
Agree.
>
>> There was one other subtlety that did not work but would be nice if it did. Auto Configuration Specification 115.4.4
>>
>> "The OCD elements that are referred from an Object element can be contained
>> in the Autoconf resource, or they can come from the Meta Type service.
>> The reference takes place through the ocdref attribute of the Object
>> element. The Autoconf Resource Processor must first match this name to
>> any OCD elements in the Autoconf resources. If the reference cannot be
>> found in this file, it must consult the Meta Type service (if present) for the
>> bundle that is associated with the PID that is configured."
>>
>> I am using Meta Type for my bundles. But could not remove my OCD element to let it find the one on the bundle. When I try and load a Deployment Package with this defaulting autoconf.xml I get thrown a Null Pointer and the load fails. May be some other kind of edge thing here because it is further complicated by my using ManagedServiceFactories. I am content with it work as it is though.
>>
>
> Feel free to report this as an enhancement. Probably the issue tracker for Apache Felix is the best place as that's where the code resides.
>
>
Will do.
thanks again,
John
Re: Getting Started problems with Ace WebUI
Posted by Marcel Offermans <ma...@luminis.nl>.
Hello John,
On Jan 29, 2010, at 0:52 , John E. Conlon wrote:
> Marcel Offermans wrote:
>> No, I meant adding the resource processor bundle to the list of bundles you want installed on the target.
> I thought you may have meant this, but if one does add it to the list of bundles, how will ACE distinguish this 'Customizer bundle' from others bundle resources that are part of the Deployment Package? Will need to specify this somehow as a "DeploymentPackage-Customizer: true".
If you stick to the spec, then "customizer bundles" don't provide any mandatory metadata to recognize them. However, for ACE we decided that it would be very convenient if a user could just drop it in, so we add a header of the following form:
Deployment-ProvidesResourceProcessor: org.osgi.deployment.rp.autoconf
(in this example for a processor that can process resources tagged with that PID)
> Also same question for other customizers. How to distinguish them from bundles that are part of the list?
> Same as well for 'processed resources'. How to tell ACE their resource processor's pid?
There are a couple of other bits that we have to add to ACE to make this whole process work. You have to provide an implementation of both ArtifactRecognizer and ArtifactHelper, which provide support services to the client.
As said before by Angelo, the current UI does not expose enough features yet to make it work.
Some background information about this can be found on the following page:
http://incubator.apache.org/ace/object-graph-in-client.html
>>> (Seems to me that it should work because it is not associated with a
>>> foriegn deployment package it is just installed normally on the framework. )
>>>
>>
>> As far as I understood it, it has to be in the same DP, but it's been a while since I read the spec. Could you point me to the part of the spec that states that?
>>
>
> Deployment Admin 114.16.4
> "Bundles exporting the service may arrive in
> the deployment package (customizers) or may be preregistered (they are
> installed prevoiusly). Resource processors has to define the service.pid
> standard OSGi service property which should be a unique string."
Thanks, that's a bug.
> Actually I sort of like it as a Customizer Bundle although, it makes the Deployment Package larger.
Indeed, but it does make the whole process more flexible.
> There was one other subtlety that did not work but would be nice if it did. Auto Configuration Specification 115.4.4
>
> "The OCD elements that are referred from an Object element can be contained
> in the Autoconf resource, or they can come from the Meta Type service.
> The reference takes place through the ocdref attribute of the Object
> element. The Autoconf Resource Processor must first match this name to
> any OCD elements in the Autoconf resources. If the reference cannot be
> found in this file, it must consult the Meta Type service (if present) for the
> bundle that is associated with the PID that is configured."
>
> I am using Meta Type for my bundles. But could not remove my OCD element to let it find the one on the bundle. When I try and load a Deployment Package with this defaulting autoconf.xml I get thrown a Null Pointer and the load fails. May be some other kind of edge thing here because it is further complicated by my using ManagedServiceFactories. I am content with it work as it is though.
Feel free to report this as an enhancement. Probably the issue tracker for Apache Felix is the best place as that's where the code resides.
>> It's in scope as far as I'm concerned. We initially developed and donated the DA implementation to Apache Felix because at that time, ACE did not exist as an open source project yet (and it makes sense because it's a compendium service, so Felix is a great place to maintain that). However, it's an important part of ACE so I do think it's in scope to discuss it here.
>>
>
> Good to hear that I have not left the building with Elvis;-)
:)
> kind regards and thanks for all the great work,
You're welcome, thanks for the feedback.
Greetings, Marcel
Re: Getting Started problems with Ace WebUI
Posted by Marcel Offermans <ma...@luminis.nl>.
Hello John,
On Jan 29, 2010, at 2:25 , John E. Conlon wrote:
> from the webconsole I tried to uninstall my current Deployment Package and got thrown a - IllegalStateException Not implemented.
> by the org.apache.felix.deploymentadmin.AbstractDeploymentPackage.uninstall(AbstractDeploymentPackage.java:219)
That is correct, we did not yet implement those.
> Seems like these are fundamental functions in the DA. Don't know the ACE backend but I thought it relied on Deployment Admin? If so doesn't this create a similar problem for ACE as well?
Well, actually we don't use uninstall in ACE at all, which is why this does not pose a problem.
In ACE we use DA this way:
- Each new target starts out as an empty OSGi framework with just a management agent installed.
- All artifacts sent to a target get bundled in one DP specific to that target.
- Every time you change some aspect of the configuration for a target, we create a new version of the DP for it.
We do that so we can use the transactional aspect of DA to ensure that any change will either install completely or not at all.
So, if a user decides he/she does not want any artifacts installed on a gateway, what we technically do is create yet another version of that DP, but this time one with zero artifacts in it. That's why we never use "uninstall" in ACE and that's probably the most important reason why we did not yet implement it.
> How difficult would you say it is to implement these? ( I have a time frame I have to work within and I wonder if I can do the implementation or hold off for the time being?)
I don't think it would be too difficult. Probably the hardest part is studying the existing implementation, but have a look. I'd be happy to assist you as much as I can.
Greetings, Marcel
Re: Getting Started problems with Ace WebUI
Posted by "John E. Conlon" <jc...@verticon.com>.
Hi Again,
Let me add one more thing...
As I was experimenting with Deployment Packages, by changing them and
reving the version, I noticed that my ManageServiceFactories kept
adding new instances but the old ones from previous versions of the
Deployment Packages were still there. Hmm? So from the webconsole I
tried to uninstall my current Deployment Package and got thrown a -
IllegalStateException Not implemented.
by the
org.apache.felix.deploymentadmin.AbstractDeploymentPackage.uninstall(AbstractDeploymentPackage.java:219)
There are two unimplemented methods.
public void uninstall() throws DeploymentException {
throw new IllegalStateException("Not implemented");
}
public boolean uninstallForced() throws DeploymentException {
throw new IllegalStateException("Not implemented");
}
Seems like these are fundamental functions in the DA. Don't know the
ACE backend but I thought it relied on Deployment Admin? If so doesn't
this create a similar problem for ACE as well?
How difficult would you say it is to implement these? ( I have a time
frame I have to work within and I wonder if I can do the implementation
or hold off for the time being?)
Again thanks for all the help,
John
John E. Conlon wrote:
> Hi Marcel,
>
> Marcel Offermans wrote:
>> Hello John,
>>
>> On Jan 28, 2010, at 3:15 , John E. Conlon wrote:
>>
>>
>>>>>> Autoconf files (or any other artifact that is not a bundle) are
>>>>>> not yet
>>>>>> supported.
>>>>>> That is, the client (the bundles that know how to communicate
>>>>>> with the
>>>>>> server) supports this, but the web ui does not show these
>>>>>> features yet.
>>>>>> https://issues.apache.org/jira/browse/ACE-53 has already been
>>>>>> created for
>>>>>> this.
>>>>>>
>>>>> Looked at ACE-53 and saw your comment on AutoConf. If I use the
>>>>> filebased server and add to my target the
>>>>> org.apache.felix.deployment.rp.autoconf-0.1.0-SNAPSHOT.jar do you
>>>>> think I can drop in an autoconf.xml file in my folder and it will
>>>>> deploy to the target??
>>>>>
>>>> From memory, I think you will need to manually include the resource
>>>> processor for AutoConf too.
>>> Did you mean manually install the autoConf on the target gateway?
>>>
>>
>> No, I meant adding the resource processor bundle to the list of
>> bundles you want installed on the target.
>>
> I thought you may have meant this, but if one does add it to the list
> of bundles, how will ACE distinguish this 'Customizer bundle' from
> others bundle resources that are part of the Deployment Package? Will
> need to specify this somehow as a "DeploymentPackage-Customizer: true".
>
> Also same question for other customizers. How to distinguish them
> from bundles that are part of the list?
>
> Same as well for 'processed resources'. How to tell ACE their
> resource processor's pid?
>>
>>> To become more familiar with DeploymentAdmin, configs and the ACE
>>> backend, I decided to experiment with a real deployment package and
>>> install it on the gateway through a felix.webconsole. On the target
>>> gateway I installed the following bundles:
>>> org.apache.felix.dependencymanager.jar
>>> org.apache.felix.deploymentadmin-0.9.0-SNAPSHOT.jar
>>> org.apache.felix.deployment.rp.autoconf-0.1.0-SNAPSHOT.jar
>>> /org.apache.felix.webconsole-2.0.6.jar
>>>
>>> When I try to load a deployment package that contains an resource like:
>>>
>>> Name: autoconf.xml
>>> Resource-Processor: org.osgi.deployment.rp.autoconf
>>>
>>> I get a:
>>>
>>> org.osgi.service.deploymentadmin.DeploymentException: Resource
>>> processor for resource 'autoconf.xml' belongs to foreign deployment
>>> package
>>>
>>
>> That is correct, according to spec, as the resource processor has to
>> be shipped as part of the deployment package. Of course we could
>> discuss if we should relax that requirement, but that would be going
>> beyond what the spec dictates (and it makes more sense to dynamically
>> install resource processors anyway).
>>
>>
>>> (Seems to me that it should work because it is not associated with a
>>> foriegn deployment package it is just installed normally on the
>>> framework. )
>>>
>>
>> As far as I understood it, it has to be in the same DP, but it's been
>> a while since I read the spec. Could you point me to the part of the
>> spec that states that?
>>
> Deployment Admin 114.16.4
> "Bundles exporting the service may arrive in
> the deployment package (customizers) or may be preregistered (they are
> installed prevoiusly). Resource processors has to define the service.pid
> standard OSGi service property which should be a unique string."
>
> Actually I sort of like it as a Customizer Bundle although, it makes
> the Deployment Package larger.
>>
>>
>>> If I take the resource processor off my target gateway and include
>>> it in
>>> my deployment package I get passed the above error but I keep getting:
>>>
>>> org.osgi.service.deploymentadmin.spi.ResourceProcessorException:
>>> Supplied configuration is not conform the metatype xml specification.
>>> at
>>> org.apache.felix.deployment.rp.autoconf.AutoConfResourceProcessor.process(AutoConfResourceProcessor.java:98)
>>>
>>> at
>>> org.apache.felix.deploymentadmin.spi.ProcessResourceCommand.execute(ProcessResourceCommand.java:92)
>>>
>>> at
>>> org.apache.felix.deploymentadmin.spi.DeploymentSessionImpl.call(DeploymentSessionImpl.java:71)
>>>
>>> at
>>> org.apache.felix.deploymentadmin.DeploymentAdminImpl.installDeploymentPackage(DeploymentAdminImpl.java:215)
>>>
>>>
>>>
>>> Tried various simpler autoconf.xml files even some out of the
>>> compendium (just to see if I can get a different error besides
>>> the parsing error) but can't get can't get passed the above parsing
>>> error. I can get cruder parsing errors but the one above
>>> is one that is thrown if no metadata is produced.
>>>
>>
>> This should work. Again, from memory, I do remember some examples in
>> the spec being wrong. This should work! To better debug it, I don't
>> have any advice beyond actually running it in a debugger and tracing
>> through the code that way.
>>
>>
>>> Perhaps I am doing something glaringly wrong?
>>>
>>
>> No, you're on the right path.
>>
>> Within luminis we use a GUI to edit these configurations, so I
>> quickly used it to generate an example:
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <MetaData xmlns:metatype="http://www.osgi.org/xmlns/metatype/v1.0.0">
>> <OCD name="ocd" id="ocd">
>> <AD id="firstName" type="STRING" cardinality="0" />
>> <AD id="lastName" type="STRING" cardinality="0" />
>> </OCD>
>> <Designate pid="myfirstpid" factoryPid="" bundle="mybundle"
>> merge="false" optional="false">
>> <Object ocdref="ocd">
>> <Attribute adref="firstName">
>> <Value><![CDATA[Marcel]]></Value>
>> </Attribute>
>> <Attribute adref="lastName">
>> <Value><![CDATA[Offermans]]></Value>
>> </Attribute>
>> </Object>
>> </Designate>
>> </MetaData>
>>
>> Let me know if you have more luck with this one (you probably need to
>> edit it a bit so it applies to the right bundle, etc.
>>
>>
> Yes I did!
>
>
> Noticed that there are a lot of differences from the ones I was
> using. Here is one from the spec, which I patterned mine after.
>
> <?xml version="1.0" encoding="UTF-8"?>
> <metatype:MetaData xmlns:metatype=
> "http://www.osgi.org/xmlns/metatype/v1.1.0">
>
> <OCD id="ChatConfiguration">
> <AD id="server" type="String">
> </OCD>
>
> <Designate pid="com.acme.pid.Chat"
> bundle="http://www.acme.com/chat.jar>
> <Object ocdref="ChatConfiguration">
>
> <Attribute adref="server" name="serverurl"
> content="http://chat.acme.com"/>
> </Object>
> </Designate>
> </metatype:MetaData>
>
>
> There was one other subtlety that did not work but would be nice if it
> did. Auto Configuration Specification 115.4.4
>
> "The OCD elements that are referred from an Object element can be
> contained
> in the Autoconf resource, or they can come from the Meta Type service.
> The reference takes place through the ocdref attribute of the Object
> element. The Autoconf Resource Processor must first match this name to
> any OCD elements in the Autoconf resources. If the reference cannot be
> found in this file, it must consult the Meta Type service (if present)
> for the
> bundle that is associated with the PID that is configured."
>
> I am using Meta Type for my bundles. But could not remove my OCD
> element to let it find the one on the bundle. When I try and load a
> Deployment Package with this defaulting autoconf.xml I get thrown a
> Null Pointer and the load fails. May be some other kind of edge
> thing here because it is further complicated by my using
> ManagedServiceFactories. I am content with it work as it is though.
>
>
>>> Sorry if I am outside the scope of Ace and into a more generic
>>> discussion of Deployment Admin.
>>>
>>
>> It's in scope as far as I'm concerned. We initially developed and
>> donated the DA implementation to Apache Felix because at that time,
>> ACE did not exist as an open source project yet (and it makes sense
>> because it's a compendium service, so Felix is a great place to
>> maintain that). However, it's an important part of ACE so I do think
>> it's in scope to discuss it here.
>>
>>
> Good to hear that I have not left the building with Elvis;-)
>
> kind regards and thanks for all the great work,
>
> John
>
>
Re: Getting Started problems with Ace WebUI
Posted by "John E. Conlon" <jc...@verticon.com>.
Hi Marcel,
Marcel Offermans wrote:
> Hello John,
>
> On Jan 28, 2010, at 3:15 , John E. Conlon wrote:
>
>
>>>>> Autoconf files (or any other artifact that is not a bundle) are not yet
>>>>> supported.
>>>>> That is, the client (the bundles that know how to communicate with the
>>>>> server) supports this, but the web ui does not show these features yet.
>>>>> https://issues.apache.org/jira/browse/ACE-53 has already been created for
>>>>> this.
>>>>>
>>>>>
>>>> Looked at ACE-53 and saw your comment on AutoConf. If I use the filebased server and add to my target the org.apache.felix.deployment.rp.autoconf-0.1.0-SNAPSHOT.jar do you think I can drop in an autoconf.xml file in my folder and it will deploy to the target??
>>>>
>>>>
>>> From memory, I think you will need to manually include the resource processor for AutoConf too.
>>>
>> Did you mean manually install the autoConf on the target gateway?
>>
>
> No, I meant adding the resource processor bundle to the list of bundles you want installed on the target.
>
I thought you may have meant this, but if one does add it to the list of
bundles, how will ACE distinguish this 'Customizer bundle' from others
bundle resources that are part of the Deployment Package? Will need to
specify this somehow as a "DeploymentPackage-Customizer: true".
Also same question for other customizers. How to distinguish them from
bundles that are part of the list?
Same as well for 'processed resources'. How to tell ACE their resource
processor's pid?
>
>> To become more familiar with DeploymentAdmin, configs and the ACE
>> backend, I decided to experiment with a real deployment package and
>> install it on the gateway through a felix.webconsole. On the target
>> gateway I installed the following bundles:
>> org.apache.felix.dependencymanager.jar
>> org.apache.felix.deploymentadmin-0.9.0-SNAPSHOT.jar
>> org.apache.felix.deployment.rp.autoconf-0.1.0-SNAPSHOT.jar
>> /org.apache.felix.webconsole-2.0.6.jar
>>
>> When I try to load a deployment package that contains an resource like:
>>
>> Name: autoconf.xml
>> Resource-Processor: org.osgi.deployment.rp.autoconf
>>
>> I get a:
>>
>> org.osgi.service.deploymentadmin.DeploymentException: Resource processor for resource 'autoconf.xml' belongs to foreign deployment package
>>
>
> That is correct, according to spec, as the resource processor has to be shipped as part of the deployment package. Of course we could discuss if we should relax that requirement, but that would be going beyond what the spec dictates (and it makes more sense to dynamically install resource processors anyway).
>
>
>> (Seems to me that it should work because it is not associated with a
>> foriegn deployment package it is just installed normally on the framework. )
>>
>
> As far as I understood it, it has to be in the same DP, but it's been a while since I read the spec. Could you point me to the part of the spec that states that?
>
Deployment Admin 114.16.4
"Bundles exporting the service may arrive in
the deployment package (customizers) or may be preregistered (they are
installed prevoiusly). Resource processors has to define the service.pid
standard OSGi service property which should be a unique string."
Actually I sort of like it as a Customizer Bundle although, it makes the
Deployment Package larger.
>
>
>> If I take the resource processor off my target gateway and include it in
>> my deployment package I get passed the above error but I keep getting:
>>
>> org.osgi.service.deploymentadmin.spi.ResourceProcessorException: Supplied configuration is not conform the metatype xml specification.
>> at org.apache.felix.deployment.rp.autoconf.AutoConfResourceProcessor.process(AutoConfResourceProcessor.java:98)
>> at org.apache.felix.deploymentadmin.spi.ProcessResourceCommand.execute(ProcessResourceCommand.java:92)
>> at org.apache.felix.deploymentadmin.spi.DeploymentSessionImpl.call(DeploymentSessionImpl.java:71)
>> at org.apache.felix.deploymentadmin.DeploymentAdminImpl.installDeploymentPackage(DeploymentAdminImpl.java:215)
>>
>>
>> Tried various simpler autoconf.xml files even some out of the compendium (just to see if I can get a different error besides
>> the parsing error) but can't get can't get passed the above parsing error. I can get cruder parsing errors but the one above
>> is one that is thrown if no metadata is produced.
>>
>
> This should work. Again, from memory, I do remember some examples in the spec being wrong. This should work! To better debug it, I don't have any advice beyond actually running it in a debugger and tracing through the code that way.
>
>
>> Perhaps I am doing something glaringly wrong?
>>
>
> No, you're on the right path.
>
> Within luminis we use a GUI to edit these configurations, so I quickly used it to generate an example:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <MetaData xmlns:metatype="http://www.osgi.org/xmlns/metatype/v1.0.0">
> <OCD name="ocd" id="ocd">
> <AD id="firstName" type="STRING" cardinality="0" />
> <AD id="lastName" type="STRING" cardinality="0" />
> </OCD>
> <Designate pid="myfirstpid" factoryPid="" bundle="mybundle" merge="false" optional="false">
> <Object ocdref="ocd">
> <Attribute adref="firstName">
> <Value><![CDATA[Marcel]]></Value>
> </Attribute>
> <Attribute adref="lastName">
> <Value><![CDATA[Offermans]]></Value>
> </Attribute>
> </Object>
> </Designate>
> </MetaData>
>
> Let me know if you have more luck with this one (you probably need to edit it a bit so it applies to the right bundle, etc.
>
>
Yes I did!
Noticed that there are a lot of differences from the ones I was using.
Here is one from the spec, which I patterned mine after.
<?xml version="1.0" encoding="UTF-8"?>
<metatype:MetaData xmlns:metatype=
"http://www.osgi.org/xmlns/metatype/v1.1.0">
<OCD id="ChatConfiguration">
<AD id="server" type="String">
</OCD>
<Designate pid="com.acme.pid.Chat"
bundle="http://www.acme.com/chat.jar>
<Object ocdref="ChatConfiguration">
<Attribute adref="server" name="serverurl"
content="http://chat.acme.com"/>
</Object>
</Designate>
</metatype:MetaData>
There was one other subtlety that did not work but would be nice if it
did.
Auto Configuration Specification 115.4.4
"The OCD elements that are referred from an Object element can be contained
in the Autoconf resource, or they can come from the Meta Type service.
The reference takes place through the ocdref attribute of the Object
element. The Autoconf Resource Processor must first match this name to
any OCD elements in the Autoconf resources. If the reference cannot be
found in this file, it must consult the Meta Type service (if present)
for the
bundle that is associated with the PID that is configured."
I am using Meta Type for my bundles. But could not remove my OCD
element to let it find the one on the bundle. When I try and load a
Deployment Package with this defaulting autoconf.xml I get thrown a Null
Pointer and the load fails. May be some other kind of edge thing here
because it is further complicated by my using ManagedServiceFactories.
I am content with it work as it is though.
>> Sorry if I am outside the scope of Ace and into a more generic
>> discussion of Deployment Admin.
>>
>
> It's in scope as far as I'm concerned. We initially developed and donated the DA implementation to Apache Felix because at that time, ACE did not exist as an open source project yet (and it makes sense because it's a compendium service, so Felix is a great place to maintain that). However, it's an important part of ACE so I do think it's in scope to discuss it here.
>
>
Good to hear that I have not left the building with Elvis;-)
kind regards and thanks for all the great work,
John
Re: Getting Started problems with Ace WebUI
Posted by Marcel Offermans <ma...@luminis.nl>.
Hello John,
On Jan 28, 2010, at 3:15 , John E. Conlon wrote:
>>>> Autoconf files (or any other artifact that is not a bundle) are not yet
>>>> supported.
>>>> That is, the client (the bundles that know how to communicate with the
>>>> server) supports this, but the web ui does not show these features yet.
>>>> https://issues.apache.org/jira/browse/ACE-53 has already been created for
>>>> this.
>>>>
>>> Looked at ACE-53 and saw your comment on AutoConf. If I use the filebased server and add to my target the org.apache.felix.deployment.rp.autoconf-0.1.0-SNAPSHOT.jar do you think I can drop in an autoconf.xml file in my folder and it will deploy to the target??
>>>
>>
>> From memory, I think you will need to manually include the resource processor for AutoConf too.
> Did you mean manually install the autoConf on the target gateway?
No, I meant adding the resource processor bundle to the list of bundles you want installed on the target.
> To become more familiar with DeploymentAdmin, configs and the ACE
> backend, I decided to experiment with a real deployment package and
> install it on the gateway through a felix.webconsole. On the target
> gateway I installed the following bundles:
> org.apache.felix.dependencymanager.jar
> org.apache.felix.deploymentadmin-0.9.0-SNAPSHOT.jar
> org.apache.felix.deployment.rp.autoconf-0.1.0-SNAPSHOT.jar
> /org.apache.felix.webconsole-2.0.6.jar
>
> When I try to load a deployment package that contains an resource like:
>
> Name: autoconf.xml
> Resource-Processor: org.osgi.deployment.rp.autoconf
>
> I get a:
>
> org.osgi.service.deploymentadmin.DeploymentException: Resource processor for resource 'autoconf.xml' belongs to foreign deployment package
That is correct, according to spec, as the resource processor has to be shipped as part of the deployment package. Of course we could discuss if we should relax that requirement, but that would be going beyond what the spec dictates (and it makes more sense to dynamically install resource processors anyway).
> (Seems to me that it should work because it is not associated with a
> foriegn deployment package it is just installed normally on the framework. )
As far as I understood it, it has to be in the same DP, but it's been a while since I read the spec. Could you point me to the part of the spec that states that?
> If I take the resource processor off my target gateway and include it in
> my deployment package I get passed the above error but I keep getting:
>
> org.osgi.service.deploymentadmin.spi.ResourceProcessorException: Supplied configuration is not conform the metatype xml specification.
> at org.apache.felix.deployment.rp.autoconf.AutoConfResourceProcessor.process(AutoConfResourceProcessor.java:98)
> at org.apache.felix.deploymentadmin.spi.ProcessResourceCommand.execute(ProcessResourceCommand.java:92)
> at org.apache.felix.deploymentadmin.spi.DeploymentSessionImpl.call(DeploymentSessionImpl.java:71)
> at org.apache.felix.deploymentadmin.DeploymentAdminImpl.installDeploymentPackage(DeploymentAdminImpl.java:215)
>
>
> Tried various simpler autoconf.xml files even some out of the compendium (just to see if I can get a different error besides
> the parsing error) but can't get can't get passed the above parsing error. I can get cruder parsing errors but the one above
> is one that is thrown if no metadata is produced.
This should work. Again, from memory, I do remember some examples in the spec being wrong. This should work! To better debug it, I don't have any advice beyond actually running it in a debugger and tracing through the code that way.
> Perhaps I am doing something glaringly wrong?
No, you're on the right path.
Within luminis we use a GUI to edit these configurations, so I quickly used it to generate an example:
<?xml version="1.0" encoding="UTF-8"?>
<MetaData xmlns:metatype="http://www.osgi.org/xmlns/metatype/v1.0.0">
<OCD name="ocd" id="ocd">
<AD id="firstName" type="STRING" cardinality="0" />
<AD id="lastName" type="STRING" cardinality="0" />
</OCD>
<Designate pid="myfirstpid" factoryPid="" bundle="mybundle" merge="false" optional="false">
<Object ocdref="ocd">
<Attribute adref="firstName">
<Value><![CDATA[Marcel]]></Value>
</Attribute>
<Attribute adref="lastName">
<Value><![CDATA[Offermans]]></Value>
</Attribute>
</Object>
</Designate>
</MetaData>
Let me know if you have more luck with this one (you probably need to edit it a bit so it applies to the right bundle, etc.
> Sorry if I am outside the scope of Ace and into a more generic
> discussion of Deployment Admin.
It's in scope as far as I'm concerned. We initially developed and donated the DA implementation to Apache Felix because at that time, ACE did not exist as an open source project yet (and it makes sense because it's a compendium service, so Felix is a great place to maintain that). However, it's an important part of ACE so I do think it's in scope to discuss it here.
Greetings, Marcel
Re: Getting Started problems with Ace WebUI
Posted by "John E. Conlon" <jc...@verticon.com>.
Hello Macel,
see in line comments.
Marcel Offermans wrote:
> Hello John,
>
> On Jan 27, 2010, at 21:46 , John E. Conlon wrote:
>
>
>> Angelo van der Sijpt wrote:
>>
>>> Hm, this could be something with the web ui. Could you try some other
>>> browser?
>>>
>>>
>> Yes.
>> Tried IE 7.0 from a windows xp, but could never see any labels for artifacts, features, or targets. Ouch.
>> So I installed another firefox on that windows box, and I could see the labels for the elements but like my Firefox on the Ubuntu machine I could not associate lower level elements to parents. ???
>>
>> Perhaps my server is hosed? What is the best way to clean my webui bundle to start the server fresh?
>>
>
> Starting the server fresh is a matter of removing the "cache" directory (which is the bundle cache) and optionally also clearing out the "store" directory (if you want to remove all bundles from the bundle repository). I'd recommend just clearing the cache.
>
>
>> I only guessing what the Retrieve Store and Revert buttons mean,
>>
>
> Look at the UI as a client that works similar to how you work with a SVN/CVS repository. Retrieve the latest version from the server when you start working, and store it to send it back to the server (which triggers the actual update process). Revert speaks for itself I guess. :)
>
>
>> not so sure about the Target Static/Dynamic label.
>>
>
> Static/dynamic is a toggle that determines what type of associations are created between artifacts and features.
> If set to dynamic, whenever you associate a feature to an artifact, it will point to the highest version of that artifact. That allows you to quickly deploy a new version of a bundle for example. If set to static, the association will keep pointing to exactly the version you associated it with. If you want to move to a new version, you have to remove the existing association and create a new one.
>
>
>> My target is the example one and it displays as 'configuredGatewayID - IDLE'.
>>
>
> That's good. IDLE is the state, and it's what you will usually see. When doing big updates over slow networks, you might actually catch targets being in different states. If an update fails, it signals so there too.
>
>
>>> Autoconf files (or any other artifact that is not a bundle) are not yet
>>> supported.
>>> That is, the client (the bundles that know how to communicate with the
>>> server) supports this, but the web ui does not show these features yet.
>>> https://issues.apache.org/jira/browse/ACE-53 has already been created for
>>> this.
>>>
>>>
>> Looked at ACE-53 and saw your comment on AutoConf. If I use the filebased server and add to my target the org.apache.felix.deployment.rp.autoconf-0.1.0-SNAPSHOT.jar do you think I can drop in an autoconf.xml file in my folder and it will deploy to the target??
>>
>
> From memory, I think you will need to manually include the resource processor for AutoConf too.
Did you mean manually install the autoConf on the target gateway?
To become more familiar with DeploymentAdmin, configs and the ACE
backend, I decided to experiment with a real deployment package and
install it on the gateway through a felix.webconsole. On the target
gateway I installed the following bundles:
org.apache.felix.dependencymanager.jar
org.apache.felix.deploymentadmin-0.9.0-SNAPSHOT.jar
org.apache.felix.deployment.rp.autoconf-0.1.0-SNAPSHOT.jar
/org.apache.felix.webconsole-2.0.6.jar
When I try to load a deployment package that contains an resource like:
Name: autoconf.xml
Resource-Processor: org.osgi.deployment.rp.autoconf
I get a:
org.osgi.service.deploymentadmin.DeploymentException: Resource processor
for resource 'autoconf.xml' belongs to foreign deployment package
(Seems to me that it should work because it is not associated with a
foriegn deployment package it is just installed normally on the framework. )
If I take the resource processor off my target gateway and include it in
my deployment package I get passed the above error but I keep getting:
org.osgi.service.deploymentadmin.spi.ResourceProcessorException:
Supplied configuration is not conform the metatype xml specification.
at
org.apache.felix.deployment.rp.autoconf.AutoConfResourceProcessor.process(AutoConfResourceProcessor.java:98)
at
org.apache.felix.deploymentadmin.spi.ProcessResourceCommand.execute(ProcessResourceCommand.java:92)
at
org.apache.felix.deploymentadmin.spi.DeploymentSessionImpl.call(DeploymentSessionImpl.java:71)
at
org.apache.felix.deploymentadmin.DeploymentAdminImpl.installDeploymentPackage(DeploymentAdminImpl.java:215)
Tried various simpler autoconf.xml files even some out of the compendium
(just to see if I can get a different error besides
the parsing error) but can't get can't get passed the above parsing
error. I can get cruder parsing errors but the one above
is one that is thrown if no metadata is produced.
Perhaps I am doing something glaringly wrong?
Sorry if I am outside the scope of Ace and into a more generic
discussion of Deployment Admin.
best regards,
John
> The web UI (when we add that feature) should do that for you automatically, so whenever you deploy an autoconf.xml file to a target, it will ship the resource processor for you.
>
> Greetings, Marcel
>
>
>
>
Re: Getting Started problems with Ace WebUI
Posted by Marcel Offermans <ma...@luminis.nl>.
Hello John,
On Jan 27, 2010, at 21:46 , John E. Conlon wrote:
> Angelo van der Sijpt wrote:
>> Hm, this could be something with the web ui. Could you try some other
>> browser?
>>
> Yes.
> Tried IE 7.0 from a windows xp, but could never see any labels for artifacts, features, or targets. Ouch.
> So I installed another firefox on that windows box, and I could see the labels for the elements but like my Firefox on the Ubuntu machine I could not associate lower level elements to parents. ???
>
> Perhaps my server is hosed? What is the best way to clean my webui bundle to start the server fresh?
Starting the server fresh is a matter of removing the "cache" directory (which is the bundle cache) and optionally also clearing out the "store" directory (if you want to remove all bundles from the bundle repository). I'd recommend just clearing the cache.
> I only guessing what the Retrieve Store and Revert buttons mean,
Look at the UI as a client that works similar to how you work with a SVN/CVS repository. Retrieve the latest version from the server when you start working, and store it to send it back to the server (which triggers the actual update process). Revert speaks for itself I guess. :)
> not so sure about the Target Static/Dynamic label.
Static/dynamic is a toggle that determines what type of associations are created between artifacts and features.
If set to dynamic, whenever you associate a feature to an artifact, it will point to the highest version of that artifact. That allows you to quickly deploy a new version of a bundle for example. If set to static, the association will keep pointing to exactly the version you associated it with. If you want to move to a new version, you have to remove the existing association and create a new one.
> My target is the example one and it displays as 'configuredGatewayID - IDLE'.
That's good. IDLE is the state, and it's what you will usually see. When doing big updates over slow networks, you might actually catch targets being in different states. If an update fails, it signals so there too.
>> Autoconf files (or any other artifact that is not a bundle) are not yet
>> supported.
>> That is, the client (the bundles that know how to communicate with the
>> server) supports this, but the web ui does not show these features yet.
>> https://issues.apache.org/jira/browse/ACE-53 has already been created for
>> this.
>>
> Looked at ACE-53 and saw your comment on AutoConf. If I use the filebased server and add to my target the org.apache.felix.deployment.rp.autoconf-0.1.0-SNAPSHOT.jar do you think I can drop in an autoconf.xml file in my folder and it will deploy to the target??
From memory, I think you will need to manually include the resource processor for AutoConf too. The web UI (when we add that feature) should do that for you automatically, so whenever you deploy an autoconf.xml file to a target, it will ship the resource processor for you.
Greetings, Marcel
Re: Getting Started problems with Ace WebUI
Posted by "John E. Conlon" <jc...@verticon.com>.
Hi Angelo,
Angelo van der Sijpt wrote:
> Hm, this could be something with the web ui. Could you try some other
> browser?
>
Yes.
Tried IE 7.0 from a windows xp, but could never see any labels for
artifacts, features, or targets. Ouch.
So I installed another firefox on that windows box, and I could see the
labels for the elements but like my Firefox on the Ubuntu machine I
could not associate lower level elements to parents. ???
Perhaps my server is hosed? What is the best way to clean my webui
bundle to start the server fresh?
I only guessing what the Retrieve Store and Revert buttons mean, not so
sure about the Target Static/Dynamic label. My target is the example one
and it displays as 'configuredGatewayID - IDLE'.
> Autoconf files (or any other artifact that is not a bundle) are not yet
> supported.
> That is, the client (the bundles that know how to communicate with the
> server) supports this, but the web ui does not show these features yet.
> https://issues.apache.org/jira/browse/ACE-53 has already been created for
> this.
>
Looked at ACE-53 and saw your comment on AutoConf.
If I use the filebased server and add to my target the
org.apache.felix.deployment.rp.autoconf-0.1.0-SNAPSHOT.jar do you think
I can drop in an autoconf.xml file in my folder and it will deploy to
the target??
thanks, John
> Angelo
>
> On Wed, Jan 27, 2010 at 6:42 PM, John E. Conlon <jc...@verticon.com>wrote:
>
>
>> Hi Ace Team,
>>
>> I'm a new user trying to come up to speed on ACE and OSGi's Deployment
>> Admin and have a few new user questions regarding the getting started on the
>> web ui and Ace/DeployAdmin.
>>
>> Test drive File based - ok
>> Was able to startup the file based server (target/dev-server-filebased) and
>> the 'target' (deploy/target/dev-gateway) and see bundle resources
>> installed, updated, and deleted as artifacts on the target. Cool stuff.
>>
>>
>> Test drive WebUI - problems
>> Had problems when I tested out the target/dev-server-webui though. While I
>> could add an artifact, feature, and distribution and I could see my target,
>> I could not associate artifacts with features, nor features with
>> distributions, nor distributions with my target. Dragging one to the other
>> does not seem to work on my Ubuntu Firefox 3.5.7 browser. Any tips on how I
>> can get this working?
>>
>> Ace and Deployment Admin
>> Besides bundle resources (aka artifacts) how can I deploy autoconf
>> processed resources or more generic processed resources and customizer
>> bundles?
>>
>> thanks for any help,
>> John
>>
>>
>>
>>
>>
>
>
Re: Getting Started problems with Ace WebUI
Posted by Angelo van der Sijpt <an...@luminis.nl>.
Hm, this could be something with the web ui. Could you try some other
browser?
Autoconf files (or any other artifact that is not a bundle) are not yet
supported.
That is, the client (the bundles that know how to communicate with the
server) supports this, but the web ui does not show these features yet.
https://issues.apache.org/jira/browse/ACE-53 has already been created for
this.
Angelo
On Wed, Jan 27, 2010 at 6:42 PM, John E. Conlon <jc...@verticon.com>wrote:
> Hi Ace Team,
>
> I'm a new user trying to come up to speed on ACE and OSGi's Deployment
> Admin and have a few new user questions regarding the getting started on the
> web ui and Ace/DeployAdmin.
>
> Test drive File based - ok
> Was able to startup the file based server (target/dev-server-filebased) and
> the 'target' (deploy/target/dev-gateway) and see bundle resources
> installed, updated, and deleted as artifacts on the target. Cool stuff.
>
>
> Test drive WebUI - problems
> Had problems when I tested out the target/dev-server-webui though. While I
> could add an artifact, feature, and distribution and I could see my target,
> I could not associate artifacts with features, nor features with
> distributions, nor distributions with my target. Dragging one to the other
> does not seem to work on my Ubuntu Firefox 3.5.7 browser. Any tips on how I
> can get this working?
>
> Ace and Deployment Admin
> Besides bundle resources (aka artifacts) how can I deploy autoconf
> processed resources or more generic processed resources and customizer
> bundles?
>
> thanks for any help,
> John
>
>
>
>