Re: [VOTE] Apache Felix Dependency Manager Release R9

[Marcel Offermans]

+1 …good job Pierre!

Greetings, Marcel

Re: [VOTE] Apache Felix Dependency Manager Release R7

[Marcel Offermans]

Hello Pierre,
On 1 March 2016 at 10:01:01, Pierre De Rop (pierre.de...@gmail.com) wrote:

(I don't know if I *must* wait for 72 hours before canceling and restarting 
the vote, or if I can restart it today ?) 
No need to wait, just start a new vote today.

Greetings, Marcel

Re: Git dies of lack of interest?

[Marcel Offermans]

Hello Benson,

There is, at least, substantial apathy about git on the part of the 
sub-communities that work on some of the sub-projects. In my view, 
this apathy, including perhaps a bit of antipathy, sunk the discussion 
of just converting as one big repo. As I see it, Felix is a bit of a 
loose confederation, and Ray's suggestion is consistent with letting 
each of the tribes make up its own mind. 
I am not sure if the apathy is related to converting as one big repository.

Let me speak for myself here, I don’t see compelling arguments for moving to 
Git. What problem are we solving here? Why is moving to Git the right solution? 
That’s where my lack of enthusiasm comes from. Nobody has yet explained that to 
me. And splitting the project so each subproject ends up in a different 
repository sounds even less appealing to me (which I am afraid will happen if 
we just start moving one, or a few, subprojects). I would be in favour of a 
plan where we either move every subproject, or none at all. And before we start 
the move, please come up with a plan that outlines the steps that need to be 
taken. Maybe even physically do the migration and demonstrate that things like 
our release processes are still working. And yes, that is a lot of work, and 
enough people need to step up and offer their help.

Greetings, Marcel

Re: [DS] gogo command missing help from descriptors

[Marcel Offermans]

On 11 Sep 2015 at 17:56:01, David Jencks (david_jen...@yahoo.com.invalid) wrote:
Similar considerations would apply to the non-gogo legacy command. Do we still 
need to support this command? 
For Dependency Manager 4 we have dropped support for the legacy Felix and 
Equinox commands and only provide gogo commands. Obviously that does not mean 
we need to do the same for DS, but it’s worth mentioning.

Greetings, Marcel

Re: git?

[Marcel Offermans]

I would be more comfortable if we first had someone volunteer to adapt all 
(Maven and Ant/Gradle based builds) to work with Git and otherwise ensure that 
all projects keep working. Then demonstrate all of that (with a copy of our 
repository), and update our documentation to reflect the new processes before 
we decide on making such a move. I have a feeling this is going to be a lot of 
work and it could break quite a few processes that we currently have which is 
why I don’t think we should “just switch” and then try to pick up the broken 
pieces.

Greetings, Marcel

On 31 October 2015 at 22:01:01 , Oliver Lietz (apa...@oliverlietz.de) wrote:

On Friday 30 October 2015 06:41:09 Benson Margulies wrote:  
> On Fri, Oct 30, 2015 at 2:36 AM, Carsten Ziegeler   
wrote:  
> > Am 30.10.15 um 01:48 schrieb Benson Margulies:  
> >> Is this a consensus to proceed yet? It's been a few days since the  
> >> last contribution.  
> >  
> > We clearly have different opinions, they range from "why change?",  
> > "let's get moving" to "let's do more than a simple conversion".  
> > I don't see a clear consensus/agreement on any of the three. For each  
> > opinion there are imho good/valid arguments. I have the feeling that a  
> > formal vote does not lead us anywhere.  
> >  
> > Maybe someone can clearly identify/list the benefits for everyone if we  
> > move from svn to a single git repo - compared to using the already  
> > existing git proxy. I think this should give everyone a clear view of  
> > why the migration makes sense. And if there are no compelling reasons  
> > then we have a decision as well.  
>  
> I think I can state some advantages:  
>  
>  
> 1: Make it significantly easier to apply patches from people who  
> provide them via github.  
>  
> 2: Make it significantly easier to create branches in the main repo  
> for collaborative changes.  
>  
> 3: Take a first step towards subdividing into multiple repos where  
> that makes sense.  

some more:  

https://issues.apache.org/jira/browse/SLING-3987  
https://cwiki.apache.org/confluence/display/SLING/Move+from+Subversion+to+Git  

Is there already a project at Apache which moved from Subversion to Git  
setting up multiple repos or even a repo per release artifact?  

Regards,  
O.  

> My sense of the email thread is that we have some enthusiastic  
> supporters of moving to git, and some '+0' weak objectors. So, in some  
> models of consensus process, that would be a reason to go ahead. Do  
> you want to recast this as a VOTE as a way of clarifying views?  
>  
> > Carsten  
> > --  
> > Carsten Ziegeler  
> > Adobe Research Switzerland  
> > cziege...@apache.org  

Re: git?

[Marcel Offermans]

Within Felix we have “subprojects” that consist of one or more bundles and I 
would argue that they are always released together. This does not mean that for 
every release, every bundle needs to change, sometimes only a subset of the 
released bundles change.

So I would definitely argue against getting a Git repository per bundle. Per 
subproject sounds like the right granularity to me.

Regarding Maven I don’t have much experience on how to set that up with Git. 
Note that not all subprojects use Maven. Specifically the “dependency manager” 
uses a gradle/bndtools based setup. We could easily move that to its own Git 
repository. It is already setup for that.

In general I like Git, and outside of the Apache projects I’m involved in I 
almost exclusively use it, but I’m +0 on making a switch because it’s also a 
lot of work and I don’t think the benefits are huge. If it works, don’t fix it. 
:)

Greetings, Marcel

On 24 October 2015 at 11:06:02, Benson Margulies (ben...@basistech.com) wrote:

Here's the basic issue. The maven-release-plugin doesn't always work  
with git when the pom you are releasing is not the top of the  
repository. I put a great deal of work into fixing it, and yet others  
continue to report problems. (It works for my favorite test case.)  

So, the conservative strategy is to put each group that are released  
together into a repo.  

As far as migration, INFRA only understands 'one big flip.' That  
offers us two choices if our goal is to subdivide:  

1: Let infra do the flip, and then gradually get new repos and move  
some things into them.  

2: Do our own migration: one by one, get infra to make new, empty,  
repos, and use the existing mirror repo as a source to push the pieces  
into them.  

I don't see much value in item #1 over item #2. So I'd propose to  
start by asking infra for a repo for the overall parent pom, which I  
think needs to live in a repo by itself (that's how we do it at  
Maven). Once we have released the pom from there, we can migrate  
others in whatever grouping we prefer.  

As the new committer here, I have to ask: what decision-making process  
would be good?  




On Sat, Oct 24, 2015 at 1:00 AM, David Jencks  wrote: 
 
> YAY!!  
>  
> as you can tell, I’m in favor of it.  
>  
> I think that 1 repo per project may be too small. For instance I think it 
> makes sense to have one repo for the 3 gogo projects, even though they are 
> released separately. I think soon there will be at least 4 scr projects and 
> I’d like them to be in 1 repo.  
>  
> Do you know how infra feels about gradual migration? Are they fine with it or 
> do they prefer all-at-once?  
>  
> thanks  
> david jencks  
>  
>> On Oct 23, 2015, at 10:36 PM, Benson Margulies  wrote: 
>>  
>>  
>> There was some discussion a while back about git, which I recall  
>> (perhaps inaccurately) as vaguely positive. It's a lot easier if each  
>> releasable thing gets its own git repo.  
>>  
>> How do folks feel about starting with a migration of the bundle plugin?  
>>  
>> --benson  
>  

Re: September Board Report

[Marcel Offermans]

Reviewed the report. I have nothing to add.

Greetings, Marcel

Re: Felix Connect?

[Marcel Offermans]

And some documentation can be found in this presentation:

http://archive.apachecon.com/eu2012/presentations/08-Thursday/RN-OSGi_FFT/aceu-2012-felix-connect.pdf

On 18 Aug 2015 at 16:21:01, Bertrand Delacretaz (bdelacre...@apache.org) wrote:

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 

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

[Marcel Offermans]

Go for it!

On 29 Jul 2015 at 08:36:01, Carsten Ziegeler (cziege...@apache.org) wrote:

Hi, 

we have modules for R4 of org.osgi.core, org.osgi.compendium and 
org.osgi.foundation. As these are officially available in the maven 
repo, I guess we can get rid of those. 

If no one objects, I'll remove them from trunk 

Carsten 
-- 
Carsten Ziegeler 
Adobe Research Switzerland 
cziege...@apache.org 

Re: June Board Report

[Marcel Offermans]

Did some small corrections to the DM4 releases in the report.

On 10 Jun 2015 at 10:46:03 , Carsten Ziegeler (cziege...@apache.org) wrote:

I've created a draft for the board report at: 

https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=53739940 

Not much to report, but I'm sure I'm missing some releases. Feel free to 
add missing pieces. 

Thanks 
Carsten 
-- 
Carsten Ziegeler 
Adobe Research Switzerland 
cziege...@apache.org 

Re: [VOTE] Apache Felix Dependency Manager Release Candidate R5

[Marcel Offermans]

+1 (binding)

Checked the signatures, built the sources, ran all the tests. Thanks Pierre!

Greetings, Marcel

Re: [VOTE] Apache Felix Dependency Manager Release Candidate R4

[Marcel Offermans]

First of all:

+1 (binding)

After reading up on the discussion, I do not agree that there is a problem that 
is big enough to cancel the release as Pierre proposes for the following 
reasons:

1) At Apache, we vote on the source code of the release. The binaries are there 
for convenience. I don’t see anything wrong with the sources other than the 
fact that adding that “-removeheaders” statement is probably a good idea.

2) There is nothing really wrong with the binaries either. Semantically they 
have the same version, because they have the same content. The only difference 
as far as I understand are these non-standard headers. Sure you can argue that 
that makes them different, but if you load the bundle into an OSGi framework, 
you end up with exactly the same code.

Sure we can further optimise our release process, but this release complies 
with the procedure we have. A discussion about including unmodified binaries is 
something we should have separate from this release vote.

Greetings, Marcel

On 5 Jun 2015 at 12:36:02 , Pierre De Rop (pierre.de...@gmail.com) wrote:

Thanks Bram,  

I'm cancelling this release.  

I like your suggestion that just consists in picking up the unmodified  
bundles from the releaserepo if not modified at all. That is safe and is  
making sense.  

I will just modify the gradle script in order to support a parameter that I  
will use to specify the list of bundles I want to release, and then other  
bundles will be simply picked up from the releaserepo. I will also update  
the release process in the README file.  

cheers  
/Pierre  

On Fri, Jun 5, 2015 at 12:18 PM, Bram de Kruijff bdekrui...@gmail.com  
wrote:  

 On Fri, Jun 5, 2015 at 12:11 PM, Pierre De Rop pierre.de...@gmail.com  
 wrote:  
  So, is there an existing bnd directive that can disable the generation of  
  the Bnd-LastModified header ? this would then resolve the issue ?  
   
  
 -removeheaders: Bnd-LastModified,Tool,Created-By  
  
 grz  
 Bram  
  
  thanks  
  /Pierre  
   
   
  On Fri, Jun 5, 2015 at 11:46 AM, Pierre De Rop pierre.de...@gmail.com  
  wrote:  
   
  Hello Bram,  
   
  First, thanks for your checks. no problem if I have to cancel this  
  release. But before, can we discuss in order to clarify and confirm  
 your -1:  
   
  So, the latest version of the runtime bundle comes from the R2 release  
  (runtime-4.0.1), and the runtime bundle has not been changed in R3, and  
 R4.  
  That is why the version is unchanged, but binary is different only  
 because  
  of the Bundle-LastModified headers are different, as you said (I just  
  verified that):  
   
  R3 - Bnd-LastModified  
  1432232347449  
  R4 - Bnd-LastModified  
  1433450664064  
   
   
  Let me explain with more details the process I'm using, and confirm if  
 I'm  
  reasoning write or wrong:  
   
  So:  
   
  1) the baselining is performed against the cnf/releaserepo, where there  
 is  
  still the org.apache.felix.dependencymanager.runtime-4.0.0.jar version  
  (R1).  
   
  2) The last time I modified the runtime was done in R2, that's why I did  
  not modify the cnf/releaserepo where I still have the runtime 4.0.0  
  version. At the time I modified the runtime before release R2, then  
  bndtools proposed me to increment the runtime version to 4.0.1  
   
  3) Now, the next time I will modify the runtime, I will then update the  
  releaserepo with runtime-4.0.1. So, then, when I will start to modify  
 the  
  runtime (before release R5 for example), then bndtools baselining will  
  propose me to increment the version for the runtime bundle (to 4.0.2 for  
  example).  
   
  so, can you please confirm your -1 ? if your confirm -1, then can you  
  please suggest how I should then make the next release ?  
   
  Indeed, with Marcel, we previously agreed on the fact that a release  
  should include all binary artifacts.  
  So, I could systematically increment the bundle version even if the  
  bundles have not been modified (by systematically updating the  
 releaserepo  
  with all previously released bundles), but then I think it would be  
 weird  
  to increment a bundle version even if it has not been changed ?  
   
  thanks;  
  /Pierre  
   
   
   
   
   
  On Fri, Jun 5, 2015 at 10:29 AM, Bram de Kruijff bdekrui...@gmail.com  
  wrote:  
   
  On Thu, Jun 4, 2015 at 11:17 PM, Pierre De Rop pierre.de...@gmail.com  
   
  wrote:  
   Hello all,  

   I would like to call for a vote on the Dependency Manager toplevel  
  release  
   R4.  

   We solved the following issues:  

   Release Notes - Felix - Version org.apache.felix.dependencymanager-r4  

   ** Bug  
   * [FELIX-4907] - ConfigurationDependency calls updated(null) when  
   component is stopped.  
   * [FELIX-4910] - ComponentExecutorFactory does not allow to  
 return  
  null  
   from getExecutorFor method.  
   * [FELIX-4913] - DM Optional callbacks may sometimes be invoked  
  twice  

   ** Improvement  

[jira] [Commented] (FELIX-4907) ConfigurationDependency calls updated(null) when component is stopped.

[Marcel Offermans (JIRA)]

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

Marcel Offermans commented on FELIX-4907:
-

I think the DM3 behaviour makes sense. It only invokes updated(null) if the 
configuration is indeed deleted, and that leaves the component the opportunity 
to react on that (if it wants to do something). Only after that the component 
is then stopped.

 ConfigurationDependency calls updated(null) when component is stopped.
 --

 Key: FELIX-4907
 URL: https://issues.apache.org/jira/browse/FELIX-4907
 Project: Felix
  Issue Type: Bug
  Components: Dependency Manager
Affects Versions: org.apache.felix.dependencymanager-r3
Reporter: Pierre De Rop
Assignee: Pierre De Rop

 When a component has a Configuration Dependency, the updated callback is 
 invoked with a null Dictionary when the omponent is stopped.



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

Re: [VOTE] Apache Felix Dependency Manager Release Candidate R3

[Marcel Offermans]

I tried the script before I voted, and just tried it again on another machine, 
but it works for me. No such looping. Weird.

Greetings, Marcel

On 22 May 2015 at 9:51:02 , David Bosschaert (david.bosscha...@gmail.com) wrote:

It could be me, but when I run the special DM check_staged_release.sh  
script it keeps on looping with:  

Connecting to dist.apache.org (dist.apache.org)|140.211.11.105|:443...  
connected.  
HTTP request sent, awaiting response... 200 OK  
Length: ignored [application/zip]  
Saving to: 
`dmrc3_2/org.apache.felix.dependencymanager-r3/org.apache.felix.dependencymanager-r3-bin.zip'
  

[ = ] 424,207 247K/s in 1.7s  

2015-05-22 08:42:20 (247 KB/s) - Read error at byte 424207 (A TLS  
packet with unexpected length was received.).Retrying.  

--2015-05-22 08:42:30-- (try:11)  
https://dist.apache.org/repos/dist/dev/felix/org.apache.felix.dependencymanager-r3/org.apache.felix.dependencymanager-r3-bin.zip
  
Connecting to dist.apache.org (dist.apache.org)|140.211.11.105|:443...  
connected.  
... and so on ...  

David  

On 22 May 2015 at 06:29, Jean-Baptiste Onofré j...@nanthrax.net wrote:  
 +1 (non binding)  
  
 Regards  
 JB  
  
  
 On 05/21/2015 08:35 PM, Pierre De Rop wrote:  
  
 Hello all,  
  
 I would like to call for a vote on the Dependency Manager toplevel release  
 R3.  
  
 We solved the following issues:  
  
 ** Bug  
 * [FELIX-4858] - DependencyManager: missing createCopy method in  
 timed  
 service dependency  
 * [FELIX-4869] - Callbacks not invoked for dependencies that are  
 added  
 after the component is initialized  
  
 ** Improvement  
 * [FELIX-4614] - Factory create() method should have access to the  
 component definition  
 * [FELIX-4873] - Enhance DM API to get missing and circular  
 dependencies  
 * [FELIX-4876] - DM Annotations bnd plugin compatibility with  
 Bndtools  
 2.4.1 / 3.0.0 versions  
 * [FELIX-4877] - DM Annotations should detect service type using more  
 method signatures.  
 * [FELIX-4878] - Support more signatures for Dependency callbacks  
 * [FELIX-4880] - Missing callback instance support for some adapters  
 * [FELIX-4889] - Refactor dm shell command to use the  
 org.apache.dm.diagnostics api  
  
 ** Wish  
 * [FELIX-4875] - Update DM integration test with latest ConfigAdmin  
  
 You can use this UNIX script to download the release and verify the  
 signatures:  
  
  
 http://svn.apache.org/repos/asf/felix/trunk/dependencymanager/release/check_staged_release.sh
   
  
 Usage:  
 sh check_staged_release.sh r3 /tmp/felix-staging  
  
 This script, unlike the original Felix check_stage_release.sh, is specific  
 to the new Dependency Manager release process (see FELIX-4818) and will  
 download staging from https://dist.apache.org/repos/dist/dev/felix instead  
 of http://repository.apache.org/content/repositories.  
  
 To rebuild the DM binaries from the source, you can then refer to  
  
 https://svn.apache.org/repos/asf/felix/trunk/dependencymanager/release/resources/src/README.src
   
  
 Please vote to approve this release:  
  
 [ ] +1 Approve the release  
 [ ] -1 Veto the release (please provide specific comments)  
  
 This vote will be open for 72 hours.  
  
 Thank you;  
 /Pierre  
  
  
 --  
 Jean-Baptiste Onofré  
 jbono...@apache.org  
 http://blog.nanthrax.net  
 Talend - http://www.talend.com  

[jira] [Commented] (FELIX-4844) Store configuration data in a diff-tool friendly way

[Marcel Offermans (JIRA)]

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

Marcel Offermans commented on FELIX-4844:
-

ConfigurationAdmin offers a method to create a new configuration with a 
pre-defined service.pid so I don't see your problem. In fact, the ability to 
create a configuration for a service.pid (regardless of whether the associated 
service exists or not) was one of the use cases of the specification. So making 
an import/export like bundle (similar to File Installer) is probably your best 
option. That way you don't depend on any implementation detail.

 Store configuration data in a diff-tool friendly way
 

 Key: FELIX-4844
 URL: https://issues.apache.org/jira/browse/FELIX-4844
 Project: Felix
  Issue Type: Wish
  Components: Configuration Admin
Reporter: Balazs Zsoldos

 We store our configuration with the sources in the source-code control system 
 (git). It often happens that multiple developers work on the same project and 
 they modify the configuration parallel. It would not be a problem if the 
 config files were diff-tool friendly. To achieve this goal, two improvements 
 would be necessary:
 *Store entries in alphabetically ordered list*
 In the config files, the entries should be stored sorted by ABC. It is easy 
 to implement by overriding HashTable in the same way that LinkedHashMap 
 overrides HashMap.
 *Store array values in multiple lines*
 At the moment a setting with two values are stored like this:
 key=[value1, value2]
 Instead of this, I would store it in the following format (each entry on new 
 line):
 key=[ \
   value1, \
   value2 \
   ]
 *Question*
 Do you think that if I prepare a patch for this, that would be accepted?



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

Re: [DISCUSS] Release Felix metatype

[Marcel Offermans]

On 14 Apr 2015 at 15:41:01, Jan Willem Janssen (janwillem.jans...@luminis.eu) 
wrote:
Any objections to cut a release for Felix Metatype? 
Not at all, go for it!

Greetings, Marcel

Re: [VOTE] Apache Felix Dependency Manager Release Candidate R2

[Marcel Offermans]

+1 (binding)

Checked the signatures, compiled from source, ran all tests. Looking good!

Greetings, Marcel

Re: Our old website at /site/...

[Marcel Offermans]

Done.

I’ve removed everything under /site/ and updated our templates to no longer 
generate a reference to anything that was there. What I did not do is remove 
the header from each page that still wanted to render that link to /site/ but 
if someone cares about that, feel free to do so (it affects a little over 200 
pages).

I also removed all references that referred to the transition from the 
Confluence CMS to Apache CMS from the home page.

Greetings, Marcel

On 12 Mar 2015 at 11:46:01 , Carsten Ziegeler (cziege...@apache.org) wrote:

Am 11.03.15 um 19:49 schrieb Marcel Offermans:  
 Hey all,  
  
 We still have a lot of old files hosted at /site/… and I would propose we 
 remove all of them as it is confusing to our users to even find these old 
 pages.  
  
 WDYT?  
  
Makes sense, +1  

Carsten  

--  
Carsten Ziegeler  
Adobe Research Switzerland  
cziege...@apache.org  

Our old website at /site/...

[Marcel Offermans]

Hey all,

We still have a lot of old files hosted at /site/… and I would propose we 
remove all of them as it is confusing to our users to even find these old pages.

WDYT?

Greetings, Marcel

Re: [RESULT] [VOTE] Release bundle repository 2.0.4, configadmin 1.8.2, file install 3.5.0, gogo-runtime 0.16.0, utils 1.8.0

[Marcel Offermans]

Hello Guillaume,
On 11 Mar 2015 at 10:11:01, Guillaume Nodet (gno...@apache.org) wrote:

2015-03-11 9:51 GMT+01:00 Marcel Offermans marcel.offerm...@luminis.nl: 

 Guillaume, all, I am a bit confused here. 
 
 First of all, I doubt that you are allowed to “modify” a vote that is 
 ongoing. People voted on a set of artifacts, if you modify that set, you 
 need to start a new vote. Also, the subject and this message still refers 
 to the gogo-runtime 0.16.0, so you did not even completely remove that from 
 this vote, causing more confusion. 

The other artifacts have not changed at all, so while the set of artifacts 
to release is changed, the artifacts have not. I don't see why the vote 
for artifacts that have not been removed or changed would become invalid. 

That would be the case if the artifacts were not really independent, but in 
this case, I could have started several votes and the result would have 
been the same (with I agree, less confusion). 
Formally, I don’t think it matters. If you group source code in a single vote, 
you simply cannot remove parts of it from the vote and continue. Of course I 
understand these are different bundles, but that, at least in my opinion, does 
not matter. I also don’t see anything documenting such a procedure in our or 
Apache’s general release guide. That is why I am asking for clarification and 
opinions of others about this.

 I would be in favor of a completely new vote on these artifacts, but I’m 
 happy to hear what others think about this. 

I've sent an email with the result of the vote already and they have been 
published. 
I suppose that you either missed that, or you're talking about a future 
policy. 
I did see that, but I don’t think the procedure was correct, or at least I 
would like some other PMC members or committers to comment on this. So we can 
either change our release guide to specifically allow this, or agree that we 
don’t in which case we can discuss what to do, if anything, with artifacts that 
we accidentally released.

I think the confusion comes from me launching a single vote for multiple 
independent artifacts. We could avoid that in the future if that causes 
too much confusion. 
I agree that’s where the confusion starts. We have no such concept in our 
procedures that defines “independent artifacts” so whatever you decide to 
group, that is what you vote on and that vote either passes, or it does not. 
It’s a trade-off you have to decide on when preparing the release. The more you 
group, the less work you have, but the higher the chance that something is 
wrong and you have to redo everything again.

Greetings, Marcel

Re: [RESULT] [VOTE] Release bundle repository 2.0.4, configadmin 1.8.2, file install 3.5.0, gogo-runtime 0.16.0, utils 1.8.0

[Marcel Offermans]

Guillaume, all, I am a bit confused here.

First of all, I doubt that you are allowed to “modify” a vote that is ongoing. 
People voted on a set of artifacts, if you modify that set, you need to start a 
new vote. Also, the subject and this message still refers to the gogo-runtime 
0.16.0, so you did not even completely remove that from this vote, causing more 
confusion.

I would be in favor of a completely new vote on these artifacts, but I’m happy 
to hear what others think about this.

Greetings, Marcel

On 10 Mar 2015 at 09:41:02, Guillaume Nodet (gno...@apache.org) wrote:

The vote passes with 4 +1s (3 bindings).  
I'll publish the release asap.  

2015-03-05 10:01 GMT+01:00 Guillaume Nodet gno...@apache.org:  

 Hi all,  
  
 Here are a bunch of releases:  
 * bundlerepository 2.0.4  
  
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12327159projectId=12310100
   
 * configadmin 1.8.2  
  
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12324886projectId=12310100
   
  
 * fileinstall 3.5.0  
  
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12328641projectId=12310100
   
 * goto-runtime 0.16.0  
  
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12329377projectId=12310100
   
 * utils 1.8.0  
  
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12329035projectId=12310100
   
  
 Staging repository:  
 https://repository.apache.org/content/repositories/orgapachefelix-1054/  
  
 You can use this UNIX script to download the release and verify the  
 signatures:  
 http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh  
  
 Usage:  
 sh check_staged_release.sh 1054 /tmp/felix-staging  
  
 Please vote to approve this release:  
  
 [ ] +1 Approve the release  
 [ ] -1 Veto the release (please provide specific comments)  
  
 This vote will be open for at least 72 hours.  
  
 Cheers,  
 Guillaume  
  
  

Re: [VOTE] Apache Felix Dependency Manager Release Candidate R1

[Marcel Offermans]

+1 (binding)

Built the code from source and ran all the different tests. Also took the 
bundles and tried them in some simple projects. That works too.

Greetings, Marcel

Re: [VOTE] Release bundle repository 2.0.4, configadmin 1.8.2, file install 3.5.0, gogo-runtime 0.16.0, utils 1.8.0

[Marcel Offermans]

-1

Seeing the same issue as Pierre and Jan Willem reported.

Small note: the copyright message (at least the one that ends up in the 
META-INF/NOTICE) still says 2014, not a showstopper but nevertheless something 
we should fix.

Greetings, Marcel

Re: Needing some help to release Dependency Manager

[Marcel Offermans]

Hello Pierre,

On 4 Mar 2015 at 10:56:00, Pierre De Rop (pierre.de...@gmail.com) wrote:

some progress: while re-reading the Felix release guide, the download page 
can be changed from content/downloads.list (see [1]) , and this file seems 
to contain some macros which are interpreted by another downloads.cgi 
script. 

Then, when releasing DM, will it be possible to add in the downloads.list 
file a hardcoded link to the released DM artifacts, which link will be: 
https://dist.apache.org/repos/dist/release/felix/org.apache.felix.dependencymanager-r1/
 
https://dist.apache.org/repos/dist/release/felix/org.apache.felix.dependencymanager-r1/org.apache.felix.dependencymanager-r1-src.zip
 
? 
The code behind this is actually in lib/view.pm and I added some code there to 
support the slightly different format of the links so that you can still just 
add DM to the downloads.list like any other artifact. Staging confirms that for 
me nicely [1] (and no, I won’t deploy the site like this).

Now, I would like to make a release soon (we still have to update the 
website documentation), so it would be cool if other people could take a 
quick look at https://issues.apache.org/jira/browse/FELIX-4818, in order to 
check if there is no critical problems with this new release process. 
Looks good to me. I’d say let’s move ahead!

Also, does someone knows how to manually release artifacts in maven central 
? 
No, it would be nice if there is some gradle task that generates a pom.xml and 
pushes them. This is however a “nice to have” and we should not block the 
release for it (binaries exist for convenience reasons only anyway).

[1] http://felix.staging.apache.org/downloads.cgi

Greetings, Marcel

[jira] [Commented] (FELIX-4720) Web Console and Gogo rely on Log history buffer in the Log Service

[Marcel Offermans (JIRA)]

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

Marcel Offermans commented on FELIX-4720:
-

The specification does not explicitly state that that history can be empty:

{quote}The Log Reader Service maintains a list of LogEntry objects called the 
log. The Log Reader Service is a service that bundle developers can use to 
retrieve information contained in this log, and receive noti- fications about 
LogEntry objects when they are created through the Log Service.
The size of the log is implementation-specific, and it determines how far into 
the past the log entries go. Additionally, some log entries may not be recorded 
in the log in order to save space. In particular, LOG_DEBUG log entries may not 
be recorded. Note that this rule is implementation-dependent. Some 
implementations may allow a configurable policy to ignore certain LogEntry 
object types.{quote}

Sure, you can interpret it like that, just like you can interpret it the other 
way round and implement an infinite buffer. Both are extremes. If you reason 
like that than you could also say that WebConsole and Gogo do not fail: they 
show everything that is provided. Of course this then becomes a silly 
discussion.

But it is as least as reasonable to ask Equinox to fix this, as it is to ask 
all other bundles that consume the LogReaderService to provide a second cache. 
Or, alternatively, you can provide an extra bundle to provide that cache (and 
publish a LogReaderService for all other consumers).

 Web Console and Gogo rely on Log history buffer in the Log Service
 --

 Key: FELIX-4720
 URL: https://issues.apache.org/jira/browse/FELIX-4720
 Project: Felix
  Issue Type: Bug
  Components: Gogo Command, Web Console
Reporter: Peter Kriens

 The OSGi Log Reader Service has a command to get the history of the log. 
 However, the specification states that this history can be empty. The Equinox 
 framework is nowadays registering a Log Reader Service that has such an empty 
 history to prevent pinning objects in memory. 
 Using the history this way was always at odds with the specification since 
 the history was only intended to hold the start up events. The primary model 
 of the Log Service is a dispatcher.
 I suggest that the Gogo log command and the Web Console maintain their own 
 history buffer to become independent on this fragile history buffer in the 
 Log Reader service.



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

[jira] [Commented] (FELIX-4720) Web Console and Gogo rely on Log history buffer in the Log Service

[Marcel Offermans (JIRA)]

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

Marcel Offermans commented on FELIX-4720:
-

The discussion is about whether or not we should solve this in web console, the 
gogo command and any other consumer of the LogReaderService at all. Or 
elsewhere.

The argument you make about building in all kinds of different options inside 
the implementation and enable them using configuration is only one possible 
solution. Although it's always hard to make generic statements, I would prefer 
a solution where we implement this in a different bundle altogether, and simply 
not deploy that bundle if we don't need it. I would also prefer in this case 
not to implement it for every consumer, but instead change the provider.

Make a small bundle that is a LogListener and that caches the number of entries 
you want. Make that bundle implement a LogReaderService with a higher ranking 
and all consumers can bind to that. No need to change webconsole, or the log 
command, or any other consumer.

 Web Console and Gogo rely on Log history buffer in the Log Service
 --

 Key: FELIX-4720
 URL: https://issues.apache.org/jira/browse/FELIX-4720
 Project: Felix
  Issue Type: Bug
  Components: Gogo Command, Web Console
Reporter: Peter Kriens

 The OSGi Log Reader Service has a command to get the history of the log. 
 However, the specification states that this history can be empty. The Equinox 
 framework is nowadays registering a Log Reader Service that has such an empty 
 history to prevent pinning objects in memory. 
 Using the history this way was always at odds with the specification since 
 the history was only intended to hold the start up events. The primary model 
 of the Log Service is a dispatcher.
 I suggest that the Gogo log command and the Web Console maintain their own 
 history buffer to become independent on this fragile history buffer in the 
 Log Reader service.



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

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

[Marcel Offermans (JIRA)]

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

Marcel Offermans commented on FELIX-4697:
-

Should we re-open that issue and figure out a different way of implementing it?

 Error parsing the default gosh_profile.
 ---

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

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



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

Re: Make DependencyManager API more fluent?

[Marcel Offermans]

Hello Christian,

On 13 Nov 2014 at 14:16:01 , Christian Schneider (ch...@die-schneider.net) 
wrote:

I very much like the idea of a separate builder class. It will make the 
transition very smooth. We can also package it in an extra bundle but I 
do not think there is a technical need for it. So I propose to simply 
add the new syntax in a separate package.
I agree there is no need for it, but in general we do so to keep things 
modular. :) That’s why, for example, we’ve also separated the runtime (that 
acts on annotations after they have been processed and converted into json 
metadata) and some of the other components. So I do have a slight preference to 
keep things separate, but it’s not a decision we need to make upfront so let’s 
first make sure we have a good implementation!

if we want to remove the old syntax at some point then we have to do 
this in a major version. So as 4.0 is quite near we might aim at this 
for 5.0.
Agreed, for now the focus is on getting ready for 4.0, and new builders (and 
some other ideas we have now) can be done as minor updates.

We do not need to introduce the new API (if we keep the old one 
unchanged) in a major version. It is not a breaking change so I think it 
can be introduced in any minor version. Of course we can do it in 
version 4.0 but there is no technical need for it.
Agreed.

Btw. I am at apachecon next week. Would be great if we could take the 
chance to meet in person. 
That’s an excellent idea!

Greetings, Marcel

Re: Make DependencyManager API more fluent?

[Marcel Offermans]

Hey all,

 On 11 Nov 2014, at 0:39 am, Pierre De Rop pierre.de...@gmail.com wrote:
 
 The improvements you are proposing would require a major version bump since
 it's an incompatible API change. But I personally like what you are
 suggesting, and I could quickly do it in the upcoming Dependency Manager
 4.0.0, which is a new major version.

Agreed, we cannot introduce something like this any sooner than in version 4. 
However, it is probably not too hard to implement this yourself on top of the 
current release either, since 80% of what Christian is proposing is just 
renaming existing methods:

If you create your own version of DependencyManagerBase and also wrap classes 
like Component and ServiceDependency/ConfigurationDependency it is quite 
straightforward to delegate from your new set of methods to the existing ones.

This goes in the direction that Paul proposes as well with the builder class.

 But before, I need to know if Marcel is agree to go ahead with all this; so
 for the moment, may be you can just create a Jira issue, and let's wait for
 Marcel to see if he's OK.

I am fairly neutral on this.

Yes, the proposed methods are better aligned with most fluent APIs. However, 
two downsides I see is that it does break the existing API, making it harder 
for people to migrate to version 4 (and, for various reasons, they should do 
that). Also, you are not required to use the fluent style, in some cases you 
end up invoking individual setter methods on DM components and in those cases, 
the fluent style methods might look a bit strange.

Because of this, maybe we should explore the separate builder class that Paul 
suggested!?

 Just one remark: the setters can be easily removed, however I think we
 can't manage to make the component() method automatically add the
 Component to the DependencyManager, because technically; when you add a
 Component to a DependencyManager, the Component is actually *activated*,
 and at this point, all the necessary dependencies have to be already in
 place.

Yes, and there are a few other scenarios as well where you don’t want to 
combine creating and adding a component, so I think we should leave that part 
alone. 

 So, the only possible improvement I'm thinking about for now could have the
 form of this:
 
public void init(BundleContext context, DependencyManager manager)
 throws Exception {
component()
.implementation(DataGenerator.class)
.add(serviceDependency(Store.class).required())
.add(serviceDependency(LogService.class))
.addTo(manager);
}
 
 (notice the addTo method at the end of the sample above, which could just
 add the fully built component to the DependencyManager manager object).

I don’t think that makes the code better. You still have two calls (one to 
create, one to add) and if you forget the addTo(…) it will probably still be 
hard to spot that that was the “bug”. 

 but I propose you first create the Jira issue and see what Marcel thinks.
 
 I will possible add more suggestions in your Jira issue once you will have
 created it (like also using a builder pattern for the aspects/adapters:
 this would allow to reduce the number of method signatures for the
 createAdapter/createAspect methods).
 
 kind regards (and thanks for proposing to improve Dependency Manager :-))

Agreed, this is a good discussion, thanks for the input!

Greetings, Marcel

Re: Make DependencyManager API more fluent?

[Marcel Offermans]

Hey Paul,

 On 11 Nov 2014, at 8:55 am, Paul Bakker paul.bak...@luminis.eu wrote:
 
 One thing to consider is that although DM 4 is a major version bump, it so
 far seems to be very close to a drop-in replacement of DM 3. Changing the
 API itself would break all existing code. This is technically ok for a
 major version, but will make adoption of the new version a lot slower.

So far our approach has been to fix the things we really wanted to fix but 
leave everything we don’t need to change as is, exactly because of the reason 
you mention. We want people to move to the new release as painless as possible. 
 

 On the other hand, I do like the proposal :-) Maybe it's possible to add a
 new API, while keeping the existing one. E.g. introduce a builder class
 specifically for this reason, user can than gradually move towards the new
 API. Potentially there could even be builders for multiple JVM languages,
 leveraging the DSL functionality of language Groovy etc.

I like this suggestion, like I stated in my previous mail it might require 
wrapping a few classes but it’s definitely doable and probably a good way to 
get some experience under our belts with this approach.

Greetings, Marcel
 

Re: Make DependencyManager API more fluent?

[Marcel Offermans]

Hello Christian,

 On 11 Nov 2014, at 9:22 am, Christian Schneider ch...@die-schneider.net 
 wrote:
 
 About auto adding. How about this:
 Inside component() we add the component to a separate list of pending 
 components in dependency manager.
 Then after init we call a method in the manager to finally add all pending 
 components into the active structure.
 In that method we could then also convert from the class with the new syntax 
 to the existing class. So the changes for the new syntax would have
 minimal impact to the rest of the code.

The problem with this approach is that the API can be used outside of the init 
method as well, so I don’t like adding code that only works in a specific 
scenario.

Greetings, Marcel
  

Re: Make DependencyManager API more fluent?

[Marcel Offermans]

Hello Pierre,

 On 12 Nov 2014, at 9:13 am, Pierre De Rop pierre.de...@gmail.com wrote:
 
 Regarding your suggestion, adding specific builder classes could also be an
 interesting way to go.
 I would even consider to make some specific API bundles, like:
 
 org.apache.felix.dependencymanager - the current 4.0 API, and it should be
 close to the old 3.2 API as much as possible (Marcel, what is your opinion
 ?)

Yes, we can keep this as close to the existing API to ease migration.

 org.apache.felix.dependencymanager.scala - we could leverage DM API to
 scala
 org.apache.felix.dependencymanager.groovy - same for groovy
 etc …
 
 All this could be discussed with more details in the jira issue that
 Christian created.

Makes sense, and we could introduce a .java package (and bundle) for the API 
that Christian proposed. That fits nicely in our plans (just like we have the 
.runtime and annotations if you like that style) and possibly also our future 
support for the declarative services API.

Greetings, Marcel

[jira] [Commented] (FELIX-2875) Improve the setService() methods in the ServiceDependencyImpl to allow null for the service name.

[Marcel Offermans (JIRA)]

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

Marcel Offermans commented on FELIX-2875:
-

I agree with your analysis and proposal. However, I'll leave it up to Tuomas to 
respond before closing these issues.

 Improve the setService() methods in the ServiceDependencyImpl to allow null 
 for the service name.
 -

 Key: FELIX-2875
 URL: https://issues.apache.org/jira/browse/FELIX-2875
 Project: Felix
  Issue Type: Improvement
  Components: Dependency Manager
Reporter: Marcel Offermans
Assignee: Marcel Offermans

 The setService() methods are currently a bit more strict than necessary, not 
 allowing you to, for example, specify only a filter condition via the method 
 called setService(Class name, String filter). This in turn limits the options 
 you have when creating adapters. Fix this problem and factor out any 
 redundant code in these methods.



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

Re: [ANN] New Apache Felix Committer : Bob Paulin

[Marcel Offermans]

Welcome, great to have you on our team, Bob! I’m sure we’ll run into each other 
again soon. :)

Greetings, Marcel

On 17 Oct 2014 at 11:06:01 , Carsten Ziegeler (cziege...@apache.org) wrote:

Hi  

it's my pleasure to announce that the Apache Felix PMC has invited  
Bob Paulin as a new Felix committer...and Bob accepted.  

So please join me in welcoming Bob.  

Regards  
Carsten  
--  
Carsten Ziegeler  
Adobe Research Switzerland  
cziege...@apache.org  

[jira] [Created] (FELIX-4673) Log any error thrown when trying to create a null object.

[Marcel Offermans (JIRA)]

Marcel Offermans created FELIX-4673:
---

 Summary: Log any error thrown when trying to create a null object.
 Key: FELIX-4673
 URL: https://issues.apache.org/jira/browse/FELIX-4673
 Project: Felix
  Issue Type: Improvement
  Components: Dependency Manager
Affects Versions: dependencymanager-3.2.0
Reporter: Marcel Offermans


Currently, the dependency manager will log an error if an exception occurs 
while trying to create a null object. However, it can also encounter a 
NoClassDefFoundError (when a bundle is misconfigured for some reason). Such 
errors should probably also be caught and logged.

See getNullObject() in ServiceDependencyImpl.



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

[jira] [Commented] (FELIX-4673) Log any error thrown when trying to create a null object.

[Marcel Offermans (JIRA)]

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

Marcel Offermans commented on FELIX-4673:
-

Yes, that is fine!

 Log any error thrown when trying to create a null object.
 -

 Key: FELIX-4673
 URL: https://issues.apache.org/jira/browse/FELIX-4673
 Project: Felix
  Issue Type: Improvement
  Components: Dependency Manager
Affects Versions: dependencymanager-3.2.0
Reporter: Marcel Offermans
Assignee: Pierre De Rop

 Currently, the dependency manager will log an error if an exception occurs 
 while trying to create a null object. However, it can also encounter a 
 NoClassDefFoundError (when a bundle is misconfigured for some reason). Such 
 errors should probably also be caught and logged.
 See getNullObject() in ServiceDependencyImpl.



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

[jira] [Commented] (FELIX-4426) Allow DM to manage collections of services

[Marcel Offermans (JIRA)]

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

Marcel Offermans commented on FELIX-4426:
-

I'm not sure if it will affect us, but the contract for a ConcurrentHashMap is 
rather vague when it comes to iterating over the collection while updating it:

Yes, the good news is that it will not throw an exception.
No, it is not guaranteed that you will see updates in the iterator. The 
iterator reflects the state of the hash table at some point at or since the 
creation of the iterator/enumeration.

Will this be a problem? It depends. There is no CopyOnWriteHashMap which 
would have a more determinate behaviour (namely guaranteeing that your 
collection and therefore the iterator won't change after you've got hold of a 
reference) but at the cost of more expensive modifications. We should think 
this through, though, to advise our users when to use this, and when not to 
(you can always use callbacks and a list implementation of choice if you need 
more control).

 Allow DM to manage collections of services
 --

 Key: FELIX-4426
 URL: https://issues.apache.org/jira/browse/FELIX-4426
 Project: Felix
  Issue Type: New Feature
  Components: Dependency Manager
Affects Versions: dependencymanager-4.0.0
Reporter: J.W. Janssen
Assignee: Pierre De Rop
 Fix For: dependencymanager-4.0.0


 DM has great support for single-cardinality dependencies, allowing you to 
 only declare the dependency as (volatile) field. For multiple-cardinality 
 dependencies, no such support is present, forcing you to always manually 
 implement this using callbacks.
 It would be great if I could declare multiple-cardinality dependencies like:
 {code}
 private volatile ListMyService m_services;
 {code}
 and let DM manage the list for me.
 Note that you need some additional reflection mojo to obtain the actual 
 collection type. An example of how this can work can be found in a utility 
 class for Swagger in the Amdatu-Web project, see 
 https://bitbucket.org/amdatu/amdatu-web/src/master/org.amdatu.web.rest/src/org/amdatu/web/rest/doc/swagger/SwaggerUtil.java?at=master#cl-304



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

Re: Event Admin Java Concurrency Changes

[Marcel Offermans]

Are you turning off blacklisting of event handlers and making sure that all 
events are actually received by someone as well?

On 21 Aug 2014, at 17:15 pm, Bob Paulin b...@bobpaulin.com wrote:

 Hi,
 
 I've got some things in progress but nothing that should hold up the release. 
  I'm seeing a significant variance in the test results so I've been making 
 some tweaks to the IT that should hopefully smooth that out.   Perhaps the 
 most interesting result I'm getting from the tests is that the postEvent 
 (asynchronous delivery) is taking nearly twice as long as the sendEvents 
 (synchronous delivery).  I would not expect that much difference in 
 performance between the 2 types of submissions.
 
 Below is a typical run.  Post event vary by 10+ seconds between runs 40 - 50 
 seconds is the typical range.  Send seems a bit more consistent with runs (22 
 - 26 seconds)
 postEvent
 1050 events in 43635ms
 
 sendEvent
 1050 events in 22914ms
 
 Any thoughts on why this might be?
 
 - Bob
 On 8/21/2014 4:49 AM, Carsten Ziegeler wrote:
 THanks for your patch Bob, it's applied. The next release of the event
 admin will have the version 1.4.0.
 
 I would like to cut a release as soon as possible, or do you think
 something needs to changed before?
 
 Carsten
 
 
 2014-08-18 13:22 GMT+02:00 Carsten Ziegeler cziege...@apache.org:
 
 Hi Bob,
 
 I think there is no good reason to keep it separate, I guess I just forgot
 to merge them into trunk :)
 Therefore, patches welcome :)
 
 Carsten
 
 
 2014-08-17 20:31 GMT+02:00 Bob Paulin b...@bobpaulin.com:
 
 Hi,
 Carsten would it make sense to move the IT test from the whiteboard to
 the regular code base?  These tests only take about a minute and require a
 profile to run anyways so I think include them would be a good idea.  I'd
 be happy to integrate the poms to allow this unless there's a reason they
 must be separate.  I also have a patch to upgrade it to Pax-Exam 4 which I
 had to do for it to work with my OS.
 
 I'll work with those with the TCK for the performance/readability
 enhancements but the IT test has been helpful already for some tinkering.
 Thanks for the direction!
 
 - Bob
 
 
 On 8/15/2014 10:40 AM, Carsten Ziegeler wrote:
 
 Hi,
 
 
 2014-08-15 15:28 GMT+02:00 Jan Willem Janssen 
 janwillem.jans...@luminis.eu
 :
 
  On 15/08/14 14:58, Bob Paulin wrote:
 I noticed in https://issues.apache.org/jira/browse/FELIX-3511 Java
 Concurrency is being introduced to the code base.  A couple of
 thoughts on this.
 
 1) With this not being backwards compatible with earlier versions
 does it make sense to increment at least the minor version (ie 1.3
 - 1.4). Java 8 introduces a slew of incompatibility with prior
 releases with the changes to the collection libraries so I'm
 curious how other projects are handling this.
 
 As I understand the issue, it talks about going from Java 5 to Java 6
 as required version, but yes, strictly speaking this would mean a
 minor bump at least. We should be more strict on this, I agree (made
 the same mistake in the Felix HTTP project as well).
 
  Actually, as far as I remember the idea was that the version number
 reflects the specification version it implements - but this might not
 really make sense, so bumping the minor version is a good thing.
 
  2) Event admin has no tests.  I would be interested in working on
 creating some tests for this project.  Any thoughts on where to
 begin with this effort?
 
 I think the current implementation is written (and maintained) by
 people that have access to the OSGi TCK, so they can tests the
 implementation against the specification, which might explain the lack
 of unit and integration tests.
 
  Yepp, the implementation passes the OSGi TCK which I believe tests a
 lot of
 aspects already.
 
 
  But to get started: just start writing unit tests against the code in
 trunk and provide them as patches. It is always good to have tests
 written by somebody else, as they most often have new/fresh insights
 in the use cases...
 
  Absolutely, we also have some additional tests in the whiteboard area
 for
 event admin. It's basically a stress test.
 
  3) It appears there maybe other areas of the event admin code that
 might benefit from the Concurrency objects.  Perhaps the use of one
 of the Queue constructs for holding some of the asynchronous
 events.  Thoughts on this?
 
 As long as it has positive effect on the performance, I think nobody
 will complaint about this, if you're willing to provide patches ;)
 
 Right :) This has all been written initially on Java 1.4 so there might
 be
 
 areas which can be improved.
 However, a nicer implementation is one thing, the other one is
 performance.
 The goal should be to have a minimum on synchronization between threads
 to
 get the best performance. I'm not saying the current implementation is
 perfect though :)
 
 Carsten
 
 
  - --
 Met vriendelijke groeten | Kind regards
 
 Jan Willem Janssen | Software Architect
 +31 631 765 814
 
 

RE: Upgrading to Jetty 9

[Marcel Offermans]

I agree with the general sentiment that we need to keep moving forward, 
supporting the latest version of Jetty.

Personally, I'm not sure if an open source project should keep maintaining 
releases that run on Java versions that are no longer supported themselves, but 
this is a broader discussion and I guess if there are enough people here that 
care, then we have a good argument to do so.

That said, if we keep two branches, I would like to suggest that we create 
bundles with *different* symbolic names, instead of trying to maintain both 
forks within the same bundle version range. Since the Jetty 9 effort is new, I 
suggest we choose a new symbolic name for it and keep the existing one for the 
Java 6 compatible fork.

Greetings, Marcel


From: paul.bakker...@gmail.com paul.bakker...@gmail.com on behalf of Paul 
Bakker paul.bak...@luminis.eu
Sent: Monday, July 28, 2014 9:16 AM
To: dev@felix.apache.org
Subject: Re: Upgrading to Jetty 9

A major version bump is justified when the bundle doesn't work in
environments that previously did work. Note that we're talking about the
bundle version, not about package versions. Even the last release (2.3.0)
should have been a major bump; it now requires extra bundles to be
installed containing APIs, so existing configurations did not longer work.
The version number should warn users if the update is a simple drop-in
replacement or that other changes might be required.

I would be in favour of branching. The Java 6 supported version only gets
maintenance updates, while new development continues on Jetty 9. This way
developers on Java 6 are not forced to upgrade, but new development is not
complicated or limited by the fact that an older version still should be
supported.

Cheers,

Paul


On Mon, Jul 28, 2014 at 8:35 AM, Felix Meschberger fmesc...@adobe.com
wrote:

 Hi

 The question really is whether the _internal_ upgrade of the Jetty bundle
 to Jetty 9 really is a major change for the Http Service functionality ?

 Backwards compatibility is not expected to be hampered. The only
 difference, apart from the new features offered potentially by Jetty 9,
 such as javax.websockets API support, is that the bundle now requires Java
 7. And I am not really sure, whether an updated requirement really warrants
 going to the next major version.

 I know dropping Java 6 support is a problem in some cases, but hey, the
 world keeps on spinning :-)

 If possible, I'd rather create two artifacts from the same project, if at
 all possible: One embedding Jetty 8 (supporting Java 6) and one embedding
 Jetty 9 (requiring Java 7).

 WDYT ?

 Regards
 Felix

 Am 25.07.2014 um 19:29 schrieb Tobias Bocanegra tri...@apache.org:

  Hi,
 
  there is an issue that deals with upgrading jetty to 9.x [0]. As it
  requires java 7, it is not a trivial update. basically the question
  is:
 
  - create 2 bundles: org.apache.felix.http.[jetty8|jetty9]
  - or update the maven artifact version to 3.0.0 (from 2.4.x)
 
  I would tend to the later
  regards, toby
 
  [0] https://issues.apache.org/jira/browse/FELIX-4550

RE: Java process codepage sharing

[Marcel Offermans]

You might want to try and contact Jan Rellermeyer about this. Last time I 
talked to him at an OSGi meeting he was looking into doing multi-tenancy based 
on codepage sharing. He might have further insights into this.

Greetings, Marcel


From: Rob Walker r...@ascert.com
Sent: Friday, July 25, 2014 3:35 PM
To: dev@felix.apache.org
Subject: Re: Java process codepage sharing

On 25/07/2014 15:20, Richard S. Hall wrote:
 On 7/25/14, 08:45 , Rob Walker wrote:
 I'm being lazy here, but didn't find a quick answer via Google.

 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. Each will have it's own data pages clearly.

 1st question is - am I correct on this?

 If this is true it leads to my 2nd question - whether Felix/OSGi
 defeats? I'm assuming that any codepage sharing done by the VM would
 be based on the absolute path to the JAR, and hence in an OSGi model
 where we have a bundle cache per-process, the codepages may not end
 up shared?

 I thought they only memory mapped the JRE classes, not application
 classes...

That could be what I'm thinking of!

Be interesting to know if they do go beyond that

 - richard



 Feel free to respond with links to article I need to go read!

 -- Rob


 Ascert - Taking systems to the edge
 r...@ascert.com
 SA +27 21 300 2028
 UK +44 20 7488 3470 ext 5119
 www.ascert.com



--


Ascert - Taking systems to the edge
r...@ascert.com
SA +27 21 300 2028
UK +44 20 7488 3470 ext 5119
www.ascert.com

[jira] [Commented] (FELIX-4557) Update Dependency Manager to latest felix parent pom/bundle plugin versions

[Marcel Offermans (JIRA)]

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

Marcel Offermans commented on FELIX-4557:
-

If it's not broke, don't fix it. So are there actually issues with using the 
older parent pom and plugin? If so, there is a valid reason to upgrade, with 
the risk of changing other things: parent poms and bundle plugin versions do 
tend to change certain aspects, at least in my experience whenever I upgraded 
either of them, random other stuff started breaking.

Also, keep in mind that with Dependency Manager 4, we are switching to Bndtools 
anyway, so I would not make too many big upgrades to the 3.x codebase in that 
respect.

That being said, if we need to upgrade this, we should. :)

 Update Dependency Manager to latest felix parent pom/bundle plugin versions
 ---

 Key: FELIX-4557
 URL: https://issues.apache.org/jira/browse/FELIX-4557
 Project: Felix
  Issue Type: Improvement
  Components: Dependency Manager
Reporter: Pierre De Rop
Assignee: Pierre De Rop
Priority: Trivial

 Currently, dependency manager is using maven-bundle-plugin 2.3.4, and 
 felix-parent pom 1.2.0;
 So, before doing a release, we should update the poms of the DM artifacts to 
 be released with latest parent pom (2.1) and latest maven-bundle-plugin 
 (2.5.0).
 Notice that using parent pom 2.1 introduces an issue with the DM core: 
 indeed, the 2.1 parent pom is using a strict java compiler compliance level 
 to 1.3, which generates an eclipse compilation error for the 
 org.apache.felix.dm.tracker.ServiceTracker class, because in the Tracked 
 inner class, the highestTracked method is invoking the size() method, 
 like this (line 921):
 private ServiceReference highestTracked(long serviceId) {
 ServiceReference result = null;
 int max = Integer.MIN_VALUE;
 
 synchronized (this) {
 int length = size();
 ...
 but when using strict java 1.3 compliance, Eclipse displays a compilation 
 error because the size() method is both declared in the AbstractTracked 
 inherited class , as well as in the ServiceTracker enclosing class.
 One way to work around would be to modify the code like this:
 synchronized (this) {
 int length = this.size();
 but I prefer to not modify the code before releasing and use a 
 source1.4/source in pom.xml, which resolves the eclipse compilation issue.



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

Re: About to release the Dependency Manager

[Marcel Offermans]

Hello Pierre,

On 07 Jul 2014, at 15:46 pm, Pierre De Rop pierre.de...@gmail.com wrote:

 Just to say that this week I will (try to) release the DependencyManager
 from the trunk;

Sounds like a good idea to do another release! +1 on that...

Greetings, Marcel

Re: Handling of provisional OSGi API?

[Marcel Offermans]

I did not read David’s proposal that way. I think he is saying:

YES, you can code against an API that is under development, as long as you do 
not do any releases (before the API is finalized).

So only if you want to do a release before the API is finalized do you need to 
package it under the Felix namespace and deprecate it (with a provisional 
status).

The only downside I see is that, from the OSGi Alliance point of view, they are 
getting less “real world” use of their reference implementations while they are 
being developed, because this policy makes it impractical to use (in 
production) any API that is still under development. On the other hand, it’s 
not too hard for someone to write a small component that publishes such an API 
itself and “bridges” to the artifact that our project released. I think that’s 
actually a reasonable compromise.

Personally, I could also live with a policy that only requires us to put the 
API in the Felix namespace (and not mark it deprecated or anything). Once an 
artifact has been released, it’s out there anyway. On the other hand, those 
extras are not in anybody’s way and they do serve as a warning, so I’m not 
going to make an argument that we must remove them.

Greetings, Marcel

On 19 May 2014, at 9:24 , Guillaume Nodet gno...@apache.org wrote:

 The change and your proposal.  It seems to restrictive to not allow coding
 against API that are being developped when not planning to release the
 project before the API is.
 
 
 2014-05-17 9:37 GMT+02:00 David Jencks david_jen...@yahoo.com:
 
 I propose we change the provisional api policy page
 http://felix.apache.org/documentation/development/provisional-osgi-api-policy.htmlto
  this (markdown source):
 
 The OSGi Alliance exposes provisional API that may or may not become part
 of future OSGI specifications.  This policy explains how and when Felix
 subprojects may relate to such API. Provisional OSGi API refers to anything
 in the `org.osgi.*` package namespace that is not part of a final released
 specification.
 
 ## Policy
 1. No Felix release may contain or refer to provisional OSGI API.
 1. Provisional API may be included and used in unreleased source code,
 however the API must be part of a final released OSGI specification before
 this felix source may be released.
 
 1. Although it is STRONGLY NOT RECOMMENDED, modified versions of
 provisional api may be released with these modifications:
 
 1. Any provisional OSGi API must be recreated in the `org.apache.felix.*`
 package name space; this effectively makes it provisional Felix API.
 1. All Felix provisional API must be marked as deprecated.
 1. All Felix provisional API exported from bundles should be exported
 with a mandatory attribute of `status=provisional`.
 
 ## Discussion
 
 The first goal of this policy is to completely avoid using provisional
 OSGi API in released Felix projects given the potential confusion and
 questions by doing so. The second goal is to make the existence of any
 released Felix provisional API completely obvious to downstream users and
 make it difficult for them to use it unknowingly. However, any such release
 is likely to involve numerous problems such as incorrect semantic
 versioning or version mismatch between the provisional and eventual osgi
 release and bundle version inflation if the felix provisional api is
 removed after the OSGI API is released.
 
 As an example, to provisionally export the
 `org.apache.felix.service.metatype` package, the
 `Export-Package` statement would look something like this:
 
:::xml
Export-Package
  org.apache.felix.service.metatype; version=0.1;
 mandatory=status; status=provisional
/Export-Package
 
 When working with new OSGI specifications, constructing a Felix
 provisional API will likely result in parallel package structures between
 the provisional OSGi and Felix APIs. When working with existing
 specifications, it may be necessary to create extensions to existing OSGi
 interfaces in the Felix package namespace.
 
 Comments?
 
 thanks
 
 david jencks
 
 ps.  JB, Guillaume, what exactly are you +1ing?  That we keep talking?
 That the policy stay the same? Change?
 
 On May 16, 2014, at 7:56 PM, Richard S. Hall he...@ungoverned.org
 wrote:
 
 On 5/16/14, 20:43 , David Jencks wrote:
 You have a point about specs that don't get released.  And in such a
 circumstance having something released with org.osgi packages marked
 provisional would be sort of a disaster.
 
 But if a felix subproject is going to be an osgi ri, it really needs to
 be developed with the right package names.  Otherwise, for instance,
 debugging the conformance test suite will be more or less impossible, as
 well as making running the ri against the ct implausible.
 
 I believe we did have this issue with the Config Admin RI and somehow we
 managed.
 
 
 So I think I'd like the policy to say (sub) projects are strongly
 discouraged from releasing anything with a non released osgi spec api no
 

Re: Handling of provisional OSGi API?

[Marcel Offermans]

Hello David,

On 19 May 2014, at 10:22 , David Bosschaert david.bosscha...@gmail.com wrote:

 On 5/16/14, 20:43 , David Jencks wrote:
 for instance, debugging the conformance test suite will be more or less 
 impossible,
 
 Yep, if you're writing an RI in Felix and this RI needs to run as part
 of the OSGi CT, it will only work if it uses the official OSGi API.
 As an example take an OSGi CT that looks for a whiteboard service that
 implements the org.osgi.service.http.runtime.HttpServiceRuntime
 interface.
 The CT will not find the implementation if it's renamed to
 org.apache.felix...something. So at least to test the RI as part of
 the CT you need the real API.

You do, but as far as I know you do not need a release (in the Apache sense of 
the word, meaning source code) for that as the OSGi CT only requires you to 
submit a binary artifact. And that can easily be produced without doing any 
kind of release (and should, because it’s not for public consumption usually).

 BTW I think it would be good if this policy could also apply to new
 versions of an existing API. E.g. it should also be usable when we
 move the Core API from 1.7 to 1.8 for Core R6. Thought anyone?

This policy already applies to new versions of an existing API, right?

Greetings, Marcel


 
 Cheers,
 
 David
 
 On 19 May 2014 10:05, Marcel Offermans marcel.offerm...@luminis.nl wrote:
 I did not read David’s proposal that way. I think he is saying:
 
 YES, you can code against an API that is under development, as long as you 
 do not do any releases (before the API is finalized).
 
 So only if you want to do a release before the API is finalized do you need 
 to package it under the Felix namespace and deprecate it (with a provisional 
 status).
 
 The only downside I see is that, from the OSGi Alliance point of view, they 
 are getting less “real world” use of their reference implementations while 
 they are being developed, because this policy makes it impractical to use 
 (in production) any API that is still under development. On the other hand, 
 it’s not too hard for someone to write a small component that publishes such 
 an API itself and “bridges” to the artifact that our project released. I 
 think that’s actually a reasonable compromise.
 
 Personally, I could also live with a policy that only requires us to put the 
 API in the Felix namespace (and not mark it deprecated or anything). Once an 
 artifact has been released, it’s out there anyway. On the other hand, those 
 extras are not in anybody’s way and they do serve as a warning, so I’m not 
 going to make an argument that we must remove them.
 
 Greetings, Marcel
 
 On 19 May 2014, at 9:24 , Guillaume Nodet gno...@apache.org wrote:
 
 The change and your proposal.  It seems to restrictive to not allow coding
 against API that are being developped when not planning to release the
 project before the API is.
 
 
 2014-05-17 9:37 GMT+02:00 David Jencks david_jen...@yahoo.com:
 
 I propose we change the provisional api policy page
 http://felix.apache.org/documentation/development/provisional-osgi-api-policy.htmlto
  this (markdown source):
 
 The OSGi Alliance exposes provisional API that may or may not become part
 of future OSGI specifications.  This policy explains how and when Felix
 subprojects may relate to such API. Provisional OSGi API refers to anything
 in the `org.osgi.*` package namespace that is not part of a final released
 specification.
 
 ## Policy
 1. No Felix release may contain or refer to provisional OSGI API.
 1. Provisional API may be included and used in unreleased source code,
 however the API must be part of a final released OSGI specification before
 this felix source may be released.
 
 1. Although it is STRONGLY NOT RECOMMENDED, modified versions of
 provisional api may be released with these modifications:
 
 1. Any provisional OSGi API must be recreated in the `org.apache.felix.*`
 package name space; this effectively makes it provisional Felix API.
 1. All Felix provisional API must be marked as deprecated.
 1. All Felix provisional API exported from bundles should be exported
 with a mandatory attribute of `status=provisional`.
 
 ## Discussion
 
 The first goal of this policy is to completely avoid using provisional
 OSGi API in released Felix projects given the potential confusion and
 questions by doing so. The second goal is to make the existence of any
 released Felix provisional API completely obvious to downstream users and
 make it difficult for them to use it unknowingly. However, any such release
 is likely to involve numerous problems such as incorrect semantic
 versioning or version mismatch between the provisional and eventual osgi
 release and bundle version inflation if the felix provisional api is
 removed after the OSGI API is released.
 
 As an example, to provisionally export the
 `org.apache.felix.service.metatype` package, the
 `Export-Package` statement would look something like this:
 
   :::xml
   Export-Package

Re: deadlock in fileinstall on equinox

[Marcel Offermans]

The problem here is that file install cannot dictate the framework what to 
refresh. The refresh method takes an initial set of bundles, but the framework 
calculates a dependency closure (see 7.6.1 of the spec for example). If that 
closure includes file install, then this issue occurs. The only way file 
install can solve this is by making sure it never gets included by not 
importing anything or by modifying the code so it does not deadlock. I think 
that modifying the code is the best option, because that ensures that this can 
never happen. Any other solution is probably very fragile as *any* bundle can 
trigger a refresh that might include file install.

Greetings, Marcel


On 29 Apr 2014, at 21:22 pm, Raymond Auge raymond.a...@liferay.com wrote:

 I don't think fileinstall should ever really be able to refresh itself
 exactly for the reason that it's going to create a deadlock.
 
 It would appear to me that fileinstall should just ignore anything that it
 can't itself manage, such as itself.
 
 I'm actually wondering why
 
 felix.fileinstall.optionalImportRefreshScope=managed
 
 isn't the default
 
 The default is null which equates to all framework bundles which seems is
 leading to the problem.
 
 - Ray
 
 
 On Tue, Apr 29, 2014 at 3:14 PM, Guillaume Nodet gno...@apache.org wrote:
 
 My question was about why fileinstall refreshes itself.  It must be because
 you deploy either configadmin or a log service as those are the only two
 optional imports on fileinstall.
 
 
 2014-04-29 20:53 GMT+02:00 Raymond Auge raymond.a...@liferay.com:
 
 I'm not using config admin at all. Rather, the only path to setting the
 bit
 I need is via service update lifecycle.
 
 - Ray
 
 
 On Tue, Apr 29, 2014 at 2:47 PM, Guillaume Nodet gno...@apache.org
 wrote:
 
 Are you trying to use fileinstall to deploy configadmin ?
 That's not really supported, but it should not be very difficult to
 support.
 Please raise a JIRA.
 
 I think allowing all configuration bits to be available from the bundle
 context would be a good work around.
 
 
 2014-04-29 20:13 GMT+02:00 Raymond Auge raymond.a...@liferay.com:
 
 It would seem that this could be solved it it were possible to pass
 the
 property:
 
 felix.fileinstall.optionalImportRefreshScope=managed
 
 but this property cannot be passed except via config admin, so you
 can't
 bootstrap the system as it is.
 
 - Ray
 
 
 On Tue, Apr 29, 2014 at 1:28 PM, Raymond Auge 
 raymond.a...@liferay.com
 wrote:
 
 Hey All (cross posted as I'm not sure where the answer will come
 from),
 
 versions:
 - fileinstall 3.4.0
 - equinox 3.8.0.v20120529-1548
 
 I'm seeing a deadlock where on first start the fileinstall bundle
 is
 getting stuck with itself
 
 as per the following two stack traces:
 
 Refresh Packages daemon prio=10 tid=0x7fc29c0f6800 nid=0x94c
 waiting on condition [0x7fc2b9c15000]
   java.lang.Thread.State: WAITING (parking)
  at sun.misc.Unsafe.park(Native Method)
  - parking to wait for  0xc095f950 (a
 java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
  at
 java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
  at
 
 
 
 java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
  at
 
 
 
 java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
  at
 
 
 
 java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
  at
 
 
 
 java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:945)
  at
 
 
 
 org.apache.felix.fileinstall.internal.FileInstall.stop(FileInstall.java:171)
  at
 
 
 
 org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:771)
  at java.security.AccessController.doPrivileged(Native Method)
  at
 
 
 
 org.eclipse.osgi.framework.internal.core.BundleContextImpl.stop(BundleContextImpl.java:764)
  at
 
 
 
 org.eclipse.osgi.framework.internal.core.BundleHost.stopWorker(BundleHost.java:510)
  at
 
 
 
 org.eclipse.osgi.framework.internal.core.AbstractBundle.suspend(AbstractBundle.java:566)
  at
 
 
 
 org.eclipse.osgi.framework.internal.core.Framework.suspendBundle(Framework.java:1207)
  at
 
 
 
 org.eclipse.osgi.framework.internal.core.PackageAdminImpl.suspendBundle(PackageAdminImpl.java:326)
  at
 
 
 
 org.eclipse.osgi.framework.internal.core.PackageAdminImpl.processDelta(PackageAdminImpl.java:467)
  at
 
 
 
 org.eclipse.osgi.framework.internal.core.PackageAdminImpl.doResolveBundles(PackageAdminImpl.java:251)
  - locked 0xc0cbc1f8 (a
 org.eclipse.osgi.framework.internal.core.PackageAdminImpl)
  at
 
 
 
 org.eclipse.osgi.framework.internal.core.PackageAdminImpl$1.run(PackageAdminImpl.java:174)
  at java.lang.Thread.run(Thread.java:744)
   Locked ownable synchronizers:
  - None
 
 
 

Re: [VOTE] Release Felix DeploymentAdmin 0.9.6

[Marcel Offermans]

+1

Checked the signatures, performed some basic testing in Apache ACE. Looks good 
to me.

Greetings, Marcel

Re: Clean build of Felix

[Marcel Offermans]

I agree, subprojects evolve at their own rate. We could encourage everybody to 
move to the latest plugin and parent though. Maybe we should remove the top 
level build that tries to build all subprojects completely, and just explain to 
everybody to go into the subproject of choice to build it.

Greetings, Marcel


On 25 Mar 2014, at 14:33 , Richard S. Hall he...@ungoverned.org wrote:

 There has never really been a reliable way to build trunk. For the most part, 
 we just build the subprojects of interest.
 
 I'm not sure there is much value in a trunk build, especially if it causes 
 subprojects to have to evolve in lock step.
 
 - richard
 
 On 3/25/14, 04:45 , Grzegorz Grzybek wrote:
 Hello all!
 
 I was trying to build clean trunk of Felix. I added new *profile*consisting 
 of
 *all* modules and it was built fine without problems on JDK6 and Maven
 3.0.x.
 
 So my first question is: is the ANT buildfile still needed? The problematic
 MNG-1682 issue was resolved long time ago...
 
 But after looking more deeply into the POMs, I saw weird things which makes
 clean building impossble:
  - there are 3 versions of org.apache.felix:felix-parent used as parent POM
 (1.2.0, 1.2.1 and 2.1.0)
  - there is even org.apache.felix:felix:1.0.4 used as parent POM in some
 artifacts
  - some artifacts have wrong parent.relativePath set
  - there are *eleven* versions of maven-bundle-plugin used:
 - 1.0.0
 - 1.4.0
 - 1.4.3
 - 2.0.0
 - 2.0.1
 - 2.1.0
 - 2.3.4
 - 2.3.5
 - 2.3.6
 - 2.3.7
 - 2.4.1-SNAPSHOT
 
 Shouldn't Felix allow this kind of clean, offline build?
 
 regards
 Grzegorz Grzybek
 
 

Re: [VOTE] Accept PojoSR code donation

[Marcel Offermans]

+1

On Mar 5, 2014 3:49 PM, Guillaume Nodet gno...@apache.org wrote:
Karl Pauls is willing to donate PojoSR (https://code.google.com/p/pojosr/)
to Felix.

This vote is about officially accepting the donation.

[ ] +1  Accept PojoSR code into Felix
[ ] -1 Do not

Cheers,
Guillaume Nodet

[jira] [Commented] (FELIX-4446) Optionally enhance event admin to add a timestamp and the authenticated subject before dispatching events

[Marcel Offermans (JIRA)]

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

Marcel Offermans commented on FELIX-4446:
-

Using Event Admin as an audit trail is only one specific application of this 
service. I would not want to have code in its implementation to deal with that. 
I would propose you implement this in a separate bundle (as a proxy in front of 
EventAdmin or something similar).

 Optionally enhance event admin to add a timestamp and the authenticated 
 subject before dispatching events
 -

 Key: FELIX-4446
 URL: https://issues.apache.org/jira/browse/FELIX-4446
 Project: Felix
  Issue Type: New Feature
  Components: Event Admin
Reporter: Guillaume Nodet
Assignee: Guillaume Nodet

 EventAdmin is great because various bundles do send events, so it's really 
 nice for an audit trail of what happened.
 However, in order for the audit trail to be useful, it's missing a few 
 properties such as the timestamp and the user performing the action.
 It would be nice if event admin add those automatically to avoid modifying 
 various projects to add those properties.



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

Re: Any plans to make PojoSR part of Apache Felix

[Marcel Offermans]

On 06 Mar 2014, at 14:58 , David Bosschaert david.bosscha...@gmail.com wrote:

 It can be quite useful for people who like to use OSGi Services or
 migrate to OSGi for other reasons, but don't want to handle the
 modularity on the classloader level just yet.

Other applications are to deploy OSGi bundles to environments that have no 
classloaders, or even no threads, such as Google AppEngine. We’ve also used it 
in the past to deploy to Android (which does have both, but you can run into 
some differences/restrictions of the Dalvik JVM that can be avoided this way).

Greetings, Marcel

[jira] [Commented] (FELIX-4446) Optionally enhance event admin to add a timestamp and the authenticated subject before dispatching events

[Marcel Offermans (JIRA)]

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

Marcel Offermans commented on FELIX-4446:
-

I still think these two properties are way too specific to your use case to put 
them in this implementation. I mean what if the next user comes along and wants 
to add his or her set of properties in the same way? In my opinion, EventAdmin 
should stick to implementing the specification.

 Optionally enhance event admin to add a timestamp and the authenticated 
 subject before dispatching events
 -

 Key: FELIX-4446
 URL: https://issues.apache.org/jira/browse/FELIX-4446
 Project: Felix
  Issue Type: New Feature
  Components: Event Admin
Reporter: Guillaume Nodet
Assignee: Guillaume Nodet

 EventAdmin is great because various bundles do send events, so it's really 
 nice for an audit trail of what happened.
 However, in order for the audit trail to be useful, it's missing a few 
 properties such as the timestamp and the user performing the action.
 It would be nice if event admin add those automatically to avoid modifying 
 various projects to add those properties.



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

Re: Any plans to make PojoSR part of Apache Felix

[Marcel Offermans]

On 05 Mar 2014, at 14:55 pm, Guillaume Nodet gno...@apache.org wrote:

 2014-03-05 13:43 GMT+01:00 Karl Pauls karlpa...@gmail.com:
  * we need a formal agreement from the contributors (karlpauls and AngelovdS
 from the pojosr commit log) to give copyright to the ASF (a CLA would do it
 afaik)

For the record, Angelo van der Sijpt is also an Apache committer (in the ACE 
project) so both contributors already have an ICLA on file.

Greetings, Marcel

Re: Fragment Bundle supplying a Require-Capability seems to not work

[Marcel Offermans]

Hello Nick,

From your description I cannot determine if you first installed, resolved and 
started the host and then installed the fragment or if the fragment was already 
installed at the point where the host resolved. I’m asking because that’s a 
common pitfall when dealing with fragments: if you install them after the host 
has already been resolved, “nothing happens”.

Greetings, Marcel


On 03 Mar 2014, at 5:42 , Nick Baker codeoncof...@gmail.com wrote:

 Just a heads-up,
 
 According to the specs, it should be possible for a Fragment to add a
 Require-Capability to a Host. I tried this with Log4J to have it wait for
 an Apache FileInstall exploded bundle to supply the Capability, but it
 didn't seem to take. If I get the time, I'll try to gather the work and
 submit a case.
 
 If anyone is familiar with the code, I'd appreciate a quick pointer to the
 responsible class. I'd like to submit a patch along with the case.
 
 Thanks,
 Nick Baker

Re: [VOTE] Release Felix Utils 1.6.0

[Marcel Offermans]

+1

One minor comment: NOTICE and DEPENDENCIES have an old copyright statement 
(2010).

Greetings, Marcel

On 26 Feb 2014, at 12:12 pm, Guillaume Nodet gno...@apache.org wrote:

 I'm calling a vote on Felix Utils.
 
 Staging repository:
 https://repository.apache.org/content/repositories/orgapachefelix-1007/
 
 You can use this UNIX script to download the release and verify the
 signatures:
 http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
 
 Usage:
 sh check_staged_release.sh 1007 /tmp/felix-staging
 
 Changes:
 ** Improvement
* [FELIX-4433] - Provide more control over the substitution
* [FELIX-4434] - Require JDK 5
* [FELIX-4435] - Add a method to do substitution without any callback
 
 
 Please vote to approve this release:
 
 [ ] +1 Approve the release
 [ ] -1 Veto the release (please provide specific comments)
 
 Cheers,
 Guillaume

[jira] [Closed] (FELIX-4226) Add option to have the dependency manager log against a single BundleContext's LogService.

[Marcel Offermans (JIRA)]

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

Marcel Offermans closed FELIX-4226.
---

Resolution: Fixed

Closing the issue, as it has already been implemented and we received no 
further feedback on that implementation.

 Add option to have the dependency manager log against a single 
 BundleContext's LogService.
 --

 Key: FELIX-4226
 URL: https://issues.apache.org/jira/browse/FELIX-4226
 Project: Felix
  Issue Type: Improvement
  Components: Dependency Manager
Affects Versions: dependencymanager-3.1.0
Reporter: Xander Uiterlinden
Assignee: Xander Uiterlinden

 DependencyManager uses the OSGi LogService for it's logging. The LogService 
 is provided per bundle. As a typical application consists of many bundles, 
 many different LogServices will be used by the dependencymanager.
 A common pattern for an application is to implement a LogListener to catch 
 all log events and pass them to a logging framework, e.g. log4j, 
 commons-logging etc. All of these framework have the notion of a logger name 
 or class. This is usually also the element of which the log levels can be 
 configured. In a LogEntry provided by the OSGi logging framework typically 
 only the bundlename makes sense to be used as the logger name/class.
 Due to the fact that an application can have many dependency managers and 
 thus use several different LogServices all tied to their own bundlecontext, 
 this logger name is going to be differ. 
 It would be practical to be able to instruct the dependency manager to log 
 against a single LogService only so the bundle name provided in the log event 
 can also practically be used as a logger name.



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

[jira] [Commented] (FELIX-4384) Difference between inner class and normal class service

[Marcel Offermans (JIRA)]

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

Marcel Offermans commented on FELIX-4384:
-

A patch for this would be nice as I see no fundamental reason why it would be 
bad to use an inner class as the implementation for a component.

 Difference between inner class and normal class service
 ---

 Key: FELIX-4384
 URL: https://issues.apache.org/jira/browse/FELIX-4384
 Project: Felix
  Issue Type: Bug
  Components: Dependency Manager
Affects Versions: dependencymanager-3.1.0
Reporter: Jago de Vreede
Priority: Minor

 Given the following code:
 package org.example;
 import org.apache.felix.dm.DependencyActivatorBase;
 import org.apache.felix.dm.DependencyManager;
 import org.osgi.framework.BundleContext;
 public class Activator extends DependencyActivatorBase {
 @Override
 public synchronized void init(BundleContext context, DependencyManager 
 manager) throws Exception {
 manager.add(createComponent()
 .setInterface(A.class.getName(), null)
 .setImplementation(A.class)
 
 .add(createServiceDependency().setService(S.class).setRequired(true)));
 
 manager.add(createComponent()
 .setInterface(S.class.getName(), null)
 .setImplementation(S1.class));
 }
 @Override
 public synchronized void destroy(BundleContext context, DependencyManager 
 manager) throws Exception {}
 
 interface S {}
 class A {}
 class S1 implements S {}
 }
 dm will print out:
 g! dm
 [8] mytest
  [0] org.example.Activator$A unregistered
 org.example.Activator$S service required unavailable
  [1] org.example.Activator$S registered
 But when the class S1 is promoted to a real class, dm will print out:
 g! dm
 [8] mytest
  [0] org.example.Activator$A registered
 org.example.Activator$S service required available
  [1] org.example.Activator$S registered
 So the service class S1 is not available if its an inner class but is 
 available if its a normal class.



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

[jira] [Created] (FELIX-4409) Improve exception messages to be more explicit and helpful

[Marcel Offermans (JIRA)]

Marcel Offermans created FELIX-4409:
---

 Summary: Improve exception messages to be more explicit and helpful
 Key: FELIX-4409
 URL: https://issues.apache.org/jira/browse/FELIX-4409
 Project: Felix
  Issue Type: Bug
  Components: Deployment Admin
Affects Versions: deploymentadmin-0.9.5
Reporter: Marcel Offermans


In the UpdateCommand lines 95 and 98 there are exceptions that are thrown if 
either the BSN or version does not match. These messages simply state that, 
without being explicit about *what* BSN or version(s) this is about.

It probably makes sense improve these and perhaps review other similar 
exception messages to make them more helpful.



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

[jira] [Updated] (FELIX-4409) Improve exception messages to be more explicit and helpful

[Marcel Offermans (JIRA)]

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

Marcel Offermans updated FELIX-4409:


Issue Type: Improvement  (was: Bug)

 Improve exception messages to be more explicit and helpful
 --

 Key: FELIX-4409
 URL: https://issues.apache.org/jira/browse/FELIX-4409
 Project: Felix
  Issue Type: Improvement
  Components: Deployment Admin
Affects Versions: deploymentadmin-0.9.5
Reporter: Marcel Offermans

 In the UpdateCommand lines 95 and 98 there are exceptions that are thrown if 
 either the BSN or version does not match. These messages simply state that, 
 without being explicit about *what* BSN or version(s) this is about.
 It probably makes sense improve these and perhaps review other similar 
 exception messages to make them more helpful.



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

[jira] [Created] (FELIX-4410) Exceptions during rollback are not always properly handled

[Marcel Offermans (JIRA)]

Marcel Offermans created FELIX-4410:
---

 Summary: Exceptions during rollback are not always properly handled
 Key: FELIX-4410
 URL: https://issues.apache.org/jira/browse/FELIX-4410
 Project: Felix
  Issue Type: Bug
  Components: Deployment Admin
Affects Versions: deploymentadmin-0.9.5
Reporter: Marcel Offermans


In DeploymentSessionImpl.call(...) there are a couple of locations that trigger 
a rollback. It is currently possible for the rollback itself to create an 
exception. Not all commands that participate in the rollback currently catch 
all such exceptions. The spec describes in 114.7.1 that the rollback should 
always do its best to reverse all effects, and log any problems it ran into. We 
should make a better effort to do so. Therefore I suggest a review of all those 
commands where we explicitly check thrown exceptions and deal with them.



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

[jira] [Commented] (FELIX-4384) Difference between inner class and normal class service

[Marcel Offermans (JIRA)]

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

Marcel Offermans commented on FELIX-4384:
-

When reproducing the scenario using the code you provided, I immediately get 
the following error (I cut away most of the stack trace):

{code}
ERROR: Could not create service instance of class class zzz.dm.Activator$S1. 
(java.lang.NoSuchMethodException: zzz.dm.Activator$S1.init())
java.lang.NoSuchMethodException: zzz.dm.Activator$S1.init()
ERROR: Could not register service null (java.lang.IllegalArgumentException: 
Service object cannot be null.)
java.lang.IllegalArgumentException: Service object cannot be null.
{code}

So your problem is that DM cannot find a default constructor for S1 (or A for 
that matter). Without an instance, it cannot register the service. If you 
change the init method as follows:

{code}
manager.add(createComponent()
.setInterface(A.class.getName(), null)
.setImplementation(new A())

.add(createServiceDependency().setService(S.class).setRequired(true)));

manager.add(createComponent()
.setInterface(S.class.getName(), null)
.setImplementation(new S1()));
{code}

It works:

{code}
g! dm 4
[4] zzz.dm
  zzz.dm.Activator$A() registered
zzz.dm.Activator$S service required available
  zzz.dm.Activator$S() registered
{code}

Another thing about your code. I noticed you synchronize the init and destroy 
methods. Because you invoke DM methods there, you end up invoking code outside 
your bundle. For example, if you register a service that someone else is 
depending on, the registration might trigger the invocation of callback methods 
in someone else's bundle on that same thread. You cannot hold locks while 
invoking such methods, because they might end up causing deadlocks (trust me, 
I've seen a few over the years). In this case, I would simply remove the 
keyword, since there is no reason for it to be there.

If you agree with my analysis, feel free to close the issue.

 Difference between inner class and normal class service
 ---

 Key: FELIX-4384
 URL: https://issues.apache.org/jira/browse/FELIX-4384
 Project: Felix
  Issue Type: Bug
  Components: Dependency Manager
Affects Versions: dependencymanager-3.1.0
Reporter: Jago de Vreede
Priority: Minor

 Given the following code:
 package org.example;
 import org.apache.felix.dm.DependencyActivatorBase;
 import org.apache.felix.dm.DependencyManager;
 import org.osgi.framework.BundleContext;
 public class Activator extends DependencyActivatorBase {
 @Override
 public synchronized void init(BundleContext context, DependencyManager 
 manager) throws Exception {
 manager.add(createComponent()
 .setInterface(A.class.getName(), null)
 .setImplementation(A.class)
 
 .add(createServiceDependency().setService(S.class).setRequired(true)));
 
 manager.add(createComponent()
 .setInterface(S.class.getName(), null)
 .setImplementation(S1.class));
 }
 @Override
 public synchronized void destroy(BundleContext context, DependencyManager 
 manager) throws Exception {}
 
 interface S {}
 class A {}
 class S1 implements S {}
 }
 dm will print out:
 g! dm
 [8] mytest
  [0] org.example.Activator$A unregistered
 org.example.Activator$S service required unavailable
  [1] org.example.Activator$S registered
 But when the class S1 is promoted to a real class, dm will print out:
 g! dm
 [8] mytest
  [0] org.example.Activator$A registered
 org.example.Activator$S service required available
  [1] org.example.Activator$S registered
 So the service class S1 is not available if its an inner class but is 
 available if its a normal class.



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

[jira] [Closed] (FELIX-4357) Support types beside String/String[] in @Property annotation.

[Marcel Offermans (JIRA)]

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

Marcel Offermans closed FELIX-4357.
---

Resolution: Fixed

That's an excellent solution. Thanks Pierre!

 Support types beside String/String[] in @Property annotation.
 -

 Key: FELIX-4357
 URL: https://issues.apache.org/jira/browse/FELIX-4357
 Project: Felix
  Issue Type: Improvement
  Components: Dependency Manager
Reporter: Marcel Offermans
Assignee: Pierre De Rop
Priority: Minor

 The dependency manager has an extension that allows you to use annotations to 
 specify components, services and their dependencies. One of the supported 
 annotations is @Property, which allows you to specify service properties. 
 However, the values it supports are just String and String[], so if you need 
 other types (for example when specifying a service ranking) you are out of 
 luck. You can use the workaround described in the javadoc, which is to use 
 a @Start annotation and method, but it would be more convenient if @Property 
 had support for arbitrary types (for example by just making the value an 
 Object). This issue is about discussing and potentially adding such support.



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

[jira] [Closed] (FELIX-4361) Possible ConcurrentModificationException in DependencyManager.getComponents()

[Marcel Offermans (JIRA)]

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

Marcel Offermans closed FELIX-4361.
---

Resolution: Fixed

Applied the patch.

 Possible ConcurrentModificationException in DependencyManager.getComponents()
 -

 Key: FELIX-4361
 URL: https://issues.apache.org/jira/browse/FELIX-4361
 Project: Felix
  Issue Type: Bug
  Components: Dependency Manager
Affects Versions: dependencymanager-3.1.0
Reporter: Paul Bakker
Assignee: Marcel Offermans
 Attachments: FELIX-4361.patch


 DependencyManager.getComponents() returns a unmodifiableList created as 
 follows:
 {code}
 Collections.unmodifiableList(m_components);
 {code}
 However, this does not provide safe iteration on the result of calling this 
 method. E.g. the following can fail with a ConcurrentModificationException:
 {code}
 ListComponentDeclaration components = dm.getComponents();
 for (ComponentDeclaration c : components) {
   //do something
 }
 {code}
 This is possible because the underlaying collection can be modified during 
 iteration. Wrapping it in an unmodifiable list doesn't prevent this, because 
 the modifications are done on the original list.
 This can be fixed by copying the list to a new collection before returning. 
 This is more expensive, but the only way to be safe.
 Patch and test provided.



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

[jira] [Assigned] (FELIX-4361) Possible ConcurrentModificationException in DependencyManager.getComponents()

[Marcel Offermans (JIRA)]

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

Marcel Offermans reassigned FELIX-4361:
---

Assignee: Marcel Offermans

 Possible ConcurrentModificationException in DependencyManager.getComponents()
 -

 Key: FELIX-4361
 URL: https://issues.apache.org/jira/browse/FELIX-4361
 Project: Felix
  Issue Type: Bug
  Components: Dependency Manager
Affects Versions: dependencymanager-3.1.0
Reporter: Paul Bakker
Assignee: Marcel Offermans
 Attachments: FELIX-4361.patch


 DependencyManager.getComponents() returns a unmodifiableList created as 
 follows:
 {code}
 Collections.unmodifiableList(m_components);
 {code}
 However, this does not provide safe iteration on the result of calling this 
 method. E.g. the following can fail with a ConcurrentModificationException:
 {code}
 ListComponentDeclaration components = dm.getComponents();
 for (ComponentDeclaration c : components) {
   //do something
 }
 {code}
 This is possible because the underlaying collection can be modified during 
 iteration. Wrapping it in an unmodifiable list doesn't prevent this, because 
 the modifications are done on the original list.
 This can be fixed by copying the list to a new collection before returning. 
 This is more expensive, but the only way to be safe.
 Patch and test provided.



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

[jira] [Created] (FELIX-4357) Support types beside String/String[] in @Property annotation.

[Marcel Offermans (JIRA)]

Marcel Offermans created FELIX-4357:
---

 Summary: Support types beside String/String[] in @Property 
annotation.
 Key: FELIX-4357
 URL: https://issues.apache.org/jira/browse/FELIX-4357
 Project: Felix
  Issue Type: Improvement
  Components: Dependency Manager
Reporter: Marcel Offermans
Priority: Minor


The dependency manager has an extension that allows you to use annotations to 
specify components, services and their dependencies. One of the supported 
annotations is @Property, which allows you to specify service properties. 
However, the values it supports are just String and String[], so if you need 
other types (for example when specifying a service ranking) you are out of 
luck. You can use the workaround described in the javadoc, which is to use a 
@Start annotation and method, but it would be more convenient if @Property had 
support for arbitrary types (for example by just making the value an Object). 
This issue is about discussing and potentially adding such support.



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

Re: [VOTE] Release DeploymentAdmin 0.9.5 and AutoConf Processor 0.1.5

[Marcel Offermans]

+1

Checked the signatures. Used both bundles in Apache ACE and found no functional 
issues.

Greetings, Marcel

Re: [VOTE] Release Felix HTTP v2.2.2

[Marcel Offermans]

+1

Validated the signatures.
Tested in Apache ACE, played around with it a bit.

Greetings, Marcel

[jira] [Created] (FELIX-4314) Split service registration to solve visibility issue in autoconf

[Marcel Offermans (JIRA)]

Marcel Offermans created FELIX-4314:
---

 Summary: Split service registration to solve visibility issue in 
autoconf
 Key: FELIX-4314
 URL: https://issues.apache.org/jira/browse/FELIX-4314
 Project: Felix
  Issue Type: Bug
  Components: Deployment Admin
Reporter: Marcel Offermans
Assignee: Marcel Offermans


The current implementation of autoconf registers itself as both a 
ResourceProcessor and EventHandler. The first because, obviously, it is a 
resource processor. The second because it wants to know when the deployment 
session ends, which is signalled through an event.

This creates an interesting visibility issue, especially when bootstrapping an 
OSGi framework by installing a deployment package containing everything.

Initially this means there is just some management agent available. Through 
DeploymentAdmin the agent installs the deployment package which contains 
bundles and configuration data. The bundles that are included contain 
EventAdmin and ConfigurationAdmin.

Let's also assume that the management agent has no dependency on EventAdmin, 
not even its API, because a) it does not want to depend on it (through an 
ImportPackage) and b) it does not want to provide and depend on it either 
(because it tries to isolate itself as much as possible from the rest of the 
framework).

This creates an interesting problem: because autoconf registers as both a 
ResourceProcessor and EventHandler, and EventHandler is not visible to the 
agent, it will *not* see the resource processor either. Therefore the 
deployment will fail in a way that is hard to debug (if you inspect the 
registry, the service is there, it's just that the agent is not allowed to see 
it).

The easiest solution is to split the registration into two. First just register 
as a ResourceProcessor and then, separately, also register as an EventHandler. 
In fact, in this case, we can defer the latter a bit until we are actually 
interested in the event.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (FELIX-4314) Split service registration to solve visibility issue in autoconf

[Marcel Offermans (JIRA)]

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

Marcel Offermans resolved FELIX-4314.
-

Resolution: Fixed

Implemented.

 Split service registration to solve visibility issue in autoconf
 

 Key: FELIX-4314
 URL: https://issues.apache.org/jira/browse/FELIX-4314
 Project: Felix
  Issue Type: Bug
  Components: Deployment Admin
Reporter: Marcel Offermans
Assignee: Marcel Offermans

 The current implementation of autoconf registers itself as both a 
 ResourceProcessor and EventHandler. The first because, obviously, it is a 
 resource processor. The second because it wants to know when the deployment 
 session ends, which is signalled through an event.
 This creates an interesting visibility issue, especially when bootstrapping 
 an OSGi framework by installing a deployment package containing everything.
 Initially this means there is just some management agent available. Through 
 DeploymentAdmin the agent installs the deployment package which contains 
 bundles and configuration data. The bundles that are included contain 
 EventAdmin and ConfigurationAdmin.
 Let's also assume that the management agent has no dependency on EventAdmin, 
 not even its API, because a) it does not want to depend on it (through an 
 ImportPackage) and b) it does not want to provide and depend on it either 
 (because it tries to isolate itself as much as possible from the rest of the 
 framework).
 This creates an interesting problem: because autoconf registers as both a 
 ResourceProcessor and EventHandler, and EventHandler is not visible to the 
 agent, it will *not* see the resource processor either. Therefore the 
 deployment will fail in a way that is hard to debug (if you inspect the 
 registry, the service is there, it's just that the agent is not allowed to 
 see it).
 The easiest solution is to split the registration into two. First just 
 register as a ResourceProcessor and then, separately, also register as an 
 EventHandler. In fact, in this case, we can defer the latter a bit until we 
 are actually interested in the event.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Assigned] (FELIX-3355) Autoconf can't find Metatype service

[Marcel Offermans (JIRA)]

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

Marcel Offermans reassigned FELIX-3355:
---

Assignee: Marcel Offermans

 Autoconf can't find Metatype service
 

 Key: FELIX-3355
 URL: https://issues.apache.org/jira/browse/FELIX-3355
 Project: Felix
  Issue Type: Bug
  Components: Deployment Admin
Affects Versions: autoconf-rp-0.1.0
Reporter: Bram de Kruijff
Assignee: Marcel Offermans
 Fix For: autoconf-rp-0.1.4


 Although Autoconf appears to consult MetaTypeService to resolve OCDs in code 
 it never will. This is caused by the fact that the bundle does not import 
 org.osgi.service.metatype, but embeds it. Any actual MetaTypeService will not 
 be assignable.
 The reason it doesn't fail is that the dependencymanager dependency is 
 optional. As a result the AutoconfResourceProcessor operates against an 
 injected NullObject. You never get any warning, but it simply never resolves 
 OCDs. 
 Besides fixing the import IMHO it would not be unreasnable to require 
 MetaTypeService
 {code}
 Index: autoconf/pom.xml
 ===
 --- autoconf/pom.xml(revision 1245822)
 +++ autoconf/pom.xml(working copy)
 @@ -86,7 +86,7 @@
  Bundle-NameApache Felix AutoConf Resource 
 Processor/Bundle-Name
  Bundle-DescriptionA customizer bundle that 
 publishes a Resource Processor service that processes configuration resources 
 shipped in a
  Deployment Package./Bundle-Description
  Bundle-VendorApache Software 
 Foundation/Bundle-Vendor
 -
 Private-Packageorg.apache.felix.deployment.rp.autoconf, 
 org.apache.felix.metatype, org.apache.felix.metatype.internal.l10n, org.apach
 e.felix.metatype.internal, org.kxml2.io;-split-package:=merge-first, 
 org.xmlpull.v1;-split-package:=merge-first, 
 org.osgi.service.metatype;-split-package:=merge
 -first/Private-Package
 +
 Private-Packageorg.apache.felix.deployment.rp.autoconf, 
 org.apache.felix.metatype, org.apache.felix.metatype.internal.l10n, org.apach
 e.felix.metatype.internal, org.kxml2.io;-split-package:=merge-first, 
 org.xmlpull.v1;-split-package:=merge-first/Private-Package
  
 Export-Packageorg.osgi.service.deploymentadmin.spi;version=1.0/Export-Package
  
 DeploymentPackage-Customizertrue/DeploymentPackage-Customizer
  
 Deployment-ProvidesResourceProcessororg.osgi.deployment.rp.autoconf/Deployment-ProvidesResourceProcessor
 {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (FELIX-3355) Autoconf can't find Metatype service

[Marcel Offermans (JIRA)]

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

Marcel Offermans resolved FELIX-3355.
-

Resolution: Fixed

Committed a fix.

 Autoconf can't find Metatype service
 

 Key: FELIX-3355
 URL: https://issues.apache.org/jira/browse/FELIX-3355
 Project: Felix
  Issue Type: Bug
  Components: Deployment Admin
Affects Versions: autoconf-rp-0.1.0
Reporter: Bram de Kruijff
Assignee: Marcel Offermans
 Fix For: autoconf-rp-0.1.4


 Although Autoconf appears to consult MetaTypeService to resolve OCDs in code 
 it never will. This is caused by the fact that the bundle does not import 
 org.osgi.service.metatype, but embeds it. Any actual MetaTypeService will not 
 be assignable.
 The reason it doesn't fail is that the dependencymanager dependency is 
 optional. As a result the AutoconfResourceProcessor operates against an 
 injected NullObject. You never get any warning, but it simply never resolves 
 OCDs. 
 Besides fixing the import IMHO it would not be unreasnable to require 
 MetaTypeService
 {code}
 Index: autoconf/pom.xml
 ===
 --- autoconf/pom.xml(revision 1245822)
 +++ autoconf/pom.xml(working copy)
 @@ -86,7 +86,7 @@
  Bundle-NameApache Felix AutoConf Resource 
 Processor/Bundle-Name
  Bundle-DescriptionA customizer bundle that 
 publishes a Resource Processor service that processes configuration resources 
 shipped in a
  Deployment Package./Bundle-Description
  Bundle-VendorApache Software 
 Foundation/Bundle-Vendor
 -
 Private-Packageorg.apache.felix.deployment.rp.autoconf, 
 org.apache.felix.metatype, org.apache.felix.metatype.internal.l10n, org.apach
 e.felix.metatype.internal, org.kxml2.io;-split-package:=merge-first, 
 org.xmlpull.v1;-split-package:=merge-first, 
 org.osgi.service.metatype;-split-package:=merge
 -first/Private-Package
 +
 Private-Packageorg.apache.felix.deployment.rp.autoconf, 
 org.apache.felix.metatype, org.apache.felix.metatype.internal.l10n, org.apach
 e.felix.metatype.internal, org.kxml2.io;-split-package:=merge-first, 
 org.xmlpull.v1;-split-package:=merge-first/Private-Package
  
 Export-Packageorg.osgi.service.deploymentadmin.spi;version=1.0/Export-Package
  
 DeploymentPackage-Customizertrue/DeploymentPackage-Customizer
  
 Deployment-ProvidesResourceProcessororg.osgi.deployment.rp.autoconf/Deployment-ProvidesResourceProcessor
 {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (FELIX-4184) Temporary resolver errors while updating bundles with deploymentadmin

[Marcel Offermans (JIRA)]

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

Marcel Offermans commented on FELIX-4184:
-

Following up. Jan Willem correctly mentions that, due to a flaw, we currently 
don't stop *affected* bundles at all, but attempt to update them while running. 
This causes the resolve issues mentioned above. An example:

Say we update a bundle that implements some API, and the bundle containing it, 
because the API has been changed. If we first update the implementation without 
stopping it, it will try to resolve against the new API and fail because that 
has not yet been installed. Stopping both bundles first, then updating, 
refreshing and then starting again solves that issue nicely.

So that's what we need to do here!

 Temporary resolver errors while updating bundles with deploymentadmin
 -

 Key: FELIX-4184
 URL: https://issues.apache.org/jira/browse/FELIX-4184
 Project: Felix
  Issue Type: Bug
  Components: Deployment Admin
Affects Versions: deploymentadmin-0.9.4
Reporter: Marcel Offermans

 When you use the system property to not stop the world during an update, 
 updating a running bundle might cause a (temporary) resolver error (I've seen 
 it throw exceptions related to uses constraints). According to the spec, if 
 we get an exception here, we should rollback. If you stop the world, this 
 never happens, but here such temporary exceptions are probably resolved when 
 we refresh packages at the end. That does not happen though, since we never 
 get there. We should consider covering this use case, letting the deployment 
 continue and deal with errors when resolving (and maybe then rolling back).



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Assigned] (FELIX-4184) Temporary resolver errors while updating bundles with deploymentadmin

[Marcel Offermans (JIRA)]

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

Marcel Offermans reassigned FELIX-4184:
---

Assignee: Marcel Offermans

 Temporary resolver errors while updating bundles with deploymentadmin
 -

 Key: FELIX-4184
 URL: https://issues.apache.org/jira/browse/FELIX-4184
 Project: Felix
  Issue Type: Bug
  Components: Deployment Admin
Affects Versions: deploymentadmin-0.9.4
Reporter: Marcel Offermans
Assignee: Marcel Offermans

 When you use the system property to not stop the world during an update, 
 updating a running bundle might cause a (temporary) resolver error (I've seen 
 it throw exceptions related to uses constraints). According to the spec, if 
 we get an exception here, we should rollback. If you stop the world, this 
 never happens, but here such temporary exceptions are probably resolved when 
 we refresh packages at the end. That does not happen though, since we never 
 get there. We should consider covering this use case, letting the deployment 
 continue and deal with errors when resolving (and maybe then rolling back).



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (FELIX-4184) Temporary resolver errors while updating bundles with deploymentadmin

[Marcel Offermans (JIRA)]

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

Marcel Offermans resolved FELIX-4184.
-

Resolution: Fixed

Added test and fix for the issue.

 Temporary resolver errors while updating bundles with deploymentadmin
 -

 Key: FELIX-4184
 URL: https://issues.apache.org/jira/browse/FELIX-4184
 Project: Felix
  Issue Type: Bug
  Components: Deployment Admin
Affects Versions: deploymentadmin-0.9.4
Reporter: Marcel Offermans
Assignee: Marcel Offermans

 When you use the system property to not stop the world during an update, 
 updating a running bundle might cause a (temporary) resolver error (I've seen 
 it throw exceptions related to uses constraints). According to the spec, if 
 we get an exception here, we should rollback. If you stop the world, this 
 never happens, but here such temporary exceptions are probably resolved when 
 we refresh packages at the end. That does not happen though, since we never 
 get there. We should consider covering this use case, letting the deployment 
 continue and deal with errors when resolving (and maybe then rolling back).



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (FELIX-4282) HTTP Bundle 2.1.1 has and incorrect embedded Jetty instance

[Marcel Offermans (JIRA)]

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

Marcel Offermans commented on FELIX-4282:
-

Out of curiosity, how do you determine that the Jetty version we've used in the 
release is a snapshot version, and not an official release? As far as I can 
see, we've used an official release that was announced [1] by the Jetty 
community. Granted, there might still be a bug in there, but the text implies 
that we did something wrong by including a snapshot release and I don't think 
that is actually true.

Also, feel free to provide patches and/or extra tests if you feel strongly 
about this issue as both will obviously help us provide a new release sooner.

[1] http://dev.eclipse.org/mhonarc/lists/jetty-announce/msg00052.html

 HTTP Bundle 2.1.1 has and incorrect embedded Jetty instance
 ---

 Key: FELIX-4282
 URL: https://issues.apache.org/jira/browse/FELIX-4282
 Project: Felix
  Issue Type: Bug
  Components: HTTP Service
Reporter: Bruce Jackson

 I've recently downloaded the latest version of the http bundle 2.2.1 which
 contains the update to Jetty 7. This seems to have a problem, perhaps
 because the Jetty version is a snapshot.
 java.lang.NoSuchMethodError:
 org.eclipse.jetty.util.QuotedStringTokenizer.unquoteOnly(Ljava/lang/String;
 )Ljava/lang/String;
   at
 org.eclipse.jetty.server.CookieCutter.parseFields(CookieCutter.java:284)
   at 
 org.eclipse.jetty.server.CookieCutter.getCookies(CookieCutter.java:64)
   at org.eclipse.jetty.server.Request.getCookies(Request.java:499)
   at
 org.eclipse.jetty.server.session.SessionHandler.checkRequestedSessionId(Ses
 sionHandler.java:260)
   at
 org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java
 :155)
   at
 org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java
 :978)
   at
 org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:13
 5)
   at
 org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHan
 dlerCollection.java:255)
   at
 org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:
 116)
   at org.eclipse.jetty.server.Server.handle(Server.java:369)
   at
 org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpC
 onnection.java:486)
   at
 org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttp
 Connection.java:933)
   at
 org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComple
 te(AbstractHttpConnection.java:995)
   at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:630)
   at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:230)
   at
 org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.jav
 a:82)
   at
 org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint
 .java:606)
   at
 org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.
 java:46)
   at
 org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java
 :603)
   at
 org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:
 538)
   at java.lang.Thread.run(Thread.java:724)
 If I build the bundle manually with the 7.4.16 Jetty-all, I don't see this
 problem.
 I'm using the released HTTP Bundle from the felix download site. If I
 manually remove the classes from the exploded jar and replace them with
 the contents of the latest release Jetty all build (which is
 jetty-all-server-7.6.13.v20130916) then I no longer see this problem.
 I suspect that the reason that we see this is that we are using Jetty 7
 continuations (looking at the stack trace, this seems to be an async
 operation) and so if you're not using them, you may never have encountered
 this problem.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (FELIX-4294) Dependency Manager Shell improvements

[Marcel Offermans (JIRA)]

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

Marcel Offermans commented on FELIX-4294:
-

You're welcome. I remember that during a face to face meeting, Xander and I 
discussed some other possible extensions he had as well. I'm sure he has some 
feedback on this as well. :)

 Dependency Manager Shell improvements
 -

 Key: FELIX-4294
 URL: https://issues.apache.org/jira/browse/FELIX-4294
 Project: Felix
  Issue Type: Improvement
  Components: Dependency Manager
Affects Versions: dependencymanager-3.1.0
Reporter: Pierre De Rop
Assignee: Pierre De Rop
Priority: Minor

 This issue proposes two enhancements regarding the dependency manager shell.
 1) display component names more consistently
 =
 - some components are sometimes displayed with a class  prefix, while 
 others are not:
 class org.amdatu.multitenant.adapter.TenantAdapter registered
 org.amdatu.multitenant.adapter.BundleDataStore(org.amdatu.tenant.pid=org.amdatu.tenant.PLATFORM,bundle.id=18)
  registered
 For readability, the class  could be just removed.
 - When a component does not contain any service properties, an empty () is 
 displayed after the component name
 pierre.multitenant.both.Both() registered
  org.amdatu.multitenant.TenantLifeCycleListener(org.amdatu.tenant.binding=3) 
 registered
 As in previous case and for readability, it makes sense to not append an 
 empty () after the component name, if it has no properties.
 2) add filter and nofilters options for filter displayed components
 =
 By default, the  dm  shell command dumps all components. But sometimes, it 
 is desirable to display a subset of all components, 
 using a regular expression on the component name or on the component service 
 properties.
 We can of course do this using gogo shell grep, but the problem is that we 
 may miss some important informations, like the component bundle id, or the 
 component dependencies.
 As an example, let's assume we are using the AMDATU mutli-tenancy framework. 
 With AMDATU MT, many internal AMDATU components are instantiated behind the 
 scene for a given tenant bundle.
 In the following example, we have three tenant bundles, and if we type dm, 
 then we are getting a long list of components, including:
   - application tenant components: pierre.multitenant.*
   - some internal amdatu mt components (org.amdatu.multitenant.*):
 g! dm
 [2] org.amdatu.multitenant.conf
   
 org.osgi.service.cm.ManagedServiceFactory(service.pid=org.amdatu.tenant.factory)
  registered
 org.amdatu.multitenant.TenantFactoryConfiguration service required 
 available
 org.osgi.service.log.LogService service optional available
 [3] org.amdatu.multitenant.factory
   org.amdatu.multitenant.TenantFactoryConfiguration() registered
 org.osgi.service.log.LogService service optional available
 org.amdatu.multitenant.TenantLifeCycleListener service optional available
   
 org.amdatu.multitenant.Tenant(service.pid=org.amdatu.tenant.factory.91a788f0-da4f-405d-a643-b220f4b2bcee,org.amdatu.tenant.pid=org.amdatu.tenant.factory.91a788f0-da4f-405d-a643-b220f4b2bcee,service.factoryPid=org.amdatu.tenant.factory,org.amdatu.tenant.name=bar2,felix.fileinstall.filename=file:/home/nxuser/work/osgi/amdatu/felix-framework-4.2.1/load/org.amdatu.tenant.factory-2.cfg,foo=bar)
  registered
   
 org.amdatu.multitenant.Tenant(org.amdatu.tenant.pid=org.amdatu.tenant.PLATFORM,org.amdatu.tenant.name=Platform
  Tenant) registered
   
 org.amdatu.multitenant.Tenant(service.pid=org.amdatu.tenant.factory.f4d53487-5a51-480c-9f67-ba64d657986c,org.amdatu.tenant.pid=org.amdatu.tenant.factory.f4d53487-5a51-480c-9f67-ba64d657986c,service.factoryPid=org.amdatu.tenant.factory,felix.fileinstall.filename=file:/home/nxuser/work/osgi/amdatu/felix-framework-4.2.1/load/org.amdatu.tenant.factory-1.cfg,foo=bar2)
  registered
 [5] org.amdatu.multitenant.org.apache.felix.dependencymanager.runtime
   class org.apache.felix.dm.runtime.DependencyManagerRuntime registered
 org.osgi.service.log.LogService service optional unavailable
 active (DependencyManager-Component=*) bundle optional unavailable
   org.amdatu.multitenant.TenantLifeCycleListener(org.amdatu.tenant.binding=3) 
 registered
   Adapter for interface org.amdatu.multitenant.Tenant registered
 org.amdatu.multitenant.Tenant service optional available
 org.osgi.service.log.LogService service optional available
   class org.amdatu.multitenant.adapter.TenantAdapter registered
 org.amdatu.multitenant.Tenant 
 (|(service.id=32)(org.apache.felix.dependencymanager.aspect=32)) service 
 required available
 org.osgi.service.log.LogService

Re: Why DependencyManager rather than DS?

[Marcel Offermans]

Hello David,

Sit down first, this is a long mail. :)

On Oct 16, 2013, at 1:06 AM, David Jencks david_jen...@yahoo.com wrote:
 On Oct 15, 2013, at 1:33 PM, Marcel Offermans marcel.offerm...@luminis.nl 
 wrote:
 On Oct 15, 2013, at 19:51 PM, David Jencks david_jen...@yahoo.com wrote:

 DS still can't do dynamic dependencies, nor is it extensible to support new 
 types of dependencies (DM comes with dependencies to track services, 
 configuration, bundles and resources. To give an example, DM can declare a 
 component that requires service A and configuration B. As soon as it has 
 both, the component can evaluate configuration B and depending on its 
 contents add another service dependency C (or something like that).
 
 Do you have an example?  The requires service A and configuration B sounds 
 like in DS a 1..1 reference to A and ConfigurationPolicy.REQUIRE.

This part is the same as DS, and it would look somewhat like this in DM:

public class Activator extends DependencyActivatorBase {
public void init(BundleContext c, DependencyManager dm) throws 
Exception {
dm.add(createComponent()

.setImplementation(ComponentWithDynamicDependencies.class)
.add(createServiceDependency()
.setService(EventAdmin.class)
.setRequired(true))
.add(createConfigurationDependency()
.setPid(org.foo.pid)));
}

public void destroy(BundleContext c, DependencyManager dm) throws 
Exception {
}
}

So we end up with a component that will be instantiated lazily by creating an 
instance of ComponentWithDynamicDependencies as soon as the EventAdmin service 
is available and a configuration called org.foo.pid. For that configuration 
we can also do very specific checks in code to determine if it contains all the 
information we want. If not, DM will not consider the requirement as 
satisfied and the component will wait until a good configuration comes along 
(see updated method below).

 What adds the dependency on C?  How does this differ from including the 
 C.target property in the configuration?

The component does, programmatically, as soon as the two requirements above 
have been satisfied. Let's continue with our example:

public class ComponentWithDynamicDependencies implements ManagedService {
private volatile EventAdmin m_eventAdmin;
private String m_filter;
private boolean m_isRequired;

public void init(Component c) {
DependencyManager dm = c.getDependencyManager();
c.add(dm.createServiceDependency()
.setService(Storage.class, m_filter)
.setRequired(m_isRequired)
.setInstanceBound(true));
}

public void updated(Dictionary properties) throws 
ConfigurationException {
m_filter = (String) getNotNull(properties, filter);
m_isRequired = (Boolean) getNotNull(properties, required);
}

private Object getNotNull(Dictionary properties, String key) throws 
ConfigurationException {
Object result = properties.get(key);
if (result == null) {
throw new ConfigurationException(key, must be 
specified);
}
return result;
}
}

So the updated method checks the incoming properties and checks if the two 
ones we need are really there. Here you could (and maybe should) do more 
consistency checks, such as make sure you got a valid filter, etc. but I left 
that out to keep the example simple).

Then, the init method is automatically invoked as part of the life cycle of 
the component, as soon as the two dependencies are present. It takes the 
Component, as previously declared in the Activator, as an optional argument 
and in this case we use that to add an extra service dependency on a Storage 
class with the filter condition that was in the configuration data. Also, a 
second condition determines if the dependency is optional or required.

 DM also has concepts like aspects and adapters, that allow you to declare 
 factories that automatically generate components that attach to other 
 services. In the case of aspects creating a whole chain of services, 
 allowing you to easily intercept existing services and add behaviour such as 
 adding a cache to a store. In the case of adapters allowing you to add for 
 example management capabilities to services.. Just to name a few examples. 
 This really deserves a longer description, but this gives you a general idea.
 
 From my quick look at the docs it looked like these examples basically 
 registered another service exposing the same interface and with a dependency 
 on the original service, something that is easy to do with DS as well.  I 
 didn't see the factory aspect described

Re: Why DependencyManager rather than DS?

[Marcel Offermans]

Hello David,

On Oct 15, 2013, at 19:51 PM, David Jencks david_jen...@yahoo.com wrote:

 After seeing a lot of commit activity on DependencyManager I decided to try 
 to understand what it's for, and after looking at the documentation I'm still 
 not sure.  It looks to me like the main feature is a fluent api that provides 
 something like DS, although less declaratively, and then there are some 
 special cases that might be slightly simpler than just declaring a service 
 that does the same thing (aspects, temporal)

DependencyManager has its roots long time ago, when there was no Declarative 
Services specification yet. It started when I was working on my first big OSGi 
project (about 10 years ago) and we needed a library to help us declare and 
manage dependencies.

The only library at that time was servicebinder, which was somewhat similar 
to what became DS. We evaluated that library for our project, but it did not 
fulfill all our use cases.

Most importantly, we had use cases that required us to declare dependencies at 
runtime, for example based on configuration data or some hardware aspects we 
discovered at runtime. Furthermore, I did not like the XML configuration, which 
did not automatically update when refactoring your code and did not have code 
completion or syntax checking.

That last bit has been improved now that DS supports annotations to generate 
XML.

 So as a DS partisan :-) I'm wondering what the big advantages of 
 DependencyManager are.

DS still can't do dynamic dependencies, nor is it extensible to support new 
types of dependencies (DM comes with dependencies to track services, 
configuration, bundles and resources. To give an example, DM can declare a 
component that requires service A and configuration B. As soon as it has both, 
the component can evaluate configuration B and depending on its contents add 
another service dependency C (or something like that).

DM also has concepts like aspects and adapters, that allow you to declare 
factories that automatically generate components that attach to other services. 
In the case of aspects creating a whole chain of services, allowing you to 
easily intercept existing services and add behaviour such as adding a cache to 
a store. In the case of adapters allowing you to add for example management 
capabilities to services.. Just to name a few examples. This really deserves a 
longer description, but this gives you a general idea.

A third feature that might be interesting is that DM also has support for 
indices that dramatically speed up the OSGi service registry when you're 
dealing with applications that consist of lots of services (1k-10k or even 
more). It uses a technique similar to what relational databases use to speed up 
lookups. Xander did a lot of work on this, they have a huge application that 
used to take about 30 minutes to start up and now does so in more like 30 
seconds (so orders of magnitude speedup).

 I also wonder if it would be useful to add to DS a fluent api for adding 
 components at runtime.  I think this would be pretty easy, just construct 
 ComponentMetadata and add it to the appropriate BundleComponentActivator.

Creating the fluent API would not be too hard, but DS is not dynamic, you need 
to package the XML with the bundle for it to work, so that part would be harder 
to fix (unless you resort to generating bundles on the fly or something like 
that).

The other way round would be easier: creating an extender bundle that reads the 
XML descriptors that DS uses and using DM to create the appropriate components.

For the record, DM currently also has an annotation based API, contributed a 
while ago by Pierre and Arjun.

Greetings, Marcel

Re: Time for new Felix HTTP release?

[Marcel Offermans]

I've tested the snapshot, both in a personal project and in Apache ACE, and it 
works nicely, so no objections from me.

Greetings, Marcel


On Sep 12, 2013, at 15:50 PM, Jan Willem Janssen janwillem.jans...@luminis.eu 
wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Hi,
 
 I think it's time for a new release of the HTTP implementation. Are
 there any objections to this? Any urgent issues that *must* be fixed?
 
 - -- 
 Met vriendelijke groeten | Kind regards
 
 Jan Willem Janssen | Software Architect
 +31 631 765 814
 
 /My world is revolving around PulseOn and Amdatu/
 
 Luminis Technologies B.V.
 J.C. Wilslaan 29
 7313 HK   Apeldoorn
 +31 88 586 46 30
 
 http://www.luminis-technologies.com
 http://www.luminis.eu
 
 KvK (CoC) 09 16 28 93
 BTW (VAT) NL8169.78.566.B.01
 -BEGIN PGP SIGNATURE-
 Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
 Comment: GPGTools - http://gpgtools.org
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
 
 iQIcBAEBAgAGBQJSMcaJAAoJEKF/mP2eHDc4r4YQANFI+u+aXsrS1uL2FGH94/UW
 VmsENLQJ+W4wkG5fQcQljernHM6XE1ckSoX4RYrimSuPbSiTKLbgGHe31sBGjtcX
 kSYCtG5Qr8iG4ViZstUp/wTJAbMwj9sVyN2OrsOJWgZINyPhhF23En2Tr8+qQm4n
 RKv7c/LgEbL9+J/irzfbf/GcUSkjQtQM6BolIfOZwlqtm6QQF4odeiuh3YlK/3uE
 Or78PUCLZjePa5M8fn5OXi/khh+YZ2q/cUcUvHUr4sPn5fgVzjG85jLwj5K4UBcW
 Q570rwmDNh64y8MtXEPvemQ53WMxm+GZzaHL5CBY8cNT7VC9fHWl9YNYui8Q97Kq
 yFHgKVol2B+cxLKlcGHVGmLPrGSI7XuoP95slflc507QpshxqQ6yWn6dUAg8y6oN
 aFWjrie2RcRjAGtXivHmqD7zEzaZDidrIYILI+9hJCdEk6R5e2swl0bDP5WAFqVk
 PVtTpbDzXaDfdOA51pdKGDA667zZxIy8WEUZ5fajkOubm15xqw8cYiniLq0Nyfoz
 GldSaGVJdIQpXUMBHCjTMdnrHk1oo3+o3lSXEIZePj6v/1MRzT5tD6tzKAkAHQrs
 E4Mr/PWpYazBjwbjF7vHA6/wqzvn/ZGXJFcPfPFlw9f+OooomfQRHYKxoUngwXKr
 9oLFWrUUlQTKfDOJX0oh
 =L44K
 -END PGP SIGNATURE-

Re: Some download links not working

[Marcel Offermans]

Thanks!

Crossposting to dev@ for follow up. I took a quick look but I'm not quite sure 
how to fix this. Felix (Meschberger), could you take a quick look, since I'm 
guessing you came up with the code to generate the downloads page?

Greetings, Marcel


On Aug 22, 2013, at 16:37 , jacgec jacge...@gmail.com wrote:

 Thanks for checking into this Marcel.  The new jira entry has been created:
 
 https://issues.apache.org/jira/browse/FELIX-4201
 
 
 
 --
 View this message in context: 
 http://apache-felix.18485.x6.nabble.com/Some-download-links-not-working-tp5004666p5004670.html
 Sent from the Apache Felix - Users mailing list archive at Nabble.com.
 
 -
 To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
 For additional commands, e-mail: users-h...@felix.apache.org
 

Re: [DS/SCR] Configuration Binding

[Marcel Offermans]

Hello Felix,

On Aug 12, 2013, at 7:52 AM, Felix Meschberger fmesc...@adobe.com wrote:

 Currently our Declarative Services implementation statically binds 
 configuration to the using bundle when such configuration is used to 
 configure a component. The intent was to follow the Configuration Admin 
 specification which also statically binds configuration to 
 ManagedService[Factory] when first supplying configuration which is not 
 previously bound.

In fact, the spec calls this dynamic binding when you supply a configuration 
that will be bound to the first bundle that registers a MS[F] with that PID. If 
this is indeed what you're talking about then I don't really get the problem 
you're describing as the spec already states (4.3 compendium 104.4.2):

When this dynamically bound Bundle is subsequently uninstalled, configurations 
that are bound to this bundle must be released. That means that for such 
Configuration object’s the bundle location must be set to null again so it can 
be bound again to another bundle.

 This mechanism works really nicely but has a problematic drawback: When the 
 owning bundle is uninstalled, configurations remain bound. If a new version 
 of the same bundle is installed later, configuration will thus not be 
 supplied because, presumably, the bundle will have a new bundle location and 
 thus does not own the configuration.
 
 I could imagine two solutions to this problem:
 
 (1) DS does not statically bind configuration any longer. So, if unbound 
 configuration is supplied to a component, it just remains unbound. In my 
 understanding, this bends on the semantics defined by the Configuration Admin 
 specification.
 
 (2) DS maintains a list of configurations which it has statically bound. On 
 Bundle UNINSTALLED events the location of the uninstalled bundle is matched 
 against the bindings of the configurations in the list and if such bindings 
 exists, it is removed again. In my understanding, this would be the correct 
 solution but is somewhat more complicated to implement.
 
 WDYT ?

Just exploring the possible solutions:

(3) make sure you always set the location for the bundle with the same value, 
even after a re-install (for example, deployment admin uses the BSN as the 
location, which nicely solves this problem)

(4) if you target 4.3 you could look into using the multi-location feature 
(although that might be bending the spec a bit as well)

Greetings, Marcel

Re: [DS/SCR] Configuration Binding

[Marcel Offermans]

I don't think you're missing something. The spec states CA should be doing that 
already, so if our implementation is not, we should raise a bug.

Greetings, Marcel

On Aug 12, 2013, at 9:40 , David Jencks david_jen...@yahoo.com wrote:

 Hi,
 
 I was under the impression that setting the location of the configuration to 
 null when the bundle that owns the configuration is uninstalled was the 
 responsibility of config admin.  Config admin sets the location when you call 
 getConfiguration using the bundle's CA, surely it is also CA's responsibility 
 to track the bundle and undo the locations when the bundle is uninstalled.
 
 Am I missing something?
 
 I don't see how it could affect this but I have a few tests and bug fixes for 
 location binding and targeted pids that I hope to finish up and commit in the 
 next couple of days.
 
 thanks
 david jencks
 
 On Aug 12, 2013, at 12:34 AM, Felix Meschberger fmesc...@adobe.com wrote:
 
 Hi
 
 Am 12.08.2013 um 08:16 schrieb Marcel Offermans:
 
 Hello Felix,
 
 On Aug 12, 2013, at 7:52 AM, Felix Meschberger fmesc...@adobe.com wrote:
 
 Currently our Declarative Services implementation statically binds 
 configuration to the using bundle when such configuration is used to 
 configure a component. The intent was to follow the Configuration Admin 
 specification which also statically binds configuration to 
 ManagedService[Factory] when first supplying configuration which is not 
 previously bound.
 
 In fact, the spec calls this dynamic binding when you supply a 
 configuration that will be bound to the first bundle that registers a MS[F] 
 with that PID. If this is indeed what you're talking about then I don't 
 really get the problem you're describing as the spec already states (4.3 
 compendium 104.4.2):
 
 When this dynamically bound Bundle is subsequently uninstalled, 
 configurations that are bound to this bundle must be released. That means 
 that for such Configuration object’s the bundle location must be set to 
 null again so it can be bound again to another bundle.
 
 Yes, that would be my solution (2) ;-)
 
 This mechanism works really nicely but has a problematic drawback: When 
 the owning bundle is uninstalled, configurations remain bound. If a new 
 version of the same bundle is installed later, configuration will thus not 
 be supplied because, presumably, the bundle will have a new bundle 
 location and thus does not own the configuration.
 
 I could imagine two solutions to this problem:
 
 (1) DS does not statically bind configuration any longer. So, if unbound 
 configuration is supplied to a component, it just remains unbound. In my 
 understanding, this bends on the semantics defined by the Configuration 
 Admin specification.
 
 (2) DS maintains a list of configurations which it has statically bound. 
 On Bundle UNINSTALLED events the location of the uninstalled bundle is 
 matched against the bindings of the configurations in the list and if such 
 bindings exists, it is removed again. In my understanding, this would be 
 the correct solution but is somewhat more complicated to implement.
 
 WDYT ?
 
 Just exploring the possible solutions:
 
 (3) make sure you always set the location for the bundle with the same 
 value, even after a re-install (for example, deployment admin uses the BSN 
 as the location, which nicely solves this problem)
 
 You can only set the location from Bundle.getLocation() and DS has no 
 influence on that. Other installers may use the actual source URL from which 
 the bundle was installed.
 
 
 (4) if you target 4.3 you could look into using the multi-location 
 feature (although that might be bending the spec a bit as well)
 
 Right. That's a thread for the Web Console for example: If configuration is 
 created with the Web Console it should use the generic ?* location by 
 default if the appropriate Configuration Admin API is wired.
 
 Regards
 Felix
 
 
 Greetings, Marcel
 
 
 

[jira] [Created] (FELIX-4184) Temporary resolver errors while updating bundles with deploymentadmin

[Marcel Offermans (JIRA)]

Marcel Offermans created FELIX-4184:
---

 Summary: Temporary resolver errors while updating bundles with 
deploymentadmin
 Key: FELIX-4184
 URL: https://issues.apache.org/jira/browse/FELIX-4184
 Project: Felix
  Issue Type: Bug
  Components: Deployment Admin
Affects Versions: deploymentadmin-0.9.4
Reporter: Marcel Offermans


When you use the system property to not stop the world during an update, 
updating a running bundle might cause a (temporary) resolver error (I've seen 
it throw exceptions related to uses constraints). According to the spec, if we 
get an exception here, we should rollback. If you stop the world, this never 
happens, but here such temporary exceptions are probably resolved when we 
refresh packages at the end. That does not happen though, since we never get 
there. We should consider covering this use case, letting the deployment 
continue and deal with errors when resolving (and maybe then rolling back).

--
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-4184) Temporary resolver errors while updating bundles with deploymentadmin

[Marcel Offermans (JIRA)]

Marcel Offermans created FELIX-4184:
---

 Summary: Temporary resolver errors while updating bundles with 
deploymentadmin
 Key: FELIX-4184
 URL: https://issues.apache.org/jira/browse/FELIX-4184
 Project: Felix
  Issue Type: Bug
  Components: Deployment Admin
Affects Versions: deploymentadmin-0.9.4
Reporter: Marcel Offermans


When you use the system property to not stop the world during an update, 
updating a running bundle might cause a (temporary) resolver error (I've seen 
it throw exceptions related to uses constraints). According to the spec, if we 
get an exception here, we should rollback. If you stop the world, this never 
happens, but here such temporary exceptions are probably resolved when we 
refresh packages at the end. That does not happen though, since we never get 
there. We should consider covering this use case, letting the deployment 
continue and deal with errors when resolving (and maybe then rolling back).

--
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-4184) Temporary resolver errors while updating bundles with deploymentadmin

[Marcel Offermans (JIRA)]

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

Marcel Offermans commented on FELIX-4184:
-

I'm hesitant to go that way Bram, as ultimately it would have to exactly 
simulate what the resolver does. In the case I had, it was a uses constraint 
that failed. Also, unlike what Jan Willem said, we're currently NOT stopping 
any bundles. We leave everything running and invoke update on the active 
bundles.

 Temporary resolver errors while updating bundles with deploymentadmin
 -

 Key: FELIX-4184
 URL: https://issues.apache.org/jira/browse/FELIX-4184
 Project: Felix
  Issue Type: Bug
  Components: Deployment Admin
Affects Versions: deploymentadmin-0.9.4
Reporter: Marcel Offermans

 When you use the system property to not stop the world during an update, 
 updating a running bundle might cause a (temporary) resolver error (I've seen 
 it throw exceptions related to uses constraints). According to the spec, if 
 we get an exception here, we should rollback. If you stop the world, this 
 never happens, but here such temporary exceptions are probably resolved when 
 we refresh packages at the end. That does not happen though, since we never 
 get there. We should consider covering this use case, letting the deployment 
 continue and deal with errors when resolving (and maybe then rolling back).

--
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: [VOTE] Release DeploymentAdmin 0.9.4 and AutoConf Processor 0.1.4

[Marcel Offermans]

+1

[RESULT] [VOTE] Release DeploymentAdmin 0.9.4 and AutoConf Processor 0.1.4

[Marcel Offermans]

Hi,

The vote has passed with the following result :

  +1 (binding): Carsten Ziegeler, Karl Pauls, Marcel Offermans
  +1 (non binding): Bram de Kruijff, Pierre De Rop, Jan Willem Janssen

I will copy this release to the Felix dist directory and promote the artifacts 
to the central Maven repository.

Greetings, Marcel

DP WebConsole suggestion (Was: Re: [VOTE] Release DeploymentAdmin 0.9.4 and AutoConf Processor 0.1.4)

[Marcel Offermans]

On Jun 3, 2013, at 12:32 PM, Pierre De Rop pierre.de...@gmail.com wrote:

 A minor remark regarding the DP webconsole plugin (not concerned by this
 candidate release), I see that DP is located in the Main tab instead of
 the OSGi tab.
 May be I should open a jira issue for moving DP in the OSGi webconsole
 tab section ?

That makes sense, Pierre, please do open an issue for that!

Greetings, Marcel

[VOTE] Release DeploymentAdmin 0.9.2 and AutoConf Processor 0.1.2

[Marcel Offermans]

Hi all,

I'd like to announce the vote for two Felix bundles. These are the changelogs:

DeploymentAdmin Release 0.9.2
-

FELIX-3336 Exceptions related to the pipe used in deployment admin
FELIX-3272 Add property to allow foreign resource processors
FELIX-3515 DeploymentAdmin triggers IOException on install
FELIX-1307 Log situation in DeploymentAdmin impl very unclear
FELIX-3270 Deployment admin incorrectly takes snapshots of bundle data areas
FELIX-3526 DeploymentAdmin fails on windows due to unclosed iostreams
FELIX-1828 Mistake in code of the class UpdateCommand
FELIX-1829 Method AbstractDeploymentPackage.getBundle(...) throws 
NullPointerException
FELIX-3678 org.apache.felix.deploymentadmin imports wrong version of 
org.osgi.service.deploymentadmin
FELIX-3139 Implement uninstall() for deployment admin.

AutoConf Processor Release 0.1.2
-

FELIX-3243 Autoconf does not recognize non-local non-factory OCDs
FELIX-3245 Autoconf handles metatype 1.1 cardinalty wrong
FELIX-3400 Nullpointer in autoconfprocessor for invalid metatype files


There are still some outstanding issues:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20FELIX%20AND%20component%20%3D%20%22Deployment%20Admin%22%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC

Staging repository:
https://repository.apache.org/content/repositories/orgapachefelix-040/

You can use this UNIX script to download the release and verify the signatures:
http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh

Usage:
sh check_staged_release.sh 040 /tmp/felix-staging

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Veto the release (please provide specific comments)

This vote will be open for 72 hours.

Have a nice weekend!

Greetings, Marcel

Re: [VOTE] Release DeploymentAdmin 0.9.2 and AutoConf Processor 0.1.2

[Marcel Offermans]

Hmm, you're right, Bram. I will cancel this vote, fix it, and start a new vote 
later today.

Greetings, Marcel


On May 31, 2013, at 15:21 PM, Bram de Kruijff bdekrui...@gmail.com wrote:

 -1 (non-binding)
 
 It looks like the autoconf rp now has an import constraint
 managmentagent=true for cmpn packages that I think should not be
 there. I know we use it in ACE (beside the typo) to contain the agent,
 but I am guessing this requirements should not be in Felix?
 
 {quote}
 Caused by: org.osgi.framework.BundleException: Unresolved constraint
 in bundle org.apache.felix.deployment.rp.autoconf [470]: Unable to
 resolve 470.0: missing requirement [470.0] osgi.wiring.package;
 ((osgi.wiring.package=org.osgi.service.event)(managmentagent=true)(version=1.2.0)(!(version=2.0.0)))
 {quote}
 
 Regards,
 Bram
 
 
 
 
 Have a nice weekend!
 
 Greetings, Marcel
 

[VOTE] [CANCELLED] Release DeploymentAdmin 0.9.2 and AutoConf Processor 0.1.2

[Marcel Offermans]

After Bram discovered an issue in the AutoConf manifest, I cancelled the vote 
an I will fix the issue. Then I will start a new vote.

[VOTE] Release DeploymentAdmin 0.9.4 and AutoConf Processor 0.1.4

[Marcel Offermans]

Hi all,

After cancelling the previous release, I've fixed the issue and I'd like to 
announce the new vote for two Felix bundles. These are the changelogs:

DeploymentAdmin Release 0.9.4
-

FELIX-3336 Exceptions related to the pipe used in deployment admin
FELIX-3272 Add property to allow foreign resource processors
FELIX-3515 DeploymentAdmin triggers IOException on install
FELIX-1307 Log situation in DeploymentAdmin impl very unclear
FELIX-3270 Deployment admin incorrectly takes snapshots of bundle data areas
FELIX-3526 DeploymentAdmin fails on windows due to unclosed iostreams
FELIX-1828 Mistake in code of the class UpdateCommand
FELIX-1829 Method AbstractDeploymentPackage.getBundle(...) throws 
NullPointerException
FELIX-3678 org.apache.felix.deploymentadmin imports wrong version of 
org.osgi.service.deploymentadmin
FELIX-3139 Implement uninstall() for deployment admin.

AutoConf Processor Release 0.1.4
-

FELIX-3243 Autoconf does not recognize non-local non-factory OCDs
FELIX-3245 Autoconf handles metatype 1.1 cardinalty wrong
FELIX-3400 Nullpointer in autoconfprocessor for invalid metatype files


There are still some outstanding issues:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20FELIX%20AND%20component%20%3D%20%22Deployment%20Admin%22%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC

Staging repository:
https://repository.apache.org/content/repositories/orgapachefelix-042/

You can use this UNIX script to download the release and verify the signatures:
http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh

Usage:
sh check_staged_release.sh 042 /tmp/felix-staging

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Veto the release (please provide specific comments)

This vote will be open for 72 hours.

Have a nice weekend!

Greetings, Marcel

Preparing for release: DeploymentAdmin and AutoConfiguration

[Marcel Offermans]

Hi all,

Just a quick heads-up to the list that I would like to start preparing for a 
new release of both DeploymentAdmin and the (related) AutoConfiguration 
resource processor. There have been quite a few updates to both and within the 
Apache ACE community we have been testing recent snapshots for some time now.

Greetings, Marcel

[jira] [Resolved] (FELIX-3678) org.apache.felix.deploymentadmin imports wrong version of org.osgi.service.deploymentadmin

[Marcel Offermans (JIRA)]

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

Marcel Offermans resolved FELIX-3678.
-

Resolution: Fixed

Has been fixed.

 org.apache.felix.deploymentadmin imports wrong version of 
 org.osgi.service.deploymentadmin
 --

 Key: FELIX-3678
 URL: https://issues.apache.org/jira/browse/FELIX-3678
 Project: Felix
  Issue Type: Bug
  Components: Deployment Admin
Affects Versions: deploymentadmin-0.9.0
 Environment: Any
Reporter: Raymond Augé
Priority: Minor
 Fix For: deploymentadmin-0.9.2


 Export-Package: org.osgi.service.deploymentadmin;uses:=org.osgi.frame
  work;version=1.0,org.osgi.service.deploymentadmin.spi;uses:=org.o
  sgi.framework,org.osgi.service.deploymentadmin;version=1.0
 Import-Package: org.apache.felix.dm;version=[3.0,4),org.osgi.framewo
  rk;version=[1.5,2),org.osgi.service.deploymentadmin;version=[1.1,2
  ),org.osgi.service.deploymentadmin.spi;version=[1.0,2),org.osgi.se
  rvice.event;version=[1.2,2),org.osgi.service.log;version=[1.3,2),
  org.osgi.service.packageadmin;version=[1.2,2)

--
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-3139) Implement uninstall() for deployment admin.

[Marcel Offermans (JIRA)]

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

Marcel Offermans resolved FELIX-3139.
-

   Resolution: Fixed
Fix Version/s: deploymentadmin-0.9.2

Has been implemented.

 Implement uninstall() for deployment admin.
 ---

 Key: FELIX-3139
 URL: https://issues.apache.org/jira/browse/FELIX-3139
 Project: Felix
  Issue Type: Improvement
  Components: Deployment Admin
Reporter: Marcel Offermans
Assignee: Marcel Offermans
 Fix For: deploymentadmin-0.9.2


 Currently, uninstall() is not implemented, even though it's part of the API. 
 The root cause of that is historical, as DA was originally developed for 
 Apache ACE and ACE never uninstalls deployment packages (but instead installs 
 an empty update if you remove all artifacts from a deployment package).

--
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-1829) Method AbstractDeploymentPackage.getBundle(...) throws NullPointerException

[Marcel Offermans (JIRA)]

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

Marcel Offermans resolved FELIX-1829.
-

Resolution: Fixed

Has been fixed.

 Method AbstractDeploymentPackage.getBundle(...) throws NullPointerException
 ---

 Key: FELIX-1829
 URL: https://issues.apache.org/jira/browse/FELIX-1829
 Project: Felix
  Issue Type: Bug
  Components: Deployment Admin
Reporter: Pavel Kodl
Assignee: Marcel Offermans
Priority: Critical
 Fix For: deploymentadmin-0.9.2


 Because in this method on row 115 is:
   if (bundles[i].getSymbolicName().equals(symbolicName)) {
 but should be something like:
   String sn = bundles[i].getSymbolicName();
   if (sn != null  sn.equals(symbolicName)) {
 It happends by installing a deployment package, stack trace is:
 java.lang.NullPointerException
   at 
 org.apache.felix.deploymentadmin.AbstractDeploymentPackage.getBundle(AbstractDeploymentPackage.java:115)
   at 
 org.apache.felix.deploymentadmin.spi.UpdateCommand.execute(UpdateCommand.java:70)
   at 
 org.apache.felix.deploymentadmin.spi.DeploymentSessionImpl.call(DeploymentSessionImpl.java:74)
   at 
 org.apache.felix.deploymentadmin.DeploymentAdminImpl.installDeploymentPackage(DeploymentAdminImpl.java:215)

--
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] [Closed] (FELIX-454) Deployment Admin: Provide implementation of the R4.1 Autoconf Service

[Marcel Offermans (JIRA)]

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

Marcel Offermans closed FELIX-454.
--

Resolution: Fixed

Cleaning up old issues, we have already released a version of autoconf, so I'm 
closing this one.

 Deployment Admin: Provide implementation of the R4.1 Autoconf Service
 -

 Key: FELIX-454
 URL: https://issues.apache.org/jira/browse/FELIX-454
 Project: Felix
  Issue Type: New Feature
  Components: Deployment Admin
Reporter: Felix Meschberger
Assignee: Christian van Spaandonk

 Now that Deployment Admin is on its way into Felix (see FELIX-452), we should 
 also provide an implementation of the AutoConf Service.

--
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] [Closed] (FELIX-1307) Log situation in DeploymentAdmin impl very unclear

[Marcel Offermans (JIRA)]

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

Marcel Offermans closed FELIX-1307.
---

   Resolution: Fixed
Fix Version/s: deploymentadmin-0.9.2

This has been fixed a long time ago. In general, the OSGi LogService is used 
now, and logging in the code was improved.

 Log situation in DeploymentAdmin impl very unclear
 --

 Key: FELIX-1307
 URL: https://issues.apache.org/jira/browse/FELIX-1307
 Project: Felix
  Issue Type: Improvement
  Components: Deployment Admin
Reporter: Toni Menzel
Assignee: Marcel Offermans
Priority: Trivial
 Fix For: deploymentadmin-0.9.2


 e.g. StartBundleCommand.java : 
 has this:
 // TODO: m_log.log(LogService.LOG_DEBUG, won't wait for Packages refreshed 
 event, event is already received);
 all over the place.
 And not just this one.
 Question: what is the intend of commenting this out ? What is the plan here ?

--
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] [Closed] (FELIX-1831) Reinstalling of deployment package fails

[Marcel Offermans (JIRA)]

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

Marcel Offermans closed FELIX-1831.
---

Resolution: Cannot Reproduce

Closing this issue. Could not reproduce it some time ago, asked for further 
feedback. None given. Please re-open when more information becomes available.

 Reinstalling of deployment package fails
 

 Key: FELIX-1831
 URL: https://issues.apache.org/jira/browse/FELIX-1831
 Project: Felix
  Issue Type: Bug
  Components: Deployment Admin
 Environment: Windows Vista x64, Apache Felix
Reporter: Pavel Kodl
Priority: Critical

 In DeploymentAdminImpl class should be from line 240 something like this:
 } else {
 // causes unlock deployment package manifest file
 m_packages.remove(source.getName());
 System.gc();  // have to be here
 File targetPackage = m_context.getDataFile(PACKAGE_DIR + 
 File.separator + source.getName());
 targetPackage.mkdirs();
 ExplodingOutputtingInputStream.replace(targetPackage, 
 tempPackage);
 }
 instead of:
 } else {
 File targetPackage = m_context.getDataFile(PACKAGE_DIR + 
 File.separator + source.getName());
 targetPackage.mkdirs();
 ExplodingOutputtingInputStream.replace(targetPackage, 
 tempPackage);
 }
 without this correction it throws:
 org.osgi.service.deploymentadmin.DeploymentException: Could not create 
 installed deployment package from disk
 at 
 org.apache.felix.deploymentadmin.DeploymentAdminImpl.installDeploymentPackage(DeploymentAdminImpl.java:252)
 at 
 org.apache.felix.webconsole.internal.deppack.DepPackServlet.doPost(DepPackServlet.java:94)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
 at 
 org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:296)
 at 
 org.apache.felix.http.base.internal.handler.ServletHandler.doHandle(ServletHandler.java:92)
 at 
 org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:78)
 at 
 org.apache.felix.http.base.internal.dispatch.ServletPipeline.handle(ServletPipeline.java:42)
 at 
 org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:49)
 at 
 org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:33)
 at 
 org.apache.felix.http.base.internal.dispatch.FilterPipeline.dispatch(FilterPipeline.java:48)
 at 
 org.apache.felix.http.base.internal.dispatch.Dispatcher.dispatch(Dispatcher.java:39)
 at 
 org.apache.felix.http.base.internal.DispatcherServlet.service(DispatcherServlet.java:55)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
 at 
 org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
 at 
 org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:390)
 at 
 org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
 at 
 org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
 at 
 org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
 at org.mortbay.jetty.Server.handle(Server.java:326)
 at 
 org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:536)
 at 
 org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:930)
 at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:747)
 at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218)
 at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:405)
 at 
 org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)
 at 
 org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
 Caused by: java.io.FileNotFoundException: 
 .\felix-cache\bundle23\data\packages\test4\index.txt
 at java.io.FileInputStream.open(Native Method)
 at java.io.FileInputStream.init(FileInputStream.java:106)
 at java.io.FileReader.init(FileReader.java:55)
 at 
 org.apache.felix.deploymentadmin.ExplodingOutputtingInputStream.readIndex(ExplodingOutputtingInputStream.java:212)
 at 
 org.apache.felix.deploymentadmin.FileDeploymentPackage.init(FileDeploymentPackage.java:52)
 at 
 org.apache.felix.deploymentadmin.DeploymentAdminImpl.installDeploymentPackage(DeploymentAdminImpl.java:247)
 ... 26 more

--
This message is automatically generated by JIRA.
If you think it was sent

[jira] [Closed] (FELIX-3336) Exceptions related to the pipe used in deployment admin

[Marcel Offermans (JIRA)]

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

Marcel Offermans closed FELIX-3336.
---

   Resolution: Fixed
Fix Version/s: deploymentadmin-0.9.2

This has been fixed.

 Exceptions related to the pipe used in deployment admin
 ---

 Key: FELIX-3336
 URL: https://issues.apache.org/jira/browse/FELIX-3336
 Project: Felix
  Issue Type: Bug
  Components: Deployment Admin
Reporter: Marcel Offermans
Assignee: Marcel Offermans
 Fix For: deploymentadmin-0.9.2


 Sporadically getting Pipe closed exceptions. Not reproducible yet, but 
 seemingly related to a line containing input.close() in the 
 ExplodingOutputtingInputStream. Needs investigation.

--
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-3355) Autoconf can't find Metatype service

[Marcel Offermans (JIRA)]

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

Marcel Offermans updated FELIX-3355:


Fix Version/s: autoconf-rp-0.1.2

Make sure we fix this for the next release.

 Autoconf can't find Metatype service
 

 Key: FELIX-3355
 URL: https://issues.apache.org/jira/browse/FELIX-3355
 Project: Felix
  Issue Type: Bug
  Components: Deployment Admin
Affects Versions: autoconf-rp-0.1.0
Reporter: Bram de Kruijff
 Fix For: autoconf-rp-0.1.2


 Although Autoconf appears to consult MetaTypeService to resolve OCDs in code 
 it never will. This is caused by the fact that the bundle does not import 
 org.osgi.service.metatype, but embeds it. Any actual MetaTypeService will not 
 be assignable.
 The reason it doesn't fail is that the dependencymanager dependency is 
 optional. As a result the AutoconfResourceProcessor operates against an 
 injected NullObject. You never get any warning, but it simply never resolves 
 OCDs. 
 Besides fixing the import IMHO it would not be unreasnable to require 
 MetaTypeService
 {code}
 Index: autoconf/pom.xml
 ===
 --- autoconf/pom.xml(revision 1245822)
 +++ autoconf/pom.xml(working copy)
 @@ -86,7 +86,7 @@
  Bundle-NameApache Felix AutoConf Resource 
 Processor/Bundle-Name
  Bundle-DescriptionA customizer bundle that 
 publishes a Resource Processor service that processes configuration resources 
 shipped in a
  Deployment Package./Bundle-Description
  Bundle-VendorApache Software 
 Foundation/Bundle-Vendor
 -
 Private-Packageorg.apache.felix.deployment.rp.autoconf, 
 org.apache.felix.metatype, org.apache.felix.metatype.internal.l10n, org.apach
 e.felix.metatype.internal, org.kxml2.io;-split-package:=merge-first, 
 org.xmlpull.v1;-split-package:=merge-first, 
 org.osgi.service.metatype;-split-package:=merge
 -first/Private-Package
 +
 Private-Packageorg.apache.felix.deployment.rp.autoconf, 
 org.apache.felix.metatype, org.apache.felix.metatype.internal.l10n, org.apach
 e.felix.metatype.internal, org.kxml2.io;-split-package:=merge-first, 
 org.xmlpull.v1;-split-package:=merge-first/Private-Package
  
 Export-Packageorg.osgi.service.deploymentadmin.spi;version=1.0/Export-Package
  
 DeploymentPackage-Customizertrue/DeploymentPackage-Customizer
  
 Deployment-ProvidesResourceProcessororg.osgi.deployment.rp.autoconf/Deployment-ProvidesResourceProcessor
 {code}

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