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

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on FELIX-5573:
--

My understanding is like David's: I think Bundle.loadClass should not return 
null as this sounds unexpected, although the specification is not entirely 
clear. So I would sort this under the topic "managing expectations".

How about throwing a new "ClassLoadingCircularityDetectedException extends 
ClassNotFoundException" ? This way callers get the "ClassNotFoundException" 
while internally you can differentiate between the cases. Plus logging the 
exception will properly indicate the actual problem: the circularity.

> Detect recursive class loads while invoking weaving hooks
> -
>
> Key: FELIX-5573
> URL: https://issues.apache.org/jira/browse/FELIX-5573
> Project: Felix
>  Issue Type: Bug
>  Components: Framework
>Affects Versions: framework-5.6.2
>Reporter: Karl Pauls
>Assignee: Karl Pauls
> Fix For: framework-5.6.4
>
>
> We need to detect recursive class loads while invoking weaving hooks, if 
> recursion is detected for a class name then we want to simply ignore all 
> weave hooks for the recursive class load and allow it to proceed to define 
> class.



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

Re: [jira] [Commented] (FELIX-5571) Replace JSONParser in Serializer with the new one from utils

[Felix Meschberger]

The problem, really is that scope=compile on the utils bundle is the viral 
thing which cannot be undone by doing scope=provided in the consumer of the 
utils bundle … (unless you explicitly exclude the dependency or do the ordering 
trick)

Regards
Felix

> Am 28.02.2017 um 15:02 schrieb Guillaume Nodet :
> 
> I disagree.  Semantically, utils dependencies are actually at
> scope=compile.   However an osgi bundle should depend on utils with a
> scope=provided because it has to embed the packages it needs, so it makes
> sense to not convey this dependency.
> 
> 2017-02-28 14:49 GMT+01:00 Felix Meschberger :
> 
>> Hi
>> 
>> The problem seems that utils actually declares its own dependencies with
>> scope=compile which pollutes the transitive dependency space.
>> 
>> The fix is for utils to declare the dependencies as scope=provided so that
>> these dependencies are not transitive.
>> 
>> Regards
>> Felix
>> 
>>> Am 28.02.2017 um 11:30 schrieb David Leangen (JIRA) :
>>> 
>>> 
>>>   [ https://issues.apache.org/jira/browse/FELIX-5571?page=
>> com.atlassian.jira.plugin.system.issuetabpanels:comment-
>> tabpanel&focusedCommentId=15887753#comment-15887753 ]
>>> 
>>> David Leangen commented on FELIX-5571:
>>> --
>>> 
>>> It is in the Activator.
>>> 
>>> Actually, I did. I added the depdendency as:
>>> 
>>> {code}
>>>   
>>>   org.apache.felix
>>>   org.apache.felix.utils
>>>   1.9.1-SNAPSHOT
>>>   provided
>>>   
>>> {code}
>>> 
>>> It pulls in the old osgi core transitively, and causes this exception:
>>> 
>>> {code}
>>> [ERROR] Failed to execute goal org.apache.maven.plugins:
>> maven-compiler-plugin:3.2:compile (default-compile) on project
>> org.apache.felix.serializer: Compilation failure: Compilation failure:
>>> [ERROR] /Users/dleangen/libs/felix/converter/serializer/src/main/
>> java/org/apache/felix/serializer/impl/Activator.java:[35,16] no suitable
>> method found for registerService(java.lang.Class> serializer.Serializer>,org.apache.felix.serializer.impl.
>> json.JsonSerializerImpl,java.util.Dictionary> String,java.lang.Object>)
>>> [ERROR] method org.osgi.framework.BundleContext.registerService(
>> java.lang.String[],java.lang.Object,java.util.Dictionary) is not
>> applicable
>>> [ERROR] (argument mismatch; 
>>> java.lang.Class
>> cannot be converted to java.lang.String[])
>>> {code}
>>> 
>>> R6 allows a class as a parameter to BundleContext.registerService(),
>> but R4 does not. I don't think it would be the right call to revert to the
>> older version of this method call.
>>> 
>>>> Replace JSONParser in Serializer with the new one from utils
>>>> 
>>>> 
>>>>   Key: FELIX-5571
>>>>   URL: https://issues.apache.org/jira/browse/FELIX-5571
>>>>   Project: Felix
>>>>Issue Type: Bug
>>>>Components: Converter
>>>>  Reporter: David Leangen
>>>>  Assignee: David Leangen
>>>> 
>>>> I can do this if there are no objections.
>>> 
>>> 
>>> 
>>> --
>>> This message was sent by Atlassian JIRA
>>> (v6.3.15#6346)
>> 
>> 
> 
> 
> -- 
> 
> Guillaume Nodet

Re: [jira] [Commented] (FELIX-5571) Replace JSONParser in Serializer with the new one from utils

[Felix Meschberger]

Hi

The problem seems that utils actually declares its own dependencies with 
scope=compile which pollutes the transitive dependency space.

The fix is for utils to declare the dependencies as scope=provided so that 
these dependencies are not transitive.

Regards
Felix

> Am 28.02.2017 um 11:30 schrieb David Leangen (JIRA) :
> 
> 
>[ 
> https://issues.apache.org/jira/browse/FELIX-5571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15887753#comment-15887753
>  ] 
> 
> David Leangen commented on FELIX-5571:
> --
> 
> It is in the Activator.
> 
> Actually, I did. I added the depdendency as:
> 
> {code}
>
>org.apache.felix
>org.apache.felix.utils
>1.9.1-SNAPSHOT
>provided
>
> {code}
> 
> It pulls in the old osgi core transitively, and causes this exception:
> 
> {code}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-compiler-plugin:3.2:compile (default-compile) 
> on project org.apache.felix.serializer: Compilation failure: Compilation 
> failure:
> [ERROR] 
> /Users/dleangen/libs/felix/converter/serializer/src/main/java/org/apache/felix/serializer/impl/Activator.java:[35,16]
>  no suitable method found for 
> registerService(java.lang.Class,org.apache.felix.serializer.impl.json.JsonSerializerImpl,java.util.Dictionary)
> [ERROR] method 
> org.osgi.framework.BundleContext.registerService(java.lang.String[],java.lang.Object,java.util.Dictionary)
>  is not applicable
> [ERROR] (argument mismatch; 
> java.lang.Class cannot be converted 
> to java.lang.String[])
> {code}
> 
> R6 allows a class as a parameter to BundleContext.registerService(), but R4 
> does not. I don't think it would be the right call to revert to the older 
> version of this method call.
> 
>> Replace JSONParser in Serializer with the new one from utils
>> 
>> 
>>Key: FELIX-5571
>>URL: https://issues.apache.org/jira/browse/FELIX-5571
>>Project: Felix
>> Issue Type: Bug
>> Components: Converter
>>   Reporter: David Leangen
>>   Assignee: David Leangen
>> 
>> I can do this if there are no objections.
> 
> 
> 
> --
> This message was sent by Atlassian JIRA
> (v6.3.15#6346)

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

[Felix Meschberger]

Hi all

Hmm, thinking a bit more about this and looking at the FrameworkFactory class 
which is targeted at launching frameworks in an implementation independent 
manner, I wonder, whether logging being a crucial function in each and every 
application should not get special treatment on a specification level ?

Shouldn’t we try to get the specification extended to define a well known 
property for configuration map handed to the FrameworkFactory.newFramework 
method which names some sort of logger ?

Unfortunately that configuration map is Map so the logger 
itself cannot be provided … but maybe some factory class name or so ?

Regards
Felix

> Am 24.02.2017 um 16:39 schrieb Christian Schneider :
> 
> The problem is that we can not directly depend on the felix framework from 
> karaf as we must be able to switch between equinox and felix.
> So the karaf starter may not have a direct dependency on felix framework.
> 
> So if the log service interface would be in an OSGi spec jar it would be fine.
> 
> Christian
> 
> On 24.02.2017 16:33, Karl Pauls wrote:
>>> I guess it would be nice if the launcher api had a simple logger
>>> interface which you could implement and pass into the framework factory.
>>> Then everyone can implement this in any way they want and this would be
>>> portable across framework implementations.
>> I'm fine with that as well. Basically, just replace the current
>> reflection calls one-to-one with real methods (which will look like
>> the OSGi LogService by-and-large).
>> 
>> So karaf and others would just have to wrap their JUL logger with a
>> simple Felix LogService decorator.
>> 
>> regards,
>> 
>> Karl
>> 
>>> Carsten
>>> --
>>> Carsten Ziegeler
>>> Adobe Research Switzerland
>>> cziege...@apache.org
>> 
>> 
> 
> 
> -- 
> Christian Schneider
> http://www.liquid-reality.de
> 
> Open Source Architect
> http://www.talend.com
> 

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

[Felix Meschberger]

Hi Christian


> Am 24.02.2017 um 15:32 schrieb Christian Schneider :
> 
> Currently felix framework uses reflection to allow other logging frameworks. 
> It is a quite complicated and still pretty limited approach.
> As far as I know this is only used for karaf to hook in. So I propose to only 
> allow to choose jul as it is built in and we can avoid to add dependencies as 
> well as avoid to use reflection.
> 
> https://issues.apache.org/jira/browse/FELIX-5525
> 
> Karl reviewed the change and is generally positive but we would like to get 
> feedback from the community if this is a good idea.

I have already commented on some aspects in the pull request. But now that you 
kick this discussion, let me throw in my 2 cents.

First of all, I understand the „problem“ of providing a Logger instance which 
really binds the caller into the Felix API and thus breaks quite some 
assumptions of the FrameworkFactory launching method.

Now for me the question is, whether JUL really is a good choice for logging or 
not. YMMV but I don’t know many JUL uses. Most of the projects I have contact 
with are using SLF4J API and then mostly logback (or Log4J) implementation. 
Granted, there is quite some logging API variance (JUL, Log4J, SLF4J, Apache 
Commons Logging, probably some more) and deciding on which to use and which 
dependency to actually bind the framework on is a hard choice.

So maybe, in the end, supporting just JUL might be ok, particularly for SLF4J 
there is a wrapper which redirects JUL to SLF4J. So in my use cases, I can just 
deploy the JUL-to-SLF4J wrapper, set the property, and be done.

I wonder, though, whether we should not keep the reflection feature for 
backwards compatibility.

Regards
Felix

Re: [utils] support comments in JSONOParser?

[Felix Meschberger]

Hi

I tend to agree with this …

plus: that project even implements the standard javax.json API…

Regards
Felix


> Am 21.02.2017 um 09:06 schrieb Achim Nierbeck :
> 
> Hi,
> 
> I wouldn't do it, in the end you'll endup re-inventing the wheel a 50th
> time.
> If you think the minimum parser isn't sufficient, it's time to think of
> using another one.
> As I already pointed out previously we do have an apache project for JSON
> stuff.
> At this point if it is really needed and not a simple string parsing and
> done with it.
> Go for a full featured JSON lib, which is already OSGi ready.
> 
> regards, Achim
> 
> 2017-02-21 0:42 GMT+01:00 David Leangen :
> 
>> 
>> Agree that it would be a very nice feature to have.
>> 
>> HOWEVER, this is how the scope creep starts. The original thought was to
>> have a very simple parser.
>> 
>> 
>> What about a separate (possibly even configurable) pre-parser instead?
>> 
>> 
>> Cheers,
>> =David
>> 
>> 
>>> On Feb 21, 2017, at 7:17 AM, Stefan Seifert 
>> wrote:
>>> 
>>> the new json parser added to Felix Utils fails when the JSON files
>> contain comments like /* comment */.
>>> 
>>> i known that the JSON format [1] officially does not support comments at
>> all, but most JSON parsers nowadays seem to support them by just skipping
>> comments when parsing a JSON file. should the felix parser support this as
>> well? perhaps configurable via a strict and non-strict mode?
>>> 
>>> stefan
>>> 
>>> [1] https://tools.ietf.org/html/rfc7159
>>> 
>>> 
>> 
>> 
> 
> 
> -- 
> 
> Apache Member
> Apache Karaf  Committer & PMC
> OPS4J Pax Web  Committer &
> Project Lead
> blog 
> Co-Author of Apache Karaf Cookbook 
> 
> Software Architect / Project Manager / Scrum Master

Re: [jira] [Resolved] (FELIX-5556) JSONParser does not retain object order

[Felix Meschberger]

Hi all

I think this is a very bad idea !

According to RFC 4627 [1]:

> An object is an unordered collection of zero or more name/value
> pairs, where a name is a string and a value is a string, number,
> boolean, null, object, or array.

Parsing the JSON and then storing in a defined order creates expectations which 
are not valid. There is no defined order amongst properties in an object and we 
must not create the impression that there would be and even start having 
applications depending on it.

Therefore I strongly suggest to revert this change and go back to using a 
HashMap.

Regards
Felix

[1] https://www.ietf.org/rfc/rfc4627.txt

> Am 20.02.2017 um 23:08 schrieb Stefan Seifert (JIRA) :
> 
> 
> [ 
> https://issues.apache.org/jira/browse/FELIX-5556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>  ]
> 
> Stefan Seifert resolved FELIX-5556.
> ---
>Resolution: Fixed
> 
> Completed: At revision: 1783803  
> 
> 
>> JSONParser does not retain object order
>> ---
>> 
>>Key: FELIX-5556
>>URL: https://issues.apache.org/jira/browse/FELIX-5556
>>Project: Felix
>> Issue Type: Bug
>> Components: Utils
>>   Affects Versions: utils-1.9.0
>>   Reporter: Stefan Seifert
>>   Assignee: Stefan Seifert
>>Fix For: utils-1.9.2
>> 
>> 
>> the {{JSONParser}} does not retain the order of objects the JSON files it 
>> parses. the order is randomly based on the HashMap implementation used 
>> internally.
> 
> 
> 
> --
> This message was sent by Atlassian JIRA
> (v6.3.15#6346)

Re: [ANN] New Apache Felix Committers: David Leangen and Neil Bartlett

[Felix Meschberger]

Welcome David and Neil !

Regards
Felix

> Am 07.02.2017 um 05:27 schrieb dav...@apache.org:
> 
> Hi all,
> 
> I'm very happy to announce that the Apache Felix project has invited two
> new committers and both have accepted:
> David Leangen and Neil Bartlett.
> 
> Please join me in welcoming David and Neil to the project.
> 
> Best regards,
> 
> David Bosschaert

[jira] [Commented] (FELIX-5507) ConfigurationAdmin not visible to bundles

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on FELIX-5507:
--

I tend to agree with [~djencks] here. IIRC the reason for using the extended 
bundle's context is to make sure the Configuration Admin service applies the 
correct permissions for the consuming bundle ! Using the system bundle 
completely breaks this assumption and I would even go as far as saying this is 
non-compliant behaviour.

It really is important to find the real cause for the problem in this context.

> ConfigurationAdmin not visible to bundles
> -
>
> Key: FELIX-5507
> URL: https://issues.apache.org/jira/browse/FELIX-5507
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-2.0.8
>Reporter: Carsten Ziegeler
> Fix For: scr-2.1.0
>
>
> We have one case where the extended bundles do not see the configuration 
> admin service. Interestingly the same application runs fine everywhere else, 
> but just on a special environment (windows, ibm java inside Websphere) we 
> have this problem reproducibly.
> Using the system bundle context instead of the bundle context of the extended 
> bundle in ConfigAdminTracker solves the problem.
> Interestingly only the bundles started last (2 out of probably 80) see the 
> configuration admin.
> It could also be that a faulty service hook is involved, although I'm not yet 
> aware of such a hook



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

Re: [DISCUSS] [POLICY] IP tracking for OSGi APIs

[Felix Meschberger]

Hi all

I think Guillaume’s idea of defining that provisional,  WIP, interim, temporary 
OSGi API commits be isolated and refer to a concrete OSGi Repository commit 
(URL ideally) makes sense to me. So that we can track back this source.

In any case, OSGi API will always bei OSGi copyrighted and this is not a 
problem at Apache actually. Copyright and License to use are not the same 
thing, complicated in their own right and even more complicated in their 
relation/interaction.

So for this OSGi API we leave the license header and copyright statements as 
they are. They present no problem for us: The AL2 grants us the right to use, 
include, distribute irrespective of the copyright. Actually the copyright gives 
the OSGi Alliance the right to license these use and distribution rights to us.

To settle this down discussion down, I suggest we ammend the Felix „Provisional 
OSGi API Policy“ [1] by a section on how to handle these cases:

  * develop in a branch
  * never release (as in Apache Release) provisional API in the OSGi name space 
(existing)
  * when committing provisional API in the branch, use isolated commit with URL 
reference to original source

For Aries, I suggest to refer to the Apache Felix page.

Lets not create an elephant out of this mouse, please.

Regards
Felix

[1] 
http://felix.apache.org/documentation/development/provisional-osgi-api-policy.html

Am 23.01.2017 um 23:47 schrieb Guillaume Nodet 
mailto:gno...@apache.org>>:

Well maybe it should, but again, I don't think it has always been done
correctly in the past...
Hence this proposal to discuss what options we have to actually correctly
implement it.

2017-01-23 23:30 GMT+01:00 Carsten Ziegeler 
mailto:cziege...@apache.org>>:

As discussed already it's always #2

Carsten

Guillaume Nodet wrote
Right, we discussed that.
My understanding is that we have 2 options:
 * either the API is committed first at Apache, in which case, it can't
really be copyrighted to the OSGi Alliance
 * or it's copyrighted to the OSGi Alliance and it has to pre-exist the
commit in our svn source tree

If we choose #1, that's easy, we just have to remove the copyright on the
APIs headers.

If we go for #2, for specs that have been released, that's not a problem,
they usually come from the released spec jar (and they usually are not
even
included in the source tree).  For spec / rfcs under development, the
only
thing needed is to commit the api first in an osgi repository.
For example:
  https://github.com/osgi/design/tree/master/rfcs/rfc-/api
and then commit the same code referencing the commit in the above
directory.
If the above is not practical, it can be any github repo actually, even
you
own repo.  From the moment is has been committed by you somewhere outside
the ASF, the copyright can be granted to the OSGi in a clear way, so that
if the github code / commit is referenced from out svn commit, we can
track
the IP correctly.  I think an OSGi repository such as the one above would
be better.

The only thing is to avoid committing an API directly to the ASF and
pretending it's copyrighted by the OSGi Alliance, because source
committed
to the ASF is by default supposed to be given a non-exclusive copyright
license grant coming from the ICLA/CCLA.

So I'm not sure what's wrong with the above, nor how that's practically
impossible, not that it would prohibit any kind of development.


2017-01-23 22:28 GMT+01:00 Carsten Ziegeler 
mailto:cziege...@apache.org>>:

Well, we discussed this in length last week, and as a matter of fact the
OSGi API which is under development is not available publically. So how
can we define a policy that is practically impossible?


This goes back to what I said several times last week, we can only
change our side (Apache) but we can't change the OSGi Alliance side.

I think having a separate commit for the API and mentioning some
reference like the commit id or similar is a good idea. However, only
developers working for a member company of the OSGi Alliance can verify
this. But in practice, we have a lot of committers here being able to do
so, including Guillaume.

Carsten

Guillaume Nodet wrote
As discussed on legal@ (see [1]), and in order to be able to track
code
IP
correctly, I propose that all commits that includes API code from the
OSGi
Alliance are done in separate commit and include a reference to the
public
source where the code comes from.

Thoughts ?
Guillaume

[1]
http://mail-archives.apache.org/mod_mbox/www-legal-
discuss/201701.mbox/%
3ccaa66tppc9lp71ak4uoxsnz8qzg+bnutyntzspbt+z48dynu...@mail.gmail.com%3e





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








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




--

Guillaume Nodet

Re: Implementation of unreleased spec and community

[Felix Meschberger]

Hi all

And we should also mention that quite a number of active community members 
actually working on those things are members (or employees of members) of the 
OSGi alliance and as such open to feedback received from the communities on the 
evolution of the specifications.

As such, I think it is even positive for both the communities and the OSGi 
alliance to have Apache projects implement reference implementations.

Maybe we could do a better job in communicating that fact ?

Regards
Felix

> Am 18.01.2017 um 11:59 schrieb David Bosschaert :
> 
> Hi Guillaume,
> 
> First of all, the OSGi Alliance is a very open standards development
> organization. Any organisation can join. RFPs and RFCs are developed in the
> open, specs are available for free and are free to be implemented by anyone.
> 
> There is also an open feedback channel available where everyone can post
> feedback, described at https://github.com/osgi/design
> 
> OSGi works very hard in defining specs that are portable and can be
> implemented without the need to pay for any licenses or anything of that
> sort.
> 
> History has shown that spec implementations are really quite portable.
> Implementation bundles can be mixed from different sources and everything
> just works as long as you use the specced APIs.
> 
> Every new spec that is being worked on in OSGi needs, besides the RFP/RFC
> and spec chapter, a Reference Implementation and a Conformance Testsuite.
> Over the past 10 years or so, Reference Implementations have primarily been
> implemented in open source. This has the benefit that everyone can see what
> the implementation is going to be and also it allows everyone to provide
> feedback and participate in the implementation. Apache committers have free
> access to the relevant CTs as well.
> 
> I think this is all goodness. Or would you rather see that Reference
> Implementations are implemented in private?
> 
> Best regards,
> 
> David
> 
> 
> On 18 January 2017 at 10:41, Guillaume Nodet  wrote:
> 
>> I'm a bit concerned by some subprojects in our communities.
>> 
>> The ASF is supposed to be "community over code", so the very basic thing
>> for a project is that people can get involved.
>> 
>> However, I see more and more code developped as a reference implementation
>> of a spec which is not publicly available, because it's still being
>> developed at the OSGi Alliance.  I find that very disturbing because
>> there's no way the community can get involved unless they are OSGi Alliance
>> members, and that's clearly not acceptable imho.
>> 
>> Thoughts ?
>> Guillaume Nodet
>> 

Re: What branch to do OSGi R-next work in.

[Felix Meschberger]

Hi


> Am 05.01.2017 um 17:06 schrieb Carsten Ziegeler :
> 
> Felix Meschberger wrote
>> Hmm, this sounds confusing somehow…
>> 
>> why not have:
>> 
>>   felix/trunk/configadmin — releasable R6 based Config Admin
>>   felix/trunk/scr — releasable R6 based DS
>>   felix/branches/osgi-r7/configadmin — un-releasable R7 work on Config Admin
>>   felix/branches/osgi-r7/scr — un-releasable R7 work on DS
>> 
>> … and this can be continued for other projects where we work on for R7 
>> implementations such as the Configurator etc.
>> 
>> Drawback is, that this is somehow „hidden“ in a different, yet SVN custom, 
>> branch tree.
>> 
> Exactly, I started in such a branch but moved it to trunk for more
> visibility. People complained that the work was not visible.
> Not easy to make it right for everyone…

Oh yeah ;-)

In Git there would be a proper Git branch… which is why I came up with the 
felix/branches proposal which is a standard SVN branch. (*)

> 
> What about renaming scr to scr-r7-branch and scr-2.0.x to scr and the
> same for config admin but leaving them in trunk?
> Or creating and osgi-r7 directory in trunk and move the stuff there?

I like the folder, because it then properly delineates all the OSGI R7 work.

> And we should not forget that this is only a temporary problem, roughly
> from about now until the release. So maybe something like 9 months…

Temporary but recurring — thinking of R8, R9, …

Regards
Felix

(*) Ok there is no such thing as a real branch in SVN, just lazy tree copies 
and some conventions around trunk, tags, and branches folders.

Re: What branch to do OSGi R-next work in.

[Felix Meschberger]

Hmm, this sounds confusing somehow…

why not have:

   felix/trunk/configadmin — releasable R6 based Config Admin
   felix/trunk/scr — releasable R6 based DS
   felix/branches/osgi-r7/configadmin — un-releasable R7 work on Config Admin
   felix/branches/osgi-r7/scr — un-releasable R7 work on DS

… and this can be continued for other projects where we work on for R7 
implementations such as the Configurator etc.

Drawback is, that this is somehow „hidden“ in a different, yet SVN custom, 
branch tree.

Regards
Felix

> Am 05.01.2017 um 16:16 schrieb Carsten Ziegeler :
> 
> In trunk we have now
> configadmin-1.8.x (R6)
> configadmin   (R7)
> scr-2.0.x (R6)
> scr   (R7)
> 
> So we can release config admin at any time from the 1.8.x directory and
> scr from the scr-2.0.x.
> 
> I'm fine with adding a readme, however as we have the voting period we
> will catch such a release anyway before it will become public.
> 
> Carsten
> 
> Thomas Watson wrote
>> What branch is that for config admin?  Can you point me to it?  Is this a
>> branch to do releases out of while trunk is in a state that cannot be
>> released?
>> 
>> I don't mind this process, but I think it should be made clear in trunk
>> that the ongoing work there cannot be released.  Perhaps with a readme file
>> or something in the project that points to the branch where releases can be
>> done from?
>> 
>> Tom
>> 
>> On Wed, Jan 4, 2017 at 11:52 PM, Carsten Ziegeler 
>> wrote:
>> 
>>> I assume you're talking about DS, right?
>>> 
>>> I'll create a branch similar to what we did for config admin
>>> 
>>> Carsten
>>> 
>>> Thomas Watson wrote
>>>> Changed subject to stop hijacking the discussion on releasing provisional
>>>> API from the org.osgi namespace.
>>>> 
>>>> How do we come to an agreement on what branch to do OSGi R-next work
>>> in?  I
>>>> would prefer to keep trunk in a releasable state based on the latest
>>>> published specification from OSGi.  But we have more and more R7 work now
>>>> going on directly in trunk.  Is it past the point of no return?
>>>> 
>>>> Tom.
>>>> 
>>>> 
>>>> On Wed, Jan 4, 2017 at 8:33 AM, Felix Meschberger 
>>>> wrote:
>>>> 
>>>>> Hi
>>>>> 
>>>>> As of now, we don’t have an official branch policy. In fact we had a
>>>>> discussion before and we decided against such.
>>>>> 
>>>>> So I would think that we should continue releasing from trunk and from
>>>>> trunk only.
>>>>> 
>>>>> As such I like Tom’s proposal for a R-Next working branch. And since
>>> OSGi
>>>>> generally releases yearly with just consecutive spec version numbers we
>>>>> could just create a single branches/osgi-r-7 (or 8 or 9 or …) branch
>>> where
>>>>> we have branch copies of the specs we implement.
>>>>> 
>>>>> This is orthogonal, though, to the question of whether we should be
>>>>> „releasing“ provisional API in the org.osgi namespace.
>>>>> 
>>>>> Regards
>>>>> Felix
>>>>> 
>>>>>> Am 04.01.2017 um 15:23 schrieb Thomas Watson :
>>>>>> 
>>>>>> My preference would be to do new osgi R-Next work in a dedicated
>>> feature
>>>>>> branch instead of directly in trunk.  That way trunk remains releasable
>>>>> at
>>>>>> all times.  But if we want to instead branch each project when its
>>> trunk
>>>>>> version becomes unreleasable then I guess that is fine, but it does
>>> seem
>>>>>> confusing.
>>>>>> 
>>>>>> If that is what felix dev has agreed to then I do request a branch for
>>>>> scr
>>>>>> to release some fixes for the R6 scr implementation.  I'm have a few
>>>>> fixes
>>>>>> that I need to get released very soon in order to allow the felix scr
>>>>>> implementation to be used as the DS implementation in Eclipse.
>>>>>> 
>>>>>> Tom
>>>>>> 
>>>>>> On Wed, Jan 4, 2017 at 1:56 AM, Carsten Ziegeler >>> 
>>>>>> wrote:
>>>>>> 
>>>>>>> Thomas Watson wrote
>>>>>>>> This has come to my attention because

Re: [ANN] New Apache Felix Committer: Stefan Seifert

[Felix Meschberger]

Congratulations and welcome, Stefan !

Keep the good stuff coming.

Regards
Felix

> Am 23.12.2016 um 11:47 schrieb Stefan Seifert :
> 
> thanks!
> 
> it is a tradition that a new committer introduces himself, so here are some 
> words about myself:
> 
> i'm living in berlin, and using OSGi and Felix for about 7 years. i'm also 
> heavily involved in the Apache Sling community where i'm committer since 
> 2014. but my first relevant contribution to an Apache project was to Apache 
> Felix in 2009 (FELIX-1010). i'm also involved in organizing the yearly 
> adaptTo() conference in berlin, which focuses on Apache Sling, Felix and 
> Jackrabbit.
> 
> within Felix my main areas of interest in the past was the tooling part like 
> Maven Bundle Plugin, SCR, Web Console.
> 
> stefan
> 
> 
>> -Original Message-
>> From: Carsten Ziegeler [mailto:cziege...@apache.org]
>> Sent: Friday, December 23, 2016 11:28 AM
>> To: dev@felix.apache.org
>> Subject: [ANN] New Apache Felix Committer: Stefan Seifert
>> 
>> Hi
>> 
>> it's my pleasure to announce that the Apache Felix PMC has invited
>> Stefan Seifert as a new Felix committer...and gladly Stefan accepted.
>> 
>> So please join me in welcoming Stefan.
>> 
>> Regards
>> Carsten
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziege...@apache.org
> 

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

[Felix Meschberger]

Hi

As of now, we don’t have an official branch policy. In fact we had a discussion 
before and we decided against such.

So I would think that we should continue releasing from trunk and from trunk 
only.

As such I like Tom’s proposal for a R-Next working branch. And since OSGi 
generally releases yearly with just consecutive spec version numbers we could 
just create a single branches/osgi-r-7 (or 8 or 9 or …) branch where we have 
branch copies of the specs we implement.

This is orthogonal, though, to the question of whether we should be „releasing“ 
provisional API in the org.osgi namespace.

Regards
Felix

> Am 04.01.2017 um 15:23 schrieb Thomas Watson :
> 
> My preference would be to do new osgi R-Next work in a dedicated feature
> branch instead of directly in trunk.  That way trunk remains releasable at
> all times.  But if we want to instead branch each project when its trunk
> version becomes unreleasable then I guess that is fine, but it does seem
> confusing.
> 
> If that is what felix dev has agreed to then I do request a branch for scr
> to release some fixes for the R6 scr implementation.  I'm have a few fixes
> that I need to get released very soon in order to allow the felix scr
> implementation to be used as the DS implementation in Eclipse.
> 
> Tom
> 
> On Wed, Jan 4, 2017 at 1:56 AM, Carsten Ziegeler 
> wrote:
> 
>> Thomas Watson wrote
>>> This has come to my attention because I am working on some fixes in the
>> SCR
>>> implementation.  I noticed the latest SCR in trunk now depends on
>>> org.apache.felix.configadmin 1.9.0-SNAPSHOT.  And I think
>>> org.apache.felix.configadmin 1.9.0 is being used to implement OSGi R7.
>> So
>>> now we have OSGi R7 API updates in trunk for existing OSGi packages.  If
>> I
>>> understand correctly that means trunk is no longer in a state where we
>> can
>>> release SCR or configadmin out of.  Instead we have to create a branch to
>>> get new releases of these bundles until a time when OSGi R7 is finalized
>>> and released.  That seems like a bad state to be in.
>>> 
>> 
>> We already have the branch for config admin and if we think that we need
>> another R6 based release of SCR we can create the branch on demand like
>> we did with config admin.
>> I started with these two projects in a branch and at one point we have
>> to merge the branch into trunk. I thought that now is the time as I
>> didn't expect another release before R7 will be out. Might be wrong...
>> In any case, creating that branch is easy. Just shout and it will be done.
>> 
>> Carsten
>> 
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziege...@apache.org
>> 

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

[Felix Meschberger]

Hi

Upfront I like the amended proposal of using a version < 1 and a mandatory 
attribute „provisional“ with value „felix“. As Neil said, BND will solve this 
for imports be it the bndtools or the maven bundle plugin.

Not declaring a version and thus using 0.0.0 will have BND generate a 
version-less import, which essentially means „any version“, which really is 
bad. All exports always should have an export version.

Now, to Richard’s point: I think this is very valid and we better take good 
care here. If we include OSGi API in our releases it is a re-release of AL2 
licensed bits. Key is re-release. If we release provisional OSGi API in the 
OSGi name space which has not been released by OSGi yet, we are essentially 
first-party releasing it.

So before we go this route, I would like to have the OSGi Alliance make a 
statement on this topic. In fact, it would make sense for the alliance to make 
an official statement not only to the benefit of the Felix project but to the 
benefit of all OSGi-related projects at Apache and elsewhere.

WDYT ?

Regards
Felix


> Am 03.01.2017 um 10:46 schrieb David Bosschaert :
> 
> Hi Richard,
> 
> On 23 December 2016 at 19:19, Richard S. Hall  wrote:
> 
>> I'm not for changing the policy. The whole point behind the policy is that
>> anything that we released is in some way blessed and lives forever. If we
>> release packages in the OSGi namespace, they look official even potentially
>> after the OSGi Alliance dumps an RFC (ala Gogo). There is no way for us to
>> retract a release.
>> 
> 
> There will be org.osgi.something API but it will be with a version < 1,
> like 0.1 or something like that. Additionally it will have the mandatory
> attribute on it as discussed above something like provisional="felix". The
> fact that the version is less than one means that it will never clash with
> OSGi released API. These two factors mean that nobody will accidentally use
> this API. The users will have to put the mandatory attribute on the import
> in order to use it.
> 
> 
>> 
>> So, yes, it makes the process a little bit of a pain, but that was sort of
>> the point, so we could make the status clear. Besides, using a temporary
>> package name until a spec if final and then doing a global search/replace
>> when it goes final isn't really that painful.
>> 
>> 
> I think that experience over the years tells us that the temporary package
> name basically means that nobody uses it. I think that others on this
> thread have echoed that the temporary package name doesn't work for them.
> 
> As you say the process is a bit of a pain and my point is that this stands
> in the way of adoption and feedback of new APIs. With this modification to
> the policy adoption and feedback becomes easier and less painful while we
> still retain the barriers that require people to consciously decide to use
> the provisional API...
> 
> Cheers,
> 
> David

Re: [jira] [Created] (FELIX-5459) Use Java 6 as minimum version

[Felix Meschberger]

Hi Ferrie

I heard that before in other places, but I am bit concerned with this stance, 
because: AFAICT Debian Jessie based on OpenJDK 7 and this basically is not 
really supported, is it ? All work seems to go toward OpenJDK 8/Java 8 and now 
Java 9.

So,I think it is unfortunate that OpenJDK 8 is only available through the 
Jessie back ports. But still, I think this should not prevent users from using 
it.

But that is your take, for sure. Just some other light on this strange Debian 
situation.

Regards
Felix

> Am 22.12.2016 um 09:01 schrieb Ferry Huberts :
> 
> From the sidelines:
> 
> Going to 8 would not be good for the products I work on.
> These are based on Debian Jessie, which has 7.
> We _can_ get 8 though backports but are a bit hesitant to do that.
> 
> I guess all products based on 'older' distros would suffer when going to 8.
> 
> My 2 cents.
> 
> Ferry
> 
> On 22/12/16 08:50, Felix Meschberger wrote:
>> I wonder, whether not go directly to Java 7 (or even 8) ? IIRC we stayed at 
>> 1.4 for a long time as Java 1.4 was the latest version available on 
>> mobile/embedded platforms for a long time. Now the latest versions for these 
>> is Java 8, so I think we might not restrict ourselves to Java 6 any longer.
>> 
>> WDYT ?
>> 
>> Regards
>> Felix
>> 
>>> Am 21.12.2016 um 16:46 schrieb Carsten Ziegeler (JIRA) :
>>> 
>>> Carsten Ziegeler created FELIX-5459:
>>> ---
>>> 
>>>Summary: Use Java 6 as minimum version
>>>Key: FELIX-5459
>>>URL: https://issues.apache.org/jira/browse/FELIX-5459
>>>Project: Felix
>>> Issue Type: Improvement
>>> Components: Declarative Services (SCR)
>>>   Reporter: Carsten Ziegeler
>>>   Assignee: Carsten Ziegeler
>>>Fix For: scr-2.1.0
>>> 
>>> 
>>> Currently we have Java 5 as the min version, considering that R7 of the 
>>> OSGi spec is at least targetting Java 7 or even Java 8, this looks really 
>>> out of date.
>>> I suggest we move to Java 6 for now
>>> 
>>> 
>>> 
>>> --
>>> This message was sent by Atlassian JIRA
>>> (v6.3.4#6332)
>> 
> 
> -- 
> Ferry Huberts

Re: [jira] [Created] (FELIX-5459) Use Java 6 as minimum version

[Felix Meschberger]

I wonder, whether not go directly to Java 7 (or even 8) ? IIRC we stayed at 1.4 
for a long time as Java 1.4 was the latest version available on mobile/embedded 
platforms for a long time. Now the latest versions for these is Java 8, so I 
think we might not restrict ourselves to Java 6 any longer.

WDYT ?

Regards
Felix

> Am 21.12.2016 um 16:46 schrieb Carsten Ziegeler (JIRA) :
> 
> Carsten Ziegeler created FELIX-5459:
> ---
> 
> Summary: Use Java 6 as minimum version
> Key: FELIX-5459
> URL: https://issues.apache.org/jira/browse/FELIX-5459
> Project: Felix
>  Issue Type: Improvement
>  Components: Declarative Services (SCR)
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: scr-2.1.0
> 
> 
> Currently we have Java 5 as the min version, considering that R7 of the OSGi 
> spec is at least targetting Java 7 or even Java 8, this looks really out of 
> date.
> I suggest we move to Java 6 for now
> 
> 
> 
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)

Re: Maven repo for Felix Converter

[Felix Meschberger]

Hi

Apache runs a SNAPSHOT repository which is public. But reliance on SNAPSHOTs 
deployed there is brittle.

I just tried to deply a SNAPSHOT build but I get test failures, so I am a bit 
unsure, whether that makes a lot of sense.

Regards
Felix

> Am 20.12.2016 um 14:57 schrieb David Leangen :
> 
> 
> Oh, sorry, I re-read your message.
> 
> Don’t know where there is a public Maven repo, or even if there is one at 
> all. David B would know for sure.
> 
> Cheers,
> =David
> 
> 
>> On Dec 20, 2016, at 10:56 PM, David Leangen  wrote:
>> 
>> 
>> Hi Neil,
>> 
>> It is here:
>> 
>> https://github.com/apache/felix/tree/trunk/converter/converter 
>> 
>> 
>> 
>> Cheers,
>> =David
>> 
>> 
>>> On Dec 20, 2016, at 10:45 PM, Neil Bartlett  wrote:
>>> 
>>> Hello,
>>> 
>>> I’m interested in using the Felix Converter library 
>>> (org.apache.felix.converter) in a Maven project. It doesn’t matter at this 
>>> stage that it’s only a SNAPSHOT. Is there a Maven repository from which 
>>> this dependency can be found? I have been unable to find it in the Nexus on 
>>> https://repository.apache.org .
>>> 
>>> Many thanks
>>> Neil
>> 
> 

Re: Felix HTTP Jetty: enabling request logging

[Felix Meschberger]

Hi Neil

Yes, the Jetty server is setup programmatically and is a private field to the 
implementation. And there is no hook to add such an NCSARequestLog instance.

Having said that, I would think the community would be open to a decent patch 
;-)

Regards
Felix

> Am 19.12.2016 um 18:41 schrieb Neil Bartlett :
> 
> Hi,
> 
> I’m trying to figure out how to enable access/request logging in the Felix 
> HTTP Jetty implementation. I’m looking at org.apache.felix.http.jetty 
> version, which (according to its manifest) embeds Jetty version 
> 9.3.12.v20160915.
> 
> The base Jetty documentation 
> (https://www.eclipse.org/jetty/documentation/current/configuring-jetty-request-logs.html
>  
> )
>  talks about creating an instance of NCSARequestLog and providing it to the 
> Server object with setRequestLog(). Unfortunately, looking at the code, it 
> seems like there is no way to do this in the Felix wrapper around Jetty. I’m 
> looking at SVN trunk revision 1773432. Could one of the developers confirm 
> this assessment?
> 
> Many thanks,
> Neil

[jira] [Commented] (FELIX-5446) Http Service ignores Whiteboard Servlet API Listeners

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on FELIX-5446:
--

I have looked again, and it looks like the Http Service Web Console plugin 
indeed *lists* the listener for the servlet context "'org.osgi.service.http" 
where the HttpService registered services are listed. But the listener is not 
called.

> Http Service ignores Whiteboard Servlet API Listeners
> -
>
> Key: FELIX-5446
> URL: https://issues.apache.org/jira/browse/FELIX-5446
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Affects Versions: http.base-3.0.16, http.jetty-3.4.0
>Reporter: Felix Meschberger
>Assignee: Carsten Ziegeler
> Fix For: http.base-3.0.18, http.jetty-3.4.2
>
>
> Situation:
> # A ServletRequestListener registered with the Http Whiteboard Service 
> (standard OSGi Http Whiteboard) with property 
> {{osgi.http.whiteboard.listener==true}}.
> # A Servlet registered with the traditional OSGi HttpService
> Problem: The ServletRequestListener is not called for requests for requests 
> to said servlet.
> Investigation: It looks like the ServletRequestListenerManager used to handle 
> ServletRequestListener services for traditionally registered Servlets 
> explicitly ignores listeners registered with the 
> {{osgi.http.whiteboard.listener}} property set. See this code in 
> [ServletRequestListenerManager|https://github.com/apache/felix/blob/trunk/http/base/src/main/java/org/apache/felix/http/base/internal/service/listener/ServletRequestListenerManager.java#L45].
> For one thing, the listener should at best ignore services registered with 
> the property set to true. If the property is set to anything else, it will 
> explicitly be ignored by the OSGi Whiteboard Http Service and thus should 
> probably be accepted by the legacy Felix Http Service implementation.
> On the other hand: Why ignore at all ? Originally the legacy Felix Http 
> Service accepted all Servlet API listeners regardless of such property set. 
> So if there is a listener used and the Jetty bundle is updated and the 
> service updated to make sure it is called for new OSGi Whiteboard services it 
> will not be called any more for the legacy registered services
> I think the legacy Felix Http Service should just accept all listeners like 
> it always did.



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

[jira] [Created] (FELIX-5446) Http Service ignores Whiteboard Servlet API Listeners

[Felix Meschberger (JIRA)]

Felix Meschberger created FELIX-5446:


 Summary: Http Service ignores Whiteboard Servlet API Listeners
 Key: FELIX-5446
 URL: https://issues.apache.org/jira/browse/FELIX-5446
 Project: Felix
  Issue Type: Bug
  Components: HTTP Service
Affects Versions: http.jetty-3.4.0
Reporter: Felix Meschberger


Situation:

# A ServletRequestListener registered with the Http Whiteboard Service 
(standard OSGi Http Whiteboard) with property 
{{osgi.http.whiteboard.listener==true}}.
# A Servlet registered with the traditional OSGi HttpService

Problem: The ServletRequestListener is not called for requests for requests to 
said servlet.

Investigation: It looks like the ServletRequestListenerManager used to handle 
ServletRequestListener services for traditionally registered Servlets 
explicitly ignores listeners registered with the 
{{osgi.http.whiteboard.listener}} property set. See this code in 
[ServletRequestListenerManager|https://github.com/apache/felix/blob/trunk/http/base/src/main/java/org/apache/felix/http/base/internal/service/listener/ServletRequestListenerManager.java#L45].

For one thing, the listener should at best ignore services registered with the 
property set to true. If the property is set to anything else, it will 
explicitly be ignored by the OSGi Whiteboard Http Service and thus should 
probably be accepted by the legacy Felix Http Service implementation.

On the other hand: Why ignore at all ? Originally the legacy Felix Http Service 
accepted all Servlet API listeners regardless of such property set. So if there 
is a listener used and the Jetty bundle is updated and the service updated to 
make sure it is called for new OSGi Whiteboard services it will not be called 
any more for the legacy registered services

I think the legacy Felix Http Service should just accept all listeners like it 
always did.



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

[jira] [Commented] (FELIX-5443) Frequent Changes cause UpdateThread to ConcurrentModificationException

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on FELIX-5443:
--

Good catch. Current uses do not seem to trigger this much concurrency in this 
context ...

How about replacing the internal set with an immutable variant:

{code}
Index: Factory.java
===
--- Factory.java(Revision 1773058)
+++ Factory.java(Arbeitskopie)
@@ -20,6 +20,7 @@
 
 
 import java.io.IOException;
+import java.util.Collections;
 import java.util.Dictionary;
 import java.util.HashSet;
 import java.util.Hashtable;
@@ -41,7 +42,7 @@
 public static final String FACTORY_PID_LIST = "factory.pidList";
 
 // the set of configuration PIDs belonging to this factory
-private final Set pids = new HashSet();;
+private Set pids;
 
 
 static boolean exists( PersistenceManager persistenceManager, String 
factoryPid )
@@ -67,6 +68,7 @@
 Factory( ConfigurationManager configurationManager, PersistenceManager 
persistenceManager, String factoryPid )
 {
 super( configurationManager, persistenceManager, factoryPid );
+this.pids = Collections.unmodifiableSet( Collections.emptySet() );
 }
 
 
@@ -77,6 +79,7 @@
 
 // set pids
 String[] pidList = ( String[] ) props.get( FACTORY_PID_LIST );
+HashSet pids = new HashSet();
 if ( pidList != null )
 {
 for ( int i = 0; i < pidList.length; i++ )
@@ -84,6 +87,7 @@
 pids.add( pidList[i] );
 }
 }
+this.pids = Collections.unmodifiableSet( pids );
 }
 
 
@@ -101,19 +105,25 @@
 
 Set getPIDs()
 {
-return new HashSet( pids );
+return this.pids;
 }
 
 
 boolean addPID( String pid )
 {
-return pids.add( pid );
+HashSet pids = new HashSet();
+boolean added = pids.add( pid );
+this.pids = Collections.unmodifiableSet( pids );
+return added;
 }
 
 
 boolean removePID( String pid )
 {
-return pids.remove( pid );
+HashSet pids = new HashSet();
+boolean removed = pids.remove( pid );
+this.pids = Collections.unmodifiableSet( pids );
+return removed;
 }
 
 
@@ -120,6 +130,7 @@
 void store() throws IOException
 {
 Hashtable props = new Hashtable();
+Set pids = this.pids;
 
 if ( !pids.isEmpty() )
 {
{code}

This allows us to optimize the {{getPids()}} method which is presumably called 
more often than {{addPid}} and {{removePid}} which become more expensive.

> Frequent Changes cause UpdateThread to ConcurrentModificationException
> --
>
> Key: FELIX-5443
> URL: https://issues.apache.org/jira/browse/FELIX-5443
> Project: Felix
>  Issue Type: Bug
>  Components: Configuration Admin
>Affects Versions: configadmin-1.8.8
>Reporter: Fabian Lange
>
> 2016-11-30T10:20:15.614+ | ERROR | 836-1bc8-4066-963b-9b9cbccbd9d0) | 
> configadmin | org.apache.felix.configadmin - 1.8.8 | Unexpected problem 
> executing task java.util.ConcurrentModificationException at 
> java.util.HashMap$HashIterator.nextNode(HashMap.java:1437)[:1.8.0_101] at 
> java.util.HashMap$KeyIterator.next(HashMap.java:1461)[:1.8.0_101] at 
> java.util.AbstractCollection.toArray(AbstractCollection.java:196)[:1.8.0_101] 
> at 
> org.apache.felix.cm.impl.Factory.store(Factory.java:126)[4:org.apache.felix.configadmin:1.8.8]
>  at 
> org.apache.felix.cm.impl.ConfigurationManager$DeleteConfiguration.run(ConfigurationManager.java:1851)[4:org.apache.felix.configadmin:1.8.8]
>  at 
> org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:143)[4:org.apache.felix.configadmin:1.8.8]
>  at 
> org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:110)[4:org.apache.felix.configadmin:1.8.8]
>  at java.lang.Thread.run(Thread.java:745)[:1.8.0_101]



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

Re: persistently disable a component

[Felix Meschberger]

Hi

True, but then the SCR Runtime introspection API allows to access all 
components. And so Ray’s idea is potentially possible:

* define the components to be disabled by default
* have the controller be configured by configuration
* introspect the components and enable according to configuratin

Regards
Felix

> Am 13.11.2016 um 12:29 schrieb Pierre De Rop :
> 
> Hi Ray,
> 
> As far as I remember, the ComponentContext.enableComponent(String name)
> method only works for components within the same bundle of the
> ComponentContext. So, if you write a global manager, it will only be able
> to enable the components from its own bundle (if I'm correct).
> 
> BR
> /Pierre
> 
> On Sun, Nov 13, 2016 at 2:39 AM, Raymond Auge 
> wrote:
> 
>> Actually using David's example, couldn't I make a global bundle that speaks
>> SCR runtime and through configuration of its own disable any component?
>> 
>> - Ray
>> 
>> On Nov 11, 2016 23:28, "Felix Meschberger"  wrote:
>> 
>>> Hi Ray
>>> 
>>> Indirectly: have your component require configuration. In this case the
>>> component is only activated if there is configuration for it. This is
>>> similar to a mandatory reference.
>>> 
>>> Regards
>>> Felix
>>> 
>>> --
>>> Typos caused by my iPhone
>>> 
>>>> Am 11.11.2016 um 20:42 schrieb Raymond Auge >> :
>>>> 
>>>> Hey all,
>>>> 
>>>> is there a way in SCR to persistently disable a component, for instance
>>> via
>>>> config admin?
>>>> 
>>>> --
>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>>> (@rotty3000)
>>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>>>> (@Liferay)
>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
>>> (@OSGiAlliance)
>>> 
>> 

Re: persistently disable a component

[Felix Meschberger]

Hi Ray

Indirectly: have your component require configuration. In this case the 
component is only activated if there is configuration for it. This is similar 
to a mandatory reference.

Regards
Felix

--
Typos caused by my iPhone

> Am 11.11.2016 um 20:42 schrieb Raymond Auge :
> 
> Hey all,
> 
> is there a way in SCR to persistently disable a component, for instance via
> config admin?
> 
> -- 
> *Raymond Augé* 
> (@rotty3000)
> Senior Software Architect *Liferay, Inc.* 
> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)

[jira] [Commented] (FELIX-5394) Memoryusage plugin creates a heap dump on every notification

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on FELIX-5394:
--

On rethought and some discussions, it might probably be worth while extending 
the memory plugin as follows:

* Allow to set thresholds for each of the events separately, where zero means 
the plugin should *not* change any current threshold
* Allow to configure whether to dump heap on either or both of the events or to 
not dump at all

Possible UI:

{code}
+---+---+---+
| Mem Threshold |  | ☐ dump heap ? |
+---+---+---+
| Snapshot Th.  |  | ☐ dump heap ? |
+---+---+---+
{code}

In addition dumping heap should be limited more flexibly:

* dump only if last dump is more than some amount of time in the past (as today)
* dump if nth event within an amount of time (e.g. dump if 3rd event within an 
hour)

> Memoryusage plugin creates a heap dump on every notification
> 
>
> Key: FELIX-5394
> URL: https://issues.apache.org/jira/browse/FELIX-5394
> Project: Felix
>  Issue Type: Bug
>  Components: Web Console
>Affects Versions: webconsole-memoryusage-plugin-1.0.6
>Reporter: Alex Parvulescu
>  Labels: patch-available
> Attachments: FELIX-5394-v0.patch
>
>
> As a part of OAK-4966 I'm trying to install a listener on available memory 
> with a notification when a certain available memory threshold is met [0]. 
> This seems to clash a bit with the current {{memoryusage}} plugin, as both 
> jmx listeners try to change the threshold for the notification, and 
> subsequently both might receive the notification at a different value than 
> expected. (for example I'm setting a notification at {{15%}} and even though 
> the {{memoryusage}} plugin is not used and is currently set at {{0%}} it will 
> still create a heap dump:
> {noformat}
> *WARN* [Service Thread] org.apache.felix.webconsole.plugins.memoryusage 
> Received Memory Threshold Exceeded Notification, dumping Heap
> {noformat}
> I have 2 suggestions:
> * first is to _not_ change the threshold value if it's already set at a 
> smaller value. this means the plugin will not break other listeners 
> expectations of receiving an event
>  
> * second is to verify the locally set threshold value against the values seen 
> at notification time. this effectively means the plugin is free to ignore 
> certain events, and not dump the heap to disk every time it gets a ping [1].
> I would like to provide a patch for this issue pretty soon as I really need 
> to fix OAK-4966, unless someone is more eager to come up with a working 
> solution.
> [0] 
> https://issues.apache.org/jira/browse/OAK-4966?focusedCommentId=15629253&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15629253
> [1] 
> https://github.com/apache/felix/blob/trunk/webconsole-plugins/memoryusage/src/main/java/org/apache/felix/webconsole/plugins/memoryusage/internal/MemoryUsageSupport.java#L553



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

[jira] [Commented] (FELIX-5394) Memoryusage plugin creates a heap dump on every notification

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on FELIX-5394:
--

bq. could you just clarify who will be responsible for setting the threshold on 
the memory pool? will the plugin not set it any more going forward?

If the threshold is configured to zero, yes, the idea is that the plugin will 
not set it any longer. If the configured value is in the valid range, the 
plugin will set it.

bq. also, might I add a small thing to your list: if the plugin is registered 
for a specific threshold and it receives an event, it should check that the 
memory delta is within that threshold before creating the dump

I am a bit at unease at doing that. My assumption is that someone enabled 
dumping by threshold. Now someone else changed the threshold, but still the 
dump might be desired

> Memoryusage plugin creates a heap dump on every notification
> 
>
> Key: FELIX-5394
> URL: https://issues.apache.org/jira/browse/FELIX-5394
> Project: Felix
>  Issue Type: Bug
>  Components: Web Console
>Affects Versions: webconsole-memoryusage-plugin-1.0.6
>Reporter: Alex Parvulescu
>  Labels: patch-available
> Attachments: FELIX-5394-v0.patch
>
>
> As a part of OAK-4966 I'm trying to install a listener on available memory 
> with a notification when a certain available memory threshold is met [0]. 
> This seems to clash a bit with the current {{memoryusage}} plugin, as both 
> jmx listeners try to change the threshold for the notification, and 
> subsequently both might receive the notification at a different value than 
> expected. (for example I'm setting a notification at {{15%}} and even though 
> the {{memoryusage}} plugin is not used and is currently set at {{0%}} it will 
> still create a heap dump:
> {noformat}
> *WARN* [Service Thread] org.apache.felix.webconsole.plugins.memoryusage 
> Received Memory Threshold Exceeded Notification, dumping Heap
> {noformat}
> I have 2 suggestions:
> * first is to _not_ change the threshold value if it's already set at a 
> smaller value. this means the plugin will not break other listeners 
> expectations of receiving an event
>  
> * second is to verify the locally set threshold value against the values seen 
> at notification time. this effectively means the plugin is free to ignore 
> certain events, and not dump the heap to disk every time it gets a ping [1].
> I would like to provide a patch for this issue pretty soon as I really need 
> to fix OAK-4966, unless someone is more eager to come up with a working 
> solution.
> [0] 
> https://issues.apache.org/jira/browse/OAK-4966?focusedCommentId=15629253&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15629253
> [1] 
> https://github.com/apache/felix/blob/trunk/webconsole-plugins/memoryusage/src/main/java/org/apache/felix/webconsole/plugins/memoryusage/internal/MemoryUsageSupport.java#L553



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

[jira] [Created] (FELIX-5397) Memoryusage plugin default configuration incorrect

[Felix Meschberger (JIRA)]

Felix Meschberger created FELIX-5397:


 Summary: Memoryusage plugin default configuration incorrect
 Key: FELIX-5397
 URL: https://issues.apache.org/jira/browse/FELIX-5397
 Project: Felix
  Issue Type: Bug
  Components: Web Console
Affects Versions: webconsole-memoryusage-plugin-1.0.6
Reporter: Felix Meschberger
 Fix For: webconsole-memoryusage-plugin-1.0.8


When no Configuration Admin configuration exists for the Memoryusage plugin 
static default values are displayed. In addition the dump interval time is 
documented to be given seconds with a default value of 6h, while the displayed 
values would 6h in milliseconds (or 6000h in seconds).

As the metatype is dynamically generated anyway, the default values should 
actually be derived from the currently configured values as provided by the 
either the static defaults or the configuration provided from the framework 
properties.



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

[jira] [Comment Edited] (FELIX-5394) Memoryusage plugin creates a heap dump on every notification

[Felix Meschberger (JIRA)]

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

Felix Meschberger edited comment on FELIX-5394 at 11/4/16 2:17 PM:
---

Apart from that, there is indeed a proplem with the plugin: The documentation 
of the _Dump Threshold_ property states _zero to disable automatic dump 
creation_.

This is clearly not implemented like that. Rather the implementation does this 
when the property is zero:

  * Registers the notification listener (yes, this listener is always 
registered !)
  * Sets the threshold to zero on all memory pools allowing to set the 
threshold. This causes these pools to not send events.
  * Still set the threshold to zero on the settable pools (this may be 
overwritten by other tooling but dumps by the plugin will not be created)

Now, should some other system tooling decide to set the threshold to some value 
(of course this setting is sort of a race condition between this plugin and the 
other tool), the plugin will receive events and in contrast to the stated 
"disable automatic dump creation", dumps will be created.

We should fix this as follows:

  * Register the listener only in case a non-zero threshold is configured
  * Make sure the listener is not registered (or unregistered) if a zero 
threshold is configured

[~alex.parvulescu] Does that work for you ?


was (Author: fmeschbe):
Apart from that, there is indeed a proplem with the plugin: The documentation 
of the _Dump Threshold_ property states _zero to disable automatic dump 
creation_.

This is clearly not implemented like that. Rather the implementation does this 
when the property is zero:

  * Registers the notification listener (yes, this listener is always 
registered !)
  * Sets the threshold to zero on all memory pools allowing to set the 
threshold. This causes these pools to not send events.

Now, should some other system tooling decide to set the threshold to some value 
(of course this setting is sort of a race condition between this plugin and the 
other tool), the plugin will receive events and in contrast to the stated 
"disable automatic dump creation", dumps will be created.

We should fix this as follows:

  * Register the listener only in case a non-zero threshold is configured
  * Make sure the listener is not registered (or unregistered) if a zero 
threshold is configured

[~alex.parvulescu] Does that work for you ?

> Memoryusage plugin creates a heap dump on every notification
> 
>
> Key: FELIX-5394
> URL: https://issues.apache.org/jira/browse/FELIX-5394
> Project: Felix
>  Issue Type: Bug
>  Components: Web Console
>Affects Versions: webconsole-memoryusage-plugin-1.0.6
>Reporter: Alex Parvulescu
>  Labels: patch-available
> Attachments: FELIX-5394-v0.patch
>
>
> As a part of OAK-4966 I'm trying to install a listener on available memory 
> with a notification when a certain available memory threshold is met [0]. 
> This seems to clash a bit with the current {{memoryusage}} plugin, as both 
> jmx listeners try to change the threshold for the notification, and 
> subsequently both might receive the notification at a different value than 
> expected. (for example I'm setting a notification at {{15%}} and even though 
> the {{memoryusage}} plugin is not used and is currently set at {{0%}} it will 
> still create a heap dump:
> {noformat}
> *WARN* [Service Thread] org.apache.felix.webconsole.plugins.memoryusage 
> Received Memory Threshold Exceeded Notification, dumping Heap
> {noformat}
> I have 2 suggestions:
> * first is to _not_ change the threshold value if it's already set at a 
> smaller value. this means the plugin will not break other listeners 
> expectations of receiving an event
>  
> * second is to verify the locally set threshold value against the values seen 
> at notification time. this effectively means the plugin is free to ignore 
> certain events, and not dump the heap to disk every time it gets a ping [1].
> I would like to provide a patch for this issue pretty soon as I really need 
> to fix OAK-4966, unless someone is more eager to come up with a working 
> solution.
> [0] 
> https://issues.apache.org/jira/browse/OAK-4966?focusedCommentId=15629253&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15629253
> [1] 
> https://github.com/apache/felix/blob/trunk/webconsole-plugins/memoryusage/src/main/java/org/apache/felix/webconsole/plugins/memoryusage/internal/MemoryUsageSupport.java#L553



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

[jira] [Commented] (FELIX-5394) Memoryusage plugin creates a heap dump on every notification

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on FELIX-5394:
--

Apart from that, there is indeed a proplem with the plugin: The documentation 
of the _Dump Threshold_ property states _zero to disable automatic dump 
creation_.

This is clearly not implemented like that. Rather the implementation does this 
when the property is zero:

  * Registers the notification listener (yes, this listener is always 
registered !)
  * Sets the threshold to zero on all memory pools allowing to set the 
threshold. This causes these pools to not send events.

Now, should some other system tooling decide to set the threshold to some value 
(of course this setting is sort of a race condition between this plugin and the 
other tool), the plugin will receive events and in contrast to the stated 
"disable automatic dump creation", dumps will be created.

We should fix this as follows:

  * Register the listener only in case a non-zero threshold is configured
  * Make sure the listener is not registered (or unregistered) if a zero 
threshold is configured

[~alex.parvulescu] Does that work for you ?

> Memoryusage plugin creates a heap dump on every notification
> 
>
> Key: FELIX-5394
> URL: https://issues.apache.org/jira/browse/FELIX-5394
> Project: Felix
>  Issue Type: Bug
>  Components: Web Console
>Affects Versions: webconsole-memoryusage-plugin-1.0.6
>Reporter: Alex Parvulescu
>  Labels: patch-available
> Attachments: FELIX-5394-v0.patch
>
>
> As a part of OAK-4966 I'm trying to install a listener on available memory 
> with a notification when a certain available memory threshold is met [0]. 
> This seems to clash a bit with the current {{memoryusage}} plugin, as both 
> jmx listeners try to change the threshold for the notification, and 
> subsequently both might receive the notification at a different value than 
> expected. (for example I'm setting a notification at {{15%}} and even though 
> the {{memoryusage}} plugin is not used and is currently set at {{0%}} it will 
> still create a heap dump:
> {noformat}
> *WARN* [Service Thread] org.apache.felix.webconsole.plugins.memoryusage 
> Received Memory Threshold Exceeded Notification, dumping Heap
> {noformat}
> I have 2 suggestions:
> * first is to _not_ change the threshold value if it's already set at a 
> smaller value. this means the plugin will not break other listeners 
> expectations of receiving an event
>  
> * second is to verify the locally set threshold value against the values seen 
> at notification time. this effectively means the plugin is free to ignore 
> certain events, and not dump the heap to disk every time it gets a ping [1].
> I would like to provide a patch for this issue pretty soon as I really need 
> to fix OAK-4966, unless someone is more eager to come up with a working 
> solution.
> [0] 
> https://issues.apache.org/jira/browse/OAK-4966?focusedCommentId=15629253&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15629253
> [1] 
> https://github.com/apache/felix/blob/trunk/webconsole-plugins/memoryusage/src/main/java/org/apache/felix/webconsole/plugins/memoryusage/internal/MemoryUsageSupport.java#L553



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

[jira] [Commented] (FELIX-5394) Memoryusage plugin creates a heap dump on every notification

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on FELIX-5394:
--

If I understand it correctly, Oak wants to be notified if there is a memory 
shortage while they perform some housekeeping (tar online compaction). I 
appreciate their use of this notification to try to make sure their heap 
consumption while housekeeping does not "kill" the system.

But then, I think it cannot be Oak's task to change any of the thresholds. As 
such I think we should not change this plugin and rather have Oak just register 
for the notification and document that they expect deployments to have a 
reasonable threshold configuration.

> Memoryusage plugin creates a heap dump on every notification
> 
>
> Key: FELIX-5394
> URL: https://issues.apache.org/jira/browse/FELIX-5394
> Project: Felix
>  Issue Type: Bug
>  Components: Web Console
>Affects Versions: webconsole-memoryusage-plugin-1.0.6
>Reporter: Alex Parvulescu
>  Labels: patch-available
> Attachments: FELIX-5394-v0.patch
>
>
> As a part of OAK-4966 I'm trying to install a listener on available memory 
> with a notification when a certain available memory threshold is met [0]. 
> This seems to clash a bit with the current {{memoryusage}} plugin, as both 
> jmx listeners try to change the threshold for the notification, and 
> subsequently both might receive the notification at a different value than 
> expected. (for example I'm setting a notification at {{15%}} and even though 
> the {{memoryusage}} plugin is not used and is currently set at {{0%}} it will 
> still create a heap dump:
> {noformat}
> *WARN* [Service Thread] org.apache.felix.webconsole.plugins.memoryusage 
> Received Memory Threshold Exceeded Notification, dumping Heap
> {noformat}
> I have 2 suggestions:
> * first is to _not_ change the threshold value if it's already set at a 
> smaller value. this means the plugin will not break other listeners 
> expectations of receiving an event
>  
> * second is to verify the locally set threshold value against the values seen 
> at notification time. this effectively means the plugin is free to ignore 
> certain events, and not dump the heap to disk every time it gets a ping [1].
> I would like to provide a patch for this issue pretty soon as I really need 
> to fix OAK-4966, unless someone is more eager to come up with a working 
> solution.
> [0] 
> https://issues.apache.org/jira/browse/OAK-4966?focusedCommentId=15629253&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15629253
> [1] 
> https://github.com/apache/felix/blob/trunk/webconsole-plugins/memoryusage/src/main/java/org/apache/felix/webconsole/plugins/memoryusage/internal/MemoryUsageSupport.java#L553



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

json.org library use

[Felix Meschberger]

Hi all

Over at legal-discuss there is a discussion of whether the json.org library 
with the amended MIT license (remember the „use for good not evil“ clause ?) 
should be „banned“ by reconsidering the „A“ rating of this license (assuming 
the clause is just a joke) and turning it into an „X“ rating (don’t use based 
on Debian’s and other’s considerations:

https://wiki.debian.org/qa.debian.org/jsonevil
https://www.cnet.com/news/dont-be-evil-google-spurns-no-evil-software/

It is not decided yet. But for the web console we should probably be prepared.

Plenty of alternatives exist: Jackson, GSon, and IMHO quite interesting 
javax.json (https://json-processing-spec.java.net/) with a RI from glassfish 
(https://jsonp.java.net/).

Assuming we would have to change things, I propose we reimplement the API of 
the json.org library with javax.json using the Glassfish RI.

WDYT ?

Regards
Felix

[jira] [Commented] (FELIX-5148) Framework Security unusable

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on FELIX-5148:
--

I have to admit [~olli], that I don't know exactly what's going on here.

I once added a policy file to the configadmin bundle (FELIX-4039), but TBH I 
don't exactly know that works, except that with this file in place the bundle 
passes the OSGi CT tests even with SecurityManager enabled.

> Framework Security unusable
> ---
>
> Key: FELIX-5148
> URL: https://issues.apache.org/jira/browse/FELIX-5148
> Project: Felix
>  Issue Type: Bug
>  Components: Configuration Admin, Framework Security
>Affects Versions: framework.security-2.4.0, configadmin-1.8.0
>Reporter: Oliver Lietz
>
> While fixing an issue with Sling and RMI (SLING-5375) reported by an user I 
> came across an issue (KARAF-3400) reported by [~achim_nierbeck] for Karaf 
> related to framework security.
> There is also an issue with [Sling's own OSGi launcher 
> Launchpad|https://svn.apache.org/viewvc/sling/trunk/launchpad/builder/] and 
> framework security when using {{org.apache.felix.configadmin}} >= {{1.8.0}}.
> {{all.policy}}:
> {noformat}
> grant {
>permission java.security.AllPermission;
> };
> {noformat}
> Adding {{org.apache.felix/org.apache.felix.framework.security/2.4.0}} to 
> {{boot.txt}} and starting with arguments described on [Framework Security's 
> page|http://felix.apache.org/documentation/subprojects/apache-felix-framework-security.html]
>  (which looks broken) and 
> [{{-Djava.security.manager}}|http://docs.oracle.com/javase/8/docs/technotes/guides/security/spec/security-spec.doc6.html]
>  ([Building Secure OSGi 
> Applications|http://de.slideshare.net/marrs/building-secure-osgi-applications])
>  throws a {{java.security.AccessControlException}}:
> {noformat}
> java -Djava.security.manager -Djava.security.policy="all.policy" 
> -Dorg.osgi.framework.security="osgi" -jar 
> org.apache.sling.launchpad-9-SNAPSHOT.jar
> {noformat}
> {noformat}
> [...]
> [...] *ERROR* [FelixStartLevel] ERROR: Error starting 
> slinginstall:org.apache.felix.configadmin-1.8.0.jar 
> (java.security.AccessControlException: access denied 
> ("java.io.FilePermission" "/[...]/sling/config" "read"))
> java.security.AccessControlException: access denied ("java.io.FilePermission" 
> "/[...]/sling/config" "read")
>   at 
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
>   at 
> java.security.AccessController.checkPermission(AccessController.java:884)
>   at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
>   at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
>   at java.io.File.isDirectory(File.java:844)
>   at 
> org.apache.felix.cm.file.FilePersistenceManager.(FilePersistenceManager.java:342)
>   at 
> org.apache.felix.cm.impl.ConfigurationManager.start(ConfigurationManager.java:244)
>   at 
> org.apache.felix.framework.util.SecureAction$Actions.run(SecureAction.java:1709)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at 
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:688)
>   at org.apache.felix.framework.Felix.activateBundle(Felix.java:2226)
>   at org.apache.felix.framework.Felix.startBundle(Felix.java:2144)
>   at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1371)
>   at 
> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
>   at java.lang.Thread.run(Thread.java:745)
> [...]
> {noformat}
> I had to remove OSGi Subsystems support from {{boot.txt}} when using 
> {{org.apache.felix.configadmin}} {{1.6}}:
> {noformat}
> org.apache.felix/org.apache.felix.coordinator/1.0.0
> org.eclipse.equinox/org.eclipse.equinox.region/1.2.101.v20150831-1342
> org.apache.aries.subsystem/org.apache.aries.subsystem.api/2.0.6
> org.apache.aries.subsystem/org.apache.aries.subsystem.core/2.0.6
> {noformat}



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

[jira] [Updated] (FELIX-4890) Implement a MetaType service inventory printer

[Felix Meschberger (JIRA)]

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

Felix Meschberger updated FELIX-4890:
-
Fix Version/s: webconsole-metatype-plugin-1.0.0

> Implement a MetaType service inventory printer
> --
>
> Key: FELIX-4890
> URL: https://issues.apache.org/jira/browse/FELIX-4890
> Project: Felix
>  Issue Type: Task
>  Components: Web Console
>    Reporter: Felix Meschberger
>    Assignee: Felix Meschberger
> Fix For: webconsole-metatype-plugin-1.0.0
>
>
> For completeness of information of the status output of a framework 
> supporting inventory printing, it would be good to have an InventoryPrinter 
> for MetaType service information.



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

[jira] [Commented] (FELIX-4890) Implement a MetaType service inventory printer

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on FELIX-4890:
--

Added first version in commit 1679974 to 
http://svn.apache.org/repos/asf/felix/trunk/webconsole-plugins/metatype

> Implement a MetaType service inventory printer
> --
>
> Key: FELIX-4890
> URL: https://issues.apache.org/jira/browse/FELIX-4890
> Project: Felix
>  Issue Type: Task
>  Components: Web Console
>Reporter: Felix Meschberger
>    Assignee: Felix Meschberger
>
> For completeness of information of the status output of a framework 
> supporting inventory printing, it would be good to have an InventoryPrinter 
> for MetaType service information.



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

[jira] [Created] (FELIX-4890) Implement a MetaType service inventory printer

[Felix Meschberger (JIRA)]

Felix Meschberger created FELIX-4890:


 Summary: Implement a MetaType service inventory printer
 Key: FELIX-4890
 URL: https://issues.apache.org/jira/browse/FELIX-4890
 Project: Felix
  Issue Type: Task
  Components: Web Console
Reporter: Felix Meschberger
Assignee: Felix Meschberger


For completeness of information of the status output of a framework supporting 
inventory printing, it would be good to have an InventoryPrinter for MetaType 
service information.



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

[jira] [Commented] (FELIX-4599) Support Encryption Of Configuration Properties

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on FELIX-4599:
--

No they are really on called as I said :-)

> Support Encryption Of Configuration Properties
> --
>
> Key: FELIX-4599
> URL: https://issues.apache.org/jira/browse/FELIX-4599
> Project: Felix
>  Issue Type: New Feature
>  Components: Configuration Admin
>Reporter: Dominique Jäggi
>
> Currently it is not possible to define configuration properties, the contents 
> of which should be automatically encrypted upon save by the configuration 
> admin.
> An example would be a mail server configuration, where SMTP credentials must 
> specified and the password should be encrypted upon saving the configuration. 
> The encrypted password should then be accessible and decryptable in the 
> component to which the configuration is bound.



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

[jira] [Commented] (FELIX-4599) Support Encryption Of Configuration Properties

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on FELIX-4599:
--

[~chetanm] The problem ConfigurationPlugin is that they only kick in when 
ConfigurationAdmin service is sending configuration ManagedService[Factory] 
services. They don't kick in when accessing configuration with getConfiguration 
and listConfigurations. As such they are not a complete solution.

> Support Encryption Of Configuration Properties
> --
>
> Key: FELIX-4599
> URL: https://issues.apache.org/jira/browse/FELIX-4599
> Project: Felix
>  Issue Type: New Feature
>  Components: Configuration Admin
>Reporter: Dominique Jäggi
>
> Currently it is not possible to define configuration properties, the contents 
> of which should be automatically encrypted upon save by the configuration 
> admin.
> An example would be a mail server configuration, where SMTP credentials must 
> specified and the password should be encrypted upon saving the configuration. 
> The encrypted password should then be accessible and decryptable in the 
> component to which the configuration is bound.



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

[jira] [Resolved] (FELIX-4792) [SCR] Handle Errors on component initialization

[Felix Meschberger (JIRA)]

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

Felix Meschberger resolved FELIX-4792.
--
Resolution: Fixed

Implemented catching any Throwable during initial component initialization and 
logging it in Rev. 1658457.

In addition the component is disabled to make sure any partical setup is rolled 
back.

> [SCR] Handle Errors on component initialization
> ---
>
> Key: FELIX-4792
> URL: https://issues.apache.org/jira/browse/FELIX-4792
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-1.8.2
>    Reporter: Felix Meschberger
>    Assignee: Felix Meschberger
> Fix For: scr-2.0.0
>
>
> During component initialization the component implementation class is loaded. 
> If the class or one of its dependencies cannot be properly loaded a 
> ClassDefNotFound error can be thrown.
> This error bubbles up from BundleComponentActivator.initialEnable to the 
> AbstractExtender.createExtension method, where it is logged. The problem with 
> this is, that the BundleComponentActivator has registered all the components 
> of the bundle with the ComponentRegistry but when the error is thrown, the 
> BundleComponentActivator is not registered in Activator's m_componentBundles 
> map.
> So, when the bundle is stopped, the components registered with the 
> ComponentRegistry stay registered and will never be cleaned away.
> The simple fix is to catch Throwable in the 
> BundleComponentActivator.initialEnable method and log it. The single 
> component failing to load will stay inactive but the rest of the component 
> registration will continue unaffected.
> Background: We have a situation where a bundle is compiled against an API 
> bundle whose exported API is not properly versioned. So the OSGi framework 
> happily wires the bundle to the older API bundle version but one of the 
> components fails to load due to missing API.



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

[jira] [Created] (FELIX-4792) [SCR] Handle Errors on component initialization

[Felix Meschberger (JIRA)]

Felix Meschberger created FELIX-4792:


 Summary: [SCR] Handle Errors on component initialization
 Key: FELIX-4792
 URL: https://issues.apache.org/jira/browse/FELIX-4792
 Project: Felix
  Issue Type: Bug
  Components: Declarative Services (SCR)
Affects Versions: scr-1.8.2
Reporter: Felix Meschberger
Assignee: Felix Meschberger
 Fix For: scr-2.0.0


During component initialization the component implementation class is loaded. 
If the class or one of its dependencies cannot be properly loaded a 
ClassDefNotFound error can be thrown.

This error bubbles up from BundleComponentActivator.initialEnable to the 
AbstractExtender.createExtension method, where it is logged. The problem with 
this is, that the BundleComponentActivator has registered all the components of 
the bundle with the ComponentRegistry but when the error is thrown, the 
BundleComponentActivator is not registered in Activator's m_componentBundles 
map.

So, when the bundle is stopped, the components registered with the 
ComponentRegistry stay registered and will never be cleaned away.

The simple fix is to catch Throwable in the 
BundleComponentActivator.initialEnable method and log it. The single component 
failing to load will stay inactive but the rest of the component registration 
will continue unaffected.

Background: We have a situation where a bundle is compiled against an API 
bundle whose exported API is not properly versioned. So the OSGi framework 
happily wires the bundle to the older API bundle version but one of the 
components fails to load due to missing API.



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

Felix OBR and Downloads

[Felix Meschberger]

Hi


> Anfang der weitergeleiteten Nachricht:
> 
> Antwort an: 
> Datum: 8. Februar 2015 20:19:29 MEZ
> Betreff: Aw: [SCR] BND file ok ?
> Von: Pierre De Rop 
> An: "dev@felix.apache.org" 
> 
> Hi Felix, David;
> 
> - create a bndtools project for SCR, and activate semantic versioning using
> our Apache Felix OBR repository
> Something like:
> 
>   aQute.bnd.deployer.repository.FixedIndexRepo; name=Apache Felix Obr;
> locations=http://felix.apache.org/obr/releases.xml
>   -baseline: *
>   -baselinerepo: Apache Felix Obr
> 

The Felix OBR [1] essentially provides the same information as the Felix 
Downloads page [2]. Is there a way to actually only maintain one of them and 
generate the other automatically ?

WDYT ?

Regards
Felix

[1] http://felix.apache.org/downloads.cgi
[2] http://felix.apache.org/obr/releases.xml

Re: [SCR] BND file ok ?

[Felix Meschberger]

Hi Pierre

This sounds like a great plan. 

Regarding generation of a POM: Is this needed for Maven Central deployment ?

You mentioned the repository, this brings me to an idea I’ll start discussing 
in a separate thread.

Regards
Felix

> Am 08.02.2015 um 20:19 schrieb Pierre De Rop :
> 
> Hi Felix, David;
> 
> I confirm that the upcoming Dependency Manager 4.0 is now fully based on
> bndtools and gradle, and we are not using maven anymore. I hope that we'll
> (try to) make a release soon.
> 
> Now, regarding the SCR project, it could be possible to switch to bndtools
> and gradle, but that will require some work.
> 
> If there is a general consensus on doing that move, I could then create a
> Jira issue, and attach to it an initial patch. We could then continue to
> discuss on the Jira issue, based on the initial patch.
> But before that, I first have to do my best to bring to life the new DM4
> release, and we'll then benefit from the bndtools/gradle based DM release
> to see what could be reused for SCR.
> 
> I imagine that the work to do would consist in the following:
> 
> - create a bndtools project for SCR, and activate semantic versioning using
> our Apache Felix OBR repository
> Something like:
> 
>   aQute.bnd.deployer.repository.FixedIndexRepo; name=Apache Felix Obr;
> locations=http://felix.apache.org/obr/releases.xml
>   -baseline: *
>   -baselinerepo: Apache Felix Obr
> 
> - adapt the tests, based of bndtools. We could even gradually change the
> integration tests in order to generate the test components xml descriptors
> using DS annotations, instead of doing that manually.
> - create a release gradle script. That script would do the following:
> 
> * reuse the Apache rat gradle script to check correct license file headers.
> * generate a local staging repository, which would contain:
>  - the scr binary jar (org.apache.felix.scr.jar)
>  - the bndtools scr source project (org.apache.felix.scr-src.zip)
>  - the bndtols binary dependencies (org.apache.felix.scr-deps.zip)
> 
> * sign the local repository, by simply using gpg
> * generate a pom (could be done by dynamically inspecting bnd dependencies
> from gradle, using the  aQute.bnd.build.Project library)
> * use the same kind of gradle scripts from [3] in order to upload the local
> staging repository to our nexus repository.
> 
> cheers;
> /Pierre
> 
> [1] http://www.apache.org/dev/release.html
> [2] http://books.sonatype.com/nexus-book/reference/gradle.html
> [3]
> https://github.com/sonatype/nexus-book-examples/tree/master/gradle/simple-project-staging
> 
> 
> On Sat, Feb 7, 2015 at 5:01 AM, David Jencks > wrote:
> 
>> Ok, it seems like now all the changes I've made for the last year +  are
>> getting discussed which is good :-)
>> 
>> I'd like to propose that instead of re-maven-ifying ds we
>> gradle-bndtools-ize it instead and drop maven entirely from this
>> sub-project.  I haven't had time to experiment with this conversion but
>> IIUC Pierre has been trying it out in his dependency manager sandbox
>> project.  Unfortunately I haven't even had time to investigate that.  Could
>> anyone comment on it?
>> 
>> Based on the speed of the bnd and osgi ct builds I would suspect that it
>> would cut the ds build time by about 75%.  However I have no concrete
>> evidence to support this.
>> 
>> thanks
>> david jencks
>> 
>> On Feb 6, 2015, at 3:42 AM, Felix Meschberger  wrote:
>> 
>>> Hi
>>> 
>>> With FELIX-4537 [1] the bundle plugin configuration was moved out into a
>> .bnd file.
>>> 
>>> While the format of either pom.xml or .bnd is debatable I think we
>> should be having a discussion around this. For now we always had all bundle
>> plugin configuration in the pom.xml and I see a clear advantage to that:
>> All configuration for the bundle generation is in one place.
>>> 
>>> Apart from this discussion, I think we should switch to using
>> package-info.java files with @Version annotations to have the package
>> version close to the code it describes.
>>> 
>>> Also, the .bnd file is not really properly set up, unfortunately:
>>> 
>>> * It hard codes many of the configurations of the POM file. If we stick
>> with the .bnd these values should referenced with variables — if not
>> possible, I fear that would be another argument against the .bnd file…
>>> 
>>> * The bundle must import all exports, this is particularly important
>> for the util.function and util.promise packages.
>>> 
>>> I have no hard feelings about whether we keep the .bnd or not. My
>> personal impression is just that having two files to configure things makes
>> it harder to maintain and bears the danger of duplication of information
>> (e.g. the bundle version). So I have slight preference, if you will :-)
>>> 
>>> Regards
>>> Felix
>>> 
>>> [1] https://issues.apache.org/jira/browse/FELIX-4537
>>> 
>> 
>> 

Re: [SCR] BND file ok ?

[Felix Meschberger]

Hi David

> Am 07.02.2015 um 05:01 schrieb David Jencks :
> 
> Ok, it seems like now all the changes I've made for the last year +  are 
> getting discussed which is good :-)

Sorry, for chiming in this late and having had your work virtually ignored … 
Really.

> 
> I'd like to propose that instead of re-maven-ifying ds we gradle-bndtools-ize 
> it instead and drop maven entirely from this sub-project.  I haven't had time 
> to experiment with this conversion but IIUC Pierre has been trying it out in 
> his dependency manager sandbox project.  Unfortunately I haven't even had 
> time to investigate that.  Could anyone comment on it?
> 
> Based on the speed of the bnd and osgi ct builds I would suspect that it 
> would cut the ds build time by about 75%.  However I have no concrete 
> evidence to support this.

Now, that sounds like a good idea as well. At the end of the day, I think it 
really doesn’t matter whether we use a pure Maven build or a pure Gradle/BND 
build. The more important point is that it is „pure“ and even more important is 
that information is not replicated across multiple files.

So, I am in favour of trying it out.

Regards
Felix

> 
> thanks
> david jencks
> 
> On Feb 6, 2015, at 3:42 AM, Felix Meschberger  wrote:
> 
>> Hi
>> 
>> With FELIX-4537 [1] the bundle plugin configuration was moved out into a 
>> .bnd file.
>> 
>> While the format of either pom.xml or .bnd is debatable I think we should be 
>> having a discussion around this. For now we always had all bundle plugin 
>> configuration in the pom.xml and I see a clear advantage to that: All 
>> configuration for the bundle generation is in one place.
>> 
>> Apart from this discussion, I think we should switch to using 
>> package-info.java files with @Version annotations to have the package 
>> version close to the code it describes.
>> 
>> Also, the .bnd file is not really properly set up, unfortunately:
>> 
>> * It hard codes many of the configurations of the POM file. If we stick with 
>> the .bnd these values should referenced with variables — if not possible, I 
>> fear that would be another argument against the .bnd file…
>> 
>> * The bundle must import all exports, this is particularly important for the 
>> util.function and util.promise packages.
>> 
>> I have no hard feelings about whether we keep the .bnd or not. My personal 
>> impression is just that having two files to configure things makes it harder 
>> to maintain and bears the danger of duplication of information (e.g. the 
>> bundle version). So I have slight preference, if you will :-)
>> 
>> Regards
>> Felix
>> 
>> [1] https://issues.apache.org/jira/browse/FELIX-4537
>> 
> 

[SCR] BND file ok ?

[Felix Meschberger]

Hi

With FELIX-4537 [1] the bundle plugin configuration was moved out into a .bnd 
file.

While the format of either pom.xml or .bnd is debatable I think we should be 
having a discussion around this. For now we always had all bundle plugin 
configuration in the pom.xml and I see a clear advantage to that: All 
configuration for the bundle generation is in one place.

Apart from this discussion, I think we should switch to using package-info.java 
files with @Version annotations to have the package version close to the code 
it describes.

Also, the .bnd file is not really properly set up, unfortunately:

  * It hard codes many of the configurations of the POM file. If we stick with 
the .bnd these values should referenced with variables — if not possible, I 
fear that would be another argument against the .bnd file…

  * The bundle must import all exports, this is particularly important for the 
util.function and util.promise packages.

I have no hard feelings about whether we keep the .bnd or not. My personal 
impression is just that having two files to configure things makes it harder to 
maintain and bears the danger of duplication of information (e.g. the bundle 
version). So I have slight preference, if you will :-)

Regards
Felix

[1] https://issues.apache.org/jira/browse/FELIX-4537

[jira] [Commented] (FELIX-4787) DS implementation should be based on R6

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on FELIX-4787:
--

In light of FELIX-4785 where we discuss keeping the old service API I think we 
should not jump the band wagon and just blindly require framework R6.

Just as we have consumers of the old service API we might have implementations 
of the old Framework API which cannot easily migrate to a new framework version 
(in fact migrating the framework is probably harder than migrating just about 
some bundle).

So I suggest we should actually keep compatibility with old framework versions. 
This probably means:

  * not support new functionality if the framework does not support it. For 
ServiceObjects this means that components making use of this functionality fail 
to "resolve" due to a missing dependency.
  * embed parts of the API which we cannot expect on older frameworks -- or not 
expose that functionality at all. For DTO this means either embedding the DTO 
API and exporting/importing it like we do with the Promise API or it means not 
exposing the DTOs if the basic DTO API is not available -- similar to how we 
support Configuration Admin and Metatype depending on whether these APIs and 
services are available.

> DS implementation should be based on R6
> ---
>
> Key: FELIX-4787
> URL: https://issues.apache.org/jira/browse/FELIX-4787
> Project: Felix
>  Issue Type: Task
>  Components: Declarative Services (SCR)
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: scr-2.0.0
>
>
> Right now the new DS implementation stills tries to run on older frameworks, 
> the bnd.bnd file claims it works with version 1.4 of the framework api.
> However, the new DS spec includes support for ServiceObjects and DTOs which 
> are part of core R6 (package version 1.8). There is some effort in the code 
> to still run on an older framework if these features are not used, but I'm 
> wondering if this is a good idea and how we ensure that everything is working.
> Now, that we have an official Apache Felix releases that is R6 compliant, I 
> would rather require this as the minimal version.
> [~djencks] WDYT?



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

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

[Felix Meschberger (JIRA)]

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

Felix Meschberger resolved FELIX-4692.
--
Resolution: Fixed

Thanks for the feedback. I have applied the second patch in Rev. 1649858 (and I 
hope I got the formatting right this time :-) )

> Improve Service access time
> ---
>
> Key: FELIX-4692
> URL: https://issues.apache.org/jira/browse/FELIX-4692
> Project: Felix
>  Issue Type: Improvement
>  Components: Framework
>Affects Versions: framework-4.4.1
>    Reporter: Felix Meschberger
>    Assignee: Felix Meschberger
> Fix For: framework-4.6.0
>
> Attachments: FELIX-4692-2.patch, FELIX-4692.diff
>
>
> Currently the ServiceRegistry takes roughly 1ms to access a single service. 
> In a reasonably large system, this may over time consume considerable time.
> For example in our inhouse system sporting roughly 5000 services with 15'000 
> service accesses during startup, these accesses acount for almost 15 seconds 
> or roughly 25-30% of the total startup time.
> Internally all accesses to services are handled with a Filter even if the 
> service is simply retrieved with the service name without a filter. This 
> causes a considerable overhead.
> A simple improvement is to keep services not only in a global Capabitliy Set 
> accessible through generic filters but also keep such a set for each 
> registered service name.
> The measured improvement of this change is substantial: accessing these 
> 15'000 services now only takes roughly 3 seconds or 0.2 ms per service or 5 
> times faster.



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

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

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on FELIX-4692:
--

For illustration purposes some measurments of the 
{{ServiceRegistry.getServiceReferences(String className, SimpleFilter filter)}} 
method.

|| Period || #1   || #2|| #3 || #4|| #5|| 
#6  || ||
| Startup | 8720 | 8720 | 8720 | 8720 | 8722 | 8720 | calls 
to getServiceReferences method |
|  | 4074 | 3983 | 3740 | 1397 | 1086 | 1017 | 
Total ms spent in method |
| Startup + Shutdown | 15093 | 15105 | 15075 | 15091 | 15199 | 15197 | calls to 
getServiceReferences method |
|  | 12951 | 13039 | 12012 | 4336 | 3144 | 3101 
| Total ms spent in method |

# Unmodified framework at Rev. 1649764
# Guard {{matches.retainAll(caps)}} call only -- not that much of an influence, 
interestingly; probably not doing much work most of the time due to small set 
of entries in the matches set.
# Guard {{matches.retainAll(caps)}} call and not wrapping set in ArrayList -- 
some more improvement, nothing drammatic yet
# Guard {{matches.retainAll(caps)}} call, not wrapping set in ArrayList, 
special case code (not in the patch) to specially handle 
{{SimpleFilter.PRESENT}} filters - starts to go into the right direction
# [^FELIX-4692-2.patch] applied -- since the presence check derives from access 
to services with a {{null}} service interface, changing the filter to 
{{MATCH_ALL}} instead looks even better and makes for simpler code in the 
{{CapabilitySet}} not requiring special handling of the presence check.
# [^FELIX-4692.diff] applied -- best numbers but most complex and thus not used.

All tests are run on an mid-2013 MacBook Air 13 with 1.7 GHz Intel Core i7, 8GB 
RAM, and SSD. The absolute values vary but relative values across the options 
are interesting.

> Improve Service access time
> ---
>
> Key: FELIX-4692
> URL: https://issues.apache.org/jira/browse/FELIX-4692
> Project: Felix
>  Issue Type: Improvement
>  Components: Framework
>Affects Versions: framework-4.4.1
>    Reporter: Felix Meschberger
>    Assignee: Felix Meschberger
> Fix For: framework-4.6.0
>
> Attachments: FELIX-4692-2.patch, FELIX-4692.diff
>
>
> Currently the ServiceRegistry takes roughly 1ms to access a single service. 
> In a reasonably large system, this may over time consume considerable time.
> For example in our inhouse system sporting roughly 5000 services with 15'000 
> service accesses during startup, these accesses acount for almost 15 seconds 
> or roughly 25-30% of the total startup time.
> Internally all accesses to services are handled with a Filter even if the 
> service is simply retrieved with the service name without a filter. This 
> causes a considerable overhead.
> A simple improvement is to keep services not only in a global Capabitliy Set 
> accessible through generic filters but also keep such a set for each 
> registered service name.
> The measured improvement of this change is substantial: accessing these 
> 15'000 services now only takes roughly 3 seconds or 0.2 ms per service or 5 
> times faster.



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

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

[Felix Meschberger (JIRA)]

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

Felix Meschberger updated FELIX-4692:
-
Attachment: FELIX-4692-2.patch

Simpler patch with three changes as described in previous comment.

> Improve Service access time
> ---
>
> Key: FELIX-4692
> URL: https://issues.apache.org/jira/browse/FELIX-4692
> Project: Felix
>  Issue Type: Improvement
>  Components: Framework
>Affects Versions: framework-4.4.1
>    Reporter: Felix Meschberger
>    Assignee: Felix Meschberger
> Fix For: framework-4.6.0
>
> Attachments: FELIX-4692-2.patch, FELIX-4692.diff
>
>
> Currently the ServiceRegistry takes roughly 1ms to access a single service. 
> In a reasonably large system, this may over time consume considerable time.
> For example in our inhouse system sporting roughly 5000 services with 15'000 
> service accesses during startup, these accesses acount for almost 15 seconds 
> or roughly 25-30% of the total startup time.
> Internally all accesses to services are handled with a Filter even if the 
> service is simply retrieved with the service name without a filter. This 
> causes a considerable overhead.
> A simple improvement is to keep services not only in a global Capabitliy Set 
> accessible through generic filters but also keep such a set for each 
> registered service name.
> The measured improvement of this change is substantial: accessing these 
> 15'000 services now only takes roughly 3 seconds or 0.2 ms per service or 5 
> times faster.



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

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

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on FELIX-4692:
--

Digging a bit deeper, I found the following opportunities for improvements:

# In the {{CapabilitySet.match(Set<> caps, SimpleFilter sf)}} method on line 
239 the {{matches.retainAll(caps)}} call is guarded by an {{if (caps != 
m_capSet)}}
# The {{ServiceRegistry.getServiceReferences(String className, SimpleFilter 
filter)}} method returns the set from the {{CapabilitySet.match(SimplerFilter, 
boolean)}} method directly without copying that into an ArrayList. This 
requires a slight adaption in the {{Felix.getServiceReferences(BundleImpl, 
String, String, boolean)}} method.
# Using a {{SimpleFilter.MATCH_ALL}} filter instead of a filter which checks 
for the objectclass property presence.

This last change has a drammatic impact in our use case, because the presence 
checks caused lots of "useless" property access because the objectclasses 
property is always present for services and hence just simply matching all 
services is correct. The reason for this impact is that we leverage the Aries 
JMX bundles which do repeated {{BundleContext.getAllServiceReferences(null, 
null)}} calls (maybe worth investigating on another route).

With these three changes I come close to the improvements compared to attached 
patch [^FELIX-4692.diff] but they have a much lower impact. So I will create a 
new patch with these changes.

> Improve Service access time
> ---
>
> Key: FELIX-4692
> URL: https://issues.apache.org/jira/browse/FELIX-4692
> Project: Felix
>  Issue Type: Improvement
>  Components: Framework
>Affects Versions: framework-4.4.1
>Reporter: Felix Meschberger
>Assignee: Felix Meschberger
> Fix For: framework-4.6.0
>
> Attachments: FELIX-4692.diff
>
>
> Currently the ServiceRegistry takes roughly 1ms to access a single service. 
> In a reasonably large system, this may over time consume considerable time.
> For example in our inhouse system sporting roughly 5000 services with 15'000 
> service accesses during startup, these accesses acount for almost 15 seconds 
> or roughly 25-30% of the total startup time.
> Internally all accesses to services are handled with a Filter even if the 
> service is simply retrieved with the service name without a filter. This 
> causes a considerable overhead.
> A simple improvement is to keep services not only in a global Capabitliy Set 
> accessible through generic filters but also keep such a set for each 
> registered service name.
> The measured improvement of this change is substantial: accessing these 
> 15'000 services now only takes roughly 3 seconds or 0.2 ms per service or 5 
> times faster.



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

[jira] [Commented] (FELIX-4704) Show ranking in web console services plugin

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on FELIX-4704:
--

bq. while often important

It is actually not very important that often ... But it really depends on your 
concrete use case and so YMMV (and, yes if you need it, you need it badly, also 
applies :-) )

> Show ranking in web console services plugin
> ---
>
> Key: FELIX-4704
> URL: https://issues.apache.org/jira/browse/FELIX-4704
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Reporter: Alexander Klimetschek
>Assignee: Carsten Ziegeler
>Priority: Minor
> Fix For: webconsole-4.2.6
>
> Attachments: FELIX-4704.patch, screenshot.png
>
>
> The service ranking is an important property of services and one often needs 
> to look for all implementations of a given service and sort them by their 
> ranking - to list them in the order they are used by some other component.
> Thus adding a new column to the services table that can be sorted like the 
> other ones would be really helpful. Filtering down to one service interface 
> is already possible since FELIX-4202 (e.g. {{(objectclass=*.MyService}}).



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

[jira] [Commented] (FELIX-4704) Show ranking in web console services plugin

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on FELIX-4704:
--

Ok

> Show ranking in web console services plugin
> ---
>
> Key: FELIX-4704
> URL: https://issues.apache.org/jira/browse/FELIX-4704
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Reporter: Alexander Klimetschek
>Assignee: Carsten Ziegeler
>Priority: Minor
> Fix For: webconsole-4.2.6
>
> Attachments: FELIX-4704.patch, screenshot.png
>
>
> The service ranking is an important property of services and one often needs 
> to look for all implementations of a given service and sort them by their 
> ranking - to list them in the order they are used by some other component.
> Thus adding a new column to the services table that can be sorted like the 
> other ones would be really helpful. Filtering down to one service interface 
> is already possible since FELIX-4202 (e.g. {{(objectclass=*.MyService}}).



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

[jira] [Commented] (FELIX-3773) WebConsole uses library with ASL-incompatible licence

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on FELIX-3773:
--

I like this very much. We should get started with some concepts of how to build 
the next generation Web Console and its API. We can still see how we can 
support old Web Console 3/4 plugins with some kind of a compat/bridge bundle.

As for JSON, I am really fine. As for RPC, I am more weary -- I prefer proper 
REST style. :-)

As for plugin.*: Sounds like a good approach. Since we would have .html, .css, 
and .js in most cases, we might want to define a plugin service registration 
property setting the base name where the property defaults to "plugin" if 
missing. The reason fo adding another service property is to allow for multiple 
plugins with different helper files to be embedded in a single bundle (e.g. the 
Web Console Core bundle itself).

> WebConsole uses library with ASL-incompatible licence
> -
>
> Key: FELIX-3773
> URL: https://issues.apache.org/jira/browse/FELIX-3773
> Project: Felix
>  Issue Type: Bug
>  Components: Web Console
>Affects Versions: webconsole-4.0.0
>Reporter: Neil Bartlett
>Priority: Critical
>
> WebConsole uses the JSON library from json.org that contains the following 
> term in its licence (http://www.json.org/license.html):
> "The Software shall be used for Good, not Evil."
> I believe that this restriction is incompatible with the ASL.



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

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

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on FELIX-4692:
--

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

Interestingly I just found a draft message in my inbox which comes to the exact 
same conclusion. I like your proposal of only retaining all if {{(caps != 
m_capSet)}}.

> Improve Service access time
> ---
>
> Key: FELIX-4692
> URL: https://issues.apache.org/jira/browse/FELIX-4692
> Project: Felix
>  Issue Type: Improvement
>  Components: Framework
>Affects Versions: framework-4.4.1
>Reporter: Felix Meschberger
>Assignee: Felix Meschberger
> Fix For: framework-4.6.0
>
> Attachments: FELIX-4692.diff
>
>
> Currently the ServiceRegistry takes roughly 1ms to access a single service. 
> In a reasonably large system, this may over time consume considerable time.
> For example in our inhouse system sporting roughly 5000 services with 15'000 
> service accesses during startup, these accesses acount for almost 15 seconds 
> or roughly 25-30% of the total startup time.
> Internally all accesses to services are handled with a Filter even if the 
> service is simply retrieved with the service name without a filter. This 
> causes a considerable overhead.
> A simple improvement is to keep services not only in a global Capabitliy Set 
> accessible through generic filters but also keep such a set for each 
> registered service name.
> The measured improvement of this change is substantial: accessing these 
> 15'000 services now only takes roughly 3 seconds or 0.2 ms per service or 5 
> times faster.



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

[jira] [Comment Edited] (FELIX-4704) Show ranking in web console services plugin

[Felix Meschberger (JIRA)]

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

Felix Meschberger edited comment on FELIX-4704 at 1/5/15 7:13 AM:
--

While I appreciate this patch and the importance of the service.ranking 
property, I really think the service.ranking property is not important on a 
general level. But maybe it makes sense to expose it explicitly in the list.

Regardless, I still have some issues with the simplistic approach here: First I 
don't think we should show the service.ranking in the second column even before 
the service types. Maybe the last column is more appropriate.

Second, and more subtle, though, is that the service.ranking property is not 
generally used on a global level across all services but amongst services of a 
specific type. So I doubt the general usefulness of sorting the global service 
table by the service.ranking property.

Finally, whether a certain service is actually used by a particular consumer 
depends on more than the service.ranking itself. For example the whether a 
filter has been used to select the service. Or how the Declarative Services 
@Reference is setup (static vs. dynamic policy, target filter).


was (Author: fmeschbe):
While I appreciate this patch and the importance of the service.ranking 
property, I really think the service.ranking property is not important on a 
general level. But maybe it makes sense to expose it explicitly in the list.

Regardless, I still have some issues with the simplistic approach here: First I 
don't think we should show the service.ranking in the second column even before 
the service types. Maybe the last column is more appropriate.

Second, and more subtle, though, is that the service.ranking property is not 
generally used on a global level across all services but amongst services of a 
specific type. So I doubt the general usefulness of sorting the global service 
table by the service.ranking property.

> Show ranking in web console services plugin
> ---
>
> Key: FELIX-4704
> URL: https://issues.apache.org/jira/browse/FELIX-4704
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Reporter: Alexander Klimetschek
>Assignee: Carsten Ziegeler
>Priority: Minor
> Fix For: webconsole-4.2.6
>
> Attachments: FELIX-4704.patch, screenshot.png
>
>
> The service ranking is an important property of services and one often needs 
> to look for all implementations of a given service and sort them by their 
> ranking - to list them in the order they are used by some other component.
> Thus adding a new column to the services table that can be sorted like the 
> other ones would be really helpful. Filtering down to one service interface 
> is already possible since FELIX-4202 (e.g. {{(objectclass=*.MyService}}).



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

[jira] [Commented] (FELIX-4704) Show ranking in web console services plugin

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on FELIX-4704:
--

While I appreciate this patch and the importance of the service.ranking 
property, I really think the service.ranking property is not important on a 
general level. But maybe it makes sense to expose it explicitly in the list.

Regardless, I still have some issues with the simplistic approach here: First I 
don't think we should show the service.ranking in the second column even before 
the service types. Maybe the last column is more appropriate.

Second, and more subtle, though, is that the service.ranking property is not 
generally used on a global level across all services but amongst services of a 
specific type. So I doubt the general usefulness of sorting the global service 
table by the service.ranking property.

> Show ranking in web console services plugin
> ---
>
> Key: FELIX-4704
> URL: https://issues.apache.org/jira/browse/FELIX-4704
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Reporter: Alexander Klimetschek
>Assignee: Carsten Ziegeler
>Priority: Minor
> Fix For: webconsole-4.2.6
>
> Attachments: FELIX-4704.patch, screenshot.png
>
>
> The service ranking is an important property of services and one often needs 
> to look for all implementations of a given service and sort them by their 
> ranking - to list them in the order they are used by some other component.
> Thus adding a new column to the services table that can be sorted like the 
> other ones would be really helpful. Filtering down to one service interface 
> is already possible since FELIX-4202 (e.g. {{(objectclass=*.MyService}}).



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

[jira] [Commented] (FELIX-4734) Web Console RESTful API should wait for asynchonous operations until they complete

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on FELIX-4734:
--

Please make sure to not cause deadlocks ! We had situations in the past where 
the web console bundle itself was involved in the update and refreshPackage 
operations and when not properly handling this, this may cause a deadlock !

> Web Console RESTful API should wait for asynchonous operations until they 
> complete 
> ---
>
> Key: FELIX-4734
> URL: https://issues.apache.org/jira/browse/FELIX-4734
> Project: Felix
>  Issue Type: Bug
>  Components: Web Console
>Affects Versions: webconsole-4.2.4
>Reporter: Konrad Windszus
> Attachments: FELIX-4734.patch
>
>
> Currently the RESTful API 
> (http://felix.apache.org/documentation/subprojects/apache-felix-web-console/web-console-restful-api.html)
>  adds a delay of 800ms to the response to give the asynchronous operations 
> enough time to complete successfully 
> (https://github.com/apache/felix/blob/trunk/webconsole/src/main/java/org/apache/felix/webconsole/internal/core/BundlesServlet.java#L412).
> Instead the according listeners should be used which are notified upon 
> completion of an asynchronous task.
> For {{refresh}} {{FrameworkWiring.refreshBundles}} can be used 
> (http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/wiring/FrameworkWiring.html#refreshBundles%28java.util.Collection,%20org.osgi.framework.FrameworkListener...%29).
>  A similar approach should be used for the other actions like uninstall, 
> install, update, start, stop, ...



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

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

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on FELIX-4692:
--

[~cziegeler] For the reasons stated by [~rickhall] I would not apply the patch 
yet. Looking at the code, it really *is* strange that this patch exhibits such 
a dramatic improvement. I wanted to find out, what actually is going on in the 
indexed capability set which really should have a quick (or almost as quick) 
exit as my patch.

> Improve Service access time
> ---
>
> Key: FELIX-4692
> URL: https://issues.apache.org/jira/browse/FELIX-4692
> Project: Felix
>  Issue Type: Improvement
>  Components: Framework
>Affects Versions: framework-4.4.1
>    Reporter: Felix Meschberger
>    Assignee: Felix Meschberger
> Fix For: framework-4.6.0
>
> Attachments: FELIX-4692.diff
>
>
> Currently the ServiceRegistry takes roughly 1ms to access a single service. 
> In a reasonably large system, this may over time consume considerable time.
> For example in our inhouse system sporting roughly 5000 services with 15'000 
> service accesses during startup, these accesses acount for almost 15 seconds 
> or roughly 25-30% of the total startup time.
> Internally all accesses to services are handled with a Filter even if the 
> service is simply retrieved with the service name without a filter. This 
> causes a considerable overhead.
> A simple improvement is to keep services not only in a global Capabitliy Set 
> accessible through generic filters but also keep such a set for each 
> registered service name.
> The measured improvement of this change is substantial: accessing these 
> 15'000 services now only takes roughly 3 seconds or 0.2 ms per service or 5 
> times faster.



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

Re: [VOTE RESULT] Release Apache Felix Web Console 4.2.4

[Felix Meschberger]

… and updated dist in Rev. 7398

Regards
Felix

> Am 12.12.2014 um 17:01 schrieb Felix Meschberger :
> 
> Hi
> 
> I have released the Maven Repository and am now updating dist
> 
> Regards
> Felix
> 
>> Am 12.12.2014 um 16:30 schrieb Valentin Valchev :
>> 
>> The vote passes with four binding +1 votes.
>> 
>> Thank you all.
>> 
>> Now I had to publish the staging repository. But I'm not a PMC member,
>> so I would kindly ask you if somebody can publish the new release?
>> 
>> Regards,
>> Valentin
>> 
>>> On 10/12/2014 16:35, David Bosschaert wrote:
>>> +1
>>> 
>>> David
>>> 
>>> On 10 December 2014 at 14:26, Clement Escoffier
>>>  wrote:
>>> +1,
>>> 
>>> Regards,
>>> 
>>> Clement
>>> 
>>> On 10 décembre 2014 at 14:58:11, Carsten Ziegeler
>> (cziege...@apache.org) wrote:
>>> 
>>> +1
>>> 
>>> Carsten
>>> On 11/12/2014 22:41, Pierre De Rop wrote:
>>> Hi Valentin;
>>> 
>>> +1
>>> 
>>> regards;
>>> /Pierre
>> 
>> -- 
>> 
>> -
>> Valentin Valchev · Lead Software Engineer
>> ProSyst Labs EOOD
>> 1606 Sofia, Bulgaria · 48 Vladajska Str.
>> Tel. +359 (0)2 952 35 81; Fax +359 (0)2 953 26 17
>> http://www.prosyst.com · v.valc...@prosyst.bg
>> -
>> stay in touch with your product.
>> -
>> 
>> 
> 

Re: [VOTE RESULT] Release Apache Felix Web Console 4.2.4

[Felix Meschberger]

Hi

I have released the Maven Repository and am now updating dist

Regards
Felix

> Am 12.12.2014 um 16:30 schrieb Valentin Valchev :
> 
> The vote passes with four binding +1 votes.
> 
> Thank you all.
> 
> Now I had to publish the staging repository. But I'm not a PMC member,
> so I would kindly ask you if somebody can publish the new release?
> 
> Regards,
> Valentin
> 
>> On 10/12/2014 16:35, David Bosschaert wrote:
>> +1
>> 
>> David
>> 
>> On 10 December 2014 at 14:26, Clement Escoffier
>>  wrote:
>> +1,
>> 
>> Regards,
>> 
>> Clement
>> 
>> On 10 décembre 2014 at 14:58:11, Carsten Ziegeler
> (cziege...@apache.org) wrote:
>> 
>> +1
>> 
>> Carsten
>> On 11/12/2014 22:41, Pierre De Rop wrote:
>> Hi Valentin;
>> 
>> +1
>> 
>> regards;
>> /Pierre
> 
> -- 
> 
> -
> Valentin Valchev · Lead Software Engineer
> ProSyst Labs EOOD
> 1606 Sofia, Bulgaria · 48 Vladajska Str.
> Tel. +359 (0)2 952 35 81; Fax +359 (0)2 953 26 17
> http://www.prosyst.com · v.valc...@prosyst.bg
> -
> stay in touch with your product.
> -
> 
> 

[jira] [Resolved] (FELIX-4730) RequestDispatcher's servletPath is wrong for the root servlet

[Felix Meschberger (JIRA)]

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

Felix Meschberger resolved FELIX-4730.
--
   Resolution: Fixed
Fix Version/s: http-2.4.0

Fixed in Rev. 1644885 by applying using the empty string as the servlet path if 
the alias denotes the root servlet -- this is the same logic as in 
ServletHandlerRequest.getServletPath

> RequestDispatcher's servletPath is wrong for the root servlet
> -
>
> Key: FELIX-4730
> URL: https://issues.apache.org/jira/browse/FELIX-4730
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Affects Versions: http-2.3.2
>Reporter: Felix Meschberger
>    Assignee: Felix Meschberger
> Fix For: http-2.4.0
>
>
> ServletHandler.RequestDispatcherImpl uses the servlet alias unmodified as the 
> servlet path for forwarded requests. In case of the root servlet resgistered 
> with "/", this should actually be converted to the empty string according to 
> the specification of ServletRequest.getServletPath().



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

[jira] [Created] (FELIX-4730) RequestDispatcher's servletPath is wrong for the root servlet

[Felix Meschberger (JIRA)]

Felix Meschberger created FELIX-4730:


 Summary: RequestDispatcher's servletPath is wrong for the root 
servlet
 Key: FELIX-4730
 URL: https://issues.apache.org/jira/browse/FELIX-4730
 Project: Felix
  Issue Type: Bug
  Components: HTTP Service
Affects Versions: http-2.3.2
Reporter: Felix Meschberger
Assignee: Felix Meschberger


ServletHandler.RequestDispatcherImpl uses the servlet alias unmodified as the 
servlet path for forwarded requests. In case of the root servlet resgistered 
with "/", this should actually be converted to the empty string according to 
the specification of ServletRequest.getServletPath().



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

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on FELIX-4720:
--

Somehow I have the impression, that yes, the Web Console (or Gogo for that 
matter) should not do what [~pkriens] proposes because its none its/their 
business.

On the other hand, from a practical and problem solving point of view, I agree 
with Peter that these tools should go to some length to help solving problems. 
I think the Web Console and Gogo stand special in the landscape of OSGi bundles 
in that they are tools for application administrators. As such they should do 
the best they can to support those (sometimes) poor guys.

So, yes, lets build a simple circular buffer of log messages in the Web Console 
and Gogo:

  * Create a new administrative log support bundle
  * Inherit the LogServlet from  Web Console core
  * Inherit logging support commands from Gogo Command (Basic class)
  * Dynamic package imports to Web Console and Gogo API (as needed)
  * Can be deployed very early independently of Web Console proper and Gogo to 
start collecting logs
  * Maintains its own log entries which have weak references to the Throwables
  * Gathers the entries in a circular buffer of configurable size

WDYT ?

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

Re: felix webconsole: human-readable factory config entry labels

[Felix Meschberger]

Hi


> Am 09.12.2014 um 15:57 schrieb Carsten Ziegeler :
> 
> I think we don't need to support 1.4 with the web console anymore.
> I guess we could directly go at least to Java 6, but Java 5 is imho
> definitely fine.

Careful !

AFAICT there are users of the WebConsole bound to 1.4 due to Java ME. We have 
discussed going Java 5 with WebConsole before and we went to great work to 
stick with Java 1.4 for that exact reason.

This issue might be smaller going forward, but I would expect it to take some 
time until Java 1.4 is reasonably replaced by Java 8 minimum.

Regards
Felix


> 
> I like your idea as the current rendering is really ugly and not really
> user friendly.
> 
> Carsten
> 
> Am 04.12.14 um 23:57 schrieb Stefan Seifert:
>> some days ago i submitted a patch to have better readable labels for factory 
>> configuration entries in felix console - instead of the GUIDs which require 
>> to click on every single item if you search for a specific entry.
>> 
>> see [1] for details and a screenshot what i'm pointing at.
>> 
>> WDYT of such a solution?
>> 
>> the provided patch will need some polishing, but i think this is a very 
>> important enhancement of configuration usability in the console. if you 
>> agree I would finalize the patch. if we can at least update to JDK 1.5 the 
>> patch could be simplified.
>> 
>> stefan
>> 
>> [1] https://issues.apache.org/jira/browse/FELIX-4710
>> 
>> 
> 
> 
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: Apache Felix release tags not showing in git mirrors

[Felix Meschberger]

Hi

Sounds reasonable to me.

But I read „redo the entire mirror“: What is the consequence of a such redoing 
for existing clones ?

Thanks
Felix

> Am 28.11.2014 um 01:42 schrieb Jean-Baptiste Onofré :
> 
> +1 as well
> 
> Regards
> JB
> 
> On 11/28/2014 01:31 AM, Freeman Fang wrote:
>> +1
>> 
>> Get the released tag into Git mirrors is really convenient, the proposal 
>> there sounds good to me.
>> －
>> Freeman(Yue) Fang
>> 
>> Red Hat, Inc.
>> FuseSource is now part of Red Hat
>> 
>> 
>> 
>> On 2014-11-14, at 下午10:25, Jon Anstey wrote:
>> 
>>> Hi all,
>>> 
>>> Felix release tags are not showing up in any of the Git mirrors. I opened
>>> https://issues.apache.org/jira/browse/INFRA-8592 to address this. Is
>>> everyone OK with the change infra is proposing?
>>> 
>>> --
>>> Cheers,
>>> Jon
>>> ---
>>> Red Hat, Inc.
>>> Email: jans...@redhat.com
>>> Web: http://redhat.com
>>> Twitter: jon_anstey
>>> Blog: http://janstey.blogspot.com
>>> Author of Camel in Action: http://manning.com/ibsen
>> 
>> 
> 
> -- 
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: Framework compilation problems

[Felix Meschberger]

Hi

I have reported FELIX-4695 [1] with two potential patches. I think the Felix 
class patch is correct, while the ExtensionManager patch is probably sufficient 
for this problem.

I would prefer to patch the Felix class at the expense of the 
org.osgi.framework.os.version property not exposing the correct version.

Maybe we can improve the normalizeOsVersion method to be a bit more intelligent 
like the DefaultMaven2OsgiConverter of the Maven Bundle Plugin does. See 
FELIX-4696 [2] for a proposed patch.

WDYT ?

Regards
Felix

[1] https://issues.apache.org/jira/browse/FELIX-4695
[2] https://issues.apache.org/jira/browse/FELIX-4696

> Am 13.11.2014 um 11:42 schrieb Felix Meschberger :
> 
> Hi
> 
> Ok, there seems to be a larger problem to this, it seems.
> 
> The ExtensionManager creates native capabilities in the 
> ExtensionManager.buildNativeCapabilites() method. This method gets the 
> PROCESSOR, OS_NAME, and OS_VERSION framework properties to build this 
> capability.
> 
> On the other hand the R4LibraryClause.match(Map) method uses these same 
> properties but before using them applies normalisation to them using its own 
> R4LibraryClause.normalize* methods.
> 
> Applying this normalisation to the ExtensionManager.buildNativeCapabilities() 
> method actually „solves“ the problem.
> 
> Now, I wonder, whether we should actually only have the normalised values in 
> the framework properties ?
> 
> WDYT ?
> 
> Regards
> Felix
> 
>> Am 13.11.2014 um 10:03 schrieb Felix Meschberger :
>> 
>> Hi
>> 
>> I can reproduce this. And worse still, it actually prevents the framework 
>> from starting under Linux.
>> 
>> The situation is that the ExtensionManager wants to parse the os.version 
>> system property into an OSGi Version. the os.version seems to be based on 
>> the kernel version, which in my case of Ubuntu 14.04.1 LTS is 
>> 3.13.0-39-generic and is not a valid OSGi version string.
>> 
>> In your case I would assume the error message is indicating 
>> 3.14.22-100.fc19.i686.PAE is not valid.
>> 
>> Looks like the os.version system property needs some cleansing before 
>> supplying it to the Version constructor.
>> 
>> Regards
>> Felix
>> 
>>> Am 13.11.2014 um 01:57 schrieb David Bosschaert 
>>> :
>>> 
>>> Hi Pierre,
>>> 
>>> I don't see your attachment with the errors. Did you forget to attach it?
>>> 
>>> Cheers,
>>> 
>>> David
>>> 
>>> On 12 November 2014 13:49, Pierre De Rop  wrote:
>>>> Hello everyone;
>>>> 
>>>> I would like to test the patch provided by Felix for the FELIX-4692 issue
>>>> ("Improve Service access time").
>>>> But before applying the patch provided by Felix, I just can't compile the
>>>> framework (the tests does not seem to compile):
>>>> 
>>>> I'm on a linux fc19,
>>>> uname -a = Linux nx0012 3.14.22-100.fc19.i686.PAE #1 SMP Wed Oct 15 
>>>> 13:06:27
>>>> UTC 2014 i686 i686 i386 GNU/Linux
>>>> and my jdk is "1.7.0_67":
>>>> 
>>>> I have attached the compile errors I'm having. it looks like there is a
>>>> problem with my framework os version (with the jvm
>>>> org.osgi.framework.os.version system property). But I tried to compile on
>>>> another linux box and I'm having the same kind of errors.
>>>> 
>>>> can anyone please take a look ?
>>>> 
>>>> thanks;
>>>> 
>>>> kind regards
>>>> /Pierre
>>>> 
>>>> 
>>>> 
>>>> 
>> 
> 

[jira] [Updated] (FELIX-4696) Improve native OS version sanitation

[Felix Meschberger (JIRA)]

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

Felix Meschberger updated FELIX-4696:
-
Attachment: FELIX-4696.patch

Proposed patch taking code from the DefaultMaven2OsgiConverter class of the 
Bundle Maven Plugin.

> Improve native OS version sanitation
> 
>
> Key: FELIX-4696
> URL: https://issues.apache.org/jira/browse/FELIX-4696
> Project: Felix
>  Issue Type: Improvement
>  Components: Framework
>Affects Versions: framework-4.4.1
>    Reporter: Felix Meschberger
>    Assignee: Felix Meschberger
> Fix For: framework-4.6.0
>
> Attachments: FELIX-4696.patch
>
>
> The Native OS version sanitation currently simply tries to parse the native 
> OS version and if failing falls back to 0.0.0.
> I think it would be better to actually properly sanitize the version similar 
> to what the DefaultMaven2OsgiConverter class of the Bundle Maven Plugin does.
> So for example, a FC9 version of "3.14.22-100.fc19.i686.PAE" would then be 
> converted to "3.14.22.100_fc19_i686_PAE" which is much more suited to real 
> world use.



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

[jira] [Created] (FELIX-4696) Improve native OS version sanitation

[Felix Meschberger (JIRA)]

Felix Meschberger created FELIX-4696:


 Summary: Improve native OS version sanitation
 Key: FELIX-4696
 URL: https://issues.apache.org/jira/browse/FELIX-4696
 Project: Felix
  Issue Type: Improvement
  Components: Framework
Affects Versions: framework-4.4.1
Reporter: Felix Meschberger
Assignee: Felix Meschberger
 Fix For: framework-4.6.0


The Native OS version sanitation currently simply tries to parse the native OS 
version and if failing falls back to 0.0.0.

I think it would be better to actually properly sanitize the version similar to 
what the DefaultMaven2OsgiConverter class of the Bundle Maven Plugin does.

So for example, a FC9 version of "3.14.22-100.fc19.i686.PAE" would then be 
converted to "3.14.22.100_fc19_i686_PAE" which is much more suited to real 
world use.



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

[jira] [Updated] (FELIX-4695) Normalize os.version system property in framework properties

[Felix Meschberger (JIRA)]

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

Felix Meschberger updated FELIX-4695:
-
Attachment: FELIX-4695-Felix.patch
FELIX-4695-ExtensionManager.patch

Two mutually "exclusive" patches:

One against the Felix class causing the org.osgi.framework.os.version property 
to be a valid Version value string. This would be in line of my reading section 
4.2.2, Launching Propertes, of OSGi Core R6:

bq. The version of the operating system as used in the native code clause. If 
not set, then the framework must provide a default value. If the operating 
system reported version does not fit the standard version syntax (e.g. 
2.4.32-kwt), then the launcher should define this launching property with a 
valid version value.

The other patch is against the ExtensionManager building the native 
capabilities. This would ensure the native capability property is a valid 
version.

Looking at cited section 4.2.2, I would probably prefer the patch against the 
Felix class to ensure the framework properties contain a valid OSGi Version 
string.

WDYT ?

> Normalize os.version system property in framework properties
> 
>
> Key: FELIX-4695
> URL: https://issues.apache.org/jira/browse/FELIX-4695
> Project: Felix
>  Issue Type: Bug
>  Components: Framework
>Affects Versions: framework-4.4.1
>Reporter: Felix Meschberger
>Assignee: Felix Meschberger
> Fix For: framework-4.6.0
>
> Attachments: FELIX-4695-ExtensionManager.patch, FELIX-4695-Felix.patch
>
>
> The Felix class currently normalizes the processor name and os name system 
> property before putting it into the framework properties.
> Likewise the os version system property should be normalized as well.
> Symptom of not normalizing the os version is the 
> ExtensionManager.buildNativeCapabilites method failing to create the os 
> version.
> Alternatively, the ExtensionManager.buildNativeCapabilites method could 
> itself normalize the os.version framework property. This would prevent the 
> method from failing and would still allow the R4LibraryClause to match an os 
> version capability (R4LlibraryClause does normalize the os version in the 
> clause of the bundle before matching).



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

[jira] [Created] (FELIX-4695) Normalize os.version system property in framework properties

[Felix Meschberger (JIRA)]

Felix Meschberger created FELIX-4695:


 Summary: Normalize os.version system property in framework 
properties
 Key: FELIX-4695
 URL: https://issues.apache.org/jira/browse/FELIX-4695
 Project: Felix
  Issue Type: Bug
  Components: Framework
Affects Versions: framework-4.4.1
Reporter: Felix Meschberger
Assignee: Felix Meschberger
 Fix For: framework-4.6.0


The Felix class currently normalizes the processor name and os name system 
property before putting it into the framework properties.

Likewise the os version system property should be normalized as well.

Symptom of not normalizing the os version is the 
ExtensionManager.buildNativeCapabilites method failing to create the os version.

Alternatively, the ExtensionManager.buildNativeCapabilites method could itself 
normalize the os.version framework property. This would prevent the method from 
failing and would still allow the R4LibraryClause to match an os version 
capability (R4LlibraryClause does normalize the os version in the clause of the 
bundle before matching).



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

Re: Framework compilation problems

[Felix Meschberger]

Hi

Ok, there seems to be a larger problem to this, it seems.

The ExtensionManager creates native capabilities in the 
ExtensionManager.buildNativeCapabilites() method. This method gets the 
PROCESSOR, OS_NAME, and OS_VERSION framework properties to build this 
capability.

On the other hand the R4LibraryClause.match(Map) method uses these same 
properties but before using them applies normalisation to them using its own 
R4LibraryClause.normalize* methods.

Applying this normalisation to the ExtensionManager.buildNativeCapabilities() 
method actually „solves“ the problem.

Now, I wonder, whether we should actually only have the normalised values in 
the framework properties ?

WDYT ?

Regards
Felix

> Am 13.11.2014 um 10:03 schrieb Felix Meschberger :
> 
> Hi
> 
> I can reproduce this. And worse still, it actually prevents the framework 
> from starting under Linux.
> 
> The situation is that the ExtensionManager wants to parse the os.version 
> system property into an OSGi Version. the os.version seems to be based on the 
> kernel version, which in my case of Ubuntu 14.04.1 LTS is 3.13.0-39-generic 
> and is not a valid OSGi version string.
> 
> In your case I would assume the error message is indicating 
> 3.14.22-100.fc19.i686.PAE is not valid.
> 
> Looks like the os.version system property needs some cleansing before 
> supplying it to the Version constructor.
> 
> Regards
> Felix
> 
>> Am 13.11.2014 um 01:57 schrieb David Bosschaert :
>> 
>> Hi Pierre,
>> 
>> I don't see your attachment with the errors. Did you forget to attach it?
>> 
>> Cheers,
>> 
>> David
>> 
>> On 12 November 2014 13:49, Pierre De Rop  wrote:
>>> Hello everyone;
>>> 
>>> I would like to test the patch provided by Felix for the FELIX-4692 issue
>>> ("Improve Service access time").
>>> But before applying the patch provided by Felix, I just can't compile the
>>> framework (the tests does not seem to compile):
>>> 
>>> I'm on a linux fc19,
>>> uname -a = Linux nx0012 3.14.22-100.fc19.i686.PAE #1 SMP Wed Oct 15 13:06:27
>>> UTC 2014 i686 i686 i386 GNU/Linux
>>> and my jdk is "1.7.0_67":
>>> 
>>> I have attached the compile errors I'm having. it looks like there is a
>>> problem with my framework os version (with the jvm
>>> org.osgi.framework.os.version system property). But I tried to compile on
>>> another linux box and I'm having the same kind of errors.
>>> 
>>> can anyone please take a look ?
>>> 
>>> thanks;
>>> 
>>> kind regards
>>> /Pierre
>>> 
>>> 
>>> 
>>> 
> 

Re: Framework compilation problems

[Felix Meschberger]

Hi

I can reproduce this. And worse still, it actually prevents the framework from 
starting under Linux.

The situation is that the ExtensionManager wants to parse the os.version system 
property into an OSGi Version. the os.version seems to be based on the kernel 
version, which in my case of Ubuntu 14.04.1 LTS is 3.13.0-39-generic and is not 
a valid OSGi version string.

In your case I would assume the error message is indicating 
3.14.22-100.fc19.i686.PAE is not valid.

Looks like the os.version system property needs some cleansing before supplying 
it to the Version constructor.

Regards
Felix

> Am 13.11.2014 um 01:57 schrieb David Bosschaert :
> 
> Hi Pierre,
> 
> I don't see your attachment with the errors. Did you forget to attach it?
> 
> Cheers,
> 
> David
> 
> On 12 November 2014 13:49, Pierre De Rop  wrote:
>> Hello everyone;
>> 
>> I would like to test the patch provided by Felix for the FELIX-4692 issue
>> ("Improve Service access time").
>> But before applying the patch provided by Felix, I just can't compile the
>> framework (the tests does not seem to compile):
>> 
>> I'm on a linux fc19,
>> uname -a = Linux nx0012 3.14.22-100.fc19.i686.PAE #1 SMP Wed Oct 15 13:06:27
>> UTC 2014 i686 i686 i386 GNU/Linux
>> and my jdk is "1.7.0_67":
>> 
>> I have attached the compile errors I'm having. it looks like there is a
>> problem with my framework os version (with the jvm
>> org.osgi.framework.os.version system property). But I tried to compile on
>> another linux box and I'm having the same kind of errors.
>> 
>> can anyone please take a look ?
>> 
>> thanks;
>> 
>> kind regards
>> /Pierre
>> 
>> 
>> 
>> 

Improve Service Access (FELIX-4692)

[Felix Meschberger]

Hi

I have created a patch to improve the Service Access time. With this patch 
applied I measure 4-5 times faster access to the service registry in our 
application which in general access services simply by its name and almost 
never uses a filter.

I expect that this patch also significantly improves service access if both a 
filter and a service name is supplied. I expect no change if no service name is 
supplied, though, since then the complete service registry has to be searched.

See issue FELIX-4692.

It would be great if this patch could be quickly reviewed before I actually 
apply it.

Thanks
Felix

[1] https://issues.apache.org/jira/browse/FELIX-4692

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

[Felix Meschberger (JIRA)]

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

Felix Meschberger updated FELIX-4692:
-
Attachment: FELIX-4692.diff

Patch with the proposed change.

> Improve Service access time
> ---
>
> Key: FELIX-4692
> URL: https://issues.apache.org/jira/browse/FELIX-4692
> Project: Felix
>  Issue Type: Improvement
>  Components: Framework
>Affects Versions: framework-4.4.1
>    Reporter: Felix Meschberger
>    Assignee: Felix Meschberger
> Fix For: framework-4.6.0
>
> Attachments: FELIX-4692.diff
>
>
> Currently the ServiceRegistry takes roughly 1ms to access a single service. 
> In a reasonably large system, this may over time consume considerable time.
> For example in our inhouse system sporting roughly 5000 services with 15'000 
> service accesses during startup, these accesses acount for almost 15 seconds 
> or roughly 25-30% of the total startup time.
> Internally all accesses to services are handled with a Filter even if the 
> service is simply retrieved with the service name without a filter. This 
> causes a considerable overhead.
> A simple improvement is to keep services not only in a global Capabitliy Set 
> accessible through generic filters but also keep such a set for each 
> registered service name.
> The measured improvement of this change is substantial: accessing these 
> 15'000 services now only takes roughly 3 seconds or 0.2 ms per service or 5 
> times faster.



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

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

[Felix Meschberger (JIRA)]

Felix Meschberger created FELIX-4692:


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


Currently the ServiceRegistry takes roughly 1ms to access a single service. In 
a reasonably large system, this may over time consume considerable time.

For example in our inhouse system sporting roughly 5000 services with 15'000 
service accesses during startup, these accesses acount for almost 15 seconds or 
roughly 25-30% of the total startup time.

Internally all accesses to services are handled with a Filter even if the 
service is simply retrieved with the service name without a filter. This causes 
a considerable overhead.

A simple improvement is to keep services not only in a global Capabitliy Set 
accessible through generic filters but also keep such a set for each registered 
service name.

The measured improvement of this change is substantial: accessing these 15'000 
services now only takes roughly 3 seconds or 0.2 ms per service or 5 times 
faster.



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

[jira] [Resolved] (FELIX-4674) Allow inclusion/exclusion of protocols in SSL connector

[Felix Meschberger (JIRA)]

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

Felix Meschberger resolved FELIX-4674.
--
   Resolution: Fixed
Fix Version/s: http-2.3.2

Thanks for providing the patch. I have applied it somewhat extended in Rev. 
1633120

The extension is to additionally support the included protocols for 
whitelisting and to add some more explanations to the property descriptions.

> Allow inclusion/exclusion of protocols in SSL connector
> ---
>
> Key: FELIX-4674
> URL: https://issues.apache.org/jira/browse/FELIX-4674
> Project: Felix
>  Issue Type: Improvement
>  Components: HTTP Service
>Affects Versions: http-2.3.0
>Reporter: Dominique Pfister
>    Assignee: Felix Meschberger
> Fix For: http-2.3.2
>
> Attachments: patch.txt
>
>
> With the recent security attack discovered called "POODLE" [1], it would be 
> great to make the set of SSL protocols Jetty accepts configurable through 
> OSGI. I suggest to introduce a string array property containing the list of 
> protocols to disable, e.g. [ "SSLv3" ].
> [1] https://zmap.io/sslv3/



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

[jira] [Assigned] (FELIX-4674) Allow inclusion/exclusion of protocols in SSL connector

[Felix Meschberger (JIRA)]

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

Felix Meschberger reassigned FELIX-4674:


Assignee: Felix Meschberger

> Allow inclusion/exclusion of protocols in SSL connector
> ---
>
> Key: FELIX-4674
> URL: https://issues.apache.org/jira/browse/FELIX-4674
> Project: Felix
>  Issue Type: Improvement
>  Components: HTTP Service
>Affects Versions: http-2.3.0
>Reporter: Dominique Pfister
>    Assignee: Felix Meschberger
> Attachments: patch.txt
>
>
> With the recent security attack discovered called "POODLE" [1], it would be 
> great to make the set of SSL protocols Jetty accepts configurable through 
> OSGI. I suggest to introduce a string array property containing the list of 
> protocols to disable, e.g. [ "SSLv3" ].
> [1] https://zmap.io/sslv3/



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

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

[Felix Meschberger]

Welcome to the team, Bob !

Regards
Felix

Am 17.10.2014 um 11:00 schrieb Carsten Ziegeler :

> 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] [Resolved] (FELIX-4664) [SSLFilter] Support for pre-3.0 Servlet API

[Felix Meschberger (JIRA)]

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

Felix Meschberger resolved FELIX-4664.
--
   Resolution: Fixed
Fix Version/s: http-sslfilter-0.2.0
   http-2.3.2
 Assignee: Felix Meschberger

Applied the patch in Rev. 1629609

> [SSLFilter] Support for pre-3.0 Servlet API
> ---
>
> Key: FELIX-4664
> URL: https://issues.apache.org/jira/browse/FELIX-4664
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Affects Versions: http-2.3.0, http-sslfilter-0.1.0
>    Reporter: Felix Meschberger
>    Assignee: Felix Meschberger
> Fix For: http-2.3.2, http-sslfilter-0.2.0
>
> Attachments: FELIX-4664.patch
>
>
> The SSL Filter bundle currently inherits the Servlet API dependency from the 
> parent project which sets it to Servlet API 3.0. 
> Actually, the filter itself does not depend at all on Servlet API 3.0 and the 
> dependency should probably be fixed to a reduced version number -- maybe even 
> the lowest version still compiling...
> There is one caveat: unit tests currently use HttpServletResponse.getHeader 
> method which has been introduced with Servlet API 3.0. So the tests need to 
> be tweaked.



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

[jira] [Updated] (FELIX-4664) [SSLFilter] Support for pre-3.0 Servlet API

[Felix Meschberger (JIRA)]

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

Felix Meschberger updated FELIX-4664:
-
Attachment: FELIX-4664.patch

Proposed patch.

> [SSLFilter] Support for pre-3.0 Servlet API
> ---
>
> Key: FELIX-4664
> URL: https://issues.apache.org/jira/browse/FELIX-4664
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Affects Versions: http-2.3.0, http-sslfilter-0.1.0
>    Reporter: Felix Meschberger
> Attachments: FELIX-4664.patch
>
>
> The SSL Filter bundle currently inherits the Servlet API dependency from the 
> parent project which sets it to Servlet API 3.0. 
> Actually, the filter itself does not depend at all on Servlet API 3.0 and the 
> dependency should probably be fixed to a reduced version number -- maybe even 
> the lowest version still compiling...
> There is one caveat: unit tests currently use HttpServletResponse.getHeader 
> method which has been introduced with Servlet API 3.0. So the tests need to 
> be tweaked.



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

[jira] [Created] (FELIX-4664) [SSLFilter] Support for pre-3.0 Servlet API

[Felix Meschberger (JIRA)]

Felix Meschberger created FELIX-4664:


 Summary: [SSLFilter] Support for pre-3.0 Servlet API
 Key: FELIX-4664
 URL: https://issues.apache.org/jira/browse/FELIX-4664
 Project: Felix
  Issue Type: Bug
  Components: HTTP Service
Affects Versions: http-sslfilter-0.1.0, http-2.3.0
Reporter: Felix Meschberger


The SSL Filter bundle currently inherits the Servlet API dependency from the 
parent project which sets it to Servlet API 3.0. 

Actually, the filter itself does not depend at all on Servlet API 3.0 and the 
dependency should probably be fixed to a reduced version number -- maybe even 
the lowest version still compiling...

There is one caveat: unit tests currently use HttpServletResponse.getHeader 
method which has been introduced with Servlet API 3.0. So the tests need to be 
tweaked.



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

Re: [FELIX-3693] HTTP SSLFilter

[Felix Meschberger]

Yes.

Regards
Felix

Am 29.09.2014 um 12:07 schrieb Antonio Sanso :

> thanks Felix . So IIUC the logic is based on the presence of the 
> X-Forwarded-Port header right :))?
> 
> regards
> 
> antonio
> 
> On Sep 29, 2014, at 11:47 AM, Antonio Sanso 
> mailto:asa...@adobe.com>> wrote:
> 
> (sorry I am not subscribed to the list)
> 
> the configuration options proposed by Jan is a good solution IMHO.
> 
> regards
> 
> antonio
> 
> On Sep 29, 2014, at 10:54 AM, Antonio Sanso 
> mailto:asa...@adobe.com>> wrote:
> 
> hi *,
> 
> looking at [FELIX-3693] HTTP SSLFilter [0] specially at the SslFilterRequest 
> it looks to me that the final Request object might end up having this weird 
> behavior:
> 
> - request.getScheme() ==> https
> - request.getServerPort() ==> 80
> 
> and possibly
> 
> - request.getRequestURL() ==> https://domain.80/active.html
> 
> IMHO having a scheme https with a port 80 might lead to some inconsistencies 
> . WDYT?
> 
> regards
> 
> antonio
> 
> [0] https://issues.apache.org/jira/browse/FELIX-4420
> 
> 

Re: [FELIX-3693] HTTP SSLFilter

[Felix Meschberger]

Hi

Am 29.09.2014 um 11:47 schrieb Antonio Sanso :

> (sorry I am not subscribed to the list)

You should be subscribing :-)

> 
> the configuration options proposed by Jan is a good solution IMHO.

Look at how we do it in the SslFilterResponse class. The 
SslFilterRequest.getServerPort should (must?) apply the same logic.

Regards
Felix

> 
> regards
> 
> antonio
> 
> On Sep 29, 2014, at 10:54 AM, Antonio Sanso 
> mailto:asa...@adobe.com>> wrote:
> 
> hi *,
> 
> looking at [FELIX-3693] HTTP SSLFilter [0] specially at the SslFilterRequest 
> it looks to me that the final Request object might end up having this weird 
> behavior:
> 
> - request.getScheme() ==> https
> - request.getServerPort() ==> 80
> 
> and possibly
> 
> - request.getRequestURL() ==> https://domain.80/active.html
> 
> IMHO having a scheme https with a port 80 might lead to some inconsistencies 
> . WDYT?
> 
> regards
> 
> antonio
> 
> [0] https://issues.apache.org/jira/browse/FELIX-4420
> 

Re: [FELIX-3693] HTTP SSLFilter

[Felix Meschberger]

Hi

Am 29.09.2014 um 11:34 schrieb Jan Willem Janssen 
:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 29/09/14 11:25, Felix Meschberger wrote:
>> While you are technically correct, the request.getServerPort()
>> should really reflect the port that the actual SSL terminating
>> server is running on.
>> 
>> If this is the default port (getServerPort may return -1) this
>> would still be 443 and not 80. So it should probably be checked
>> that we get the SSL terminator’s port right. And this is really the
>> bug: The current SslFilterRequest implementation does not implement
>> the getServerPort method to ensure this.
> 
> Still, this is all based on heuristics: the code assumes the SSL
> terminating server runs on the default https port.
> 
> Wouldn't it make a lot more sense to make the SslFilter configurable
> wrt what ports it should rewrite? While it requires explicit
> configuration, it makes the code a lot simpler and less bug-prone?

Actually we do port calculation in the response for the sendRedirect support. 
We should probably apply the same algorithm for the getServerPort method.

Regards
Felix


> 
> - -- 
> Met vriendelijke groeten | Kind regards
> 
> Jan Willem Janssen | Software Architect
> +31 631 765 814
> 
> /My world is revolving around INAETICS and Amdatu/
> 
> Luminis Technologies B.V.
> Churchillplein 1
> 7314 BZ   Apeldoorn
> +31 88 586 46 00
> 
> 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.22 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> 
> iQIcBAEBAgAGBQJUKSeWAAoJEKF/mP2eHDc4+NIP/1DMT+7FZLLx8VDQAqxpRdFi
> 2t6fAaDR+a+0UeH0vCFgMtgMmIhdJJGUhYeIo979RNuIr7k10zhnmHVPHTx7fgGq
> 9kOkooD1Yw0aGBdrfxtekiUxrAXgS2zm6m1UxS+Tp3tNdwd1kNTJgUnhjFrhtnBv
> /hlaO1Qg7Eu0p9GvKZhbaa3AN1ZGmEmEgpDttNCsJzoYM9LG2gZ8FgAKh58Ojo6D
> 7va7kCa0RivLjGkoagdMM6LuSe7vTwl+yhzRgf6FjXxcHgRyTWyWPf5iqO7rVOFo
> zauQ1Rh3UJTB7dq8j2CCWA5b4KJnfgXK8mo0O0zDnHVRNETdGlDZu3KMPexwNjrC
> d03TtbiLZGx7XZA4x8jEWDeGMxMCg+pWa8VX59BNKq/JmxDgHfj+Pv8YSjuD3htT
> kUw5RNzCBM2SjLupCLqQKU5E5VQpaxjMAcpvGz/JaaamsEh5C7tdWIDuKFW1f2iS
> DWJ/alhE/xrF0wcQyZt+fdBeNA6vsIZ3CI26C+LPoUe4bc20fQMdUFbMtJDYNkqN
> kL0/TrKC5OkoLrgRCLqzg4r0RNQZbfA5wP7P784JfjXZclTUPIWeuyzaP0bodtt/
> 9AjawZvYcuGQBkHZMUUWr4QUJKffNosRVcwJzrBKFA/O2fAQZ7LIv0xaEAaMrxy2
> Xk/TaAfkzzrIgT8idD48
> =lRNe
> -END PGP SIGNATURE-

Re: [FELIX-3693] HTTP SSLFilter

[Felix Meschberger]

Hi

While you are technically correct, the request.getServerPort() should really 
reflect the port that the actual SSL terminating server is running on.

If this is the default port (getServerPort may return -1) this would still be 
443 and not 80. So it should probably be checked that we get the SSL 
terminator’s port right. And this is really the bug: The current 
SslFilterRequest implementation does not implement the getServerPort method to 
ensure this.

Regards
Felix

Am 29.09.2014 um 11:16 schrieb Jan Willem Janssen 
mailto:janwillem.jans...@luminis.eu>>:

Signierter PGP Teil
On 29/09/14 10:59, Felix Meschberger wrote:
> Hi Antonio,
>
> I agree this is a bug.
>
>>
>> looking at [FELIX-3693] HTTP SSLFilter [0] specially at the
>> SslFilterRequest it looks to me that the final Request object
>> might end up having this weird behavior:
>>
>> - request.getScheme() ==> https - request.getServerPort() ==> 80
>>
>> and possibly
>>
>> - request.getRequestURL() ==> https://domain.80/active.html
>>
>> IMHO having a scheme https with a port 80 might lead to some
>> inconsistencies . WDYT?

I'm less inclined to immediately state this as a bug. Though it is by
convention to use port 443 for secure HTTP, actually nothing prevents
me from using port 80 instead for secure HTTP.

--
Met vriendelijke groeten | Kind regards

Jan Willem Janssen | Software Architect
+31 631 765 814

/My world is revolving around INAETICS and Amdatu/

Luminis Technologies B.V.
Churchillplein 1
7314 BZ   Apeldoorn
+31 88 586 46 00

http://www.luminis-technologies.com
http://www.luminis.eu

KvK (CoC) 09 16 28 93
BTW (VAT) NL8169.78.566.B.01

Re: [FELIX-3693] HTTP SSLFilter

[Felix Meschberger]

Hi Antonio,

I agree this is a bug.

Regards
Felix

Am 29.09.2014 um 10:54 schrieb Antonio Sanso :

> hi *,
> 
> looking at [FELIX-3693] HTTP SSLFilter [0] specially at the SslFilterRequest 
> it looks to me that the final Request object might end up having this weird 
> behavior:
> 
> - request.getScheme() ==> https
> - request.getServerPort() ==> 80
> 
> and possibly
> 
> - request.getRequestURL() ==> https://domain.80/active.html
> 
> IMHO having a scheme https with a port 80 might lead to some inconsistencies 
> . WDYT?
> 
> regards
> 
> antonio
> 
> [0] https://issues.apache.org/jira/browse/FELIX-4420

Re: [SCR] Compilation error when compiling trunk

[Felix Meschberger]

That indeed solved build problems on my box (mac) with both Java 1.7.0_51 and 
1.8.0_20. Without the fix both java versions could not build (with different 
error messages, interestingly).

Regards
Felix

Am 03.09.2014 um 11:35 schrieb David Jencks :

> I don't have this problem on my mac with 
> java -version
> java version "1.7.0_25"
> Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
> Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)
> 
> but someone else mentioned it.  Does replacing the lines with
> 
> 671:
>m_enablePromise = new 
> Deferred>().resolveWith(Promises.all(promises));
> 
> 701:
>m_disablePromise = new 
> Deferred>().resolveWith(Promises.all(promises));
> 
> help?
> 
> thanks
> david jencks
> 
> On Sep 3, 2014, at 10:04 AM, Carsten Ziegeler  wrote:
> 
>> Hi,
>> 
>> I just tried to compile latest scr and got:
>> 
>> ERROR]
>> /Users/cziegeler/Developer/workspaces/granite/felix/scr/src/main/java/org/apache/felix/scr/impl/config/ConfigurableComponentHolder.java:[671,56]
>> error: method resolveWith in class Deferred cannot be applied to given
>> types;
>> [ERROR]
>>   T extends Object declared in class Deferred
>> /Users/cziegeler/Developer/workspaces/granite/felix/scr/src/main/java/org/apache/felix/scr/impl/config/ConfigurableComponentHolder.java:[701,57]
>> error: method resolveWith in class Deferred cannot be applied to given
>> types;
>> 
>> Is this a known problem?
>> 
>> Carsten
>> 
>> -- 
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziege...@apache.org
> 

Re: Jetty Logging

[Felix Meschberger]

Hi Rob

Yeah, I would think so.

I would think it is just a regression from some Jetty migrations in the past…

Regards
Felix


Am 26.08.2014 um 13:34 schrieb Rob Walker :

> Thanks Felix - that's how I read it also.
> 
> Not urgent for me at present - I have an internal PR to migrate our App to 
> the latest HTTP Jetty version anyone, so maybe I'll take a look at wiring 
> that debug flag back in at the same time.
> 
> Do you think it's worth raising a JIRA report for it?
> 
> -- Rob
> 
> On 26/08/2014 12:01, Felix Meschberger wrote:
>> Hi
>> 
>> If I see it correctly it all happens in the Jetty 
>> org.eclipse.jetty.util.log.Log class, which by defaults sets up logging to 
>> SLF4J which can be overwritten by setting the 
>> „org.eclipse.jetty.util.log.class“ property.
>> 
>> Looking at JettyConfig it seems that the debug flag is not currently used. 
>> It is exposed in the isDebug method, but that does not seem to be called. I 
>> would think we would have to „fix“ that in the JettyServer class when 
>> starting Jetty up — really early similar to how we „fix“ the jetty.version 
>> setup.
>> 
>> Regards
>> Felix
>> 
>> 
>> Am 26.08.2014 um 09:18 schrieb Rob Walker :
>> 
>>> I'm being lazy here I know, but anyone remember offhand the set of 
>>> properties required to get Jetty's own internal tracing/logging piped 
>>> through to the OSGi logging. Scanning the code quickly, I can see the 
>>> JettyLogger class but my head is not quite connecting the dots on how to 
>>> get that active.
>>> 
>>> The org.apache.felix.http.debug = true is fine for service logs, but I'm 
>>> after the low level tracing that Jetty spits out as it processes requests
>>> 
>>> I know this used to just be as simple as setting the old DEBUg=true flag 
>>> and using the Jetty StdErrLog flag, but obviously moved on since those days!
>>> 
>>> Cheers
>>> 
>>> --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
> 

Re: Jetty Logging

[Felix Meschberger]

Hi

If I see it correctly it all happens in the Jetty 
org.eclipse.jetty.util.log.Log class, which by defaults sets up logging to 
SLF4J which can be overwritten by setting the 
„org.eclipse.jetty.util.log.class“ property.

Looking at JettyConfig it seems that the debug flag is not currently used. It 
is exposed in the isDebug method, but that does not seem to be called. I would 
think we would have to „fix“ that in the JettyServer class when starting Jetty 
up — really early similar to how we „fix“ the jetty.version setup.

Regards
Felix


Am 26.08.2014 um 09:18 schrieb Rob Walker :

> I'm being lazy here I know, but anyone remember offhand the set of properties 
> required to get Jetty's own internal tracing/logging piped through to the 
> OSGi logging. Scanning the code quickly, I can see the JettyLogger class but 
> my head is not quite connecting the dots on how to get that active.
> 
> The org.apache.felix.http.debug = true is fine for service logs, but I'm 
> after the low level tracing that Jetty spits out as it processes requests
> 
> I know this used to just be as simple as setting the old DEBUg=true flag and 
> using the Jetty StdErrLog flag, but obviously moved on since those days!
> 
> Cheers
> 
> --Rob
> 
> 

Re: Why is config admin checking for empty collections in Configuration values?

[Felix Meschberger]

Hi David

Hmm, good question. It has always been there - ever since it was first imported 
into the Felix project as part of FELIX-11.

While an empty collection does not make that much sense, I think the check 
doesn't either. On the other hand: If empty collections are allowed, then it 
must be made sure the ConfigurationHandler serializer can also read and write 
such empty collections.

Regards
Felix

Am 06.08.2014 um 03:35 schrieb David Jencks :

> While writing a test I discovered that config admin doesn't like empty 
> collections or collections with empty values as configuration values.  After 
> searching the 5.0 config admin spec for a while I can't find any support for 
> these restrictions, and they are not applied to arrays.  What is the 
> justification for these checks?
> 
> Here's the code I'm asking about (CaseInsensitiveDictionary lines 309ff)
> 
>if ( collection.isEmpty() )
>{
>throw new IllegalArgumentException( "Collection must not be 
> empty" );
>}
> 
>// ensure all elements have the same type and to internal list
>Collection internalValue = new ArrayList( collection.size() );
>type = null;
>for ( Iterator ci = collection.iterator(); ci.hasNext(); )
>{
>Object el = ci.next();
>if ( el == null )
>{
>throw new IllegalArgumentException( "Collection must not 
> contain null elements" );
>}
> 
> 
> thanks
> david jencks

Re: Upgrading to Jetty 9

[Felix Meschberger]

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 :

> 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: [ANN] Carsten Ziegeler confirmed as Chair of the PMC and VP, Apache Felix

[Felix Meschberger]

Ha, I wondered how long it would take for someone to notice :-)

Honestly, I am sorry for the typo, indeed.

Regards
Felix

Am 19.06.2014 um 16:52 schrieb Bertrand Delacretaz :

> On Thu, Jun 19, 2014 at 4:15 PM, Felix Meschberger  wrote:
>> ...I would like to congratulate Carsten to his new role and wish him as much 
>> fun and appreciation as I had in the last 20 years
> 
> Congrats Carsten, thanks for stepping up!
> 
> And congrats Felix for being PMC chair for the last 20 years...quite a feat 
> ;-)
> 
> -Bertrand

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

[Felix Meschberger]

Hi all

The ASF Board yesterday approved a resolution to change the Apache Felix PMC 
Chair. I have resigned and the PMC proposed Carsten Ziegeler to be the new 
Chair of the Apache Felix PMC and thus bear the title VP, Apache Felix.

I would like to congratulate Carsten to his new role and wish him as much fun 
and appreciation as I had in the last 20 years.

Regards
Felix

Re: RFE: add sources to bundles

[Felix Meschberger]

+1 FWIW.

I agree that having the source within the bundles might be a nice-to-have. 
AFAICT we already deploy the sources to maven and as such can download them as 
dependencies.

I would be ok if we would have a build profile which would create a developer's 
artifact which embeds the sources with the binary code. But the default IMHO 
should remain to be binary only.

Regards
Felix

Am 18.06.2014 um 16:08 schrieb Karl Pauls :

> Oh, I was assuming you where talking about generating maven source jars on
> release. So that will not work (I'd still be happy if somebody gets that
> one done in the parent pom).
> 
> FWIW, I'm not a super big fan of shipping the source in the binaries as
> that makes them extra bloated - we should deploy/release the source.jars
> via maven and bnd should learn how to download them from the maven repo or
> at least provide a way to attach them manually without forcing the source
> to be contained in the jar (if it can't do that already).
> 
> regards,
> 
> Karl
> 
> 
> On Wed, Jun 18, 2014 at 3:39 PM, Ferry Huberts  wrote:
> 
>> 
>> 
>> On 18/06/14 15:27, Karl Pauls wrote:
>> 
>>> Attaching the source jars makes a lot of sense - somebody wants to take a
>>> go at our parent pom?
>>> 
>>> 
>> IIRC you can't do it in the parent pom.
>> You need to add
>>  <_source>true
>> to the bundle plugin configurations
>> 
>> 
>> regards,
>>> 
>>> Karl
>>> 
>>> 
>>> On Wed, Jun 18, 2014 at 3:18 PM, Paul Bakker 
>>> wrote:
>>> 
>>> +1
 
 I believe Maven source jars are already generated, but it would be great
 to
 also generate the sources in the binaries like Bndtools expects.
 
 Cheers,
 
 Paul
 
 
 On Wed, Jun 18, 2014 at 9:11 AM, Ferry Huberts 
 wrote:
 
 
> 
> On 18/06/14 14:48, Raymond Auge wrote:
> 
> +1
>> 
>> I find if incredibly tiring to have to fetch the source bundles for
>> libs
>> all the time.
>> 
>> Meanwhile, some libs like bnd for instance, contain the sources and
>> that
>> makes them a joy to work with.
>> 
>> 
> 
> the reason I sent this mail is that I have an insane jetty crash that I
> wanted to track down. Because no sources were included and I use many
> 
 felix
 
> bundles with widely differing versions it became a nightmare and I just
> gave up.
> 
> 
> 
> However, I could see a counter argument for the size of the archive
>> 
> being
 
> adversely affected by the inclusion of sources, particularly for those
>> small profile installations (particularly embedded).
>> 
>> 
>> I'm sure an acceptable solution can be found.
> 
> 
> 
> On Wed, Jun 18, 2014 at 3:14 AM, Ferry Huberts 
>> wrote:
>> 
>>  Hi,
>> 
>>> 
>>> I'd like to request that the sources be added to released bundles.
>>> This makes debugging so much easier, especially when using bndtools.
>>> 
>>> The bnd instruction to accomplish this (also applicable to the bundle
>>> plugin) is:
>>>-sources: true
>>> 
>>> 
>>> 
>>> 
>>> --
>>> Ferry Huberts
>>> 
>>> 
>>> 
>> 
>> 
>> --
> Ferry Huberts
> 
> 
 
>>> 
>>> 
>>> 
>> --
>> Ferry Huberts
>> 
> 
> 
> 
> -- 
> Karl Pauls
> karlpa...@gmail.com
> http://twitter.com/karlpauls
> http://www.linkedin.com/in/karlpauls
> https://profiles.google.com/karlpauls

Re: Question about the Felix release process

[Felix Meschberger]

Hi David

Not sure any longer, why we have this SNAPSHOT step. Maybe really it was about 
building a release candidate for others to test.

For the actual release process it is not really relevant.

Regards
Felix

Am 17.06.2014 um 11:37 schrieb David Bosschaert :

> The Felix release process
> (http://felix.apache.org/documentation/development/release-management-nexus.html)
> says that you need to deploy a snapshot using 'mvn deploy'.
> 
> I'm not sure I fully understand the reason for this? If it is to test
> the to-be-released artifacts, then these are available in Nexus
> staging before the release is promoted, right?
> 
> Thanks,
> 
> David

[jira] [Commented] (FELIX-4530) [SCR Plugin] Revisit setting the default output to target/classes

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on FELIX-4530:
--

[~cziegeler] It's about a default behaviour of the bundle plugin and how the 
SCR plugin interferes.

I am absolutely in favor of the SCR plugin adding the generated descriptors to 
the project resources. But this is just the manifests not the complete folder 
where they reside in.

If the only way to add the desciptors is to add the complete descriptor target 
folder, then using target/classes is not a good idea because then you loose all 
the fine tuning that the bundle plugin and bnd offer.

And maybe, it is the Sling tooling which should be more intelligent ?

> [SCR Plugin] Revisit setting the default output to target/classes
> -
>
> Key: FELIX-4530
> URL: https://issues.apache.org/jira/browse/FELIX-4530
> Project: Felix
>  Issue Type: Bug
>  Components: SCR Tooling
>Affects Versions: maven-scr-plugin 1.17.0
>Reporter: Felix Meschberger
>Priority: Critical
> Fix For: maven-scr-plugin 1.17.2
>
>
> With FELIX-4241 the default value for the descriptor output files has been 
> set to {{target/classes}}. Unfortunately this causes {{target/classes}} to be 
> added to the Maven Input Resources resulting in all contents of 
> {{target/classes}} to be included in the final bundle regardless of whether 
> this is actually desired or not.
> Regardless of tooling integration noted in FELIX-4241, it is against the 
> spirit of the bundle plugin to blindly include everything in 
> {{target/classes}} in the bundle. So the resolution for FELIX-4241 must be 
> revisited.



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

[jira] [Updated] (FELIX-4530) [SCR Plugin] Revisit setting the default output to target/classes

[Felix Meschberger (JIRA)]

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

Felix Meschberger updated FELIX-4530:
-

Fix Version/s: maven-scr-plugin 1.17.2

> [SCR Plugin] Revisit setting the default output to target/classes
> -
>
> Key: FELIX-4530
> URL: https://issues.apache.org/jira/browse/FELIX-4530
> Project: Felix
>  Issue Type: Bug
>  Components: SCR Tooling
>Affects Versions: maven-scr-plugin 1.17.0
>    Reporter: Felix Meschberger
>Priority: Critical
> Fix For: maven-scr-plugin 1.17.2
>
>
> With FELIX-4241 the default value for the descriptor output files has been 
> set to {{target/classes}}. Unfortunately this causes {{target/classes}} to be 
> added to the Maven Input Resources resulting in all contents of 
> {{target/classes}} to be included in the final bundle regardless of whether 
> this is actually desired or not.
> Regardless of tooling integration noted in FELIX-4241, it is against the 
> spirit of the bundle plugin to blindly include everything in 
> {{target/classes}} in the bundle. So the resolution for FELIX-4241 must be 
> revisited.



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

[jira] [Created] (FELIX-4530) [SCR Plugin] Revisit setting the default output to target/classes

[Felix Meschberger (JIRA)]

Felix Meschberger created FELIX-4530:


 Summary: [SCR Plugin] Revisit setting the default output to 
target/classes
 Key: FELIX-4530
 URL: https://issues.apache.org/jira/browse/FELIX-4530
 Project: Felix
  Issue Type: Bug
  Components: SCR Tooling
Affects Versions: maven-scr-plugin 1.17.0
Reporter: Felix Meschberger
Priority: Critical


With FELIX-4241 the default value for the descriptor output files has been set 
to {{target/classes}}. Unfortunately this causes {{target/classes}} to be added 
to the Maven Input Resources resulting in all contents of {{target/classes}} to 
be included in the final bundle regardless of whether this is actually desired 
or not.

Regardless of tooling integration noted in FELIX-4241, it is against the spirit 
of the bundle plugin to blindly include everything in {{target/classes}} in the 
bundle. So the resolution for FELIX-4241 must be revisited.



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

[REPORT] Apache Felix - June 2014

[Felix Meschberger]

Apache Felix is a project aimed at implementing specifications from the OSGi
Alliance as well as implementing other supporting tools and technologies
aligned with OSGi technology.

Community
* PMC: No new PMC members have been added in this report period. The last new
   PMC member was added in Dec. 2013
* Committers: No new committers have been added in this report period. The
   last new committer was added in Dec. 2013
* Steady mailing list activity.
* There are no issues requiring board attention at this time.

Software
* Apache Felix Maven SCR Plugin 1.17.0 (May 22, 2014)
* Apache Felix SCR Ant Task 1.11.0 (May 22, 2014)
* Apache Felix SCR Bnd Plugin 1.1.0 (May 22, 2014)
* Apache Felix SCR Generator 1.10.0 (May 22, 2014)
* Apache Felix iPOJO Manipulator and Runtime 1.12.0 (May 17, 2014)
* Apache Felix FileInstall 3.4.0 (April 22, 2014)
* Apache Felix DeploymentAdmin 0.9.6 (April 1, 2014)
* Apache Felix Framework 4.4.0 and Framework Security 2.4.0 (March 25, 2014)
* Apache Felix Maven SCR Plugin 1.16.0 (March 16, 2014)
* Apache Felix SCR Ant Task 1.10.0 (March 16, 2014)
* Apache Felix SCR Bnd Plugin 1.0.0 (March 16, 2014)
* Apache Felix SCR Annotations 1.9.8 (March 16, 2014)
* Apache Felx SCR Generator 1.9.0 (March 16, 2014)
* Apache Felix iPOJO Manipulator and Runtime 1.11.2 (March 15, 2014)

Project Branding
* TM missing from all Logos

Licensing and other issues
* None

Regards
Felix

ApacheCon CFP closes June 25

[Felix Meschberger]

Dear Apache Felix (and OSGi) enthusiast,

As you may be aware, ApacheCon will be held this year in Budapest, on
November 17-23. (See http://apachecon.eu for more info.)

The Call For Papers for that conference is still open, but will be
closing soon. We need your talk proposals, to represent Apache Felix
and OSGi at ApacheCon. We need all kinds of talks - deep technical
talks, hands-on tutorials, introductions for beginners, or case studies
about the awesome stuff you're doing with Apache Felix and/or OSGi.

Please consider submitting a proposal, at
http://events.linuxfoundation.org//events/apachecon-europe/program/cfp

Thanks!
Felix

[jira] [Commented] (FELIX-4420) [HTTP SSLFilter] Implement sendRedirect

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on FELIX-4420:
--

[~jajans] +1

Except that I would make "Constants" a final class and rename it to 
SSLFilterConstants (there are so many Constants classes and interfaces flying 
around that it is hard to disambiguate them).

Thanks.

> [HTTP SSLFilter] Implement sendRedirect
> ---
>
> Key: FELIX-4420
> URL: https://issues.apache.org/jira/browse/FELIX-4420
> Project: Felix
>  Issue Type: Improvement
>  Components: HTTP Service
>Affects Versions: http-2.2.1, http-2.2.2
>Reporter: Felix Meschberger
>Assignee: J.W. Janssen
> Fix For: http-2.3.0, http-sslfilter-1.0.0
>
> Attachments: FELIX-4420.patch
>
>
> The HTTP SSL Filter service implemented in FELIX-3693 supports revealing the 
> actual protocol used by the client side browser by inspecting a request 
> header and exposing the proper scheme through its ServletRequest.getScheme() 
> implementation if the actual server is operated behind an SSL terminating 
> proxy (i.e. client connects with HTTPS to proxy, proxy forwards request to 
> server over plain HTTP)
> The HttpServletRequest.sendRedirect() method is declared to set the Location 
> header to the absolute redirect URL which includes the scheme. In an SSL 
> terminating proxy situation, the servlet container does not know about this 
> fact and hence uses the actual server scheme (HTTP) for the redirect instead 
> of the scheme used by client.
> To fix this situation the SSL filter response should implement the 
> HttpServletResponse.sendRedirect() method to use use the client side scheme 
> as extracted from the request instead of the actual server request.



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