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 Fri, 29 Jan 2010 01:25:24 GMT
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
>
>


Mime
View raw message