Re: Work starting for SRC R8 implementation

Hopefully that's SCR... ;-) On 10/8/20 1:45 PM, Thomas Watson wrote: Hi, I have started a branch (srcR8) where ongoing work will be done to implement the future OSGi R8 Declarative Services spec updates. Apache Felix SCR implementation will remain the reference implementation for the

Re: [VOTE] Accept the Atomos contribution

+1 -> richard On 1/29/20 4:40 PM, Karl Pauls wrote: I think the discussion of the "Atomos" contribution (https://github.com/tjwatson/atomos) by Thomas Watson has died down by now. It looks like there is quite some interest in the idea and assuming that the OSGI R8 Core specification will

Re: [DISCUSS] Contribute Atomos to Apache Felix

Sounds reasonable to me. -> richard On 1/23/20 10:08 AM, Thomas Watson wrote: Hi, The OSGI R8 Core specification is currently being worked on by the OSGi Alliance. One of the proposals is to add something called OSGi Connect to the Core Framework specification [1] [2]. This specification

Re: Showing commits on JIRA issues

the commit in the issue's activity log... On 1/25/19 09:43 , Jean-Baptiste Onofré wrote: Hi Richard, good question, it's possible to be related to a change made by INFRA. It's worth to create a Jira at INFRA IMHO. Regards JB On 25/01/2019 15:35, Richard S. Hall wrote: Hey everyone, Back in the old da

Showing commits on JIRA issues

Hey everyone, Back in the old days we used to be able to see associated commits on a JIRA issue if we included the JIRA issue number in the commit message. I recently wanted to check on the diff of a commit for one of Karl's commits on FELIX-6035 where he did reference the issue number in the

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

[ 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 "B

Re: [VOTE] Apache Felix Framework 6.0.0 and related subproject releases

+1 On 7/3/18 11:03 , Karl Pauls wrote: I would like to call a vote on the following subproject releases: resolver 2.0.0 framework 6.0.0 main 6.0.0 main.distribution 6.0.0 The main changelogs are in jira and at:

Re: osgi.to.logback

Yeah, something like those probably make more sense, otherwise for consistency it would have to be something like "logbackbackend", which doesn't really roll off the tongue. On 5/21/18 16:41 , Karl Pauls wrote: Hm, not sure I like that name too much. It seems to be potentially somewhat

Re: Proposal to donate the system readiness check framework to Apache Felix

The question to answer is whether it would be worthwhile "as is" to be donated to Apache Felix as a starting point? If so, figuring out ways to improve it can happen after the fact. If not, then there isn't much else to discuss. -> richard On 4/17/18 08:53 , Neil Bartlett wrote: I like the

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

[ 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

Re: FELIX-5782

Clearly, this will only be of interest to a very small number of people, but that's probably also true of the resolver API in general. Regardless, the patch itself seems reasonably harmless, so I don't have any technical issues with it as an implementation detail. In general, though, we try

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

[ 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

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

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

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

[ 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

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

[ 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

Re: memory visibility of @Reference service references

On 5/2/17 19:41 , Richard S. Hall wrote: Resending to the mailing list... On 5/2/17 18:55 , Dirk Hogan wrote: Hi Richard- I have a embedded jetty OSGi component that exposes the conglomeration of OSGi services to the outside world. Felix would need to set these service references in a thread

Reply-To

Did the reply-to change for our mailing lists? Before when I would reply to a message it would go to the list, now it goes to the sender. Was this a change on the list or a change in my email client? -> richard

Re: memory visibility of @Reference service references

could provide an answer to my original question. I may well have my answer. Thanks Dirk On Tue, May 2, 2017 at 2:29 PM, Richard S. Hall <he...@ungoverned.org> wrote: Dirk, Allow I'm not well versed on the details of JMM. I think this boils down to typical OSGi component code will be

Re: memory visibility of @Reference service references

ean to be contentious, and there is nothing preventing me from declaring my @References volatile. I just was hoping that there was JMM-knowledge active in this forum which could provide an answer to my original question. I may well have my answer. Thanks Dirk On Tue, May 2, 2017 at 2:29 PM, Richar

Re: memory visibility of @Reference service references

Dirk, Allow I'm not well versed on the details of JMM. I think this boils down to typical OSGi component code will be going through the hidden barriers in the the framework when they try to retrieve and access the service objects. You appear to be concocting a situation where you have threads

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

[ https://issues.apache.org/jira/browse/FELIX-5573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15889029#comment-15889029 ] Richard S. Hall commented on FELIX-5573: Rightly or wrongly, we explicitly chose to return null

Re: Implementation of unreleased spec and community

On 1/20/17 05:42 , Guillaume Nodet wrote: 2017-01-20 11:26 GMT+01:00 Neil Bartlett : On 20 Jan 2017, at 10:12, Guillaume Nodet wrote: 2017-01-20 10:58 GMT+01:00 Guillaume Nodet >: 2017-01-19 19:36 GMT+01:00

Re: Implementation of unreleased spec and community

e of action. -> richard Guillaume 2017-01-18 21:52 GMT+01:00 Richard S. Hall <he...@ungoverned.org>: On 1/18/17 15:28 , Guillaume Nodet wrote: 2017-01-18 20:23 GMT+01:00 Richard S. Hall <he...@ungoverned.org>: On 1/18/17 14:06 , Guillaume Nodet wrote: Let's take a

Re: Implementation of unreleased spec and community

On 1/18/17 15:28 , Guillaume Nodet wrote: 2017-01-18 20:23 GMT+01:00 Richard S. Hall <he...@ungoverned.org>: On 1/18/17 14:06 , Guillaume Nodet wrote: Let's take a clearer example, as I have a feeling I'm still not understood correctly. My problem is definitely not th

Re: Implementation of unreleased spec and community

On 1/18/17 14:06 , Guillaume Nodet wrote: Let's take a clearer example, as I have a feeling I'm still not understood correctly. My problem is definitely not the fact that there is an implementation based on an unreleased spec or RFC (as my email title seemed to indicate). If a committer comes

Re: Implementation of unreleased spec and community

On 1/18/17 08:55 , Guillaume Nodet wrote: 2017-01-18 14:29 GMT+01:00 Richard S. Hall <he...@ungoverned.org>: On 1/18/17 08:22 , Guillaume Nodet wrote: 2017-01-18 13:53 GMT+01:00 Carsten Ziegeler <cziege...@apache.org>: Whoever is doing the RI does it somewhere else and mig

Re: Implementation of unreleased spec and community

On 1/18/17 08:22 , Guillaume Nodet wrote: 2017-01-18 13:53 GMT+01:00 Carsten Ziegeler : Whoever is doing the RI does it somewhere else and might do a code contribution or not. Yes, that definitely would avoid the problem. And I don't think it changes anything from the

Re: Proposal for slight amendment to Felix provisional OSGi API policy

On 1/3/17 11:59 , David Bosschaert wrote: Hi Felix and Richard, On 3 January 2017 at 16:40, Richard S. Hall <he...@ungoverned.org> wrote: On 1/3/17 11:21 , Felix Meschberger wrote: Hi Upfront I like the amended proposal of using a version < 1 and a mandatory attribute „pr

Re: Proposal for slight amendment to Felix provisional OSGi API policy

Hi Richard, On 23 December 2016 at 19:19, Richard S. Hall <he...@ungoverned.org> wrote: I'm not for changing the policy. The whole point behind the policy is that anything that we released is in some way blessed and lives forever. If we release packages in the OSGi namespace, they look officia

Re: Proposal for slight amendment to Felix provisional OSGi API policy

I'm not for changing the policy. The whole point behind the policy is that anything that we released is in some way blessed and lives forever. If we release packages in the OSGi namespace, they look official even potentially after the OSGi Alliance dumps an RFC (ala Gogo). There is no way for

Re: [DISCUSS] Release new gogo runtime / jline bundles

On 10/4/16 04:13 , Guillaume Nodet wrote: 2016-10-04 9:16 GMT+02:00 David Bosschaert : Hi Guillaume, Does gogo-runtime have a dependency on gogo-jline or will it work without? Just trying to understand what Java 7 users will be able to do/are missing without

Re: [DISCUSS] Persistent wiring framework

On 10/3/16 12:02 , Guillaume Nodet wrote: I have a use case where the wiring is a bit complicated. Karaf uses the felix resolver to compute the full wiring and then applies it. At this point, all the bundles are resolved and started correctly. If Karaf is restarted, the framework restarts and

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

[ https://issues.apache.org/jira/browse/FELIX-5329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15428833#comment-15428833 ] Richard S. Hall commented on FELIX-5329: I guess this is more complicated for Java 9 since

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

[ https://issues.apache.org/jira/browse/FELIX-5329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall updated FELIX-5329: --- Summary: [Framework] Fix Java 8 packages and add Java 9 packages in default.properties

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

[ 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

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

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

Re: Some ideas for improvements in resolver

On 5/11/16 10:10 , Christian Schneider wrote: On 11.05.2016 15:52, Jean-Baptiste Onofré wrote: Hi Christian, About 1/, the spec classes will be embedded in the resolver bundle anyway ? It is not about removing the embedding. This is fine. It is more about keeping the spec sources in one

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

[ 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

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

[ 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

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

[ 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

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

[ 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

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

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

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

[ 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

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

[ 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

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

[ 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

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

[ 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

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

[ 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

Re: Git dies of lack of interest?

> On Dec 1, 2015, at 19:14, Benson Margulies <bimargul...@gmail.com> wrote: > > On Dec 1, 2015 6:43 PM, "Richard S. Hall" <he...@ungoverned.org> wrote: >> >> >>> On Dec 1, 2015, at 17:50, Benson Margulies <bimargul...@gmail.com> > w

Re: Git dies of lack of interest?

there is a better way to handle such issues? -> richard > > > On Tue, Dec 1, 2015 at 1:56 PM, Richard S. Hall <he...@ungoverned.org> wrote: >> On 12/1/15 13:40 , Carsten Ziegeler wrote: >>> >>> Richard S. Hall wrote >>>> >>>> We

Re: Git dies of lack of interest?

On 12/1/15 12:57 , Carsten Ziegeler wrote: Marcel Offermans wrote Let me speak for myself here, I don’t see compelling arguments for moving to Git. What problem are we solving here? Why is moving to Git the right solution? That’s where my lack of enthusiasm comes from. Nobody has yet

Re: Git dies of lack of interest?

On 12/1/15 13:40 , Carsten Ziegeler wrote: Richard S. Hall wrote Well, the argument to the contrary is perhaps that is makes it more difficult for us as a community to have oversight into releases. It almost assures us that some/many community members will never checkout subprojects that aren't

Re: git?

I have no idea how it impacts anything, but keep in mind that framework releases regularly (and generally) include more than one subproject. I don't know how it complicates anything, just wanting to point it out. In other words, it would be nice if those pushing this make sure they work out

Re: git?

Simon, You do realize that in Subversion you can just checkout a given subproject, create a patch against it, then delete it, right? -> richard On 10/27/15 15:52 , Simon Chemouil wrote: Benson Margulies wrote: There was some discussion a while back about git, which I recall (perhaps

Re: git?

> On Oct 27, 2015, at 18:06, Simon Chemouil <schemo...@gmail.com> wrote: > > Richard S. Hall a écrit le 27/10/2015 21:22 : >> Simon, >> >> You do realize that in Subversion you can just checkout a given >> subproject, create a patch against it, then de

Re: I'd like to be a committer

On 10/15/15 14:59 , Benson Margulies wrote: JB, I realize that I'm being a bit harsh. Felix hasn't voted in a new committer since 2014, Ha! Shows what you know, we added a new committer in August! :-P and I get no response to patches unless I whine over and over on the mailing list. So, I

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

[ 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

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

[ 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

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

[ 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

Re: Bug fixes - commit to repo or patch?

If you are uncertain about your patch or just want to find a second pair of eyes, you can always open an issue (or an existing one) in the tracker and attach your patch to it to solicit feedback. If you don't hear any objections after a few days, just go ahead and commit it. -> richard On

Re: Move org.osgi.* modules to attic?

On 8/1/15 05:47 , Carsten Ziegeler wrote: Am 29.07.15 um 14:32 schrieb Richard S. Hall: On 7/29/15 02:31 , Carsten Ziegeler wrote: Hi, we have modules for R4 of org.osgi.core, org.osgi.compendium and org.osgi.foundation. As these are officially available in the maven repo, I guess we can get

Re: Move org.osgi.* modules to attic?

On 7/29/15 02:31 , Carsten Ziegeler wrote: Hi, we have modules for R4 of org.osgi.core, org.osgi.compendium and org.osgi.foundation. As these are officially available in the maven repo, I guess we can get rid of those. If no one objects, I'll remove them from trunk I think that's fine. We

Re: [HEADS UP] Resolver optimizations

On 6/26/15 10:15 , David Bosschaert wrote: Looks like a great piece of work, Guillaume. I left some minor thoughts in a few places on github. One potential concern is that the change to depth-first search will produce different results than the previous approach. I wouldn't worry too much

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

[ 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

Re: [DISCUSS] Release Felix framework next version

On 4/17/15 07:26 , Guillaume Nodet wrote: I think we're good to go. Does this also mean that we need to release a new version of the resolver since the framework uses it and it has a dependency on a resolver snapshot? - richard Cheers, Guillaume Nodet 2015-04-13 19:40 GMT+02:00 Karl

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

[ 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

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

[ 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

Re: [DISCUSS] Release Felix framework next version

think we should include the patch... - richard On Fri, Apr 17, 2015 at 3:03 PM, Richard S. Hall he...@ungoverned.org wrote: On 4/17/15 07:26 , Guillaume Nodet wrote: I think we're good to go. Does this also mean that we need to release a new version of the resolver since the framework uses

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

[ 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

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

[ 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

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

[ 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

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

[ 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

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

[ 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

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

[ 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

Re: [Framework] ServiceRegistry.getService() endless loop with lock?

...@apache.org: Am 23.03.15 um 01:25 schrieb Richard S. Hall: On 3/21/15 05:52 , Carsten Ziegeler wrote: Question remains, why the thread got interrupted in the first place. It was something that you did as part of FELIX-4806: Yes, I noticed this as well - and I have no idea why I did it. I know that I

Re: Service Registry refactor using Java-5 concurrency libraries (Was Re: [Framework] ServiceRegistry.getService() endless loop with lock?)

On 3/23/15 10:17 , David Bosschaert wrote: On 23 March 2015 at 13:39, Richard S. Hall he...@ungoverned.org wrote: On 3/23/15 03:55 , Guillaume Nodet wrote: There's a call to interrupt() in Felix#acquireBundleLock(), not sure if it can be the culprit though. Interrupts could also be caused

Re: [Framework] ServiceRegistry.getService() endless loop with lock?

On 3/21/15 05:52 , Carsten Ziegeler wrote: Am 20.03.15 um 18:41 schrieb David Bosschaert: Some more thoughts about this... The wait() call in the getService() method is as follows: synchronized (this) { // First make sure that no existing operation is currently

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

[ 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

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

[ 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

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

[ 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

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

[ 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

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

[ 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

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

[ 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

Re: Native CT Tests passing

On 12/18/14 18:05 , Bob Paulin wrote: All, I resolved the rest of the native code CT test failures in https://issues.apache.org/jira/browse/FELIX-4729. So looks like we're getting close to being ready for R6. Please let me know if there is any feedback on the implementation. A couple of

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

[ 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

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

[ 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

Re: Native Selection Filters matching in Native Namespace

On 12/14/14 23:24 , Bob Paulin wrote: Per the R6 Spec selection filters should be able to match launching properties (p 75). This works fine within the matching the is currently happening within R4LibraryClause.match() method. However since we're now deriving a Require-Capability (p 73 - 74)

Re: Native Selection Filters matching in Native Namespace

On 12/15/14 08:44 , Bob Paulin wrote: Responses inline. On 12/15/2014 7:20 AM, Richard S. Hall wrote: On 12/14/14 23:24 , Bob Paulin wrote: Per the R6 Spec selection filters should be able to match launching properties (p 75). This works fine within the matching the is currently happening

Re: OSGi R6 Native Code Namespace Aliases

On 12/12/14 13:44 , Bob Paulin wrote: Currently working on getting the OSGi R6 tests related to Native Code. The tests failures that I'm working through start with the name testNativeCode. The tests are failing on a org.osgi.framework.Filter.matches() call between a raw map of Native

Re: OSGi R6 Native Code Namespace Aliases

, then I would think it would use an list type for the values of osname and processor than contained all known aliases. If, on the other hand, macPPC is being created directly in the CT, then I don't see how it would work. - richard - Bob On 12/12/2014 1:32 PM, Richard S. Hall wrote: On 12

Re: OSGi R6 Native Code Namespace Aliases

On 12/12/2014 2:15 PM, Richard S. Hall wrote: On 12/12/14 15:00 , Bob Paulin wrote: Hi Richard, Here's an approximation of what the CT code is doing: //First we get the native requirement for filters String filterDirective = ((osgi.native.osname~=mac os x)(osgi.native.processor~=powerpc

Re: OSGi R6 Native Code Namespace Aliases

On 12/12/14 15:27 , Richard S. Hall wrote: On 12/12/14 15:00 , Bob Paulin wrote: Hi Richard, Here's an approximation of what the CT code is doing: //First we get the native requirement for filters String filterDirective = ((osgi.native.osname~=mac os x)(osgi.native.processor~=powerpc

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

[ 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

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

[ 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

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

[ 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

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

[ 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

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

[ 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

Re: Improve Service Access (FELIX-4692)

On 11/12/14 09:17 , Felix Meschberger wrote: Hi I have created a patch to improve the Service Access time. With this patch applied I measure 4-5 times faster access to the service registry in our application which in general access services simply by its name and almost never uses a filter.

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

[ 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

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

[ 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

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

[ 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

  1   2   3   4   5   6   7   8   9   10   >