ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John E. Conlon" <jcon...@verticon.com>
Subject Re: Getting Started problems with Ace WebUI
Date Thu, 28 Jan 2010 02:15:32 GMT
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
>
>
>
>   



Mime
View raw message