[jira] [Commented] (FELIX-6431) Add toggle to change passwords visibility

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on FELIX-6431:


There might be a misunderstanding here, I think what [~olli] wants is to be 
able to mark some configuration entries, such as a property named 
{{{}thisIsNotAPassword{}}}, as _not_ being actual passwords so _not_ needing 
special treatment. Without changing how configuration parameters which need the 
special "it's a password" treatment are handled.
I don't have suggestions for the implementation, just wanted to make sure 
people are on the same wavelength.

> Add toggle to change passwords visibility
> -
>
> Key: FELIX-6431
> URL: https://issues.apache.org/jira/browse/FELIX-6431
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Affects Versions: webconsole-4.6.2
>Reporter: Oliver Lietz
>Priority: Major
>
> The heuristic reenabled in FELIX-6428 is very simple and all values where the 
> field name contains {{password}} will be masked.
>  {{input}} {{type}} of "password" fields needs to be {{password}} and 
> {{input}} {{value}} needs to be the original (not obfuscated) value.
> Toggle {{input}} {{type}} with JavaScript from {{password}} to {{text}} and 
> back to show/hide {{value}}.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

Re: Putting subproject docs in the code repos

[Bertrand Delacretaz]

On Tue, Jul 27, 2021 at 10:50 AM Carsten Ziegeler  wrote:
> ...I prefer having the docs of a subproject directly within git as this
> makes updates that involve code and docs much easier (a single PR)...

I also like that option as long as all modules are discoverable from
the main website.

For Sling and its more than 300 modules we have
https://sling.apache.org/repolist.html which lists all modules on a
single page.

-Bertrnad

Re: [Website] Docs near subprojects experiment

[Bertrand Delacretaz]

On Fri, Sep 4, 2020 at 9:18 PM David Jencks  wrote:
> ...Multiple pages.  IIUC there can only be one README, but some subprojects 
> have extensive documentation.
> I suggest that for such subprojects, we consider moving the documentation to 
> the subproject and having a
> short non-copied README.adoc pointing to the website

FWIW we have a similar problem in Sling and what seems to be working
well is to make sure each module is discoverable from the
sling.apache.org website, even if their docs are not on the website.

For some modules this means having a brief description on the website
that just links to more info, like
https://sling.apache.org/documentation/bundles/graphql-core.html

Also, in some cases this means using GitHub queries as links to all
repositories that belong to a given subproject, like
https://github.com/search?q=topic%3Asling+topic%3Aosgi-feature-model+topic%3Aosgi+org%3Aapache=Repositories

-Bertrand

Re: Why do the docs claim a DEPENDENCIES file is needed?

[Bertrand Delacretaz]

Hi,

On Fri, Sep 4, 2020 at 3:05 AM David Jencks  wrote:
>
> https://felix.apache.org/documentation/development/dependencies-file-template.html
>  claims that each
> released software archive (what is that? source? compiled? ???) must contain a
> “DEPENDENCIES” file

http://apache.org/legal/release-policy.html only requires LICENSE and
NOTICE but does not mention a DEPENDENCIES file.

I think the relevant part of that page is

>>  When a package bundles code under several licenses, the LICENSE file MUST 
>> contain
>> details of all these licenses.

So if something's bundled in an Apache Release (that is, a source code
release) that has impact on the LICENSE file but I agree that
DEPENDENCIES is not required.

-Bertrand

Re: Your project website

[Bertrand Delacretaz]

Hi,

On Tue, Aug 4, 2020 at 6:30 PM Raymond Auge
 wrote:
> ...So far the Apache Aries project seems to be leaning toward choosing Antora
> [1] for choice of static site building tool...

I'm not really active in Felix so I'll let the PMC or whoever does the
work decide.

However, as per [2] it looks like Antora supports only Asciidoc as its
input format, whereas the current Felix site content is in Markdown.

This *might* represent more conversion work - however there are
various flavors of Markdown, so even staying in that format will
require some conversion work as well. For Sling we migrated from the
Apache CMS to Jbake [3] and a number of things required fixing, even
though we used Markdown in both cases.

-Bertrand

[1] https://docs.antora.org/antora/2.3/
[2] https://docs.antora.org/antora/2.3/page/
[3] https://issues.apache.org/jira/browse/SLING-6955

Re: Proposal for a microservice blueprint

[Bertrand Delacretaz]

Hi,

On Sun, Apr 12, 2020 at 11:58 AM Christian Schneider
 wrote:
> ...The newest trend goes to building bigger micro services on the level of
> domain driven design bounded contexts...

FWIW, I've been favoring the term "Federated Services" for quite some
time, it's reassuring to see your observation about people realizing
that not everything needs to be "micro".

-Bertrand

[jira] [Commented] (FELIX-6097) Improve startup behaviour of ServiceUnavailableFilter for low start levels

[Bertrand Delacretaz (Jira)]

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

Bertrand Delacretaz commented on FELIX-6097:


Shouldn't the "Avoid 404" option default to true?

To me, getting a 503 as soon as HTTP requests work is the natural behavior, 
getting a 404 first and later a 503 is an unfortunate side effect of the HTTP 
whiteboard.

> Improve startup behaviour of ServiceUnavailableFilter for low start levels
> --
>
> Key: FELIX-6097
> URL: https://issues.apache.org/jira/browse/FELIX-6097
> Project: Felix
>  Issue Type: Improvement
>  Components: Health Checks
>Affects Versions: healthcheck.core 2.0.2
>Reporter: Georg Henzler
>Assignee: Georg Henzler
>Priority: Major
> Fix For: healthcheck.core 2.0.4
>
>
> After some analysis and after comparing with the sling mechanism at [1], it 
> turns out that if a filter is registered to the http whiteboard, it only 
> becomes active if there is actually a servlet to answer the request 
> (otherwise the filter will never kick in and the request just return 404). 
> In a setup that uses a product that registers the http whiteboard at start 
> level 5 and the product servlets at start level 20, the current version of 
> ServiceUnavailableFilter only kicks in at start level 20 once the product 
> servlets become active when it should really already return 503 during 
> startup start levels 5-19. Although the 404 response code is usually treated 
> equally by machine clients (load balancers, kubernetes probles) it is still 
> not semantically correct, hence this shall be improved to use the mechanism 
> of [1].
> [1] 
> https://github.com/apache/sling-org-apache-sling-starter-startup/blob/f9f9496588e335d7bdee0246abff5fb22051809f/src/main/java/org/apache/sling/starter/startup/impl/HttpStartupSetup.java#L61



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Potential Felix contribution: ConfigAdmin plugin that can substitute variable placeholders (e.g. for K8s secrets)

[Bertrand Delacretaz]

Hi,

On Thu, Jul 25, 2019 at 4:32 PM David Bosschaert
 wrote:
> ...I was thinking of putting it at configadmin-plugins/substitution..

FWIW, "interpolation" is a common term for that as per
https://en.wikipedia.org/wiki/String_interpolation

-Bertrand

Re: Documentation for Apache Felix Health Checks

[Bertrand Delacretaz]

Hi Georg,

On Mon, Jan 28, 2019 at 12:50 AM Georg Henzler  wrote:
> ...I would like to
> move the documentation in the markdown file [3] to the correct location
> which I believe is a sub page "Apache Felix Health Checks" underneath
> [4],...

Many projects today just use those Markdown files in GitHub for docs,
the advantage IMO is that they stay with the code which can make it
easier to remember to keep them up to date.

If the Felix PMC agrees with that I would suggest just listing the new
Health Checks modules at [4], pointing to the
https://github.com/apache/felix/tree/trunk/healthcheck mirror and
moving [3] so that it becomes the README of that path - as it's the
general documentation for that group of modules.

-Bertrand

> [3]
> http://svn.apache.org/viewvc/felix/trunk/healthcheck/docs/felix-health-checks.md?view=log=1849246
> [4] https://cwiki.apache.org/confluence/display/FELIX/Subprojects

Re: [VOTE] Release for migration testing: Felix Health Check Annotations 0.1.1, Health Check API 0.1.1, Health Check Core 0.1.1, Health Check Webconsole Plugin 0.1.1

[Bertrand Delacretaz]

On Fri, Feb 1, 2019 at 4:00 PM Georg Henzler  wrote:
> ...Staging repository:
> https://repository.apache.org/content/repositories/orgapachefelix-1282/ ...

+1 for the release of the *0.1.1-source-release.zip archives found in there.

-Bertrand

Re: [VOTE] Initial release Felix Health Check Annotations 2.0.0, Health Check API 2.0.0, Health Check Core 2.0.0, Health Check General Checks 2.0.0, Health Check Webconsole Plugin 2.0.0

[Bertrand Delacretaz]

On Thu, Jan 31, 2019 at 5:37 PM Christian Schneider
 wrote:
> ...How about releasing 0.1.0 now and release a 2.0.0 in two weeks?
> It would give people time to test the new project and still allow us to do
> incompatible changes

I'm also strongly in favor of that, especially as these modules
migrated from Sling and people will expect backwards compatibility.

Testing that on snapshots is not optimal IMO as those are potentially
moving targets.

Releases are cheap - making another 1.0.0 or 2.0.0 release soon
shouldn't be a problem.

I'm -0 on releasing these modules as 2.0.0.

-Bertrand

Re: [ANN] New committers: Georg Henzler, Bertrand Delacretaz, and Oliver Lietz

[Bertrand Delacretaz]

Hi Felix community,

On Mon, Dec 17, 2018 at 10:17 PM Karl Pauls  wrote:
> The Project Management Committee (PMC) for Apache Felix has invited
> Georg Henzler, Bertrand Delacretaz, and Oliver Lietz to become
> committers...

Thank you very much for this!

Besides my activities at the Foundation level I've been a Sling
committer from the beginning and a fan of OSGi since that project
started. Well, a bit later maybe, once we started doing crazyish
things like replacing large numbers of bundles at startup, that helped
us find and help fix "fun" bugs around deadlocks in Felix. That was
back in 2008 so there were a few things to iron out at that time.

Besides reporting a few of those fun bugs I haven't worked much on
Felix code, but I was heavily involved in the design and development
of the Sling Health Checks that are moving here so I suppose that's
where my focus will be.

-Bertrand

Commit bit for sibling projects committers (was: [DISCUSS] Health checks contribution)

[Bertrand Delacretaz]

Hi,

On Sun, Nov 25, 2018 at 9:52 PM Karl Pauls  wrote:
> ...As I said before, we don't typically have an issue with making people
> committers that want to continue maintaining contributions...

FWIW, an idea that I (vaguely) mentioned earlier is making the Felix
repositories writable for committers of "sibling projects". Felix
would give write access to all committers of OSGi-related Apache
projects, and define community rules for how people are expected to
use those commit rights. Rules like "feel free to fix non-core simple
things directly where test coverage makes things obvious, and discuss
everything else on list before committing".

We did that between Cocoon, Lenya and Forrest a while ago (well, 15
years maybe ;-) and it worked well. I shall be able to dig out more
info if desired, can't find it right now.

I'm not saying this needs to happen right now but wanted to mention
the idea - it might help make the non-core parts of Felix more dynamic
by getting more contributions from those "sibling" OSGi-related
projects as well as motivate people to bring modules here that are of
general use.

-Bertrand (who's not a PMC member here, so just making a suggestion
based on past experience)

Re: sha512

[Bertrand Delacretaz]

On Thu, Oct 18, 2018 at 8:24 AM Konrad Windszus  wrote:
> ...Also compare with 
> https://maven.apache.org/developers/release/maven-project-release-procedure.html.
> This is currently a process decoupled from the staging repo unfortunately...

I haven't followed all the details but I think
https://issues.apache.org/jira/browse/INFRA-14923 can get in the way.

Note that http://www.apache.org/dev/release-distribution#sigs-and-sums
now says SHOULD supply sha-512 and SHOULD NOT supply md5.

IIUC those requirements have been relaxed from MUST to SHOULD for now
as the tooling is not fully in place depending on your release
process. Which means it's fine to postpone those changes until the
tooling is here, if that makes things easier.

-Bertrand

[jira] [Commented] (FELIX-5952) Felix Health Checks

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on FELIX-5952:


Ah ok, sorry if I misunderstood, I thought this was about starting the process 
of moving this module to Felix.

If it's about gauging interest I have no problem with that, the necessary 
clarifications on the Sling side can happen in parallel. Thanks for clarifying!

> Felix Health Checks
> ---
>
> Key: FELIX-5952
> URL: https://issues.apache.org/jira/browse/FELIX-5952
> Project: Felix
>  Issue Type: New Feature
>Reporter: Georg Henzler
>Assignee: Karl Pauls
>Priority: Major
> Attachments: 
> FELIX-5952-new-module-healthcheck-initial-version-v2.zip, 
> FELIX-5952-new-module-healthcheck-initial-version.zip
>
>
> Sling Health Checks [1] allow to check a system's health manually (humans) or 
> technically (load balancers, Kubernetes, etc.). Since Sling HCs have minimal 
> dependencies to Sling, they should be brought to Felix to make them available 
> to a broader audience and to to be able to use the executor runtime for the 
> systemready checks - see [2] for the discussion on the Sling mailing list.
> [1] 
> https://sling.apache.org/documentation/bundles/sling-health-check-tool.html
> [2] 
> http://apache-sling.73963.n3.nabble.com/hackathon-health-checks-td4086283.html



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

[jira] [Commented] (FELIX-5952) Felix Health Checks

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on FELIX-5952:


I see that Christian has proposed this module to the Felix PMC [1] but I don't 
see a clear decision on the Sling side so far - I have commented in that thread.

[1] 
https://lists.apache.org/thread.html/2a10823b9e8304c175cd1c8724d8903b04d4a5640e3e5e85e97a2fc7@%3Cdev.felix.apache.org%3E

> Felix Health Checks
> ---
>
> Key: FELIX-5952
> URL: https://issues.apache.org/jira/browse/FELIX-5952
> Project: Felix
>  Issue Type: New Feature
>Reporter: Georg Henzler
>Assignee: Karl Pauls
>Priority: Major
> Attachments: 
> FELIX-5952-new-module-healthcheck-initial-version-v2.zip, 
> FELIX-5952-new-module-healthcheck-initial-version.zip
>
>
> Sling Health Checks [1] allow to check a system's health manually (humans) or 
> technically (load balancers, Kubernetes, etc.). Since Sling HCs have minimal 
> dependencies to Sling, they should be brought to Felix to make them available 
> to a broader audience and to to be able to use the executor runtime for the 
> systemready checks - see [2] for the discussion on the Sling mailing list.
> [1] 
> https://sling.apache.org/documentation/bundles/sling-health-check-tool.html
> [2] 
> http://apache-sling.73963.n3.nabble.com/hackathon-health-checks-td4086283.html



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

Re: [DISCUSS] Move the sling hc project to felix and merge with systemready

[Bertrand Delacretaz]

Hi,

On Thu, Oct 11, 2018 at 10:42 AM Christian Schneider
 wrote:
> ...The sling community discussed to offer to move this project to felix. (
> https://lists.apache.org/thread.html/d42c2064bf98d10b4f9b5d424384e2e83993e41613e643de944c7c35@%3Cdev.sling.apache.org%3E
>  ...

Do you see a consensus or decision there?

I don't - I just see a vaguely converging discussion.

IMO on the Sling side we need a clear plan about moving and keeping
compatibility so that Sling users can use these new Felix Health
Checks.

If we don't have that we'll probably end up with two parallel projects
with fractured communities - no benefits compared to now, just
downsides.

Another important aspect is whether Sling committers can efficiently
help maintain that module if it moves to Felix - will Felix give write
access to Sling committers to that module? That has happened in the
past between related Apache projects (Cocoon and Forrest IIRC) and
might be a good idea here but that's a decision for the Felix PMC to
make. And the Sling PMC needs to take that into account before
considering a move, IMO.

I think the move is a great idea but I also think a transition plan
needs to be discussed on the Sling side before proceeding.

-Bertrand (Sling PMC member)

Re: [RESULT][VOTE] Apache Felix Connect 0.2.0 release (take 2)

[Bertrand Delacretaz]

Hi,

On Mon, May 28, 2018 at 7:35 AM, Jean-Baptiste Onofré  wrote:
> ...this vote passed with 6 votes (4 bindings)

FWIW, I just noticed that http://felix.apache.org/downloads.cgi stills
points to 0.1.0, and 0.2.0 is not at
https://dist.apache.org/repos/dist/release/felix/ either.

-Bertrand

Re: "system readiness check framework" contribution

[Bertrand Delacretaz]

On Tue, May 8, 2018 at 11:53 AM, Andrei Dulvac  wrote:
> ...I'm personally not hung up on the systemreadiness name;
> suggestions more than welcome

"systemready" might be less likely to be mistyped ;-)

-Bertrand

Comments on your last board report

[Bertrand Delacretaz]

Hi Felix PMC,

I'm relaying comments from the board on your last report from
December, see https://whimsy.apache.org/board/minutes/Felix.html

There were comments about your report being too terse in terms of
community health - the report shows that there's good activity in
terms of releases but is a bit minimalistic when it comes to "summing
up the status and health of your project and the community in a few
sentences" as described at
https://www.apache.org/foundation/board/reporting

Please take this into account when you prepare your next report - thanks!

-Bertrand, for the ASF Board of Directors

Re: svn commit: r1749869 - /felix/trunk/scr/src/test/java/org/apache/felix/scr/integration/components/felix5248/Component.java

[Bertrand Delacretaz]

Hi,

On Thu, Jun 23, 2016 at 4:40 PM, David Jencks
 wrote:
> ...I had a similar commit lined up to deliver and indeed intended the file to
> be apache-2.0 licensed

Note that anything that you commit is covered by your iCLA, so unless
explicitly flagged as being someone else's code it's automatically
covered by the Apache License.

-Bertrand

Webconsole: inactive component disappears from /system/console/components/

[Bertrand Delacretaz]

Hi,

Using the latest org.apache.felix.webconsole 4.2.10 in Sling, if I
deactivate a component at /system/console/components it disappears
from the list (and from the underlying json data).

Unless I'm missing something, this makes it impossible to reactivate
the component.

Is this a known issue?

-Bertrand

Felix Connect?

[Bertrand Delacretaz]

Hi,

It looks like pojosr has moved here as Felix Connect, but I cannot
find any mention of it at http://felix.apache.org/ nor at
http://felix.apache.org/downloads.cgi - did I miss something?

I have found the code at
https://svn.apache.org/repos/asf/felix/trunk/connect/ , it's just the
lack of any info about it that's surprising.

-Bertrand

Re: Felix Connect?

[Bertrand Delacretaz]

On Tue, Aug 18, 2015 at 4:03 PM, Carsten Ziegeler cziege...@apache.org wrote:
 I guess whoever did the release simply forgot to update the downloads
 list. It's there now.

Thanks!

-Bertrand

[jira] [Commented] (FELIX-4678) No list of blacklisted services available

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on FELIX-4678:


JMX would be nice as we could use it in Sling to implement a Health Check that 
complains if anything is blacklisted

 No list of blacklisted services available
 -

 Key: FELIX-4678
 URL: https://issues.apache.org/jira/browse/FELIX-4678
 Project: Felix
  Issue Type: Improvement
  Components: Event Admin
Affects Versions: eventadmin-1.4.2
Reporter: Jörg Hoh

 When a service gets blacklisted by the eventAdmin, there is only a single 
 warn statement in the logs. It would be great, if it would be an error, as a 
 blacklisted service normally results in application problems. And if it's 
 printed as error, it should be catched by any log analyzing mechanism.
 On top it would be good, if blacklisted services can be detected by a 
 different way (e.g. by throwing an OSGI event, updating an JMX MBean or 
 something like that). Log parsing is cumbersome if you need to do online 
 monitoring of your application.



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

[patch] trivial typo in AbstractBaselinePlugin

[Bertrand Delacretaz]

Hi,

I'm too lazy to create a jira on that one, find patch below.

-Bertrand


Index: 
bundleplugin/src/main/java/org/apache/felix/bundleplugin/baseline/AbstractBaselinePlugin.java
===
--- 
bundleplugin/src/main/java/org/apache/felix/bundleplugin/baseline/AbstractBaselinePlugin.java
(revision 1614033)
+++ 
bundleplugin/src/main/java/org/apache/felix/bundleplugin/baseline/AbstractBaselinePlugin.java
(working copy)
@@ -336,7 +336,7 @@
 }
 }

-getLog().info( String.format( Baseline analisys complete, %s
error(s), %s warning(s),
+getLog().info( String.format( Baseline analysis complete, %s
error(s), %s warning(s),
   reporter.getErrors().size(),
   reporter.getWarnings().size() ) );

Re: Java process codepage sharing

[Bertrand Delacretaz]

On Fri, Jul 25, 2014 at 3:20 PM, Richard S. Hall he...@ungoverned.org wrote:
 On 7/25/14, 08:45 , Rob Walker wrote:
 ...I have it in the back of my mind that the Java VM has some kind of
 codepage sharing i.e. 2 java process running the same code on the same
 machine will only use one memory space for the loaded class bytecode...

I haven't used it but as per [1] it seems like the IBM VM allows for
sharing some (ROM) parts of loaded classes between processes.

If you find more info about this in general I'd be interested.

-Bertrand

[1] 
http://pic.dhe.ibm.com/infocenter/realtime/v3r0m0/index.jsp?topic=%2Fcom.ibm.wrt.aix.doc.30%2Frealtime%2Fdiagnose_oom_understanding.html

[jira] [Comment Edited] (FELIX-3067) Prevent Deadlock Situation in Felix.acquireGlobalLock

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz edited comment on FELIX-3067 at 7/11/14 10:02 AM:
--

I don't seem to be able to produce deadlocks anymore with my stress test tool 
on the Sling trunk code revision 1609658, which uses org.apache.felix.framework 
4.4.0.

When I created that tool I would get deadlocks within seconds, now I've been 
running it for about 15 minutes with no deadlock.


was (Author: bdelacretaz):
I don't seem to be able to produce deadlocks anymore with my stress test tool 
on the Sling trunk code revision 1609658, which uses org.apache.felix.framework 
4.4.0.

When I created that tool I would get deadlocks within seconds, now I've been 
running it four about 15 minutes with no deadlock.

 Prevent Deadlock Situation in Felix.acquireGlobalLock
 -

 Key: FELIX-3067
 URL: https://issues.apache.org/jira/browse/FELIX-3067
 Project: Felix
  Issue Type: Improvement
  Components: Framework
Affects Versions: framework-3.0.7, framework-3.0.8, framework-3.0.9, 
 framework-3.2.0, framework-3.2.1, fileinstall-3.1.10
Reporter: Felix Meschberger
 Attachments: FELIX-3067-sling.patch, FELIX-3067.patch, 
 felix_unblock_deadlock.patch, threaddump-ise-deadlock.txt, 
 threads_locked_by_camel_type_converter


 Every now and then we encounter deadlock situations which involve the 
 Felix.acquireGlobalLock method. In our use case we have the following aspects 
 which contribute to this:
 (a) The Apache Felix Declarative Services implementation stops components 
 (and thus causes service unregistration) while the bundle lock is being held 
 because this happens in a SynchronousBundleListener while handling the 
 STOPPING bundle event. We have to do this to ensure the bundle is not really 
 stopped yet to properly stop the bundle's components.
 (b) Implementing a special class loader which involves dynamically resolving 
 packages which in turn uses the global lock
 (c) Eclipse Gemini Blueprint implementation which operates asynchronously
 (d) synchronization in application classes
 Often times, I would assume that we can self-heal such complex deadlck 
 situations, if we let acquireGlobalLock time out. Looking at the calles of 
 acquireGlobalLock there seems to already be provision to handle this case 
 since acquireGlobalLock returns true only if the global lock has actually 
 been acquired.
 This issue is kind of a companion to FELIX-3000 where deadlocks involve 
 sending service registration events while holding the bundle lock.



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

[jira] [Commented] (FELIX-3067) Prevent Deadlock Situation in Felix.acquireGlobalLock

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on FELIX-3067:


I don't seem to be able to produce deadlocks anymore with my stress test tool 
on the Sling trunk code revision 1609658, which uses org.apache.felix.framework 
4.4.0.

When I created that tool I would get deadlocks within seconds, now I've been 
running it four about 15 minutes with no deadlock.

 Prevent Deadlock Situation in Felix.acquireGlobalLock
 -

 Key: FELIX-3067
 URL: https://issues.apache.org/jira/browse/FELIX-3067
 Project: Felix
  Issue Type: Improvement
  Components: Framework
Affects Versions: framework-3.0.7, framework-3.0.8, framework-3.0.9, 
 framework-3.2.0, framework-3.2.1, fileinstall-3.1.10
Reporter: Felix Meschberger
 Attachments: FELIX-3067-sling.patch, FELIX-3067.patch, 
 felix_unblock_deadlock.patch, threaddump-ise-deadlock.txt, 
 threads_locked_by_camel_type_converter


 Every now and then we encounter deadlock situations which involve the 
 Felix.acquireGlobalLock method. In our use case we have the following aspects 
 which contribute to this:
 (a) The Apache Felix Declarative Services implementation stops components 
 (and thus causes service unregistration) while the bundle lock is being held 
 because this happens in a SynchronousBundleListener while handling the 
 STOPPING bundle event. We have to do this to ensure the bundle is not really 
 stopped yet to properly stop the bundle's components.
 (b) Implementing a special class loader which involves dynamically resolving 
 packages which in turn uses the global lock
 (c) Eclipse Gemini Blueprint implementation which operates asynchronously
 (d) synchronization in application classes
 Often times, I would assume that we can self-heal such complex deadlck 
 situations, if we let acquireGlobalLock time out. Looking at the calles of 
 acquireGlobalLock there seems to already be provision to handle this case 
 since acquireGlobalLock returns true only if the global lock has actually 
 been acquired.
 This issue is kind of a companion to FELIX-3000 where deadlocks involve 
 sending service registration events while holding the bundle lock.



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

Re: [ANN] Carsten Ziegeler confirmed as Chair of the PMC and VP, Apache Felix

[Bertrand Delacretaz]

On Thu, Jun 19, 2014 at 4:15 PM, Felix Meschberger fmesc...@adobe.com wrote:
 ...I would like to congratulate Carsten to his new role and wish him as much 
 fun and appreciation as I had in the last 20 years

Congrats Carsten, thanks for stepping up!

And congrats Felix for being PMC chair for the last 20 years...quite a feat ;-)

-Bertrand

Re: [ANN] Carsten Ziegeler confirmed as Chair of the PMC and VP, Apache Felix

[Bertrand Delacretaz]

On Thu, Jun 19, 2014 at 5:08 PM, Felix Meschberger fmesc...@adobe.com wrote:
... Honestly, I am sorry for the typo, indeed

No worries of course...it was just too tempting ;-)

-Bertrand

Re: Question about the Felix release process

[Bertrand Delacretaz]

Hi,

On Tue, Jun 17, 2014 at 11:37 AM, David Bosschaert
david.bosscha...@gmail.com wrote:
 The Felix release process
 (http://felix.apache.org/documentation/development/release-management-nexus.html)
 says that you need to deploy a snapshot using 'mvn deploy'

We do the same for Sling at
http://sling.apache.org/documentation/development/release-management.html
- continuous builds that use snapshots, for example, can benefit from
that, when they depend on a snapshot that's not the latest one. OTOH,
not deploying helps catch those situations, so YMMV.

-Bertrand

Re: Question about the Felix release process

[Bertrand Delacretaz]

Hi,

On Tue, Jun 17, 2014 at 1:43 PM, David Bosschaert
david.bosscha...@gmail.com wrote:
 Right - it makes sense to be able to deploy snapshots to the snapshot
 repo for the reason you outline or when people want to integrate
 SNAPSHOT components before a release, but I guess that doesn't mean it
 needs to be part of the release *process*

In theory I agree but in practice doing it just before the release is
the last time when you can do it very easily, and publishing the last
snapshot before the release is useful.

So maybe leave it in the release process description but just as a
hint that it's a good time to publish the last snapshots.

(I'm not a committer here, so just my 2 cents)

-Bertrand

[jira] [Commented] (FELIX-3239) PackageAdmin#getExportedPackages does not work on packages exported by attached fragments

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on FELIX-3239:


Thanks David, your test does match my scenario. And it is *a bit* simpler than 
mine ;-)

 PackageAdmin#getExportedPackages does not work on packages exported by 
 attached fragments
 -

 Key: FELIX-3239
 URL: https://issues.apache.org/jira/browse/FELIX-3239
 Project: Felix
  Issue Type: Bug
Affects Versions: framework-4.0.1
Reporter: Guillaume Nodet
Assignee: David Bosschaert
 Fix For: framework-4.6.0






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

[jira] [Commented] (FELIX-4479) wrong MANIFEST.MF ends up in jar bundle file sometimes

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on FELIX-4479:


I think this is related to MIME4J-231 which has more details.

 wrong MANIFEST.MF ends up in jar bundle file sometimes
 --

 Key: FELIX-4479
 URL: https://issues.apache.org/jira/browse/FELIX-4479
 Project: Felix
  Issue Type: Bug
  Components: Maven Bundle Plugin
Affects Versions: maven-bundle-plugin-2.4.0
Reporter: Mark
Priority: Blocker

 Fetch the sources from
 http://svn.apache.org/repos/asf/james/server/trunk/
 and enter mvn clean install. At the end, there will be a few karaf 
 integration tests that may sometimes fail because of a Bundle-SymbolicName 
 missing error. It is pretty much random and my best guess is that after the 
 MANIFEST.MF modification by the plugin, the file handle is not closed 
 properly, the data is not flushed to disk properly etc. because the maven 
 debug output tells me that the change is recognized and the MANIFEST.MF 
 included in the jar after it has been updated by maven-bundle-plugin. But 
 still, the old non-OSGi version ends up in the jar file sometimes.



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

[jira] [Commented] (FELIX-4101) Create metatype.properties file when description and label are inlined

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on FELIX-4101:


Note that AFAIK using this feature requires org.apache.felix.metatype V1.0.8 or 
later at runtime.

 Create metatype.properties file when description and label are inlined
 --

 Key: FELIX-4101
 URL: https://issues.apache.org/jira/browse/FELIX-4101
 Project: Felix
  Issue Type: Improvement
  Components: Maven SCR Plugin
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
 Fix For: maven-scr-plugin 1.14.0, scr ant task 1.8.0, scr 
 generator 1.8.0


 We advertise the SCR annotations with single source development = 
 everything is in a single java source file, no need to edit any other file 
 (like the DS xml descriptor). However as soon as you use metatype information 
 this is not necessarily true, especially if you want to put the real values 
 in a separate metatype.properties file.
 This somehow breaks the ease of use promise and requires to keep the source 
 code and the metatype properties in sync.
 We could easily get away with this by always creating a metatype.properties 
 file when information like label or description is inlined, e.g.
 @Property(label = Velocity, description=Set the velocity, 
 name=velocity) will
 create a metatype.properties file with
 PID.velocity.name = Velocity
 PID.velocity.description = Set the velocity
 and a metatype XML with 
 AD id=velocity type=String default= name=%PID.velocity.name 
 description=%PID.velocity.description/
 This would allow to add translations even if the information was inlined in 
 the source code.
 We could add a switch whether this should be enabled or not, default set to 
 true. I think we need this switch just for the (rare?) case where within the 
 same bundles some metatype is inlined while other metatype info is within a 
 metatype.properties. - we could even handle this by merging a potentially 
 existing props file with the generated.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (FELIX-3239) PackageAdmin#getExportedPackages does not work on packages exported by attached fragments

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz edited comment on FELIX-3239 at 4/3/13 2:02 PM:


This used to work in 3.x versions (tested with 3.0.8 and 3.2.2) but does not in 
4.0.1 or 4.0.2.

I have created a test at https://github.com/bdelacretaz/felix-fragment-tests - 
running mvn clean test -Dfelix.version=4.0.2 at the top of that causes 
FragmentsTest.testPackageFromFragment to fail. 

The test is really simple, just calls 
getExportedPackage(ch.x42.felix.fragmenttests.fragment) where the 
ch.x42.felix.fragmenttests.fragment package is provided by the test's 
fragment-bundle which is attached to the test's host-bundle.

I haven't found a place in the Felix codebase to add such a test, that requires 
two test bundles.

  was (Author: bdelacretaz):
This used to work in 3.x versions (tested with 3.0.8 and 3.2.2) but does 
not in 4.0.1 or 4.0.2.

I have created a test at https://github.com/bdelacretaz/felix-fragment-tests, 
running mvn clean test -Dfelix.version=4.0.2 at the top of that causes 
FragmentsTest.testPackageFromFragment to fail. 

The test is really simple, just calls 
getExportedPackage(ch.x42.felix.fragmenttests.fragment) where the 
ch.x42.felix.fragmenttests.fragment package is provided by the test's 
fragment-bundle which is attached to the test's host-bundle.

I haven't found a place in the Felix codebase to add such a test, that requires 
two test bundles.
  
 PackageAdmin#getExportedPackages does not work on packages exported by 
 attached fragments
 -

 Key: FELIX-3239
 URL: https://issues.apache.org/jira/browse/FELIX-3239
 Project: Felix
  Issue Type: Bug
Affects Versions: framework-4.0.1
Reporter: Guillaume Nodet
 Fix For: framework-4.4.0




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (FELIX-3239) PackageAdmin#getExportedPackages does not work on packages exported by attached fragments

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on FELIX-3239:


This used to work in 3.x versions (tested with 3.0.8 and 3.2.2) but does not in 
4.0.1 or 4.0.2.

I have created a test at https://github.com/bdelacretaz/felix-fragment-tests, 
running mvn clean test -Dfelix.version=4.0.2 at the top of that causes 
FragmentsTest.testPackageFromFragment to fail. 

The test is really simple, just calls 
getExportedPackage(ch.x42.felix.fragmenttests.fragment) where the 
ch.x42.felix.fragmenttests.fragment package is provided by the test's 
fragment-bundle which is attached to the test's host-bundle.

I haven't found a place in the Felix codebase to add such a test, that requires 
two test bundles.

 PackageAdmin#getExportedPackages does not work on packages exported by 
 attached fragments
 -

 Key: FELIX-3239
 URL: https://issues.apache.org/jira/browse/FELIX-3239
 Project: Felix
  Issue Type: Bug
Affects Versions: framework-4.0.1
Reporter: Guillaume Nodet



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (FELIX-3152) JMX as web console feature

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on FELIX-3152:


I briefly tested this as we're discussing dumping JMX values in json for Sling, 
quick usage notes:

This provides a simple interactive web-based JMX console at 
/system/console/jmx, which displays MBeans and allows for executing operations 
that they support.

A new JMX tab is added to /system/console/config, which dumps MBeans values.

The json data of that config printer is available at 
/system/console/config/JMX.nfo


 JMX as web console feature
 --

 Key: FELIX-3152
 URL: https://issues.apache.org/jira/browse/FELIX-3152
 Project: Felix
  Issue Type: New Feature
  Components: Web Console
Reporter: Christanto
  Labels: jmx, webconsole
 Attachments: org.apache.felix.webconsole.plugins.jmx.zip, 
 org.apache.felix.webconsole.plugins.jmx.zip, 
 org.apache.felix.webconsole.plugins.jmx.zip


 The attached file is a source code that implement JMX client as felix web 
 console.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (FELIX-3879) [PATCH] overridable client scripts for the webconsole

[Bertrand Delacretaz (JIRA)]

Bertrand Delacretaz created FELIX-3879:
--

 Summary: [PATCH] overridable client scripts for the webconsole
 Key: FELIX-3879
 URL: https://issues.apache.org/jira/browse/FELIX-3879
 Project: Felix
  Issue Type: Improvement
  Components: Web Console
Affects Versions: webconsole-4.0.0
Reporter: Bertrand Delacretaz
Priority: Minor
 Fix For: webconsole-4.0.2


This patch adds an OverridableResourcesServlet to the webconsole, that handles 
the /overridable path and returns an empty response for paths like 
/system/console/overridable/scripts/confighelp.js

If a Servlet service with a org.apache.felix.resources.servlet=true service 
property is present, it is used to handle those requests instead.

This can be used to provide extension points in the webconsole where users can 
replace default do-nothing scripts with their own variants.

I'ill provide another patch that uses this feature for progressive enhancement 
of the console config page with help links.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (FELIX-3879) [PATCH] overridable client scripts for the webconsole

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz updated FELIX-3879:
---

Description: 
This patch adds an OverridableResourcesServlet to the webconsole, that handles 
the /overridable path and returns an empty response for paths like 
/system/console/overridable/scripts/*

If a Servlet service with a org.apache.felix.resources.servlet=true service 
property is present, it is used to handle those requests instead.

This can be used to provide extension points in the webconsole where users can 
replace default do-nothing scripts with their own variants.

I'ill provide another patch that uses this feature for progressive enhancement 
of the console config page with help links.

  was:
This patch adds an OverridableResourcesServlet to the webconsole, that handles 
the /overridable path and returns an empty response for paths like 
/system/console/overridable/scripts/confighelp.js

If a Servlet service with a org.apache.felix.resources.servlet=true service 
property is present, it is used to handle those requests instead.

This can be used to provide extension points in the webconsole where users can 
replace default do-nothing scripts with their own variants.

I'ill provide another patch that uses this feature for progressive enhancement 
of the console config page with help links.


 [PATCH] overridable client scripts for the webconsole
 -

 Key: FELIX-3879
 URL: https://issues.apache.org/jira/browse/FELIX-3879
 Project: Felix
  Issue Type: Improvement
  Components: Web Console
Affects Versions: webconsole-4.0.0
Reporter: Bertrand Delacretaz
Priority: Minor
 Fix For: webconsole-4.0.2

 Attachments: FELIX-3879.patch


 This patch adds an OverridableResourcesServlet to the webconsole, that 
 handles the /overridable path and returns an empty response for paths like 
 /system/console/overridable/scripts/*
 If a Servlet service with a org.apache.felix.resources.servlet=true service 
 property is present, it is used to handle those requests instead.
 This can be used to provide extension points in the webconsole where users 
 can replace default do-nothing scripts with their own variants.
 I'ill provide another patch that uses this feature for progressive 
 enhancement of the console config page with help links.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (FELIX-3879) [PATCH] overridable client scripts for the webconsole

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz updated FELIX-3879:
---

Attachment: FELIX-3879.patch

 [PATCH] overridable client scripts for the webconsole
 -

 Key: FELIX-3879
 URL: https://issues.apache.org/jira/browse/FELIX-3879
 Project: Felix
  Issue Type: Improvement
  Components: Web Console
Affects Versions: webconsole-4.0.0
Reporter: Bertrand Delacretaz
Priority: Minor
 Fix For: webconsole-4.0.2

 Attachments: FELIX-3879.patch


 This patch adds an OverridableResourcesServlet to the webconsole, that 
 handles the /overridable path and returns an empty response for paths like 
 /system/console/overridable/scripts/confighelp.js
 If a Servlet service with a org.apache.felix.resources.servlet=true service 
 property is present, it is used to handle those requests instead.
 This can be used to provide extension points in the webconsole where users 
 can replace default do-nothing scripts with their own variants.
 I'ill provide another patch that uses this feature for progressive 
 enhancement of the console config page with help links.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (FELIX-3880) [PATCH] placeholders for help links in the webconsole

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz updated FELIX-3880:
---

Attachment: FELIX-3880.patch

 [PATCH] placeholders for help links in the webconsole
 -

 Key: FELIX-3880
 URL: https://issues.apache.org/jira/browse/FELIX-3880
 Project: Felix
  Issue Type: Improvement
  Components: Web Console
Affects Versions: webconsole-4.0.0
Reporter: Bertrand Delacretaz
Priority: Minor
 Fix For: webconsole-4.0.2

 Attachments: FELIX-3880.patch


 The attached patch adds placeholders for help links to the webconsole, like
 span 
   class=configHelpLink 
   data-config-param=ds.loglevel 
   data-config-pid=org.apache.felix.scr.ScrService 
   data-config-name=SCR Log Level 
   data-config-description=Allows limiting the amount... 
 /span
 which can be enhanced with client-side javascript to build customized help 
 links.
 The patch also adds a script reference at the end of the config page:
 script 
   type=text/javascript 
   src=/system/console/overridable/scripts/confighelp.js/script
 which by default points to an empty script provided by the FELIX-3879 
 mechanism, overridable by providing a Servlet service that returns the 
 desired code.
 I have created an example such servlet/script at 
 https://github.com/bdelacretaz/felix-confighelp-demo, to test this feature:
 -Apply the FELIX-3879 patch and this patch and install the patched webconsole
 -Install the felix-confighelp-demo bundle
 -The /system/console/overridable/scripts/confighelp.js path must then return 
 the felix-confighelp-demo's confighelp.js script
 -Open a config form in the console, help links should be present next to each 
 parameter, which point to google.com for the demo

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (FELIX-3880) [PATCH] placeholders for help links in the webconsole

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz updated FELIX-3880:
---

Attachment: helplinks.jpg

Screenshot of the web console with help links - the (?) links, could be made 
nicer of course.

 [PATCH] placeholders for help links in the webconsole
 -

 Key: FELIX-3880
 URL: https://issues.apache.org/jira/browse/FELIX-3880
 Project: Felix
  Issue Type: Improvement
  Components: Web Console
Affects Versions: webconsole-4.0.0
Reporter: Bertrand Delacretaz
Priority: Minor
 Fix For: webconsole-4.0.2

 Attachments: FELIX-3880.patch, helplinks.jpg


 The attached patch adds placeholders for help links to the webconsole, like
 span 
   class=configHelpLink 
   data-config-param=ds.loglevel 
   data-config-pid=org.apache.felix.scr.ScrService 
   data-config-name=SCR Log Level 
   data-config-description=Allows limiting the amount... 
 /span
 which can be enhanced with client-side javascript to build customized help 
 links.
 The patch also adds a script reference at the end of the config page:
 script 
   type=text/javascript 
   src=/system/console/overridable/scripts/confighelp.js/script
 which by default points to an empty script provided by the FELIX-3879 
 mechanism, overridable by providing a Servlet service that returns the 
 desired code.
 I have created an example such servlet/script at 
 https://github.com/bdelacretaz/felix-confighelp-demo, to test this feature:
 -Apply the FELIX-3879 patch and this patch and install the patched webconsole
 -Install the felix-confighelp-demo bundle
 -The /system/console/overridable/scripts/confighelp.js path must then return 
 the felix-confighelp-demo's confighelp.js script
 -Open a config form in the console, help links should be present next to each 
 parameter, which point to google.com for the demo

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (FELIX-3879) [PATCH] overridable client scripts for the webconsole

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on FELIX-3879:


I don't have a use case besides FELIX-3880, which is an excellent use case for 
this ;-)

 [PATCH] overridable client scripts for the webconsole
 -

 Key: FELIX-3879
 URL: https://issues.apache.org/jira/browse/FELIX-3879
 Project: Felix
  Issue Type: Improvement
  Components: Web Console
Affects Versions: webconsole-4.0.0
Reporter: Bertrand Delacretaz
Priority: Minor
 Fix For: webconsole-4.0.2

 Attachments: FELIX-3879.patch


 This patch adds an OverridableResourcesServlet to the webconsole, that 
 handles the /overridable path and returns an empty response for paths like 
 /system/console/overridable/scripts/*
 If a Servlet service with a org.apache.felix.resources.servlet=true service 
 property is present, it is used to handle those requests instead.
 This can be used to provide extension points in the webconsole where users 
 can replace default do-nothing scripts with their own variants.
 I'ill provide another patch that uses this feature for progressive 
 enhancement of the console config page with help links.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (FELIX-3880) [PATCH] placeholders for help links in the webconsole

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on FELIX-3880:


Each element gets a help link *placeholder*, which is initially invisible on 
the config form. 

They are enhanced by the javascript code that can be plugged in with the 
FELIX-3879 mechanism, and which can decide if a specific parameter gets a link 
or not.

We could make the decision to generate a link or not server-side, but assuming 
you need to query an external service (like a docs website) to find out if a 
link is available that would slow down the config display, while with my 
client-side solution the links are generated asynchronously, once the form is 
displayed.

Generating help *texts* server-side won't work for my use case - my goal is to 
have those links point to a website maintained by a docs team and/or system 
users, so totally decoupled from the system where this runs.

 [PATCH] placeholders for help links in the webconsole
 -

 Key: FELIX-3880
 URL: https://issues.apache.org/jira/browse/FELIX-3880
 Project: Felix
  Issue Type: Improvement
  Components: Web Console
Affects Versions: webconsole-4.0.0
Reporter: Bertrand Delacretaz
Priority: Minor
 Fix For: webconsole-4.0.2

 Attachments: FELIX-3880.patch, helplinks.jpg


 The attached patch adds placeholders for help links to the webconsole, like
 span 
   class=configHelpLink 
   data-config-param=ds.loglevel 
   data-config-pid=org.apache.felix.scr.ScrService 
   data-config-name=SCR Log Level 
   data-config-description=Allows limiting the amount... 
 /span
 which can be enhanced with client-side javascript to build customized help 
 links.
 The patch also adds a script reference at the end of the config page:
 script 
   type=text/javascript 
   src=/system/console/overridable/scripts/confighelp.js/script
 which by default points to an empty script provided by the FELIX-3879 
 mechanism, overridable by providing a Servlet service that returns the 
 desired code.
 I have created an example such servlet/script at 
 https://github.com/bdelacretaz/felix-confighelp-demo, to test this feature:
 -Apply the FELIX-3879 patch and this patch and install the patched webconsole
 -Install the felix-confighelp-demo bundle
 -The /system/console/overridable/scripts/confighelp.js path must then return 
 the felix-confighelp-demo's confighelp.js script
 -Open a config form in the console, help links should be present next to each 
 parameter, which point to google.com for the demo

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Separating configuration status support from web console

[Bertrand Delacretaz]

On Fri, Jan 25, 2013 at 10:33 AM, Carsten Ziegeler cziege...@apache.org wrote:
 ...I've created a first implementation[1] of a new bundle which takes
 over the configuration status functionality from the web console...
...
 WDYT?...

AFAIK the current configuration status tabs don't have their own URL,
the only way to access them is by clicking their tab on the main
config page.

If I'm correct, is that something that your changes address, or is
that unrelated?

-Bertrand

Re: IPOJO initialization + refresh deadlock

[Bertrand Delacretaz]

On Thu, Jan 3, 2013 at 10:19 AM, Jad Naous j...@nerati.com wrote:
 On Thu, Jan 3, 2013 at 12:55 AM, Bertrand Delacretaz bdelacre...@apache.org
... I haven't studied your case in detail but you might want to compare
 with FELIX-3067...

 Seems related. I'm guessing you are running into the deadlock because the
 classloader tries to acquire the global lock while holding some application
 lock?

I cannot say for sure, haven't looked at that issue in a while. The
SCR subsystem might have its own locks that contribute to exposing the
deadlocks.


 I'm not familiar with the Sling Launchpad. Is this a maven repo somewhere
 where I can get your patches?...

You can build Sling and use its launchpad as described in FELIX-3067
if you want, but the key part in reproducing the deadlocks is the
stress tests [1] - I used Sling only as a provider of several bundles
which use SCR services, as that helps expose the problem.

-Bertrand

[1] https://github.com/bdelacretaz/osgi-stresser

[jira] [Commented] (FELIX-3785) [PATCH] debug logging of lock operations in Felix class

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on FELIX-3785:


I see - I wasn't aware of this issue, and I suspect the same problem might be 
present in other classes that log while locks are being held.

Anyway, I agree that this should be avoided in this class, how about using a 
framework property to disable those logs by default, like the existing 
ds.loglevel one?

 [PATCH] debug logging of lock operations in Felix class
 ---

 Key: FELIX-3785
 URL: https://issues.apache.org/jira/browse/FELIX-3785
 Project: Felix
  Issue Type: Improvement
  Components: Framework
Affects Versions: framework-4.0.2
Reporter: Bertrand Delacretaz
Priority: Minor
 Attachments: FELIX-3785.patch


 I've added some debug logging to the Felix class to help follow 
 global/bundle/install lock/unlock operations, will attach the patch.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (FELIX-3067) Prevent Deadlock Situation in Felix.acquireGlobalLock

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on FELIX-3067:


5.6 deadlock, stress test tool?
jenkins tests
Sling log markers

from53 test, not enough memory for 5.6, uses plain java instead of 
/usr/java/jdk1.6.0_35/bin/java ?

I can now reliably reproduce such deadlocks using my 
https://github.com/bdelacretaz/osgi-stresser stress test tool - requires a few 
manual steps but generates deadlocks after just a few seconds in my tests.

I'm using the Sling Launchpad for this, as that contains a number of bundles 
that can be uninstalled/started/stopped (like crazy) to expose the problem. It 
looks like lots of package refreshes helps expose deadlocks much quicker.

Here's my failure scenario:
# Build Sling from http://svn.apache.org/repos/asf/sling/trunk, making sure 
it's using the Felix trunk's framework and scr modules (patch follows)
# Start Sling:
## cd launchpad/builder
## rm -rf sling (if needed to remove all previous state)
## java -jar target/org.apache.sling.launchpad-7-SNAPSHOT-standalone.jar
## Optionally add -Dsling.launchpad.log.level=4 to set OSGi log level to DEBUG, 
use with my FELIX-3785 patch to log locking operations
# Build the https://github.com/bdelacretaz/osgi-stresser bundle and install at 
start level 1 (so that it doesn't stop itself) from /system/console
# Connect to the tool's command line using telnet 1234

At this point the tool's stress test tasks can be started using the commands 
described at https://github.com/bdelacretaz/osgi-stresser - or simply use 

{code}
* r
{code}

to start all tasks, at which point the tool should display something like

{code}
OSGI stresser * r
sl task running - cycle time -1000 msec - levels=[3, 45, 8, 19, 30]
rp task running - cycle time 5000 msec - max wait for packages refresh=1
ss task running - cycle time 0 msec - bundle to stop and 
restart=org.apache.sling.junit.core
bu task running - cycle time -1000 msec - ignored symbolic names 
(patterns)=[commons, org.apache.felix, slf4j, ch.x42, log, org.osgi]
up task running - cycle time 0 msec - bundle to 
update=org.apache.sling.junit.core
OSGI stresser 
{code}

the tasks then do crazy things to the OSGi framework, but (IMO) according to 
spec so should not cause any deadlocks.

The sling/logs/error.log shows what the tasks are doing, and a good way to 
detect the global/bundle locks deadlock is to try to refresh /system/console, 
that will block if the locks cannot be acquired.

 Prevent Deadlock Situation in Felix.acquireGlobalLock
 -

 Key: FELIX-3067
 URL: https://issues.apache.org/jira/browse/FELIX-3067
 Project: Felix
  Issue Type: Improvement
  Components: Framework
Affects Versions: framework-3.0.7, framework-3.0.8, framework-3.0.9, 
 framework-3.2.0, framework-3.2.1, fileinstall-3.1.10
Reporter: Felix Meschberger
 Attachments: FELIX-3067.patch


 Every now and then we encounter deadlock situations which involve the 
 Felix.acquireGlobalLock method. In our use case we have the following aspects 
 which contribute to this:
 (a) The Apache Felix Declarative Services implementation stops components 
 (and thus causes service unregistration) while the bundle lock is being held 
 because this happens in a SynchronousBundleListener while handling the 
 STOPPING bundle event. We have to do this to ensure the bundle is not really 
 stopped yet to properly stop the bundle's components.
 (b) Implementing a special class loader which involves dynamically resolving 
 packages which in turn uses the global lock
 (c) Eclipse Gemini Blueprint implementation which operates asynchronously
 (d) synchronization in application classes
 Often times, I would assume that we can self-heal such complex deadlck 
 situations, if we let acquireGlobalLock time out. Looking at the calles of 
 acquireGlobalLock there seems to already be provision to handle this case 
 since acquireGlobalLock returns true only if the global lock has actually 
 been acquired.
 This issue is kind of a companion to FELIX-3000 where deadlocks involve 
 sending service registration events while holding the bundle lock.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (FELIX-3067) Prevent Deadlock Situation in Felix.acquireGlobalLock

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz edited comment on FELIX-3067 at 11/27/12 10:54 AM:
---

I can now reliably reproduce such deadlocks using my 
https://github.com/bdelacretaz/osgi-stresser stress test tool - requires a few 
manual steps but generates deadlocks after just a few seconds in my tests.

I'm using the Sling Launchpad for this, as that contains a number of bundles 
that can be uninstalled/started/stopped (like crazy) to expose the problem. It 
looks like lots of package refreshes helps expose deadlocks much quicker.

Here's my failure scenario:
# Build Sling from http://svn.apache.org/repos/asf/sling/trunk, making sure 
it's using the Felix trunk's framework and scr modules (patch follows)
# Start Sling:
## cd launchpad/builder
## rm -rf sling (if needed to remove all previous state)
## java -jar target/org.apache.sling.launchpad-7-SNAPSHOT-standalone.jar
## Optionally add -Dsling.launchpad.log.level=4 to set OSGi log level to DEBUG, 
use with my FELIX-3785 patch to log locking operations
# Build the https://github.com/bdelacretaz/osgi-stresser bundle and install at 
start level 1 (so that it doesn't stop itself) from /system/console
# Connect to the tool's command line using telnet 1234

At this point the tool's stress test tasks can be started using the commands 
described at https://github.com/bdelacretaz/osgi-stresser - or simply use 

{code}
* r
{code}

to start all tasks, at which point the tool should display something like

{code}
OSGI stresser * r
sl task running - cycle time -1000 msec - levels=[3, 45, 8, 19, 30]
rp task running - cycle time 5000 msec - max wait for packages refresh=1
ss task running - cycle time 0 msec - bundle to stop and 
restart=org.apache.sling.junit.core
bu task running - cycle time -1000 msec - ignored symbolic names 
(patterns)=[commons, org.apache.felix, slf4j, ch.x42, log, org.osgi]
up task running - cycle time 0 msec - bundle to 
update=org.apache.sling.junit.core
OSGI stresser 
{code}

the tasks then do crazy things to the OSGi framework, but (IMO) according to 
spec so should not cause any deadlocks.

The sling/logs/error.log shows what the tasks are doing, and a good way to 
detect the global/bundle locks deadlock is to try to refresh /system/console, 
that will block if the locks cannot be acquired.

  was (Author: bdelacretaz):
5.6 deadlock, stress test tool?
jenkins tests
Sling log markers

from53 test, not enough memory for 5.6, uses plain java instead of 
/usr/java/jdk1.6.0_35/bin/java ?

I can now reliably reproduce such deadlocks using my 
https://github.com/bdelacretaz/osgi-stresser stress test tool - requires a few 
manual steps but generates deadlocks after just a few seconds in my tests.

I'm using the Sling Launchpad for this, as that contains a number of bundles 
that can be uninstalled/started/stopped (like crazy) to expose the problem. It 
looks like lots of package refreshes helps expose deadlocks much quicker.

Here's my failure scenario:
# Build Sling from http://svn.apache.org/repos/asf/sling/trunk, making sure 
it's using the Felix trunk's framework and scr modules (patch follows)
# Start Sling:
## cd launchpad/builder
## rm -rf sling (if needed to remove all previous state)
## java -jar target/org.apache.sling.launchpad-7-SNAPSHOT-standalone.jar
## Optionally add -Dsling.launchpad.log.level=4 to set OSGi log level to DEBUG, 
use with my FELIX-3785 patch to log locking operations
# Build the https://github.com/bdelacretaz/osgi-stresser bundle and install at 
start level 1 (so that it doesn't stop itself) from /system/console
# Connect to the tool's command line using telnet 1234

At this point the tool's stress test tasks can be started using the commands 
described at https://github.com/bdelacretaz/osgi-stresser - or simply use 

{code}
* r
{code}

to start all tasks, at which point the tool should display something like

{code}
OSGI stresser * r
sl task running - cycle time -1000 msec - levels=[3, 45, 8, 19, 30]
rp task running - cycle time 5000 msec - max wait for packages refresh=1
ss task running - cycle time 0 msec - bundle to stop and 
restart=org.apache.sling.junit.core
bu task running - cycle time -1000 msec - ignored symbolic names 
(patterns)=[commons, org.apache.felix, slf4j, ch.x42, log, org.osgi]
up task running - cycle time 0 msec - bundle to 
update=org.apache.sling.junit.core
OSGI stresser 
{code}

the tasks then do crazy things to the OSGi framework, but (IMO) according to 
spec so should not cause any deadlocks.

The sling/logs/error.log shows what the tasks are doing, and a good way to 
detect the global/bundle locks deadlock is to try to refresh /system/console, 
that will block if the locks cannot be acquired.
  
 Prevent Deadlock Situation

[jira] [Updated] (FELIX-3067) Prevent Deadlock Situation in Felix.acquireGlobalLock

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz updated FELIX-3067:
---

Attachment: FELIX-3067-sling.patch

Patch to use the Felix framework + scr snapshots in Sling launchpad

 Prevent Deadlock Situation in Felix.acquireGlobalLock
 -

 Key: FELIX-3067
 URL: https://issues.apache.org/jira/browse/FELIX-3067
 Project: Felix
  Issue Type: Improvement
  Components: Framework
Affects Versions: framework-3.0.7, framework-3.0.8, framework-3.0.9, 
 framework-3.2.0, framework-3.2.1, fileinstall-3.1.10
Reporter: Felix Meschberger
 Attachments: FELIX-3067.patch, FELIX-3067-sling.patch


 Every now and then we encounter deadlock situations which involve the 
 Felix.acquireGlobalLock method. In our use case we have the following aspects 
 which contribute to this:
 (a) The Apache Felix Declarative Services implementation stops components 
 (and thus causes service unregistration) while the bundle lock is being held 
 because this happens in a SynchronousBundleListener while handling the 
 STOPPING bundle event. We have to do this to ensure the bundle is not really 
 stopped yet to properly stop the bundle's components.
 (b) Implementing a special class loader which involves dynamically resolving 
 packages which in turn uses the global lock
 (c) Eclipse Gemini Blueprint implementation which operates asynchronously
 (d) synchronization in application classes
 Often times, I would assume that we can self-heal such complex deadlck 
 situations, if we let acquireGlobalLock time out. Looking at the calles of 
 acquireGlobalLock there seems to already be provision to handle this case 
 since acquireGlobalLock returns true only if the global lock has actually 
 been acquired.
 This issue is kind of a companion to FELIX-3000 where deadlocks involve 
 sending service registration events while holding the bundle lock.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (FELIX-3067) Prevent Deadlock Situation in Felix.acquireGlobalLock

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz edited comment on FELIX-3067 at 11/27/12 11:04 AM:
---

I can now reliably reproduce such deadlocks using my 
https://github.com/bdelacretaz/osgi-stresser stress test tool - requires a few 
manual steps but generates deadlocks after just a few seconds in my tests.

I'm using the Sling Launchpad for this, as that contains a number of bundles 
that can be uninstalled/started/stopped (like crazy) to expose the problem. It 
looks like lots of package refreshes helps expose deadlocks much quicker.

Here's my failure scenario:
# Build Sling from http://svn.apache.org/repos/asf/sling/trunk, making sure 
it's using the Felix trunk's framework and scr modules (patch follows)
# Start Sling:
## cd launchpad/builder
## rm -rf sling (if needed to remove all previous state)
## java -jar target/org.apache.sling.launchpad-7-SNAPSHOT-standalone.jar
## Optionally add -Dsling.launchpad.log.level=4 to set OSGi log level to DEBUG, 
use with my FELIX-3785 patch to log locking operations
# Build the https://github.com/bdelacretaz/osgi-stresser bundle and install at 
start level 1 (so that it doesn't stop itself) from /system/console
# Connect to the tool's command line using telnet 1234

At this point the tool's stress test tasks can be started using the commands 
described at https://github.com/bdelacretaz/osgi-stresser - or simply use * r 
to start all tasks, at which point the tool should display something like

OSGI stresser * r
sl task running - cycle time -1000 msec - levels=[3, 45, 8, 19, 30]
rp task running - cycle time 5000 msec - max wait for packages refresh=1
ss task running - cycle time 0 msec - bundle to stop and 
restart=org.apache.sling.junit.core
bu task running - cycle time -1000 msec - ignored symbolic names 
(patterns)=[commons, org.apache.felix, slf4j, ch.x42, log, org.osgi]
up task running - cycle time 0 msec - bundle to 
update=org.apache.sling.junit.core
OSGI stresser 

the tasks then do crazy things to the OSGi framework, but (IMO) according to 
spec so should not cause any deadlocks.

The sling/logs/error.log shows what the tasks are doing, and a good way to 
detect the global/bundle locks deadlock is to try to refresh /system/console, 
that will block if the locks cannot be acquired.

  was (Author: bdelacretaz):
I can now reliably reproduce such deadlocks using my 
https://github.com/bdelacretaz/osgi-stresser stress test tool - requires a few 
manual steps but generates deadlocks after just a few seconds in my tests.

I'm using the Sling Launchpad for this, as that contains a number of bundles 
that can be uninstalled/started/stopped (like crazy) to expose the problem. It 
looks like lots of package refreshes helps expose deadlocks much quicker.

Here's my failure scenario:
# Build Sling from http://svn.apache.org/repos/asf/sling/trunk, making sure 
it's using the Felix trunk's framework and scr modules (patch follows)
# Start Sling:
## cd launchpad/builder
## rm -rf sling (if needed to remove all previous state)
## java -jar target/org.apache.sling.launchpad-7-SNAPSHOT-standalone.jar
## Optionally add -Dsling.launchpad.log.level=4 to set OSGi log level to DEBUG, 
use with my FELIX-3785 patch to log locking operations
# Build the https://github.com/bdelacretaz/osgi-stresser bundle and install at 
start level 1 (so that it doesn't stop itself) from /system/console
# Connect to the tool's command line using telnet 1234

At this point the tool's stress test tasks can be started using the commands 
described at https://github.com/bdelacretaz/osgi-stresser - or simply use 

{code}
* r
{code}

to start all tasks, at which point the tool should display something like

{code}
OSGI stresser * r
sl task running - cycle time -1000 msec - levels=[3, 45, 8, 19, 30]
rp task running - cycle time 5000 msec - max wait for packages refresh=1
ss task running - cycle time 0 msec - bundle to stop and 
restart=org.apache.sling.junit.core
bu task running - cycle time -1000 msec - ignored symbolic names 
(patterns)=[commons, org.apache.felix, slf4j, ch.x42, log, org.osgi]
up task running - cycle time 0 msec - bundle to 
update=org.apache.sling.junit.core
OSGI stresser 
{code}

the tasks then do crazy things to the OSGi framework, but (IMO) according to 
spec so should not cause any deadlocks.

The sling/logs/error.log shows what the tasks are doing, and a good way to 
detect the global/bundle locks deadlock is to try to refresh /system/console, 
that will block if the locks cannot be acquired.
  
 Prevent Deadlock Situation in Felix.acquireGlobalLock
 -

 Key: FELIX-3067
 URL: https://issues.apache.org/jira/browse/FELIX-3067

[jira] [Comment Edited] (FELIX-3067) Prevent Deadlock Situation in Felix.acquireGlobalLock

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz edited comment on FELIX-3067 at 11/27/12 11:06 AM:
---

I can now reliably reproduce such deadlocks using my 
https://github.com/bdelacretaz/osgi-stresser stress test tool - requires a few 
manual steps but generates deadlocks after just a few seconds in my tests.

I'm using the Sling Launchpad for this, as that contains a number of bundles 
that can be uninstalled/started/stopped (like crazy) to expose the problem. It 
looks like lots of package refreshes helps expose deadlocks much quicker.

Here's my failure scenario (using a 1.6.0_37 JVM on macosx):
# Build Sling from http://svn.apache.org/repos/asf/sling/trunk, making sure 
it's using the Felix trunk's framework and scr modules (patch follows)
# Start Sling:
## cd launchpad/builder
## rm -rf sling (if needed to remove all previous state)
## java -jar target/org.apache.sling.launchpad-7-SNAPSHOT-standalone.jar
## Optionally add -Dsling.launchpad.log.level=4 to set OSGi log level to DEBUG, 
use with my FELIX-3785 patch to log locking operations
# Build the https://github.com/bdelacretaz/osgi-stresser bundle and install at 
start level 1 (so that it doesn't stop itself) from /system/console
# Connect to the tool's command line using telnet 1234

At this point the tool's stress test tasks can be started using the commands 
described at https://github.com/bdelacretaz/osgi-stresser - or simply use * r 
to start all tasks, at which point the tool should display something like

OSGI stresser * r
sl task running - cycle time -1000 msec - levels=[3, 45, 8, 19, 30]
rp task running - cycle time 5000 msec - max wait for packages refresh=1
ss task running - cycle time 0 msec - bundle to stop and 
restart=org.apache.sling.junit.core
bu task running - cycle time -1000 msec - ignored symbolic names 
(patterns)=[commons, org.apache.felix, slf4j, ch.x42, log, org.osgi]
up task running - cycle time 0 msec - bundle to 
update=org.apache.sling.junit.core
OSGI stresser 

the tasks then do crazy things to the OSGi framework, but (IMO) according to 
spec so should not cause any deadlocks - but they do.

The sling/logs/error.log shows what the tasks are doing, and a good way to 
detect the global/bundle locks deadlock is to try to refresh /system/console, 
that will block if the locks cannot be acquired.

  was (Author: bdelacretaz):
I can now reliably reproduce such deadlocks using my 
https://github.com/bdelacretaz/osgi-stresser stress test tool - requires a few 
manual steps but generates deadlocks after just a few seconds in my tests.

I'm using the Sling Launchpad for this, as that contains a number of bundles 
that can be uninstalled/started/stopped (like crazy) to expose the problem. It 
looks like lots of package refreshes helps expose deadlocks much quicker.

Here's my failure scenario:
# Build Sling from http://svn.apache.org/repos/asf/sling/trunk, making sure 
it's using the Felix trunk's framework and scr modules (patch follows)
# Start Sling:
## cd launchpad/builder
## rm -rf sling (if needed to remove all previous state)
## java -jar target/org.apache.sling.launchpad-7-SNAPSHOT-standalone.jar
## Optionally add -Dsling.launchpad.log.level=4 to set OSGi log level to DEBUG, 
use with my FELIX-3785 patch to log locking operations
# Build the https://github.com/bdelacretaz/osgi-stresser bundle and install at 
start level 1 (so that it doesn't stop itself) from /system/console
# Connect to the tool's command line using telnet 1234

At this point the tool's stress test tasks can be started using the commands 
described at https://github.com/bdelacretaz/osgi-stresser - or simply use * r 
to start all tasks, at which point the tool should display something like

OSGI stresser * r
sl task running - cycle time -1000 msec - levels=[3, 45, 8, 19, 30]
rp task running - cycle time 5000 msec - max wait for packages refresh=1
ss task running - cycle time 0 msec - bundle to stop and 
restart=org.apache.sling.junit.core
bu task running - cycle time -1000 msec - ignored symbolic names 
(patterns)=[commons, org.apache.felix, slf4j, ch.x42, log, org.osgi]
up task running - cycle time 0 msec - bundle to 
update=org.apache.sling.junit.core
OSGI stresser 

the tasks then do crazy things to the OSGi framework, but (IMO) according to 
spec so should not cause any deadlocks.

The sling/logs/error.log shows what the tasks are doing, and a good way to 
detect the global/bundle locks deadlock is to try to refresh /system/console, 
that will block if the locks cannot be acquired.
  
 Prevent Deadlock Situation in Felix.acquireGlobalLock
 -

 Key: FELIX-3067
 URL: https://issues.apache.org/jira/browse/FELIX

[jira] [Updated] (FELIX-3785) [PATCH] debug logging of lock operations in Felix class

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz updated FELIX-3785:
---

Attachment: FELIX-3785.patch

 [PATCH] debug logging of lock operations in Felix class
 ---

 Key: FELIX-3785
 URL: https://issues.apache.org/jira/browse/FELIX-3785
 Project: Felix
  Issue Type: Improvement
  Components: Framework
Affects Versions: framework-4.0.2
Reporter: Bertrand Delacretaz
Priority: Minor
 Attachments: FELIX-3785.patch


 I've added some debug logging to the Felix class to help follow 
 global/bundle/install lock/unlock operations, will attach the patch.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (FELIX-3746) Deadlock around SCR AbstractComponentManager and DelayedComponentManager

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz resolved FELIX-3746.


Resolution: Duplicate

Trunk seems to be fine indeed - sorry for the noise.

 Deadlock around SCR AbstractComponentManager and DelayedComponentManager
 

 Key: FELIX-3746
 URL: https://issues.apache.org/jira/browse/FELIX-3746
 Project: Felix
  Issue Type: Bug
  Components: Declarative Services (SCR)
Affects Versions:  scr-1.6.0
Reporter: Bertrand Delacretaz
 Attachments: stack-trace.txt


 The exact affected version is org.apache.felix.scr trunk revision 1236132
 I'm running my stress tests from https://github.com/bdelacretaz/osgi-stresser 
 which repeatedly and concurrently change the start level, update a bundle and 
 stop/start bundles, and sometimes seeing a deadlock between threads that use 
 the AbstractComponentManager and DelayedComponentManager.
 I'll attach a stack trace that's slightly incomplete, where I removed 
 product-specific threads. I can provide the full stack trace privately if 
 needed.
 I'll try running the latest trunk of that module to see if that makes a 
 difference.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (FELIX-3746) Deadlock around SCR AbstractComponentManager and DelayedComponentManager

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on FELIX-3746:


You're right, I compared that revision 1236132 with trunk and there's been a 
lot of changes, I should have done that earlier.

I'll run my torture tests against trunk and report here.

 Deadlock around SCR AbstractComponentManager and DelayedComponentManager
 

 Key: FELIX-3746
 URL: https://issues.apache.org/jira/browse/FELIX-3746
 Project: Felix
  Issue Type: Bug
  Components: Declarative Services (SCR)
Affects Versions:  scr-1.6.0
Reporter: Bertrand Delacretaz
 Attachments: stack-trace.txt


 The exact affected version is org.apache.felix.scr trunk revision 1236132
 I'm running my stress tests from https://github.com/bdelacretaz/osgi-stresser 
 which repeatedly and concurrently change the start level, update a bundle and 
 stop/start bundles, and sometimes seeing a deadlock between threads that use 
 the AbstractComponentManager and DelayedComponentManager.
 I'll attach a stack trace that's slightly incomplete, where I removed 
 product-specific threads. I can provide the full stack trace privately if 
 needed.
 I'll try running the latest trunk of that module to see if that makes a 
 difference.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (FELIX-3746) Deadlock around SCR AbstractComponentManager and DelayedComponentManager

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz updated FELIX-3746:
---

Attachment: stack-trace.txt

 Deadlock around SCR AbstractComponentManager and DelayedComponentManager
 

 Key: FELIX-3746
 URL: https://issues.apache.org/jira/browse/FELIX-3746
 Project: Felix
  Issue Type: Bug
  Components: Declarative Services (SCR)
Affects Versions:  scr-1.6.0
Reporter: Bertrand Delacretaz
 Attachments: stack-trace.txt


 The exact affected version is org.apache.felix.scr trunk revision 1236132
 I'm running my stress tests from https://github.com/bdelacretaz/osgi-stresser 
 which repeatedly and concurrently change the start level, update a bundle and 
 stop/start bundles, and sometimes seeing a deadlock between threads that use 
 the AbstractComponentManager and DelayedComponentManager.
 I'll attach a stack trace that's slightly incomplete, where I removed 
 product-specific threads. I can provide the full stack trace privately if 
 needed.
 I'll try running the latest trunk of that module to see if that makes a 
 difference.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (FELIX-3746) Deadlock around SCR AbstractComponentManager and DelayedComponentManager

[Bertrand Delacretaz (JIRA)]

Bertrand Delacretaz created FELIX-3746:
--

 Summary: Deadlock around SCR AbstractComponentManager and 
DelayedComponentManager
 Key: FELIX-3746
 URL: https://issues.apache.org/jira/browse/FELIX-3746
 Project: Felix
  Issue Type: Bug
  Components: Declarative Services (SCR)
Affects Versions:  scr-1.6.0
Reporter: Bertrand Delacretaz
 Attachments: stack-trace.txt

The exact affected version is org.apache.felix.scr trunk revision 1236132

I'm running my stress tests from https://github.com/bdelacretaz/osgi-stresser 
which repeatedly and concurrently change the start level, update a bundle and 
stop/start bundles, and sometimes seeing a deadlock between threads that use 
the AbstractComponentManager and DelayedComponentManager.

I'll attach a stack trace that's slightly incomplete, where I removed 
product-specific threads. I can provide the full stack trace privately if 
needed.

I'll try running the latest trunk of that module to see if that makes a 
difference.





--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Future of the Maven SCR Plugin

[Bertrand Delacretaz]

On Mon, Nov 7, 2011 at 10:46 AM, Felix Meschberger fmesc...@adobe.com wrote:
 ...Going forward I see the following changes, we might want to apply to the 
 SCR plugin:...

 ...* Add support for the new OSGi standard annotations, of course.

 * Consider supportig mixing Felix and standard annotations in the same class 
 (not a requirement but might be helpful -- or confusing ;-) )...

Should the Felix annotations also be deprecated?

It's probably good, medium-term, for everybody to move to the new
standard annotations.

-Bertrand

Re: Bndtools based OSGi bundles maker project need feedback

[Bertrand Delacretaz]

Hi Tiger,

On Fri, Apr 15, 2011 at 4:21 AM, Tiger Gui tigergui1...@gmail.com wrote:
 Hi Bert,

 Thank you for your remind, in fact, i am really interested in OSGi
 technology and just want to do *some thing* for this community, may be
 it is not really a good idea to ask you guys register as mentor to
 support our project...

Don't get me wrong - your project certainly deserves the support that
this community is willing to express.

My point was that people signing up as GSoC mentors just to support
it, with no intention of actually mentoring, is not the right thing to
do.

Supporting comments in FELIX-2899 or on blogs, twitter etc. can
certainly be relayed by the actual mentors to the GSoC team to show
community support.

-Bertrand




 2011/4/15 Bertrand Delacretaz bdelacre...@apache.org:
 On Thu, Apr 14, 2011 at 4:31 PM, David Bosschaert
 david.bosscha...@gmail.com wrote:
 Sure, but I guess there are other responsibilities attached to being a
 mentor, than just leaving a supportive comment.

 Yes - I'm not a GSoC admin this year but I was in the past, and AFAIK
 signing up as a mentor indeed means you're intending to mentor a
 project. Signing up just to support a project is pushing it a bit,
 IMO.

 -Bertrand

Re: Bndtools based OSGi bundles maker project need feedback

[Bertrand Delacretaz]

On Thu, Apr 14, 2011 at 4:31 PM, David Bosschaert
david.bosscha...@gmail.com wrote:
 Sure, but I guess there are other responsibilities attached to being a
 mentor, than just leaving a supportive comment.

Yes - I'm not a GSoC admin this year but I was in the past, and AFAIK
signing up as a mentor indeed means you're intending to mentor a
project. Signing up just to support a project is pushing it a bit,
IMO.

-Bertrand

[jira] [Created] (FELIX-2906) SCR plugin error with @Property(..., intValue=Integer.MAX_VALUE)

[Bertrand Delacretaz (JIRA)]

SCR plugin error with @Property(..., intValue=Integer.MAX_VALUE)


 Key: FELIX-2906
 URL: https://issues.apache.org/jira/browse/FELIX-2906
 Project: Felix
  Issue Type: Bug
  Components: Maven SCR Plugin
Affects Versions: maven-scr-plugin-1.7.0
Reporter: Bertrand Delacretaz
Priority: Minor


This annotation

@Property(name=Constants.SERVICE_RANKING, intValue=Integer.MAX_VALUE)

causes the plugin to fail:

Caused by: org.apache.felix.scrplugin.SCRDescriptorException: Unable to load 
class
at 
org.apache.felix.scrplugin.JavaClassDescriptorManager.getJavaClassDescription(JavaClassDescriptorManager.java:429)
at 
org.apache.felix.scrplugin.tags.qdox.QDoxJavaClassDescription.getExternalFieldByName(QDoxJavaClassDescription.java:173)
at 
org.apache.felix.scrplugin.tags.annotation.Util$1.visitAnnotationFieldRef(Util.java:412)

The workaround is to import java.lang.Integer

This is similar to FELIX-1129 but I don't seem to be allowed to reopen that 
issue.


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: can/should the webconsole HTTP API be formalized?

[Bertrand Delacretaz]

Hi,

On Sun, Feb 20, 2011 at 8:34 PM, Felix Meschberger fmesc...@adobe.com wrote:
 Am Sonntag, den 20.02.2011, 18:27 + schrieb Justin Edelson:
 Shay's question(s) have got me thinking... is there a need to
 formalize the HTTP API exposed by the webconsole plugins (or at least
 the *core* plugins)? Other than maven-sling-plugin, do other
 applications use the webconsole as an HTTP service? Or is that just a
 quirk of the history of the webconsole?...

I am starting to use the webconsole HTTP API to create testing
examples in SLING-1981, where bundles are installed during integration
tests.

 There are two parts of the API: The input (client-to-server requests)
 which has been stable over the last few releases and the output
 (server-to-client responses) which have been changed now and then while
 converting to JQuery.

 So, I agree we probably (1) have to document the input side and (2)
 better formalize the output side ...

FWIW, up to date docs are cool but IMO integration tests are almost as
good, and much easier to keep in sync.

For Stanbol and Sling I'm creating some testing utilities that lead to
very readable tests [1], I think such tests can complement docs
nicely. The (small) library that I'm working on for that is at [2] and
has no stanbol or sling dependencies, so if someone wants to play with
it feel free.

-Bertrand

[1] 
http://svn.apache.org/repos/asf/incubator/stanbol/trunk/enhancer/integration-tests/src/test/java/org/apache/stanbol/enhancer/it/StatelessEngineTest.java

[2] http://svn.apache.org/repos/asf/incubator/stanbol/trunk/commons/testing/http

[jira] Created: (FELIX-2333) service.ranking property type should be Integer by default

[Bertrand Delacretaz (JIRA)]

service.ranking property type should be Integer by default
--

 Key: FELIX-2333
 URL: https://issues.apache.org/jira/browse/FELIX-2333
 Project: Felix
  Issue Type: Improvement
  Components: Maven SCR Plugin
Affects Versions: maven-scr-plugin-1.4.2
Reporter: Bertrand Delacretaz
Priority: Minor


Forgetting to specify the type on

@scr.property name=service.ranking type=Integer value=500

causes the ranking to be silently ignored, as the property is then of type 
String and the OSGi spec requires an Integer.

Using the Integer type by default for this property would help avoid this 
problem.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Regarding broken Http Service links...

[Bertrand Delacretaz]

On Fri, Dec 11, 2009 at 9:09 AM, Sten Roger Sandvik s...@x3m.com wrote:
 Also I noticed on the 27. november when I edited the news section that
 the Gogo release bullet was there. I even fixed a spelling mistake in
 the news announcement. I bet something fishy was going on the 27th :-)...

Yes, a wrong database restore overwrote some Confluence data around
that time, the recommendation from infra is to reapply edits done
between ~2009-11-26 23:00 and ~2009-11-27 16:00 (UTC).

-Bertrand

[jira] Created: (FELIX-1886) Bundle-SymbolicName generated with maven-bundle-plugin 2.0.0 is not the same as with 1.4.3

[Bertrand Delacretaz (JIRA)]

Bundle-SymbolicName generated with maven-bundle-plugin 2.0.0 is not the same as 
with 1.4.3
--

 Key: FELIX-1886
 URL: https://issues.apache.org/jira/browse/FELIX-1886
 Project: Felix
  Issue Type: Bug
  Components: Maven Bundle Plugin
Affects Versions: maven-bundle-plugin-2.0.0
Reporter: Bertrand Delacretaz


I have noticed this with the jackrabbit-jcr-commons 2.0-beta3 module.

1) Build as is, uses maven-bundle-plugin 2.0.0, resulting MANIFEST.MF contains:

Tool: Bnd-0.0.311
Bundle-SymbolicName: org.apache.jackrabbit.jcr-commons

(not sure if the version of bnd makes a difference)

2) Modify pom.xml to use maven-bundle-plugin 1.4.3, rebuild, resulting 
MANIFEST.MF contains:

Tool: Bnd-0.0.255
Bundle-SymbolicName: org.apache.jackrabbit.jackrabbit-jcr-commons

The new symbolic name looks nicer, but the change is surprising  - that should 
be documented (did I miss that?), and having a way to use the old 
Bundle-SymbolicName generation rules might be good.

[1] 
http://svn.apache.org/repos/asf/jackrabbit/tags/2.0-beta3/jackrabbit-jcr-commons/

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (FELIX-1886) Bundle-SymbolicName generated with maven-bundle-plugin 2.0.0 is not the same as with 1.4.3

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on FELIX-1886:


Thanks, makes perfect sense and the configuration workaround is fine!

 Bundle-SymbolicName generated with maven-bundle-plugin 2.0.0 is not the same 
 as with 1.4.3
 --

 Key: FELIX-1886
 URL: https://issues.apache.org/jira/browse/FELIX-1886
 Project: Felix
  Issue Type: Bug
  Components: Maven Bundle Plugin
Affects Versions: maven-bundle-plugin-2.0.0
Reporter: Bertrand Delacretaz

 I have noticed this with the jackrabbit-jcr-commons 2.0-beta3 module.
 1) Build as is, uses maven-bundle-plugin 2.0.0, resulting MANIFEST.MF 
 contains:
 Tool: Bnd-0.0.311
 Bundle-SymbolicName: org.apache.jackrabbit.jcr-commons
 (not sure if the version of bnd makes a difference)
 2) Modify pom.xml to use maven-bundle-plugin 1.4.3, rebuild, resulting 
 MANIFEST.MF contains:
 Tool: Bnd-0.0.255
 Bundle-SymbolicName: org.apache.jackrabbit.jackrabbit-jcr-commons
 The new symbolic name looks nicer, but the change is surprising  - that 
 should be documented (did I miss that?), and having a way to use the old 
 Bundle-SymbolicName generation rules might be good.
 [1] 
 http://svn.apache.org/repos/asf/jackrabbit/tags/2.0-beta3/jackrabbit-jcr-commons/

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Proposal for a new NOTICE file

[Bertrand Delacretaz]

On Mon, Oct 12, 2009 at 2:46 PM, Felix Meschberger fmesc...@gmail.com wrote:
 ...Thanks for bringing this up (again). The problem I have had for some
 time now, is that our NOTICE files are not really consistent with the
 legal intent of the NOTICE files

FWIW, there's been some discussion about this recently at
https://issues.apache.org/jira/browse/LEGAL-62, which includes
pointers to some related discussions threads.

-Bertrand

Re: Proposal for a new NOTICE file

[Bertrand Delacretaz]

On Mon, Oct 12, 2009 at 3:08 PM, Richard S. Hall he...@ungoverned.org wrote:
 ...reading the issue Bertrand references it is not clear. From my point
 of view the overall issue to decide is:

  1. Two-file approach, one for legal requirements and one for courtesy.
  2. One-file approach for both.

 I prefer (2) if this is possible

See also http://markmail.org/message/cxwtnuys65c7hs2y - we had a
similar discussion in Sling a while ago, and the way I read it Roy
clearly states that 1) is the way to go - NOTICE should only be used
for *required* attribution notices.

http://www.apache.org/legal/src-headers.html#notice also says the
remainder of the NOTICE file is to be used for *required* third-party
notices (my emphasis).

-Bertrand (from the peanuts gallery)

Re: [REPORT] Apache Felix

[Bertrand Delacretaz]

On Thu, Sep 17, 2009 at 9:27 AM, Charles Moulliard cmoulli...@gmail.com wrote:
 That's very fine and interesting to produce such a report. thxs ;-)

As Richard says, Apache projects have to produce those board reports.

FYI, they are published as part of the board's minutes [1], which is a
great way to (try and) keep up with all what's happening at Apache!

-Bertrand

[1] http://www.apache.org/foundation/records/minutes/

[jira] Created: (FELIX-1166) SCR does not rebind ConfigurationAdmin service in Sling jcrinstall tests

[Bertrand Delacretaz (JIRA)]

SCR does not rebind ConfigurationAdmin service in Sling jcrinstall tests


 Key: FELIX-1166
 URL: https://issues.apache.org/jira/browse/FELIX-1166
 Project: Felix
  Issue Type: Bug
  Components: Declarative Services (SCR)
Affects Versions: scr-1.0.8
Reporter: Bertrand Delacretaz
 Attachments: FELIX-1166-reproduce.patch

I'm testing the Sling jcrinstall module using Pax Exam, and the SCR reference 
shown below is not rebound after stopping and restarting the 
org.apache.felix.configadmin bundle, and waiting up to 5 seconds.

The reference is declared like this in the OsgiControllerImpl class:

/** @scr.reference cardinality=0..1 policy=dynamic */
private ConfigurationAdmin configAdmin;

To reproduce, apply the attached patch to revision 776315 of  
http://svn.apache.org/repos/asf/incubator/sling/trunk/contrib/extensions/jcrinstall,
 and run the tests with mvn clean install.

The OsgiControllerTest.testDeferredConfigInstall test then fails, because the 
ConfigurationAdmin service is not rebound to the OsgiControllerImpl class, 
after waiting up to 5 seconds for that to happen.




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (FELIX-1166) SCR does not rebind ConfigurationAdmin service in Sling jcrinstall tests

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz updated FELIX-1166:
---

Attachment: FELIX-1166-reproduce.patch

Sling jcrinstall patch to reproduce the problem

 SCR does not rebind ConfigurationAdmin service in Sling jcrinstall tests
 

 Key: FELIX-1166
 URL: https://issues.apache.org/jira/browse/FELIX-1166
 Project: Felix
  Issue Type: Bug
  Components: Declarative Services (SCR)
Affects Versions: scr-1.0.8
Reporter: Bertrand Delacretaz
 Attachments: FELIX-1166-reproduce.patch


 I'm testing the Sling jcrinstall module using Pax Exam, and the SCR reference 
 shown below is not rebound after stopping and restarting the 
 org.apache.felix.configadmin bundle, and waiting up to 5 seconds.
 The reference is declared like this in the OsgiControllerImpl class:
 /** @scr.reference cardinality=0..1 policy=dynamic */
 private ConfigurationAdmin configAdmin;
 To reproduce, apply the attached patch to revision 776315 of  
 http://svn.apache.org/repos/asf/incubator/sling/trunk/contrib/extensions/jcrinstall,
  and run the tests with mvn clean install.
 The OsgiControllerTest.testDeferredConfigInstall test then fails, because the 
 ConfigurationAdmin service is not rebound to the OsgiControllerImpl class, 
 after waiting up to 5 seconds for that to happen.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (FELIX-1166) SCR does not rebind ConfigurationAdmin service in Sling jcrinstall tests

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on FELIX-1166:


Note that this should not be related to Pax Exam, but I'm mentioning it as the 
rebinding mechanism seems to generally work in SCR 1.0.8, so there might be a 
weirdness related to this particular testing environment.

 SCR does not rebind ConfigurationAdmin service in Sling jcrinstall tests
 

 Key: FELIX-1166
 URL: https://issues.apache.org/jira/browse/FELIX-1166
 Project: Felix
  Issue Type: Bug
  Components: Declarative Services (SCR)
Affects Versions: scr-1.0.8
Reporter: Bertrand Delacretaz
 Attachments: FELIX-1166-reproduce.patch


 I'm testing the Sling jcrinstall module using Pax Exam, and the SCR reference 
 shown below is not rebound after stopping and restarting the 
 org.apache.felix.configadmin bundle, and waiting up to 5 seconds.
 The reference is declared like this in the OsgiControllerImpl class:
 /** @scr.reference cardinality=0..1 policy=dynamic */
 private ConfigurationAdmin configAdmin;
 To reproduce, apply the attached patch to revision 776315 of  
 http://svn.apache.org/repos/asf/incubator/sling/trunk/contrib/extensions/jcrinstall,
  and run the tests with mvn clean install.
 The OsgiControllerTest.testDeferredConfigInstall test then fails, because the 
 ConfigurationAdmin service is not rebound to the OsgiControllerImpl class, 
 after waiting up to 5 seconds for that to happen.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (FELIX-1061) [PATCH] webconsole silently ignores bundles which have no Bundle-SymbolicName header

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz updated FELIX-1061:
---

Attachment: FELIX-1061.patch

 [PATCH] webconsole silently ignores bundles which have no Bundle-SymbolicName 
 header
 

 Key: FELIX-1061
 URL: https://issues.apache.org/jira/browse/FELIX-1061
 Project: Felix
  Issue Type: Bug
  Components: Web Console
Reporter: Bertrand Delacretaz
Priority: Minor
 Attachments: FELIX-1061.patch


 Trying to install a bundle which has no Bundle-SymbolicName header silently 
 fails with the current console, there no error report in the log or in the 
 web browser.
 Other exceptions during bundle installation are also invisible from the 
 console web interface, they are only logged.
 With the attached patch, exceptions during bundle installation cause a 500 
 HTTP status and exception report in the web browser, and the InstallAction 
 throws an IOException if a bundle has no Bundle-SymbolicName.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (FELIX-1061) [PATCH] webconsole silently ignores bundles which have no Bundle-SymbolicName header

[Bertrand Delacretaz (JIRA)]

[PATCH] webconsole silently ignores bundles which have no Bundle-SymbolicName 
header


 Key: FELIX-1061
 URL: https://issues.apache.org/jira/browse/FELIX-1061
 Project: Felix
  Issue Type: Bug
  Components: Web Console
Reporter: Bertrand Delacretaz
Priority: Minor


Trying to install a bundle which has no Bundle-SymbolicName header silently 
fails with the current console, there no error report in the log or in the web 
browser.

Other exceptions during bundle installation are also invisible from the console 
web interface, they are only logged.

With the attached patch, exceptions during bundle installation cause a 500 HTTP 
status and exception report in the web browser, and the InstallAction throws an 
IOException if a bundle has no Bundle-SymbolicName.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (FELIX-961) 100% CPU looping inside uses calculation

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on FELIX-961:
---

I have seen similar problems when working on the Sling jcrinstall module, 
framework seems to hang but is really only spending *lots* of time in the 
R4SearchPolicyCore.findConsistentClassSpace() method.

Looks like my problem is more likely to happen with JDK 1.6 than with JDK 1.5: 
the test scenario below always passes with 1.5 but hangs almost every time 
with 1.6 (macosx, java versions 1.6.0-dp and 1.5.0_16).

Note that I'm still running V1.0.4 of the Felix framework for those tests, so 
not sure if it's the same problem.

Here's my test scenario FWIW.

Uses the Felix webconsole mounted at /system/console.

1. Install about 80 bundles (can't share those, sorry) via the console, using a 
loop of CURL commands like

curl -F action=install -fbundlefi...@$f 
http://admin:ad...@localhost:4502/system/console/bundles

2. Try to start all bundles using a loop of CURL commands like

curl -d action=start http://admin:ad...@localhost:4502/system/console/bundles/N

with N ranging from 20 (the number of bundles installed before 1.) to 150

With JDK 1.6, step 2. very often hangs when the first bundle is started (HTTP 
response does not come), and jconsole shows the SCR Actor thread spending all 
its time inside R4SearchPolicyCore.findConsistentClassSpace() 

 100% CPU looping inside uses calculation
 

 Key: FELIX-961
 URL: https://issues.apache.org/jira/browse/FELIX-961
 Project: Felix
  Issue Type: Bug
  Components: Framework
Affects Versions: felix-1.4.1
Reporter: Stuart McCulloch
 Attachments: USES_TESTCASE.zip, USES_TESTCASE2.zip


 While investigating a problem report against pax-runner 
 (http://article.gmane.org/gmane.comp.java.ops4j.general/6778) I found it was 
 actually caused by a 100% CPU loop inside the uses calculation code. In 
 Felix 1.4.1 this was stopping the shell bundle from activating, hence the 
 lack of console. Using the trunk build I can get a console, but the looping 
 still occurs with the testcase.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Moving the Sling Management Console to Apache Felix

[Bertrand Delacretaz]

On Fri, Apr 11, 2008 at 9:47 AM, Felix Meschberger [EMAIL PROTECTED] wrote:

 ... Point is, if we can show to the IPMC that both communities are
  interested in this move - shown by a vote in both places - this should
  not be a problem to the IPMC

Ok, let's have those votes then. I'm also on the IPMC, so I'll support
our case there if needed.

-Bertrand

Re: Moving the Sling Management Console to Apache Felix

[Bertrand Delacretaz]

On Thu, Apr 10, 2008 at 10:19 AM, Felix Meschberger [EMAIL PROTECTED] wrote:

 ...As such we (Richard Hall, Marcel Offermans, Karl Pauls,
  Carsten Ziegeler and me) discussed that it might be a good idea to move
  this console to the Apache Felix project...

And me! +1 to that.

And thanks to those Felix people for attending our Sling BOF yesterday
evening, much appreciated!

-Bertrand

Re: Procedure for performing a release

[Bertrand Delacretaz]

On Dec 21, 2007 10:41 PM, Stefano Lenzi [EMAIL PROTECTED] wrote:

 ...I'd like to know if there
 is a document describing the procedure for performing a release

I cannot help with Felix-specific information, but you can have a look
at http://www.apache.org/dev/#releases for general information about
releases at the ASF. I also wrote a blog post about this a while ago
at http://codeconsult.ch/bertrand/archives/000759.html

-Bertrand

[jira] Created: (FELIX-353) Garbled scr.property name when serialVersionUID declaration is present

[Bertrand Delacretaz (JIRA)]

Garbled scr.property name when serialVersionUID declaration is present
--

 Key: FELIX-353
 URL: https://issues.apache.org/jira/browse/FELIX-353
 Project: Felix
  Issue Type: Bug
  Components: Maven SCR Plugin
 Environment: macosx / JDK 1.5 / maven-scr-plugin V0.3.0-SNAPSHOT
Reporter: Bertrand Delacretaz
Priority: Minor


Processing the following code with mvn scr:scr generates a garbled 
scr.property name in serviceComponents.xml:

package org.apache.felix.bugreports;

/** @scr.component */
public class TestScrProperty {

// the scr.property name is correctly generated
// if the following declaration is commented out
private static final long serialVersionUID = 5710195320616458465L;

   // this comment should not be part of the
   // scr.property name, but it is

/** @scr.property value=something */
private final static String S = whatever;
}

Leads to a bad scr:property name:

?xml version=1.0 encoding=UTF-8?
components xmlns:scr=http://www.osgi.org/xmlns/scr/v1.0.0;
scr:component enabled=true immediate=true 
name=org.apache.felix.bugreports.TestScrProperty
scr:implementation class=org.apache.felix.bugreports.TestScrProperty/
scr:property name=// this comment should not be part of the #10;   // 
scr.property name, but it is#10;#10;   #10;  quot;whatever 
value=something/
/scr:component
/components

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (FELIX-353) Garbled scr.property name when serialVersionUID declaration is present

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz updated FELIX-353:
--

Attachment: pom.xml

the pom.xml that I'm using

 Garbled scr.property name when serialVersionUID declaration is present
 --

 Key: FELIX-353
 URL: https://issues.apache.org/jira/browse/FELIX-353
 Project: Felix
  Issue Type: Bug
  Components: Maven SCR Plugin
 Environment: macosx / JDK 1.5 / maven-scr-plugin V0.3.0-SNAPSHOT
Reporter: Bertrand Delacretaz
Priority: Minor
 Attachments: pom.xml


 Processing the following code with mvn scr:scr generates a garbled 
 scr.property name in serviceComponents.xml:
 package org.apache.felix.bugreports;
 /** @scr.component */
 public class TestScrProperty {
 // the scr.property name is correctly generated
 // if the following declaration is commented out
 private static final long serialVersionUID = 5710195320616458465L;
// this comment should not be part of the
// scr.property name, but it is
 /** @scr.property value=something */
 private final static String S = whatever;
 }
 Leads to a bad scr:property name:
 ?xml version=1.0 encoding=UTF-8?
 components xmlns:scr=http://www.osgi.org/xmlns/scr/v1.0.0;
 scr:component enabled=true immediate=true 
 name=org.apache.felix.bugreports.TestScrProperty
 scr:implementation class=org.apache.felix.bugreports.TestScrProperty/
 scr:property name=// this comment should not be part of the #10;   // 
 scr.property name, but it is#10;#10;   #10;  quot;whatever 
 value=something/
 /scr:component
 /components

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (FELIX-353) Garbled scr.property name when serialVersionUID declaration is present

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on FELIX-353:
---

Confirmed, revision #572968 processes my example correctly, thanks!

 Garbled scr.property name when serialVersionUID declaration is present
 --

 Key: FELIX-353
 URL: https://issues.apache.org/jira/browse/FELIX-353
 Project: Felix
  Issue Type: Bug
  Components: Maven SCR Plugin
 Environment: macosx / JDK 1.5 / maven-scr-plugin V0.3.0-SNAPSHOT
Reporter: Bertrand Delacretaz
Priority: Minor
 Attachments: pom.xml


 Processing the following code with mvn scr:scr generates a garbled 
 scr.property name in serviceComponents.xml:
 package org.apache.felix.bugreports;
 /** @scr.component */
 public class TestScrProperty {
 // the scr.property name is correctly generated
 // if the following declaration is commented out
 private static final long serialVersionUID = 5710195320616458465L;
// this comment should not be part of the
// scr.property name, but it is
 /** @scr.property value=something */
 private final static String S = whatever;
 }
 Leads to a bad scr:property name:
 ?xml version=1.0 encoding=UTF-8?
 components xmlns:scr=http://www.osgi.org/xmlns/scr/v1.0.0;
 scr:component enabled=true immediate=true 
 name=org.apache.felix.bugreports.TestScrProperty
 scr:implementation class=org.apache.felix.bugreports.TestScrProperty/
 scr:property name=// this comment should not be part of the #10;   // 
 scr.property name, but it is#10;#10;   #10;  quot;whatever 
 value=something/
 /scr:component
 /components

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (FELIX-349) metatype.xml generated by Maven SCR plugin is not well-formed

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on FELIX-349:
---

That was quick, thanks!

The metatype.xml is indeed well-formed using the 0.3.0-SNAPSHOT version of the 
plugin. 

I don't have karma to close this issue, so feel free to do it.

 metatype.xml generated by Maven SCR plugin is not well-formed
 -

 Key: FELIX-349
 URL: https://issues.apache.org/jira/browse/FELIX-349
 Project: Felix
  Issue Type: Bug
  Components: Maven SCR Plugin
 Environment: macosx / JDK 1.5
Reporter: Bertrand Delacretaz
Assignee: Carsten Ziegeler
 Fix For: 1.0.0

 Attachments: metatype.xml


 I'm using the maven-scr-plugin 0.2.0, and the generated metatype.xml is not 
 well-formed.
 From the example below, it looks like only the last metatype:Option is 
 closed, inside a metatype:OCD/
 metatype:OCD id=org.apache.sling.core.log.RequestLoggerFilter 
 name=%request.log.name description=%request.log.description
 metatype:AD id=service.description name=%service.description.name 
 description=%service.description.description/
 metatype:AD id=service.vendor name=%service.vendor.name 
 description=%service.vendor.description/
 metatype:AD id=request.log.output name=%request.log.output.name 
 description=%request.log.output.description/
 metatype:AD id=request.log.outputtype type=Integer 
 name=%request.log.outputtype.name 
 description=%request.log.outputtype.description
 metatype:Option value=0 label=Logger Name
 metatype:Option value=1 label=File
 metatype:Option value=Name label=RequestLog/
 metatype:AD id=request.log.enabled type=Boolean 
 name=%request.log.enabled.name 
 description=%request.log.enabled.description/
 metatype:AD id=access.log.output name=%access.log.output.name 
 description=%access.log.output.description/
 metatype:AD id=access.log.outputtype type=Integer 
 name=%access.log.outputtype.name 
 description=%access.log.outputtype.description
 metatype:Option value=0 label=Logger Name
 metatype:Option value=1 label=File
 metatype:Option value=Name label=RequestLog/
 metatype:AD id=access.log.enabled type=Boolean 
 name=%access.log.enabled.name 
 description=%access.log.enabled.description/
 /metatype:OCD
 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (FELIX-349) metatype.xml generated by Maven SCR plugin is not well-formed

[Bertrand Delacretaz (JIRA)]

metatype.xml generated by Maven SCR plugin is not well-formed
-

 Key: FELIX-349
 URL: https://issues.apache.org/jira/browse/FELIX-349
 Project: Felix
  Issue Type: Bug
  Components: Maven SCR Plugin
 Environment: macosx / JDK 1.5
Reporter: Bertrand Delacretaz


I'm using the maven-scr-plugin 0.2.0, and the generated metatype.xml is not 
well-formed.

From the example below, it looks like only the last metatype:Option is 
closed, inside a metatype:OCD/

metatype:OCD id=org.apache.sling.core.log.RequestLoggerFilter 
name=%request.log.name description=%request.log.description
metatype:AD id=service.description name=%service.description.name 
description=%service.description.description/
metatype:AD id=service.vendor name=%service.vendor.name 
description=%service.vendor.description/
metatype:AD id=request.log.output name=%request.log.output.name 
description=%request.log.output.description/
metatype:AD id=request.log.outputtype type=Integer 
name=%request.log.outputtype.name 
description=%request.log.outputtype.description
metatype:Option value=0 label=Logger Name
metatype:Option value=1 label=File
metatype:Option value=Name label=RequestLog/
metatype:AD id=request.log.enabled type=Boolean 
name=%request.log.enabled.name 
description=%request.log.enabled.description/
metatype:AD id=access.log.output name=%access.log.output.name 
description=%access.log.output.description/
metatype:AD id=access.log.outputtype type=Integer 
name=%access.log.outputtype.name 
description=%access.log.outputtype.description
metatype:Option value=0 label=Logger Name
metatype:Option value=1 label=File
metatype:Option value=Name label=RequestLog/
metatype:AD id=access.log.enabled type=Boolean 
name=%access.log.enabled.name description=%access.log.enabled.description/
/metatype:OCD


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.