incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reto Bachmann-Gmuer <reto.bachm...@trialox.org>
Subject Re: Try to use felix 2.1.0-SNAPSHOT
Date Wed, 14 Apr 2010 12:59:11 GMT
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 <karlpauls@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
> <reto.bachmann@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 <karlpauls@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 <tsuy.ito@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message