from:"Richard S. Hall $JIRA$"

[jira] [Commented] (FELIX-5935) Can't install features with dependencies to sources manifest-version 1

2018-09-21 Thread Richard S. Hall (JIRA)



[ 
https://issues.apache.org/jira/browse/FELIX-5935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16623744#comment-16623744
 ] 

Richard S. Hall commented on FELIX-5935:


To be clear, there never was any such thing as "Bundle-ManifestVersion: 1". 
This header was added purely as a way to detect R4 bundles. As such, it didn't 
make sense to introduce a value for prior versions because bundles prior to R4 
would not have this header in the first place.

> Can't install features with dependencies to sources manifest-version 1
> --
>
> Key: FELIX-5935
> URL: https://issues.apache.org/jira/browse/FELIX-5935
> Project: Felix
>  Issue Type: Bug
>  Components: Framework, Utils
>Affects Versions: utils-1.10.4
> Environment: karaf 4.2.1
> using apache felix framework 5.6.10
> and utils version 1.11.0
>Reporter: Zernikel Stefan
>Assignee: Karl Pauls
>Priority: Critical
>
> If I try to install features with Karaf depending on sources with manifest 
> version 1, I get the following exception:
>  
> {code:java}
> org.osgi.framework.BundleException: Unable to build resource for 
> mvn:: Unsupported 'Bundle-ManifestVersion' value: 1
> at 
> org.apache.felix.utils.resource.ResourceBuilder.build(ResourceBuilder.java:82)
> at 
> org.apache.felix.utils.resource.ResourceBuilder.build(ResourceBuilder.java:67)
> at 
> org.apache.karaf.features.internal.region.SubsystemResolver.prepare(SubsystemResolver.java:180)
> at 
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:379)
> at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1025)
> at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(FeaturesServiceImpl.java:964)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.osgi.framework.BundleException: Unsupported 
> 'Bundle-ManifestVersion' value: 1
>  at 
> org.apache.felix.utils.resource.ResourceBuilder.doBuild(ResourceBuilder.java:90)
>  at 
> org.apache.felix.utils.resource.ResourceBuilder.build(ResourceBuilder.java:80)
>  ... 9 more
> Error executing command: Unable to build resource for mvn:: 
> Unsupported 'Bundle-ManifestVersion' value: 1
> {code}
>  
>  
> The source of the problem is about here I guess:
>  
> {code:java}
> //Verify that only manifest version 2 is specified.
> String manifestVersion = getManifestVersion(headerMap);
> if (manifestVersion == null || !manifestVersion.equals("2")) {
> throw new BundleException("Unsupported 'Bundle-ManifestVersion' value: " 
> + manifestVersion);
> }{code}
>  
> Does Felix not support manifest version 1 any longer?
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FELIX-5782) allow resolver errors to be introspected

2018-02-23 Thread Richard S. Hall (JIRA)


[ 
https://issues.apache.org/jira/browse/FELIX-5782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16374814#comment-16374814
 ] 

Richard S. Hall commented on FELIX-5782:


Looking at this latest patch, it makes it a little more obvious to ask, why we 
are creating lots of different exception classes as opposed to adding a single 
extended exception with a "reason" method?

Especially, if in the future, you thought about adding more diagnostics (not 
that we will want to or should) which would have to be duplicated across all of 
these exceptions.

In general, I try to avoid creating lots of classes.

> allow resolver errors to be introspected
> 
>
> Key: FELIX-5782
> URL: https://issues.apache.org/jira/browse/FELIX-5782
> Project: Felix
>  Issue Type: Improvement
>  Components: Resolver
>Reporter: Raymond Augé
>Assignee: Thomas Watson
>Priority: Minor
>
> The current model for resolver errors does not provide any means of 
> introspecting deeper knowledge that the resolver gained. The information is 
> internal only, which makes user feedback more difficult to produce than 
> necessary.
> I propose to expose the error types by means of an exported package 
> {{org.apache.felix.resolver.error}}. This will allow interested clients to 
> dig more deeply into the reasons for resolution failure in order to provide 
> better feedback to users.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FELIX-5680) Add createResource(URLConnection conn) to DataModelHelperImpl to support URLs that require Authentication

2017-08-23 Thread Richard S. Hall (JIRA)


[ 
https://issues.apache.org/jira/browse/FELIX-5680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16138527#comment-16138527
 ] 

Richard S. Hall commented on FELIX-5680:


Your proposal doesn't sound unreasonable to me; however, I didn't author this 
code, so there could be issues with that approach with which I am not aware.

Perhaps [~gnt] should be the one to comment.

> Add createResource(URLConnection conn) to DataModelHelperImpl to support URLs 
> that require Authentication
> -
>
> Key: FELIX-5680
> URL: https://issues.apache.org/jira/browse/FELIX-5680
> Project: Felix
>  Issue Type: Bug
>  Components: Bundle Repository (OBR)
>Affects Versions: bundlerepository-2.0.10
> Environment: macOS 10.12.6, Felix 5.6.4
>Reporter: Ankit Dangi
> Fix For: bundlerepository-2.0.12
>
>
> Referring to classes: 
> * org.apache.felix.bundlerepository.impl.DataModelHelperImpl.java 
> * org.apache.felix.bundlerepository.impl.FileUtil.java
> Current scenario: The method DataModelHelperImpl.createResource(URL 
> bundleUrl) has an inner method loadEntry(String name) that calls 
> FileUtil.openURL(bundleUrl) on the line 479. FileUtil.openURL(URL bundleURL) 
> is a helper function for FileUtil.openURL(URLConnection conn). 
> Problem: It restricts the use of URL connections that require authorization. 
> As a result, a 401 error occurs for bundleURLs that require 
> HttpHeaders.AUTHORIZATION. Note: It is not the same as setting 
> Proxy-Authorization because Authorization is a different HTTPHeader. 
> Possible Solution: Overload the DataModelHelperImpl.createResource() such 
> that it takes as input a URLConnection object which then calls the 
> FileUtil.openURL(conn). An URLConnection object has method 
> setRequestProperty(key, value) which could then make it possible for 
> DataModelHelperImpl.createResource() to handle diverse scenarios. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (FELIX-5659) Possible bug with Framework#listResources

2017-06-27 Thread Richard S. Hall (JIRA)


[ 
https://issues.apache.org/jira/browse/FELIX-5659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16064973#comment-16064973
 ] 

Richard S. Hall commented on FELIX-5659:


>From javadoc

{quote}Returns the names of resources visible to this bundle wiring's class 
loader. The returned names can be used to access the resources via this bundle 
wiring's class loader.

Only the resource names for resources in bundle wirings will be returned. The 
names of resources visible to a bundle wiring's parent class loader, such as 
the bootstrap class loader, must not be included in the result.

Only established wires will be examined for resources. This method must not 
cause new wires for dynamic imports to be established.{quote}

At a minimum, it would appear that the two cannot always return the same result 
since the OSGi API doesn't search all the way up the class loader hierarchy.

> Possible bug with Framework#listResources
> -
>
> Key: FELIX-5659
> URL: https://issues.apache.org/jira/browse/FELIX-5659
> Project: Felix
>  Issue Type: Bug
>  Components: Framework
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>
> I'm not completely sure what the behavior should be, but it seems to me not 
> very understandable that the following may not return the same thing when 
> used for the system bundle:
> {code}
>systemBundle.adapt(BundleWiring.class).listResources("META-INF/services", 
> "javax.script.ScriptEngineFactory", 2)
> {code}
> and
> {code}
>   
> systemBundle.adapt(BundleWiring.class).getClassLoader().loadResources("META-INF/services/javax.script.ScriptEngineFactory")
> {code}
> On JDK 8, the second call correctly returns the nashorn javascript engine 
> factory, but it can't be found using the first call.
> Anyone knows if this is an expected behavior ?
> Equinox seems to behave the same way fwiw.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (FELIX-5649) Refreshing a fragment causes the framework to be restarted

2017-06-06 Thread Richard S. Hall (JIRA)


[ 
https://issues.apache.org/jira/browse/FELIX-5649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16039481#comment-16039481
 ] 

Richard S. Hall commented on FELIX-5649:


Ok, I see what you are saying. The reasoning behind not letting the ee 
requirement be hosted is not clear to me, although I understand there is no 
need to resolve the ee requirement more than once for hosting, it does no harm 
to do it more than once and doesn't create a special case. But if that is the 
case, then yes it does seem like refreshing should only consider host 
requirements when refreshing fragment dependencies.

> Refreshing a fragment causes the framework to be restarted
> --
>
> Key: FELIX-5649
> URL: https://issues.apache.org/jira/browse/FELIX-5649
> Project: Felix
>  Issue Type: Bug
>Affects Versions: framework-5.6.2
>Reporter: Guillaume Nodet
>
> This is caused because the fragment has 2 wires: one to its host and another 
> one to the system bundle for an osgi.ee requirement.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (FELIX-5649) Refreshing a fragment causes the framework to be restarted

2017-06-06 Thread Richard S. Hall (JIRA)


[ 
https://issues.apache.org/jira/browse/FELIX-5649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16039031#comment-16039031
 ] 

Richard S. Hall commented on FELIX-5649:


Fragments can have multiple wires, but they should only be wires to hosts, they 
shouldn't have any other type of wire, IIRC.

I could be wrong, but I thought a fragment attached to the system bundle does 
cause a framework refresh, though.

> Refreshing a fragment causes the framework to be restarted
> --
>
> Key: FELIX-5649
> URL: https://issues.apache.org/jira/browse/FELIX-5649
> Project: Felix
>  Issue Type: Bug
>Affects Versions: framework-5.6.2
>Reporter: Guillaume Nodet
>
> This is caused because the fragment has 2 wires: one to its host and another 
> one to the system bundle for an osgi.ee requirement.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (FELIX-5573) Detect recursive class loads while invoking weaving hooks

2017-02-28 Thread Richard S. Hall (JIRA)


[ 
https://issues.apache.org/jira/browse/FELIX-5573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15889029#comment-15889029
 ] 

Richard S. Hall commented on FELIX-5573:


Rightly or wrongly, we explicitly chose to return null in this case because we 
were under the assumption that this situation would only occur for internal 
framework operation (i.e., we didn't expect null to be returned to end user 
code). We explicitly check for null being returned and know we can ignore that 
case when we detect a cycle. So, if we just start throwing a CNFE, then we 
might have some difficulty ignoring it or knowing when to ignore it in the 
framework.

> 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-5329) [Framework] Fix Java 8 packages and add Java 9 packages in default.properties

2016-08-19 Thread Richard S. Hall (JIRA)


[ 
https://issues.apache.org/jira/browse/FELIX-5329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15428833#comment-15428833
 ] 

Richard S. Hall commented on FELIX-5329:


I guess this is more complicated for Java 9 since it is "modular" and thus 
there is no rt.jar.

> [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
>Priority: Minor
> Fix For: framework-5.6.0
>
>
> 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.4#6332)

[jira] [Updated] (FELIX-5329) [Framework] Fix Java 8 packages and add Java 9 packages in default.properties

2016-08-19 Thread Richard S. Hall (JIRA)


 [ 
https://issues.apache.org/jira/browse/FELIX-5329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall updated FELIX-5329:
---
Summary: [Framework] Fix Java 8 packages and add Java 9 packages in 
default.properties  (was: [Framework] Add Java 9 package definitions in 
default.properties)

> [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
>Priority: Minor
> Fix For: framework-5.6.0
>
>
> 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.4#6332)

[jira] [Commented] (FELIX-5329) [Framework] Add Java 9 package definitions in default.properties

2016-08-19 Thread Richard S. Hall (JIRA)


[ 
https://issues.apache.org/jira/browse/FELIX-5329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15428784#comment-15428784
 ] 

Richard S. Hall commented on FELIX-5329:


Maybe we should also re-do Java 8 package definitions too, because if I'm 
reading FELIX-3786 correctly, we never really did explicitly do this for Java 
8. If I recall correctly, I just copied over jre-1.7 package definitions to 
jre-1.8.

> [Framework] Add Java 9 package definitions 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
>Priority: Minor
> Fix For: framework-5.6.0
>
>
> 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.4#6332)

[jira] [Created] (FELIX-5329) [Framework] Add Java 9 package definition in default.properties

2016-08-19 Thread Richard S. Hall (JIRA)

Richard S. Hall created FELIX-5329:
--

 Summary: [Framework] Add Java 9 package definition 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
Priority: Minor
 Fix For: framework-5.6.0


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.4#6332)

[jira] [Resolved] (FELIX-5196) Capabilities not matching because of case

2016-04-19 Thread Richard S. Hall (JIRA)


 [ 
https://issues.apache.org/jira/browse/FELIX-5196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall resolved FELIX-5196.

   Resolution: Fixed
 Assignee: Richard S. Hall
Fix Version/s: bundlerepository-2.0.10

I applied the patch, so this fix should be included in the next release. I am 
not sure when that will happen. Please close this issue if satisfied. Thanks.

> Capabilities not matching because of case
> -
>
> Key: FELIX-5196
> URL: https://issues.apache.org/jira/browse/FELIX-5196
> Project: Felix
>  Issue Type: Bug
>  Components: Bundle Repository (OBR)
>Affects Versions: bundlerepository-2.0.6
>Reporter: Stephen Kahmann
>Assignee: Richard S. Hall
> Fix For: bundlerepository-2.0.10
>
>
> RequirementImpl is not matching Capabilities because it is using a filter 
> that ignores case. The Filter lowercases the keys, but this is also not done 
> when trying to match them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-5196) Capabilities not matching because of case

2016-04-18 Thread Richard S. Hall (JIRA)


[ 
https://issues.apache.org/jira/browse/FELIX-5196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15246750#comment-15246750
 ] 

Richard S. Hall commented on FELIX-5196:


I admit that I haven't dug into this too deeply, but that seems reasonable to 
me.

> Capabilities not matching because of case
> -
>
> Key: FELIX-5196
> URL: https://issues.apache.org/jira/browse/FELIX-5196
> Project: Felix
>  Issue Type: Bug
>  Components: Bundle Repository (OBR)
>Affects Versions: bundlerepository-2.0.6
>Reporter: Stephen Kahmann
>
> RequirementImpl is not matching Capabilities because it is using a filter 
> that ignores case. The Filter lowercases the keys, but this is also not done 
> when trying to match them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-5196) Capabilities not matching because of case

2016-04-18 Thread Richard S. Hall (JIRA)


[ 
https://issues.apache.org/jira/browse/FELIX-5196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15246714#comment-15246714
 ] 

Richard S. Hall commented on FELIX-5196:


I think utils already has a MapToDictionary class that won't make a copy.

> Capabilities not matching because of case
> -
>
> Key: FELIX-5196
> URL: https://issues.apache.org/jira/browse/FELIX-5196
> Project: Felix
>  Issue Type: Bug
>  Components: Bundle Repository (OBR)
>Affects Versions: bundlerepository-2.0.6
>Reporter: Stephen Kahmann
>
> RequirementImpl is not matching Capabilities because it is using a filter 
> that ignores case. The Filter lowercases the keys, but this is also not done 
> when trying to match them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-5196) Capabilities not matching because of case

2016-04-18 Thread Richard S. Hall (JIRA)


[ 
https://issues.apache.org/jira/browse/FELIX-5196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15246457#comment-15246457
 ] 

Richard S. Hall commented on FELIX-5196:


Perhaps I'm misunderstanding the issue, but if you want to ignore the case of 
the keys, why not just call m_filter.match() instead of m_filter.matchCase()?

> Capabilities not matching because of case
> -
>
> Key: FELIX-5196
> URL: https://issues.apache.org/jira/browse/FELIX-5196
> Project: Felix
>  Issue Type: Bug
>  Components: Bundle Repository (OBR)
>Affects Versions: bundlerepository-2.0.6
>Reporter: Stephen Kahmann
>
> RequirementImpl is not matching Capabilities because it is using a filter 
> that ignores case. The Filter lowercases the keys, but this is also not done 
> when trying to match them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Deleted] (FELIX-5216) AVG Tech Support Number @@1800-420-5166 AVG Customer support number

2016-03-20 Thread Richard S. Hall (JIRA)


 [ 
https://issues.apache.org/jira/browse/FELIX-5216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall deleted FELIX-5216:
---


> AVG Tech Support Number @@1800-420-5166 AVG Customer support number
> ---
>
> Key: FELIX-5216
> URL: https://issues.apache.org/jira/browse/FELIX-5216
> Project: Felix
>  Issue Type: Task
>Reporter: Robert a Kernel
>
> +1-800-420-5166 avg phone number, avg antivirus technical support phone 
> number avg customer care, +18004205166 avg customer service billing, avg 
> customer services, avg service, what is avg serviceavg antivirus customer 
> support number+1800 420 5166, avg antivirus tech support number+1800 420 
> 5166, support for avg avg phone number, avg customer service phone number, 
> avg contact phone number, +1800.420.5166 avg antivirus phone 
> number+18004205166, avg antivirus customer service phone number, phone number 
> for avg customer service avg software phone number, +18004205166  phone 
> number for avg, avg customer service telephone number avg helpline phone 
> number, avg contact number, avg customer service number, avg customer service 
> phone number us+18004205166, avg customer service phone number usa, avg 
> telephone number, avg phone number usa avg antivirus contact number, avg 
> number, avg contact number usa, avg antivirus helpline number avg helpline 
> number, avg customer number, avg antivirus customer service number, avg 
> contact telephone number, contact number for avg, avg software contact 
> number, ,avg technical support, avg antivirus customer support phone number 
> avg antivirus tech support phone number, avg antivirus tech 
> support+1-800-420-5166 avg phone number, avg antivirus technical support 
> phone number avg customer care, +18004205166 avg customer service billing, 
> avg customer services, avg service, what is avg serviceavg antivirus customer 
> support number+1800 420 5166, avg antivirus tech support number+1800 420 
> 5166, support for avg avg phone number, avg customer service phone number, 
> avg contact phone number, +1800.420.5166 avg antivirus phone 
> number+18004205166, avg antivirus customer service phone number, phone number 
> for avg customer service avg software phone number, +18004205166  phone 
> number for avg, avg customer service telephone number avg helpline phone 
> number, avg contact number, avg customer service number, avg customer service 
> phone number us+18004205166, avg customer service phone number usa, avg 
> telephone number, avg phone number usa avg antivirus contact number, avg 
> number, avg contact number usa, avg antivirus helpline number avg helpline 
> number, avg customer number, avg antivirus customer service number, avg 
> contact telephone number, contact number for avg, avg software contact 
> number, ,avg technical support, avg antivirus customer support phone number 
> avg antivirus tech support phone number, avg antivirus tech 
> support+1-800-420-5166 avg phone number, avg antivirus technical support 
> phone number avg customer care, +18004205166 avg customer service billing, 
> avg customer services, avg service, what is avg serviceavg antivirus customer 
> support number+1800 420 5166, avg antivirus tech support number+1800 420 
> 5166, support for avg avg phone number, avg customer service phone number, 
> avg contact phone number, +1800.420.5166 avg antivirus phone 
> number+18004205166, avg antivirus customer service phone number, phone number 
> for avg customer service avg software phone number, +18004205166  phone 
> number for avg, avg customer service telephone number avg helpline phone 
> number, avg contact number, avg customer service number, avg customer service 
> phone number us+18004205166, avg customer service phone number usa, avg 
> telephone number, avg phone number usa avg antivirus contact number, avg 
> number, avg contact number usa, avg antivirus helpline number avg helpline 
> number, avg customer number, avg antivirus customer service number, avg 
> contact telephone number, contact number for avg, avg software contact 
> number, ,avg technical support, avg antivirus customer support phone number 
> avg antivirus tech support phone number, avg antivirus tech support



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-5215) Deadlocks involving global lock

2016-03-14 Thread Richard S. Hall (JIRA)


[ 
https://issues.apache.org/jira/browse/FELIX-5215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15193750#comment-15193750
 ] 

Richard S. Hall commented on FELIX-5215:


Framework synchronization has been the bane of my existence since 2000...the 
OSGi spec has made life very difficult with requiring synchronous event 
delivery. As a result, I don't think it is completely possible to eliminate the 
possibility of deadlocking. Timeouts are one way of dealing with this reality.

Digging a little deeper, in general, there are two types of operations, those 
involving a single bundle and those involving multiple bundles. The main 
multi-bundle operation is bundle resolution (which can be triggered during a 
single-bundle operation). Related, the main reason why the global lock exists 
is to make sure the state of the framework doesn't change while a multi-bundle 
(i.e., resolve) operation is taking place.

The one thought that I've had over the years was to make the bundle resolution 
process optimistic and non-locking. Effectively, just do the resolve process on 
a copy of the state assuming the framework state won't change. At the end, 
check to see if the state used to calculate the resolution is the same as the 
current framework state; if so, grab the framework state lock and apply it; if 
not, re-resolve with the updated state. Rinse, repeat, as necessary.

I think something like this would go a long way toward improving the situation, 
but even then it won't eliminate the possibility. I think Equinox does 
something similar.

> Deadlocks involving global lock
> ---
>
> Key: FELIX-5215
> URL: https://issues.apache.org/jira/browse/FELIX-5215
> Project: Felix
>  Issue Type: Improvement
>  Components: Framework
>Affects Versions: framework-4.6.1, framework-5.4.0
>Reporter: Julian Sedding
> Attachments: deadlock-01.txt, deadlock-02.txt
>
>
> I have recently analyzed two thread dumps on a framework 4.6.1 with deadlocks 
> involving the {{FelixFrameworkWiring}} thread calling 
> {{Felix.refreshPackages}} and another thread.
> In both cases the {{FelixFrameworkWiring}} thread holds Felix' global lock in 
> {{Felix.refreshPackages}}, the other thread holds a lock in 
> {{HttpServiceImpl}} and {{ServiceRegistry}}, respectively. (Note, both 
> {{HttpServiceImpl}} and {{ServiceRegistry}} had their synchronization removed 
> in trunk, possibly due to similar deadlocks).
> While fixing the other players in the deadlock certainly helps, I was 
> wondering if it would be possible to change the code inside the framework in 
> a way that such deadlocks are no longer possible?
> I believe section 4.7.3 "Synchronization Pitfalls" in the OSGi spec talks 
> about this situation (quoted from v5.0.0):
> {quote}
> Generally, a bundle that calls a listener should not hold any Java monitors. 
> This means that neither the Framework nor the originator of a synchronous 
> event should be in a monitor when a callback is initiated.
> [...]
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-5198) Service should not be available while being unregistered

2016-02-25 Thread Richard S. Hall (JIRA)


[ 
https://issues.apache.org/jira/browse/FELIX-5198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15167396#comment-15167396
 ] 

Richard S. Hall commented on FELIX-5198:


Of course it will trigger it.

The issue was people wanted one last chance to talk to the service before it 
was gone. My position at the time was, "What's the point, the service probably 
isn't working anyway." Their position was, "Well, for my components I know they 
are working."

It is legitimate that there is no chance to say goodbye unless we allow 
retrieval, but whether or not this is useful is totally dependent on the 
service implementation.

I can pretty much guarantee that you will cause some people pain if you do 
this, but I'm not against it.

> Service should not be available while being unregistered
> 
>
> Key: FELIX-5198
> URL: https://issues.apache.org/jira/browse/FELIX-5198
> Project: Felix
>  Issue Type: Bug
>  Components: Framework
>Affects Versions: framework-5.4.0
>Reporter: Carsten Ziegeler
>Assignee: David Bosschaert
> Fix For: framework-5.6.0
>
> Attachments: felix-5198.patch
>
>
> Currently it is possible to get a service while it is  being unregistered - 
> if the service is get during processing of the unregistering event. This is 
> the order of events:
> a) a service (factory) is unregistered in the framework
> b) the UNREGISTERING event is sent before the service is actually 
> unregistered (this is as defined in the spec)
> c) the above event is handled synchronously, reactivating dependent components
> d) during this reactivation, some component looks up the service that is 
> unregistered in a). as this service is still registered and marked as valid, 
> it gets it
> According to ServiceRegistration.unregister the service should not be 
> available anymore while the events are sent



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (FELIX-5198) Service should not be available while being unregistered

2016-02-25 Thread Richard S. Hall (JIRA)


[ 
https://issues.apache.org/jira/browse/FELIX-5198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15167251#comment-15167251
 ] 

Richard S. Hall edited comment on FELIX-5198 at 2/25/16 2:36 PM:
-

I won't say I remember all of the specifics, but there are issues around this. 
I think at one time we did implement it so that a service became unavailable as 
soon as unregistering started, but we received a lot of blow back from people 
who wanted to do something with the service to say goodbye. The compromise we 
came up with was [I think] to only allow people who already had services 
references to be able to get a service, but to not allow any new lookups once 
unregistration started.


was (Author: rickhall):
I won't say I remember all of the specifics, but there are issues around this. 
I think at one time we did implement it so that a service became unavailable as 
soon as unregistering started, but we received a lot of blow back from people 
who wanted to do something with the service to say goodbye. The compromise we 
came up with was [I think] to only allow people who already had services 
references to be able to get a service, but to now allow any new lookups once 
unregistration started.

> Service should not be available while being unregistered
> 
>
> Key: FELIX-5198
> URL: https://issues.apache.org/jira/browse/FELIX-5198
> Project: Felix
>  Issue Type: Bug
>  Components: Framework
>Affects Versions: framework-5.4.0
>Reporter: Carsten Ziegeler
>Assignee: David Bosschaert
> Fix For: framework-5.6.0
>
>
> Currently it is possible to get a service while it is  being unregistered - 
> if the service is get during processing of the unregistering event. This is 
> the order of events:
> a) a service (factory) is unregistered in the framework
> b) the UNREGISTERING event is sent before the service is actually 
> unregistered (this is as defined in the spec)
> c) the above event is handled synchronously, reactivating dependent components
> d) during this reactivation, some component looks up the service that is 
> unregistered in a). as this service is still registered and marked as valid, 
> it gets it
> According to ServiceRegistration.unregister the service should not be 
> available anymore while the events are sent



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-5198) Service should not be available while being unregistered

2016-02-25 Thread Richard S. Hall (JIRA)


[ 
https://issues.apache.org/jira/browse/FELIX-5198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15167251#comment-15167251
 ] 

Richard S. Hall commented on FELIX-5198:


I won't say I remember all of the specifics, but there are issues around this. 
I think at one time we did implement it so that a service became unavailable as 
soon as unregistering started, but we received a lot of blow back from people 
who wanted to do something with the service to say goodbye. The compromise we 
came up with was [I think] to only allow people who already had services 
references to be able to get a service, but to now allow any new lookups once 
unregistration started.

> Service should not be available while being unregistered
> 
>
> Key: FELIX-5198
> URL: https://issues.apache.org/jira/browse/FELIX-5198
> Project: Felix
>  Issue Type: Bug
>  Components: Framework
>Affects Versions: framework-5.4.0
>Reporter: Carsten Ziegeler
>Assignee: David Bosschaert
> Fix For: framework-5.6.0
>
>
> Currently it is possible to get a service while it is  being unregistered - 
> if the service is get during processing of the unregistering event. This is 
> the order of events:
> a) a service (factory) is unregistered in the framework
> b) the UNREGISTERING event is sent before the service is actually 
> unregistered (this is as defined in the spec)
> c) the above event is handled synchronously, reactivating dependent components
> d) during this reactivation, some component looks up the service that is 
> unregistered in a). as this service is still registered and marked as valid, 
> it gets it
> According to ServiceRegistration.unregister the service should not be 
> available anymore while the events are sent



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (FELIX-5189) OBR R5 Capabilities are not Properly being Parsed

2016-02-22 Thread Richard S. Hall (JIRA)


 [ 
https://issues.apache.org/jira/browse/FELIX-5189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall resolved FELIX-5189.

   Resolution: Fixed
 Assignee: Richard S. Hall
Fix Version/s: bundlerepository-2.0.8

Seems reasonable. I've applied your patch, please close if satisfied. I'm 
uncertain when this will be released.

> OBR R5 Capabilities are not Properly being Parsed
> -
>
> Key: FELIX-5189
> URL: https://issues.apache.org/jira/browse/FELIX-5189
> Project: Felix
>  Issue Type: Bug
>  Components: Bundle Repository (OBR)
>Affects Versions: bundlerepository-2.0.6
>Reporter: Stephen Kahmann
>Assignee: Richard S. Hall
> Fix For: bundlerepository-2.0.8
>
>
> Capabilities are not correctly being parsed for the R5 spec. The 
> "osgi.wiring.package" attribute is being compared to "package" which always 
> fails to match.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-5049) Resolver does not choose the revision with the lowest bundle ID

2015-10-06 Thread Richard S. Hall (JIRA)


[ 
https://issues.apache.org/jira/browse/FELIX-5049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14945230#comment-14945230
 ] 

Richard S. Hall commented on FELIX-5049:


Funny, Tom Watson told me that Equinox used to do something like option (1) but 
he had removed it.

I think option (1) creates its own issues, because now you are making it 
difficult for bundles to provide newer versions of packages provided by the 
framework.

The only valid solution might be for bundles to require a service provider 
capability and for that service provider to have a proper "uses" constraint on 
the package it uses.

Another option, but less nice, is to use a resolver hook to do what you want.

> Resolver does not choose the revision with the lowest bundle ID
> ---
>
> Key: FELIX-5049
> URL: https://issues.apache.org/jira/browse/FELIX-5049
> Project: Felix
>  Issue Type: Bug
>  Components: Resolver
>Affects Versions: framework-5.2.0
>Reporter: David Bosschaert
>Assignee: David Bosschaert
> Attachments: felix-5049.diff
>
>
> The Felix Resolver does not pick the exporting bundle with the lowest bundle 
> ID when multiple bundles export the same package. This causes 
> [ARIES-1398|https://issues.apache.org/jira/browse/ARIES-1398]. For steps on 
> how to reproduce see that issue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-5049) Resolver does not choose the revision with the lowest bundle ID

2015-10-06 Thread Richard S. Hall (JIRA)


[ 
https://issues.apache.org/jira/browse/FELIX-5049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14945110#comment-14945110
 ] 

Richard S. Hall commented on FELIX-5049:


I don't think this is a good idea. I understand what you are trying to achieve, 
but I'm not sure the best way to achieve it. First of all, such a heuristic 
would lead to sorting results that varied over time and could become 
inconsistent dynamically.

Secondly, even if you wanted to ignore the potential inconsistencies, it is 
still not clear the heuristic makes sense, since it only takes into account 
services registered directly by the package provider, but it is possible that 
there is an importer of the package that is providing the service too. This 
makes the heuristic mostly meaningless since it is just stabbing in the dark. 
And, of course, you really wouldn't want to take importers who provide into 
account because that would just exacerbate the first issue.

Unfortunately, there is no good solution to this case, I don't think.

> Resolver does not choose the revision with the lowest bundle ID
> ---
>
> Key: FELIX-5049
> URL: https://issues.apache.org/jira/browse/FELIX-5049
> Project: Felix
>  Issue Type: Bug
>  Components: Resolver
>Affects Versions: framework-5.2.0
>Reporter: David Bosschaert
>Assignee: David Bosschaert
> Attachments: felix-5049.diff
>
>
> The Felix Resolver does not pick the exporting bundle with the lowest bundle 
> ID when multiple bundles export the same package. This causes 
> [ARIES-1398|https://issues.apache.org/jira/browse/ARIES-1398]. For steps on 
> how to reproduce see that issue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (FELIX-5061) Optional resource fragment with requirements that cause class space consistency issues with the host export cause unexpected ResolutionExceptions

2015-10-05 Thread Richard S. Hall (JIRA)


 [ 
https://issues.apache.org/jira/browse/FELIX-5061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall resolved FELIX-5061.

   Resolution: Fixed
 Assignee: Richard S. Hall
Fix Version/s: framework-5.4.0

I applied the patch, please close if satisfied. Thanks.

> Optional resource fragment with requirements that cause class space 
> consistency issues with the host export cause unexpected ResolutionExceptions
> -
>
> Key: FELIX-5061
> URL: https://issues.apache.org/jira/browse/FELIX-5061
> Project: Felix
>  Issue Type: Bug
>  Components: Resolver
>Affects Versions: resolver-1.6.0
>Reporter: Thomas Watson
>Assignee: Richard S. Hall
> Fix For: framework-5.4.0
>
> Attachments: FELIX-5061.patch
>
>
> Not sure if this is actually a bug in version 1.6.0.  I am testing with the 
> latest out of trunk so it could be something after 1.6.0.
> If a fragment contains a requirement that ultimately causes a uses constraint 
> conflict with one of the hosts exported packages then the resolver will end 
> up throwing a ResolutionExceptoin even when the fragment and host are 
> considered to be optional resources by the ResolverContext.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (FELIX-4897) Dynamic package resolution with fragment package exports can lead to invalid wirings

2015-05-21 Thread Richard S. Hall (JIRA)


 [ 
https://issues.apache.org/jira/browse/FELIX-4897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall resolved FELIX-4897.

   Resolution: Fixed
Fix Version/s: resolver-1.4.0

The patch looks simple enough, I've applied. Please close if satisfied, thanks!

 Dynamic package resolution with fragment package exports can lead to invalid 
 wirings
 

 Key: FELIX-4897
 URL: https://issues.apache.org/jira/browse/FELIX-4897
 Project: Felix
  Issue Type: Bug
  Components: Resolver
Affects Versions: resolver-1.0.0
 Environment: All
Reporter: Thomas Watson
 Fix For: resolver-1.4.0

 Attachments: FELIX-4897.patch


 Similar to FELIX-4428 but the behavior is a regression since the fix for 
 FELIX-4656 was released.  The issue is only with dynamic import package 
 resolution.  In this case a new CopyOnWriteList is created by 
 Candidates.add(Requirement, ListCapability) from the method 
 Candidates.populateDynamic(ResolveContext, Resource, Requirement, 
 ListCapability) but the original ListCapability list may be modified in 
 the next call to Candidates.processCandidates(ResolveContext, Resource, 
 ListCapability)
 The issue is that processCandidates is responsible for inserting hosted 
 capabilities into the candidates List.  Previously to the fix for FELIX-4656 
 the passed in List was used as is so modifying it later would effect the list 
 stored in the Candidates data structure also.  This is no longer the case.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (FELIX-4656) Improve memory usage and speed of the resolver

2015-04-17 Thread Richard S. Hall (JIRA)

[
https://issues.apache.org/jira/browse/FELIX-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500054#comment-14500054
]

Richard S. Hall edited comment on FELIX-4656 at 4/17/15 3:36 PM:
-

Tom's patch is pretty simple and it does help improve understanding of the
code, so I say apply it and release it.

was (Author: rickhall):
Tom's patch is pretty simple and it does help improve understanding of the
code, so I saw apply it and release it.

Improve memory usage and speed of the resolver
--

Key: FELIX-4656
URL: https://issues.apache.org/jira/browse/FELIX-4656
Project: Felix
Issue Type: Improvement
Components: Resolver
Reporter: Guillaume Nodet
Assignee: Guillaume Nodet
Fix For: resolver-1.2.0

Attachments: FELIX-4656.patch

During big resolutions ( 100 bundles), the memory consumption can become
very huge, mostly by keeping a lot of copies of the Candidates object.
I want to lower the memory requirements of the resolver without touching the
algorithm at all (which would be a different improvement).
This can be done by using :
* lower memory intensive collections
* do smart copies of those collections (where they would only actually copy
the data when modify)
The second item is slightly more difficult to achieve, as the maps in the
Candidate objects contains Set and List, which would mean that those must be
copied too. So it could actually be complementary, if achievable.
For the first one, the HashMap and HashSet are very memory intensive. I'll
introduce two new collections which will lower the requirements.

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-4656) Improve memory usage and speed of the resolver

2015-04-17 Thread Richard S. Hall (JIRA)

[
https://issues.apache.org/jira/browse/FELIX-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500054#comment-14500054
]

Richard S. Hall commented on FELIX-4656:

Tom's patch is pretty simple and it does help improve understanding of the
code, so I saw apply it and release it.

Improve memory usage and speed of the resolver
--

Attachments: FELIX-4656.patch

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-4854) Unable to create consistent wiring when same package is exported in same version by multiple bundles

2015-04-16 Thread Richard S. Hall (JIRA)


[ 
https://issues.apache.org/jira/browse/FELIX-4854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14498002#comment-14498002
 ] 

Richard S. Hall commented on FELIX-4854:


I would guess it is due to the fact that Equinox uses a big bang approach to 
resolving bundles where it resolves all unresolved bundles every time it 
resolves any, while the Felix framework uses an incremental approach where it 
only resolves the bundles necessary to satisfy the required dependencies (e.g., 
of a bundle that is being started or from which a class is being loaded). This 
can definitely lead to different wiring results and is within the spec.

You might be able to test this out if in Gogo you try to resolve all of your 
bundles at once, e.g., resolve 1 2 3 4 5...I am pretty sure that causes more 
recent Felix frameworks to resolve them in a single pass (old frameworks [ 
4.0.0] still did it incrementally in this case).

If that's not the issue, then I'm not sure off the top of my head.

 Unable to create consistent wiring when same package is exported in same 
 version by multiple bundles
 

 Key: FELIX-4854
 URL: https://issues.apache.org/jira/browse/FELIX-4854
 Project: Felix
  Issue Type: Bug
  Components: Framework
Affects Versions: framework-4.6.1
Reporter: Jens Offenbach
Priority: Critical
  Labels: framework, resolution, wiring
 Fix For: framework-4.8.0

 Attachments: FELIX-4854.zip


 I am confronted with a strange wiring problem in Felix. Actually I am not 
 sure if this is a problem in the Felix or Equinox framework. The attached 
 test case shows that there is a differen behaviour in the wiring process 
 between Felix 4.6.1 and Equinox 3.10.2.v20150203-1939 when we have different 
 bundles with different versions exporting the same package in the same 
 version: 
 The OSGi specification says:
 The following list defines the preferences, if multiple choices are possible, 
 in order of decreasing priority:
 • A resolved exporter must be preferred over an unresolved exporter.
 • An exporter with a higher version is preferred over an exporter with a 
 lower version.
 • An exporter with a lower bundle ID is preferred over a bundle with a higher 
 ID.
 Let us assume that we have BundleA:1.0.0 and BundleB:2.0.0 both exporting the 
 same package in the same version and we have SampleA and SampleB importing 
 the package. BundleA gets installed and started, then SampleA. I think 
 SampleA gets wired to BundleA:1.0.0. Now BundleB:2.0.0 gets installed and 
 started, followed by SampleB. To which bundle must SampleB be wired? Strict 
 to the OSGi specification, I would say to BundleB:2.0.0, because it has a 
 higher version than BundleA because BundleA and BundleB are both resolved. 
 But does it make sense? I think BundleA:1.0.0 should be preferred because it 
 is already an active part of the resolution process, but I cannot find 
 anything in the specification.
 Can someone please explain me, what is going on in the attached use case. Why 
 do we get a different wiring result in Felix 4.6.1 and Equinox 
 3.10.2.v20150203-1939.
 The attached demo use case can be executed via:
 {code}
 mvn clean install -Pfelix
 mvn clean install -Pequinox
 {code}
 Felix 4.6.1:
 {code}
 testWiringA()
 org.apache.felix.osgi.r6.wiring.sampleA uses 
 org.apache.felix.osgi.r6.wiring.bundleA:1.0.0
 org.apache.felix.osgi.r6.wiring.sampleB uses 
 org.apache.felix.osgi.r6.wiring.bundleB:2.0.0
 testWiringB()
 org.apache.felix.osgi.r6.wiring.sampleA uses 
 org.apache.felix.osgi.r6.wiring.bundleA:1.0.0
 org.apache.felix.osgi.r6.wiring.sampleB uses 
 org.apache.felix.osgi.r6.wiring.bundleA:1.0.0
 {code}
 Equinox 3.10.2.v20150203-1939:
 {code}
 testWiringA()
 org.apache.felix.osgi.r6.wiring.sampleA uses 
 org.apache.felix.osgi.r6.wiring.bundleB:2.0.0
 org.apache.felix.osgi.r6.wiring.sampleB uses 
 org.apache.felix.osgi.r6.wiring.bundleB:2.0.0
 testWiringB()
 org.apache.felix.osgi.r6.wiring.sampleA uses 
 org.apache.felix.osgi.r6.wiring.bundleA:1.0.0
 org.apache.felix.osgi.r6.wiring.sampleB uses 
 org.apache.felix.osgi.r6.wiring.bundleA:1.0.0
 {code}
 The use case is derived from a bigger one resulting in a problematic wiring 
 when the OSGi Compendium is installed in version 4.3.1 and version 5.0.0 in 
 combination with Felix SCR 1.8.2. In my productive scenario, Felix 4.6.1 
 wires my bundles to OSGi Compendium:4.3.1 and Felix SCR to OSGi 
 Compendium:5.0.0. In this case Felix SCR gets into trouble during 
 introspection, because (based on that wiring) SCR cannot find the activate 
 method when it has the ComponentContext class in its signature. Both 
 ComponentContext classes are not equal, because they are provided by 
 different classloaders.

[jira] [Commented] (FELIX-4854) Unable to create consistent wiring when same package is exported in same version by multiple bundles

2015-04-16 Thread Richard S. Hall (JIRA)

[
https://issues.apache.org/jira/browse/FELIX-4854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14498003#comment-14498003
]

Richard S. Hall commented on FELIX-4854:

One other thing, not that this is or isn't part of your difficulty, but we
recommend pretty much never installing the compendium as a bundle.

Unable to create consistent wiring when same package is exported in same
version by multiple bundles

Key: FELIX-4854
URL: https://issues.apache.org/jira/browse/FELIX-4854
Project: Felix
Issue Type: Bug
Components: Framework
Affects Versions: framework-4.6.1
Reporter: Jens Offenbach
Priority: Critical
Labels: framework, resolution, wiring
Fix For: framework-4.8.0

Attachments: FELIX-4854.zip

I am confronted with a strange wiring problem in Felix. Actually I am not
sure if this is a problem in the Felix or Equinox framework. The attached
test case shows that there is a differen behaviour in the wiring process
between Felix 4.6.1 and Equinox 3.10.2.v20150203-1939 when we have different
bundles with different versions exporting the same package in the same
version:
The OSGi specification says:
The following list defines the preferences, if multiple choices are possible,
in order of decreasing priority:
• A resolved exporter must be preferred over an unresolved exporter.
• An exporter with a higher version is preferred over an exporter with a
lower version.
• An exporter with a lower bundle ID is preferred over a bundle with a higher
ID.
Let us assume that we have BundleA:1.0.0 and BundleB:2.0.0 both exporting the
same package in the same version and we have SampleA and SampleB importing
the package. BundleA gets installed and started, then SampleA. I think
SampleA gets wired to BundleA:1.0.0. Now BundleB:2.0.0 gets installed and
started, followed by SampleB. To which bundle must SampleB be wired? Strict
to the OSGi specification, I would say to BundleB:2.0.0, because it has a
higher version than BundleA because BundleA and BundleB are both resolved.
But does it make sense? I think BundleA:1.0.0 should be preferred because it
is already an active part of the resolution process, but I cannot find
anything in the specification.
Can someone please explain me, what is going on in the attached use case. Why
do we get a different wiring result in Felix 4.6.1 and Equinox
3.10.2.v20150203-1939.
The attached demo use case can be executed via:
{code}
mvn clean install -Pfelix
mvn clean install -Pequinox
{code}
Felix 4.6.1:
{code}
testWiringA()
org.apache.felix.osgi.r6.wiring.sampleA uses
org.apache.felix.osgi.r6.wiring.bundleA:1.0.0
org.apache.felix.osgi.r6.wiring.sampleB uses
org.apache.felix.osgi.r6.wiring.bundleB:2.0.0
testWiringB()
org.apache.felix.osgi.r6.wiring.sampleA uses
org.apache.felix.osgi.r6.wiring.bundleA:1.0.0
org.apache.felix.osgi.r6.wiring.sampleB uses
org.apache.felix.osgi.r6.wiring.bundleA:1.0.0
{code}
Equinox 3.10.2.v20150203-1939:
{code}
testWiringA()
org.apache.felix.osgi.r6.wiring.sampleA uses
org.apache.felix.osgi.r6.wiring.bundleB:2.0.0
org.apache.felix.osgi.r6.wiring.sampleB uses
org.apache.felix.osgi.r6.wiring.bundleB:2.0.0
testWiringB()
org.apache.felix.osgi.r6.wiring.sampleA uses
org.apache.felix.osgi.r6.wiring.bundleA:1.0.0
org.apache.felix.osgi.r6.wiring.sampleB uses
org.apache.felix.osgi.r6.wiring.bundleA:1.0.0
{code}
The use case is derived from a bigger one resulting in a problematic wiring
when the OSGi Compendium is installed in version 4.3.1 and version 5.0.0 in
combination with Felix SCR 1.8.2. In my productive scenario, Felix 4.6.1
wires my bundles to OSGi Compendium:4.3.1 and Felix SCR to OSGi
Compendium:5.0.0. In this case Felix SCR gets into trouble during
introspection, because (based on that wiring) SCR cannot find the activate
method when it has the ComponentContext class in its signature. Both
ComponentContext classes are not equal, because they are provided by
different classloaders.

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-4854) Unable to create consistent wiring when same package is exported in same version by multiple bundles

2015-04-16 Thread Richard S. Hall (JIRA)


[ 
https://issues.apache.org/jira/browse/FELIX-4854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14498224#comment-14498224
 ] 

Richard S. Hall commented on FELIX-4854:


Are you confusing bundle version with package version? A higher bundle version 
doesn't really come into play at least as far as the spec is concerned, it is 
talking about the version of the package, which is the same for both exporters 
in this case. The next tie-breaker is the bundle ID.

 Unable to create consistent wiring when same package is exported in same 
 version by multiple bundles
 

 Key: FELIX-4854
 URL: https://issues.apache.org/jira/browse/FELIX-4854
 Project: Felix
  Issue Type: Bug
  Components: Framework
Affects Versions: framework-4.6.1
Reporter: Jens Offenbach
Priority: Critical
  Labels: framework, resolution, wiring
 Fix For: framework-4.8.0

 Attachments: FELIX-4854.zip


 I am confronted with a strange wiring problem in Felix. Actually I am not 
 sure if this is a problem in the Felix or Equinox framework. The attached 
 test case shows that there is a differen behaviour in the wiring process 
 between Felix 4.6.1 and Equinox 3.10.2.v20150203-1939 when we have different 
 bundles with different versions exporting the same package in the same 
 version: 
 The OSGi specification says:
 The following list defines the preferences, if multiple choices are possible, 
 in order of decreasing priority:
 • A resolved exporter must be preferred over an unresolved exporter.
 • An exporter with a higher version is preferred over an exporter with a 
 lower version.
 • An exporter with a lower bundle ID is preferred over a bundle with a higher 
 ID.
 Let us assume that we have BundleA:1.0.0 and BundleB:2.0.0 both exporting the 
 same package in the same version and we have SampleA and SampleB importing 
 the package. BundleA gets installed and started, then SampleA. I think 
 SampleA gets wired to BundleA:1.0.0. Now BundleB:2.0.0 gets installed and 
 started, followed by SampleB. To which bundle must SampleB be wired? Strict 
 to the OSGi specification, I would say to BundleB:2.0.0, because it has a 
 higher version than BundleA because BundleA and BundleB are both resolved. 
 But does it make sense? I think BundleA:1.0.0 should be preferred because it 
 is already an active part of the resolution process, but I cannot find 
 anything in the specification.
 Can someone please explain me, what is going on in the attached use case. Why 
 do we get a different wiring result in Felix 4.6.1 and Equinox 
 3.10.2.v20150203-1939.
 The attached demo use case can be executed via:
 {code}
 mvn clean install -Pfelix
 mvn clean install -Pequinox
 {code}
 Felix 4.6.1:
 {code}
 testWiringA()
 org.apache.felix.osgi.r6.wiring.sampleA uses 
 org.apache.felix.osgi.r6.wiring.bundleA:1.0.0
 org.apache.felix.osgi.r6.wiring.sampleB uses 
 org.apache.felix.osgi.r6.wiring.bundleB:2.0.0
 testWiringB()
 org.apache.felix.osgi.r6.wiring.sampleA uses 
 org.apache.felix.osgi.r6.wiring.bundleA:1.0.0
 org.apache.felix.osgi.r6.wiring.sampleB uses 
 org.apache.felix.osgi.r6.wiring.bundleA:1.0.0
 {code}
 Equinox 3.10.2.v20150203-1939:
 {code}
 testWiringA()
 org.apache.felix.osgi.r6.wiring.sampleA uses 
 org.apache.felix.osgi.r6.wiring.bundleB:2.0.0
 org.apache.felix.osgi.r6.wiring.sampleB uses 
 org.apache.felix.osgi.r6.wiring.bundleB:2.0.0
 testWiringB()
 org.apache.felix.osgi.r6.wiring.sampleA uses 
 org.apache.felix.osgi.r6.wiring.bundleA:1.0.0
 org.apache.felix.osgi.r6.wiring.sampleB uses 
 org.apache.felix.osgi.r6.wiring.bundleA:1.0.0
 {code}
 The use case is derived from a bigger one resulting in a problematic wiring 
 when the OSGi Compendium is installed in version 4.3.1 and version 5.0.0 in 
 combination with Felix SCR 1.8.2. In my productive scenario, Felix 4.6.1 
 wires my bundles to OSGi Compendium:4.3.1 and Felix SCR to OSGi 
 Compendium:5.0.0. In this case Felix SCR gets into trouble during 
 introspection, because (based on that wiring) SCR cannot find the activate 
 method when it has the ComponentContext class in its signature. Both 
 ComponentContext classes are not equal, because they are provided by 
 different classloaders.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-4854) Unable to create consistent wiring when same package is exported in same version by multiple bundles

2015-04-16 Thread Richard S. Hall (JIRA)

[
https://issues.apache.org/jira/browse/FELIX-4854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14498077#comment-14498077
]

Richard S. Hall commented on FELIX-4854:

Regarding not using compendium as a bundle, because it is not a cohesive
module, it is just a bunch of semi-unrelated crap thrown into a JAR file
because the spec needed a container into which to put its definitions. The
result is that its dependencies can pull in stuff you don't need and lead to
resolution issues.

Unable to create consistent wiring when same package is exported in same
version by multiple bundles

Attachments: FELIX-4854.zip

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-4848) Split ResolverImpl

2015-04-09 Thread Richard S. Hall (JIRA)


[ 
https://issues.apache.org/jira/browse/FELIX-4848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14487790#comment-14487790
 ] 

Richard S. Hall commented on FELIX-4848:


I am always humored by such rules (e.g., a file shouldn't be over X many lines, 
etc.)...as always, it just depends. I don't see how distributing complex code 
over multiple files makes it any more tractable for someone than having those 
same details in a single file. Just an observation.

 Split ResolverImpl
 --

 Key: FELIX-4848
 URL: https://issues.apache.org/jira/browse/FELIX-4848
 Project: Felix
  Issue Type: Improvement
  Components: Resolver
Affects Versions: resolver-1.0.0
Reporter: Christian Schneider
 Fix For: resolver-1.2.0


 ResolverImpl currently contains about 2300 lines of code. That is way too big 
 for a single class.
 I looked into it and found that the checkDynamicPackageSpaceConsistency and 
 checkPackageSpaceConsistency methods and their dependent methods form a nice 
 subset. I would move that into a class ConsistencyCheck.
 Both would share all of the inner classes of ResolverImpl but nothing else. 
 So I think i would make sense to move these inner classes to separate files.
 These changes should nicely split the classes into 
 ResolverImpl : 1400 lines
 ConsistencyCheck : 600 lines



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-3463) Multiple hosts for a fragment that exports a package causes ArrayIndexOutOfBoundsException

2015-03-24 Thread Richard S. Hall (JIRA)


[ 
https://issues.apache.org/jira/browse/FELIX-3463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14378272#comment-14378272
 ] 

Richard S. Hall commented on FELIX-3463:


This is an issue for the resolver subproject, not for the framework's resolver. 
The resolver subproject is based on the framework's resolver, but it is not the 
same...although there is work underway (and it was always the goal) to move the 
framework to the resolver subproject.

 Multiple hosts for a fragment that exports a package causes 
 ArrayIndexOutOfBoundsException
 --

 Key: FELIX-3463
 URL: https://issues.apache.org/jira/browse/FELIX-3463
 Project: Felix
  Issue Type: Bug
  Components: Resolver
 Environment: All
Reporter: Thomas Watson
Assignee: Richard S. Hall
 Attachments: 3463.txt


 Sample manifests:
 Bundle-ManifestVersion: 2
 Bundle-SymbolicName: h1
 Bundle-Version: 1.0.0
 Export-Package: 
  h1.a; version=1.0,
  h1.b; version=1.0; uses:=h1.a
 Bundle-ManifestVersion: 2
 Bundle-SymbolicName: h1
 Bundle-Version: 1.1.0
 Export-Package: 
  h1.a; version=1.0,
  h1.b; version=1.0; uses:=h1.a
 Bundle-ManifestVersion: 2
 Bundle-SymbolicName: f1
 Bundle-Version: 1.0.0
 Export-Package: 
  f1.a; version=1.0;uses:=h1.a
 Fragment-Host: h1
 Bundle-ManifestVersion: 2
 Bundle-SymbolicName: b3
 Bundle-Version: 1.0.0
 Import-Package: f1.a
 Then attempt to resolve b3.  When inserting the HostedCapabilities an attempt 
 is made to remove the original capability from the fragment.  But it has 
 already been removed when processing the first host.  I think you could do a 
 simple check for -1 before attempting to remove the original capability.
 java.lang.ArrayIndexOutOfBoundsException: -1
   at java.util.ArrayList.remove(ArrayList.java:390)
   at org.apache.felix.resolver.Candidates.prepare(Candidates.java:760)
   at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:125)
   at 
 org.eclipse.osgi.container.ModuleResolver$ResolveProcess.resolve(ModuleResolver.java:378)
   at 
 org.eclipse.osgi.container.ModuleResolver.resolveDelta(ModuleResolver.java:47)
   at 
 org.eclipse.osgi.container.ModuleContainer.resolve(ModuleContainer.java:238)
   at 
 org.eclipse.osgi.tests.TestModuleContainer.testMultiHost(TestModuleContainer.java:66)
   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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
   at 
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
   at 
 org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
   at 
 org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
   at 
 org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
   at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
   at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
   at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
   at 
 org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
   at 
 org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
   at 
 org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
   at 
 org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
   at 
 org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
   at 
 org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-4825) The resolver may return wires to unresolved resources in some cases

2015-03-06 Thread Richard S. Hall (JIRA)


[ 
https://issues.apache.org/jira/browse/FELIX-4825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14350394#comment-14350394
 ] 

Richard S. Hall commented on FELIX-4825:


A few more details describing the issue/situation would be welcome.

 The resolver may return wires to unresolved resources in some cases
 ---

 Key: FELIX-4825
 URL: https://issues.apache.org/jira/browse/FELIX-4825
 Project: Felix
  Issue Type: Bug
  Components: Resolver
Affects Versions: resolver-1.0.0
Reporter: Guillaume Nodet





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (FELIX-4762) OutOfMemoryError (Java Heap Space) when resolving bundles

2015-01-15 Thread Richard S. Hall (JIRA)


 [ 
https://issues.apache.org/jira/browse/FELIX-4762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall resolved FELIX-4762.

Resolution: Fixed
  Assignee: Richard S. Hall

I applied the patch, please close if satisfied. Thanks!

  OutOfMemoryError (Java Heap Space) when resolving bundles 
 ---

 Key: FELIX-4762
 URL: https://issues.apache.org/jira/browse/FELIX-4762
 Project: Felix
  Issue Type: Bug
  Components: Resolver
 Environment: Usage of Felix resolver as part of Eclipse Equinox
Reporter: Matthieu Helleboid
Assignee: Richard S. Hall
Priority: Critical
 Fix For: resolver-1.2.0

 Attachments: avoidMergeDuplicateExportedPackages.patch


 When trying to start Capella (https://polarsys.org/capella/) we encounter 
 OutOfMemoryError (please see the stacktrace below). It seems that there is 
 too many blames objects generated.
 The original bug is https://bugs.eclipse.org/bugs/show_bug.cgi?id=457118
 A quick workaround is proposed here https://git.eclipse.org/r/#/c/39271/
 This workaround helps to avoid OOMError, but the resolution is still very
 slow



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-4697) Error parsing the default gosh_profile.

2015-01-15 Thread Richard S. Hall (JIRA)


[ 
https://issues.apache.org/jira/browse/FELIX-4697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14278981#comment-14278981
 ] 

Richard S. Hall commented on FELIX-4697:


If this can't be fixed in a timely manner, perhaps FELIX-4671 should be rolled 
back and we should re-release?

 Error parsing the default gosh_profile.
 ---

 Key: FELIX-4697
 URL: https://issues.apache.org/jira/browse/FELIX-4697
 Project: Felix
  Issue Type: Bug
  Components: Gogo Runtime
Affects Versions: gogo.runtime-0.14.0
Reporter: J.W. Janssen

 It appears that the implementation of FELIX-4671 has caused an unexpected 
 side-effect in the parsing of the default {{gosh_profile}}. More 
 specifically: the Tokenizer now bails out on the following expression:
 {code}
 addcommand system (((${.context} bundles) 0) loadclass java.lang.System)
 {code}
 The reason for this is that the {{((}} makes the Tokenizer believe that it 
 should keep parsing until {{))}} is found, which isn't the case in the above 
 situation. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-4757) Native Capabilities should allow OS and Processor alias to load from default and config properties

2015-01-08 Thread Richard S. Hall (JIRA)


[ 
https://issues.apache.org/jira/browse/FELIX-4757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14269285#comment-14269285
 ] 

Richard S. Hall commented on FELIX-4757:


The suggested approach is more similar to the approach for handling the 
auto-install/start properties where start-levels can be specified as part of 
the property. I doubt the processing overhead on this would be significant 
given the reasonably small size of strings we are talking about and the fact 
that it happens only on startup when lots of other stuff is going on anyway. 
One other benefit is that if the user wants to override/add an alias in 
config.properties, they can do it in a more targeted way. But, in the end, its 
your effort so I'll leave it up to you.

 Native Capabilities should allow OS and Processor alias to load from default 
 and config properties
 --

 Key: FELIX-4757
 URL: https://issues.apache.org/jira/browse/FELIX-4757
 Project: Felix
  Issue Type: Improvement
  Components: Framework
Reporter: Bob Paulin
Assignee: Bob Paulin
Priority: Minor
 Fix For: framework-4.6.0


 The initial implementation of the native os and processor aliases had them 
 hard coded inside the NativeCodeClause Class.  The aliases should be handled 
 in a properties file outside the code to allow them to be overridden and make 
 them easier to update within the framework.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-4692) Improve Service access time

2015-01-06 Thread Richard S. Hall (JIRA)

[
https://issues.apache.org/jira/browse/FELIX-4692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14266086#comment-14266086
]

Richard S. Hall commented on FELIX-4692:

Very interesting. I think #5 is pretty close to optimal. Other than a couple of
code formatting issues, I'd say go ahead and apply it.

Improve Service access time
---

Key: FELIX-4692
URL: https://issues.apache.org/jira/browse/FELIX-4692
Project: Felix
Issue Type: Improvement
Components: Framework
Affects Versions: framework-4.4.1
Reporter: Felix Meschberger
Assignee: Felix Meschberger
Fix For: framework-4.6.0

Attachments: FELIX-4692-2.patch, FELIX-4692.diff

Currently the ServiceRegistry takes roughly 1ms to access a single service.
In a reasonably large system, this may over time consume considerable time.
For example in our inhouse system sporting roughly 5000 services with 15'000
service accesses during startup, these accesses acount for almost 15 seconds
or roughly 25-30% of the total startup time.
Internally all accesses to services are handled with a Filter even if the
service is simply retrieved with the service name without a filter. This
causes a considerable overhead.
A simple improvement is to keep services not only in a global Capabitliy Set
accessible through generic filters but also keep such a set for each
registered service name.
The measured improvement of this change is substantial: accessing these
15'000 services now only takes roughly 3 seconds or 0.2 ms per service or 5
times faster.

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (FELIX-4692) Improve Service access time

2014-12-19 Thread Richard S. Hall (JIRA)

[
https://issues.apache.org/jira/browse/FELIX-4692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14208081#comment-14208081
]

Richard S. Hall edited comment on FELIX-4692 at 12/19/14 1:43 PM:
--

Did you investigate whether or not there was something that could be modified
in the lookup path to improve performance. If the service lookup is being done
by className and no filter, then I would expect that this would be reasonably
straightforward since internally the ServiceRegistry.getServiceReferences()
method converts this to internal filter format (i.e., no parsing is required)
and then does a CapabilitySet.match() with the filter that should immediately
hit the index for objectClass and return the matching result.

It would be interesting to know where it was spending its time to see if there
was a general fix for the issue. Perhaps there is no general fix and it is just
the mechanics of doing it generically that causes the slow down, but it would
be nice to know more precisely.

was (Author: rickhall):
Did you investigate whether or not there was something that could be modified
in the lookup path to improve performance. If the service lookup is being done
by className and no filter, then I would expect that this would be reasonably
straightforward since internally the ServiceRegistry.getServiceReferences()
method converts this to internal filter format (i.e., no parsing is required)
and then does a CapabilitySet.match() with the filter that should immediately
it the index for objectClass and return the matching result.

Improve Service access time
---

Attachments: FELIX-4692.diff

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-4692) Improve Service access time

2014-12-19 Thread Richard S. Hall (JIRA)

[
https://issues.apache.org/jira/browse/FELIX-4692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14254007#comment-14254007
]

Richard S. Hall commented on FELIX-4692:

Looking at the code of CapabilitySet.match(Set caps, SimpleFilter sf) on line
239 we do matches.retainAll(caps) which in your case caps would be your 10k
services, so I expect that this is where you see the slowdown.

We have to do the retainAll() because it gives us the intersection of matches
from the index and all other capabilities that have been matched by any other
part of the filter up until this point (i.e., since this is recursive due to
expression nesting). However, it is certainly the case that the very first time
through (i.e., at the top level), we don't need to do retainAll() because by
definition caps would already be m_capSet, which is all available capabilities.

So, perhaps the simple optimization is to simply check if (caps == m_capSet)
and if so don't do retain all.

Improve Service access time
---

Attachments: FELIX-4692.diff

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-4692) Improve Service access time

2014-12-18 Thread Richard S. Hall (JIRA)

[
https://issues.apache.org/jira/browse/FELIX-4692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14251844#comment-14251844
]

Richard S. Hall commented on FELIX-4692:

I think it would be easier to answer the question I posed before changing the
control flow to make it more convoluted, but you can do whatever you want. I am
just not a fan of solving issues without first trying to understand what the
heart of the issue is. It may be that there is no other way to improve
performance other than special casing it, but looking at the code it seems like
a pretty straight path, so it would be interesting to know why it goes wrong.

The point being, is that it is a generic indexing mechanism which can index any
property. If we can see that there is some way to speed it up, then we speed it
up for all other use case...this is also used in the resolver, for example.

Improve Service access time
---

Attachments: FELIX-4692.diff

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (FELIX-4727) WrappedResource.getCapabilities ignores the namespace param

2014-12-12 Thread Richard S. Hall (JIRA)


 [ 
https://issues.apache.org/jira/browse/FELIX-4727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall resolved FELIX-4727.

   Resolution: Fixed
Fix Version/s: resolver-1.2.0
 Assignee: Richard S. Hall

I've applied the patch, please close if satisfied. Thanks.

 WrappedResource.getCapabilities ignores the namespace param
 ---

 Key: FELIX-4727
 URL: https://issues.apache.org/jira/browse/FELIX-4727
 Project: Felix
  Issue Type: Bug
  Components: Resolver
 Environment: All
Reporter: Thomas Watson
Assignee: Richard S. Hall
 Fix For: resolver-1.2.0

 Attachments: Felix-4737.patch


 The overall design of org.apache.felix.resolver.WrappedResource is that it is 
 an internal type to the ResolverImpl and is not exposed to external code.  
 The fact that it does not pay attention to the namespace param is an 
 oversite, but not one that effects the ResolverImpl since it uses a null 
 param anyway and does its own filtering of the capabilities.
 But there are cases where this type will get exposed to code outside the 
 resolver implementation.  One example is when ResolverImpl.mergeUses is 
 called and does a ArrayList.contains.  Typically the types in the list are 
 provided by the ResolveContext implementation.  If a WrappedCapability is 
 passed to the ArrayList.contains method then it does an equals call across 
 all values in the list.  If a ResolveContext capability implementation of 
 that equals method calls getResource on  WrappedCapability then it will be 
 exposed to the WrappedResource.  I know of one case where this causes issues 
 when the client code is trying to get the osgi.identity capability of the 
 WrappedResource.  All capabilities are being returned but the first one is 
 not the expected osgi.identity.
 Here is a stacktrace from Aries:
 Caused by: java.lang.NullPointerException
   at 
 org.apache.aries.subsystem.obr.internal.FelixResourceAdapter.equals(FelixResourceAdapter.java:44)
   at java.util.ArrayList.indexOf(ArrayList.java:319)
   at java.util.ArrayList.contains(ArrayList.java:302)
   at 
 org.apache.felix.resolver.ResolverImpl.mergeUses(ResolverImpl.java:955)
   at 
 org.apache.felix.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:767)
   at 
 org.apache.felix.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:715)
   at 
 org.apache.felix.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:715)
   at 
 org.apache.felix.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:715)
   at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:249)
   at 
 org.apache.aries.subsystem.core.internal.SubsystemResource.computeDependencies(SubsystemResource.java:410)
   at 
 org.apache.aries.subsystem.core.internal.SubsystemResource.computeDependencies(SubsystemResource.java:393)
   at 
 org.apache.aries.subsystem.core.internal.SubsystemResource.init(SubsystemResource.java:101)
   at 
 org.apache.aries.subsystem.core.internal.SubsystemResource.init(SubsystemResource.java:92)
   at 
 org.apache.aries.subsystem.core.internal.InstallAction.createSubsystemResource(InstallAction.java:128)
   at 
 org.apache.aries.subsystem.core.internal.InstallAction.run(InstallAction.java:62)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-4701) Properties with surprising spelling in AutoProcessor

2014-11-18 Thread Richard S. Hall (JIRA)


[ 
https://issues.apache.org/jira/browse/FELIX-4701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14216164#comment-14216164
 ] 

Richard S. Hall commented on FELIX-4701:


Pretty funny and sad at the same time.  I guess that's what copy and paste and 
command completion can do to you...makes us lazy. :-)

I assume we will have to mark the old spelling deprecated and introduce the 
correct spelling.

 Properties with surprising spelling in AutoProcessor
 

 Key: FELIX-4701
 URL: https://issues.apache.org/jira/browse/FELIX-4701
 Project: Felix
  Issue Type: Bug
Affects Versions: framework-4.0.3
Reporter: Benson Margulies

 Several fields are missing a T:
 AUTO_DEPLOY_DIR_PROPERY
 e.g.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (FELIX-4701) Properties with surprising spelling in AutoProcessor

2014-11-18 Thread Richard S. Hall (JIRA)


 [ 
https://issues.apache.org/jira/browse/FELIX-4701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall updated FELIX-4701:
---
 Priority: Minor  (was: Major)
Fix Version/s: framework-4.6.0
 Assignee: Richard S. Hall

 Properties with surprising spelling in AutoProcessor
 

 Key: FELIX-4701
 URL: https://issues.apache.org/jira/browse/FELIX-4701
 Project: Felix
  Issue Type: Bug
Affects Versions: framework-4.0.3
Reporter: Benson Margulies
Assignee: Richard S. Hall
Priority: Minor
 Fix For: framework-4.6.0


 Several fields are missing a T:
 AUTO_DEPLOY_DIR_PROPERY
 e.g.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (FELIX-4701) Properties with surprising spelling in AutoProcessor

2014-11-18 Thread Richard S. Hall (JIRA)


 [ 
https://issues.apache.org/jira/browse/FELIX-4701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall resolved FELIX-4701.

Resolution: Fixed

I created properly spelled properties and deprecated the old ones. Please close 
this bug if satisfied. Thanks.

 Properties with surprising spelling in AutoProcessor
 

 Key: FELIX-4701
 URL: https://issues.apache.org/jira/browse/FELIX-4701
 Project: Felix
  Issue Type: Bug
Affects Versions: framework-4.0.3
Reporter: Benson Margulies
Assignee: Richard S. Hall
Priority: Minor
 Fix For: framework-4.6.0


 Several fields are missing a T:
 AUTO_DEPLOY_DIR_PROPERY
 e.g.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-4692) Improve Service access time

2014-11-12 Thread Richard S. Hall (JIRA)

[
https://issues.apache.org/jira/browse/FELIX-4692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14208081#comment-14208081
]

Richard S. Hall commented on FELIX-4692:

Did you investigate whether or not there was something that could be modified
in the lookup path to improve performance. If the service lookup is being done
by className and no filter, then I would expect that this would be reasonably
straightforward since internally the ServiceRegistry.getServiceReferences()
method converts this to internal filter format (i.e., no parsing is required)
and then does a CapabilitySet.match() with the filter that should immediately
it the index for objectClass and return the matching result.

Improve Service access time
---

Attachments: FELIX-4692.diff

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-4503) [Core R6] Support osgi.native capability

2014-10-25 Thread Richard S. Hall (JIRA)


[ 
https://issues.apache.org/jira/browse/FELIX-4503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14184090#comment-14184090
 ] 

Richard S. Hall commented on FELIX-4503:


Yeah, I think you just need to expose the new capabilities.

 [Core R6] Support osgi.native capability
 

 Key: FELIX-4503
 URL: https://issues.apache.org/jira/browse/FELIX-4503
 Project: Felix
  Issue Type: Sub-task
  Components: Framework
Affects Versions: framework-4.4.0
Reporter: David Bosschaert





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-4656) Improve memory usage of the resolver

2014-10-03 Thread Richard S. Hall (JIRA)

[
https://issues.apache.org/jira/browse/FELIX-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14158115#comment-14158115
]

Richard S. Hall commented on FELIX-4656:

From mailing list:

Guillaume Nodet Tue, 30 Sep 2014 01:45:07 -0700

I recently run into OutOfMemory problems when using the resolver in
addition to the slowness I already raised.
I worked a bit on the resolver and pushed my results to a private branch
for review:
https://github.com/gnodet/felix/commits/resolver-improvements

The memory problem was addressed by replacing the internal data structures
hold by the Candidates class.
This class was using a HashMap to store the MapRequirement,
ListCapability for candidates and for each permutation, the whole data
structure was copied.
Unfortunately, the HashMap object is very memory intensive and the
ListCapability were duplicated a lot during resolutions.
Therefore, I introduced a few collections which are optimized for memory
consumption. Those are the OpenHashMap (derived from the mahout
collections) and the CopyOnWriteList/CopyOnWriteSet.
The OpenHashMap uses open adressing and two Object[] internally instead of
tons of entry objects. Copy should also be faster as much less objects are
created. The values in this map are now CopyOnWriteList instead of
ArrayList, which has the big benefit of not duplicating the entire arrays
when the structure is copied. Those two collections work roughly the same
way as CopyOnWriteArrayList but without any thread safety. In addition,
creating a new list from a CopyOnWriteList does not lead to creating a new
Object[] to store the data, but merely assign the same pointer internally.
In terms of memory consumption, this means overall, that copying a
Candidates class, will lead to two Object[] arrays creation (for the
OpenHashMap) and the creation of small objects for the lists (but with no
copy of the data itself).
This is mainly commit
https://github.com/gnodet/felix/commit/0bf1523f21f9983b21b2737b4f78bb8d78cd35fd

The slowness problem was partially addressed because I found out that the
resolver was attempting the same resolution multiple times. I think this
is due to the order or removing possible candidates and multiple paths to
the same resolution were executed. In order to solve this problem, the
Candidates now holds a m_path structure which contains all the removed
candidates. This object is used in the resolver loop to make sure we
haven't already tried the same resolution. For big resolutions, I think it
will improve things a lot.
This is fixed by commit
https://github.com/gnodet/felix/commit/090a67a7fc05170291ad9cff808229a0292b6fb2

I'm going to do further testing, and I'm going to add a big resolution test
to measure performances and memory consumption.
In the mean time, I'd like others to review and test it if possible.

Improve memory usage of the resolver

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-4650) Refactor the BundleRepository to use the Resolver Module

2014-09-19 Thread Richard S. Hall (JIRA)


[ 
https://issues.apache.org/jira/browse/FELIX-4650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14140744#comment-14140744
 ] 

Richard S. Hall commented on FELIX-4650:


There is no reason why it cannot, but it will have to take into account 
different considerations than the framework. For example, its priority system 
will be different since it has to deal with installed vs not-yet-installed 
bundles (the framework only considers installed bundles). Another difference is 
that OBR currently tries to limit the number of versions its deploys, so it 
will attempt to see if an installed bundle is update-able without break 
constraints to avoid deploying multiple versions of the same bundle.

 Refactor the BundleRepository to use the Resolver Module
 

 Key: FELIX-4650
 URL: https://issues.apache.org/jira/browse/FELIX-4650
 Project: Felix
  Issue Type: Improvement
  Components: Bundle Repository (OBR)
Affects Versions: bundlerepository-2.0.2
Reporter: David Bosschaert

 OBR contains its own resolver implementation, but it would be nice if it 
 could use the Felix resolver module. Just like the Framework is being 
 refactored to use the standalone resolver (FELIX-4525), OBR should also use 
 it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-4525) Refactor the Framework to use the Resolver module

2014-09-10 Thread Richard S. Hall (JIRA)


[ 
https://issues.apache.org/jira/browse/FELIX-4525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14128970#comment-14128970
 ] 

Richard S. Hall commented on FELIX-4525:


I looked at this briefly and it looks fairly reasonable. I think you can keep 
going forward with it. Admittedly, I didn't look into it in much depth, so I'll 
try to look at it some more to refresh my memory about the dynamic import stuff.

One nit, you change BundleRevisionImpl.toString() to be a fairly long 
string...I didn't look in depth at where this was being used, but I want to 
think it was being used for diagnostic output, which could make things a little 
verbose if so. We might want to check.

 Refactor the Framework to use the Resolver module
 -

 Key: FELIX-4525
 URL: https://issues.apache.org/jira/browse/FELIX-4525
 Project: Felix
  Issue Type: Task
  Components: Framework
Affects Versions: framework-4.4.0
Reporter: David Bosschaert
Assignee: David Bosschaert
 Fix For: framework-4.6.0


 Currently both the framework has a resolver implementation as well as the 
 resolver module, which has a separate resolver implementation. The resolver 
 module originates from the framework, but they are not the same any more.
 It would be good to refactor the framework to use the resolver implementation 
 from the resolver module so that there is no code duplication any more.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (FELIX-4569) Framework tests fail on fast Windows 8.1 machine

2014-07-23 Thread Richard S. Hall (JIRA)


 [ 
https://issues.apache.org/jira/browse/FELIX-4569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall updated FELIX-4569:
---

Fix Version/s: framework-4.6.0

 Framework tests fail on fast Windows 8.1 machine
 

 Key: FELIX-4569
 URL: https://issues.apache.org/jira/browse/FELIX-4569
 Project: Felix
  Issue Type: Test
  Components: Framework
 Environment: Windows 8.1
Reporter: Rob Walker
Priority: Minor
 Fix For: framework-4.6.0

 Attachments: windows_tests.patch


 The following 2 framework tests fail on a fast Windows 8.1 machine, causing a 
 framework build to fail:
 1 - PackageAdminImplTest
 2 - StartStopBundleTest
 The first seems to be different platform semantics on File.listFiles return
 The second seems to be a case of delay being needed beteen stopping the 
 platform and cleaning up the cache dir.
 A patch is attached with workarounds both, although in the 2nd case a better 
 solution is probably needed than an arbitrary delay e.g. a listener for the 
 stop event event before deleting cache.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (FELIX-4569) Framework tests fail on fast Windows 8.1 machine

2014-07-23 Thread Richard S. Hall (JIRA)


 [ 
https://issues.apache.org/jira/browse/FELIX-4569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall resolved FELIX-4569.


Resolution: Fixed
  Assignee: Richard S. Hall

I applied the patch, please close if satisfied. Thanks!

 Framework tests fail on fast Windows 8.1 machine
 

 Key: FELIX-4569
 URL: https://issues.apache.org/jira/browse/FELIX-4569
 Project: Felix
  Issue Type: Test
  Components: Framework
 Environment: Windows 8.1
Reporter: Rob Walker
Assignee: Richard S. Hall
Priority: Minor
 Fix For: framework-4.6.0

 Attachments: windows_tests.patch


 The following 2 framework tests fail on a fast Windows 8.1 machine, causing a 
 framework build to fail:
 1 - PackageAdminImplTest
 2 - StartStopBundleTest
 The first seems to be different platform semantics on File.listFiles return
 The second seems to be a case of delay being needed beteen stopping the 
 platform and cleaning up the cache dir.
 A patch is attached with workarounds both, although in the 2nd case a better 
 solution is probably needed than an arbitrary delay e.g. a listener for the 
 stop event event before deleting cache.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (FELIX-4525) Refactor the Framework to use the Resolver module

2014-06-30 Thread Richard S. Hall (JIRA)


[ 
https://issues.apache.org/jira/browse/FELIX-4525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14047657#comment-14047657
 ] 

Richard S. Hall commented on FELIX-4525:


The biggest issue I had when I looked at this is I couldn't decide what was the 
best way to organize my generic data structures since the framework needs 
impl-specific classes, but the resolver doesn't. I guess my generics-fu just 
wasn't good enough at the time. Other than that issue, the APIs are pretty 
similar. The only part that doesn't fit is dynamic imports, but I did have an 
idea for that...

 Refactor the Framework to use the Resolver module
 -

 Key: FELIX-4525
 URL: https://issues.apache.org/jira/browse/FELIX-4525
 Project: Felix
  Issue Type: Task
  Components: Framework
Affects Versions: framework-4.4.0
Reporter: David Bosschaert
Assignee: David Bosschaert

 Currently both the framework has a resolver implementation as well as the 
 resolver module, which has a separate resolver implementation. The resolver 
 module originates from the framework, but they are not the same any more.
 It would be good to refactor the framework to use the resolver implementation 
 from the resolver module so that there is no code duplication any more.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (FELIX-4540) Deadlock in BundleWiringImpl$BundleClassLoader.loadClass

2014-06-24 Thread Richard S. Hall (JIRA)


[ 
https://issues.apache.org/jira/browse/FELIX-4540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14042069#comment-14042069
 ] 

Richard S. Hall commented on FELIX-4540:


I know nothing about Karaf, so it might be better to give us information about 
the framework version instead.

Which version of Java are you using?

 Deadlock in BundleWiringImpl$BundleClassLoader.loadClass
 

 Key: FELIX-4540
 URL: https://issues.apache.org/jira/browse/FELIX-4540
 Project: Felix
  Issue Type: Bug
 Environment: Karaf 2.3.4
Reporter: Martin Lichtin

 {noformat}
 Found one Java-level deadlock:
 =
 Pax Web Runtime worker:
   waiting to lock monitor 0x0b0a1438 (object 0xfb585990, a 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5),
   which is held by Thread-15
 Thread-15:
   waiting to lock monitor 0x0b0a1388 (object 0xf7681f70, a 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5),
   which is held by Pax Web Runtime worker
 Java stack information for the threads listed above:
 ===
 Pax Web Runtime worker:
 at 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1836)
 - waiting to lock 0xfb585990 (a 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
 at 
 org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1317)
 at 
 org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1481)
 at 
 org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1427)
 at 
 org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
 at 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
 at 
 org.ops4j.pax.web.service.internal.Activator.updateController(Activator.java:247)
 at 
 org.ops4j.pax.web.service.internal.Activator$DynamicsServiceTrackerCustomizer$1.run(Activator.java:376)
 at 
 org.ops4j.pax.web.service.internal.Executor$Future.run(Executor.java:47)
 at 
 org.ops4j.pax.web.service.internal.Executor$Worker.run(Executor.java:128)
 Thread-15:
 at 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1836)
 - waiting to lock 0xf7681f70 (a 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
 at 
 org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1317)
 at 
 org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1481)
 at 
 org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1427)
 at 
 org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
 at 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
 at java.lang.ClassLoader.defineClass1(Native Method)
 at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
 at 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2128)
 - locked 0xfb585990 (a 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5)
 at 
 org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1432)
 at 
 org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
 at 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
 at 
 org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1317)
 at 
 org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1481)
 at 
 org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1427)
 at 
 org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
 at 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
 at

[jira] [Commented] (FELIX-4540) Deadlock in BundleWiringImpl$BundleClassLoader.loadClass

2014-06-24 Thread Richard S. Hall (JIRA)


[ 
https://issues.apache.org/jira/browse/FELIX-4540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14042101#comment-14042101
 ] 

Richard S. Hall commented on FELIX-4540:


And what about Java version?

 Deadlock in BundleWiringImpl$BundleClassLoader.loadClass
 

 Key: FELIX-4540
 URL: https://issues.apache.org/jira/browse/FELIX-4540
 Project: Felix
  Issue Type: Bug
 Environment: Karaf 2.3.4
Reporter: Martin Lichtin

 {noformat}
 Found one Java-level deadlock:
 =
 Pax Web Runtime worker:
   waiting to lock monitor 0x0b0a1438 (object 0xfb585990, a 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5),
   which is held by Thread-15
 Thread-15:
   waiting to lock monitor 0x0b0a1388 (object 0xf7681f70, a 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5),
   which is held by Pax Web Runtime worker
 Java stack information for the threads listed above:
 ===
 Pax Web Runtime worker:
 at 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1836)
 - waiting to lock 0xfb585990 (a 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
 at 
 org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1317)
 at 
 org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1481)
 at 
 org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1427)
 at 
 org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
 at 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
 at 
 org.ops4j.pax.web.service.internal.Activator.updateController(Activator.java:247)
 at 
 org.ops4j.pax.web.service.internal.Activator$DynamicsServiceTrackerCustomizer$1.run(Activator.java:376)
 at 
 org.ops4j.pax.web.service.internal.Executor$Future.run(Executor.java:47)
 at 
 org.ops4j.pax.web.service.internal.Executor$Worker.run(Executor.java:128)
 Thread-15:
 at 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1836)
 - waiting to lock 0xf7681f70 (a 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
 at 
 org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1317)
 at 
 org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1481)
 at 
 org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1427)
 at 
 org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
 at 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
 at java.lang.ClassLoader.defineClass1(Native Method)
 at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
 at 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2128)
 - locked 0xfb585990 (a 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5)
 at 
 org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1432)
 at 
 org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
 at 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
 at 
 org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1317)
 at 
 org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1481)
 at 
 org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1427)
 at 
 org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
 at 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
 at 
 org.ops4j.pax.web.extender.whiteboard.internal.util.WebContainerUtils.webContainerAvailable(WebContainerUtils.java:46)
 at

[jira] [Commented] (FELIX-4540) Deadlock in BundleWiringImpl$BundleClassLoader.loadClass

2014-06-24 Thread Richard S. Hall (JIRA)


[ 
https://issues.apache.org/jira/browse/FELIX-4540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14042119#comment-14042119
 ] 

Richard S. Hall commented on FELIX-4540:


Just to cut to the chase, I'm guess that this is the standard JVM class loader 
deadlock issue. If you are on Java 7, then you should try upgrading your 
framework version since 4.0.3 does not take advantage of the parallel capable 
class loaders introduced in Java, but more recent framework versions do.

 Deadlock in BundleWiringImpl$BundleClassLoader.loadClass
 

 Key: FELIX-4540
 URL: https://issues.apache.org/jira/browse/FELIX-4540
 Project: Felix
  Issue Type: Bug
 Environment: java version 1.7.0_55
 Karaf 2.3.4, Felix 4.0.3
Reporter: Martin Lichtin

 {noformat}
 Found one Java-level deadlock:
 =
 Pax Web Runtime worker:
   waiting to lock monitor 0x0b0a1438 (object 0xfb585990, a 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5),
   which is held by Thread-15
 Thread-15:
   waiting to lock monitor 0x0b0a1388 (object 0xf7681f70, a 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5),
   which is held by Pax Web Runtime worker
 Java stack information for the threads listed above:
 ===
 Pax Web Runtime worker:
 at 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1836)
 - waiting to lock 0xfb585990 (a 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
 at 
 org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1317)
 at 
 org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1481)
 at 
 org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1427)
 at 
 org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
 at 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
 at 
 org.ops4j.pax.web.service.internal.Activator.updateController(Activator.java:247)
 at 
 org.ops4j.pax.web.service.internal.Activator$DynamicsServiceTrackerCustomizer$1.run(Activator.java:376)
 at 
 org.ops4j.pax.web.service.internal.Executor$Future.run(Executor.java:47)
 at 
 org.ops4j.pax.web.service.internal.Executor$Worker.run(Executor.java:128)
 Thread-15:
 at 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1836)
 - waiting to lock 0xf7681f70 (a 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
 at 
 org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1317)
 at 
 org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1481)
 at 
 org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1427)
 at 
 org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
 at 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
 at java.lang.ClassLoader.defineClass1(Native Method)
 at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
 at 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2128)
 - locked 0xfb585990 (a 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5)
 at 
 org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1432)
 at 
 org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
 at 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
 at 
 org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1317)
 at 
 org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1481)
 at 
 org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1427)
 at 
 org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
 at

[jira] [Comment Edited] (FELIX-4540) Deadlock in BundleWiringImpl$BundleClassLoader.loadClass

2014-06-24 Thread Richard S. Hall (JIRA)


[ 
https://issues.apache.org/jira/browse/FELIX-4540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14042119#comment-14042119
 ] 

Richard S. Hall edited comment on FELIX-4540 at 6/24/14 1:53 PM:
-

Just to cut to the chase, I'm guess that this is the standard JVM class loader 
deadlock issue. If you are on Java 7, then you should try upgrading your 
framework version since 4.0.3 does not take advantage of the parallel capable 
class loaders introduced in Java 7, but more recent framework versions do.


was (Author: rickhall):
Just to cut to the chase, I'm guess that this is the standard JVM class loader 
deadlock issue. If you are on Java 7, then you should try upgrading your 
framework version since 4.0.3 does not take advantage of the parallel capable 
class loaders introduced in Java, but more recent framework versions do.

 Deadlock in BundleWiringImpl$BundleClassLoader.loadClass
 

 Key: FELIX-4540
 URL: https://issues.apache.org/jira/browse/FELIX-4540
 Project: Felix
  Issue Type: Bug
 Environment: java version 1.7.0_55
 Karaf 2.3.4, Felix 4.0.3
Reporter: Martin Lichtin

 {noformat}
 Found one Java-level deadlock:
 =
 Pax Web Runtime worker:
   waiting to lock monitor 0x0b0a1438 (object 0xfb585990, a 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5),
   which is held by Thread-15
 Thread-15:
   waiting to lock monitor 0x0b0a1388 (object 0xf7681f70, a 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5),
   which is held by Pax Web Runtime worker
 Java stack information for the threads listed above:
 ===
 Pax Web Runtime worker:
 at 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1836)
 - waiting to lock 0xfb585990 (a 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
 at 
 org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1317)
 at 
 org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1481)
 at 
 org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1427)
 at 
 org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
 at 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
 at 
 org.ops4j.pax.web.service.internal.Activator.updateController(Activator.java:247)
 at 
 org.ops4j.pax.web.service.internal.Activator$DynamicsServiceTrackerCustomizer$1.run(Activator.java:376)
 at 
 org.ops4j.pax.web.service.internal.Executor$Future.run(Executor.java:47)
 at 
 org.ops4j.pax.web.service.internal.Executor$Worker.run(Executor.java:128)
 Thread-15:
 at 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1836)
 - waiting to lock 0xf7681f70 (a 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
 at 
 org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1317)
 at 
 org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1481)
 at 
 org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1427)
 at 
 org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
 at 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
 at java.lang.ClassLoader.defineClass1(Native Method)
 at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
 at 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2128)
 - locked 0xfb585990 (a 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5)
 at 
 org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1432)
 at 
 org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
 at 
 org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
 at 
 org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1317)

[jira] [Commented] (FELIX-4534) Bundles containing native code fails to start on Windows 7

2014-06-16 Thread Richard S. Hall (JIRA)


[ 
https://issues.apache.org/jira/browse/FELIX-4534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14032548#comment-14032548
 ] 

Richard S. Hall commented on FELIX-4534:


Looks good, David. Thanks!

 Bundles containing native code fails to start on Windows 7
 --

 Key: FELIX-4534
 URL: https://issues.apache.org/jira/browse/FELIX-4534
 Project: Felix
  Issue Type: Bug
  Components: Framework
Affects Versions: framework-4.2.0, framework-4.2.1, framework-4.4.0
 Environment: Windows 7
Reporter: Benoît Thiébault
Assignee: David Bosschaert
 Fix For: framework-4.6.0


 Windows 7 system is not properly recognized which makes bundles containing 
 native code fail to start.
 The OS name is retrieved using Java system property in org.apache.felix.Felix 
 class, line 4481. OS name is then Windows 7, with a space.
 It is then normalized using method 
 org.apache.felix.framework.util.manifestparser.R4LibraryClause.normalizeOSName()
  and stored in the configMap. OS name becomes windows7 without the space.
 When starting the bundle, method 
 org.apache.felix.framework.util.manifestparser.R4LibraryClause.match() is 
 called, retrieves the already normalized OS name (windows7) in the 
 configMap and normalizes it again.
 This second normalisation fails as windows7 without the space is not 
 recognized by method 
 org.apache.felix.framework.util.manifestparser.R4LibraryClause.normalizeOSName().
 In particular, the condition in the if statement line 392 is false when the 
 OS name is windows7:
 if ((value.indexOf( 7) = 0) || value.equals(win7))
 Possible solutions are:
 - prevent the OS name to be normalized twice (by checking if it is already 
 normal)
 - improve the normalisation to deal with windows7 OS name (by replacing the 
 if statement with if ((value.indexOf(7) = 0)) - no space)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (FELIX-4534) Bundles containing native code fails to start on Windows 7

2014-06-13 Thread Richard S. Hall (JIRA)


[ 
https://issues.apache.org/jira/browse/FELIX-4534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14030754#comment-14030754
 ] 

Richard S. Hall commented on FELIX-4534:


Ok, I think the best approach is to simply not re-normalize already normal 
names. Thanks!

 Bundles containing native code fails to start on Windows 7
 --

 Key: FELIX-4534
 URL: https://issues.apache.org/jira/browse/FELIX-4534
 Project: Felix
  Issue Type: Bug
  Components: Framework
Affects Versions: framework-4.2.0, framework-4.2.1, framework-4.4.0
 Environment: Windows 7
Reporter: Benoît Thiébault
Assignee: David Bosschaert
 Fix For: framework-4.6.0


 Windows 7 system is not properly recognized which makes bundles containing 
 native code fail to start.
 The OS name is retrieved using Java system property in org.apache.felix.Felix 
 class, line 4481. OS name is then Windows 7, with a space.
 It is then normalized using method 
 org.apache.felix.framework.util.manifestparser.R4LibraryClause.normalizeOSName()
  and stored in the configMap. OS name becomes windows7 without the space.
 When starting the bundle, method 
 org.apache.felix.framework.util.manifestparser.R4LibraryClause.match() is 
 called, retrieves the already normalized OS name (windows7) in the 
 configMap and normalizes it again.
 This second normalisation fails as windows7 without the space is not 
 recognized by method 
 org.apache.felix.framework.util.manifestparser.R4LibraryClause.normalizeOSName().
 In particular, the condition in the if statement line 392 is false when the 
 OS name is windows7:
 if ((value.indexOf( 7) = 0) || value.equals(win7))
 Possible solutions are:
 - prevent the OS name to be normalized twice (by checking if it is already 
 normal)
 - improve the normalisation to deal with windows7 OS name (by replacing the 
 if statement with if ((value.indexOf(7) = 0)) - no space)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (FELIX-4534) Bundles containing native code fails to start on Windows 7

2014-06-13 Thread Richard S. Hall (JIRA)


[ 
https://issues.apache.org/jira/browse/FELIX-4534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14031014#comment-14031014
 ] 

Richard S. Hall commented on FELIX-4534:


Yes, David, I think that would be the easiest too.

 Bundles containing native code fails to start on Windows 7
 --

 Key: FELIX-4534
 URL: https://issues.apache.org/jira/browse/FELIX-4534
 Project: Felix
  Issue Type: Bug
  Components: Framework
Affects Versions: framework-4.2.0, framework-4.2.1, framework-4.4.0
 Environment: Windows 7
Reporter: Benoît Thiébault
Assignee: David Bosschaert
 Fix For: framework-4.6.0


 Windows 7 system is not properly recognized which makes bundles containing 
 native code fail to start.
 The OS name is retrieved using Java system property in org.apache.felix.Felix 
 class, line 4481. OS name is then Windows 7, with a space.
 It is then normalized using method 
 org.apache.felix.framework.util.manifestparser.R4LibraryClause.normalizeOSName()
  and stored in the configMap. OS name becomes windows7 without the space.
 When starting the bundle, method 
 org.apache.felix.framework.util.manifestparser.R4LibraryClause.match() is 
 called, retrieves the already normalized OS name (windows7) in the 
 configMap and normalizes it again.
 This second normalisation fails as windows7 without the space is not 
 recognized by method 
 org.apache.felix.framework.util.manifestparser.R4LibraryClause.normalizeOSName().
 In particular, the condition in the if statement line 392 is false when the 
 OS name is windows7:
 if ((value.indexOf( 7) = 0) || value.equals(win7))
 Possible solutions are:
 - prevent the OS name to be normalized twice (by checking if it is already 
 normal)
 - improve the normalisation to deal with windows7 OS name (by replacing the 
 if statement with if ((value.indexOf(7) = 0)) - no space)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (FELIX-4528) Felix properties cannot be used in unsigned JNLP files

2014-06-10 Thread Richard S. Hall (JIRA)

[
https://issues.apache.org/jira/browse/FELIX-4528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14026402#comment-14026402
]

Richard S. Hall commented on FELIX-4528:

Admittedly, there are special cases handled in the framework, but typically
those are there to get the framework to run properly/better on a given
platform, not to get them to run with various frameworks on a given platform.
Sometimes this line can be fuzzy, but we try to be consistent. The idea is that
there are a lot fewer platforms to support than frameworks.

Regarding having the project structure to provide these modules, I think we do
have such a structure, we just need people to create launcher subprojects for
special use cases.

Felix properties cannot be used in unsigned JNLP files
--

Key: FELIX-4528
URL: https://issues.apache.org/jira/browse/FELIX-4528
Project: Felix
Issue Type: Improvement
Components: Framework
Environment: java 7u45 and later
Reporter: Rob Walker
Priority: Minor
Attachments: sec_action.patch

Unsigned JNLP files are required for most real world cases - especially those
with dynamic deployment needs where the host URL cannot be known in advance.
To use System properties in unsigned JNLP files they must be prefixed with
jnlp. - which effectively renders all current Felix properties unusable.
Attached is a patch with one implementation approach for this - a mod to
SecureAction to check for a jnlp, version of a property before falling back
to System properties or the supplied default.
An alternative would be additional init code in Felix or FelixConstants to
test each property that we wish to expose to JNLP files and push any non-null
value into System properties. This would be more transparent, but also more
maintenance whenever new FelixConstants are added.

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (FELIX-4528) Felix properties cannot be used in unsigned JNLP files

2014-06-09 Thread Richard S. Hall (JIRA)


[ 
https://issues.apache.org/jira/browse/FELIX-4528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14025535#comment-14025535
 ] 

Richard S. Hall commented on FELIX-4528:


I admit to not totally understanding the requirements here, but couldn't you 
create a separate launcher that pushes whichever properties you want into 
system properties before creating and starting a framework instance?

Seems odd to build this into the framework if it can be handled externally.

 Felix properties cannot be used in unsigned JNLP files
 --

 Key: FELIX-4528
 URL: https://issues.apache.org/jira/browse/FELIX-4528
 Project: Felix
  Issue Type: Improvement
  Components: Framework
 Environment: java 7u45 and later
Reporter: Rob Walker
Assignee: Rob Walker
Priority: Minor
 Attachments: sec_action.patch


 Unsigned JNLP files are required for most real world cases - especially those 
 with dynamic deployment needs where the host URL cannot be known  in advance.
 To use System properties in unsigned JNLP files  they must be prefixed with 
 jnlp.  - which effectively renders all current Felix properties unusable.
 Attached is a patch with one implementation approach for this - a mod to 
 SecureAction to check for a jnlp, version of a property before falling back 
 to System properties or the supplied default.
 An alternative would be additional init code in Felix or FelixConstants to 
 test each property that we wish to expose to JNLP files and push any non-null 
 value into System properties. This would be more transparent, but also more 
 maintenance whenever new FelixConstants are added.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (FELIX-4528) Felix properties cannot be used in unsigned JNLP files

2014-06-09 Thread Richard S. Hall (JIRA)


[ 
https://issues.apache.org/jira/browse/FELIX-4528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14025675#comment-14025675
 ] 

Richard S. Hall commented on FELIX-4528:


I understand your argument, but this was precisely the reason why we always 
tried to keep launching issues separate from the framework implementation, so 
that we don't need to insert any n-line changes for arbitrary launching 
purposes since everyone always views their own launching use case as more of a 
requirement than someone else's.

At a minimum, this seems like you should be proposing a feature request against 
Main, which is the launcher, as opposed to the framework implementation. Even 
then, we've still largely maintained that Main was more of a simple, general 
purpose launcher and not meant to handle all cases.

Yet another approach is to simply create a new Felix subproject for a 
JNLP-specific launcher that has all the bells and whistles necessary to easily 
use the Felix framework within JNLP.

 Felix properties cannot be used in unsigned JNLP files
 --

 Key: FELIX-4528
 URL: https://issues.apache.org/jira/browse/FELIX-4528
 Project: Felix
  Issue Type: Improvement
  Components: Framework
 Environment: java 7u45 and later
Reporter: Rob Walker
Assignee: Rob Walker
Priority: Minor
 Attachments: sec_action.patch


 Unsigned JNLP files are required for most real world cases - especially those 
 with dynamic deployment needs where the host URL cannot be known  in advance.
 To use System properties in unsigned JNLP files  they must be prefixed with 
 jnlp.  - which effectively renders all current Felix properties unusable.
 Attached is a patch with one implementation approach for this - a mod to 
 SecureAction to check for a jnlp, version of a property before falling back 
 to System properties or the supplied default.
 An alternative would be additional init code in Felix or FelixConstants to 
 test each property that we wish to expose to JNLP files and push any non-null 
 value into System properties. This would be more transparent, but also more 
 maintenance whenever new FelixConstants are added.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (FELIX-4527) Infinite loop when bundle is undeployed coldly (when container is stopped)

2014-06-04 Thread Richard S. Hall (JIRA)


[ 
https://issues.apache.org/jira/browse/FELIX-4527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14017646#comment-14017646
 ] 

Richard S. Hall commented on FELIX-4527:


So, should this bug just be closed as a duplicate then?

 Infinite loop when bundle is undeployed coldly (when container is stopped)
 

 Key: FELIX-4527
 URL: https://issues.apache.org/jira/browse/FELIX-4527
 Project: Felix
  Issue Type: Bug
  Components: Framework
Affects Versions: framework-3.2.2
 Environment: ServiceMix 4.5.3
Reporter: metatech
 Attachments: felix_cold_undeploy.diff


 When a bundle is undeployed when ServiceMix is stopped, on the next restart 
 the FelixStartLevel thread enters an infinite loop.
 {code}
 FelixStartLevel daemon prio=6 tid=0x07ae9800 nid=0x2da4 runnable 
 [0x091cf000]
java.lang.Thread.State: RUNNABLE
 at 
 java.lang.IllegalStateException.init(IllegalStateException.java:55)
 at org.apache.felix.framework.Felix.acquireBundleLock(Felix.java:4955)
 - locked 0xc11bbc88 (a [Ljava.lang.Object;)
 at 
 org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1156)
 at 
 org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:266)
 at java.lang.Thread.run(Thread.java:744)
 {code}
 This is a side-effect of change FELIX-2942, in which the for loop has been 
 replaced by a while loop on a boolean bundlesRemaining.  The 
 bundlesRemaining is not recomputed in every iteration the loop. For 
 instance, when a IllegalStateException is caught, it skips to the next 
 iteration of the loop (continue).  It therefore loops infinitely.
 Suggestion solution : recompute the boolean bundlesRemaining at each 
 iteration of the loop (perhaps in a finally block ?).
 This regression has been introduced in Felix 3.2.x : version 3.0.x did not 
 have this problem.
 The impact on ServiceMix users is that cold undeploy is broken, but 
 fortunately, warm undeploy is not.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (FELIX-4524) Substituted exports may cause IndexOutOfBoundsException

2014-05-28 Thread Richard S. Hall (JIRA)


 [ 
https://issues.apache.org/jira/browse/FELIX-4524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall resolved FELIX-4524.


   Resolution: Fixed
Fix Version/s: resolver-1.2.0
 Assignee: Richard S. Hall

I've applied the patch, please close if satisfied. Thanks!

 Substituted exports may cause IndexOutOfBoundsException
 ---

 Key: FELIX-4524
 URL: https://issues.apache.org/jira/browse/FELIX-4524
 Project: Felix
  Issue Type: Bug
  Components: Resolver
Reporter: Thomas Watson
Assignee: Richard S. Hall
 Fix For: resolver-1.2.0

 Attachments: org.apache.felix.resolver.patch


 In some cases substituted exports can cause IndexOutOfBoundsException.  This 
 can happen if you have a substituted export for which the exported capability 
 is the only capability that can satisfy one or more other requirements.  For 
 example:
 BSN: A
 Import-Package; substituted; version=[1.0,1.1)
 BSN: B
 Export-Package: substituted; version=1.0
 Import-Package: substituted; version=1.0
 BSN: C
 Export-Package: substituted; version=1.1
 Import-Package: substituted; version=1.1
 Resolving A as a root resource will cause something like the following 
 exception:
 java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
   at java.util.ArrayList.rangeCheck(ArrayList.java:635)
   at java.util.ArrayList.get(ArrayList.java:411)
   at 
 org.apache.felix.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:692)
   at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:251)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (FELIX-3966) Require-Bundle header is not parsed correctly

2014-05-14 Thread Richard S. Hall (JIRA)


 [ 
https://issues.apache.org/jira/browse/FELIX-3966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall resolved FELIX-3966.


   Resolution: Not a Problem
Fix Version/s: (was: framework-4.6.0)

 Require-Bundle header is not parsed correctly
 -

 Key: FELIX-3966
 URL: https://issues.apache.org/jira/browse/FELIX-3966
 Project: Felix
  Issue Type: Bug
  Components: Framework
Affects Versions: framework-4.2.0
Reporter: Sahoo
Priority: Trivial

 It seems Felix is not detetcing a bad Require-Bundle header where as Knopfler 
 is detecting it:
 Require-Bundle: bundle1, system.bundle; org.knopflerfish.framework; 
 resolution:=optional
 A correct way to write above would be:
 Require-Bundle: bundle1, system.bundle;resolution:=optional, 
 org.knopflerfish.framework; resolution:=optional



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (FELIX-4182) Issues with package space consistency check

2014-04-24 Thread Richard S. Hall (JIRA)


 [ 
https://issues.apache.org/jira/browse/FELIX-4182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall updated FELIX-4182:
---

Affects Version/s: resolver-1.0.0

 Issues with package space consistency check
 ---

 Key: FELIX-4182
 URL: https://issues.apache.org/jira/browse/FELIX-4182
 Project: Felix
  Issue Type: Bug
  Components: Resolver
Affects Versions: resolver-1.0.0
 Environment: All
Reporter: Thomas Watson
 Fix For: resolver-1.2.0

 Attachments: org.apache.felix.resolver.patch


 There are two issues here.  I could separate this into two reports but I need 
 them both fixed at the same time and will be providing a patch shortly that 
 addresses both of the following issues:
 1) ResolverImpl.resolve(ResolveContext) fails hard if a consistent class 
 space cannot be found for all optional resources being resolved.  It would be 
 nice of the resolve process could eliminate some optional resources that are 
 the 'roots' that caused the inconsistent class space and try again.
 2) There is a case where a false positive inconsistency is reported for 
 require-bundle and split packages.  Here is the scenario
 Bundle uses.a
 Export-Package: 
  uses1; uses:=uses2; A=split; mandatory:=A,
  uses2; A=split; mandatory:=A
 Bundle uses.b
 Export-Package: 
  uses1; uses:=uses2; B=split; mandatory:=B,
  uses2; B=split; mandatory:=B
 Bundle uses.d
 Require-Bundle: uses.a, uses.b
 In this scenario, if an attempt is made to resolve uses.d then 
 checkDynamicPackageSpaceConsistency method will detect that uses2 is 
 inconsistent for resource uses.d because it gets it from two different 
 sources uses.a and uses.b.  You get something like the following error 
 message:
 Uses constraint violation. Unable to resolve resource uses.d [osgi.identity; 
 osgi.identity=uses.d; type=osgi.bundle; version:Version=1.0.0] because 
 it is exposed to package 'uses2' from resources uses.a [osgi.identity; 
 osgi.identity=uses.a; type=osgi.bundle; version:Version=1.0.0] and 
 uses.b [osgi.identity; osgi.identity=uses.b; type=osgi.bundle; 
 version:Version=1.0.0] via two dependency chains.
 Chain 1:
   uses.d [osgi.identity; osgi.identity=uses.d; type=osgi.bundle; 
 version:Version=1.0.0]
 require: (osgi.wiring.bundle=uses.a)
  |
 provide: osgi.wiring.bundle: uses.a
   uses.a [osgi.identity; osgi.identity=uses.a; type=osgi.bundle; 
 version:Version=1.0.0]
 Chain 2:
   uses.d [osgi.identity; osgi.identity=uses.d; type=osgi.bundle; 
 version:Version=1.0.0]
 require: (osgi.wiring.bundle=uses.b)
  |
 provide: osgi.wiring.bundle: uses.b
   uses.b [osgi.identity; osgi.identity=uses.b; type=osgi.bundle; 
 version:Version=1.0.0]
 The issue is in the check for isCompatible.  This method attempts to address 
 split packages, but only for the provider of the split package, it does not 
 aggregate the split sources for clients using require-bundle to gather all 
 the sources of the split package.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (FELIX-4182) Issues with package space consistency check

2014-04-24 Thread Richard S. Hall (JIRA)


 [ 
https://issues.apache.org/jira/browse/FELIX-4182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall updated FELIX-4182:
---

Fix Version/s: resolver-1.2.0

 Issues with package space consistency check
 ---

 Key: FELIX-4182
 URL: https://issues.apache.org/jira/browse/FELIX-4182
 Project: Felix
  Issue Type: Bug
  Components: Resolver
Affects Versions: resolver-1.0.0
 Environment: All
Reporter: Thomas Watson
 Fix For: resolver-1.2.0

 Attachments: org.apache.felix.resolver.patch


 There are two issues here.  I could separate this into two reports but I need 
 them both fixed at the same time and will be providing a patch shortly that 
 addresses both of the following issues:
 1) ResolverImpl.resolve(ResolveContext) fails hard if a consistent class 
 space cannot be found for all optional resources being resolved.  It would be 
 nice of the resolve process could eliminate some optional resources that are 
 the 'roots' that caused the inconsistent class space and try again.
 2) There is a case where a false positive inconsistency is reported for 
 require-bundle and split packages.  Here is the scenario
 Bundle uses.a
 Export-Package: 
  uses1; uses:=uses2; A=split; mandatory:=A,
  uses2; A=split; mandatory:=A
 Bundle uses.b
 Export-Package: 
  uses1; uses:=uses2; B=split; mandatory:=B,
  uses2; B=split; mandatory:=B
 Bundle uses.d
 Require-Bundle: uses.a, uses.b
 In this scenario, if an attempt is made to resolve uses.d then 
 checkDynamicPackageSpaceConsistency method will detect that uses2 is 
 inconsistent for resource uses.d because it gets it from two different 
 sources uses.a and uses.b.  You get something like the following error 
 message:
 Uses constraint violation. Unable to resolve resource uses.d [osgi.identity; 
 osgi.identity=uses.d; type=osgi.bundle; version:Version=1.0.0] because 
 it is exposed to package 'uses2' from resources uses.a [osgi.identity; 
 osgi.identity=uses.a; type=osgi.bundle; version:Version=1.0.0] and 
 uses.b [osgi.identity; osgi.identity=uses.b; type=osgi.bundle; 
 version:Version=1.0.0] via two dependency chains.
 Chain 1:
   uses.d [osgi.identity; osgi.identity=uses.d; type=osgi.bundle; 
 version:Version=1.0.0]
 require: (osgi.wiring.bundle=uses.a)
  |
 provide: osgi.wiring.bundle: uses.a
   uses.a [osgi.identity; osgi.identity=uses.a; type=osgi.bundle; 
 version:Version=1.0.0]
 Chain 2:
   uses.d [osgi.identity; osgi.identity=uses.d; type=osgi.bundle; 
 version:Version=1.0.0]
 require: (osgi.wiring.bundle=uses.b)
  |
 provide: osgi.wiring.bundle: uses.b
   uses.b [osgi.identity; osgi.identity=uses.b; type=osgi.bundle; 
 version:Version=1.0.0]
 The issue is in the check for isCompatible.  This method attempts to address 
 split packages, but only for the provider of the split package, it does not 
 aggregate the split sources for clients using require-bundle to gather all 
 the sources of the split package.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (FELIX-4182) Issues with package space consistency check

2014-04-24 Thread Richard S. Hall (JIRA)


 [ 
https://issues.apache.org/jira/browse/FELIX-4182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall resolved FELIX-4182.


Resolution: Fixed

Applied supplied patch to align with work done by Tom Watson at Equinox: 
http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=a7bb93e965ee40f221a1eaeb77a94aba955820e8

Please close if satisfied, thanks.

 Issues with package space consistency check
 ---

 Key: FELIX-4182
 URL: https://issues.apache.org/jira/browse/FELIX-4182
 Project: Felix
  Issue Type: Bug
  Components: Resolver
Affects Versions: resolver-1.0.0
 Environment: All
Reporter: Thomas Watson
 Fix For: resolver-1.2.0

 Attachments: org.apache.felix.resolver.patch


 There are two issues here.  I could separate this into two reports but I need 
 them both fixed at the same time and will be providing a patch shortly that 
 addresses both of the following issues:
 1) ResolverImpl.resolve(ResolveContext) fails hard if a consistent class 
 space cannot be found for all optional resources being resolved.  It would be 
 nice of the resolve process could eliminate some optional resources that are 
 the 'roots' that caused the inconsistent class space and try again.
 2) There is a case where a false positive inconsistency is reported for 
 require-bundle and split packages.  Here is the scenario
 Bundle uses.a
 Export-Package: 
  uses1; uses:=uses2; A=split; mandatory:=A,
  uses2; A=split; mandatory:=A
 Bundle uses.b
 Export-Package: 
  uses1; uses:=uses2; B=split; mandatory:=B,
  uses2; B=split; mandatory:=B
 Bundle uses.d
 Require-Bundle: uses.a, uses.b
 In this scenario, if an attempt is made to resolve uses.d then 
 checkDynamicPackageSpaceConsistency method will detect that uses2 is 
 inconsistent for resource uses.d because it gets it from two different 
 sources uses.a and uses.b.  You get something like the following error 
 message:
 Uses constraint violation. Unable to resolve resource uses.d [osgi.identity; 
 osgi.identity=uses.d; type=osgi.bundle; version:Version=1.0.0] because 
 it is exposed to package 'uses2' from resources uses.a [osgi.identity; 
 osgi.identity=uses.a; type=osgi.bundle; version:Version=1.0.0] and 
 uses.b [osgi.identity; osgi.identity=uses.b; type=osgi.bundle; 
 version:Version=1.0.0] via two dependency chains.
 Chain 1:
   uses.d [osgi.identity; osgi.identity=uses.d; type=osgi.bundle; 
 version:Version=1.0.0]
 require: (osgi.wiring.bundle=uses.a)
  |
 provide: osgi.wiring.bundle: uses.a
   uses.a [osgi.identity; osgi.identity=uses.a; type=osgi.bundle; 
 version:Version=1.0.0]
 Chain 2:
   uses.d [osgi.identity; osgi.identity=uses.d; type=osgi.bundle; 
 version:Version=1.0.0]
 require: (osgi.wiring.bundle=uses.b)
  |
 provide: osgi.wiring.bundle: uses.b
   uses.b [osgi.identity; osgi.identity=uses.b; type=osgi.bundle; 
 version:Version=1.0.0]
 The issue is in the check for isCompatible.  This method attempts to address 
 split packages, but only for the provider of the split package, it does not 
 aggregate the split sources for clients using require-bundle to gather all 
 the sources of the split package.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (FELIX-4492) Enhance resolver logging to get better uses diagnostics

2014-04-24 Thread Richard S. Hall (JIRA)


 [ 
https://issues.apache.org/jira/browse/FELIX-4492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall updated FELIX-4492:
---

Affects Version/s: resolver-1.0.0

 Enhance resolver logging to get better uses diagnostics
 ---

 Key: FELIX-4492
 URL: https://issues.apache.org/jira/browse/FELIX-4492
 Project: Felix
  Issue Type: Improvement
  Components: Resolver
Affects Versions: resolver-1.0.0
Reporter: Thomas Watson
 Attachments: org.apache.felix.resolver.patch


 There is lots of useful information the resolver encounters while trying to 
 resolve a consistent class space having to do with uses constraint 
 violations.  The felix resolver encodes a nice chain message contained in a 
 ResolutionException that can help diagnose uses constraint issues.
 It would be helpful if the Logger was enhanced to be able to capture the 
 ResolutionException for uses constraint violations as they occur during the 
 resolve process.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (FELIX-4492) Enhance resolver logging to get better uses diagnostics

2014-04-24 Thread Richard S. Hall (JIRA)


 [ 
https://issues.apache.org/jira/browse/FELIX-4492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall resolved FELIX-4492.


Resolution: Fixed
  Assignee: Richard S. Hall

Patch applied. Please close.

 Enhance resolver logging to get better uses diagnostics
 ---

 Key: FELIX-4492
 URL: https://issues.apache.org/jira/browse/FELIX-4492
 Project: Felix
  Issue Type: Improvement
  Components: Resolver
Affects Versions: resolver-1.0.0
Reporter: Thomas Watson
Assignee: Richard S. Hall
 Fix For: resolver-1.2.0

 Attachments: org.apache.felix.resolver.patch


 There is lots of useful information the resolver encounters while trying to 
 resolve a consistent class space having to do with uses constraint 
 violations.  The felix resolver encodes a nice chain message contained in a 
 ResolutionException that can help diagnose uses constraint issues.
 It would be helpful if the Logger was enhanced to be able to capture the 
 ResolutionException for uses constraint violations as they occur during the 
 resolve process.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (FELIX-4492) Enhance resolver logging to get better uses diagnostics

2014-04-24 Thread Richard S. Hall (JIRA)


 [ 
https://issues.apache.org/jira/browse/FELIX-4492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall updated FELIX-4492:
---

Fix Version/s: resolver-1.2.0

 Enhance resolver logging to get better uses diagnostics
 ---

 Key: FELIX-4492
 URL: https://issues.apache.org/jira/browse/FELIX-4492
 Project: Felix
  Issue Type: Improvement
  Components: Resolver
Affects Versions: resolver-1.0.0
Reporter: Thomas Watson
 Fix For: resolver-1.2.0

 Attachments: org.apache.felix.resolver.patch


 There is lots of useful information the resolver encounters while trying to 
 resolve a consistent class space having to do with uses constraint 
 violations.  The felix resolver encodes a nice chain message contained in a 
 ResolutionException that can help diagnose uses constraint issues.
 It would be helpful if the Logger was enhanced to be able to capture the 
 ResolutionException for uses constraint violations as they occur during the 
 resolve process.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (FELIX-4493) Allow ResolveContext to supply on demand resources

2014-04-24 Thread Richard S. Hall (JIRA)

[
https://issues.apache.org/jira/browse/FELIX-4493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Richard S. Hall updated FELIX-4493:
---

Fix Version/s: resolver-1.2.0

Allow ResolveContext to supply on demand resources
--

Key: FELIX-4493
URL: https://issues.apache.org/jira/browse/FELIX-4493
Project: Felix
Issue Type: Improvement
Components: Resolver
Affects Versions: resolver-1.0.0
Reporter: Thomas Watson
Fix For: resolver-1.2.0

Attachments: org.apache.felix.resolver.patch

We have been discussing two approaches to using the resolver
1) Big bang resolve. This is where the client wants to attempt to resolve
all currently unresolved resources in one go. Here the ResolveContext could
return all the unresolved resources as optional resources. This makes
fragment resolution more simple because the resolver is supplied the complete
set of unresolved resources from the start. But it still has a drawback of
not allowing an already resolved fragment to be attached to another host
since there is no mechanism to pull in the already resolved fragment when
resolving another potential host.
2) Single root resolve. Here the client wants to attempt to resolve each
root resource individually. As we are populating the root resource
additional resources get pulled in as they supply candidates for the
requirements that need to be resolved. This approach also suffers from a
similar fragment issue since fragments will not get automatically pulled into
a resolve operation unless they are either the root resource or they provide
a candidate capability needed to resolve some other requirement.
It would be useful if the ResolveContext could provide additional on demand
resources that get pulled in as other resources are getting automatically
pulled into the populate candidate phase.
I suggest we add a felix specific ResolveContext interface that can be
optionally implemented in order to provide a method
getOndemandResources(Resource host). This method would get called by the
resolver as it pulls in resources during the populate candidates phase.

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (FELIX-4493) Allow ResolveContext to supply on demand resources

2014-04-24 Thread Richard S. Hall (JIRA)

[
https://issues.apache.org/jira/browse/FELIX-4493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Richard S. Hall resolved FELIX-4493.

Resolution: Fixed
Assignee: Richard S. Hall

Applied patch corresponding with
http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=a1bf47f33cb8e37c97b8aee5325adc4fffba0a21

Please close if satisfied, thanks.

Allow ResolveContext to supply on demand resources
--

Attachments: org.apache.felix.resolver.patch

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (FELIX-4494) Fragment identity capabilities are incorrectly wrapped

2014-04-24 Thread Richard S. Hall (JIRA)


 [ 
https://issues.apache.org/jira/browse/FELIX-4494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall resolved FELIX-4494.


Resolution: Fixed
  Assignee: Richard S. Hall

I've applied the patch, please close if satisfied. Thanks.

 Fragment identity capabilities are incorrectly wrapped
 --

 Key: FELIX-4494
 URL: https://issues.apache.org/jira/browse/FELIX-4494
 Project: Felix
  Issue Type: Bug
Affects Versions: resolver-1.0.0
Reporter: Thomas Watson
Assignee: Richard S. Hall
 Fix For: resolver-1.2.0

 Attachments: org.apache.felix.resolver.patch


 The osgi.identity capability is not a payload capability for a fragment.  We 
 must never wrap them as if they are payloads for the hosts they are attached 
 to.
 The Cadidates.processCandidates method is currently wrapping all capabilities 
 from a fragment.  Also the Candidates code makes the incorrect assumption 
 that a a fragment wiring only has required wires in the osgi.wiring.host 
 namespace.  This is not true since osgi.ee namespace is also not a payload 
 requirement.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (FELIX-4494) Fragment identity capabilities are incorrectly wrapped

2014-04-24 Thread Richard S. Hall (JIRA)


 [ 
https://issues.apache.org/jira/browse/FELIX-4494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall updated FELIX-4494:
---

Affects Version/s: resolver-1.0.0

 Fragment identity capabilities are incorrectly wrapped
 --

 Key: FELIX-4494
 URL: https://issues.apache.org/jira/browse/FELIX-4494
 Project: Felix
  Issue Type: Bug
Affects Versions: resolver-1.0.0
Reporter: Thomas Watson
 Fix For: resolver-1.2.0

 Attachments: org.apache.felix.resolver.patch


 The osgi.identity capability is not a payload capability for a fragment.  We 
 must never wrap them as if they are payloads for the hosts they are attached 
 to.
 The Cadidates.processCandidates method is currently wrapping all capabilities 
 from a fragment.  Also the Candidates code makes the incorrect assumption 
 that a a fragment wiring only has required wires in the osgi.wiring.host 
 namespace.  This is not true since osgi.ee namespace is also not a payload 
 requirement.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (FELIX-4494) Fragment identity capabilities are incorrectly wrapped

2014-04-24 Thread Richard S. Hall (JIRA)


 [ 
https://issues.apache.org/jira/browse/FELIX-4494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall updated FELIX-4494:
---

Fix Version/s: resolver-1.2.0

 Fragment identity capabilities are incorrectly wrapped
 --

 Key: FELIX-4494
 URL: https://issues.apache.org/jira/browse/FELIX-4494
 Project: Felix
  Issue Type: Bug
Affects Versions: resolver-1.0.0
Reporter: Thomas Watson
 Fix For: resolver-1.2.0

 Attachments: org.apache.felix.resolver.patch


 The osgi.identity capability is not a payload capability for a fragment.  We 
 must never wrap them as if they are payloads for the hosts they are attached 
 to.
 The Cadidates.processCandidates method is currently wrapping all capabilities 
 from a fragment.  Also the Candidates code makes the incorrect assumption 
 that a a fragment wiring only has required wires in the osgi.wiring.host 
 namespace.  This is not true since osgi.ee namespace is also not a payload 
 requirement.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (FELIX-4495) Candidates from already resolved fragments get ignored if no new hosts are available

2014-04-24 Thread Richard S. Hall (JIRA)


 [ 
https://issues.apache.org/jira/browse/FELIX-4495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall resolved FELIX-4495.


Resolution: Fixed

I applied the patch, please close if satisfied. Thanks.

 Candidates from already resolved fragments get ignored if no new hosts are 
 available
 

 Key: FELIX-4495
 URL: https://issues.apache.org/jira/browse/FELIX-4495
 Project: Felix
  Issue Type: Bug
  Components: Resolver
Affects Versions: resolver-1.0.0
Reporter: Thomas Watson
 Fix For: resolver-1.2.0

 Attachments: org.apache.felix.resolver.patch


 org.apache.felix.resolver.Candidates.populateResource(ResolveContext, 
 Resource) gets called for fragments even if they are already resolved so that 
 we can attach them to more hosts as needed.
 The issue is that this method will throw a ResolutionException if the 
 fragment cannot attach to any new hosts during the current resolve process.  
 This has the effect of removing any candidate capabilities provided by 
 already resolved fragments.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (FELIX-4495) Candidates from already resolved fragments get ignored if no new hosts are available

2014-04-24 Thread Richard S. Hall (JIRA)


 [ 
https://issues.apache.org/jira/browse/FELIX-4495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall updated FELIX-4495:
---

Affects Version/s: resolver-1.0.0

 Candidates from already resolved fragments get ignored if no new hosts are 
 available
 

 Key: FELIX-4495
 URL: https://issues.apache.org/jira/browse/FELIX-4495
 Project: Felix
  Issue Type: Bug
  Components: Resolver
Affects Versions: resolver-1.0.0
Reporter: Thomas Watson
 Fix For: resolver-1.2.0

 Attachments: org.apache.felix.resolver.patch


 org.apache.felix.resolver.Candidates.populateResource(ResolveContext, 
 Resource) gets called for fragments even if they are already resolved so that 
 we can attach them to more hosts as needed.
 The issue is that this method will throw a ResolutionException if the 
 fragment cannot attach to any new hosts during the current resolve process.  
 This has the effect of removing any candidate capabilities provided by 
 already resolved fragments.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (FELIX-4428) When inserting hosted capability from an already resolved fragment the real non-hosted capability is not removed as a candidate

2014-04-24 Thread Richard S. Hall (JIRA)


 [ 
https://issues.apache.org/jira/browse/FELIX-4428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall updated FELIX-4428:
---

Affects Version/s: resolver-1.0.0

 When inserting hosted capability from an already resolved fragment the real 
 non-hosted capability is not removed as a candidate
 ---

 Key: FELIX-4428
 URL: https://issues.apache.org/jira/browse/FELIX-4428
 Project: Felix
  Issue Type: Bug
  Components: Resolver
Affects Versions: resolver-1.0.0
Reporter: Thomas Watson
 Fix For: resolver-1.2.0

 Attachments: org.apache.felix.resolver.patch


 In Candidates there are two places where 
 ResolveContext.insertHostedCapability is called:
  - org.apache.felix.resolver.Candidates.prepare(ResolveContext)
  - org.apache.felix.resolver.Candidates.processCandidates(ResolveContext, 
 Resource, ListCapability)
 In the prepare method the actual fragment capability is correctly removed as 
 a candidate when inserting the hosted capability:
 ListCapability original = ((ShadowList) 
 cands).getOriginal();
 int removeIdx = original.indexOf(origCap);
 if (removeIdx != -1)
 {
 original.remove(removeIdx);
 cands.remove(removeIdx);
 }
 But in the processCandidates method this is not the case.  This can lead to 
 invalid Wires being created where the fragment resource is the provider.  
 This happens if the hosted capability introduces a class space inconsistency 
 (from uses constraints).  In this case we move on to the next candidate which 
 may be the fragment capability (depending on how the ResolveContext sorts).
 The fix is simple, just remove the original fragment capability from the 
 candidate list.  I fixed this in equinox with commit:
 http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=7efe91f3673e970f32cabc3701e99743a536da00



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (FELIX-4428) When inserting hosted capability from an already resolved fragment the real non-hosted capability is not removed as a candidate

2014-04-24 Thread Richard S. Hall (JIRA)


 [ 
https://issues.apache.org/jira/browse/FELIX-4428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall resolved FELIX-4428.


Resolution: Fixed
  Assignee: Richard S. Hall

Applied patch, please close if satisfied. Thanks.

 When inserting hosted capability from an already resolved fragment the real 
 non-hosted capability is not removed as a candidate
 ---

 Key: FELIX-4428
 URL: https://issues.apache.org/jira/browse/FELIX-4428
 Project: Felix
  Issue Type: Bug
  Components: Resolver
Affects Versions: resolver-1.0.0
Reporter: Thomas Watson
Assignee: Richard S. Hall
 Fix For: resolver-1.2.0

 Attachments: org.apache.felix.resolver.patch


 In Candidates there are two places where 
 ResolveContext.insertHostedCapability is called:
  - org.apache.felix.resolver.Candidates.prepare(ResolveContext)
  - org.apache.felix.resolver.Candidates.processCandidates(ResolveContext, 
 Resource, ListCapability)
 In the prepare method the actual fragment capability is correctly removed as 
 a candidate when inserting the hosted capability:
 ListCapability original = ((ShadowList) 
 cands).getOriginal();
 int removeIdx = original.indexOf(origCap);
 if (removeIdx != -1)
 {
 original.remove(removeIdx);
 cands.remove(removeIdx);
 }
 But in the processCandidates method this is not the case.  This can lead to 
 invalid Wires being created where the fragment resource is the provider.  
 This happens if the hosted capability introduces a class space inconsistency 
 (from uses constraints).  In this case we move on to the next candidate which 
 may be the fragment capability (depending on how the ResolveContext sorts).
 The fix is simple, just remove the original fragment capability from the 
 candidate list.  I fixed this in equinox with commit:
 http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=7efe91f3673e970f32cabc3701e99743a536da00



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (FELIX-4497) Invalid wirings may result from substitutable exports

2014-04-24 Thread Richard S. Hall (JIRA)


 [ 
https://issues.apache.org/jira/browse/FELIX-4497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall updated FELIX-4497:
---

Fix Version/s: resolver-1.2.0

 Invalid wirings may result from substitutable exports
 -

 Key: FELIX-4497
 URL: https://issues.apache.org/jira/browse/FELIX-4497
 Project: Felix
  Issue Type: Bug
Affects Versions: resolver-1.0.0
Reporter: Thomas Watson
 Fix For: resolver-1.2.0

 Attachments: org.apache.felix.resolver.patch


 FELIX-737 is a framework issue but the same issue also exists in the 
 standalone resolver implementation.  I am opening a separate bug to 
 specifically address the issue in the standalone resolver implementation.
 The felix framework resolve has a known issue with substitutable exports 
 FELIX-737.  The scenario is pretty complex.  It involves bundles multiple 
 bundles that export and import the same package X at different versions and 
 an importer that imports the package with a range that requires a specific 
 package.  If that specific package gets substituted there are cases where the 
 resolver will return wires to the substituted export.
 The ideal solution would do something smart with selection of substituted 
 exports so that different combinations or selections can be made if the first 
 substitution did not provide good results.  This potentially will explode the 
 permutations.  For now we should at least change the current permutation to 
 drop the substituted exports so that invalid wires do not get created.  That 
 could drop some good valid combinations, but that is better than the current 
 state where completely invalid wires get created.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (FELIX-4497) Invalid wirings may result from substitutable exports

2014-04-24 Thread Richard S. Hall (JIRA)


 [ 
https://issues.apache.org/jira/browse/FELIX-4497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall updated FELIX-4497:
---

Affects Version/s: resolver-1.0.0

 Invalid wirings may result from substitutable exports
 -

 Key: FELIX-4497
 URL: https://issues.apache.org/jira/browse/FELIX-4497
 Project: Felix
  Issue Type: Bug
Affects Versions: resolver-1.0.0
Reporter: Thomas Watson
 Fix For: resolver-1.2.0

 Attachments: org.apache.felix.resolver.patch


 FELIX-737 is a framework issue but the same issue also exists in the 
 standalone resolver implementation.  I am opening a separate bug to 
 specifically address the issue in the standalone resolver implementation.
 The felix framework resolve has a known issue with substitutable exports 
 FELIX-737.  The scenario is pretty complex.  It involves bundles multiple 
 bundles that export and import the same package X at different versions and 
 an importer that imports the package with a range that requires a specific 
 package.  If that specific package gets substituted there are cases where the 
 resolver will return wires to the substituted export.
 The ideal solution would do something smart with selection of substituted 
 exports so that different combinations or selections can be made if the first 
 substitution did not provide good results.  This potentially will explode the 
 permutations.  For now we should at least change the current permutation to 
 drop the substituted exports so that invalid wires do not get created.  That 
 could drop some good valid combinations, but that is better than the current 
 state where completely invalid wires get created.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (FELIX-4498) Resolver does not allow optional reqs to resolve if they introduce class space inconsistencies

2014-04-24 Thread Richard S. Hall (JIRA)


 [ 
https://issues.apache.org/jira/browse/FELIX-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall updated FELIX-4498:
---

Fix Version/s: resolver-1.2.0

 Resolver does not allow optional reqs to resolve if they introduce class 
 space inconsistencies
 --

 Key: FELIX-4498
 URL: https://issues.apache.org/jira/browse/FELIX-4498
 Project: Felix
  Issue Type: Improvement
  Components: Resolver
Affects Versions: resolver-1.0.0
Reporter: Thomas Watson
 Fix For: resolver-1.2.0

 Attachments: org.apache.felix.resolver.patch


 If an optional requirement has at least one matching capability available to 
 it then the resolver only lets the resource resolve if at least one of the 
 optional candidates gives a consistent class space; otherwise the resource 
 will fail to resolve.
 While not required by the spec to find a solution, if one exists we could 
 modify the resolver to allow a permutation that has zero candidates for 
 optional requirements.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (FELIX-4498) Resolver does not allow optional reqs to resolve if they introduce class space inconsistencies

2014-04-24 Thread Richard S. Hall (JIRA)


 [ 
https://issues.apache.org/jira/browse/FELIX-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall updated FELIX-4498:
---

Affects Version/s: resolver-1.0.0

 Resolver does not allow optional reqs to resolve if they introduce class 
 space inconsistencies
 --

 Key: FELIX-4498
 URL: https://issues.apache.org/jira/browse/FELIX-4498
 Project: Felix
  Issue Type: Improvement
  Components: Resolver
Affects Versions: resolver-1.0.0
Reporter: Thomas Watson
 Fix For: resolver-1.2.0

 Attachments: org.apache.felix.resolver.patch


 If an optional requirement has at least one matching capability available to 
 it then the resolver only lets the resource resolve if at least one of the 
 optional candidates gives a consistent class space; otherwise the resource 
 will fail to resolve.
 While not required by the spec to find a solution, if one exists we could 
 modify the resolver to allow a permutation that has zero candidates for 
 optional requirements.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (FELIX-4498) Resolver does not allow optional reqs to resolve if they introduce class space inconsistencies

2014-04-24 Thread Richard S. Hall (JIRA)


 [ 
https://issues.apache.org/jira/browse/FELIX-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall resolved FELIX-4498.


Resolution: Fixed
  Assignee: Richard S. Hall

Applied patch, please close if satisfied. Thanks.

 Resolver does not allow optional reqs to resolve if they introduce class 
 space inconsistencies
 --

 Key: FELIX-4498
 URL: https://issues.apache.org/jira/browse/FELIX-4498
 Project: Felix
  Issue Type: Improvement
  Components: Resolver
Affects Versions: resolver-1.0.0
Reporter: Thomas Watson
Assignee: Richard S. Hall
 Fix For: resolver-1.2.0

 Attachments: org.apache.felix.resolver.patch


 If an optional requirement has at least one matching capability available to 
 it then the resolver only lets the resource resolve if at least one of the 
 optional candidates gives a consistent class space; otherwise the resource 
 will fail to resolve.
 While not required by the spec to find a solution, if one exists we could 
 modify the resolver to allow a permutation that has zero candidates for 
 optional requirements.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (FELIX-3701) Intermittent CNFE with embedded jars in Fragment Bundles

2014-03-26 Thread Richard S. Hall (JIRA)


[ 
https://issues.apache.org/jira/browse/FELIX-3701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13947935#comment-13947935
 ] 

Richard S. Hall commented on FELIX-3701:


Interesting. I can't say that I fully understand the situation and/or why it 
occurs, but if what you are saying is the case, then yes that would be 
problematic and needs to be fixed.

 Intermittent CNFE with embedded jars in Fragment Bundles
 

 Key: FELIX-3701
 URL: https://issues.apache.org/jira/browse/FELIX-3701
 Project: Felix
  Issue Type: Bug
  Components: Framework
Affects Versions: framework-4.0.2
Reporter: Chetan Mehrotra
Priority: Minor
 Attachments: debug info.jpg, fragment-bug.zip


 In our Sling based OSGi application we are observing intermittent 
 ClassNotFoundException for classes which are present in a jar embedded in 
 Fragment bundle. Below are the details about the scenario
 1. Host bundle BundleA com.day.crx.sling.server [52]
 2. It has two fragment bundles attached. 
 - FragBundle1 - com.day.crx.crx-auth-ldap
 - FragBundle2 - org.jcrutil.aws
 3. FragBundle2 - Has some embedded jars referred in the classpath
 - FragJar2-1 - aws-java-sdk-1.3.11.jar
 - FragJar2-2 - httpclient-4.2-beta1.jar
 4. There is a DS Component in BundleA which on activate tries to create an 
 instance of class which is present in FragJar2-1
 Now the issue is at times on clean start we get a CNFE at #4. On getting the 
 Felix debug logs following things were observed
 1. The logs report that INFO: Bundle BundleA [52] Class path entry not found: 
 FragJar2-1.jar
 2. The above entries are not observed if CNFE is not thrown
 3. If I try to debug the code the issue goes away which indicates that its 
 possible a race condition issue
 4. In case the issue is seen and I see the fragment bundle dir in the felix 
 folder the fragment jar is NOT exploded i.e. no bundle.jar-embedded directory
 5. Once the issue is seen it does not go away in restart
 6. The issue was not seen in 3.0.x releases
 7. If I flatten the jars present in fragment bundles the issue is not seen
 8. Exception seen is [1]
 [1]
 05.10.2012 12:03:19.362 *ERROR* [FelixStartLevel] com.day.crx.sling.server 
 [com.day.crx.sling.server.impl.jmx.ManagedRepository] The activate method has 
 thrown an exception (java.lang.NoClassDefFoundError: 
 com/amazonaws/services/s3/model/S3ObjectSummary) 
 java.lang.NoClassDefFoundError: 
 com/amazonaws/services/s3/model/S3ObjectSummary
   at java.lang.Class.forName0(Native Method)
   at java.lang.Class.forName(Class.java:247)
   at 
 org.apache.jackrabbit.core.config.SimpleBeanFactory.newInstance(SimpleBeanFactory.java:30)
   at 
 org.apache.jackrabbit.core.config.BeanConfig.newInstance(BeanConfig.java:191)
   at 
 org.apache.jackrabbit.core.config.RepositoryConfigurationParser$4.getDataStore(RepositoryConfigurationParser.java:997)
   at 
 org.apache.jackrabbit.core.config.RepositoryConfig.getDataStore(RepositoryConfig.java:1072)
   at 
 org.apache.jackrabbit.core.RepositoryImpl.init(RepositoryImpl.java:279)
   at com.day.crx.core.CRXRepositoryImpl.init(CRXRepositoryImpl.java:307)
   at com.day.crx.core.CRXRepositoryImpl.create(CRXRepositoryImpl.java:262)
   at com.day.crx.core.CRXRepositoryImpl.create(CRXRepositoryImpl.java:245)
   at 
 com.day.crx.sling.server.impl.jmx.ManagedRepository.activate(ManagedRepository.java:169)
   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:227)
   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:591)
   at 
 org.apache.felix.scr.impl.helper.BaseMethod.invoke(BaseMethod.java:472)
   at 
 org.apache.felix.scr.impl.helper.ActivateMethod.invoke(ActivateMethod.java:146)
   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.DelayedComponentManager.createRealComponent(DelayedComponentManager.java:95)
   at 
 org.apache.felix.scr.impl.manager.AbstractComponentManager$Registered.getService(AbstractComponentManager.java:1296)
   at

[jira] [Resolved] (FELIX-3701) Intermittent CNFE with embedded jars in Fragment Bundles

2014-03-26 Thread Richard S. Hall (JIRA)


 [ 
https://issues.apache.org/jira/browse/FELIX-3701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall resolved FELIX-3701.


Resolution: Fixed
  Assignee: Richard S. Hall

Ok, I've applied a patch to trunk to try to address this issue. Essentially, 
when we moved to R4.3 we used public API to calculate the set of attached 
fragments instead of internal API. However, the public API approach didn't 
necessarily return the fragments in the desired order. I added back an internal 
method to BundleWiringImpl to get the fragments, so now getFragments and 
getFragmentContents() should be parallel again. Please test and let me know if 
this resolves your issue. If so, close this bug. If not, reopen it. Thanks.

 Intermittent CNFE with embedded jars in Fragment Bundles
 

 Key: FELIX-3701
 URL: https://issues.apache.org/jira/browse/FELIX-3701
 Project: Felix
  Issue Type: Bug
  Components: Framework
Affects Versions: framework-4.0.2
Reporter: Chetan Mehrotra
Assignee: Richard S. Hall
Priority: Minor
 Fix For: framework-4.6.0

 Attachments: debug info.jpg, fragment-bug.zip


 In our Sling based OSGi application we are observing intermittent 
 ClassNotFoundException for classes which are present in a jar embedded in 
 Fragment bundle. Below are the details about the scenario
 1. Host bundle BundleA com.day.crx.sling.server [52]
 2. It has two fragment bundles attached. 
 - FragBundle1 - com.day.crx.crx-auth-ldap
 - FragBundle2 - org.jcrutil.aws
 3. FragBundle2 - Has some embedded jars referred in the classpath
 - FragJar2-1 - aws-java-sdk-1.3.11.jar
 - FragJar2-2 - httpclient-4.2-beta1.jar
 4. There is a DS Component in BundleA which on activate tries to create an 
 instance of class which is present in FragJar2-1
 Now the issue is at times on clean start we get a CNFE at #4. On getting the 
 Felix debug logs following things were observed
 1. The logs report that INFO: Bundle BundleA [52] Class path entry not found: 
 FragJar2-1.jar
 2. The above entries are not observed if CNFE is not thrown
 3. If I try to debug the code the issue goes away which indicates that its 
 possible a race condition issue
 4. In case the issue is seen and I see the fragment bundle dir in the felix 
 folder the fragment jar is NOT exploded i.e. no bundle.jar-embedded directory
 5. Once the issue is seen it does not go away in restart
 6. The issue was not seen in 3.0.x releases
 7. If I flatten the jars present in fragment bundles the issue is not seen
 8. Exception seen is [1]
 [1]
 05.10.2012 12:03:19.362 *ERROR* [FelixStartLevel] com.day.crx.sling.server 
 [com.day.crx.sling.server.impl.jmx.ManagedRepository] The activate method has 
 thrown an exception (java.lang.NoClassDefFoundError: 
 com/amazonaws/services/s3/model/S3ObjectSummary) 
 java.lang.NoClassDefFoundError: 
 com/amazonaws/services/s3/model/S3ObjectSummary
   at java.lang.Class.forName0(Native Method)
   at java.lang.Class.forName(Class.java:247)
   at 
 org.apache.jackrabbit.core.config.SimpleBeanFactory.newInstance(SimpleBeanFactory.java:30)
   at 
 org.apache.jackrabbit.core.config.BeanConfig.newInstance(BeanConfig.java:191)
   at 
 org.apache.jackrabbit.core.config.RepositoryConfigurationParser$4.getDataStore(RepositoryConfigurationParser.java:997)
   at 
 org.apache.jackrabbit.core.config.RepositoryConfig.getDataStore(RepositoryConfig.java:1072)
   at 
 org.apache.jackrabbit.core.RepositoryImpl.init(RepositoryImpl.java:279)
   at com.day.crx.core.CRXRepositoryImpl.init(CRXRepositoryImpl.java:307)
   at com.day.crx.core.CRXRepositoryImpl.create(CRXRepositoryImpl.java:262)
   at com.day.crx.core.CRXRepositoryImpl.create(CRXRepositoryImpl.java:245)
   at 
 com.day.crx.sling.server.impl.jmx.ManagedRepository.activate(ManagedRepository.java:169)
   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:227)
   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:591)
   at 
 org.apache.felix.scr.impl.helper.BaseMethod.invoke(BaseMethod.java:472)
   at 
 org.apache.felix.scr.impl.helper.ActivateMethod.invoke(ActivateMethod.java:146)
   at 
 org.apache.felix.scr.impl.manager.ImmediateComponentManager.createImplementationObject(ImmediateComponentManager.java:226)
   at

[jira] [Updated] (FELIX-3701) Intermittent CNFE with embedded jars in Fragment Bundles

2014-03-26 Thread Richard S. Hall (JIRA)


 [ 
https://issues.apache.org/jira/browse/FELIX-3701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall updated FELIX-3701:
---

Fix Version/s: framework-4.6.0

 Intermittent CNFE with embedded jars in Fragment Bundles
 

 Key: FELIX-3701
 URL: https://issues.apache.org/jira/browse/FELIX-3701
 Project: Felix
  Issue Type: Bug
  Components: Framework
Affects Versions: framework-4.0.2
Reporter: Chetan Mehrotra
Priority: Minor
 Fix For: framework-4.6.0

 Attachments: debug info.jpg, fragment-bug.zip


 In our Sling based OSGi application we are observing intermittent 
 ClassNotFoundException for classes which are present in a jar embedded in 
 Fragment bundle. Below are the details about the scenario
 1. Host bundle BundleA com.day.crx.sling.server [52]
 2. It has two fragment bundles attached. 
 - FragBundle1 - com.day.crx.crx-auth-ldap
 - FragBundle2 - org.jcrutil.aws
 3. FragBundle2 - Has some embedded jars referred in the classpath
 - FragJar2-1 - aws-java-sdk-1.3.11.jar
 - FragJar2-2 - httpclient-4.2-beta1.jar
 4. There is a DS Component in BundleA which on activate tries to create an 
 instance of class which is present in FragJar2-1
 Now the issue is at times on clean start we get a CNFE at #4. On getting the 
 Felix debug logs following things were observed
 1. The logs report that INFO: Bundle BundleA [52] Class path entry not found: 
 FragJar2-1.jar
 2. The above entries are not observed if CNFE is not thrown
 3. If I try to debug the code the issue goes away which indicates that its 
 possible a race condition issue
 4. In case the issue is seen and I see the fragment bundle dir in the felix 
 folder the fragment jar is NOT exploded i.e. no bundle.jar-embedded directory
 5. Once the issue is seen it does not go away in restart
 6. The issue was not seen in 3.0.x releases
 7. If I flatten the jars present in fragment bundles the issue is not seen
 8. Exception seen is [1]
 [1]
 05.10.2012 12:03:19.362 *ERROR* [FelixStartLevel] com.day.crx.sling.server 
 [com.day.crx.sling.server.impl.jmx.ManagedRepository] The activate method has 
 thrown an exception (java.lang.NoClassDefFoundError: 
 com/amazonaws/services/s3/model/S3ObjectSummary) 
 java.lang.NoClassDefFoundError: 
 com/amazonaws/services/s3/model/S3ObjectSummary
   at java.lang.Class.forName0(Native Method)
   at java.lang.Class.forName(Class.java:247)
   at 
 org.apache.jackrabbit.core.config.SimpleBeanFactory.newInstance(SimpleBeanFactory.java:30)
   at 
 org.apache.jackrabbit.core.config.BeanConfig.newInstance(BeanConfig.java:191)
   at 
 org.apache.jackrabbit.core.config.RepositoryConfigurationParser$4.getDataStore(RepositoryConfigurationParser.java:997)
   at 
 org.apache.jackrabbit.core.config.RepositoryConfig.getDataStore(RepositoryConfig.java:1072)
   at 
 org.apache.jackrabbit.core.RepositoryImpl.init(RepositoryImpl.java:279)
   at com.day.crx.core.CRXRepositoryImpl.init(CRXRepositoryImpl.java:307)
   at com.day.crx.core.CRXRepositoryImpl.create(CRXRepositoryImpl.java:262)
   at com.day.crx.core.CRXRepositoryImpl.create(CRXRepositoryImpl.java:245)
   at 
 com.day.crx.sling.server.impl.jmx.ManagedRepository.activate(ManagedRepository.java:169)
   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:227)
   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:591)
   at 
 org.apache.felix.scr.impl.helper.BaseMethod.invoke(BaseMethod.java:472)
   at 
 org.apache.felix.scr.impl.helper.ActivateMethod.invoke(ActivateMethod.java:146)
   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.DelayedComponentManager.createRealComponent(DelayedComponentManager.java:95)
   at 
 org.apache.felix.scr.impl.manager.AbstractComponentManager$Registered.getService(AbstractComponentManager.java:1296)
   at 
 org.apache.felix.scr.impl.manager.DelayedComponentManager.getService(DelayedComponentManager.java:88)
   at 
 org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:308)
   at

[jira] [Resolved] (FELIX-4425) Short command in Gogo Shell not working with Java 8

2014-03-25 Thread Richard S. Hall (JIRA)


 [ 
https://issues.apache.org/jira/browse/FELIX-4425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall resolved FELIX-4425.


   Resolution: Fixed
Fix Version/s: gogo.shell-0.12.0
 Assignee: Richard S. Hall

I applied your patch so it will be included in any future release, please close 
if satisfied.

 Short command in Gogo Shell not working with Java 8 
 

 Key: FELIX-4425
 URL: https://issues.apache.org/jira/browse/FELIX-4425
 Project: Felix
  Issue Type: Bug
  Components: Gogo Command
 Environment: Java 8
Reporter: Nicolas Roduit
Assignee: Richard S. Hall
 Fix For: gogo.shell-0.12.0


 The bug comes from the different interpretation of String.split() method in 
 line 474 of org.apache.felix.gogo.options.Options (in Gogo Shell).
 Here are the different results of the split method:
 String val = -k.substring(1).split();
 Java  8:
 val[0]=
 val[1]=k
 Java 8: 
 val[0]=k
 A simple fix can be an iteration of the characters instead of using split().



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (FELIX-4462) Classloader deadlock in Java6 between two bundles

2014-03-19 Thread Richard S. Hall (JIRA)


 [ 
https://issues.apache.org/jira/browse/FELIX-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall updated FELIX-4462:
---

Attachment: FELIX-4462.txt

I've attached a patch that tries to determine if we are using a parallel class 
loader or not. If so, it uses the class locks list as the lock object, if not, 
it uses the class loader itself as the lock object.

Please test this patch and see if it works. Thanks.

 Classloader deadlock in Java6 between two bundles
 -

 Key: FELIX-4462
 URL: https://issues.apache.org/jira/browse/FELIX-4462
 Project: Felix
  Issue Type: Bug
  Components: Framework
Affects Versions: framework-4.2.1
 Environment: MacOS 10.7.5, java version 1.6.0_65, Java(TM) SE 
 Runtime Environment (build 1.6.0_65-b14-462-11M4609), Java HotSpot(TM) 64-Bit 
 Server VM (build 20.65-b04-462, mixed mode)
Reporter: Stefan Egli
 Attachments: FELIX-4462.txt, suggested.synchronized.FELIX-4462.patch, 
 test.reproducingFELIX-4462.patch


 As discussed on the user list ([0]) there is a deadlock in Java 6 (if bug 
 4670071 [2] is not fixed). The problem is the hidden, implicit 
 ClassLoader.loadClassInternal which is is synchronized(this) in that case. 
 Consider the following scenario:
  * bundle 2 wants to load a class of bundle 1 - hence is not synchronized 
 with bundle 1's classloader - thus uses the m_classLocks locking mechanism to 
 lock bundle 1's classloader for the particular class being loaded. Then calls 
 defineClass (with bundle 1's classloader)
  * before it can do so, bundle 1 wants to load the same class (of bundle 1) - 
 hence does a synchronized loadClassInternal. then reaches the m_classLocks 
 locking mechanism and notices that there's another thread loading the class
 - this results in the deadlock reported.
 There's multiple fixes for this:
  * use Java 7
  * use -XX:+UnlockDiagnosticVMOptions -XX:+UnsyncloadClass
  * create a special Java 6 classloader (Java 7 would use the current one) 
 which does a plain synchronized findClass() - and replaces all 
 synchronized(m_classLocks) with synchronized(this)
 [0] http://markmail.org/thread/crwqzqobxgob7q3n
 [1] http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4670071



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (FELIX-4462) Classloader deadlock in Java6 between two bundles

2014-03-19 Thread Richard S. Hall (JIRA)


 [ 
https://issues.apache.org/jira/browse/FELIX-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall resolved FELIX-4462.


Resolution: Fixed
  Assignee: Richard S. Hall

Ok, great. I've applied the fix, so please close this issue if satisfied. 
Thanks.

 Classloader deadlock in Java6 between two bundles
 -

 Key: FELIX-4462
 URL: https://issues.apache.org/jira/browse/FELIX-4462
 Project: Felix
  Issue Type: Bug
  Components: Framework
Affects Versions: framework-4.2.1
 Environment: MacOS 10.7.5, java version 1.6.0_65, Java(TM) SE 
 Runtime Environment (build 1.6.0_65-b14-462-11M4609), Java HotSpot(TM) 64-Bit 
 Server VM (build 20.65-b04-462, mixed mode)
Reporter: Stefan Egli
Assignee: Richard S. Hall
 Attachments: FELIX-4462.txt, classLockMonitor.FELIX-4462.patch2, 
 suggested.synchronized.FELIX-4462.patch, test.reproducingFELIX-4462.patch


 As discussed on the user list ([0]) there is a deadlock in Java 6 (if bug 
 4670071 [2] is not fixed). The problem is the hidden, implicit 
 ClassLoader.loadClassInternal which is is synchronized(this) in that case. 
 Consider the following scenario:
  * bundle 2 wants to load a class of bundle 1 - hence is not synchronized 
 with bundle 1's classloader - thus uses the m_classLocks locking mechanism to 
 lock bundle 1's classloader for the particular class being loaded. Then calls 
 defineClass (with bundle 1's classloader)
  * before it can do so, bundle 1 wants to load the same class (of bundle 1) - 
 hence does a synchronized loadClassInternal. then reaches the m_classLocks 
 locking mechanism and notices that there's another thread loading the class
 - this results in the deadlock reported.
 There's multiple fixes for this:
  * use Java 7
  * use -XX:+UnlockDiagnosticVMOptions -XX:+UnsyncloadClass
  * create a special Java 6 classloader (Java 7 would use the current one) 
 which does a plain synchronized findClass() - and replaces all 
 synchronized(m_classLocks) with synchronized(this)
 [0] http://markmail.org/thread/crwqzqobxgob7q3n
 [1] http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4670071



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Reopened] (FELIX-4462) Classloader deadlock in Java6 between two bundles

2014-03-19 Thread Richard S. Hall (JIRA)


 [ 
https://issues.apache.org/jira/browse/FELIX-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall reopened FELIX-4462:



 Classloader deadlock in Java6 between two bundles
 -

 Key: FELIX-4462
 URL: https://issues.apache.org/jira/browse/FELIX-4462
 Project: Felix
  Issue Type: Bug
  Components: Framework
Affects Versions: framework-4.2.1
 Environment: MacOS 10.7.5, java version 1.6.0_65, Java(TM) SE 
 Runtime Environment (build 1.6.0_65-b14-462-11M4609), Java HotSpot(TM) 64-Bit 
 Server VM (build 20.65-b04-462, mixed mode)
Reporter: Stefan Egli
Assignee: Richard S. Hall
 Fix For: framework-4.4.0

 Attachments: FELIX-4462.txt, classLockMonitor.FELIX-4462.patch2, 
 suggested.synchronized.FELIX-4462.patch, test.reproducingFELIX-4462.patch


 As discussed on the user list ([0]) there is a deadlock in Java 6 (if bug 
 4670071 [2] is not fixed). The problem is the hidden, implicit 
 ClassLoader.loadClassInternal which is is synchronized(this) in that case. 
 Consider the following scenario:
  * bundle 2 wants to load a class of bundle 1 - hence is not synchronized 
 with bundle 1's classloader - thus uses the m_classLocks locking mechanism to 
 lock bundle 1's classloader for the particular class being loaded. Then calls 
 defineClass (with bundle 1's classloader)
  * before it can do so, bundle 1 wants to load the same class (of bundle 1) - 
 hence does a synchronized loadClassInternal. then reaches the m_classLocks 
 locking mechanism and notices that there's another thread loading the class
 - this results in the deadlock reported.
 There's multiple fixes for this:
  * use Java 7
  * use -XX:+UnlockDiagnosticVMOptions -XX:+UnsyncloadClass
  * create a special Java 6 classloader (Java 7 would use the current one) 
 which does a plain synchronized findClass() - and replaces all 
 synchronized(m_classLocks) with synchronized(this)
 [0] http://markmail.org/thread/crwqzqobxgob7q3n
 [1] http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4670071



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Closed] (FELIX-4462) Classloader deadlock in Java6 between two bundles

2014-03-19 Thread Richard S. Hall (JIRA)


 [ 
https://issues.apache.org/jira/browse/FELIX-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall closed FELIX-4462.
--

Resolution: Fixed

 Classloader deadlock in Java6 between two bundles
 -

 Key: FELIX-4462
 URL: https://issues.apache.org/jira/browse/FELIX-4462
 Project: Felix
  Issue Type: Bug
  Components: Framework
Affects Versions: framework-4.2.1
 Environment: MacOS 10.7.5, java version 1.6.0_65, Java(TM) SE 
 Runtime Environment (build 1.6.0_65-b14-462-11M4609), Java HotSpot(TM) 64-Bit 
 Server VM (build 20.65-b04-462, mixed mode)
Reporter: Stefan Egli
Assignee: Richard S. Hall
 Fix For: framework-4.4.0

 Attachments: FELIX-4462.txt, classLockMonitor.FELIX-4462.patch2, 
 suggested.synchronized.FELIX-4462.patch, test.reproducingFELIX-4462.patch


 As discussed on the user list ([0]) there is a deadlock in Java 6 (if bug 
 4670071 [2] is not fixed). The problem is the hidden, implicit 
 ClassLoader.loadClassInternal which is is synchronized(this) in that case. 
 Consider the following scenario:
  * bundle 2 wants to load a class of bundle 1 - hence is not synchronized 
 with bundle 1's classloader - thus uses the m_classLocks locking mechanism to 
 lock bundle 1's classloader for the particular class being loaded. Then calls 
 defineClass (with bundle 1's classloader)
  * before it can do so, bundle 1 wants to load the same class (of bundle 1) - 
 hence does a synchronized loadClassInternal. then reaches the m_classLocks 
 locking mechanism and notices that there's another thread loading the class
 - this results in the deadlock reported.
 There's multiple fixes for this:
  * use Java 7
  * use -XX:+UnlockDiagnosticVMOptions -XX:+UnsyncloadClass
  * create a special Java 6 classloader (Java 7 would use the current one) 
 which does a plain synchronized findClass() - and replaces all 
 synchronized(m_classLocks) with synchronized(this)
 [0] http://markmail.org/thread/crwqzqobxgob7q3n
 [1] http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4670071



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (FELIX-4462) Classloader deadlock in Java6 between two bundles

2014-03-19 Thread Richard S. Hall (JIRA)


 [ 
https://issues.apache.org/jira/browse/FELIX-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall updated FELIX-4462:
---

Fix Version/s: framework-4.4.0

 Classloader deadlock in Java6 between two bundles
 -

 Key: FELIX-4462
 URL: https://issues.apache.org/jira/browse/FELIX-4462
 Project: Felix
  Issue Type: Bug
  Components: Framework
Affects Versions: framework-4.2.1
 Environment: MacOS 10.7.5, java version 1.6.0_65, Java(TM) SE 
 Runtime Environment (build 1.6.0_65-b14-462-11M4609), Java HotSpot(TM) 64-Bit 
 Server VM (build 20.65-b04-462, mixed mode)
Reporter: Stefan Egli
Assignee: Richard S. Hall
 Fix For: framework-4.4.0

 Attachments: FELIX-4462.txt, classLockMonitor.FELIX-4462.patch2, 
 suggested.synchronized.FELIX-4462.patch, test.reproducingFELIX-4462.patch


 As discussed on the user list ([0]) there is a deadlock in Java 6 (if bug 
 4670071 [2] is not fixed). The problem is the hidden, implicit 
 ClassLoader.loadClassInternal which is is synchronized(this) in that case. 
 Consider the following scenario:
  * bundle 2 wants to load a class of bundle 1 - hence is not synchronized 
 with bundle 1's classloader - thus uses the m_classLocks locking mechanism to 
 lock bundle 1's classloader for the particular class being loaded. Then calls 
 defineClass (with bundle 1's classloader)
  * before it can do so, bundle 1 wants to load the same class (of bundle 1) - 
 hence does a synchronized loadClassInternal. then reaches the m_classLocks 
 locking mechanism and notices that there's another thread loading the class
 - this results in the deadlock reported.
 There's multiple fixes for this:
  * use Java 7
  * use -XX:+UnlockDiagnosticVMOptions -XX:+UnsyncloadClass
  * create a special Java 6 classloader (Java 7 would use the current one) 
 which does a plain synchronized findClass() - and replaces all 
 synchronized(m_classLocks) with synchronized(this)
 [0] http://markmail.org/thread/crwqzqobxgob7q3n
 [1] http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4670071



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (FELIX-4190) The framework should not hold any lock while calling ServiceFactory#unget

2014-03-11 Thread Richard S. Hall (JIRA)


[ 
https://issues.apache.org/jira/browse/FELIX-4190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13930291#comment-13930291
 ] 

Richard S. Hall commented on FELIX-4190:


I believe duplicating the loop would work. The first loop tries to be friendly, 
then the call to invalidate() makes it impossible to get the service object 
again, and then finally the second loop deals more harshly with clients who 
won't let go.

 The framework should not hold any lock while calling ServiceFactory#unget
 -

 Key: FELIX-4190
 URL: https://issues.apache.org/jira/browse/FELIX-4190
 Project: Felix
  Issue Type: Bug
  Components: Framework
Reporter: Guillaume Nodet
Assignee: Guillaume Nodet
 Fix For: framework-4.4.0






--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (FELIX-4355) [Core R5] org.osgi.test.cases.framework.launch OSGi CT test failure

2014-01-20 Thread Richard S. Hall (JIRA)


[ 
https://issues.apache.org/jira/browse/FELIX-4355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13876853#comment-13876853
 ] 

Richard S. Hall commented on FELIX-4355:


This failure appears to result from the fact that the Felix framework assumes 
the extension directive is mandatory for extension bundles, but the R5 CT now 
appears to treat it as optional with a default value of framework. Trying to 
determine if this is a spec change or CT error.

 [Core R5] org.osgi.test.cases.framework.launch OSGi CT test failure
 ---

 Key: FELIX-4355
 URL: https://issues.apache.org/jira/browse/FELIX-4355
 Project: Felix
  Issue Type: Bug
  Components: Framework
Reporter: David Bosschaert
 Fix For: framework-4.4.0


 The org.osgi.test.cases.framework.launch OSGi CT test suite has 1 test 
 failure:
 org.osgi.test.cases.framework.launch.junit.ExtensionBundleTests
 testFrameworkExtensionDefault(org.osgi.test.cases.framework.launch.junit.ExtensionBundleTests)
 junit.framework.AssertionFailedError: expected framework extension bundle to 
 be resolved
   at junit.framework.Assert.fail(Assert.java:47)
   at junit.framework.Assert.assertTrue(Assert.java:20)
   at 
 org.osgi.test.cases.framework.launch.junit.ExtensionBundleTests.testFrameworkExtensionDefault(ExtensionBundleTests.java:169)
   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 junit.framework.TestCase.runTest(TestCase.java:164)
   at junit.framework.TestCase.runBare(TestCase.java:130)
   at junit.framework.TestResult$1.protect(TestResult.java:106)
   at junit.framework.TestResult.runProtected(TestResult.java:124)
   at junit.framework.TestResult.run(TestResult.java:109)
   at junit.framework.TestCase.run(TestCase.java:120)
   at junit.framework.TestSuite.runTest(TestSuite.java:230)
   at junit.framework.TestSuite.run(TestSuite.java:225)
   at junit.framework.TestSuite.runTest(TestSuite.java:230)
   at junit.framework.TestSuite.run(TestSuite.java:225)
   at aQute.junit.Activator.test(Activator.java:226)
   at aQute.junit.Activator.automatic(Activator.java:118)
   at aQute.junit.Activator.run(Activator.java:59)



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (FELIX-4355) [Core R5] org.osgi.test.cases.framework.launch OSGi CT test failure

2014-01-20 Thread Richard S. Hall (JIRA)


 [ 
https://issues.apache.org/jira/browse/FELIX-4355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall resolved FELIX-4355.


Resolution: Fixed
  Assignee: Richard S. Hall

I've modified the manifest parser to assume framework is the default for the 
extension directive in the Fragment-Host header of extension bundles. It is 
not clear if this was specifically agreed upon during the spec process, but 
we've agreed that it is reasonable and will clarify it in the spec. Please 
close if satisfied.

 [Core R5] org.osgi.test.cases.framework.launch OSGi CT test failure
 ---

 Key: FELIX-4355
 URL: https://issues.apache.org/jira/browse/FELIX-4355
 Project: Felix
  Issue Type: Bug
  Components: Framework
Reporter: David Bosschaert
Assignee: Richard S. Hall
 Fix For: framework-4.4.0


 The org.osgi.test.cases.framework.launch OSGi CT test suite has 1 test 
 failure:
 org.osgi.test.cases.framework.launch.junit.ExtensionBundleTests
 testFrameworkExtensionDefault(org.osgi.test.cases.framework.launch.junit.ExtensionBundleTests)
 junit.framework.AssertionFailedError: expected framework extension bundle to 
 be resolved
   at junit.framework.Assert.fail(Assert.java:47)
   at junit.framework.Assert.assertTrue(Assert.java:20)
   at 
 org.osgi.test.cases.framework.launch.junit.ExtensionBundleTests.testFrameworkExtensionDefault(ExtensionBundleTests.java:169)
   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 junit.framework.TestCase.runTest(TestCase.java:164)
   at junit.framework.TestCase.runBare(TestCase.java:130)
   at junit.framework.TestResult$1.protect(TestResult.java:106)
   at junit.framework.TestResult.runProtected(TestResult.java:124)
   at junit.framework.TestResult.run(TestResult.java:109)
   at junit.framework.TestCase.run(TestCase.java:120)
   at junit.framework.TestSuite.runTest(TestSuite.java:230)
   at junit.framework.TestSuite.run(TestSuite.java:225)
   at junit.framework.TestSuite.runTest(TestSuite.java:230)
   at junit.framework.TestSuite.run(TestSuite.java:225)
   at aQute.junit.Activator.test(Activator.java:226)
   at aQute.junit.Activator.automatic(Activator.java:118)
   at aQute.junit.Activator.run(Activator.java:59)



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (FELIX-4388) Initial start level not considered when bundle.start() is called

2014-01-15 Thread Richard S. Hall (JIRA)


 [ 
https://issues.apache.org/jira/browse/FELIX-4388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall updated FELIX-4388:
---

Priority: Minor  (was: Major)

 Initial start level not considered when bundle.start() is called
 

 Key: FELIX-4388
 URL: https://issues.apache.org/jira/browse/FELIX-4388
 Project: Felix
  Issue Type: Bug
  Components: Framework
Affects Versions: framework-4.2.0
Reporter: Carsten Ziegeler
Priority: Minor
 Fix For: framework-4.4.0


 If a start level service is available, and the initial start level is set to 
 a higher level than the current one, a call to bundle.start() of a bundle 
 which has no start level defined, results in the bundle being immediately 
 started.
 However, according to the spec it should only be started when the initial 
 start level is reached.
 I think this is a bug in BundleImpl as it is returning -1 if no start level 
 is set for the bundle instead of the default level. This patch should fix 
 this:
 Index: src/main/java/org/apache/felix/framework/BundleImpl.java
 ===
 --- src/main/java/org/apache/felix/framework/BundleImpl.java  (Revision 
 1558397)
 +++ src/main/java/org/apache/felix/framework/BundleImpl.java  (Arbeitskopie)
 @@ -861,7 +861,12 @@
  {
  try
  {
 -return m_archive.getStartLevel();
 +int level = m_archive.getStartLevel();
 +if ( level == -1 )
 +{
 +level = defaultLevel;
 +}
 +return level;
  }
  catch (Exception ex)
  {



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (FELIX-4388) Initial start level not considered when bundle.start() is called

2014-01-15 Thread Richard S. Hall (JIRA)


[ 
https://issues.apache.org/jira/browse/FELIX-4388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13872453#comment-13872453
 ] 

Richard S. Hall commented on FELIX-4388:


Yes, I think you are correct. This code used to be correct back in the day were 
we had separate files in the bundle cache for a saved start level. In that 
case, if the bundle didn't have a set start level, then it would get an 
exception when it tried to open the file. A while ago we switched to a single 
file for all bundle persisted information which breaks the existing logic.

 Initial start level not considered when bundle.start() is called
 

 Key: FELIX-4388
 URL: https://issues.apache.org/jira/browse/FELIX-4388
 Project: Felix
  Issue Type: Bug
  Components: Framework
Affects Versions: framework-4.2.0
Reporter: Carsten Ziegeler
Priority: Minor
 Fix For: framework-4.4.0


 If a start level service is available, and the initial start level is set to 
 a higher level than the current one, a call to bundle.start() of a bundle 
 which has no start level defined, results in the bundle being immediately 
 started.
 However, according to the spec it should only be started when the initial 
 start level is reached.
 I think this is a bug in BundleImpl as it is returning -1 if no start level 
 is set for the bundle instead of the default level. This patch should fix 
 this:
 Index: src/main/java/org/apache/felix/framework/BundleImpl.java
 ===
 --- src/main/java/org/apache/felix/framework/BundleImpl.java  (Revision 
 1558397)
 +++ src/main/java/org/apache/felix/framework/BundleImpl.java  (Arbeitskopie)
 @@ -861,7 +861,12 @@
  {
  try
  {
 -return m_archive.getStartLevel();
 +int level = m_archive.getStartLevel();
 +if ( level == -1 )
 +{
 +level = defaultLevel;
 +}
 +return level;
  }
  catch (Exception ex)
  {



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

1 2 3 4 5 6 7 8 9 10 >

1 - 100 of 2170 matches

Mail list logo