[jira] Commented: (FELIX-1482) Fileinstall try to start all bundles, not only newly installed.
[ https://issues.apache.org/jira/browse/FELIX-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744389#action_12744389 ] Sahoo commented on FELIX-1482: -- No matter what we do, we will face problems as long as we allow multiple management agents to manage a bundle. e.g., my earlier suggestion of FRAMEWORK_REFRESHED events would not work, as we would fail to distinguish bundles explicitly stopped by user. So, we should really enhance FileInstall to allow user to stop a bundle. When we do that, we can check status of watched bundles in FRAMEWORK_REFRESHED event and add appropriate bundles to failed list. In the mean while, we should do the following: 1. Reopen FELIX-938. Apply your patch with one change, i.e., in addition to starting "installed" bundles and "failedToStart" bundles, we should also start "updated" bundles. This is needed so that user can modify a bundle that has been unresolved by an earlier refreshPackage. 2. Change this issue to an enhancement request to add support for "stopping" watched bundles. What do you think? > Fileinstall try to start all bundles, not only newly installed. > --- > > Key: FELIX-1482 > URL: https://issues.apache.org/jira/browse/FELIX-1482 > Project: Felix > Issue Type: Bug >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet > Fix For: karaf-1.0.0 > > Attachments: FELIX-1482.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1492) Add option to exclude optional dependencies during OBR deploy
[
https://issues.apache.org/jira/browse/FELIX-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744204#action_12744204
]
David Savage commented on FELIX-1492:
-
This is similar to a used case found in the sigil resolver where the user
wishes to analyse how a bundle would resolve in different configurations. In
the sigil resolver the api for resolve looks like:
public interface IBundleResolver
{
IResolution resolve( IModelElement element, ResolutionConfig config,
IResolutionMonitor monitor )
throws ResolutionException;
}
Where element is an OSGi bundle or something that contains bundles (such as a
karaf feature) and config is a pretty crude bitmask style filter telling the
resolver what to do when it get's to certain branches in the graph.
public class ResolutionConfig {
...
public static final int INCLUDE_DEPENDENTS = 1;
public static final int INCLUDE_OPTIONAL = 2;
public static final int IGNORE_ERRORS = 4;
/** Return only bundles that are indexed locally */
public static final int INDEXED_ONLY = 8;
/** Return only bundles that are stored or cached locally */
public static final int LOCAL_ONLY = 16;
}
Sure there are a /lot/ more options on here in the end game. Also not
suggesting that this API is perfect but thought it useful to flag it's
existence for this issue.
> Add option to exclude optional dependencies during OBR deploy
> -
>
> Key: FELIX-1492
> URL: https://issues.apache.org/jira/browse/FELIX-1492
> Project: Felix
> Issue Type: Improvement
> Components: Bundle Repository (OBR)
>Reporter: Allen Lau
>Priority: Minor
>
> Currently, OBR client will pull down all optional dependencies from the OBR
> repository if found. Sometimes this is not desirable for the end-user.
> Would be nice to have an optional flag to the OBR "deploy" and "start"
> commands to exclude optional dependencies.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1492) Add option to exclude optional dependencies during OBR deploy
Add option to exclude optional dependencies during OBR deploy - Key: FELIX-1492 URL: https://issues.apache.org/jira/browse/FELIX-1492 Project: Felix Issue Type: Improvement Components: Bundle Repository (OBR) Reporter: Allen Lau Priority: Minor Currently, OBR client will pull down all optional dependencies from the OBR repository if found. Sometimes this is not desirable for the end-user. Would be nice to have an optional flag to the OBR "deploy" and "start" commands to exclude optional dependencies. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1066) Assume a default type/classified (xml/features) on the features addUrl/removeUrl commands
[
https://issues.apache.org/jira/browse/FELIX-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet closed FELIX-1066.
--
Resolution: Won't Fix
So let's close this issue.
> Assume a default type/classified (xml/features) on the features
> addUrl/removeUrl commands
> -
>
> Key: FELIX-1066
> URL: https://issues.apache.org/jira/browse/FELIX-1066
> Project: Felix
> Issue Type: Improvement
> Components: Karaf
>Reporter: Guillaume Nodet
> Attachments: FELIX-1066-OptionalMavenUrlComponents.patch
>
>
> When doing an features/addUrl, you always have to specify the type (xml) and
> classifier (features). How about making that the default, so people can just
> do:
> {code}
> features/addUrl mvn:org.apache.servicemix.features/apache-servicemix/4.0.0
> {code}
> We can always fail-back to type jar if we don't find the xml file to support
> deploying new feature descriptors through a bundle.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1066) Assume a default type/classified (xml/features) on the features addUrl/removeUrl commands
[
https://issues.apache.org/jira/browse/FELIX-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744112#action_12744112
]
Tim Moloney commented on FELIX-1066:
True. In fact, that's how my features repo was deployed before this patch, but
I thought that I wasn't following convention, so I changed it.
I'm leaning towards "bad idea" personally.
I've been running with the patch for the last couple of days and I've found the
following:
- loading the URI when it is missing the version is slower than just typing the
version
(note that defaulting the version wasn't part of the original issue)
- it forces people to use the "features" classifier
- if we attempt to load the file without the features modifier, then on
failure, attempt with
the features modifier, I believe it will be as slow as omitting the version
(I haven't
tested this so I could be wrong)
Overall, it seems to add too much overhead to save a few keystrokes.
> Assume a default type/classified (xml/features) on the features
> addUrl/removeUrl commands
> -
>
> Key: FELIX-1066
> URL: https://issues.apache.org/jira/browse/FELIX-1066
> Project: Felix
> Issue Type: Improvement
> Components: Karaf
>Reporter: Guillaume Nodet
> Attachments: FELIX-1066-OptionalMavenUrlComponents.patch
>
>
> When doing an features/addUrl, you always have to specify the type (xml) and
> classifier (features). How about making that the default, so people can just
> do:
> {code}
> features/addUrl mvn:org.apache.servicemix.features/apache-servicemix/4.0.0
> {code}
> We can always fail-back to type jar if we don't find the xml file to support
> deploying new feature descriptors through a bundle.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1066) Assume a default type/classified (xml/features) on the features addUrl/removeUrl commands
[
https://issues.apache.org/jira/browse/FELIX-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744109#action_12744109
]
Guillaume Nodet commented on FELIX-1066:
I have a problem with this patch. It means if someone has an xml repository
deployed with no maven classifier, it won't work.
mvn:foo/bar/1.0/xml
then this patch will automatically add /features to the uri.
I think it would be better to try loading the file using the plain url, and
maybe try again with /xml/features or /features appended to the uri.
Or maybe it was a bad idea ...
> Assume a default type/classified (xml/features) on the features
> addUrl/removeUrl commands
> -
>
> Key: FELIX-1066
> URL: https://issues.apache.org/jira/browse/FELIX-1066
> Project: Felix
> Issue Type: Improvement
> Components: Karaf
>Reporter: Guillaume Nodet
> Attachments: FELIX-1066-OptionalMavenUrlComponents.patch
>
>
> When doing an features/addUrl, you always have to specify the type (xml) and
> classifier (features). How about making that the default, so people can just
> do:
> {code}
> features/addUrl mvn:org.apache.servicemix.features/apache-servicemix/4.0.0
> {code}
> We can always fail-back to type jar if we don't find the xml file to support
> deploying new feature descriptors through a bundle.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1465) Make symbolic names of Karaf webconsole bundles consistent with other bundles
[ https://issues.apache.org/jira/browse/FELIX-1465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Moloney closed FELIX-1465. -- > Make symbolic names of Karaf webconsole bundles consistent with other bundles > - > > Key: FELIX-1465 > URL: https://issues.apache.org/jira/browse/FELIX-1465 > Project: Felix > Issue Type: Bug > Components: Karaf >Reporter: Tim Moloney >Assignee: Guillaume Nodet >Priority: Trivial > Fix For: karaf-1.0.0 > > Attachments: FELIX-1465-BrandingSymbolicName.patch, > FELIX-1465-KarafSymbolicNames.patch > > > Currently the Karaf webconsole names are > org.apache.felix.karaf.webconsole.org.apache.felix.karaf.webconsole.features > org.apache.felix.karaf.webconsole.org.apache.felix.karaf.webconsole.gogo > when they should be > org.apache.felix.karaf.webconsole.features > org.apache.felix.karaf.webconsole.gogo -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-1465) Make symbolic names of Karaf webconsole bundles consistent with other bundles
[ https://issues.apache.org/jira/browse/FELIX-1465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved FELIX-1465. Resolution: Fixed URL: http://svn.apache.org/viewvc?rev=805007&view=rev Log: FELIX-1465: Make symbolic names of Karaf webconsole bundles consistent with other bundles Modified: felix/trunk/karaf/webconsole/branding/pom.xml > Make symbolic names of Karaf webconsole bundles consistent with other bundles > - > > Key: FELIX-1465 > URL: https://issues.apache.org/jira/browse/FELIX-1465 > Project: Felix > Issue Type: Bug > Components: Karaf >Reporter: Tim Moloney >Assignee: Guillaume Nodet >Priority: Trivial > Fix For: karaf-1.0.0 > > Attachments: FELIX-1465-BrandingSymbolicName.patch, > FELIX-1465-KarafSymbolicNames.patch > > > Currently the Karaf webconsole names are > org.apache.felix.karaf.webconsole.org.apache.felix.karaf.webconsole.features > org.apache.felix.karaf.webconsole.org.apache.felix.karaf.webconsole.gogo > when they should be > org.apache.felix.karaf.webconsole.features > org.apache.felix.karaf.webconsole.gogo -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-1468) wrapper:install and admin:create prints old ansi output that need to be converted to real ansi
[ https://issues.apache.org/jira/browse/FELIX-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved FELIX-1468. Resolution: Fixed URL: http://svn.apache.org/viewvc?rev=805006&view=rev Log: FELIX-1468: The shell:info command use the old @|bold syntax for ansi Modified: felix/trunk/karaf/gshell/gshell-commands/src/main/java/org/apache/felix/karaf/gshell/commands/InfoAction.java > wrapper:install and admin:create prints old ansi output that need to be > converted to real ansi > --- > > Key: FELIX-1468 > URL: https://issues.apache.org/jira/browse/FELIX-1468 > Project: Felix > Issue Type: Bug > Components: Karaf >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet > Fix For: karaf-1.0.0 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1482) Fileinstall try to start all bundles, not only newly installed.
[ https://issues.apache.org/jira/browse/FELIX-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744090#action_12744090 ] Guillaume Nodet commented on FELIX-1482: The thing I'd like to avoid is having fileinstall performing some action as a side effect of an action initiated by the user through another mean. The problem of listening to FRAMEWORK_REFRESHED events is that those might be caused by a refresh done by the user instead of the one from fileinstall. I'm wondering if we should keep the patch as it is and not try too much to manage those failures. I think those should be rare enough ... > Fileinstall try to start all bundles, not only newly installed. > --- > > Key: FELIX-1482 > URL: https://issues.apache.org/jira/browse/FELIX-1482 > Project: Felix > Issue Type: Bug >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet > Fix For: karaf-1.0.0 > > Attachments: FELIX-1482.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-1479) Security errors accessing configurations in the file system
[ https://issues.apache.org/jira/browse/FELIX-1479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved FELIX-1479. -- Resolution: Fixed The original reporter has confirmed the fix to be working correctly. Therefore resolving this issue fixed. > Security errors accessing configurations in the file system > --- > > Key: FELIX-1479 > URL: https://issues.apache.org/jira/browse/FELIX-1479 > Project: Felix > Issue Type: Bug > Components: Configuration Admin >Affects Versions: configadmin-1.0.10 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: configadmin-1.0.12 > > > When the FilePersistenceManager is trying to access the configuration files > it currently does this in the security context of the calling bundle. If the > calling bundle does not have file access permissions, this access fails > (unexpectedly). > The fix is to ensure running in doPrivileged using the configuration admin > bundle's security context to access the files. > More informations from the original reporter: > There seems no test of that SecurityException is thrown because > a configuring bundle CB does not have appropriate Permission to call > ConfigurationAdmin#getConfiguration(pid,location). > # In testGetConfigurationWithLocation(), CB can get a Configuration > # objects because it has AllPermission. > As far as I see, felix cm impl has a bug if the Java Runtime supports > security. In my test, the following Exception is thrown. ( > Currently, the CB fails to get a Configuration. The reason is CB has no > permission to access a file FilePersistenceManager handles. > "doPriviledge" in seems required to avoid it. > > locations[0]=C:\ws\OSGiSVN\cnf\repo\osgi.cmpn\osgi.cmpn-4.2.1.jar > (java.security.AllPermission) > locations[1]=targetB1.jar > (java.security.AllPermission) > locations[2]=C:\ws\OSGiSVN\licensed\repo\org.apache.felix.configadmin\org.apache.felix.configadmin-1.0.10.jar > (java.security.AllPermission) > locations[3]=C:\ws\OSGiSVN\org.osgi.test.cases.cm.ext\generated\org.osgi.test.cases.cm.ext.jar > (java.security.AllPermission) > locations[4]=setAllPermission.jar > (java.security.AllPermission) > locations[5]=configuringB1.jar > (org.osgi.framework.PackagePermission "org.osgi.service.cm" > "IMPORT") > (org.osgi.framework.ServicePermission > "org.osgi.service.cm.ConfigurationAdmin" "GET") > (org.osgi.framework.PackagePermission > "org.osgi.test.cases.cm.ext.util" "IMPORT") > (org.osgi.framework.ServicePermission > "org.osgi.test.cases.cm.ext.util.ResultKeeper" "REGISTER") > (org.osgi.framework.PackagePermission "org.osgi.framework" > "IMPORT") > (org.osgi.service.cm.ConfigurationPermission "*" "CONFIGURE") > locations[6]=System Bundle > (java.security.AllPermission) > default permission= > (java.util.PropertyPermission "java.home" "read") > org.osgi.framework.BundleException: Exception in > org.osgi.test.cases.cm.ext.configuringB1.ConfiguringActivator.start() of > bundle org.osgi.test.cases.cm.ext.configuringB1. > at > org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:805) > at > org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:754) > at > org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:352) > at > org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:280) > at > org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:272) > at > org.osgi.test.cases.cm.ext.tbc.CmExtTestControl.startBundleAndCheckSecurityException(CmExtTestControl.java:2120) > at > org.osgi.test.cases.cm.ext.tbc.CmExtTestControl.testGetConfigurationWithLocation1_1_1(CmExtTestControl.java:227) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at junit.framework.TestCase.runTest(TestCase.java:164) > at junit.framework.TestCase.runBare(TestCase.java:130) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at > junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework
[jira] Resolved: (FELIX-1486) Multiple PIDs must be supported
[ https://issues.apache.org/jira/browse/FELIX-1486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved FELIX-1486. -- Resolution: Fixed Fix Version/s: configadmin-1.0.12 Ikuo Yamasaki confirmed working implementation (Thanks). Therefore resolving this issue. > Multiple PIDs must be supported > --- > > Key: FELIX-1486 > URL: https://issues.apache.org/jira/browse/FELIX-1486 > Project: Felix > Issue Type: Bug > Components: Configuration Admin, Specification compliance >Affects Versions: configadmin-1.0.10 >Reporter: Ikuo YAMASAKI >Assignee: Felix Meschberger > Fix For: configadmin-1.0.12 > > > From R4.2, > - core spec explicitly says SERVICE_PID can be multiple (array or > collections). > - cmpn spec explicitly says ManagedService can have multiple PIDs. > Unfortunately, Felix impl doesn't handle multiple pids properly. > (Felix and I had agreeed that it is a bug.) > I had added some tests into my tests for OSGi-A CT of cm, although I didn't > release it to OSGi SVN > yet. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1484) Dynamically bound configuration must be reset to null after target bundle is uninstalled.
[ https://issues.apache.org/jira/browse/FELIX-1484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-1484. Resolution: Fixed Fix Version/s: configadmin-1.0.12 Closing this fixed. The actual implementation of fixing this is tracked in FELIX-1488 > Dynamically bound configuration must be reset to null after target bundle is > uninstalled. > - > > Key: FELIX-1484 > URL: https://issues.apache.org/jira/browse/FELIX-1484 > Project: Felix > Issue Type: Bug > Components: Configuration Admin >Affects Versions: configadmin-1.0.10 >Reporter: Ikuo YAMASAKI >Assignee: Felix Meschberger > Fix For: configadmin-1.0.12 > > > 1. create a configuration with pid1 and null location. > 2. bundleA, who has locationA, registers ManagedService with pid1. > 3. Then the configuration MUST be "dynamically bound" to bundleA, where the > location of the configuration is set to locationA. > Here, If bundleA is uninstalled, the configuration MUST be unbound again; the > location of the configuration MUST be set to null again. > See 104.4.1 Location Binding in R4.2 cmpn > > A null location parameter may be used to create Configuration objects that > are not bound. In this case, the objects become bound to a specific location > the first time that they are used by a bundle. When this dynamically bound > bundle is subsequently uninstalled, the Configuration object's bundle > location > must be set to null again so it can be bound again later. > > However, the location still keeps bundleA in Felix Cm impl. > That seems a bug. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Configuration Admin Service implementation release
Hi all, As you may know, the OSGi alliance is planning to use the Felix Configuration Admin implementation as its reference implementation for the R 4.2 specification release. At the moment I am working with the help from OSGi members to fix some flaws in the implementation (you may have seen the issue mails). As soon as we are happy with the state, I will cut a release and submit to a vote. I hope, that this will be real soon now. Regards Felix
[jira] Commented: (FELIX-1488) Configuration binding is broken
[ https://issues.apache.org/jira/browse/FELIX-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744012#action_12744012 ] Felix Meschberger commented on FELIX-1488: -- Revisions 804915 and 804916 fix an issue with incorrectly setting the staticallyBound flag: If the bundle location is statically set to null, the flag must be set to false, such that dynamic binding may occurr later when assigning the configuration to a ManagedService. The test case is test_create_with_location_unbind_before_service_supply: 1. create Configuration with pid and non-null location. 2. update the configuration with non-null props. 3. set location of the configuration to null. 4. bundleA registers a ManagedService service with the pid. > Configuration binding is broken > --- > > Key: FELIX-1488 > URL: https://issues.apache.org/jira/browse/FELIX-1488 > Project: Felix > Issue Type: Bug > Components: Configuration Admin >Affects Versions: configadmin-1.0.10 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: configadmin-1.0.12 > > > Configuration can be statically or dynamically bound: > * A configuration is statically bound by explicitly calling the > Configuration.setBundleLocation method or > by creating the configuration object with a non-null bundle location. > Static binding must be persisted and > is only reset by explicitly calling the setBundleLocation with a null > argument. > * A configuration may dynamically bound if the configuration has been > created with a null bundle location and > the setBundleLocation has not been called (or called with a null > argument). If such an unbound configuration > is provided to a ManagedService[Factory] it is dynamically bound to the > service's bundle. Such bundle > binding is not persisted. > The reason why dynamic binding need not be persisted is actually an > implementation detail because we keep used configurations in an internal > cache. Entries in the cache are only removed if the configuration is deleted > or if the configuration admin service is stopped. In the first case, bundle > binding is lost anyway. In the second case dynamic bundle bindings will be > recreated on configuration admin service restart when the configurations are > supplied to ManagedService[Factory] services 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-1491) OBR repository should not attempt to cache local file repositories
[ https://issues.apache.org/jira/browse/FELIX-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Savage closed FELIX-1491. --- Resolution: Fixed Fix Version/s: sigil-1.0.0 > OBR repository should not attempt to cache local file repositories > -- > > Key: FELIX-1491 > URL: https://issues.apache.org/jira/browse/FELIX-1491 > Project: Felix > Issue Type: Improvement > Components: Sigil >Reporter: David Savage >Assignee: David Savage > Fix For: sigil-1.0.0 > > > The OBR repository implementation caches jars and indexes. However this is > not required if the url points to a local file -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1491) OBR repository should not attempt to cache local file repositories
OBR repository should not attempt to cache local file repositories -- Key: FELIX-1491 URL: https://issues.apache.org/jira/browse/FELIX-1491 Project: Felix Issue Type: Improvement Components: Sigil Reporter: David Savage Assignee: David Savage The OBR repository implementation caches jars and indexes. However this is not required if the url points to a local file -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1488) Configuration binding is broken
[ https://issues.apache.org/jira/browse/FELIX-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12743990#action_12743990 ] Felix Meschberger commented on FELIX-1488: -- There is use case not convered by just transiently keeping the dynamic bindings: 1. create configuration pid1 2. start bundle b1 with managed service pid1 ==> configuration is provided to managed service and bound to b1 3. stop bundle b1 ==> configuration is still bound to b1 4. restart configuration admin service ==> configuration must still be bound to b1 Hence the dynamic bindings must also be persisted to survice configuration admin restarts. To facilitate the management of the dynamic bindings we do not store them inside the configuration objects but separately. This allows for simpler cleanup on configuration admin restart (i.e. not requiring to load and verify all configurations). Implemented storage of dynamic bindings (outside of the actual configuration) along with unit and integration tests in Rev. 804891 > Configuration binding is broken > --- > > Key: FELIX-1488 > URL: https://issues.apache.org/jira/browse/FELIX-1488 > Project: Felix > Issue Type: Bug > Components: Configuration Admin >Affects Versions: configadmin-1.0.10 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: configadmin-1.0.12 > > > Configuration can be statically or dynamically bound: > * A configuration is statically bound by explicitly calling the > Configuration.setBundleLocation method or > by creating the configuration object with a non-null bundle location. > Static binding must be persisted and > is only reset by explicitly calling the setBundleLocation with a null > argument. > * A configuration may dynamically bound if the configuration has been > created with a null bundle location and > the setBundleLocation has not been called (or called with a null > argument). If such an unbound configuration > is provided to a ManagedService[Factory] it is dynamically bound to the > service's bundle. Such bundle > binding is not persisted. > The reason why dynamic binding need not be persisted is actually an > implementation detail because we keep used configurations in an internal > cache. Entries in the cache are only removed if the configuration is deleted > or if the configuration admin service is stopped. In the first case, bundle > binding is lost anyway. In the second case dynamic bundle bindings will be > recreated on configuration admin service restart when the configurations are > supplied to ManagedService[Factory] services again. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
