You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Mike Ottinger <mo...@tacitknowledge.com> on 2011/04/25 09:16:09 UTC

ParseException in serviceComponents.xml when using 'updated' attribute of @Reference annotation

Hi All,

 The subject line about says it all:

	I'm using scr annotations version 1.5.0, the scr plugin is version 1.7.0. I've placed a org.apache.felix.scr.annotations.Reference annotation on a dependency in my component and gave it a updated="update" attribute. I pulled out of a JIRA item in the Felix group a note about setting my specVersion = "1.1-felix", this got me past a maven error. But once I'm past that and the bundle is deployed to Felix, I get the stacktrace below.

	The updated attribute of the org.apache.felix.scr.annotations.Reference annotation doesn't seem to be documented anywhere. I discovered this by going through the source code. Any ideas on how to get to the bottom of this? I've pored over the source code for the KXml2SAXParser.parseXML method from the stacktrace, nothing seems apparent.

	If I shouldn't be using this updated attribute, can someone send me in the right direction on allowing a component to be informed when a reference's configuration has changed? Seemed like the updated attribute was my ticket. Should I be using the Dependency Manager annotations described here: http://felix.apache.org/site/apache-felix-dependency-manager-using-annotations.html ?

	General problem with descriptor entry '/OSGI-INF/serviceComponents.xml' (org.apache.felix.scr.impl.parser.ParseException: Exception during parsing) org.apache.felix.scr.impl.parser.ParseException: Exception during parsing
	at org.apache.felix.scr.impl.metadata.XmlHandler.startElement(XmlHandler.java:333)
	at org.apache.felix.scr.impl.parser.KXml2SAXParser.parseXML(KXml2SAXParser.java:73)
	at org.apache.felix.scr.impl.BundleComponentActivator.loadDescriptor(BundleComponentActivator.java:227)
	at org.apache.felix.scr.impl.BundleComponentActivator.initialize(BundleComponentActivator.java:147)
	at org.apache.felix.scr.impl.BundleComponentActivator.<init>(BundleComponentActivator.java:111)
	at org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:285)
	at org.apache.felix.scr.impl.Activator.bundleChanged(Activator.java:203)
	at org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:807)
	at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:729)
	at org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:610)
	at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:3724)
	at org.apache.felix.framework.Felix.startBundle(Felix.java:1772)
	at org.apache.felix.framework.Felix$RefreshHelper.restart(Felix.java:4498)
	at org.apache.felix.framework.Felix.refreshPackages(Felix.java:3554)
	at org.apache.felix.framework.PackageAdminImpl.run(PackageAdminImpl.java:336)
	at java.lang.Thread.run(Thread.java:619) 

Thanks!

___________________________
Mike Ottinger
Senior Consultant
Tacit Knowledge - San Francisco
925-330-9002


Re: ParseException in serviceComponents.xml when using 'updated' attribute of @Reference annotation

Posted by Mike Ottinger <mo...@tacitknowledge.com>.
Thanks so much Pierre, great info in here.

I've devised an alternative approach to get around the below. I'll be keen to see what comes of this, whether this is bug or not, it'd be a great way to simplify some of my classes.

Thanks again!

On Apr 25, 2011, at 5:55 AM, Pierre De Rop wrote:

> @Mike ->
> 
> Hi Mike;
> Let's see if I correctly understand your use case (I think that your post is
> also related to your previous one which subject is "Accessing all of the
> configurations of a configuration factory" ; right ?)
> 
> So, you would like to:
> 
> 1) create some DS components from webconsole, using a factory configuration.
> (to do so, you then have to set the property "ds.factory.enabled=true" in
> the felix config.properties, because it is not a standard DS feature).
> 
> 2) and let a separate component be notified when you change one of the
> component configuration (the ones created with a factory configuration, from
> webconsone).
> Is this correct ?
> 
> So, I think that you are right to try to use the "updated" callback, because
> this callback allows to notify a Referencing service when the Referenced
> service properties are changed.
> (be maybe Felix will do another suggestion, or may be I don't correctly
> understand your use case ?)
> 
> Now, I tried a sample code which does what I described, and I then get the
> same exception as you. So, may be you have uncovered a bug (see the
> following below, which is addressed to Felix Meschberger).
> 
> 
> @Felix ->
> Hi Felix,
> 
> Not sure if I am correct, but it seems that there is a mismatch between the
> spec version generated by the scrplugin and the spec version used by the scr
> implementation: indeed, when a component is using "spec=1.1-felix" (in order
> to use the new "updated" method), then the scrplugin is generating the
> following namespace (see the constant NAMESPACE_URI_1_1_FELIX, in scrplugin
> ComponentDescriptorIO.java):
> 
> public static final String NAMESPACE_URI_1_1_FELIX = "
> http://www.osgi.org/xmlns/scr/v1.1.0-felix";
> 
> However,, the scr runtime seems to expect the following (different) name
> space (see XmlHandler.java, in constant NAMESPACE_URI_1_1_FELIX)
> 
> public static final String NAMESPACE_URI_1_1_FELIX = "
> http://felix.apache.org/xmlns/scr/v1.1.0-felix";
> 
> So, if I patch for example the scrplugin and manage to use the same name
> space as the scr runtime (http://felix.apache.org/xmlns/scr/v1.1.0-felix),
> then the exception disappears, and everything is working fine.
> 
> I have patched org.apache.felix.scrplugin.xml.ComponentDescriptorIO.java and
> modified the following constant like this:
> 
>    public static final String NAMESPACE_URI_1_1_FELIX = "
> http://felix.apache.org/xmlns/scr/v1.1.0-felix";
> 
> Am I correct ? If true, then should a Jira issue be opened for the scrplugin
> ? (or for the scr) ?
> 
> @Mike ->
> 
> So, with the scrplugin patch above, then your use case seems to work.
> For example: here is ServiceImpl component with configurationFactory = true:
> 
> @Component(immediate = true,
>           metatype = true,
>           description = "ServiceImpl Configuration",
>           label = "ServiceImpl",
>           policy = ConfigurationPolicy.REQUIRE,
>           configurationFactory = true)
> @Service
> public class ServiceImpl implements ServiceInterface
> {
>    @Property(description = "ServiceImpl property",
>              name = "property",
>              label = "Property",
>              value = { "FOO" },
>              cardinality = 0)
>    private final static String PROPERTY = "property";
> 
>    @Activate
>    protected void start(Map<?,?> config)
>    {
>        System.out.println("ServiceImpl.start: configuration = " +
> config.get(PROPERTY));
>    }
> 
>    @Modified
>    protected void modified(Map<?,?> config)
>    {
>        System.out.println("ServiceImpl.modified: configuration = " +
> config.get(PROPERTY));
>    }
> 
>    public void doService()
>    {
>    }
> }
> 
> and here is the separate component which has a reference over every
> ServiceImpl service instances, and which is also using an "updated"
> callback:
> 
> @Component(specVersion = "1.1-felix")
> public class ServiceImpl2
> {
>    @Reference(policy = ReferencePolicy.DYNAMIC,
>               cardinality=ReferenceCardinality.MANDATORY_MULTIPLE,
>               bind="bind",
>               updated="updated")
>    ServiceInterface m_serviceInterface;
> 
>    protected void bind(ServiceInterface si, Map<?, ?> config)
>    {
>        System.out.println("ServiceImpl2.bind:" + si + " with config: " +
> config);
>    }
> 
>    protected void unbind(ServiceInterface si, Map<?, ?> config)
>    {
>        System.out.println("ServiceImpl2.unbind:" + si + " with config: " +
> config);
>    }
> 
>    protected void updated(ServiceInterface si, Map<?, ?> config)
>    {
>        System.out.println("ServiceImpl2.Updated: " + si + " with config: "
> + config);
>    }
> 
>    @Activate
>    void start()
>    {
>        System.out.println("ServiceImpl2.Start");
>    }
> 
>    @Deactivate
>    void stop()
>    {
>        System.out.println("ServiceImpl2.Stop");
>    }
> }
> 
> Before testing, make sure you have set "ds.factory.enabled=true" in your
> felix "config.properties" (because the "updated" callback is not a standard
> feature).
> Then, from webconsole, create one ServiceImpl factory configuration, and
> then update it; and finally the ServiceImpl2.updated method is invoked, thus
> notifying that the ServiceImpl service properties are updated ...
> 
> Regarding DependencyManager, its is a different framework than DS, but it
> also allows to listen to service properties updates.
> Here is the similar example as above, but with dependencymanager:
> 
> /**
> * This component is instantiated when a factory configuration is created
> from webconsole
> */
> @FactoryConfigurationAdapterService(
>     propagate=true,
>     updated="modified",
>     heading="ServiceImpl Configuration",
>     description="Declare here a configuration, allowing to instantiate a
> ServiceImpl service instance",
>     metadata={
>            @PropertyMetaData(heading="ServiceImpl property",
>                              description="ServiceImpl property
> description.",
>                              defaults={"FOO"},
>                              id="property",
>                              cardinality=0)
>    })
> public class ServiceImpl implements ServiceInterface
> {
>    @Start
>    void start()
>    {
>        System.out.println("ServiceImpl.Start");
>    }
> 
>    void modified(Dictionary<?, ?> config)
>    {
>        // method called when our configuration has changed
>        System.out.println("ServiceImpl.modified: " +
> config.get("property"));
>    }
> 
>    public void doService()
>    {
>    }
> }
> 
> 
> /**
> * This component refers to all ServiceImpl components, and also tracks
> ServiceImpl service properties updates
> */
> @Component
> public class ServiceImpl2
> {
>    @ServiceDependency(changed="updated")
>    void bind(Map<?, ?> serviceProperties, ServiceInterface service)
>    {
>        System.out.println("ServiceImpl2.bind: property=" +
> serviceProperties.get("property") +
>                           ", service=" + service);
>    }
> 
>    void updated(Map<?, ?> serviceProperties, ServiceInterface service)
>    {
>        System.out.println("ServiceImpl2.updated: property=" +
> serviceProperties.get("property") +
>                           ", service=" + service);
>    }
> }
> 
> 
> Kind Regards;
> /pierre
> 
> 
> 
> 
> On Mon, Apr 25, 2011 at 9:16 AM, Mike Ottinger <mottinger@tacitknowledge.com
>> wrote:
> 
>> Hi All,
>> 
>> The subject line about says it all:
>> 
>>       I'm using scr annotations version 1.5.0, the scr plugin is version
>> 1.7.0. I've placed a org.apache.felix.scr.annotations.Reference annotation
>> on a dependency in my component and gave it a updated="update" attribute. I
>> pulled out of a JIRA item in the Felix group a note about setting my
>> specVersion = "1.1-felix", this got me past a maven error. But once I'm past
>> that and the bundle is deployed to Felix, I get the stacktrace below.
>> 
>>       The updated attribute of the
>> org.apache.felix.scr.annotations.Reference annotation doesn't seem to be
>> documented anywhere. I discovered this by going through the source code. Any
>> ideas on how to get to the bottom of this? I've pored over the source code
>> for the KXml2SAXParser.parseXML method from the stacktrace, nothing seems
>> apparent.
>> 
>>       If I shouldn't be using this updated attribute, can someone send me
>> in the right direction on allowing a component to be informed when a
>> reference's configuration has changed? Seemed like the updated attribute was
>> my ticket. Should I be using the Dependency Manager annotations described
>> here:
>> http://felix.apache.org/site/apache-felix-dependency-manager-using-annotations.html?
>> 
>>       General problem with descriptor entry
>> '/OSGI-INF/serviceComponents.xml'
>> (org.apache.felix.scr.impl.parser.ParseException: Exception during parsing)
>> org.apache.felix.scr.impl.parser.ParseException: Exception during parsing
>>       at
>> org.apache.felix.scr.impl.metadata.XmlHandler.startElement(XmlHandler.java:333)
>>       at
>> org.apache.felix.scr.impl.parser.KXml2SAXParser.parseXML(KXml2SAXParser.java:73)
>>       at
>> org.apache.felix.scr.impl.BundleComponentActivator.loadDescriptor(BundleComponentActivator.java:227)
>>       at
>> org.apache.felix.scr.impl.BundleComponentActivator.initialize(BundleComponentActivator.java:147)
>>       at
>> org.apache.felix.scr.impl.BundleComponentActivator.<init>(BundleComponentActivator.java:111)
>>       at
>> org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:285)
>>       at
>> org.apache.felix.scr.impl.Activator.bundleChanged(Activator.java:203)
>>       at
>> org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:807)
>>       at
>> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:729)
>>       at
>> org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:610)
>>       at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:3724)
>>       at org.apache.felix.framework.Felix.startBundle(Felix.java:1772)
>>       at
>> org.apache.felix.framework.Felix$RefreshHelper.restart(Felix.java:4498)
>>       at org.apache.felix.framework.Felix.refreshPackages(Felix.java:3554)
>>       at
>> org.apache.felix.framework.PackageAdminImpl.run(PackageAdminImpl.java:336)
>>       at java.lang.Thread.run(Thread.java:619)
>> 
>> Thanks!
>> 
>> ___________________________
>> Mike Ottinger
>> Senior Consultant
>> Tacit Knowledge - San Francisco
>> 925-330-9002
>> 
>> 

___________________________
Mike Ottinger
Senior Consultant
Tacit Knowledge - San Francisco
925-330-9002


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Re: ParseException in serviceComponents.xml when using 'updated' attribute of @Reference annotation

Posted by Pierre De Rop <pi...@gmail.com>.
@Mike ->

Hi Mike;
Let's see if I correctly understand your use case (I think that your post is
also related to your previous one which subject is "Accessing all of the
configurations of a configuration factory" ; right ?)

So, you would like to:

1) create some DS components from webconsole, using a factory configuration.
(to do so, you then have to set the property "ds.factory.enabled=true" in
the felix config.properties, because it is not a standard DS feature).

2) and let a separate component be notified when you change one of the
component configuration (the ones created with a factory configuration, from
webconsone).
Is this correct ?

So, I think that you are right to try to use the "updated" callback, because
this callback allows to notify a Referencing service when the Referenced
service properties are changed.
(be maybe Felix will do another suggestion, or may be I don't correctly
understand your use case ?)

Now, I tried a sample code which does what I described, and I then get the
same exception as you. So, may be you have uncovered a bug (see the
following below, which is addressed to Felix Meschberger).


@Felix ->
Hi Felix,

Not sure if I am correct, but it seems that there is a mismatch between the
spec version generated by the scrplugin and the spec version used by the scr
implementation: indeed, when a component is using "spec=1.1-felix" (in order
to use the new "updated" method), then the scrplugin is generating the
following namespace (see the constant NAMESPACE_URI_1_1_FELIX, in scrplugin
ComponentDescriptorIO.java):

public static final String NAMESPACE_URI_1_1_FELIX = "
http://www.osgi.org/xmlns/scr/v1.1.0-felix";

However,, the scr runtime seems to expect the following (different) name
space (see XmlHandler.java, in constant NAMESPACE_URI_1_1_FELIX)

public static final String NAMESPACE_URI_1_1_FELIX = "
http://felix.apache.org/xmlns/scr/v1.1.0-felix";

So, if I patch for example the scrplugin and manage to use the same name
space as the scr runtime (http://felix.apache.org/xmlns/scr/v1.1.0-felix),
then the exception disappears, and everything is working fine.

I have patched org.apache.felix.scrplugin.xml.ComponentDescriptorIO.java and
modified the following constant like this:

    public static final String NAMESPACE_URI_1_1_FELIX = "
http://felix.apache.org/xmlns/scr/v1.1.0-felix";

Am I correct ? If true, then should a Jira issue be opened for the scrplugin
? (or for the scr) ?

@Mike ->

So, with the scrplugin patch above, then your use case seems to work.
For example: here is ServiceImpl component with configurationFactory = true:

@Component(immediate = true,
           metatype = true,
           description = "ServiceImpl Configuration",
           label = "ServiceImpl",
           policy = ConfigurationPolicy.REQUIRE,
           configurationFactory = true)
@Service
public class ServiceImpl implements ServiceInterface
{
    @Property(description = "ServiceImpl property",
              name = "property",
              label = "Property",
              value = { "FOO" },
              cardinality = 0)
    private final static String PROPERTY = "property";

    @Activate
    protected void start(Map<?,?> config)
    {
        System.out.println("ServiceImpl.start: configuration = " +
config.get(PROPERTY));
    }

    @Modified
    protected void modified(Map<?,?> config)
    {
        System.out.println("ServiceImpl.modified: configuration = " +
config.get(PROPERTY));
    }

    public void doService()
    {
    }
}

and here is the separate component which has a reference over every
ServiceImpl service instances, and which is also using an "updated"
callback:

@Component(specVersion = "1.1-felix")
public class ServiceImpl2
{
    @Reference(policy = ReferencePolicy.DYNAMIC,
               cardinality=ReferenceCardinality.MANDATORY_MULTIPLE,
               bind="bind",
               updated="updated")
    ServiceInterface m_serviceInterface;

    protected void bind(ServiceInterface si, Map<?, ?> config)
    {
        System.out.println("ServiceImpl2.bind:" + si + " with config: " +
config);
    }

    protected void unbind(ServiceInterface si, Map<?, ?> config)
    {
        System.out.println("ServiceImpl2.unbind:" + si + " with config: " +
config);
    }

    protected void updated(ServiceInterface si, Map<?, ?> config)
    {
        System.out.println("ServiceImpl2.Updated: " + si + " with config: "
+ config);
    }

    @Activate
    void start()
    {
        System.out.println("ServiceImpl2.Start");
    }

    @Deactivate
    void stop()
    {
        System.out.println("ServiceImpl2.Stop");
    }
}

Before testing, make sure you have set "ds.factory.enabled=true" in your
felix "config.properties" (because the "updated" callback is not a standard
feature).
Then, from webconsole, create one ServiceImpl factory configuration, and
then update it; and finally the ServiceImpl2.updated method is invoked, thus
notifying that the ServiceImpl service properties are updated ...

Regarding DependencyManager, its is a different framework than DS, but it
also allows to listen to service properties updates.
Here is the similar example as above, but with dependencymanager:

/**
 * This component is instantiated when a factory configuration is created
from webconsole
 */
@FactoryConfigurationAdapterService(
     propagate=true,
     updated="modified",
     heading="ServiceImpl Configuration",
     description="Declare here a configuration, allowing to instantiate a
ServiceImpl service instance",
     metadata={
            @PropertyMetaData(heading="ServiceImpl property",
                              description="ServiceImpl property
description.",
                              defaults={"FOO"},
                              id="property",
                              cardinality=0)
    })
public class ServiceImpl implements ServiceInterface
{
    @Start
    void start()
    {
        System.out.println("ServiceImpl.Start");
    }

    void modified(Dictionary<?, ?> config)
    {
        // method called when our configuration has changed
        System.out.println("ServiceImpl.modified: " +
config.get("property"));
    }

    public void doService()
    {
    }
}


/**
 * This component refers to all ServiceImpl components, and also tracks
ServiceImpl service properties updates
 */
@Component
public class ServiceImpl2
{
    @ServiceDependency(changed="updated")
    void bind(Map<?, ?> serviceProperties, ServiceInterface service)
    {
        System.out.println("ServiceImpl2.bind: property=" +
serviceProperties.get("property") +
                           ", service=" + service);
    }

    void updated(Map<?, ?> serviceProperties, ServiceInterface service)
    {
        System.out.println("ServiceImpl2.updated: property=" +
serviceProperties.get("property") +
                           ", service=" + service);
    }
}


Kind Regards;
/pierre




On Mon, Apr 25, 2011 at 9:16 AM, Mike Ottinger <mottinger@tacitknowledge.com
> wrote:

> Hi All,
>
>  The subject line about says it all:
>
>        I'm using scr annotations version 1.5.0, the scr plugin is version
> 1.7.0. I've placed a org.apache.felix.scr.annotations.Reference annotation
> on a dependency in my component and gave it a updated="update" attribute. I
> pulled out of a JIRA item in the Felix group a note about setting my
> specVersion = "1.1-felix", this got me past a maven error. But once I'm past
> that and the bundle is deployed to Felix, I get the stacktrace below.
>
>        The updated attribute of the
> org.apache.felix.scr.annotations.Reference annotation doesn't seem to be
> documented anywhere. I discovered this by going through the source code. Any
> ideas on how to get to the bottom of this? I've pored over the source code
> for the KXml2SAXParser.parseXML method from the stacktrace, nothing seems
> apparent.
>
>        If I shouldn't be using this updated attribute, can someone send me
> in the right direction on allowing a component to be informed when a
> reference's configuration has changed? Seemed like the updated attribute was
> my ticket. Should I be using the Dependency Manager annotations described
> here:
> http://felix.apache.org/site/apache-felix-dependency-manager-using-annotations.html?
>
>        General problem with descriptor entry
> '/OSGI-INF/serviceComponents.xml'
> (org.apache.felix.scr.impl.parser.ParseException: Exception during parsing)
> org.apache.felix.scr.impl.parser.ParseException: Exception during parsing
>        at
> org.apache.felix.scr.impl.metadata.XmlHandler.startElement(XmlHandler.java:333)
>        at
> org.apache.felix.scr.impl.parser.KXml2SAXParser.parseXML(KXml2SAXParser.java:73)
>        at
> org.apache.felix.scr.impl.BundleComponentActivator.loadDescriptor(BundleComponentActivator.java:227)
>        at
> org.apache.felix.scr.impl.BundleComponentActivator.initialize(BundleComponentActivator.java:147)
>        at
> org.apache.felix.scr.impl.BundleComponentActivator.<init>(BundleComponentActivator.java:111)
>        at
> org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:285)
>        at
> org.apache.felix.scr.impl.Activator.bundleChanged(Activator.java:203)
>        at
> org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:807)
>        at
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:729)
>        at
> org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:610)
>        at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:3724)
>        at org.apache.felix.framework.Felix.startBundle(Felix.java:1772)
>        at
> org.apache.felix.framework.Felix$RefreshHelper.restart(Felix.java:4498)
>        at org.apache.felix.framework.Felix.refreshPackages(Felix.java:3554)
>        at
> org.apache.felix.framework.PackageAdminImpl.run(PackageAdminImpl.java:336)
>        at java.lang.Thread.run(Thread.java:619)
>
> Thanks!
>
> ___________________________
> Mike Ottinger
> Senior Consultant
> Tacit Knowledge - San Francisco
> 925-330-9002
>
>