You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@clerezza.apache.org by Reto Bachmann-Gmuer <re...@trialox.org> on 2010/04/14 14:59:11 UTC
Re: Try to use felix 2.1.0-SNAPSHOT
Hi Karl
Now using 2.0.4 with security 1.0.0 after a while the amount of Permssions
object in memory seems to grow massively.
I was wondering about the eqlas implenatiion of Permissions.Entry, anemly
about
if (entry == null)
{
return false;
}
ahouln't this be:
if (entry == null)
{
return ((Entry) o).get() == null;
}
after the instance check?
Cheers,
reto
On Wed, Feb 10, 2010 at 5:27 PM, Karl Pauls <ka...@gmail.com> wrote:
> The vote for felix 2.0.3 is going on as we speak (and includes
> framework.security 1.0.0). I will call it either tonight or tomorrow
> so you'll have felix 2.0.3 and framework.security 1.0.0 by the end of
> the week :-)
>
> regards,
>
> Karl
>
> p.s.: not sure what differences you have inside your security
> branch... I think I recall something about caching permissions but
> I'm pretty sure I never fixed it in the felix provider so you might
> need to patch framework.security 1.0.0 again. If that is the case,
> could you then maybe open a new jira explaining the problems (or point
> me to an old one)? On the upside, framework.security now has support
> for the 4.2 spec :-)
>
> On Wed, Feb 10, 2010 at 4:19 PM, Reto Bachmann-Gmuer
> <re...@trialox.org> wrote:
> > Hi Karl,
> >
> > any ETA for the new security provider and framework release? would be
> great
> > if we could get rid of the clerezza branch of felix security and use a
> > current felix version.
> >
> > Cheers,
> > reto
> >
> > On Fri, Jan 22, 2010 at 9:12 PM, Karl Pauls <ka...@gmail.com> wrote:
> >
> >> You need to update the security provider. There is a new snapshot i
> >> think but otherwise build it yourself. We now have support for 4.2 and
> >> some internal api has changed (thats why you see the error). I'm going
> >> to cut a 1.0.0 release of the security provider any day now (along
> >> with a new version of the framework - which will be based on the
> >> current trunk).
> >>
> >> regards,
> >>
> >> Karl
> >>
> >> On Fri, Jan 22, 2010 at 2:25 PM, Tsuyoshi Ito <ts...@trialox.org>
> >> wrote:
> >> > Hi there
> >> >
> >> > Try to update clerezza.platform.launcher.storageless to use felix
> >> 2.1.0-SNAPSHOT instead of 1.4.1 because of felix framework.security (see
> >> FELIX-1101: https://issues.apache.org/jira/browse/FELIX-1101).
> >> >
> >> > When starting launcher.sesame on
> >> >
> >> > FreeBSD 7.0-RELEASE-p3
> >> >
> >> > java version "1.6.0_07"
> >> > Diablo Java(TM) SE Runtime Environment (build 1.6.0_07-b02)
> >> > Diablo Java HotSpot(TM) Server VM (build 10.0-b23, mixed mode)
> >> >
> >> > the following error occured:
> >> >
> >> > The activate method has thrown an exception
> >> > java.lang.AbstractMethodError:
> >>
> org.apache.felix.framework.SecurityProviderImpl.getSignerMatcher(Lorg/osgi/framework/Bundle;I)Ljava/lang/Object;
> >> > at
> >> org.apache.felix.framework.Felix.getSignerMatcher(Felix.java:3510)
> >> > at
> >>
> org.apache.felix.framework.BundleImpl.getSignerCertificates(BundleImpl.java:847)
> >> > at
> >>
> org.osgi.framework.SignerProperty.isBundleSigned(SignerProperty.java:109)
> >> > at
> >> org.osgi.framework.AdminPermission$1.run(AdminPermission.java:863)
> >> > at java.security.AccessController.doPrivileged(Native Method)
> >> > at
> >>
> org.osgi.framework.AdminPermission.getProperties(AdminPermission.java:854)
> >> > at
> >> org.osgi.framework.AdminPermission.implies0(AdminPermission.java:656)
> >> > at
> >>
> org.osgi.framework.AdminPermissionCollection.implies(AdminPermission.java:993)
> >> > at
> >>
> org.apache.felix.framework.security.util.Permissions.implies(Permissions.java:394)
> >> > at
> >>
> org.apache.felix.framework.security.permissionadmin.PermissionAdminImpl.check(PermissionAdminImpl.java:175)
> >> > at
> >>
> org.apache.felix.framework.security.permissionadmin.PermissionAdminImpl.hasPermission(PermissionAdminImpl.java:157)
> >> > at
> >>
> org.apache.felix.framework.SecurityProviderImpl.hasBundlePermission(SecurityProviderImpl.java:119)
> >> > at
> >>
> org.apache.felix.framework.Felix.impliesBundlePermission(Felix.java:3519)
> >> > at
> >>
> org.apache.felix.framework.BundleProtectionDomain.implies(BundleProtectionDomain.java:67)
> >> > at
> >>
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:301)
> >> > at
> >>
> java.security.AccessController.checkPermission(AccessController.java:546)
> >> > at
> >> java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
> >> > at
> >> org.apache.felix.framework.BundleImpl.getLocation(BundleImpl.java:539)
> >> > at
> >>
> org.apache.clerezza.platform.security.PermissionManager.activate(PermissionManager.java:125)
> >> > 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:597)
> >> > at
> >>
> org.apache.felix.scr.impl.helper.BaseMethod.invokeMethod(BaseMethod.java:213)
> >> > at
> >>
> org.apache.felix.scr.impl.helper.BaseMethod.access$500(BaseMethod.java:38)
> >> > at
> >>
> org.apache.felix.scr.impl.helper.BaseMethod$Resolved.invoke(BaseMethod.java:542)
> >> > at
> >> org.apache.felix.scr.impl.helper.BaseMethod.invoke(BaseMethod.java:434)
> >> > at
> >>
> org.apache.felix.scr.impl.helper.ActivateMethod.invoke(ActivateMethod.java:138)
> >> > at
> >>
> org.apache.felix.scr.impl.manager.ImmediateComponentManager.createImplementationObject(ImmediateComponentManager.java:226)
> >> > at
> >>
> org.apache.felix.scr.impl.manager.ImmediateComponentManager.createComponent(ImmediateComponentManager.java:118)
> >> > at
> >>
> org.apache.felix.scr.impl.manager.AbstractComponentManager$Unsatisfied.activate(AbstractComponentManager.java:991)
> >> > at
> >>
> org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:298)
> >> > at
> >>
> org.apache.felix.scr.impl.manager.AbstractComponentManager$3.doRun(AbstractComponentManager.java:505)
> >> > at
> >>
> org.apache.felix.scr.impl.ComponentActivatorTask.run(ComponentActivatorTask.java:67)
> >> > at
> >>
> org.apache.felix.scr.impl.ComponentActorThread.run(ComponentActorThread.java:96)
> >> > at java.lang.Thread.run(Thread.java:619)
> >> > [SCR Component Actor] ERROR org.apache.clerezza.platform.security -
> >> [org.apache.clerezza.platform.security.PermissionManager] Component
> instance
> >> could not be created, activation failed
> >> >
> >> > I am not sure if I did something wrong because
> >> >
> >> > hasan tested it successfully on his linux machine (unbuntu, don't know
> >> which version of the VM) and Ulf Dittmer wrote:
> >> >
> >> >>
> >> >> Ulf Dittmer commented on FELIX-1101:
> >> >> ------------------------------------
> >> >>
> >> >> If by "the issue you did see" you mean the "RuntimePermission for
> >> getClassLoader", then that's still happening. What's no longer happening
> is
> >> the "getSignerMatcher" issue I mentioned above. I'll create a new issue
> >> about the install/uninstall/reinstall behavior I mentioned in my second
> >> post.
> >> >
> >> > Any ideas?
> >> >
> >> > Cheers
> >> > TSuy
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> Karl Pauls
> >> karlpauls@gmail.com
> >>
> >
>
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
>
Re: Try to use felix 2.1.0-SNAPSHOT
Posted by Karl Pauls <ka...@gmail.com>.
I'm looking into the issue as well :-). For sure you are looking in
the right place, the equals goes wrong and needs to be fixed somehow.
Feel free to try to fix it but otherwise I'll try to look into it too.
regards,
Karl
On Wed, Apr 14, 2010 at 2:59 PM, Reto Bachmann-Gmuer
<re...@trialox.org> wrote:
> Hi Karl
>
> Now using 2.0.4 with security 1.0.0 after a while the amount of Permssions
> object in memory seems to grow massively.
>
> I was wondering about the eqlas implenatiion of Permissions.Entry, anemly
> about
>
> if (entry == null)
> {
> return false;
> }
>
> ahouln't this be:
>
> if (entry == null)
> {
> return ((Entry) o).get() == null;
> }
>
> after the instance check?
>
> Cheers,
> reto
>
> On Wed, Feb 10, 2010 at 5:27 PM, Karl Pauls <ka...@gmail.com> wrote:
>>
>> The vote for felix 2.0.3 is going on as we speak (and includes
>> framework.security 1.0.0). I will call it either tonight or tomorrow
>> so you'll have felix 2.0.3 and framework.security 1.0.0 by the end of
>> the week :-)
>>
>> regards,
>>
>> Karl
>>
>> p.s.: not sure what differences you have inside your security
>> branch... I think I recall something about caching permissions but
>> I'm pretty sure I never fixed it in the felix provider so you might
>> need to patch framework.security 1.0.0 again. If that is the case,
>> could you then maybe open a new jira explaining the problems (or point
>> me to an old one)? On the upside, framework.security now has support
>> for the 4.2 spec :-)
>>
>> On Wed, Feb 10, 2010 at 4:19 PM, Reto Bachmann-Gmuer
>> <re...@trialox.org> wrote:
>> > Hi Karl,
>> >
>> > any ETA for the new security provider and framework release? would be
>> > great
>> > if we could get rid of the clerezza branch of felix security and use a
>> > current felix version.
>> >
>> > Cheers,
>> > reto
>> >
>> > On Fri, Jan 22, 2010 at 9:12 PM, Karl Pauls <ka...@gmail.com> wrote:
>> >
>> >> You need to update the security provider. There is a new snapshot i
>> >> think but otherwise build it yourself. We now have support for 4.2 and
>> >> some internal api has changed (thats why you see the error). I'm going
>> >> to cut a 1.0.0 release of the security provider any day now (along
>> >> with a new version of the framework - which will be based on the
>> >> current trunk).
>> >>
>> >> regards,
>> >>
>> >> Karl
>> >>
>> >> On Fri, Jan 22, 2010 at 2:25 PM, Tsuyoshi Ito <ts...@trialox.org>
>> >> wrote:
>> >> > Hi there
>> >> >
>> >> > Try to update clerezza.platform.launcher.storageless to use felix
>> >> 2.1.0-SNAPSHOT instead of 1.4.1 because of felix framework.security
>> >> (see
>> >> FELIX-1101: https://issues.apache.org/jira/browse/FELIX-1101).
>> >> >
>> >> > When starting launcher.sesame on
>> >> >
>> >> > FreeBSD 7.0-RELEASE-p3
>> >> >
>> >> > java version "1.6.0_07"
>> >> > Diablo Java(TM) SE Runtime Environment (build 1.6.0_07-b02)
>> >> > Diablo Java HotSpot(TM) Server VM (build 10.0-b23, mixed mode)
>> >> >
>> >> > the following error occured:
>> >> >
>> >> > The activate method has thrown an exception
>> >> > java.lang.AbstractMethodError:
>> >>
>> >> org.apache.felix.framework.SecurityProviderImpl.getSignerMatcher(Lorg/osgi/framework/Bundle;I)Ljava/lang/Object;
>> >> > at
>> >> org.apache.felix.framework.Felix.getSignerMatcher(Felix.java:3510)
>> >> > at
>> >>
>> >> org.apache.felix.framework.BundleImpl.getSignerCertificates(BundleImpl.java:847)
>> >> > at
>> >>
>> >> org.osgi.framework.SignerProperty.isBundleSigned(SignerProperty.java:109)
>> >> > at
>> >> org.osgi.framework.AdminPermission$1.run(AdminPermission.java:863)
>> >> > at java.security.AccessController.doPrivileged(Native Method)
>> >> > at
>> >>
>> >> org.osgi.framework.AdminPermission.getProperties(AdminPermission.java:854)
>> >> > at
>> >> org.osgi.framework.AdminPermission.implies0(AdminPermission.java:656)
>> >> > at
>> >>
>> >> org.osgi.framework.AdminPermissionCollection.implies(AdminPermission.java:993)
>> >> > at
>> >>
>> >> org.apache.felix.framework.security.util.Permissions.implies(Permissions.java:394)
>> >> > at
>> >>
>> >> org.apache.felix.framework.security.permissionadmin.PermissionAdminImpl.check(PermissionAdminImpl.java:175)
>> >> > at
>> >>
>> >> org.apache.felix.framework.security.permissionadmin.PermissionAdminImpl.hasPermission(PermissionAdminImpl.java:157)
>> >> > at
>> >>
>> >> org.apache.felix.framework.SecurityProviderImpl.hasBundlePermission(SecurityProviderImpl.java:119)
>> >> > at
>> >>
>> >> org.apache.felix.framework.Felix.impliesBundlePermission(Felix.java:3519)
>> >> > at
>> >>
>> >> org.apache.felix.framework.BundleProtectionDomain.implies(BundleProtectionDomain.java:67)
>> >> > at
>> >>
>> >> java.security.AccessControlContext.checkPermission(AccessControlContext.java:301)
>> >> > at
>> >>
>> >> java.security.AccessController.checkPermission(AccessController.java:546)
>> >> > at
>> >> java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
>> >> > at
>> >> org.apache.felix.framework.BundleImpl.getLocation(BundleImpl.java:539)
>> >> > at
>> >>
>> >> org.apache.clerezza.platform.security.PermissionManager.activate(PermissionManager.java:125)
>> >> > 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:597)
>> >> > at
>> >>
>> >> org.apache.felix.scr.impl.helper.BaseMethod.invokeMethod(BaseMethod.java:213)
>> >> > at
>> >>
>> >> org.apache.felix.scr.impl.helper.BaseMethod.access$500(BaseMethod.java:38)
>> >> > at
>> >>
>> >> org.apache.felix.scr.impl.helper.BaseMethod$Resolved.invoke(BaseMethod.java:542)
>> >> > at
>> >> org.apache.felix.scr.impl.helper.BaseMethod.invoke(BaseMethod.java:434)
>> >> > at
>> >>
>> >> org.apache.felix.scr.impl.helper.ActivateMethod.invoke(ActivateMethod.java:138)
>> >> > at
>> >>
>> >> org.apache.felix.scr.impl.manager.ImmediateComponentManager.createImplementationObject(ImmediateComponentManager.java:226)
>> >> > at
>> >>
>> >> org.apache.felix.scr.impl.manager.ImmediateComponentManager.createComponent(ImmediateComponentManager.java:118)
>> >> > at
>> >>
>> >> org.apache.felix.scr.impl.manager.AbstractComponentManager$Unsatisfied.activate(AbstractComponentManager.java:991)
>> >> > at
>> >>
>> >> org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:298)
>> >> > at
>> >>
>> >> org.apache.felix.scr.impl.manager.AbstractComponentManager$3.doRun(AbstractComponentManager.java:505)
>> >> > at
>> >>
>> >> org.apache.felix.scr.impl.ComponentActivatorTask.run(ComponentActivatorTask.java:67)
>> >> > at
>> >>
>> >> org.apache.felix.scr.impl.ComponentActorThread.run(ComponentActorThread.java:96)
>> >> > at java.lang.Thread.run(Thread.java:619)
>> >> > [SCR Component Actor] ERROR org.apache.clerezza.platform.security -
>> >> [org.apache.clerezza.platform.security.PermissionManager] Component
>> >> instance
>> >> could not be created, activation failed
>> >> >
>> >> > I am not sure if I did something wrong because
>> >> >
>> >> > hasan tested it successfully on his linux machine (unbuntu, don't
>> >> > know
>> >> which version of the VM) and Ulf Dittmer wrote:
>> >> >
>> >> >>
>> >> >> Ulf Dittmer commented on FELIX-1101:
>> >> >> ------------------------------------
>> >> >>
>> >> >> If by "the issue you did see" you mean the "RuntimePermission for
>> >> getClassLoader", then that's still happening. What's no longer
>> >> happening is
>> >> the "getSignerMatcher" issue I mentioned above. I'll create a new issue
>> >> about the install/uninstall/reinstall behavior I mentioned in my second
>> >> post.
>> >> >
>> >> > Any ideas?
>> >> >
>> >> > Cheers
>> >> > TSuy
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Karl Pauls
>> >> karlpauls@gmail.com
>> >>
>> >
>>
>>
>>
>> --
>> Karl Pauls
>> karlpauls@gmail.com
>
>
--
Karl Pauls
karlpauls@gmail.com