[jira] Commented: (FELIX-1929) getStartLevel() always reports requested start level, not active start level
[ https://issues.apache.org/jira/browse/FELIX-1929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787907#action_12787907 ] Chris Custine commented on FELIX-1929: -- This patch seems to do the the trick perfectly for me and both increments and decrements the active start level as it changes. I didn't see any point in incrementing by +1 when there are no bundles in that startlevel so I just inserted the increment/decrement inside the start/stop blocks. Those are already executed in proper order and have the only reference to what the current start level is (ie, start level of the current bundle). Could one of the framework guys review this and let me know if this looks ok to commit? > getStartLevel() always reports requested start level, not active start level > > > Key: FELIX-1929 > URL: https://issues.apache.org/jira/browse/FELIX-1929 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: felix-2.0.2 >Reporter: Chris Custine >Assignee: Chris Custine >Priority: Minor > Attachments: FELIX-1929.patch > > > Start Level spec for getStartLevel() states: "If the Framework is in the > process of changing the start level this method must return the active start > level if this differs from the requested start level." -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1929) getStartLevel() always reports requested start level, not active start level
[ https://issues.apache.org/jira/browse/FELIX-1929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Custine updated FELIX-1929: - Attachment: FELIX-1929.patch > getStartLevel() always reports requested start level, not active start level > > > Key: FELIX-1929 > URL: https://issues.apache.org/jira/browse/FELIX-1929 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: felix-2.0.2 >Reporter: Chris Custine >Assignee: Chris Custine >Priority: Minor > Attachments: FELIX-1929.patch > > > Start Level spec for getStartLevel() states: "If the Framework is in the > process of changing the start level this method must return the active start > level if this differs from the requested start level." -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Board report due
On 12/8/09 6:50 PM, Sten Roger Sandvik wrote: Yes, HTTP Service (2.0.2) ... and 2.0.4 :-) Ok. It apparently wasn't listed in our news...neither was Gogo, but I remembered that one. :-) -> richard On Tue, Dec 8, 2009 at 10:00 PM, Richard S. Hall wrote: Ok, here is my first pass at the board report for this quarter: http://cwiki.apache.org/confluence/display/FELIX/Board+Report+%282009-12%29 Please help me remember what I am missing by adding it. Thanks. -> richard
Re: Board report due
Yes, HTTP Service (2.0.2) ... and 2.0.4 :-) On Tue, Dec 8, 2009 at 10:00 PM, Richard S. Hall wrote: > Ok, here is my first pass at the board report for this quarter: > > > http://cwiki.apache.org/confluence/display/FELIX/Board+Report+%282009-12%29 > > Please help me remember what I am missing by adding it. Thanks. > > -> richard >
Board report due
Ok, here is my first pass at the board report for this quarter: http://cwiki.apache.org/confluence/display/FELIX/Board+Report+%282009-12%29 Please help me remember what I am missing by adding it. Thanks. -> richard
[jira] Commented: (FELIX-1661) ps is not showing all the bundles
[ https://issues.apache.org/jira/browse/FELIX-1661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787721#action_12787721 ] Richard S. Hall commented on FELIX-1661: Any more feedback on this? > ps is not showing all the bundles > - > > Key: FELIX-1661 > URL: https://issues.apache.org/jira/browse/FELIX-1661 > Project: Felix > Issue Type: Bug > Components: Shell >Affects Versions: shell-1.4.0 > Environment: felix 2.0.0 > Java 1.6.0_15 > OSX 10.5.5 >Reporter: Aaron Zeckoski >Assignee: Richard S. Hall > Fix For: shell-1.6.0 > > > Running ps in felix command shell is not showing all the bundles > -> version > 2.0.0 > -> find cxf >ID StateName > [ 27] [Active ] [1] Apache CXF Bundle Jar (2.3.0.SNAPSHOT) > [ 28] [Active ] [1] CXF Local Discovery Service Bundle > (1.1.0.SNAPSHOT) > [ 29] [Resolved ] [1] CXF Distributed Software Bundle (1.1.0.SNAPSHOT) > -> ps -a > START LEVEL 5 >ID State Level Name > [ 0] [Active ] [0] System Bundle (2.0.0) > [ 1] [Active ] [5] Apache Felix Bundle Repository (1.4.1) > [ 2] [Active ] [5] Apache Felix Shell Service (1.4.0) > [ 3] [Active ] [5] Apache Felix Shell TUI (1.4.0) > [ 4] [Active ] [4] Apache MINA Core (2.0.0.M6) > [ 5] [Active ] [4] OPS4J Pax Web - Service (0.6.0) > [ 6] [Active ] [4] spring-osgi-io (1.2.0) > [ 7] [Active ] [4] spring-osgi-core (1.2.0) > [ 8] [Active ] [4] spring-osgi-extender (1.2.0) > [ 33] [Active ] [3] jettison (1.1) > [ 34] [Active ] [3] Apache Commons IO Bundle (1.4) > [ 35] [Active ] [3] Commons Lang (2.4) > [ 36] [Active ] [3] Commons Codec (1.4) > [ 37] [Active ] [3] Commons Pool (1.5.2) > [ 38] [Active ] [3] Apache Commons FileUpload Bundle (1.2.1) > [ 39] [Active ] [3] Commons Collections (3.2.1) > [ 40] [Active ] [2] Apache ServiceMix Specs :: JAVAMAIL API 1.4 > (1.3.0) > [ 41] [Active ] [2] Apache ServiceMix Specs :: JAXB API 2.1 (1.3.0) > [ 42] [Active ] [2] Apache ServiceMix Specs :: JAXWS API 2.1 (1.3.0) > [ 43] [Active ] [2] Apache ServiceMix Specs :: SAAJ API 1.3 (1.3.0) > [ 44] [Active ] [2] Apache ServiceMix Specs :: STAX API 1.0 (1.3.0) > [ 45] [Active ] [2] Apache ServiceMix Specs :: JSR311 API 1.1 > (1.4.0.SNAPSHOT) > [ 46] [Active ] [2] geronimo-jms_1.1_spec (1.1.1) > [ 47] [Active ] [2] geronimo-jta_1.1_spec (1.1.1) > [ 48] [Active ] [2] geronimo-annotation_1.0_spec (1.1.1) > [ 49] [Active ] [2] geronimo-activation_1.1_spec (1.0.2) > [ 50] [Active ] [2] geronimo-j2ee-connector_1.5_spec (2.0.0) > [ 51] [Active ] [2] geronimo-j2ee-management_1.1_spec (1.0.1) > [ 52] [Active ] [2] geronimo-ws-metadata_2.0_spec (1.1.2) > [ 55] [Active ] [1] OSGi R4 Compendium Bundle (4.1.0) > [ 56] [Active ] [1] Apache Felix Declarative Services (1.0.8) > [ 57] [Active ] [1] Apache Felix Configuration Admin Service (1.0.10) > [ 58] [Active ] [1] Pax ConfMan - Properties Loader (0.2.1) > [ 59] [Active ] [1] OPS4J Pax Logging - API (1.3.0) > [ 60] [Active ] [1] OPS4J Pax Logging - Service (1.3.0) > [ 61] [Active ] [1] Apache Felix EventAdmin (1.0.0) > [ 62] [Active ] [1] Apache Felix File Install (1.2.0) > [ 65] [Active ] [5] opencast-authentication-api (0.1.0.SNAPSHOT) > [ 66] [Active ] [5] opencast-search-service-api (0.1.0.SNAPSHOT) > [ 67] [Active ] [5] opencast-ingest-service-api (0.1.0.SNAPSHOT) > [ 68] [Active ] [5] opencast-workflow-service-impl (0.1.0.SNAPSHOT) > [ 69] [Active ] [5] opencast-http (0.1.0.SNAPSHOT) > [ 70] [Active ] [5] opencast-inspection-service-api (0.1.0.SNAPSHOT) > [ 71] [Active ] [5] opencast-engage-service-impl (0.1.0.SNAPSHOT) > [ 72] [Active ] [5] opencast-search-service-impl (0.1.0.SNAPSHOT) > [ 73] [Active ] [5] opencast-inspection-service-impl (0.1.0.SNAPSHOT) > [ 74] [Active ] [5] opencast-delivery-service-impl (0.1.0.SNAPSHOT) > [ 75] [Active ] [5] opencast-util (0.1.0.SNAPSHOT) > [ 76] [Active ] [5] opencast-workspace-api (0.1.0.SNAPSHOT) > [ 77] [Active ] [5] opencast-media (0.1.0.SNAPSHOT) > [ 78] [Active ] [5] opencast-workspace-impl (0.1.0.SNAPSHOT) > [ 79] [Active ] [5] opencast-ingest-service-impl (0.1.0.SNAPSHOT) > [ 80] [Active ] [5] opencast-notification-service-api > (0.1.0.SNAPSHOT) > [ 81] [Active ] [5] opencast-runtime-info-ui (0.1.0.SNAPSHOT) > [ 82] [Active ] [5] opencast-delivery-service-api (0.1.0.SNAPSHOT) > [ 83] [
[jira] Updated: (FELIX-1929) getStartLevel() always reports requested start level, not active start level
[ https://issues.apache.org/jira/browse/FELIX-1929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Custine updated FELIX-1929: - Assignee: Chris Custine > getStartLevel() always reports requested start level, not active start level > > > Key: FELIX-1929 > URL: https://issues.apache.org/jira/browse/FELIX-1929 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: felix-2.0.2 >Reporter: Chris Custine >Assignee: Chris Custine >Priority: Minor > > Start Level spec for getStartLevel() states: "If the Framework is in the > process of changing the start level this method must return the active start > level if this differs from the requested start level." -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1929) getStartLevel() always reports requested start level, not active start level
[ https://issues.apache.org/jira/browse/FELIX-1929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787587#action_12787587 ] Chris Custine commented on FELIX-1929: -- Fix seems easy enough, I'll attach a patch here for review first. > getStartLevel() always reports requested start level, not active start level > > > Key: FELIX-1929 > URL: https://issues.apache.org/jira/browse/FELIX-1929 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: felix-2.0.2 >Reporter: Chris Custine >Assignee: Chris Custine >Priority: Minor > > Start Level spec for getStartLevel() states: "If the Framework is in the > process of changing the start level this method must return the active start > level if this differs from the requested start level." -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1929) getStartLevel() always reports requested start level, not active start level
getStartLevel() always reports requested start level, not active start level Key: FELIX-1929 URL: https://issues.apache.org/jira/browse/FELIX-1929 Project: Felix Issue Type: Bug Components: Framework Affects Versions: felix-2.0.2 Reporter: Chris Custine Priority: Minor Start Level spec for getStartLevel() states: "If the Framework is in the process of changing the start level this method must return the active start level if this differs from the requested start level." -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1928) File installer starts bundles too early on restart
[ https://issues.apache.org/jira/browse/FELIX-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787578#action_12787578 ] Chris Custine commented on FELIX-1928: -- This fix works just fine in Equinox, but not with Felix. It seems that the call to getStartLevel() returns the requested startlevel even when the framework is still incrementing through the startlevels. I will open a separate issue for that and fix it. > File installer starts bundles too early on restart > -- > > Key: FELIX-1928 > URL: https://issues.apache.org/jira/browse/FELIX-1928 > Project: Felix > Issue Type: Bug > Components: File Install >Affects Versions: fileinstall-2.0.4 >Reporter: Chris Custine >Assignee: Chris Custine > Fix For: fileinstall-2.0.6 > > > File installer will try to start bundles before the proper startlevel has > been reached on startup, leading to problems on restart. Caused by fix for > FELIX-1540. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-1928) File installer starts bundles too early on restart
[ https://issues.apache.org/jira/browse/FELIX-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Custine resolved FELIX-1928. -- Resolution: Fixed Fix Version/s: fileinstall-2.0.6 > File installer starts bundles too early on restart > -- > > Key: FELIX-1928 > URL: https://issues.apache.org/jira/browse/FELIX-1928 > Project: Felix > Issue Type: Bug > Components: File Install >Affects Versions: fileinstall-2.0.4 >Reporter: Chris Custine >Assignee: Chris Custine > Fix For: fileinstall-2.0.6 > > > File installer will try to start bundles before the proper startlevel has > been reached on startup, leading to problems on restart. Caused by fix for > FELIX-1540. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1789) FileInstall is too verbose
[
https://issues.apache.org/jira/browse/FELIX-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787577#action_12787577
]
Guillaume Nodet commented on FELIX-1789:
Sorry, I missed your patch. Let me until tomorrow to review it.
> FileInstall is too verbose
> --
>
> Key: FELIX-1789
> URL: https://issues.apache.org/jira/browse/FELIX-1789
> Project: Felix
> Issue Type: Bug
> Components: File Install
>Affects Versions: fileinstall-2.0.0
> Environment: generic
>Reporter: Sahoo
> Fix For: fileinstall-2.0.6
>
> Attachments: FELIX-1789.txt
>
>
> GlassFish users have commented that FileInstall is too verbose. They suggest
> the initial configuration related messages to be moved to debug level.
> e.g.,
> INFO: {felix.fileinstall.poll (ms) = 5000, felix.fileinstall.dir =
> /space/ss141213/WS/gf/v3/publish/glassfishv3/glassfish/domains/domain1/autodeploy/bundles,
> felix.fileinstall.debug = 1, felix.fileinstall.bundles.new.start = true,
> felix.fileinstall.tmpdir = /tmp/fileinstall, felix.fileinstall.filter = null}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1789) FileInstall is too verbose
[
https://issues.apache.org/jira/browse/FELIX-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787570#action_12787570
]
Richard S. Hall commented on FELIX-1789:
So, does anyone have any feedback on this patch? Should I just go ahead and
commit? I am not a user of File Install, so I'd appreciate some feedback.
> FileInstall is too verbose
> --
>
> Key: FELIX-1789
> URL: https://issues.apache.org/jira/browse/FELIX-1789
> Project: Felix
> Issue Type: Bug
> Components: File Install
>Affects Versions: fileinstall-2.0.0
> Environment: generic
>Reporter: Sahoo
> Fix For: fileinstall-2.0.6
>
> Attachments: FELIX-1789.txt
>
>
> GlassFish users have commented that FileInstall is too verbose. They suggest
> the initial configuration related messages to be moved to debug level.
> e.g.,
> INFO: {felix.fileinstall.poll (ms) = 5000, felix.fileinstall.dir =
> /space/ss141213/WS/gf/v3/publish/glassfishv3/glassfish/domains/domain1/autodeploy/bundles,
> felix.fileinstall.debug = 1, felix.fileinstall.bundles.new.start = true,
> felix.fileinstall.tmpdir = /tmp/fileinstall, felix.fileinstall.filter = null}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1928) File installer starts bundles too early on restart
File installer starts bundles too early on restart -- Key: FELIX-1928 URL: https://issues.apache.org/jira/browse/FELIX-1928 Project: Felix Issue Type: Bug Components: File Install Affects Versions: fileinstall-2.0.4 Reporter: Chris Custine Assignee: Chris Custine File installer will try to start bundles before the proper startlevel has been reached on startup, leading to problems on restart. Caused by fix for FELIX-1540. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-1927) NPE in AbstractComponentManager if no services are provided and a SecurityManager is installed
[
https://issues.apache.org/jira/browse/FELIX-1927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger resolved FELIX-1927.
--
Resolution: Fixed
Thanks again for your patch. I have applied in Rev. 888451.
Can you please check ? Thanks.
> NPE in AbstractComponentManager if no services are provided and a
> SecurityManager is installed
> --
>
> Key: FELIX-1927
> URL: https://issues.apache.org/jira/browse/FELIX-1927
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR)
>Affects Versions: scr-1.2.0
>Reporter: Lukas Kolisko
>Assignee: Felix Meschberger
> Fix For: scr-1.2.2
>
>
> Lukas Kolisko reports in response to FELIX-1827:
> If a service component does not provide any service and system security
> manager is set , then
> AbstractComponentManager.java line 537
> final String[] services =
> getComponentMetadata().getServiceMetadata().getProvides(); fails with NPE
> because ServiceMetadata is null.
> Possible patch:
> Index:
> src/main/java/org/apache/felix/scr/impl/manager/AbstractComponentManager.java
> ===
> ---
> src/main/java/org/apache/felix/scr/impl/manager/AbstractComponentManager.java
> (revision 888421)
> +++
> src/main/java/org/apache/felix/scr/impl/manager/AbstractComponentManager.java
> (working copy)
> @@ -33,6 +33,7 @@
> import org.apache.felix.scr.impl.ComponentActivatorTask;
> import org.apache.felix.scr.impl.metadata.ComponentMetadata;
> import org.apache.felix.scr.impl.metadata.ReferenceMetadata;
> +import org.apache.felix.scr.impl.metadata.ServiceMetadata;
> import org.osgi.framework.Bundle;
> import org.osgi.framework.InvalidSyntaxException;
> import org.osgi.framework.ServicePermission;
> @@ -534,18 +535,22 @@
> boolean allowed = true;
> if ( System.getSecurityManager() != null )
> {
> - final String[] services =
> getComponentMetadata().getServiceMetadata().getProvides();
> - if ( services != null && services.length > 0 )
> + final ServiceMetadata metadata =
> getComponentMetadata().getServiceMetadata();
> + if ( metadata != null )
> {
> - final Bundle bundle = getBundle();
> - for ( int i = 0; i < services.length; i++ )
> + final String[] services = metadata.getProvides();
> + if ( services != null && services.length > 0 )
> {
> - final Permission perm = new ServicePermission( services[i],
> ServicePermission.REGISTER );
> - if ( !bundle.hasPermission( perm ) )
> + final Bundle bundle = getBundle();
> + for ( int i = 0; i < services.length; i++ )
> {
> - log( LogService.LOG_INFO, "Permission to register service {0} is denied",
> new Object[]
> - { services[i] }, null );
> - allowed = false;
> + final Permission perm = new ServicePermission( services[i],
> ServicePermission.REGISTER );
> + if ( !bundle.hasPermission( perm ) )
> + {
> + log( LogService.LOG_INFO, "Permission to register service {0} is denied",
> new Object[]
> + { services[i] }, null );
> + allowed = false;
> + }
> }
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1833) Stopping the Felix SCR bundle may leave traces behind thus preventing the class loader from being GC-ed
[ https://issues.apache.org/jira/browse/FELIX-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-1833. SCR 1.2.0 has been released. Close all issues. > Stopping the Felix SCR bundle may leave traces behind thus preventing the > class loader from being GC-ed > --- > > Key: FELIX-1833 > URL: https://issues.apache.org/jira/browse/FELIX-1833 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-1.2.0 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.2.0 > > > Apart from the ServiceReference issue with Garbage Collection (and clean > system state) described by FELIX-1832, some other cases may happen preventing > proper garbage collection and ultimately classloader removal. > One such case is the ComponentActorThread class which extends Thread. There > are some libraries wich keep references to threads and thus also to the > ComponentActorThread (one such class is the Lucene ClosableThreadLocal > class). This prevents the object from being collected and consequently the > class loader from being collected. > Also there are some fields in the BundleComponentActivator which must be > cleared and -- most notably -- the LogService tracker should be closed and > dropped. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1832) ServiceFactory must not be deactivated if the instances fails to be created
[ https://issues.apache.org/jira/browse/FELIX-1832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-1832. SCR 1.2.0 has been released. Close all issues. > ServiceFactory must not be deactivated if the instances fails to be created > --- > > Key: FELIX-1832 > URL: https://issues.apache.org/jira/browse/FELIX-1832 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-1.2.0 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.2.0 > > > The AbstractComponentManager.Registered state (Satisfied state for delayed > and service factory components) class tries to deactivate the component if > the component instance cannot be created and setup. Part of this deactivation > is actually unregistration of the service factory service. > This may fail if the getService method is called as part of a chain of > service activations, one of which is actually trying to get the service > instance from the factory. It is not allowed to unregister this exact service > in this situation. > So, instead of deactivating the component, the component instance is just > deleted and the component remains in the registered state. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1827) Check permission before getting or registering services
[ https://issues.apache.org/jira/browse/FELIX-1827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-1827. SCR 1.2.0 has been released. Close all issues. > Check permission before getting or registering services > --- > > Key: FELIX-1827 > URL: https://issues.apache.org/jira/browse/FELIX-1827 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR), Specification compliance >Affects Versions: scr-1.2.0 >Reporter: Felix Meschberger > Fix For: scr-1.2.0 > > > The DS specification states in 112.9.3 that SCR has to call > Bundle.hasPermission for the providing bundle when registering or getting > services on behalf of the providing bundle: >SCR does all publishing, finding and binding of services on behalf > of the >component using the Bundle Context of the component's bundle. This >means that normal stack-based permission checks will check SCR and > not >the component's bundle. Since SCR is registering and getting > services on >behalf of a component's bundle, SCR must call the > Bundle.hasPermission >method to validate that a component's bundle has the necessary > permission >to register or get a service. > This is not currently implemented. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1830) Support for DS 1.1 character property type name
[ https://issues.apache.org/jira/browse/FELIX-1830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-1830. SCR 1.2.0 has been released. Close all issues. > Support for DS 1.1 character property type name > --- > > Key: FELIX-1830 > URL: https://issues.apache.org/jira/browse/FELIX-1830 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR), Specification compliance >Affects Versions: scr-1.2.0 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.2.0 > > > DS 1.1 modified the property type name for characters from "Char" to > "Character" to align with the Java class name: > The Char type for the property element has been renamed > Character to match the Java type name (Section 112.11, Changes) > Currently the old type name is still only supported. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1826) ComponentException must be thrown if ComponentFactory.newInstance cannot create a component instance
[ https://issues.apache.org/jira/browse/FELIX-1826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-1826. SCR 1.2.0 has been released. Close all issues. > ComponentException must be thrown if ComponentFactory.newInstance cannot > create a component instance > > > Key: FELIX-1826 > URL: https://issues.apache.org/jira/browse/FELIX-1826 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR), Specification compliance >Affects Versions: scr-1.2.0 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.2.0 > > > If the ComponentFactory.newInstance method cannot create a component > instance, null must not be returned but a ComponentException must be thrown > as described in Section 112.5.5, Factory Component, of the DS Specification: > If SCR is unable to satisfy the component > configuration given the component properties and the Dictionary argument > to newInstance, the newInstance method must throw a > ComponentException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1825) Configurations of delayed components are not deactivated if not used any more
[ https://issues.apache.org/jira/browse/FELIX-1825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-1825. SCR 1.2.0 has been released. Close all issues. > Configurations of delayed components are not deactivated if not used any more > - > > Key: FELIX-1825 > URL: https://issues.apache.org/jira/browse/FELIX-1825 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-1.0.8, scr-1.2.0 >Reporter: Felix Meschberger > Fix For: scr-1.2.0 > > > The Declarative Service specification Section 112.5.4, Delayed Component, > demands that component configurations of delayed which are not used anymore > have to be deactivated: > If the service registered by a component configuration becomes unused > because there are no more bundles using it, then SCR should deactivate > that > component configuration. This allows SCR implementations to eagerly > reclaim activated component configurations. > Currently only component instances created for service factory components are > reclaimed when they are not used anymore. Instances of delayed components are > not reclaimed at the moment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1823) Drop support for Framework API 1.3 (R4.0)
[ https://issues.apache.org/jira/browse/FELIX-1823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-1823. SCR 1.2.0 has been released. Close all issues. > Drop support for Framework API 1.3 (R4.0) > - > > Key: FELIX-1823 > URL: https://issues.apache.org/jira/browse/FELIX-1823 > Project: Felix > Issue Type: Improvement > Components: Declarative Services (SCR) >Affects Versions: scr-1.0.8 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.2.0 > > > By dropping support for Framework API 1.3 (R4.0) we can make easy use of the > following Framework API 1.4 (R4.1) features: >* Bundle.getBundleContext() used to get the bundle context of bundles > providing components >* ServiceReference extends Comparable supporting the service ranking > service property to order references > This simplifies the code a bit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1735) Use system property to provide bundle jar file to integration tests
[ https://issues.apache.org/jira/browse/FELIX-1735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-1735. SCR 1.2.0 has been released. Close all issues. > Use system property to provide bundle jar file to integration tests > --- > > Key: FELIX-1735 > URL: https://issues.apache.org/jira/browse/FELIX-1735 > Project: Felix > Issue Type: Improvement > Components: Declarative Services (SCR) >Affects Versions: scr-1.2.0 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.2.0 > > > Currently the integration tests depend on a hard coded file name for the > bundle JAR file to tests. This file is created in the pre-integration-test by > copying the actual bundle file to the file with the fixed name. It would > probably be better to use a system property to set the name of the bundle jar > file and interpret that in the integration tests. > For ease of use in IDEs the fixed file name can be left as a fallback if the > system property is not set. And the maven project provides a profile which > copies the bundle file after creating it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1530) Extend the SCR introspection API to reflect the new DS 1.1 features
[ https://issues.apache.org/jira/browse/FELIX-1530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-1530. SCR 1.2.0 has been released. Close all issues. > Extend the SCR introspection API to reflect the new DS 1.1 features > --- > > Key: FELIX-1530 > URL: https://issues.apache.org/jira/browse/FELIX-1530 > Project: Felix > Issue Type: Improvement > Components: Declarative Services (SCR) >Affects Versions: scr-1.0.8 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.2.0 > > > The current SCR introspection API in org.apache.felix.scr does not currently > reflect the SCR 1.1 changes targeted for OSGi Compendium 4.2. > Namely the reflection of the configuration-policy, activate, deactivate and > modify attributes of the component element are missing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1733) Disposed components are not removed from the component registry
[ https://issues.apache.org/jira/browse/FELIX-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-1733. SCR 1.2.0 has been released. Close all issues. > Disposed components are not removed from the component registry > --- > > Key: FELIX-1733 > URL: https://issues.apache.org/jira/browse/FELIX-1733 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-1.2.0 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.2.0 > > > Stopping bundles disposes the bundle's components. But the components remain > registered in the component registry. > Listing the components later through the Web Console or the Shell Command > results in NullPointerException because the bundle field of the components > has been set to null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1686) Missing activate or deativate methods show up as Error in LogService
[ https://issues.apache.org/jira/browse/FELIX-1686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-1686. SCR 1.2.0 has been released. Close all issues. > Missing activate or deativate methods show up as Error in LogService > > > Key: FELIX-1686 > URL: https://issues.apache.org/jira/browse/FELIX-1686 > Project: Felix > Issue Type: Improvement > Components: Declarative Services (SCR) >Affects Versions: scr-1.2.0 > Environment: org.apache.felix.scr-1.0.9-SNAPSHOT >Reporter: David Savage >Assignee: Felix Meschberger >Priority: Trivial > Fix For: scr-1.2.0 > > > If no activate or deactivate methods are registered in the xml this is not an > error as activate and deactivate methods are optional. > However complexity arises if user explicitly sets an activate or deactivate > methods in xml as in this case it probably is an error if the method is not > found. > Thought it worth registering this issue as it caused me some confusion when I > saw it and I needed to go digging though the code to figure out that this was > in fact harmless. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1711) Remove OSGi library source from SVN and depend on official R4.2 libraries
[ https://issues.apache.org/jira/browse/FELIX-1711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-1711. SCR 1.2.0 has been released. Close all issues. > Remove OSGi library source from SVN and depend on official R4.2 libraries > - > > Key: FELIX-1711 > URL: https://issues.apache.org/jira/browse/FELIX-1711 > Project: Felix > Issue Type: Task > Components: Declarative Services (SCR) >Affects Versions: scr-1.2.0 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.2.0 > > > Currently we have a copy of an early release of the > org.osgi.service.component.ComponentConstants interface in our repository. > This interface provides the additional constant values for the deactivation > reasons not available previously. > Now that the official R4.2 libraries are available, we should remove the > interface from our repository again and use the official library. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1504) ComponentInstance implementation is reused accross reactivations
[ https://issues.apache.org/jira/browse/FELIX-1504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-1504. SCR 1.2.0 has been released. Close all issues. > ComponentInstance implementation is reused accross reactivations > > > Key: FELIX-1504 > URL: https://issues.apache.org/jira/browse/FELIX-1504 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR), Specification compliance >Affects Versions: scr-1.0.0, scr-1.0.2, scr-1.0.4, scr-1.0.6, scr-1.0.8 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.2.0 > > > According to the specification of the ComponentInstance interface, instances > of this interface must not be reused after a component instance has been > deactivated. > Currently, the ComponentInstance interface is implemented by the > AbstractComponentManager class and thus is not replaced after the > reactivation of a component. > The implementation of the ComponentInstance interface has to be refactored to > reflect the life cycle of the actual component object (the object returned > from ComponentInstance.getInstance(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1674) typo in scr and webconsole - "unsatisifed"
[ https://issues.apache.org/jira/browse/FELIX-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-1674. SCR 1.2.0 has been released. Close all issues. > typo in scr and webconsole - "unsatisifed" > -- > > Key: FELIX-1674 > URL: https://issues.apache.org/jira/browse/FELIX-1674 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR), Web Console >Affects Versions: scr-1.0.8, webconsole-2.0.0 >Reporter: Davanum Srinivas >Assignee: Felix Meschberger >Priority: Minor > Fix For: scr-1.2.0, webconsole-2.0.2 > > > Of the typos, the following do show up either when we connect to felix > command line console or the web console > ./scr/src/main/java/org/apache/felix/scr/impl/ScrCommand.java: > return "unsatisifed"; > ./webconsole/src/main/java/org/apache/felix/webconsole/internal/compendium/ComponentsServlet.java: > return "unsatisifed"; > ./scr/src/main/java/org/apache/felix/scr/impl/manager/ImmediateComponentManager.java: > "Updating the service references caused atleast on reference > to become unsatisifed, deactivating component", > the following are just in the comments > ./scr/src/main/java/org/apache/felix/scr/impl/manager/AbstractComponentManager.java: > * not met, the component is not activated and remains unsatisifed. > ./scr/src/test/java/org/apache/felix/scr/integration/ComponentConfigurationTest.java: > // expect a single unsatisifed component > thanks, > dims -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1714) typo in scr command
[ https://issues.apache.org/jira/browse/FELIX-1714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-1714. SCR 1.2.0 has been released. Close all issues. > typo in scr command > --- > > Key: FELIX-1714 > URL: https://issues.apache.org/jira/browse/FELIX-1714 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-1.0.8 >Reporter: Davanum Srinivas >Assignee: Felix Meschberger >Priority: Trivial > Fix For: scr-1.2.0 > > > Please note the typo "Componnent", should be "Component" > ./scr/src/main/java/org/apache/felix/scr/impl/ScrCommand.java: > out.println( "Componnent " + component.getName() + " disabled" ); > thanks, > dims -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1658) Deadlocks caused by component activation and deactivation
[ https://issues.apache.org/jira/browse/FELIX-1658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-1658. SCR 1.2.0 has been released. Close all issues. > Deadlocks caused by component activation and deactivation > - > > Key: FELIX-1658 > URL: https://issues.apache.org/jira/browse/FELIX-1658 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-1.2.0 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.2.0 > > > Deadlock issues with SCR: Component operations are synchronized and may run > while the bundle lock is held. This may cause deadlocks with the framework > (mostly between the PackageAdmin thread and the SCR Component Actor thread). > The problem is that many operations of SCR are called in a bundle listener > and cause further operations (while holding Java locks (synchronized)) inside > the framework. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1666) Missing support for DS 1.1 specified lazy activation behavior
[ https://issues.apache.org/jira/browse/FELIX-1666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-1666. SCR 1.2.0 has been released. Close all issues. > Missing support for DS 1.1 specified lazy activation behavior > - > > Key: FELIX-1666 > URL: https://issues.apache.org/jira/browse/FELIX-1666 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-1.0.8 >Reporter: Matthew Sykes >Assignee: Felix Meschberger > Fix For: scr-1.2.0 > > Attachments: lazy-bundle-state.diff > > > While attempting to move code from the Equinox implementation of DS to the > Felix implementation, I discovered that the Felix SCR does not seem to > support processing and activation of component configurations that are > declared in bundles awaiting lazy activation. The DS 1.1 specification, > section 112.8.2 indicates that bundles awaiting lazy activation are to be > processed when the SCR starts (and, presumedly by extension, as bundles > bundles are starting/started). > It appears that Felix has implemented most of the DS 1.1 support already so > it appears this is an oversight. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1440) Abort method (binder, activator) method search on non-accessible suitable methods
[ https://issues.apache.org/jira/browse/FELIX-1440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-1440. SCR 1.2.0 has been released. Close all issues. > Abort method (binder, activator) method search on non-accessible suitable > methods > - > > Key: FELIX-1440 > URL: https://issues.apache.org/jira/browse/FELIX-1440 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-1.2.0 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.2.0 > > > The R4.2 draft specification (dated 2009/03/10) states in section 112.8.4, > Locating Component Methods: > If suitable methods are found in a class but none of > the suitable methods are accessible, the search for suitable methods > terminates > with no suitable method having been located. If no suitable methods > are found in a class, the search continues in the superclass. > This means, that as soon as a class would have one or more suitable methods > but none of these is accessible, the search should terminate with no method > found. > Currently the search continues as if no suitable method would have been found > if suitable methods found are not accessible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1443) Unify Method lookup
[ https://issues.apache.org/jira/browse/FELIX-1443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-1443. SCR 1.2.0 has been released. Close all issues. > Unify Method lookup > --- > > Key: FELIX-1443 > URL: https://issues.apache.org/jira/browse/FELIX-1443 > Project: Felix > Issue Type: Improvement > Components: Declarative Services (SCR) >Affects Versions: scr-1.2.0 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.2.0 > > > Currently method lookup for activator and for bind methods is similar but > indication of whether a method is found or not is completely different: > (de)activator method indication is based on a sentinel method while (un)bind > method indication is based on an internal state machine and an object > representing the method to be looked up and called. > It would be good to unify the two approaches to get a single one. FInd > details of method selection remain disctinct due to different requirements > for method signatures. But maybe some coercion is also possible on that level. > Looking at the current two approaches, the new (un)bind method approach > (provided as part of FELIX-924 by Alin Dreghiciu) with a Facade class for > method lookup and invocation looks very promising and might be the base for > this coercion. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1447) Remove ComponentMetadata parameter from AbstractComponentManager.log method signature
[ https://issues.apache.org/jira/browse/FELIX-1447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-1447. SCR 1.2.0 has been released. Close all issues. > Remove ComponentMetadata parameter from AbstractComponentManager.log method > signature > - > > Key: FELIX-1447 > URL: https://issues.apache.org/jira/browse/FELIX-1447 > Project: Felix > Issue Type: Improvement > Components: Declarative Services (SCR) >Affects Versions: scr-1.2.0 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.2.0 > > > The AbstractComponentManager.log method expects a ComponentMetadata object to > enhance logging. This parameter is not required since the component metadata > is available directly from the AbstractComponentManager. Thus this parameter > can be removed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1503) Component Factory instances are not let gone after dispose
[ https://issues.apache.org/jira/browse/FELIX-1503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-1503. SCR 1.2.0 has been released. Close all issues. > Component Factory instances are not let gone after dispose > -- > > Key: FELIX-1503 > URL: https://issues.apache.org/jira/browse/FELIX-1503 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-1.0.6, scr-1.0.8 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.2.0 > > > Component factory instances retrieved with > ComponentFactory.newInstance(Dictionary) are not removed from the internal > maintenance data structure. In the longer run, this prevents the components > from being garbage collected and eat up all memory. > At one time we had a situation of 700'000 disposed ImmediateComponentManager > instances kept in the ComponentFactory internal map -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1416) Wrong factory configuration behaviour
[ https://issues.apache.org/jira/browse/FELIX-1416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-1416. SCR 1.2.0 has been released. Close all issues. > Wrong factory configuration behaviour > - > > Key: FELIX-1416 > URL: https://issues.apache.org/jira/browse/FELIX-1416 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR), Specification compliance >Affects Versions: scr-1.0.8 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.2.0 > > > Currently factory configurations are applied to component factories, such > that each factory configuration instance creates a componnent > instances of a component factory. Reversly deleting a factory configuration > also deletes component instances. This is not how it is specified. > Correct is, that > (1) Component Factories can only be configured with singleton > configurations applying > the configuration to all instances created with newInstance > (2) Factory configurations are applied to non-component-factory components > and > cause multiple component instances to be created. > To accomodate for this, the handling of components has to be redesigned: A > component descriptor now causes the creation of a ComponentHolder. Depending > on configuration availability a ComponentHolder will hold a single component > (no configuration or singleton configuration) or multiple components (factory > configuration). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1437) DS 1.1 signatures for activators and bind methods only available for declaration with new namespace
[ https://issues.apache.org/jira/browse/FELIX-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-1437. SCR 1.2.0 has been released. Close all issues. > DS 1.1 signatures for activators and bind methods only available for > declaration with new namespace > --- > > Key: FELIX-1437 > URL: https://issues.apache.org/jira/browse/FELIX-1437 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-1.0.8 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.2.0 > > > The draft compendium specification (dated 2009/03/10) states: > The additional signatures and additional accessibility for the activate, > deactivate, bind and unbind methods can cause problems for components > written to version 1.0 of this specification. The behaviour in this > specification only applies to component descriptions using the v1.1.0 > name space. > Currently the new method signatures are checked and accepted regardless of > the namespace version of the component declaration. If a component is > declared with a 1.0 namespace declaration, only the original signatures must > be accepted, which are: >* methods must be protected or public >* bind methods take ServiceReference or service object >* activator methods take ComponentContext -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1414) Service ranking is only obeyed on first component activation
[ https://issues.apache.org/jira/browse/FELIX-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-1414. SCR 1.2.0 has been released. Close all issues. > Service ranking is only obeyed on first component activation > > > Key: FELIX-1414 > URL: https://issues.apache.org/jira/browse/FELIX-1414 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR), Specification compliance >Affects Versions: scr-1.0.8 >Reporter: Felix Meschberger > Fix For: scr-1.2.0 > > > As of FELIX-950 (released with scr 1.0.8) and FELIX-1213 (not released yet) > unary services bindings are replaced if a new service is registered with a > higher service ranking than the already bound service. > It has been clarified in the OSGi dev list thread "Questions on DS Spec" [1] > that a service once bound is only replaced if it ceaces to be a target either > by the service being unregistered of the target filter not matching any > longer. Service ranking is only obeyed upon first binding of a service to the > component. > To fix we have to revert the fixes for FELIX-950 and FELIX-1213. > [1] http://www.mail-archive.com/osgi-...@mail.osgi.org/msg00883.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1413) Newly registered services must not immediately bound for static references
[ https://issues.apache.org/jira/browse/FELIX-1413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-1413. SCR 1.2.0 has been released. Close all issues. > Newly registered services must not immediately bound for static references > -- > > Key: FELIX-1413 > URL: https://issues.apache.org/jira/browse/FELIX-1413 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR), Specification compliance >Affects Versions: scr-1.0.8 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.2.0 > > > Consider a static component references with mulitplie cardinality, that is > 0..n or 1..n. > If the component is satisified and active, all services existing at the time > of activation are bound. If now a service is registered matching the > component's reference this newly registered service must not be bound to the > component. > Only if the component is reactivated for another reason (e.g. reconfiguration > or removal of a statically bound service) may the newly registered service be > bound. This is comparable to optional package imports: such imports are only > wired to newly installed bundles when the importing bundle is explicitly > rewired. > In other words here is what may happen : >(1) Component C is enabled, satisfied and activated. All services bound. C > has static, multiple reference to Service type TS >(2) Service S of type TS is registered >(3) The service is *not* bound >(4) Component C is deactivated (e.g. for reconfiguration) >(5) Component C is still satisifed and activated. Now Service S is bound > > In current versions (1.0.8 and earlier) scr is immediately reactivating the > component to bind the new Service S in step 3; which is wrong. > See also the discussion on the OSGi dev list "Questions on DS Spec" [1] for > full details. > [1] http://www.mail-archive.com/osgi-...@mail.osgi.org/msg00883.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1232) Do not use private configuration properties as service properties
[ https://issues.apache.org/jira/browse/FELIX-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-1232. SCR 1.2.0 has been released. Close all issues. > Do not use private configuration properties as service properties > - > > Key: FELIX-1232 > URL: https://issues.apache.org/jira/browse/FELIX-1232 > Project: Felix > Issue Type: New Feature > Components: Declarative Services (SCR), Specification compliance >Affects Versions: scr-1.0.8 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.2.0 > > Attachments: FELIX-1232.patch > > > R4.2 of the OSGi compendium spec will introduce the notion of private > properties. Private properties are properties whose names have leading dots. > Such private properties should not be propagated to service properties. > See also 104.4.3, Property Propagation, in the draft R4.2 Compendium > Specification (dated 2009/03/10). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1284) Support for the 'modified' operation (DS in OSGi 4.2 compendium)
[ https://issues.apache.org/jira/browse/FELIX-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-1284. SCR 1.2.0 has been released. Close all issues. > Support for the 'modified' operation (DS in OSGi 4.2 compendium) > > > Key: FELIX-1284 > URL: https://issues.apache.org/jira/browse/FELIX-1284 > Project: Felix > Issue Type: New Feature > Components: Declarative Services (SCR), Specification compliance >Reporter: Erin Schnabel >Assignee: Felix Meschberger > Fix For: scr-1.2.0 > > > 112.5.11-12, 112.7.1 from 4.2 Compendium spec (numbers may be slightly > different-- these are from the May 6 draft). > Modifying a component configuration can occur if > * the component description specifies the modified attribute and > * the component properties of the component configuration use a Configuration > object from the Configuration Admin service and > * that Configuration object is modified without causing the component > configuration to become unsatisfied. > If this occurs, the component instance will be _notified of the change in the > component properties_. > If the modified attribute is not specified, then the component configuration > will become unsatisfied if its component properties use a Configuration > object and that Configuration object is modified in any way. > -- > Basically: you can specify a 'modified' attribute/method that should be > called when ConfigAdmin pushes a changed configuration for a component, > instead of deactivating and then re-activating the component on a > configuration change. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1186) Defer the construction of a log message
[ https://issues.apache.org/jira/browse/FELIX-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-1186. SCR 1.2.0 has been released. Close all issues. > Defer the construction of a log message > --- > > Key: FELIX-1186 > URL: https://issues.apache.org/jira/browse/FELIX-1186 > Project: Felix > Issue Type: Improvement > Components: Declarative Services (SCR) >Affects Versions: scr-1.0.8 >Reporter: Agemo Cui >Assignee: Felix Meschberger >Priority: Trivial > Fix For: scr-1.2.0 > > > There are a lot of log messages at the DEBUG level constructed in the first > place. > My thinking is to put the construction of a message after the threshold of > the log level is compared to, which could improve the performance and > especially means much on a resource constrained device. > Since most of the log message is constructed by simply concatenating String > values of several objects, the prototype of the method > BundleComponentActivator.log(a singleton utility may be better) could be like > the following. > public void log( int level, ComponentMetadata metadata, Throwable ex, > Object... objs ); > And because most messages consist of no more than 3 objects, we can even > implement 3 more log methods as follows to avoid the creation of an object > array. > public void log( int level, ComponentMetadata metadata, Throwable ex, Object > obj ); > public void log( int level, ComponentMetadata metadata, Throwable ex, Object > obj0, Object obj1 ); > public void log( int level, ComponentMetadata metadata, Throwable ex, Object > obj0, Object obj1, Object obj2 ); > And the final log message can be constructed after "if ( m_logLevel >= level > )". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1177) Components must correctly be disposed off
[ https://issues.apache.org/jira/browse/FELIX-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-1177. SCR 1.2.0 has been released. Close all issues. > Components must correctly be disposed off > - > > Key: FELIX-1177 > URL: https://issues.apache.org/jira/browse/FELIX-1177 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-1.0.8 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.2.0 > > > When a component is to be disposed off, the following tasks run: >* unregister the service (if registered) >* call deactivate method (if any) >* unbind references > In the current implementation the service unregistration throws an > IllegalStateException if the service cannot be unregistered because the > registration lock is being held by a nother thread. This exception is > forwarded to the caller causing neither the deactivate method being called > nor the reference being unbound. > Rather we should continue with the controlled deactivation (and maybe even > try to unregister again). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1178) Component may remain deactivated after a reference has been unregistered and registered again
[ https://issues.apache.org/jira/browse/FELIX-1178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-1178. SCR 1.2.0 has been released. Close all issues. > Component may remain deactivated after a reference has been unregistered and > registered again > - > > Key: FELIX-1178 > URL: https://issues.apache.org/jira/browse/FELIX-1178 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-1.0.8 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.2.0 > > > If a static/mandatory reference of a component is unregistered, the component > is scheduled to be deactivated. If the reference is registered again before > the refering component is deactivated, the component is not activated again > (since its state is still active or deactivating instead of unsatisifed). > A flag should be added, which is set when the component is scheduled to be > deactivated. If this flag is set when the component might have to be > activated, the component is scheduled for activation. Scheduling the > activation clears this flag. The flag is also cleared as soon as the > component has been deactivated. If the component should be scheduled for > deactivation and the flag is set, the component is not scheduled for > deactivation again. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1173) Concurrency Issues while containing bundle is stopping
[ https://issues.apache.org/jira/browse/FELIX-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-1173. SCR 1.2.0 has been released. Close all issues. > Concurrency Issues while containing bundle is stopping > -- > > Key: FELIX-1173 > URL: https://issues.apache.org/jira/browse/FELIX-1173 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-1.0.8 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.2.0 > > > While a bundle is stopping, there may still be ComponentActivatorTask on the > activator queue and be executed. The activator queue/ComponentActivatorTask > combo should be enhance to prevent running asynchrounous tasks for components > whose owning bundle is in the process of stopping, i.e. is not active. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-928) Allow use of wildcards in Service-Component header
[ https://issues.apache.org/jira/browse/FELIX-928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-928. --- SCR 1.2.0 has been released. Close all issues. > Allow use of wildcards in Service-Component header > -- > > Key: FELIX-928 > URL: https://issues.apache.org/jira/browse/FELIX-928 > Project: Felix > Issue Type: New Feature > Components: Declarative Services (SCR), Specification compliance >Affects Versions: scr-1.0.6 > Environment: OSGi RFC-0134, OSGi R4.2 Early Draft 2 > (http://www.osgi.org/download/osgi-4.2-early-draft2.pdf) >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.2.0 > > Attachments: FELIX-928.patch > > > A way is needed to allow wild specification of the XML documents containing > the component descriptions. > To support this, section 112.4.1 will be updated to state that the path > element of the Service-Component header grammar may include wildcards in the > last component of the path. For example: > Service-Component: OSGI-INF/*.xml > Only the last component of the path may use wildcards so that > Bundle.findEntries can be used to locate the XML document within the bundle > and its fragments. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-925) Extend SCR to allow alternate activate and deactivate method signatures
[ https://issues.apache.org/jira/browse/FELIX-925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-925. --- SCR 1.2.0 has been released. Close all issues. > Extend SCR to allow alternate activate and deactivate method signatures > --- > > Key: FELIX-925 > URL: https://issues.apache.org/jira/browse/FELIX-925 > Project: Felix > Issue Type: New Feature > Components: Declarative Services (SCR), Specification compliance >Affects Versions: scr-1.0.6 > Environment: OSGi RFC-0134, OSGi R4.2 Early Draft 2 > (http://www.osgi.org/download/osgi-4.2-early-draft2.pdf) >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.2.0 > > > A way is needed to avoid using DS API at all in components with SCR. This > means the activate and deactivate methods should not require the > ComponentContext parameter. We should also allow the names of the activate > and deactivate methods to be specified to avoid requiring specific method > names. > To support this, the follow attributes will be added to the component element: > /> > > The activate attribute will specify the name of the activate method and the > deactivate attribute will specify the name of the deactivate method. > The signature for the activate and deactivate methods is: > p r o t e c t ed vo i d (< a r gumen t s > > ) ; > can be zero or more arguments. > For the activate method each argument must be of one of the following types: > ● ComponentContext - the Component Context for the component > ● BundleContext - the Bundle Context of the component's bundle > ● Map - the Component Properties from ComponentContext.getProperties. > If any argument of the activate method is not one of the above types, SCR > must log an error message with the Log Service, if present, and the component > configuration is not activated. > For the deactivate method each argument must be of one of the following types: > ● int/Integer - the deactivation reason > ● ComponentContext - the Component Context for the component > ● BundleContext - the Bundle Context of the component's bundle > ● Map - the Component Properties from ComponentContext.getProperties. > If any argument of the deactivate method is not one of the above types, SCR > must log an error message with the Log Service, if present, and the > deactivation of the component configuration will continue. > The methods may also be declared public. The same rules as specified in > 112.5.8 will be used to locate the activate and deactivate methods in the > implementation class hierarchy. > 3.2.1 Component deactivation reasons > When a component is deactivated, the reason for the deactivation can be > passed to the deactivate method. The following deactivation reasons are > specified in ComponentConstants. > /** >* The reason the component instance was deactivated is > unspecified. >* >* @since 1.1 >*/ > public static final int DEACTIVATION_REASON_UNSPECIFIED = 0; > /** >* The component instance was deactivated because the > component was disabled. >* >* @since 1.1 >*/ > public static final int DEACTIVATION_REASON_DISABLED = 1; > /** >* The component instance was deactivated because a > reference became unsatisfied. >* >* @since 1.1 >*/ > public static final int DEACTIVATION_REASON_REFERENCE = 2; > /** >* The component instance was deactivated because its > configuration was changed. >* >* @since 1.1 >*/ > public static final int > DEACTIVATION_REASON_CONFIGURATION_MODIFIED = 3; > /** >* The component instance was deactivated because its > configuration was deleted. >* >* @since 1.1 >*/ > public static final int > DEACTIVATION_REASON_CONFIGURATION_DELETED = 4; > /** >* The component instance was deactivated because the > component was disposed. >* >* @since 1.1 >*/ > public static final int DEACTIVATION_REASON_DISPOSED = 5; > /** >* The component instance was deactivated because the > bundle was stopped. >* >
[jira] Closed: (FELIX-1166) SCR does not rebind ConfigurationAdmin service in Sling jcrinstall tests
[ https://issues.apache.org/jira/browse/FELIX-1166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-1166. SCR 1.2.0 has been released. Close all issues. > SCR does not rebind ConfigurationAdmin service in Sling jcrinstall tests > > > Key: FELIX-1166 > URL: https://issues.apache.org/jira/browse/FELIX-1166 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-1.0.8 >Reporter: Bertrand Delacretaz >Assignee: Felix Meschberger > Fix For: scr-1.2.0 > > Attachments: FELIX-1166-reproduce.patch > > > I'm testing the Sling jcrinstall module using Pax Exam, and the SCR reference > shown below is not rebound after stopping and restarting the > org.apache.felix.configadmin bundle, and waiting up to 5 seconds. > The reference is declared like this in the OsgiControllerImpl class: > /** @scr.reference cardinality="0..1" policy="dynamic" */ > private ConfigurationAdmin configAdmin; > To reproduce, apply the attached patch to revision 776315 of > http://svn.apache.org/repos/asf/incubator/sling/trunk/contrib/extensions/jcrinstall, > and run the tests with mvn clean install. > The OsgiControllerTest.testDeferredConfigInstall test then fails, because the > ConfigurationAdmin service is not rebound to the OsgiControllerImpl class, > after waiting up to 5 seconds for that to happen. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-924) No component instance if no Configuration
[ https://issues.apache.org/jira/browse/FELIX-924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-924. --- SCR 1.2.0 has been released. Close all issues. > No component instance if no Configuration > - > > Key: FELIX-924 > URL: https://issues.apache.org/jira/browse/FELIX-924 > Project: Felix > Issue Type: New Feature > Components: Declarative Services (SCR), Specification compliance >Affects Versions: scr-1.0.6 > Environment: OSGi RFC-0134, OSGi R4.2 Early Draft 2 > (http://www.osgi.org/download/osgi-4.2-early-draft2.pdf) >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.2.0 > > > A way is needed for the component declaration to say only create a component > configuration IF there is a Configuration( or Configurations). > To support this, the follow attribute is added to the component element: > default="optional" use="optional" /> > > > > > > > > If the attribute is present and set to require, then a component cannot be > satisfied (section 112.5.2) unless there is a Configuration in > ConfigurationAdmin for the component. In this situation, the No Configuration > case in 112.7 does not apply.If the component is a Factory Component and the > component is not satisfied because there is no Configuration present, then > the ComponentFactory service will not be registered. > If the attribute is present and set to ignore, then ConfigurationAdmin will > not be consulted for the component. In this situation, only the No > Configuration case in 112.7 applies. > If the attribute is not present or present and set to optional, then SCR will > act as it did prior to this RFC. That is, a Configuration will be used if > present in ConfigurationAdmin. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-927) Allow bind and unbind methods to receive the service properties
[ https://issues.apache.org/jira/browse/FELIX-927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-927. --- SCR 1.2.0 has been released. Close all issues. > Allow bind and unbind methods to receive the service properties > --- > > Key: FELIX-927 > URL: https://issues.apache.org/jira/browse/FELIX-927 > Project: Felix > Issue Type: New Feature > Components: Declarative Services (SCR), Specification compliance >Affects Versions: scr-1.0.6 > Environment: OSGi RFC-0134, OSGi R4.2 Early Draft 2 > (http://www.osgi.org/download/osgi-4.2-early-draft2.pdf) >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.2.0 > > Attachments: FELIX-927.patch > > > A bind or unbind method must have one of the following prototypes: > protected void (ServiceReference); > protected void (); > protected void (, Map); > If the bind or unbind method has the third prototype, then the service object > of the bound service is passed to the method as the first argument and a Map > containing the service properties of the bound service is passed as the > second argument. The method's first parameter type must be assignable from > the type specified by the reference's interface attribute. That is, the > service object of the bound service must be castable to the method's first > parameter type. > When searching for the bind or unbind method to call, SCR must look through > the component implementation class hierarchy. The declared methods of each > class are searched for a method with the specified name that takes one or two > parameters. The method is searched for using the following priority: > 1.The method takes a single parameter and the type of the parameter is > org.osgi.framework.ServiceReference. > 2.The method takes a single parameter and the type of the parameter is the > type specified by the reference's interface attribute. > 3.The method takes a single parameter and the type of the parameter is > assignable from the type specified by the reference's interface attribute. If > multiple methods match this rule, this implies the method name is overloaded > and SCR may choose any of the methods to call. > 4.The method takes two parameters and the type of the first parameter is the > type specified by the reference's interface attribute and the type of the > second parameter is java.util.Map > 5.The method takes two parameters and the type of the first parameter is > assignable from the type specified by the reference's interface attribute and > the type of the second parameter is java.util.Map. If multiple methods match > this rule, this implies the method name is overloaded and SCR may choose any > of the methods to call. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1827) Check permission before getting or registering services
[ https://issues.apache.org/jira/browse/FELIX-1827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787512#action_12787512 ] Felix Meschberger commented on FELIX-1827: -- Thanks for your report and proposed pacth. Since this issue is related to an already released bundle, I have created FELIX-1927 to track this. > Check permission before getting or registering services > --- > > Key: FELIX-1827 > URL: https://issues.apache.org/jira/browse/FELIX-1827 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR), Specification compliance >Affects Versions: scr-1.2.0 >Reporter: Felix Meschberger > Fix For: scr-1.2.0 > > > The DS specification states in 112.9.3 that SCR has to call > Bundle.hasPermission for the providing bundle when registering or getting > services on behalf of the providing bundle: >SCR does all publishing, finding and binding of services on behalf > of the >component using the Bundle Context of the component's bundle. This >means that normal stack-based permission checks will check SCR and > not >the component's bundle. Since SCR is registering and getting > services on >behalf of a component's bundle, SCR must call the > Bundle.hasPermission >method to validate that a component's bundle has the necessary > permission >to register or get a service. > This is not currently implemented. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1827) Check permission before getting or registering services
[
https://issues.apache.org/jira/browse/FELIX-1827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Kolisko updated FELIX-1827:
-
Comment: was deleted
(was: If a service component does not provide any service and system security
manager is set , then
AbstractComponentManager.java line 537
final String[] services =
getComponentMetadata().getServiceMetadata().getProvides(); fails with NPE
because ServiceMetadata is null.
Possible patch:
Index:
src/main/java/org/apache/felix/scr/impl/manager/AbstractComponentManager.java
===
---
src/main/java/org/apache/felix/scr/impl/manager/AbstractComponentManager.java
(revision 888421)
+++
src/main/java/org/apache/felix/scr/impl/manager/AbstractComponentManager.java
(working copy)
@@ -33,6 +33,7 @@
import org.apache.felix.scr.impl.ComponentActivatorTask;
import org.apache.felix.scr.impl.metadata.ComponentMetadata;
import org.apache.felix.scr.impl.metadata.ReferenceMetadata;
+import org.apache.felix.scr.impl.metadata.ServiceMetadata;
import org.osgi.framework.Bundle;
import org.osgi.framework.InvalidSyntaxException;
import org.osgi.framework.ServicePermission;
@@ -534,18 +535,22 @@
boolean allowed = true;
if ( System.getSecurityManager() != null )
{
-final String[] services =
getComponentMetadata().getServiceMetadata().getProvides();
-if ( services != null && services.length > 0 )
+final ServiceMetadata metadata =
getComponentMetadata().getServiceMetadata();
+if ( metadata != null )
{
-final Bundle bundle = getBundle();
-for ( int i = 0; i < services.length; i++ )
+final String[] services = metadata.getProvides();
+if ( services != null && services.length > 0 )
{
-final Permission perm = new ServicePermission(
services[i], ServicePermission.REGISTER );
-if ( !bundle.hasPermission( perm ) )
+final Bundle bundle = getBundle();
+for ( int i = 0; i < services.length; i++ )
{
-log( LogService.LOG_INFO, "Permission to register
service {0} is denied", new Object[]
-{ services[i] }, null );
-allowed = false;
+final Permission perm = new ServicePermission(
services[i], ServicePermission.REGISTER );
+if ( !bundle.hasPermission( perm ) )
+{
+log( LogService.LOG_INFO, "Permission to register
service {0} is denied", new Object[]
+{ services[i] }, null );
+allowed = false;
+}
}
}
}
)
> Check permission before getting or registering services
> ---
>
> Key: FELIX-1827
> URL: https://issues.apache.org/jira/browse/FELIX-1827
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR), Specification compliance
>Affects Versions: scr-1.2.0
>Reporter: Felix Meschberger
> Fix For: scr-1.2.0
>
>
> The DS specification states in 112.9.3 that SCR has to call
> Bundle.hasPermission for the providing bundle when registering or getting
> services on behalf of the providing bundle:
>SCR does all publishing, finding and binding of services on behalf
> of the
>component using the Bundle Context of the component's bundle. This
>means that normal stack-based permission checks will check SCR and
> not
>the component's bundle. Since SCR is registering and getting
> services on
>behalf of a component's bundle, SCR must call the
> Bundle.hasPermission
>method to validate that a component's bundle has the necessary
> permission
>to register or get a service.
> This is not currently implemented.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1927) NPE in AbstractComponentManager if no services are provided and a SecurityManager is installed
NPE in AbstractComponentManager if no services are provided and a
SecurityManager is installed
--
Key: FELIX-1927
URL: https://issues.apache.org/jira/browse/FELIX-1927
Project: Felix
Issue Type: Bug
Components: Declarative Services (SCR)
Affects Versions: scr-1.2.0
Reporter: Lukas Kolisko
Assignee: Felix Meschberger
Fix For: scr-1.2.2
Lukas Kolisko reports in response to FELIX-1827:
If a service component does not provide any service and system security manager
is set , then
AbstractComponentManager.java line 537
final String[] services =
getComponentMetadata().getServiceMetadata().getProvides(); fails with NPE
because ServiceMetadata is null.
Possible patch:
Index:
src/main/java/org/apache/felix/scr/impl/manager/AbstractComponentManager.java
===
---
src/main/java/org/apache/felix/scr/impl/manager/AbstractComponentManager.java
(revision 888421)
+++
src/main/java/org/apache/felix/scr/impl/manager/AbstractComponentManager.java
(working copy)
@@ -33,6 +33,7 @@
import org.apache.felix.scr.impl.ComponentActivatorTask;
import org.apache.felix.scr.impl.metadata.ComponentMetadata;
import org.apache.felix.scr.impl.metadata.ReferenceMetadata;
+import org.apache.felix.scr.impl.metadata.ServiceMetadata;
import org.osgi.framework.Bundle;
import org.osgi.framework.InvalidSyntaxException;
import org.osgi.framework.ServicePermission;
@@ -534,18 +535,22 @@
boolean allowed = true;
if ( System.getSecurityManager() != null )
{
- final String[] services =
getComponentMetadata().getServiceMetadata().getProvides();
- if ( services != null && services.length > 0 )
+ final ServiceMetadata metadata = getComponentMetadata().getServiceMetadata();
+ if ( metadata != null )
{
- final Bundle bundle = getBundle();
- for ( int i = 0; i < services.length; i++ )
+ final String[] services = metadata.getProvides();
+ if ( services != null && services.length > 0 )
{
- final Permission perm = new ServicePermission( services[i],
ServicePermission.REGISTER );
- if ( !bundle.hasPermission( perm ) )
+ final Bundle bundle = getBundle();
+ for ( int i = 0; i < services.length; i++ )
{
- log( LogService.LOG_INFO, "Permission to register service {0} is denied", new
Object[]
- { services[i] }, null );
- allowed = false;
+ final Permission perm = new ServicePermission( services[i],
ServicePermission.REGISTER );
+ if ( !bundle.hasPermission( perm ) )
+ {
+ log( LogService.LOG_INFO, "Permission to register service {0} is denied", new
Object[]
+ { services[i] }, null );
+ allowed = false;
+ }
}
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (FELIX-1827) Check permission before getting or registering services
[
https://issues.apache.org/jira/browse/FELIX-1827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787504#action_12787504
]
Lukas Kolisko edited comment on FELIX-1827 at 12/8/09 3:37 PM:
---
If a service component does not provide any service and system security manager
is set , then
AbstractComponentManager.java line 537
final String[] services =
getComponentMetadata().getServiceMetadata().getProvides(); fails with NPE
because ServiceMetadata is null.
Possible patch:
Index:
src/main/java/org/apache/felix/scr/impl/manager/AbstractComponentManager.java
===
---
src/main/java/org/apache/felix/scr/impl/manager/AbstractComponentManager.java
(revision 888421)
+++
src/main/java/org/apache/felix/scr/impl/manager/AbstractComponentManager.java
(working copy)
@@ -33,6 +33,7 @@
import org.apache.felix.scr.impl.ComponentActivatorTask;
import org.apache.felix.scr.impl.metadata.ComponentMetadata;
import org.apache.felix.scr.impl.metadata.ReferenceMetadata;
+import org.apache.felix.scr.impl.metadata.ServiceMetadata;
import org.osgi.framework.Bundle;
import org.osgi.framework.InvalidSyntaxException;
import org.osgi.framework.ServicePermission;
@@ -534,18 +535,22 @@
boolean allowed = true;
if ( System.getSecurityManager() != null )
{
-final String[] services =
getComponentMetadata().getServiceMetadata().getProvides();
-if ( services != null && services.length > 0 )
+final ServiceMetadata metadata =
getComponentMetadata().getServiceMetadata();
+if ( metadata != null )
{
-final Bundle bundle = getBundle();
-for ( int i = 0; i < services.length; i++ )
+final String[] services = metadata.getProvides();
+if ( services != null && services.length > 0 )
{
-final Permission perm = new ServicePermission(
services[i], ServicePermission.REGISTER );
-if ( !bundle.hasPermission( perm ) )
+final Bundle bundle = getBundle();
+for ( int i = 0; i < services.length; i++ )
{
-log( LogService.LOG_INFO, "Permission to register
service {0} is denied", new Object[]
-{ services[i] }, null );
-allowed = false;
+final Permission perm = new ServicePermission(
services[i], ServicePermission.REGISTER );
+if ( !bundle.hasPermission( perm ) )
+{
+log( LogService.LOG_INFO, "Permission to register
service {0} is denied", new Object[]
+{ services[i] }, null );
+allowed = false;
+}
}
}
}
was (Author: lkolisko):
If a service component does not provide any service and system security
manager is set , then
abstractcomponentmanager.j...@537
final String[] services =
getComponentMetadata().getServiceMetadata().getProvides(); fails with NPE
because ServiceMetadata is null.
Possible patch:
Index:
src/main/java/org/apache/felix/scr/impl/manager/AbstractComponentManager.java
===
---
src/main/java/org/apache/felix/scr/impl/manager/AbstractComponentManager.java
(revision 888421)
+++
src/main/java/org/apache/felix/scr/impl/manager/AbstractComponentManager.java
(working copy)
@@ -33,6 +33,7 @@
import org.apache.felix.scr.impl.ComponentActivatorTask;
import org.apache.felix.scr.impl.metadata.ComponentMetadata;
import org.apache.felix.scr.impl.metadata.ReferenceMetadata;
+import org.apache.felix.scr.impl.metadata.ServiceMetadata;
import org.osgi.framework.Bundle;
import org.osgi.framework.InvalidSyntaxException;
import org.osgi.framework.ServicePermission;
@@ -534,18 +535,22 @@
boolean allowed = true;
if ( System.getSecurityManager() != null )
{
-final String[] services =
getComponentMetadata().getServiceMetadata().getProvides();
-if ( services != null && services.length > 0 )
+final ServiceMetadata metadata =
getComponentMetadata().getServiceMetadata();
+if ( metadata != null )
{
-final Bundle bundle = getBundle();
-for ( int i = 0; i < services.length; i++ )
+final String[] services = metadata.getProvides();
+if ( services != null && services.length > 0 )
{
-final Permission perm = new ServicePermission(
services[i], ServicePermission.REGISTER );
-if ( !bundle.hasPermission( perm ) )
[jira] Commented: (FELIX-1827) Check permission before getting or registering services
[
https://issues.apache.org/jira/browse/FELIX-1827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787504#action_12787504
]
Lukas Kolisko commented on FELIX-1827:
--
If a service component does not provide any service and system security manager
is set , then
abstractcomponentmanager.j...@537
final String[] services =
getComponentMetadata().getServiceMetadata().getProvides(); fails with NPE
because ServiceMetadata is null.
Possible patch:
Index:
src/main/java/org/apache/felix/scr/impl/manager/AbstractComponentManager.java
===
---
src/main/java/org/apache/felix/scr/impl/manager/AbstractComponentManager.java
(revision 888421)
+++
src/main/java/org/apache/felix/scr/impl/manager/AbstractComponentManager.java
(working copy)
@@ -33,6 +33,7 @@
import org.apache.felix.scr.impl.ComponentActivatorTask;
import org.apache.felix.scr.impl.metadata.ComponentMetadata;
import org.apache.felix.scr.impl.metadata.ReferenceMetadata;
+import org.apache.felix.scr.impl.metadata.ServiceMetadata;
import org.osgi.framework.Bundle;
import org.osgi.framework.InvalidSyntaxException;
import org.osgi.framework.ServicePermission;
@@ -534,18 +535,22 @@
boolean allowed = true;
if ( System.getSecurityManager() != null )
{
-final String[] services =
getComponentMetadata().getServiceMetadata().getProvides();
-if ( services != null && services.length > 0 )
+final ServiceMetadata metadata =
getComponentMetadata().getServiceMetadata();
+if ( metadata != null )
{
-final Bundle bundle = getBundle();
-for ( int i = 0; i < services.length; i++ )
+final String[] services = metadata.getProvides();
+if ( services != null && services.length > 0 )
{
-final Permission perm = new ServicePermission(
services[i], ServicePermission.REGISTER );
-if ( !bundle.hasPermission( perm ) )
+final Bundle bundle = getBundle();
+for ( int i = 0; i < services.length; i++ )
{
-log( LogService.LOG_INFO, "Permission to register
service {0} is denied", new Object[]
-{ services[i] }, null );
-allowed = false;
+final Permission perm = new ServicePermission(
services[i], ServicePermission.REGISTER );
+if ( !bundle.hasPermission( perm ) )
+{
+log( LogService.LOG_INFO, "Permission to register
service {0} is denied", new Object[]
+{ services[i] }, null );
+allowed = false;
+}
}
}
}
> Check permission before getting or registering services
> ---
>
> Key: FELIX-1827
> URL: https://issues.apache.org/jira/browse/FELIX-1827
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR), Specification compliance
>Affects Versions: scr-1.2.0
>Reporter: Felix Meschberger
> Fix For: scr-1.2.0
>
>
> The DS specification states in 112.9.3 that SCR has to call
> Bundle.hasPermission for the providing bundle when registering or getting
> services on behalf of the providing bundle:
>SCR does all publishing, finding and binding of services on behalf
> of the
>component using the Bundle Context of the component's bundle. This
>means that normal stack-based permission checks will check SCR and
> not
>the component's bundle. Since SCR is registering and getting
> services on
>behalf of a component's bundle, SCR must call the
> Bundle.hasPermission
>method to validate that a component's bundle has the necessary
> permission
>to register or get a service.
> This is not currently implemented.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (FELIX-1897) Add proper Configuration Admin support for SCR configuration
[ https://issues.apache.org/jira/browse/FELIX-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787495#action_12787495 ] Felix Meschberger edited comment on FELIX-1897 at 12/8/09 3:18 PM: --- This is implemented and thus resolved The ds.rebind.enabled property has been removed again. was (Author: fmeschbe): This is implemented and thus resolved > Add proper Configuration Admin support for SCR configuration > > > Key: FELIX-1897 > URL: https://issues.apache.org/jira/browse/FELIX-1897 > Project: Felix > Issue Type: Improvement > Components: Declarative Services (SCR) >Affects Versions: scr-1.2.0 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.2.2 > > > Currently Apache Felix SCR can only be configured by setting a bunch of > bundle context properties. This presents a major problem is during runtime > some of these properties need to be changed. > As an extension, the SCR will register a ManagedService (provided the API is > available in the framework at bundle start time) to receive configuration for > the PID "org.apache.felix.scr.ScrService" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-1897) Add proper Configuration Admin support for SCR configuration
[ https://issues.apache.org/jira/browse/FELIX-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved FELIX-1897. -- Resolution: Fixed This is implemented and thus resolved > Add proper Configuration Admin support for SCR configuration > > > Key: FELIX-1897 > URL: https://issues.apache.org/jira/browse/FELIX-1897 > Project: Felix > Issue Type: Improvement > Components: Declarative Services (SCR) >Affects Versions: scr-1.2.0 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.2.2 > > > Currently Apache Felix SCR can only be configured by setting a bunch of > bundle context properties. This presents a major problem is during runtime > some of these properties need to be changed. > As an extension, the SCR will register a ManagedService (provided the API is > available in the framework at bundle start time) to receive configuration for > the PID "org.apache.felix.scr.ScrService" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-1926) Access to internal maps in the ComponentRegistry must be guarded against concurrency issues
[ https://issues.apache.org/jira/browse/FELIX-1926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved FELIX-1926. -- Resolution: Fixed Fixed in Rev. 888435 > Access to internal maps in the ComponentRegistry must be guarded against > concurrency issues > --- > > Key: FELIX-1926 > URL: https://issues.apache.org/jira/browse/FELIX-1926 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-1.2.0 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.2.2 > > > Currently accesses to the internal m_componetsById and m_compeontsByName maps > are not guarded against concurrent calls and thus become corrupt in highly > concurrent situations. > These accesses should be guared by simple Java synchronization (if possible). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1926) Access to internal maps in the ComponentRegistry must be guarded against concurrency issues
Access to internal maps in the ComponentRegistry must be guarded against concurrency issues --- Key: FELIX-1926 URL: https://issues.apache.org/jira/browse/FELIX-1926 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-1.2.0 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: scr-1.2.2 Currently accesses to the internal m_componetsById and m_compeontsByName maps are not guarded against concurrent calls and thus become corrupt in highly concurrent situations. These accesses should be guared by simple Java synchronization (if possible). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1925) Missing sources for eventadmin
Missing sources for eventadmin -- Key: FELIX-1925 URL: https://issues.apache.org/jira/browse/FELIX-1925 Project: Felix Issue Type: Bug Components: Event Admin Affects Versions: eventadmin 1.0.0 Reporter: Thomas Diesler Please upload the eventadmin sources to maven central http://repo2.maven.org/maven2/org/apache/felix/org.apache.felix.eventadmin/1.0.0/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
