Re: [Discuss] Do we need to support other logging frameworks in felix framework?

[David Jencks]

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 (JIRA)]

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?

[Christian Schneider]

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

[Xavier Fournet (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-5329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Karl Pauls (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-5570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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:187)
>   at 

[jira] [Commented] (FELIX-5570) Immediate service component that provides a WeavingHook results in an NPE

[Karl Pauls (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-5570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 
> 

[jira] [Comment Edited] (FELIX-5573) Don't return null but throw a CNFE from BundleClassloader.loadclass and Bundle.loadClass on recursive class loads.

[Karl Pauls (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-5573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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.

[Karl Pauls (JIRA)]

 [ 
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...

[xfournet]

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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-5574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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.

[Karl Pauls (JIRA)]

 [ 
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

[Karl Pauls (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-5573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 (JIRA)]

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

[Bertrand Delacretaz]

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

[Karl Pauls (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-5573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Felix Meschberger (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-5573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Karl Pauls (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-5573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)