Re: [Discuss] Do we need to support other logging frameworks in felix framework?
I’m not sure what’s happening with the log service in R7, but in R6 it appears in the cmpn rather than core spec. It might be a bit confusing for the framework to contain the LogService interface but not export it. What exactly is wrong with using jul? Aren’t there lightweight adapters available for everyones choice of favorite log service? david jencks > On Mar 1, 2017, at 1:36 PM, Christian Schneider > wrote: > > I just had an idea that might solve the problem of being flexible about the > logger while not using reflection. > > How about using the LogService interface to provide an adapter to an > arbitrary logger? > > We use the FrameworkFactory config to specify a logger. Either as an object > if that is possible or as a class name given by the caller. > The logger must implement LogService and can then internally bridge to any > logging framework. > > Using the well known LogService interface would allow to avoid reflection and > we also do not need to change the spec. Of course the spec could still be > changed to standardize how to specify a logger like this but we could easily > already start just in felix. > > > Christian > > > On 24.02.2017 15:32, Christian Schneider wrote: >> Currently felix framework uses reflection to allow other logging frameworks. >> It is a quite complicated and still pretty limited approach. >> As far as I know this is only used for karaf to hook in. So I propose to >> only allow to choose jul as it is built in and we can avoid to add >> dependencies as well as avoid to use reflection. >> >> https://issues.apache.org/jira/browse/FELIX-5525 >> >> Karl reviewed the change and is generally positive but we would like to get >> feedback from the community if this is a good idea. >> >> Christian >> > > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com >
[jira] [Created] (FELIX-5575) [Framework] Make Apache Felix ready for the upcoming Java SE 9 module system
Florian Brunner created FELIX-5575: -- Summary: [Framework] Make Apache Felix ready for the upcoming Java SE 9 module system Key: FELIX-5575 URL: https://issues.apache.org/jira/browse/FELIX-5575 Project: Felix Issue Type: Improvement Components: Framework Reporter: Florian Brunner Make Apache Felix ready for the upcoming Java SE 9 module system. According to FELIX-5329 this is not the case yet. The sooner this is out the sooner developers can start to test their OSGi applications against Java SE 9. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
Re: [Discuss] Do we need to support other logging frameworks in felix framework?
I just had an idea that might solve the problem of being flexible about the logger while not using reflection. How about using the LogService interface to provide an adapter to an arbitrary logger? We use the FrameworkFactory config to specify a logger. Either as an object if that is possible or as a class name given by the caller. The logger must implement LogService and can then internally bridge to any logging framework. Using the well known LogService interface would allow to avoid reflection and we also do not need to change the spec. Of course the spec could still be changed to standardize how to specify a logger like this but we could easily already start just in felix. Christian On 24.02.2017 15:32, Christian Schneider wrote: Currently felix framework uses reflection to allow other logging frameworks. It is a quite complicated and still pretty limited approach. As far as I know this is only used for karaf to hook in. So I propose to only allow to choose jul as it is built in and we can avoid to add dependencies as well as avoid to use reflection. https://issues.apache.org/jira/browse/FELIX-5525 Karl reviewed the change and is generally positive but we would like to get feedback from the community if this is a good idea. Christian -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
[jira] [Commented] (FELIX-5329) [Framework] Fix Java 8 packages and add Java 9 packages in default.properties
[ https://issues.apache.org/jira/browse/FELIX-5329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15890440#comment-15890440 ] Xavier Fournet commented on FELIX-5329: --- For thoses who are wondering the same thing, between felix 5.6.1 and 5.6.2, the list for Java 8 now contains the package org.w3c.dom.views. All packages that where in 5.6.1 are still here in 5.6.2. > [Framework] Fix Java 8 packages and add Java 9 packages in default.properties > - > > Key: FELIX-5329 > URL: https://issues.apache.org/jira/browse/FELIX-5329 > Project: Felix > Issue Type: New Feature > Components: Framework >Affects Versions: framework-5.4.0 >Reporter: Richard S. Hall >Assignee: Karl Pauls >Priority: Minor > Fix For: framework-5.6.2 > > Attachments: uses_java8.bnd > > > People are starting to experiment with Java 9, but I don't believe we've > created a Java 9 package definition yet in default.properties so that the > system bundle knows what to export. > I can't remember how we did this previously, but I think we used bnd to > analyze and come up with the packages and their "uses" constraints. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (FELIX-5570) Immediate service component that provides a WeavingHook results in an NPE
[ https://issues.apache.org/jira/browse/FELIX-5570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15890428#comment-15890428 ] Karl Pauls edited comment on FELIX-5570 at 3/1/17 3:56 PM: --- Ok, for now I think I at least made it so that Felix is throwing a CNFE for the second loadClass (see FELIX-5573). If I understand correctly that is what is currently happen in equinox as well. was (Author: karlpauls): Ok, for now I think I add least make it so that Felix is throwing a CNFE for the second loadClass (see FELIX-5573). If I understand correctly that is what is currently happen in equinox as well. > Immediate service component that provides a WeavingHook results in an NPE > - > > Key: FELIX-5570 > URL: https://issues.apache.org/jira/browse/FELIX-5570 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-2.0.8 >Reporter: Thomas Watson > > If you have an immediate service component that provides a WeavingHook > service then an NPE will result. An example service component XML: > > http://www.osgi.org/xmlns/scr/v1.1.0"; > enabled="true" immediate="true" name="Test Patches Weaver"> > > > > > > If you deploy this bundle along with SCR 2.0.8 on Felix Framework 5.6.2 the > following NPE happens: > ERROR: [Test Patches Weaver(0)] Error during instantiation of the > implementation object > java.lang.NullPointerException > at > org.apache.felix.scr.impl.manager.SingleComponentManager.createImplementationObject(SingleComponentManager.java:237) > at > org.apache.felix.scr.impl.manager.SingleComponentManager.createComponent(SingleComponentManager.java:109) > at > org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:906) > at > org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:879) > at > org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:823) > at > org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:347) > at > org.apache.felix.framework.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:247) > at > org.apache.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:350) > at org.apache.felix.framework.Felix.getService(Felix.java:3720) > at > org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.transformClass(BundleWiringImpl.java:2359) > at > org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2052) > at > org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1518) > at > org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:79) > at > org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1958) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1925) > at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978) > at > org.apache.felix.scr.impl.manager.AbstractComponentManager.initDependencyManagers(AbstractComponentManager.java:976) > at > org.apache.felix.scr.impl.manager.AbstractComponentManager.collectDependencies(AbstractComponentManager.java:1003) > at > org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:859) > at > org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:749) > at > org.apache.felix.scr.impl.manager.AbstractComponentManager.enableInternal(AbstractComponentManager.java:675) > at > org.apache.felix.scr.impl.manager.AbstractComponentManager.enable(AbstractComponentManager.java:430) > at > org.apache.felix.scr.impl.manager.ConfigurableComponentHolder.enableComponents(ConfigurableComponentHolder.java:657) > at > org.apache.felix.scr.impl.BundleComponentActivator.initialEnable(BundleComponentActivator.java:341) > at > org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:390) > at org.apache.felix.scr.impl.Activator.access$200(Activator.java:54) > at > org.apache.felix.scr.impl.Activator$ScrExtension.start(Activator.java:265) > at > org.apache.felix.utils.extender.AbstractExtender.createExtension(AbstractExtender.java:254) > at > org.apache.felix.utils.extender.AbstractExtender.modifiedBundle(AbstractExtender.java:227) > at > org.apache.felix.utils.extender.AbstractExtender.addingBundle(AbstractExtender.java:
[jira] [Commented] (FELIX-5570) Immediate service component that provides a WeavingHook results in an NPE
[ https://issues.apache.org/jira/browse/FELIX-5570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15890428#comment-15890428 ] Karl Pauls commented on FELIX-5570: --- Ok, for now I think I add least make it so that Felix is throwing a CNFE for the second loadClass (see FELIX-5573). If I understand correctly that is what is currently happen in equinox as well. > Immediate service component that provides a WeavingHook results in an NPE > - > > Key: FELIX-5570 > URL: https://issues.apache.org/jira/browse/FELIX-5570 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-2.0.8 >Reporter: Thomas Watson > > If you have an immediate service component that provides a WeavingHook > service then an NPE will result. An example service component XML: > > http://www.osgi.org/xmlns/scr/v1.1.0"; > enabled="true" immediate="true" name="Test Patches Weaver"> > > > > > > If you deploy this bundle along with SCR 2.0.8 on Felix Framework 5.6.2 the > following NPE happens: > ERROR: [Test Patches Weaver(0)] Error during instantiation of the > implementation object > java.lang.NullPointerException > at > org.apache.felix.scr.impl.manager.SingleComponentManager.createImplementationObject(SingleComponentManager.java:237) > at > org.apache.felix.scr.impl.manager.SingleComponentManager.createComponent(SingleComponentManager.java:109) > at > org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:906) > at > org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:879) > at > org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:823) > at > org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:347) > at > org.apache.felix.framework.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:247) > at > org.apache.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:350) > at org.apache.felix.framework.Felix.getService(Felix.java:3720) > at > org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.transformClass(BundleWiringImpl.java:2359) > at > org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2052) > at > org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1518) > at > org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:79) > at > org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1958) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1925) > at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978) > at > org.apache.felix.scr.impl.manager.AbstractComponentManager.initDependencyManagers(AbstractComponentManager.java:976) > at > org.apache.felix.scr.impl.manager.AbstractComponentManager.collectDependencies(AbstractComponentManager.java:1003) > at > org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:859) > at > org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:749) > at > org.apache.felix.scr.impl.manager.AbstractComponentManager.enableInternal(AbstractComponentManager.java:675) > at > org.apache.felix.scr.impl.manager.AbstractComponentManager.enable(AbstractComponentManager.java:430) > at > org.apache.felix.scr.impl.manager.ConfigurableComponentHolder.enableComponents(ConfigurableComponentHolder.java:657) > at > org.apache.felix.scr.impl.BundleComponentActivator.initialEnable(BundleComponentActivator.java:341) > at > org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:390) > at org.apache.felix.scr.impl.Activator.access$200(Activator.java:54) > at > org.apache.felix.scr.impl.Activator$ScrExtension.start(Activator.java:265) > at > org.apache.felix.utils.extender.AbstractExtender.createExtension(AbstractExtender.java:254) > at > org.apache.felix.utils.extender.AbstractExtender.modifiedBundle(AbstractExtender.java:227) > at > org.apache.felix.utils.extender.AbstractExtender.addingBundle(AbstractExtender.java:187) > at > org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:469) > at > org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:415) > at > org.osgi.util.tracker.AbstractTracked.trackAdding(Abst
[jira] [Comment Edited] (FELIX-5573) Don't return null but throw a CNFE from BundleClassloader.loadclass and Bundle.loadClass on recursive class loads.
[ https://issues.apache.org/jira/browse/FELIX-5573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15890414#comment-15890414 ] Karl Pauls edited comment on FELIX-5573 at 3/1/17 3:54 PM: --- I committed a test that reproduces the issue and a fix in r1784979. was (Author: karlpauls): I committed a test that reproduces the issue and a fix in 1784979. > Don't return null but throw a CNFE from BundleClassloader.loadclass and > Bundle.loadClass on recursive class loads. > -- > > Key: FELIX-5573 > URL: https://issues.apache.org/jira/browse/FELIX-5573 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-5.6.2 >Reporter: Karl Pauls >Assignee: Karl Pauls > Fix For: framework-5.6.4 > > > We need to detect recursive class loads while invoking weaving hooks, if > recursion is detected for a class name then we want to simply ignore all > weave hooks for the recursive class load and allow it to proceed to define > class. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (FELIX-5573) Don't return null but throw a CNFE from BundleClassloader.loadclass and Bundle.loadClass on recursive class loads.
[ https://issues.apache.org/jira/browse/FELIX-5573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls resolved FELIX-5573. --- Resolution: Fixed I committed a test that reproduces the issue and a fix in 1784979. > Don't return null but throw a CNFE from BundleClassloader.loadclass and > Bundle.loadClass on recursive class loads. > -- > > Key: FELIX-5573 > URL: https://issues.apache.org/jira/browse/FELIX-5573 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-5.6.2 >Reporter: Karl Pauls >Assignee: Karl Pauls > Fix For: framework-5.6.4 > > > We need to detect recursive class loads while invoking weaving hooks, if > recursion is detected for a class name then we want to simply ignore all > weave hooks for the recursive class load and allow it to proceed to define > class. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] felix pull request #95: FELIX-5574 change Windows default os name from win t...
GitHub user xfournet opened a pull request: https://github.com/apache/felix/pull/95 FELIX-5574 change Windows default os name from win to win32 You can merge this pull request into a Git repository by running: $ git pull https://github.com/xfournet/felix FELIX-5574 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/felix/pull/95.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #95 commit fe9bfcbdb7c01980a2949051b67d412f0ce4fb6a Author: xfournet Date: 2017-03-01T15:37:36Z FELIX-5574 Windows default os name from win to win32 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (FELIX-5574) When detecting an unknow Windows OS name, provides a suitable default value for org.osgi.framework.os.name
[ https://issues.apache.org/jira/browse/FELIX-5574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15890403#comment-15890403 ] ASF GitHub Bot commented on FELIX-5574: --- GitHub user xfournet opened a pull request: https://github.com/apache/felix/pull/95 FELIX-5574 change Windows default os name from win to win32 You can merge this pull request into a Git repository by running: $ git pull https://github.com/xfournet/felix FELIX-5574 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/felix/pull/95.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #95 commit fe9bfcbdb7c01980a2949051b67d412f0ce4fb6a Author: xfournet Date: 2017-03-01T15:37:36Z FELIX-5574 Windows default os name from win to win32 > When detecting an unknow Windows OS name, provides a suitable default value > for org.osgi.framework.os.name > -- > > Key: FELIX-5574 > URL: https://issues.apache.org/jira/browse/FELIX-5574 > Project: Felix > Issue Type: Improvement > Components: Framework >Reporter: Xavier Fournet >Priority: Minor > Fix For: framework-5.6.4 > > > When the system property os.name return a Windows OS name that is not > recognized by > org.apache.felix.framework.util.manifestparser.NativeLibraryClause#normalizeOSName > then it return "win" as a fallback value. > However this "win" value is not something valid for the > org.osgi.framework.os.name property name (cf > https://www.osgi.org/developer/specifications/reference/) > Changing the fallback value to "win32" would be better so it would allow most > of the JNI library to be loaded. > This would allow smooth support of future windows platform, for example for > Windows Server 2016 with JDK9 (or JDK8 when > https://bugs.openjdk.java.net/browse/JDK-8159948 will be fix on it) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (FELIX-5573) Don't return null but throw a CNFE from BundleClassloader.loadclass and Bundle.loadClass on recursive class loads.
[ https://issues.apache.org/jira/browse/FELIX-5573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls updated FELIX-5573: -- Summary: Don't return null but throw a CNFE from BundleClassloader.loadclass and Bundle.loadClass on recursive class loads. (was: Detect recursive class loads while invoking weaving hooks) > Don't return null but throw a CNFE from BundleClassloader.loadclass and > Bundle.loadClass on recursive class loads. > -- > > Key: FELIX-5573 > URL: https://issues.apache.org/jira/browse/FELIX-5573 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-5.6.2 >Reporter: Karl Pauls >Assignee: Karl Pauls > Fix For: framework-5.6.4 > > > We need to detect recursive class loads while invoking weaving hooks, if > recursion is detected for a class name then we want to simply ignore all > weave hooks for the recursive class load and allow it to proceed to define > class. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (FELIX-5573) Detect recursive class loads while invoking weaving hooks
[ https://issues.apache.org/jira/browse/FELIX-5573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15890395#comment-15890395 ] Karl Pauls commented on FELIX-5573: --- Ok, I can confirm that we do return null in this case. I created a test case that reproduces the issue. Luckily, the immediate fix seems easy. Basically, all we are missing is a check in BundleClassloader.loadClass for the class to be null and throw a CNFE in that case. This is consistent with both, bundle.loadClass and (more importantly) Classloader.loadClass API (I don't think any of the two really allow to return a null). Regarding FELIX-5570, I think it will now work as [~djencks] describes it above i.e., the attempt to get the WeavingHook from the service factory will cause a CNFE inside the service factory which will make it return null (or maybe an exception) which in turn, makes us ignore the weaving hook for this classload. It sounds like this should get us on par with equinox for the moment. Granted, I think [~tjwatson] raised another question in FELIX-5570 namely, whether it would be possible to detect that the cycle was due to this special situation and resolve it without throwing any exception but I think that discussion can continue somewhere else. I'm going to rename this issue to reflect that it is about not return null in a cycle but rather throw an CNFE. > Detect recursive class loads while invoking weaving hooks > - > > Key: FELIX-5573 > URL: https://issues.apache.org/jira/browse/FELIX-5573 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-5.6.2 >Reporter: Karl Pauls >Assignee: Karl Pauls > Fix For: framework-5.6.4 > > > We need to detect recursive class loads while invoking weaving hooks, if > recursion is detected for a class name then we want to simply ignore all > weave hooks for the recursive class load and allow it to proceed to define > class. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (FELIX-5574) When detecting an unknow Windows OS name, provides a suitable default value for org.osgi.framework.os.name
Xavier Fournet created FELIX-5574: - Summary: When detecting an unknow Windows OS name, provides a suitable default value for org.osgi.framework.os.name Key: FELIX-5574 URL: https://issues.apache.org/jira/browse/FELIX-5574 Project: Felix Issue Type: Improvement Components: Framework Reporter: Xavier Fournet Priority: Minor Fix For: framework-5.6.4 When the system property os.name return a Windows OS name that is not recognized by org.apache.felix.framework.util.manifestparser.NativeLibraryClause#normalizeOSName then it return "win" as a fallback value. However this "win" value is not something valid for the org.osgi.framework.os.name property name (cf https://www.osgi.org/developer/specifications/reference/) Changing the fallback value to "win32" would be better so it would allow most of the JNI library to be loaded. This would allow smooth support of future windows platform, for example for Windows Server 2016 with JDK9 (or JDK8 when https://bugs.openjdk.java.net/browse/JDK-8159948 will be fix on it) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
Comments on your last board report
Hi Felix PMC, I'm relaying comments from the board on your last report from December, see https://whimsy.apache.org/board/minutes/Felix.html There were comments about your report being too terse in terms of community health - the report shows that there's good activity in terms of releases but is a bit minimalistic when it comes to "summing up the status and health of your project and the community in a few sentences" as described at https://www.apache.org/foundation/board/reporting Please take this into account when you prepare your next report - thanks! -Bertrand, for the ASF Board of Directors
[jira] [Commented] (FELIX-5573) Detect recursive class loads while invoking weaving hooks
[ https://issues.apache.org/jira/browse/FELIX-5573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15889820#comment-15889820 ] Karl Pauls commented on FELIX-5573: --- Right, throwing some kind of CNFE might be one solution to it but first things first - right now, we don't expect to return null in the first place. This is a special case that makes that happen but we "explicitly" assume it will not. The relevant comment is: // If a cycle is detected, we should return null to break the // cycle. This should only ever be return to internal class // loading code and not to the actual instigator of the class load. It sounds like this assumption doesn't hold in the case of a class load of a class that requires to be woven "by itself". In other words, we use null as a result to signal to _internal_ code that this was a cycle and needs to be dealt with accordingly. In this case our _internal_ code doesn't deal with it (or so it appears) and if that is true it needs to be addressed so that it does. That is when the question of how comes up. Whether the fix is to throw an exception or to ignore the cycle in this case and allow the class load to succeed unwoven we have to see. Regardless, it should be because we understand that this is going on and not an accident. > Detect recursive class loads while invoking weaving hooks > - > > Key: FELIX-5573 > URL: https://issues.apache.org/jira/browse/FELIX-5573 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-5.6.2 >Reporter: Karl Pauls >Assignee: Karl Pauls > Fix For: framework-5.6.4 > > > We need to detect recursive class loads while invoking weaving hooks, if > recursion is detected for a class name then we want to simply ignore all > weave hooks for the recursive class load and allow it to proceed to define > class. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (FELIX-5573) Detect recursive class loads while invoking weaving hooks
[ https://issues.apache.org/jira/browse/FELIX-5573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15889790#comment-15889790 ] Felix Meschberger commented on FELIX-5573: -- My understanding is like David's: I think Bundle.loadClass should not return null as this sounds unexpected, although the specification is not entirely clear. So I would sort this under the topic "managing expectations". How about throwing a new "ClassLoadingCircularityDetectedException extends ClassNotFoundException" ? This way callers get the "ClassNotFoundException" while internally you can differentiate between the cases. Plus logging the exception will properly indicate the actual problem: the circularity. > Detect recursive class loads while invoking weaving hooks > - > > Key: FELIX-5573 > URL: https://issues.apache.org/jira/browse/FELIX-5573 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-5.6.2 >Reporter: Karl Pauls >Assignee: Karl Pauls > Fix For: framework-5.6.4 > > > We need to detect recursive class loads while invoking weaving hooks, if > recursion is detected for a class name then we want to simply ignore all > weave hooks for the recursive class load and allow it to proceed to define > class. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (FELIX-5573) Detect recursive class loads while invoking weaving hooks
[ https://issues.apache.org/jira/browse/FELIX-5573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15889751#comment-15889751 ] Karl Pauls commented on FELIX-5573: --- I agree, it might turn out to not be a bug but I want to investigate the situation as we clearly didn't expect that it would happen due to outside conditions. I might be wrong but as far as I understood the situation we are talking about two different null values - the one for getService and the one for getting the class. I'm interested in the latter - hence, this issue which may or may not be relevant for FELIX-5570. It so happens that it is triggered by the use-case in there but it might need to be (or not to be) addressed regardless. I'll try to look into it soon and report back here. > Detect recursive class loads while invoking weaving hooks > - > > Key: FELIX-5573 > URL: https://issues.apache.org/jira/browse/FELIX-5573 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-5.6.2 >Reporter: Karl Pauls >Assignee: Karl Pauls > Fix For: framework-5.6.4 > > > We need to detect recursive class loads while invoking weaving hooks, if > recursion is detected for a class name then we want to simply ignore all > weave hooks for the recursive class load and allow it to proceed to define > class. -- This message was sent by Atlassian JIRA (v6.3.15#6346)