[jira] [Updated] (FELIX-4755) [DS] avoid churn when changing global extender property
[ https://issues.apache.org/jira/browse/FELIX-4755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated FELIX-4755: Fix Version/s: (was: scr-2.0.4) scr-2.0.6 > [DS] avoid churn when changing global extender property > --- > > Key: FELIX-4755 > URL: https://issues.apache.org/jira/browse/FELIX-4755 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-2.0.0 >Reporter: David Jencks >Assignee: David Jencks > Fix For: scr-2.0.6 > > > If you change the global extender property through config admin while DS is > running we currently discard everything and start over. It would be better to > figure out which bundles have changed visibility and only add/remove them. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-5176) [DS] Make gogo command more likely to show info from annotations in shell
[ https://issues.apache.org/jira/browse/FELIX-5176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated FELIX-5176: Fix Version/s: (was: scr-2.0.4) scr-2.0.6 > [DS] Make gogo command more likely to show info from annotations in shell > - > > Key: FELIX-5176 > URL: https://issues.apache.org/jira/browse/FELIX-5176 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-2.0.2 >Reporter: David Jencks >Assignee: David Jencks > Fix For: scr-2.0.6 > > > Right now the gogo annotations have to be present at scr startup in order to > be used so the extra info shows up in the gogo shell (import is optional). > Using ServiceFactory for the gogo command (and shell command) and changing > the import to dynamic lets the annotations show up later and still get used. > This depends on only the gogo shell fetching the gogo command, which is not > that much of a restriction -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-4984) Issues in CircularReferenceTest
[
https://issues.apache.org/jira/browse/FELIX-4984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler updated FELIX-4984:
Fix Version/s: (was: scr-2.0.4)
scr-2.0.6
> Issues in CircularReferenceTest
> ---
>
> Key: FELIX-4984
> URL: https://issues.apache.org/jira/browse/FELIX-4984
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR)
>Reporter: Pierre De Rop
>Priority: Minor
> Fix For: scr-2.0.6
>
> Attachments: Felix4984Test.java,
> NPE_in_DependencyManager_line_279421.log.gz, felix-4984.diff,
> org.apache.felix.scr.integration.CircularReferenceTest.test_A11_B0n_delayed_B_first.log,
>
> org.apache.felix.scr.integration.Felix4984Test.test_A11_B0n_delayed_B_first_ABoundToAtMostOneB-NPE-with_patch.log.gz,
>
> org.apache.felix.scr.integration.Felix4984Test.test_A11_B0n_delayed_B_first_ABoundToAtMostOneB.log
>
>
> This issue is described in the dev mailing list, in
> http://www.mail-archive.com/dev@felix.apache.org/msg37281.html
> while working on FELIX-4955, I sometimes have the CircularReferenceTest
> failing.
> Everything is located in my sandbox, in
> http://svn.apache.org/repos/asf/felix/sandbox/pderop/dependencymanager.ds/
> To reproduce the test:
> install eclipse Mars
> install latest bndtools using "install new software" from Eclipse, and then
> add latest stable release from http://dl.bintray.com/bndtools/bndtools/latest/
> install a java8 runtime (I'm using oracle java8 1.8.0_45, 64 bit version).
> The whole new dependencymanager.ds project is intented to be build in java8.
> checkout my sandbox:
> $ svn checkout
> http://svn.apache.org/repos/asf/felix/sandbox/pderop/dependencymanager.ds
> go to "dependencymanager.ds" directory:
> $ cd dependencymanager.ds/
> due to a pending issue, you have to first build the DM bnd annotation plugin
> before importing the project into eclipse. to do so, just type:
> $ ./gradlew org.apache.felix.dependencymanager.annotation:jar
> now launch eclipse and use the the dependencymanager/ds directory as the
> workspace dir for Eclipse.
> switch to BndTools perpective.
> import the bndtools project into eclipse: Import -> Existing Projects into
> Workspace -> Browse -> select dependencymanager.ds directory (it is proposed
> by default).
> normally, and hopefully, everything should compile fine. Junit tests are left
> in org.apache.felix.dependencymanager.ds/ directory and integration tests are
> located in org.apache.felix.dependencymanager.ds.itest/ directory.
> Open under Eclipse the
> org.apache.felix.dependencymanager.ds.itest/src/org/apache/felix/scr/integration/CircularReferenceTest.java
> I slightly modified it in order to dump stack traces when A component is
> bound multiple times to the same B instance.
> (I believe that only delayed components are concerned by the issue).
> For example, in the test_A11_B0n_delayed_A_first() method, I added a call to
> "assertABoundToOneB(a)" like this:
> {code}
> @Test
> public void test_A11_B0n_delayed_A_first() throws InvalidSyntaxException
> {
> String componentNameA = "4.1.A.1.1.dynamic";
> final ComponentConfigurationDTO componentA =
> findComponentConfigurationByName( componentNameA,
> ComponentConfigurationDTO.SATISFIED );
> String componentNameB = "4.1.B.0.n.dynamic";
> final ComponentConfigurationDTO componentB =
> findComponentConfigurationByName( componentNameB,
> ComponentConfigurationDTO.SATISFIED );
> delay();
> A a = getServiceFromConfiguration(componentA, A.class);
> assertABoundToOneB(a);
> delay(); //async binding of a to b after circular ref detected
> B b = getServiceFromConfiguration(componentB, B.class);
> assertEquals( 1, b.getAs().size() );
> }
> {code}
> the "assertABoundToOneB(a)" call does this:
> {code}
> private void assertABoundToOneB(A a) {
> if (a.getBs().size() != 1) {
> System.err.println("detected problem ...");
> a.dumpStackTracesWhenBWasBound();
> }
> assertEquals( 1, a.getBs().size());
> }
> {code}
> And stacktraces will be dumped in order to determine why A was bound two
> times to the same B instance.
> it's possible that you have to run several times the "CircularReferenceTest"
> test before having a failure (and some stacktraces).
> Thanks.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-5205) Webconsole and text console throw IllegalStateException
[ https://issues.apache.org/jira/browse/FELIX-5205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15362158#comment-15362158 ] Carsten Ziegeler commented on FELIX-5205: - This sounds somehow similar to FELIX-5284 > Webconsole and text console throw IllegalStateException > --- > > Key: FELIX-5205 > URL: https://issues.apache.org/jira/browse/FELIX-5205 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR), Gogo Shell, Web Console >Affects Versions: scr-2.0.2 > Environment: Mac OSX 10.11.2 Java 1.8.0_66 >Reporter: Frank Lyaruu >Assignee: David Jencks > > Recently I've upgraded my application from using Karaf 3.x to Karaf 4.x. The > application works fine, but sometimes (I can't reproduce consistenly but it > happens regularly) the 'Components' tab of the webconsole throws an > IllegalStateException: > Problem accessing /system/console/components. Reason: > Server Error > Caused by: > java.lang.IllegalStateException: Invalid BundleContext. > at > org.apache.felix.framework.BundleContextImpl.checkValidity(BundleContextImpl.java:511) > at > org.apache.felix.framework.BundleContextImpl.getBundle(BundleContextImpl.java:114) > at > org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.bundleToDTO(ServiceComponentRuntimeImpl.java:345) > at > org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.holderToDescription(ServiceComponentRuntimeImpl.java:241) > at > org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.getComponentDescriptionDTOs(ServiceComponentRuntimeImpl.java:79) > at > org.apache.felix.webconsole.plugins.ds.internal.WebConsolePlugin$RequestInfo.(WebConsolePlugin.java:615) > at > org.apache.felix.webconsole.plugins.ds.internal.WebConsolePlugin.doGet(WebConsolePlugin.java:177) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at > org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:567) > at > org.apache.felix.webconsole.internal.servlet.KarafOsgiManager.doService(KarafOsgiManager.java:78) > at > org.apache.felix.webconsole.internal.servlet.KarafOsgiManager$1.run(KarafOsgiManager.java:58) > at java.security.AccessController.doPrivileged(Native Method) > at org.apache.karaf.util.jaas.JaasHelper.doAs(JaasHelper.java:103) > at > org.apache.felix.webconsole.internal.servlet.KarafOsgiManager.service(KarafOsgiManager.java:56) > at > org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:812) > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:587) > > If I do a 'scr:list' in the Gogo shell, I get a similar error: > 2016-03-02 14:48:25,065 | ERROR | nsole user karaf | ShellUtil > | 58 - org.apache.karaf.shell.core - 4.0.4 | Exception caught while > executing command > java.lang.IllegalStateException: Invalid BundleContext. > at > org.apache.felix.framework.BundleContextImpl.checkValidity(BundleContextImpl.java:511) > at > org.apache.felix.framework.BundleContextImpl.getBundle(BundleContextImpl.java:114) > at > org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.bundleToDTO(ServiceComponentRuntimeImpl.java:345) > at > org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.holderToDescription(ServiceComponentRuntimeImpl.java:241) > at > org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.getComponentDescriptionDTOs(ServiceComponentRuntimeImpl.java:79) > at org.apache.felix.scr.impl.ScrCommand.list(ScrCommand.java:248) > at org.apache.felix.scr.impl.ScrGogoCommand.list(ScrGogoCommand.java:64) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native > Method)[:1.8.0_66-internal] > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)[:1.8.0_66-internal] > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.8.0_66-internal] > at java.lang.reflect.Method.invoke(Method.java:497)[:1.8.0_66-internal] > at > org.apache.felix.gogo.runtime.Reflective.invoke(Reflective.java:137)[58:org.apache.karaf.shell.core:4.0.4] > ... > That it happens both in Gogo and Webconsole makes me think the problem is in > SCR. Any ideas? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-5275) Felix & Equinox handling of OSGI-INF/permissions.perm differs
[ https://issues.apache.org/jira/browse/FELIX-5275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15362168#comment-15362168 ] Carsten Ziegeler commented on FELIX-5275: - [~db82407] I read the linked eclipse issue and tbh I don't understand what needs to be fixed in our config admin implementation and how. Do you have any additional information? > Felix & Equinox handling of OSGI-INF/permissions.perm differs > - > > Key: FELIX-5275 > URL: https://issues.apache.org/jira/browse/FELIX-5275 > Project: Felix > Issue Type: Bug > Components: Configuration Admin, Framework Security >Affects Versions: configadmin-1.8.8 > Environment: Felix config-admin 1.8.8 running on Equinox with > SecurityManager >Reporter: Derek Baum > > Using Felix config-admin 1.8.8 in Equinox, with a SecurityManager active, > causes the ManagedService.updated() method to get AccessControlExceptions > when, for example, accessing System properties. > This is caused by: > #1 OSGI-INF/permissions.perm added to config-admin in FELIX-4039 > #2 Different handling of OSGI-INF/permissions.perm between Felix and Equinox. > I have previously raised this problem against Equinox (see External Issue > URL), and this is the gist of their analysis: > --- > The felix CM implementation is scoping their own permissions down to a strict > subset of permissions and Equinox is correctly enforcing that subset of > permissions. > So your bundle tries to read a system property, but the CM impl is not > authorized to read that property. > One complication may be that Felix is allowing its bundle protection domains > to be configured with the java policy file (because their ProtectionDomains > are constructed with that 4 arg constructor). > This would seem to break the specified behavior though, because clearly the > CM implementation should never be allowed to have permission to do things > outside of what is specified by the permissions.perm file or that are > "implied" permissions auto-granted by the framework for each bundle. > --- -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-5088) CaseSensitiveDictionary should implement equals()
[
https://issues.apache.org/jira/browse/FELIX-5088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler updated FELIX-5088:
Fix Version/s: configadmin-1.8.10
> CaseSensitiveDictionary should implement equals()
> -
>
> Key: FELIX-5088
> URL: https://issues.apache.org/jira/browse/FELIX-5088
> Project: Felix
> Issue Type: Improvement
> Components: Configuration Admin
>Affects Versions: configadmin-1.8.8
>Reporter: Eric Lessard
>Priority: Minor
> Fix For: configadmin-1.8.10
>
>
> {{Configuration.getProperties()}} currently returns an instance of
> {{CaseSensitiveDictionary}} which does not implement the {{equals()}} method.
> This forces clients to write their own comparison code if they want to
> compare {{CaseSensitiveDictionary}} objects.
> To minimize duplication in client code and have a common way of comparison,
> the {{CaseSensitiveDictionary}} class should provide an implementation of the
> {{equals()}} method.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (FELIX-5088) CaseSensitiveDictionary should implement equals()
[
https://issues.apache.org/jira/browse/FELIX-5088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler reassigned FELIX-5088:
---
Assignee: Carsten Ziegeler
> CaseSensitiveDictionary should implement equals()
> -
>
> Key: FELIX-5088
> URL: https://issues.apache.org/jira/browse/FELIX-5088
> Project: Felix
> Issue Type: Improvement
> Components: Configuration Admin
>Affects Versions: configadmin-1.8.8
>Reporter: Eric Lessard
>Assignee: Carsten Ziegeler
>Priority: Minor
> Fix For: configadmin-1.8.10
>
>
> {{Configuration.getProperties()}} currently returns an instance of
> {{CaseSensitiveDictionary}} which does not implement the {{equals()}} method.
> This forces clients to write their own comparison code if they want to
> compare {{CaseSensitiveDictionary}} objects.
> To minimize duplication in client code and have a common way of comparison,
> the {{CaseSensitiveDictionary}} class should provide an implementation of the
> {{equals()}} method.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (FELIX-5088) CaseSensitiveDictionary should implement equals()
[
https://issues.apache.org/jira/browse/FELIX-5088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler resolved FELIX-5088.
-
Resolution: Fixed
I've added an equals() method to the dictionary
> CaseSensitiveDictionary should implement equals()
> -
>
> Key: FELIX-5088
> URL: https://issues.apache.org/jira/browse/FELIX-5088
> Project: Felix
> Issue Type: Improvement
> Components: Configuration Admin
>Affects Versions: configadmin-1.8.8
>Reporter: Eric Lessard
>Assignee: Carsten Ziegeler
>Priority: Minor
> Fix For: configadmin-1.8.10
>
>
> {{Configuration.getProperties()}} currently returns an instance of
> {{CaseSensitiveDictionary}} which does not implement the {{equals()}} method.
> This forces clients to write their own comparison code if they want to
> compare {{CaseSensitiveDictionary}} objects.
> To minimize duplication in client code and have a common way of comparison,
> the {{CaseSensitiveDictionary}} class should provide an implementation of the
> {{equals()}} method.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (FELIX-5301) ConfigurationPlugin support is not spec compliant
Carsten Ziegeler created FELIX-5301: --- Summary: ConfigurationPlugin support is not spec compliant Key: FELIX-5301 URL: https://issues.apache.org/jira/browse/FELIX-5301 Project: Felix Issue Type: Bug Components: Configuration Admin Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: configadmin-1.8.10 There are some issues with the configuration plugin support: - modifications from plugins with a ranking below 0 or above 1000 should be ignored - the cmRanking property should only be used if it is of type Integer (not Number) - we need to check to clear out bundleLocation before passing the properties to the plugin - auto properties need to be reset after each plugin call (needs to be checked) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-5129) [DS] ScrInfo info should more explicitly indicatte there are no component configurations
[ https://issues.apache.org/jira/browse/FELIX-5129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated FELIX-5129: Issue Type: Improvement (was: Bug) > [DS] ScrInfo info should more explicitly indicatte there are no component > configurations > > > Key: FELIX-5129 > URL: https://issues.apache.org/jira/browse/FELIX-5129 > Project: Felix > Issue Type: Improvement > Components: Declarative Services (SCR) >Affects Versions: scr-2.0.2 >Reporter: David Jencks >Assignee: David Jencks > Fix For: scr-2.0.4 > > > Ray Auge thinks it would be easier to understand if the info explicitly said > there were no component configurations for an enabled component when in fact > there are none. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-5194) [DS] Pay attention if configuration change count doesn't change
[ https://issues.apache.org/jira/browse/FELIX-5194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated FELIX-5194: Issue Type: Improvement (was: Bug) > [DS] Pay attention if configuration change count doesn't change > --- > > Key: FELIX-5194 > URL: https://issues.apache.org/jira/browse/FELIX-5194 > Project: Felix > Issue Type: Improvement > Components: Declarative Services (SCR) >Affects Versions: scr-2.0.2 >Reporter: David Jencks >Assignee: David Jencks > Fix For: scr-2.0.4 > > > Apparently with the R6 work I left out the check that we only pay attention > to an alleged configuration change if the change count actually increases. > I'm not sure how to write a test for this without writing a whole mock CA, so > I'm fixing the evident problem without a test. > I'm taking this opportunity to insist on CA 1.5 or later, so changeCount() is > always available, as discussed on the dev list. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-5174) [DS] logging involving Configuration should show change count
[ https://issues.apache.org/jira/browse/FELIX-5174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated FELIX-5174: Issue Type: Improvement (was: Bug) > [DS] logging involving Configuration should show change count > - > > Key: FELIX-5174 > URL: https://issues.apache.org/jira/browse/FELIX-5174 > Project: Felix > Issue Type: Improvement > Components: Declarative Services (SCR) >Affects Versions: scr-2.0.2 >Reporter: David Jencks >Assignee: David Jencks > Fix For: scr-2.0.4 > > > When we log info about dealing with a configuration, we should log the change > count; it's there and can easily indicate more about how DS is interacting > with config admin. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-5257) [DS] Improve formatting of command list output
[ https://issues.apache.org/jira/browse/FELIX-5257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated FELIX-5257: Issue Type: Improvement (was: Bug) > [DS] Improve formatting of command list output > -- > > Key: FELIX-5257 > URL: https://issues.apache.org/jira/browse/FELIX-5257 > Project: Felix > Issue Type: Improvement > Components: Declarative Services (SCR) >Affects Versions: scr-2.0.2 >Reporter: David Jencks >Assignee: David Jencks > Fix For: scr-2.0.4 > > > There are some indentation problems and the properties could be labeled whit > what they are for. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-5301) ConfigurationPlugin support is not spec compliant
[ https://issues.apache.org/jira/browse/FELIX-5301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated FELIX-5301: Description: There are some issues with the configuration plugin support: - modifications from plugins with a ranking below 0 or above 1000 should be ignored - the cmRanking property should only be used if it is of type Integer (not Number) was: There are some issues with the configuration plugin support: - modifications from plugins with a ranking below 0 or above 1000 should be ignored - the cmRanking property should only be used if it is of type Integer (not Number) - we need to check to clear out bundleLocation before passing the properties to the plugin - auto properties need to be reset after each plugin call (needs to be checked) > ConfigurationPlugin support is not spec compliant > - > > Key: FELIX-5301 > URL: https://issues.apache.org/jira/browse/FELIX-5301 > Project: Felix > Issue Type: Bug > Components: Configuration Admin >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: configadmin-1.8.10 > > > There are some issues with the configuration plugin support: > - modifications from plugins with a ranking below 0 or above 1000 should be > ignored > - the cmRanking property should only be used if it is of type Integer (not > Number) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-4142) WebConsole doesn't allow installation of multiple versions of a bundle
[ https://issues.apache.org/jira/browse/FELIX-4142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergiy Shyrkov updated FELIX-4142: -- Attachment: BundlesServlet.patch Hello, I've attached a suggested patch for the BundlesServlet which considers also the version of the bundle when searching for a matching bundle to update. The patch is against version 4.2.16. Thank you in advance! Kind regards Sergiy > WebConsole doesn't allow installation of multiple versions of a bundle > -- > > Key: FELIX-4142 > URL: https://issues.apache.org/jira/browse/FELIX-4142 > Project: Felix > Issue Type: Bug > Components: Web Console >Affects Versions: webconsole-4.2.0 >Reporter: Jonathan Pierce >Priority: Minor > Attachments: BundlesServlet.patch > > > Currently when using the install button on the BundleServlet, it compares the > bundle symbolic name to determine whether or not to install (name match NOT > found), or update (name match found). It seems like it would be better to do > a comparison of the name and version so that multiple versions of a bundle > could be installed. Or at least add an option to the install dialog to allow > for it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[VOTE] Release Apache Felix SCR 2.0.4
I would like to call a vote on the following subproject releases: SCR 2.0.4 http://svn.apache.org/repos/asf/felix/releases/org.apache.felix.scr-2.0.4/changelog.txt We solved 24 issues in that release. Staging repositories: https://repository.apache.org/content/repositories/orgapachefelix-1125/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1125 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) Thanks Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [VOTE] Release Apache Felix SCR 2.0.4
+1 David On 5 July 2016 at 10:24, Carsten Ziegeler wrote: > I would like to call a vote on the following subproject releases: > > SCR 2.0.4 > > http://svn.apache.org/repos/asf/felix/releases/org.apache.felix.scr-2.0.4/changelog.txt > > We solved 24 issues in that release. > > > Staging repositories: > https://repository.apache.org/content/repositories/orgapachefelix-1125/ > > You can use this UNIX script to download the release and verify the > signatures: > http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh > > Usage: > sh check_staged_release.sh 1125 /tmp/felix-staging > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Veto the release (please provide specific comments) > > Thanks > Carsten > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org >
Re: [VOTE] Release Apache Felix SCR 2.0.4
+1 -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[jira] [Commented] (FELIX-5275) Felix & Equinox handling of OSGI-INF/permissions.perm differs
[ https://issues.apache.org/jira/browse/FELIX-5275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15362304#comment-15362304 ] Karl Pauls commented on FELIX-5275: --- I don't think this is a bug at all. Looks like felix, felix.security, and CM are doing the right thing. > Felix & Equinox handling of OSGI-INF/permissions.perm differs > - > > Key: FELIX-5275 > URL: https://issues.apache.org/jira/browse/FELIX-5275 > Project: Felix > Issue Type: Bug > Components: Configuration Admin, Framework Security >Affects Versions: configadmin-1.8.8 > Environment: Felix config-admin 1.8.8 running on Equinox with > SecurityManager >Reporter: Derek Baum > > Using Felix config-admin 1.8.8 in Equinox, with a SecurityManager active, > causes the ManagedService.updated() method to get AccessControlExceptions > when, for example, accessing System properties. > This is caused by: > #1 OSGI-INF/permissions.perm added to config-admin in FELIX-4039 > #2 Different handling of OSGI-INF/permissions.perm between Felix and Equinox. > I have previously raised this problem against Equinox (see External Issue > URL), and this is the gist of their analysis: > --- > The felix CM implementation is scoping their own permissions down to a strict > subset of permissions and Equinox is correctly enforcing that subset of > permissions. > So your bundle tries to read a system property, but the CM impl is not > authorized to read that property. > One complication may be that Felix is allowing its bundle protection domains > to be configured with the java policy file (because their ProtectionDomains > are constructed with that 4 arg constructor). > This would seem to break the specified behavior though, because clearly the > CM implementation should never be allowed to have permission to do things > outside of what is specified by the permissions.perm file or that are > "implied" permissions auto-granted by the framework for each bundle. > --- -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-5275) Felix & Equinox handling of OSGI-INF/permissions.perm differs
[ https://issues.apache.org/jira/browse/FELIX-5275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15362317#comment-15362317 ] Karl Pauls commented on FELIX-5275: --- >From what I can tell given the description and the equinox issue, this really >is just a misunderstanding on how security is working in java. The test bundle in this example is invoking privileged code (getting the java.home property) - hence, the test bundle needs the required permission to do that (it probably did get it - hard to say from the example). However, any other code on the call stack although needs that permission _unless_ the test bundle does wrap that call into a doPriv (which it doesn't). Now in OSGi, if a bundle has a OSGI-INF/permissions.perm file, its _effective_ permissions will be limited to the permissions listed in that file (no matter what permissions you assign to that bundle). As a result what happens here is: CM with (presumably) all permission has permissions.perm without java.home access permission and calls update method of test bundle; test bundle (presumably) has permission to access java.home and does so without doPriv block around call; result should be (and apparently is) a security exception because the effective permissions of CM on the call stack doesn't allow access to java.home. The correct thing for the test bundle is to wrap access to java.home in a doPriv. > Felix & Equinox handling of OSGI-INF/permissions.perm differs > - > > Key: FELIX-5275 > URL: https://issues.apache.org/jira/browse/FELIX-5275 > Project: Felix > Issue Type: Bug > Components: Configuration Admin, Framework Security >Affects Versions: configadmin-1.8.8 > Environment: Felix config-admin 1.8.8 running on Equinox with > SecurityManager >Reporter: Derek Baum > > Using Felix config-admin 1.8.8 in Equinox, with a SecurityManager active, > causes the ManagedService.updated() method to get AccessControlExceptions > when, for example, accessing System properties. > This is caused by: > #1 OSGI-INF/permissions.perm added to config-admin in FELIX-4039 > #2 Different handling of OSGI-INF/permissions.perm between Felix and Equinox. > I have previously raised this problem against Equinox (see External Issue > URL), and this is the gist of their analysis: > --- > The felix CM implementation is scoping their own permissions down to a strict > subset of permissions and Equinox is correctly enforcing that subset of > permissions. > So your bundle tries to read a system property, but the CM impl is not > authorized to read that property. > One complication may be that Felix is allowing its bundle protection domains > to be configured with the java policy file (because their ProtectionDomains > are constructed with that 4 arg constructor). > This would seem to break the specified behavior though, because clearly the > CM implementation should never be allowed to have permission to do things > outside of what is specified by the permissions.perm file or that are > "implied" permissions auto-granted by the framework for each bundle. > --- -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] Release Apache Felix SCR 2.0.4
+1 (non binding) Regards JB On 07/05/2016 11:24 AM, Carsten Ziegeler wrote: I would like to call a vote on the following subproject releases: SCR 2.0.4 http://svn.apache.org/repos/asf/felix/releases/org.apache.felix.scr-2.0.4/changelog.txt We solved 24 issues in that release. Staging repositories: https://repository.apache.org/content/repositories/orgapachefelix-1125/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1125 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) Thanks Carsten -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
[jira] [Commented] (FELIX-5275) Felix & Equinox handling of OSGI-INF/permissions.perm differs
[ https://issues.apache.org/jira/browse/FELIX-5275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15362331#comment-15362331 ] Karl Pauls commented on FELIX-5275: --- Granted, if you tested this with security enabled and the framework.security provider installed and it works in Felix without a doPriv in the test bundle than this is real bug - otherwise, I'd say close this issue. > Felix & Equinox handling of OSGI-INF/permissions.perm differs > - > > Key: FELIX-5275 > URL: https://issues.apache.org/jira/browse/FELIX-5275 > Project: Felix > Issue Type: Bug > Components: Configuration Admin, Framework Security >Affects Versions: configadmin-1.8.8 > Environment: Felix config-admin 1.8.8 running on Equinox with > SecurityManager >Reporter: Derek Baum > > Using Felix config-admin 1.8.8 in Equinox, with a SecurityManager active, > causes the ManagedService.updated() method to get AccessControlExceptions > when, for example, accessing System properties. > This is caused by: > #1 OSGI-INF/permissions.perm added to config-admin in FELIX-4039 > #2 Different handling of OSGI-INF/permissions.perm between Felix and Equinox. > I have previously raised this problem against Equinox (see External Issue > URL), and this is the gist of their analysis: > --- > The felix CM implementation is scoping their own permissions down to a strict > subset of permissions and Equinox is correctly enforcing that subset of > permissions. > So your bundle tries to read a system property, but the CM impl is not > authorized to read that property. > One complication may be that Felix is allowing its bundle protection domains > to be configured with the java policy file (because their ProtectionDomains > are constructed with that 4 arg constructor). > This would seem to break the specified behavior though, because clearly the > CM implementation should never be allowed to have permission to do things > outside of what is specified by the permissions.perm file or that are > "implied" permissions auto-granted by the framework for each bundle. > --- -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-5275) Felix & Equinox handling of OSGI-INF/permissions.perm differs
[ https://issues.apache.org/jira/browse/FELIX-5275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15362332#comment-15362332 ] Karl Pauls commented on FELIX-5275: --- Just for completeness sake: 1) felix should honor the OSGI-INF/permissions.perm file assuming it is run with security enabled and the framework.security provider being installed (otherwise, its a bug). 2) This has nothing todo whatsoever with Felix honoring the java security policy file (and for that reason using the 4 arg constructor). Yes, we do that as a (arguably framework specific - because it not spec'ed) feature but it is perfectly fine from a spec point of view (at least from my POV). The thing is that one might want to run felix with security enabled but _without_ framework.security installed. We allow that and enable the user to use a normal java security policy to assign permissions to bundles in that case but that has no impact in this case. > Felix & Equinox handling of OSGI-INF/permissions.perm differs > - > > Key: FELIX-5275 > URL: https://issues.apache.org/jira/browse/FELIX-5275 > Project: Felix > Issue Type: Bug > Components: Configuration Admin, Framework Security >Affects Versions: configadmin-1.8.8 > Environment: Felix config-admin 1.8.8 running on Equinox with > SecurityManager >Reporter: Derek Baum > > Using Felix config-admin 1.8.8 in Equinox, with a SecurityManager active, > causes the ManagedService.updated() method to get AccessControlExceptions > when, for example, accessing System properties. > This is caused by: > #1 OSGI-INF/permissions.perm added to config-admin in FELIX-4039 > #2 Different handling of OSGI-INF/permissions.perm between Felix and Equinox. > I have previously raised this problem against Equinox (see External Issue > URL), and this is the gist of their analysis: > --- > The felix CM implementation is scoping their own permissions down to a strict > subset of permissions and Equinox is correctly enforcing that subset of > permissions. > So your bundle tries to read a system property, but the CM impl is not > authorized to read that property. > One complication may be that Felix is allowing its bundle protection domains > to be configured with the java policy file (because their ProtectionDomains > are constructed with that 4 arg constructor). > This would seem to break the specified behavior though, because clearly the > CM implementation should never be allowed to have permission to do things > outside of what is specified by the permissions.perm file or that are > "implied" permissions auto-granted by the framework for each bundle. > --- -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-5275) Felix & Equinox handling of OSGI-INF/permissions.perm differs
[ https://issues.apache.org/jira/browse/FELIX-5275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15362350#comment-15362350 ] Derek Baum commented on FELIX-5275: --- Karl, thanks for your comments. Our use-case is indeed running with security enabled but _without_ framework.security installed. This is because we have some legacy RMI code that requires a SecurityManager, but we don’t otherwise use security and so we specify a policy that grants all permission. Thanks for indicating the reason that this works in Felix, (but not in Equinox), is because delegation to the java security policy (using the 4-arg ProtectionDomain constructor) is not spec’ed and is therefore framework-specific. This explains why our code runs with Felix + Felix CM, but not with Equinox + Felix CM. > Felix & Equinox handling of OSGI-INF/permissions.perm differs > - > > Key: FELIX-5275 > URL: https://issues.apache.org/jira/browse/FELIX-5275 > Project: Felix > Issue Type: Bug > Components: Configuration Admin, Framework Security >Affects Versions: configadmin-1.8.8 > Environment: Felix config-admin 1.8.8 running on Equinox with > SecurityManager >Reporter: Derek Baum > > Using Felix config-admin 1.8.8 in Equinox, with a SecurityManager active, > causes the ManagedService.updated() method to get AccessControlExceptions > when, for example, accessing System properties. > This is caused by: > #1 OSGI-INF/permissions.perm added to config-admin in FELIX-4039 > #2 Different handling of OSGI-INF/permissions.perm between Felix and Equinox. > I have previously raised this problem against Equinox (see External Issue > URL), and this is the gist of their analysis: > --- > The felix CM implementation is scoping their own permissions down to a strict > subset of permissions and Equinox is correctly enforcing that subset of > permissions. > So your bundle tries to read a system property, but the CM impl is not > authorized to read that property. > One complication may be that Felix is allowing its bundle protection domains > to be configured with the java policy file (because their ProtectionDomains > are constructed with that 4 arg constructor). > This would seem to break the specified behavior though, because clearly the > CM implementation should never be allowed to have permission to do things > outside of what is specified by the permissions.perm file or that are > "implied" permissions auto-granted by the framework for each bundle. > --- -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FELIX-5301) ConfigurationPlugin support is not spec compliant
[ https://issues.apache.org/jira/browse/FELIX-5301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved FELIX-5301. - Resolution: Fixed Fixed the above mentioned problems. > ConfigurationPlugin support is not spec compliant > - > > Key: FELIX-5301 > URL: https://issues.apache.org/jira/browse/FELIX-5301 > Project: Felix > Issue Type: Bug > Components: Configuration Admin >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: configadmin-1.8.10 > > > There are some issues with the configuration plugin support: > - modifications from plugins with a ranking below 0 or above 1000 should be > ignored > - the cmRanking property should only be used if it is of type Integer (not > Number) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] Release Apache Felix SCR 2.0.4
+1 (non-binding) - Ray On Jul 5, 2016 6:16 AM, "Jean-Baptiste Onofré" wrote: > +1 (non binding) > > Regards > JB > > On 07/05/2016 11:24 AM, Carsten Ziegeler wrote: > >> I would like to call a vote on the following subproject releases: >> >> SCR 2.0.4 >> >> http://svn.apache.org/repos/asf/felix/releases/org.apache.felix.scr-2.0.4/changelog.txt >> >> We solved 24 issues in that release. >> >> >> Staging repositories: >> https://repository.apache.org/content/repositories/orgapachefelix-1125/ >> >> You can use this UNIX script to download the release and verify the >> signatures: >> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh >> >> Usage: >> sh check_staged_release.sh 1125 /tmp/felix-staging >> >> Please vote to approve this release: >> >> [ ] +1 Approve the release >> [ ] -1 Veto the release (please provide specific comments) >> >> Thanks >> Carsten >> >> > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com >
Re: [VOTE] Release Apache Felix SCR 2.0.4
+1 (non binding) Christian Schneider On 05.07.2016 11:24, Carsten Ziegeler wrote: I would like to call a vote on the following subproject releases: SCR 2.0.4 http://svn.apache.org/repos/asf/felix/releases/org.apache.felix.scr-2.0.4/changelog.txt We solved 24 issues in that release. Staging repositories: https://repository.apache.org/content/repositories/orgapachefelix-1125/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1125 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) Thanks Carsten -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: [SCR] New Release?
Carsten, would you consider also releasing the new scr-ext-anno project? I think having this available would make it a lot easier to use the various felix ds extensions. Thanks for cleaning up the changelog and getting started on the release so quickly :-) thanks david jencks > On Jul 4, 2016, at 9:53 PM, David Jencks > wrote: > > Well, I haven’t gotten confirmation from Tim Ward that his problem is fixed, > and I haven’t been able to reproduce David Leangen’s problem with startup > order, but I fixed all the problems I know about and can reproduce. So lets > go for it. It’s been way to long. > > thanks > david jencks >> On Jul 4, 2016, at 7:53 AM, Carsten Ziegeler wrote: >> >> Any news here? It would really be great to get a new release out >> >> >> Regards >> Carsten >> -- >> Carsten Ziegeler >> Adobe Research Switzerland >> cziege...@apache.org >
Re: [SCR] New Release?
David Jencks wrote > Carsten, would you consider also releasing the new scr-ext-anno project? I > think having this available would make it a lot easier to use the various > felix ds extensions. > sure, I'll either do it today or right away tomorrow. > Thanks for cleaning up the changelog and getting started on the release so > quickly :-) :) Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[VOTE] Release Apache Felix ConfigAdmin 1.8.10
I would like to call a vote on the following subproject releases: ConfigAdmin 1.8.10 http://svn.apache.org/repos/asf/felix/releases/org.apache.felix.configadmin-1.8.10/changelog.txt We solved 2 issues in that release. Staging repositories: https://repository.apache.org/content/repositories/orgapachefelix-1127/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1127 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) Thanks Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[VOTE] Release Apache Felix SCR Ext Anno 1.0.0
I would like to call a vote on the following subproject releases: SCR Ext Anno 1.0.0 This is the first public release Staging repositories: https://repository.apache.org/content/repositories/orgapachefelix-1126/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1126 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) Thanks Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [VOTE] Release Apache Felix ConfigAdmin 1.8.10
+1 (non binding) Regards JB On 07/06/2016 07:17 AM, Carsten Ziegeler wrote: I would like to call a vote on the following subproject releases: ConfigAdmin 1.8.10 http://svn.apache.org/repos/asf/felix/releases/org.apache.felix.configadmin-1.8.10/changelog.txt We solved 2 issues in that release. Staging repositories: https://repository.apache.org/content/repositories/orgapachefelix-1127/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1127 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) Thanks Carsten -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: [VOTE] Release Apache Felix ConfigAdmin 1.8.10
+1 -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[VOTE] Release Apache Felix SCR Compat 1.0.4
I would like to call a vote on the following subproject releases: SCR Compat 1.0.4 http://svn.apache.org/repos/asf/felix/releases/org.apache.felix.scr.compat-1.0.4/changelog.txt We solved 1 issue in that release. Staging repositories: https://repository.apache.org/content/repositories/orgapachefelix-1128/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1128 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) Thanks Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [VOTE] Release Apache Felix SCR Compat 1.0.4
+1 -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [VOTE] Release Apache Felix SCR Ext Anno 1.0.0
+1 -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [VOTE] Release Apache Felix SCR Compat 1.0.4
+1 (non binding) Regards JB On 07/06/2016 07:37 AM, Carsten Ziegeler wrote: I would like to call a vote on the following subproject releases: SCR Compat 1.0.4 http://svn.apache.org/repos/asf/felix/releases/org.apache.felix.scr.compat-1.0.4/changelog.txt We solved 1 issue in that release. Staging repositories: https://repository.apache.org/content/repositories/orgapachefelix-1128/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1128 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) Thanks Carsten -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
