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
