Re: [DISCUSS] Release resolver 1.10.2

2017-02-10 Thread Thomas Watson 
+1

Also notice that I fixed resolver issue
https://issues.apache.org/jira/browse/FELIX-5514 which should get released
also

Tom.

On Feb 10, 2017 8:19 AM, "David Bosschaert" 
wrote:

> That would be great, thanks Guillaume!
>
> David
>
> On 9 February 2017 at 23:43, Guillaume Nodet  wrote:
>
> > I'd like to get FELIX-5450 and FELIX-5514 out of the door, so unless
> > someone volunteer  to do the resolver 1.10.2 release, i'll give it a try
> > next week.
> >
> > Cheers,
> > Guillaume
> >
>

Re: [VOTE] Release Apache Felix Utils 1.9.0

2017-02-10 Thread Raymond Auge 
+1 (non-binding)

On Fri, Feb 10, 2017 at 3:03 PM, David Bosschaert <
david.bosscha...@gmail.com> wrote:

> +1
>
> David
>
> On 10 February 2017 at 11:24, Carsten Ziegeler 
> wrote:
>
> > Hi,
> >
> > We solved 2 issues in this release
> > https://issues.apache.org/jira/browse/FELIX/fixforversion/12339156
> >
> >
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachefelix-1165/
> >
> > You can use this UNIX script to download the release and verify the
> > signatures:
> > http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
> >
> > Usage:
> > sh check_staged_release.sh 1165 /tmp/felix-staging
> >
> > Please vote to approve this release:
> >
> > [ ] +1 Approve the release
> > [ ] -1 Veto the release (please provide specific comments)
> >
> > This vote will be open for 72 hours.
> >
> > Regards
> > Carsten
> > --
> > Carsten Ziegeler
> > Adobe Research Switzerland
> > cziege...@apache.org
> >
>



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)

Re: Component Property Type with empty array as default value

2017-02-10 Thread Raymond Auge 
Hello Julien,

As Carsten stated you should post this question on the
osgi-...@mail.osgi.org mailing as it relates to specifying behaviour.

However, I tend to agree with your assessment and I think it may be
reasonable to make some amendments to the specs to clarify the cases you
mentioned. And as the EGs are in the throws of R7 updates this would be a
good time to do it, particularly since we are doing other annotation
related work as we speak :).

In fact the very best thing might be to create a bug report on the OSGi
Alliance bug tracker https://osgi.org/bugzilla/

Sincerely,
- Ray

On Fri, Feb 10, 2017 at 2:25 PM, Carsten Ziegeler 
wrote:

> Hi Julian
>
> I think this question is best asked on osgi-...@mail.osgi.org .
>
> Regards
> Carsten
>
> Julian Sedding wrote
> > Hi all
> >
> > I have been puzzled recently when using DS Component Property Types by
> > the following situation (see also FELIX-5404[0]):
> >
> > @interface Config {
> > String[] whitelist default {};
> > }
> >
> > public class WhitelistComponent {
> > private String[] whitelist;
> > @Activate
> > void activate(Config config) {
> > this.whitelist = config.whitelist(); // throws
> NullPointerException
> > }
> > }
> >
> > Hopefully, you agree that this behaviour is unexpected and
> > undesirable. I certainly did not expect a NullPointerException when
> > calling "config.whitelist()"; I expected an empty array, as that's the
> > default value I defined. (I actually believe this behaviour is in
> > violation of the Java spec, see my comment in FELIX-5404).
> >
> > After the discussion in FELIX-5404 I did some more reading in the
> > spec, but I am still not entirely sure if the problem is in the spec
> > or in the implementation.
> >
> > When I look at the generated metatype information the XML files
> > contain the empty array as default value. The Metatype Service Spec
> > 1.3 clearly defines the case of an empty array default values: "[...]
> > The empty string is significant and must be seen as an empty List or
> > array if specified as the default for an attribute with a cardinality
> > that is not equal to zero. [...]" (105.7.1 XML Schema of a Meta Type
> > Resource).
> >
> > However, the Declarative Services Spec 1.3 is less clear about empty
> > array default values. As I read it, an array (default) value must be
> > represented in the  tag's body: "[...] If the value
> > attribute is not specified, the body of the property element must
> > contain one or more values. The value of the property is then an array
> > of the specified type. [...]". However, it mandates that there be one
> > or more values, thus explicitly excluding the possibility to represent
> > an empty array. Our tooling seems to omit any  tags with an
> > empty default value. It is unclear to me how an empty array default
> > value can or should be represented in a component descriptor.
> >
> > AFAIU the metatype does not factor in when component configurations
> > are concerned, hence the default value present in the metatype is
> > irrelevant for this situation.
> >
> > This leaves two possible places where this behaviour could be fixed:
> >
> > 1. My understanding is wrong and an empty array default value can be
> > represented in the component descriptor XML. Then I believe we need to
> > fix our tooling.
> > 2. When Component Property Types are used, the annotation's default
> > values should be consulted as a last resort (i.e. if no service
> > property is set). We would need to check whether this is compliant
> > with the spec, however.
> >
> > The third option is to accept this oddity and leave the implementation
> > as-is. However, this would likely confuse users of component property
> > types and negate some of their benefits (i.e. null checks would still
> > be necessary, even if default values are used).
> >
> > Thanks for your thoughts and insights!
> >
> > Regards
> > Julian
> >
> > [0] https://issues.apache.org/jira/browse/FELIX-5404
> >
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>
>


-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)

Re: [VOTE] Release Apache Felix Utils 1.9.0

2017-02-10 Thread David Bosschaert 
+1

David

On 10 February 2017 at 11:24, Carsten Ziegeler  wrote:

> Hi,
>
> We solved 2 issues in this release
> https://issues.apache.org/jira/browse/FELIX/fixforversion/12339156
>
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachefelix-1165/
>
> You can use this UNIX script to download the release and verify the
> signatures:
> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
>
> Usage:
> sh check_staged_release.sh 1165 /tmp/felix-staging
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
>
> This vote will be open for 72 hours.
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>

Re: [VOTE] Release Apache Felix Utils 1.9.0

2017-02-10 Thread Carsten Ziegeler 
+1

 

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

Re: Component Property Type with empty array as default value

2017-02-10 Thread Carsten Ziegeler 
Hi Julian

I think this question is best asked on osgi-...@mail.osgi.org .

Regards
Carsten

Julian Sedding wrote
> Hi all
> 
> I have been puzzled recently when using DS Component Property Types by
> the following situation (see also FELIX-5404[0]):
> 
> @interface Config {
> String[] whitelist default {};
> }
> 
> public class WhitelistComponent {
> private String[] whitelist;
> @Activate
> void activate(Config config) {
> this.whitelist = config.whitelist(); // throws NullPointerException
> }
> }
> 
> Hopefully, you agree that this behaviour is unexpected and
> undesirable. I certainly did not expect a NullPointerException when
> calling "config.whitelist()"; I expected an empty array, as that's the
> default value I defined. (I actually believe this behaviour is in
> violation of the Java spec, see my comment in FELIX-5404).
> 
> After the discussion in FELIX-5404 I did some more reading in the
> spec, but I am still not entirely sure if the problem is in the spec
> or in the implementation.
> 
> When I look at the generated metatype information the XML files
> contain the empty array as default value. The Metatype Service Spec
> 1.3 clearly defines the case of an empty array default values: "[...]
> The empty string is significant and must be seen as an empty List or
> array if specified as the default for an attribute with a cardinality
> that is not equal to zero. [...]" (105.7.1 XML Schema of a Meta Type
> Resource).
> 
> However, the Declarative Services Spec 1.3 is less clear about empty
> array default values. As I read it, an array (default) value must be
> represented in the  tag's body: "[...] If the value
> attribute is not specified, the body of the property element must
> contain one or more values. The value of the property is then an array
> of the specified type. [...]". However, it mandates that there be one
> or more values, thus explicitly excluding the possibility to represent
> an empty array. Our tooling seems to omit any  tags with an
> empty default value. It is unclear to me how an empty array default
> value can or should be represented in a component descriptor.
> 
> AFAIU the metatype does not factor in when component configurations
> are concerned, hence the default value present in the metatype is
> irrelevant for this situation.
> 
> This leaves two possible places where this behaviour could be fixed:
> 
> 1. My understanding is wrong and an empty array default value can be
> represented in the component descriptor XML. Then I believe we need to
> fix our tooling.
> 2. When Component Property Types are used, the annotation's default
> values should be consulted as a last resort (i.e. if no service
> property is set). We would need to check whether this is compliant
> with the spec, however.
> 
> The third option is to accept this oddity and leave the implementation
> as-is. However, this would likely confuse users of component property
> types and negate some of their benefits (i.e. null checks would still
> be necessary, even if default values are used).
> 
> Thanks for your thoughts and insights!
> 
> Regards
> Julian
> 
> [0] https://issues.apache.org/jira/browse/FELIX-5404
> 



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

[VOTE] Release Apache Felix Utils 1.9.0

2017-02-10 Thread Carsten Ziegeler 
Hi,

We solved 2 issues in this release
https://issues.apache.org/jira/browse/FELIX/fixforversion/12339156


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

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

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

Please vote to approve this release:

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

This vote will be open for 72 hours.

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

[jira] [Updated] (FELIX-5508) Add simple JSON Parser

2017-02-10 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler updated FELIX-5508:

Summary: Add simple JSON Parser  (was: Multiple JSON Serializers)

> Add simple JSON Parser
> --
>
> Key: FELIX-5508
> URL: https://issues.apache.org/jira/browse/FELIX-5508
> Project: Felix
>  Issue Type: Improvement
>  Components: Converter
>Reporter: David Leangen
>Assignee: David Bosschaert
> Fix For: utils-1.9.0
>
>
> There appears to be multiple json serializers in the code base (serializer, 
> schematizer, and even more recently webconsole).
> Would it be worthwhile to consider consolidating them somehow, to avoid 
> duplicate work?



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

[jira] [Resolved] (FELIX-5537) ConfigSpiOsgi should not try to unregister provider if not registered

2017-02-10 Thread Chetan Mehrotra (JIRA) 

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

Chetan Mehrotra resolved FELIX-5537.

Resolution: Fixed

Done with 1782503

> ConfigSpiOsgi should not try to unregister provider if not registered
> -
>
> Key: FELIX-5537
> URL: https://issues.apache.org/jira/browse/FELIX-5537
> Project: Felix
>  Issue Type: Improvement
>  Components: JAAS
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: jaas-1.0.2
>
>
> On startup following log is seen which indicates a provider with null name is 
> being unregistered. This should be avoided as when provider name is null then 
> it indicates that provider has not be regsitered
> {noformat}
> 10.02.2017 17:09:19.873 *INFO* [FelixStartLevel] org.apache.felix.jaas 
> Removed provider null type JavaLoginConfig from Security providers list
> {noformat}



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

[jira] [Created] (FELIX-5537) ConfigSpiOsgi should not try to unregister provider if not registered

2017-02-10 Thread Chetan Mehrotra (JIRA) 
Chetan Mehrotra created FELIX-5537:
--

 Summary: ConfigSpiOsgi should not try to unregister provider if 
not registered
 Key: FELIX-5537
 URL: https://issues.apache.org/jira/browse/FELIX-5537
 Project: Felix
  Issue Type: Improvement
  Components: JAAS
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Priority: Minor
 Fix For: jaas-1.0.2


On startup following log is seen which indicates a provider with null name is 
being unregistered. This should be avoided as when provider name is null then 
it indicates that provider has not be regsitered

{noformat}
10.02.2017 17:09:19.873 *INFO* [FelixStartLevel] org.apache.felix.jaas Removed 
provider null type JavaLoginConfig from Security providers list
{noformat}



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

[jira] [Resolved] (FELIX-5536) ConfigSpiOSGi may end with incomplete realm due to race conditions

2017-02-10 Thread Chetan Mehrotra (JIRA) 

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

Chetan Mehrotra resolved FELIX-5536.

Resolution: Fixed

Fixed with 1782501

> ConfigSpiOSGi may end with incomplete realm due to race conditions
> --
>
> Key: FELIX-5536
> URL: https://issues.apache.org/jira/browse/FELIX-5536
> Project: Felix
>  Issue Type: Bug
>  Components: JAAS
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: jaas-1.0.2
>
>
> Some race conditions around this have been fixed with FELIX-5505. However one 
> more case surfaced where {{ConfigSpiOsgi#recreateConfigs}} can be invoked 
> concurrently without lock from 
> # {{ConfigSpiOsgi#updated}} - When ConfigurationAdmin dispatches config 
> update for {{org.apache.felix.jaas.ConfigurationSpi}}
> # {{ConfigSpiOsgi#addingService}} - When some LoginModuleFactory is registered
> In such a case the setup may end up with incomplete realm where some 
> LoginModuleFactory are missed out



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

[jira] [Commented] (FELIX-5536) ConfigSpiOSGi may end with incomplete realm due to race conditions

2017-02-10 Thread Chetan Mehrotra (JIRA) 

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

Chetan Mehrotra commented on FELIX-5536:


Adding ignored test in 1782497

> ConfigSpiOSGi may end with incomplete realm due to race conditions
> --
>
> Key: FELIX-5536
> URL: https://issues.apache.org/jira/browse/FELIX-5536
> Project: Felix
>  Issue Type: Bug
>  Components: JAAS
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: jaas-1.0.2
>
>
> Some race conditions around this have been fixed with FELIX-5505. However one 
> more case surfaced where {{ConfigSpiOsgi#recreateConfigs}} can be invoked 
> concurrently without lock from 
> # {{ConfigSpiOsgi#updated}} - When ConfigurationAdmin dispatches config 
> update for {{org.apache.felix.jaas.ConfigurationSpi}}
> # {{ConfigSpiOsgi#addingService}} - When some LoginModuleFactory is registered
> In such a case the setup may end up with incomplete realm where some 
> LoginModuleFactory are missed out



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

[jira] [Updated] (FELIX-5536) ConfigSpiOSGi may end with incomplete realm due to race conditions

2017-02-10 Thread Chetan Mehrotra (JIRA) 

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

Chetan Mehrotra updated FELIX-5536:
---
Summary: ConfigSpiOSGi may end with incomplete realm due to race conditions 
 (was: ConfigSpiOSGi may end with in complete realm due to race conditions)

> ConfigSpiOSGi may end with incomplete realm due to race conditions
> --
>
> Key: FELIX-5536
> URL: https://issues.apache.org/jira/browse/FELIX-5536
> Project: Felix
>  Issue Type: Bug
>  Components: JAAS
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: jaas-1.0.2
>
>
> Some race conditions around this have been fixed with FELIX-5505. However one 
> more case surfaced where {{ConfigSpiOsgi#recreateConfigs}} can be invoked 
> concurrently without lock from 
> # {{ConfigSpiOsgi#updated}} - When ConfigurationAdmin dispatches config 
> update for {{org.apache.felix.jaas.ConfigurationSpi}}
> # {{ConfigSpiOsgi#addingService}} - When some LoginModuleFactory is registered
> In such a case the setup may end up with incomplete realm where some 
> LoginModuleFactory are missed out



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

[jira] [Created] (FELIX-5536) ConfigSpiOSGi may end with in complete realm due to race conditions

2017-02-10 Thread Chetan Mehrotra (JIRA) 
Chetan Mehrotra created FELIX-5536:
--

 Summary: ConfigSpiOSGi may end with in complete realm due to race 
conditions
 Key: FELIX-5536
 URL: https://issues.apache.org/jira/browse/FELIX-5536
 Project: Felix
  Issue Type: Bug
  Components: JAAS
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
 Fix For: jaas-1.0.2


Some race conditions around this have been fixed with FELIX-5505. However one 
more case surfaced where {{ConfigSpiOsgi#recreateConfigs}} can be invoked 
concurrently without lock from 

# {{ConfigSpiOsgi#updated}} - When ConfigurationAdmin dispatches config update 
for {{org.apache.felix.jaas.ConfigurationSpi}}
# {{ConfigSpiOsgi#addingService}} - When some LoginModuleFactory is registered

In such a case the setup may end up with incomplete realm where some 
LoginModuleFactory are missed out



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

Re: [VOTE] Apache Felix Dependency Manager Release R9

2017-02-10 Thread Marcel Offermans 
+1 …good job Pierre!

Greetings, Marcel

Re: [VOTE] Apache Felix Dependency Manager Release R9

2017-02-10 Thread Jean-Baptiste Onofré 
+1 (binding)

Regards
JB

On Feb 10, 2017, 12:05, at 12:05, Bram de Kruijff  wrote:
>+1 (non-binding)
>
>Dropped this in a big app. No regressions found.
>
>Grz
>Bram
>
>On Fri, Feb 10, 2017 at 12:23 AM, Pierre De Rop
> wrote:
>> Hello all,
>>
>> I would like to call for a vote on the Dependency Manager toplevel
>release
>> R9.
>>
>> The following issues were solved:
>>
>> ** Bug
>> * [FELIX-5236] - Single @Property annotation on a type doesn't
>work
>> * [FELIX-5242] - Configuration updates may be missed when the
>component
>> is restarting
>> * [FELIX-5244] - Can't inject service using a method ref on a
>parent
>> class method.
>> * [FELIX-5245] - Typo in error logged when a component callback
>is not
>> found.
>> * [FELIX-5268] - Service not unregistered while bundle is
>starting
>> * [FELIX-5273] - Wrong log when a callback is not found from
>component
>> instance(s)
>> * [FELIX-5274] - remove callback fails after manually removing
>dynamic
>> dependencies
>> * [FELIX-5399] - Unable to define default map or list config
>types
>> * [FELIX-5400] - Can't override default configuration type list
>value
>> using an empty list
>> * [FELIX-5401] - Can't override default configuration type map
>value
>> using an empty map
>> * [FELIX-5402] - Factory configuration adapter ignores factory
>method
>> * [FELIX-5411] - When you stop a component, the service
>references are
>> not ungotten.
>> * [FELIX-5426] - Remove callbacks aren't called for optional
>> dependencies in a "circular" dependency scenario
>> * [FELIX-5428] - Dependency events set not cleared when component
>is
>> removed
>> * [FELIX-5429] - Aspect swap callback sometimes not called on
>optional
>> dependencies
>> * [FELIX-5469] - Methodcache system size property is not used
>> * [FELIX-5471] - Ensure that unbound services are always handled
>> synchronously
>> * [FELIX-5517] - @Inject annotation ignored when applied on
>> ServiceRegistration
>> * [FELIX-5519] - services are not ungotten when swapped by an
>aspect
>> * [FELIX-5523] - required dependencies added to a started adapter
>(or
>> aspect) are not injected
>>
>> ** Improvement
>> * [FELIX-5228] - Upgrade DM With latest release of BndTools
>> * [FELIX-5237] - Configurable invocation handler should use
>default
>> method values
>> * [FELIX-5346] - Start annotation not propagated to sub classes
>> * [FELIX-5355] - Allow to use properties having dots with
>configuration
>> proxies
>> * [FELIX-5365] - Generate warning on service published and
>consumed on
>> same interface but different bundles
>> * [FELIX-5403] - Improve the Javadoc for
>> org.apache.felix.dm.ComponentStateListener
>> * [FELIX-5405] - Do not have org.apache.felix.dm.Logger invoke
>> toString() of message parameters when enabled log level is not high
>enough
>> * [FELIX-5406] - DM lambda fluent service properties don't
>support dots
>> * [FELIX-5407] - DM annotation plugin generates temp log files
>even if
>> logging is disabled
>> * [FELIX-5408] - Parallel DM should not stop components
>asynchronously
>> * [FELIX-5467] - MultiPropertyFilterIndex is unusable when a
>service
>> reference contains a lot of values for one key
>> * [FELIX-5499] - Remove usage of json.org from dependency manager
>> * [FELIX-5515] - Upgrade DM to OSGi R6 API
>> * [FELIX-5516] - Allow to not dereference services internally
>> * [FELIX-5518] - Remove all eclipse warnings in DM code
>> * [FELIX-5520] - ComponentStateListener not supported in DM
>lambda
>> * [FELIX-5521] - add more callback method signature in DM lambda
>> service dependency callbacks
>> * [FELIX-5522] - Refactor aspect service implementation
>> * [FELIX-5524] - add more signatures for aspect swap callbacks
>> * [FELIX-5526] - Allow to use generic custom DM dependencies when
>using
>> dm lambda.
>> * [FELIX-5531] - Document dependency callback signatures
>> * [FELIX-5532] - Swap callback is missing in @ServiceDependency
>> annotation
>>
>> ** Task
>> * [FELIX-5533] - Fix a semantic versioning issue when releasing
>> dependency manager
>>
>>
>> You can use this UNIX script to download the release and verify the
>> signatures:
>>
>http://svn.apache.org/repos/asf/felix/trunk/dependencymanager/release/
>> check_staged_release.sh
>>
>> Usage:
>> sh check_staged_release.sh r9 /tmp/felix-staging
>>
>> This script, unlike the original Felix check_stage_release.sh, is
>specific
>> to the new Dependency Manager release process (see FELIX-4818) and
>will
>> download staging from https://dist.apache.org/repos/dist/dev/felix
>instead
>> of http://repository.apache.org/content/repositories.
>>
>> To rebuild the DM binaries from the source, you can then refer to
>>
>https://svn.apache.org/repos/asf/felix/trunk/dependencymanager/release/
>> resources/src/README.src
>>
>>
>> Please vote to approve this release:
>>
>> [ ] +1 Approve the

Re: [VOTE] Apache Felix Dependency Manager Release R9

2017-02-10 Thread Bram de Kruijff 
+1 (non-binding)

Dropped this in a big app. No regressions found.

Grz
Bram

On Fri, Feb 10, 2017 at 12:23 AM, Pierre De Rop  wrote:
> Hello all,
>
> I would like to call for a vote on the Dependency Manager toplevel release
> R9.
>
> The following issues were solved:
>
> ** Bug
> * [FELIX-5236] - Single @Property annotation on a type doesn't work
> * [FELIX-5242] - Configuration updates may be missed when the component
> is restarting
> * [FELIX-5244] - Can't inject service using a method ref on a parent
> class method.
> * [FELIX-5245] - Typo in error logged when a component callback is not
> found.
> * [FELIX-5268] - Service not unregistered while bundle is starting
> * [FELIX-5273] - Wrong log when a callback is not found from component
> instance(s)
> * [FELIX-5274] - remove callback fails after manually removing dynamic
> dependencies
> * [FELIX-5399] - Unable to define default map or list config types
> * [FELIX-5400] - Can't override default configuration type list value
> using an empty list
> * [FELIX-5401] - Can't override default configuration type map value
> using an empty map
> * [FELIX-5402] - Factory configuration adapter ignores factory method
> * [FELIX-5411] - When you stop a component, the service references are
> not ungotten.
> * [FELIX-5426] - Remove callbacks aren't called for optional
> dependencies in a "circular" dependency scenario
> * [FELIX-5428] - Dependency events set not cleared when component is
> removed
> * [FELIX-5429] - Aspect swap callback sometimes not called on optional
> dependencies
> * [FELIX-5469] - Methodcache system size property is not used
> * [FELIX-5471] - Ensure that unbound services are always handled
> synchronously
> * [FELIX-5517] - @Inject annotation ignored when applied on
> ServiceRegistration
> * [FELIX-5519] - services are not ungotten when swapped by an aspect
> * [FELIX-5523] - required dependencies added to a started adapter (or
> aspect) are not injected
>
> ** Improvement
> * [FELIX-5228] - Upgrade DM With latest release of BndTools
> * [FELIX-5237] - Configurable invocation handler should use default
> method values
> * [FELIX-5346] - Start annotation not propagated to sub classes
> * [FELIX-5355] - Allow to use properties having dots with configuration
> proxies
> * [FELIX-5365] - Generate warning on service published and consumed on
> same interface but different bundles
> * [FELIX-5403] - Improve the Javadoc for
> org.apache.felix.dm.ComponentStateListener
> * [FELIX-5405] - Do not have org.apache.felix.dm.Logger invoke
> toString() of message parameters when enabled log level is not high enough
> * [FELIX-5406] - DM lambda fluent service properties don't support dots
> * [FELIX-5407] - DM annotation plugin generates temp log files even if
> logging is disabled
> * [FELIX-5408] - Parallel DM should not stop components asynchronously
> * [FELIX-5467] - MultiPropertyFilterIndex is unusable when a service
> reference contains a lot of values for one key
> * [FELIX-5499] - Remove usage of json.org from dependency manager
> * [FELIX-5515] - Upgrade DM to OSGi R6 API
> * [FELIX-5516] - Allow to not dereference services internally
> * [FELIX-5518] - Remove all eclipse warnings in DM code
> * [FELIX-5520] - ComponentStateListener not supported in DM lambda
> * [FELIX-5521] - add more callback method signature in DM lambda
> service dependency callbacks
> * [FELIX-5522] - Refactor aspect service implementation
> * [FELIX-5524] - add more signatures for aspect swap callbacks
> * [FELIX-5526] - Allow to use generic custom DM dependencies when using
> dm lambda.
> * [FELIX-5531] - Document dependency callback signatures
> * [FELIX-5532] - Swap callback is missing in @ServiceDependency
> annotation
>
> ** Task
> * [FELIX-5533] - Fix a semantic versioning issue when releasing
> dependency manager
>
>
> You can use this UNIX script to download the release and verify the
> signatures:
> http://svn.apache.org/repos/asf/felix/trunk/dependencymanager/release/
> check_staged_release.sh
>
> Usage:
> sh check_staged_release.sh r9 /tmp/felix-staging
>
> This script, unlike the original Felix check_stage_release.sh, is specific
> to the new Dependency Manager release process (see FELIX-4818) and will
> download staging from https://dist.apache.org/repos/dist/dev/felix instead
> of http://repository.apache.org/content/repositories.
>
> To rebuild the DM binaries from the source, you can then refer to
> https://svn.apache.org/repos/asf/felix/trunk/dependencymanager/release/
> resources/src/README.src
>
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
>
>
> Many thanks;
>
> regards;
> /Pierre

Re: [VOTE] Apache Felix Dependency Manager Release R9

2017-02-10 Thread David Bosschaert 
+1

David

On 9 February 2017 at 15:23, Pierre De Rop  wrote:

> Hello all,
>
> I would like to call for a vote on the Dependency Manager toplevel release
> R9.
>
> The following issues were solved:
>
> ** Bug
> * [FELIX-5236] - Single @Property annotation on a type doesn't work
> * [FELIX-5242] - Configuration updates may be missed when the component
> is restarting
> * [FELIX-5244] - Can't inject service using a method ref on a parent
> class method.
> * [FELIX-5245] - Typo in error logged when a component callback is not
> found.
> * [FELIX-5268] - Service not unregistered while bundle is starting
> * [FELIX-5273] - Wrong log when a callback is not found from component
> instance(s)
> * [FELIX-5274] - remove callback fails after manually removing dynamic
> dependencies
> * [FELIX-5399] - Unable to define default map or list config types
> * [FELIX-5400] - Can't override default configuration type list value
> using an empty list
> * [FELIX-5401] - Can't override default configuration type map value
> using an empty map
> * [FELIX-5402] - Factory configuration adapter ignores factory method
> * [FELIX-5411] - When you stop a component, the service references are
> not ungotten.
> * [FELIX-5426] - Remove callbacks aren't called for optional
> dependencies in a "circular" dependency scenario
> * [FELIX-5428] - Dependency events set not cleared when component is
> removed
> * [FELIX-5429] - Aspect swap callback sometimes not called on optional
> dependencies
> * [FELIX-5469] - Methodcache system size property is not used
> * [FELIX-5471] - Ensure that unbound services are always handled
> synchronously
> * [FELIX-5517] - @Inject annotation ignored when applied on
> ServiceRegistration
> * [FELIX-5519] - services are not ungotten when swapped by an aspect
> * [FELIX-5523] - required dependencies added to a started adapter (or
> aspect) are not injected
>
> ** Improvement
> * [FELIX-5228] - Upgrade DM With latest release of BndTools
> * [FELIX-5237] - Configurable invocation handler should use default
> method values
> * [FELIX-5346] - Start annotation not propagated to sub classes
> * [FELIX-5355] - Allow to use properties having dots with configuration
> proxies
> * [FELIX-5365] - Generate warning on service published and consumed on
> same interface but different bundles
> * [FELIX-5403] - Improve the Javadoc for
> org.apache.felix.dm.ComponentStateListener
> * [FELIX-5405] - Do not have org.apache.felix.dm.Logger invoke
> toString() of message parameters when enabled log level is not high enough
> * [FELIX-5406] - DM lambda fluent service properties don't support dots
> * [FELIX-5407] - DM annotation plugin generates temp log files even if
> logging is disabled
> * [FELIX-5408] - Parallel DM should not stop components asynchronously
> * [FELIX-5467] - MultiPropertyFilterIndex is unusable when a service
> reference contains a lot of values for one key
> * [FELIX-5499] - Remove usage of json.org from dependency manager
> * [FELIX-5515] - Upgrade DM to OSGi R6 API
> * [FELIX-5516] - Allow to not dereference services internally
> * [FELIX-5518] - Remove all eclipse warnings in DM code
> * [FELIX-5520] - ComponentStateListener not supported in DM lambda
> * [FELIX-5521] - add more callback method signature in DM lambda
> service dependency callbacks
> * [FELIX-5522] - Refactor aspect service implementation
> * [FELIX-5524] - add more signatures for aspect swap callbacks
> * [FELIX-5526] - Allow to use generic custom DM dependencies when using
> dm lambda.
> * [FELIX-5531] - Document dependency callback signatures
> * [FELIX-5532] - Swap callback is missing in @ServiceDependency
> annotation
>
> ** Task
> * [FELIX-5533] - Fix a semantic versioning issue when releasing
> dependency manager
>
>
> You can use this UNIX script to download the release and verify the
> signatures:
> http://svn.apache.org/repos/asf/felix/trunk/dependencymanager/release/
> check_staged_release.sh
>
> Usage:
> sh check_staged_release.sh r9 /tmp/felix-staging
>
> This script, unlike the original Felix check_stage_release.sh, is specific
> to the new Dependency Manager release process (see FELIX-4818) and will
> download staging from https://dist.apache.org/repos/dist/dev/felix instead
> of http://repository.apache.org/content/repositories.
>
> To rebuild the DM binaries from the source, you can then refer to
> https://svn.apache.org/repos/asf/felix/trunk/dependencymanager/release/
> resources/src/README.src
>
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
>
>
> Many thanks;
>
> regards;
> /Pierre
>

Re: [VOTE] Apache Felix Dependency Manager Release R9

2017-02-10 Thread Raymond Auge 
+1 (non-binding)

On Fri, Feb 10, 2017 at 9:49 AM, Carsten Ziegeler 
wrote:

> +1
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)

Re: [VOTE] Apache Felix Dependency Manager Release R9

2017-02-10 Thread Carsten Ziegeler 
+1

 

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

Re: [DISCUSS] Release resolver 1.10.2

2017-02-10 Thread David Bosschaert 
That would be great, thanks Guillaume!

David

On 9 February 2017 at 23:43, Guillaume Nodet  wrote:

> I'd like to get FELIX-5450 and FELIX-5514 out of the door, so unless
> someone volunteer  to do the resolver 1.10.2 release, i'll give it a try
> next week.
>
> Cheers,
> Guillaume
>

[GitHub] felix pull request #92: [FELIX-5535] Fix ArrayIndexOutOfBoundsException

2017-02-10 Thread cschneider 
GitHub user cschneider opened a pull request:

https://github.com/apache/felix/pull/92

[FELIX-5535] Fix ArrayIndexOutOfBoundsException



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/cschneider/felix FELIX-5535

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/92.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #92


commit 0f499685dd79660ea39b49aa0b4a116642a002df
Author: Christian Schneider 
Date:   2017-02-10T13:51:28Z

[FELIX-5535] Fix ArrayIndexOutOfBoundsException




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (FELIX-5535) ArrayIndexOutOfBoundsException when typing < or > in shell

2017-02-10 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on FELIX-5535:
---

GitHub user cschneider opened a pull request:

https://github.com/apache/felix/pull/92

[FELIX-5535] Fix ArrayIndexOutOfBoundsException



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/cschneider/felix FELIX-5535

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/92.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #92


commit 0f499685dd79660ea39b49aa0b4a116642a002df
Author: Christian Schneider 
Date:   2017-02-10T13:51:28Z

[FELIX-5535] Fix ArrayIndexOutOfBoundsException




> ArrayIndexOutOfBoundsException when typing < or > in shell
> --
>
> Key: FELIX-5535
> URL: https://issues.apache.org/jira/browse/FELIX-5535
> Project: Felix
>  Issue Type: Bug
>  Components: Gogo Runtime
>Affects Versions: gogo.runtime-1.0.2
>Reporter: Christian Schneider
> Fix For: gogo.runtime-1.0.4
>
>
> 2017-02-10T14:40:44,145 | ERROR | Karaf local console user karaf | ShellUtil  
>   | 43 - org.apache.karaf.shell.core - 4.1.1.SNAPSHOT | 
> Exception caught while executing command
> java.lang.ArrayIndexOutOfBoundsException: 1
>   at org.apache.felix.gogo.runtime.Token.charAt(Token.java:81) 
> [43:org.apache.karaf.shell.core:4.1.1.SNAPSHOT]
>   at java.util.regex.Pattern$Slice.match(Pattern.java:3969) [?:?]
>   at java.util.regex.Pattern$Ques.match(Pattern.java:4182) [?:?]
>   at java.util.regex.Pattern$Branch.match(Pattern.java:4604) [?:?]
>   at java.util.regex.Matcher.match(Matcher.java:1270) [?:?]
>   at java.util.regex.Matcher.matches(Matcher.java:604) [?:?]
>   at org.apache.felix.gogo.runtime.Tokenizer.next(Tokenizer.java:111) 
> [43:org.apache.karaf.shell.core:4.1.1.SNAPSHOT]
>   at org.apache.felix.gogo.runtime.Parser.next(Parser.java:284) 
> [43:org.apache.karaf.shell.core:4.1.1.SNAPSHOT]
>   at org.apache.felix.gogo.runtime.Parser.program(Parser.java:202) 
> [43:org.apache.karaf.shell.core:4.1.1.SNAPSHOT]
>   at 
> org.apache.felix.gogo.jline.Highlighter.highlight(Highlighter.java:58) 
> [43:org.apache.karaf.shell.core:4.1.1.SNAPSHOT]
>   at 
> org.jline.reader.impl.LineReaderImpl.getDisplayedBufferWithPrompts(LineReaderImpl.java:3263)
>  [50:org.jline:3.1.3]
>   at 
> org.jline.reader.impl.LineReaderImpl.redisplay(LineReaderImpl.java:3203) 
> [50:org.jline:3.1.3]
>   at 
> org.jline.reader.impl.LineReaderImpl.cleanup(LineReaderImpl.java:2180) 
> [50:org.jline:3.1.3]
>   at 
> org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:570) 
> [50:org.jline:3.1.3]
>   at 
> org.apache.karaf.shell.impl.console.ConsoleSessionImpl.run(ConsoleSessionImpl.java:332)
>  [43:org.apache.karaf.shell.core:4.1.1.SNAPSHOT]
>   at java.lang.Thread.run(Thread.java:745) [?:?]



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

[jira] [Created] (FELIX-5535) ArrayIndexOutOfBoundsException when typing < or > in shell

2017-02-10 Thread Christian Schneider (JIRA) 
Christian Schneider created FELIX-5535:
--

 Summary: ArrayIndexOutOfBoundsException when typing < or > in shell
 Key: FELIX-5535
 URL: https://issues.apache.org/jira/browse/FELIX-5535
 Project: Felix
  Issue Type: Bug
  Components: Gogo Runtime
Affects Versions: gogo.runtime-1.0.2
Reporter: Christian Schneider
 Fix For: gogo.runtime-1.0.4


2017-02-10T14:40:44,145 | ERROR | Karaf local console user karaf | ShellUtil
| 43 - org.apache.karaf.shell.core - 4.1.1.SNAPSHOT | 
Exception caught while executing command
java.lang.ArrayIndexOutOfBoundsException: 1
at org.apache.felix.gogo.runtime.Token.charAt(Token.java:81) 
[43:org.apache.karaf.shell.core:4.1.1.SNAPSHOT]
at java.util.regex.Pattern$Slice.match(Pattern.java:3969) [?:?]
at java.util.regex.Pattern$Ques.match(Pattern.java:4182) [?:?]
at java.util.regex.Pattern$Branch.match(Pattern.java:4604) [?:?]
at java.util.regex.Matcher.match(Matcher.java:1270) [?:?]
at java.util.regex.Matcher.matches(Matcher.java:604) [?:?]
at org.apache.felix.gogo.runtime.Tokenizer.next(Tokenizer.java:111) 
[43:org.apache.karaf.shell.core:4.1.1.SNAPSHOT]
at org.apache.felix.gogo.runtime.Parser.next(Parser.java:284) 
[43:org.apache.karaf.shell.core:4.1.1.SNAPSHOT]
at org.apache.felix.gogo.runtime.Parser.program(Parser.java:202) 
[43:org.apache.karaf.shell.core:4.1.1.SNAPSHOT]
at 
org.apache.felix.gogo.jline.Highlighter.highlight(Highlighter.java:58) 
[43:org.apache.karaf.shell.core:4.1.1.SNAPSHOT]
at 
org.jline.reader.impl.LineReaderImpl.getDisplayedBufferWithPrompts(LineReaderImpl.java:3263)
 [50:org.jline:3.1.3]
at 
org.jline.reader.impl.LineReaderImpl.redisplay(LineReaderImpl.java:3203) 
[50:org.jline:3.1.3]
at 
org.jline.reader.impl.LineReaderImpl.cleanup(LineReaderImpl.java:2180) 
[50:org.jline:3.1.3]
at 
org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:570) 
[50:org.jline:3.1.3]
at 
org.apache.karaf.shell.impl.console.ConsoleSessionImpl.run(ConsoleSessionImpl.java:332)
 [43:org.apache.karaf.shell.core:4.1.1.SNAPSHOT]
at java.lang.Thread.run(Thread.java:745) [?:?]




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

[jira] [Updated] (FELIX-5138) Felix should log underlying exception on failed bundle update

2017-02-10 Thread Karl Pauls (JIRA) 

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

Karl Pauls updated FELIX-5138:
--
Fix Version/s: framework-5.6.2

> Felix should log underlying exception on failed bundle update
> -
>
> Key: FELIX-5138
> URL: https://issues.apache.org/jira/browse/FELIX-5138
> Project: Felix
>  Issue Type: Improvement
>  Components: Framework
>Affects Versions: framework-5.0.1
>Reporter: Jörg Hoh
>Assignee: Karl Pauls
> Fix For: framework-5.6.2
>
>
> I run an application, which is based on Apache Sling. We recently updated our 
> bundles and I faced this message; as outcome my.custom.bundle wasn't updated 
> properly.
> {noformat}
> 11.12.2015 14:09:36.753 *INFO* [FelixStartLevel] my.custom.bundle BundleEvent 
> RESOLVED
> 11.12.2015 14:09:36.753 *INFO* [FelixStartLevel] my.custom.bundle BundleEvent 
> STARTING
> 11.12.2015 14:09:36.754 INFO [OsgiInstallerImpl] 
> org.apache.sling.installer.core.impl.tasks.BundleUpdateTask Removing failing 
> update task - unable to retry: BundleUpdateTask: 
> TaskResource(url=jcrinstall:/apps/myapp/install/my.custom.bundle-1.5.6-SNAPSHOT.jar,
>  entity=bundle:my.custom.bundle, state=INSTALL, 
> attributes=[org.apache.sling.installer.api.tasks.ResourceTransformer=:28:84:15:,
>  Bundle-SymbolicName=my.custom.bundle, Bundle-Version=1.5.6-SNAPSHOT], 
> digest=1449838063263)
> org.osgi.framework.BundleException: Bundle my.custom.bundle [252] cannot be 
> update, since it is either starting or stopping.
> at org.apache.felix.framework.Felix.updateBundle(Felix.java:2311)
> at org.apache.felix.framework.BundleImpl.update(BundleImpl.java:995)
> at 
> org.apache.sling.installer.core.impl.tasks.BundleUpdateTask.execute(BundleUpdateTask.java:92)
> at 
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.doExecuteTasks(OsgiInstallerImpl.java:847)
> at 
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.executeTasks(OsgiInstallerImpl.java:689)
> at 
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.run(OsgiInstallerImpl.java:265)
> at java.lang.Thread.run(Thread.java:767)
> {noformat}
> According to the code, Felix.updateBundle() prints this message only when 
> acquireBundleLock() throws an IllegalStateException; and this 
> IllegalStatement exception can have 2 different causes.
> It would be good, if the log message contains an information, which of these 
> 2 reasons actually occurred. And it would be even better, if this action is 
> actually retried, as this problem looks like a temporary issue for me.



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

[jira] [Resolved] (FELIX-5528) Improve handing of bundle updates concurrent to other lifecycle changes

2017-02-10 Thread Karl Pauls (JIRA) 

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

Karl Pauls resolved FELIX-5528.
---
Resolution: Fixed

I committed support for this in r1782457. 

The main idea is that we now wait for STARTING and STOPPING bundles and when we 
get the lock we check if they are not STARTING or STOPPING. If they are not we 
are good and otherwise, we had the bundle lock already - hence, we are in a 
cycle and throw the exception we previously always did throw directly when the 
bundle was STARTING or STOPPING. 


> Improve handing of bundle updates concurrent to other lifecycle changes
> ---
>
> Key: FELIX-5528
> URL: https://issues.apache.org/jira/browse/FELIX-5528
> Project: Felix
>  Issue Type: Improvement
>  Components: Framework
>Affects Versions: framework-5.6.1
>Reporter: Karl Pauls
>Assignee: Karl Pauls
> Fix For: framework-5.6.2
>
>
> Updating a bundle that is in the STARTING or STOPPING state is currently 
> causing a bundle exception saying that we couldn't perform the update. 
> According to the current spec we have to allow to call update on bundles in 
> the STARTING or STOPPING state and handle them like we would handle ACTIVE 
> bundles (I.e., wait until the bundle is in the ACTIVE state and then stop it) 
> or wait until the bundle is RESOLVED, respectively, and then do the update.
> The reason, I believe, we currently throw the exception is that we have to 
> prevent the case where a bundle that is getting STARTED or STOPPED triggers 
> an update of itself (directly or indirectly) in the same thread before it has 
> transitioned into RESOLVED or ACTIVE. If that happens, we'd otherwise run 
> into a deadlock which might even involve the global lock (and hence, pretty 
> much deadlock the complete framework). 
> However, we should be able to detect that case separately and only then throw 
> an exception. 



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

[jira] [Resolved] (FELIX-5138) Felix should log underlying exception on failed bundle update

2017-02-10 Thread Karl Pauls (JIRA) 

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

Karl Pauls resolved FELIX-5138.
---
Resolution: Fixed

> Felix should log underlying exception on failed bundle update
> -
>
> Key: FELIX-5138
> URL: https://issues.apache.org/jira/browse/FELIX-5138
> Project: Felix
>  Issue Type: Improvement
>  Components: Framework
>Affects Versions: framework-5.0.1
>Reporter: Jörg Hoh
>Assignee: Karl Pauls
>
> I run an application, which is based on Apache Sling. We recently updated our 
> bundles and I faced this message; as outcome my.custom.bundle wasn't updated 
> properly.
> {noformat}
> 11.12.2015 14:09:36.753 *INFO* [FelixStartLevel] my.custom.bundle BundleEvent 
> RESOLVED
> 11.12.2015 14:09:36.753 *INFO* [FelixStartLevel] my.custom.bundle BundleEvent 
> STARTING
> 11.12.2015 14:09:36.754 INFO [OsgiInstallerImpl] 
> org.apache.sling.installer.core.impl.tasks.BundleUpdateTask Removing failing 
> update task - unable to retry: BundleUpdateTask: 
> TaskResource(url=jcrinstall:/apps/myapp/install/my.custom.bundle-1.5.6-SNAPSHOT.jar,
>  entity=bundle:my.custom.bundle, state=INSTALL, 
> attributes=[org.apache.sling.installer.api.tasks.ResourceTransformer=:28:84:15:,
>  Bundle-SymbolicName=my.custom.bundle, Bundle-Version=1.5.6-SNAPSHOT], 
> digest=1449838063263)
> org.osgi.framework.BundleException: Bundle my.custom.bundle [252] cannot be 
> update, since it is either starting or stopping.
> at org.apache.felix.framework.Felix.updateBundle(Felix.java:2311)
> at org.apache.felix.framework.BundleImpl.update(BundleImpl.java:995)
> at 
> org.apache.sling.installer.core.impl.tasks.BundleUpdateTask.execute(BundleUpdateTask.java:92)
> at 
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.doExecuteTasks(OsgiInstallerImpl.java:847)
> at 
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.executeTasks(OsgiInstallerImpl.java:689)
> at 
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.run(OsgiInstallerImpl.java:265)
> at java.lang.Thread.run(Thread.java:767)
> {noformat}
> According to the code, Felix.updateBundle() prints this message only when 
> acquireBundleLock() throws an IllegalStateException; and this 
> IllegalStatement exception can have 2 different causes.
> It would be good, if the log message contains an information, which of these 
> 2 reasons actually occurred. And it would be even better, if this action is 
> actually retried, as this problem looks like a temporary issue for me.



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

[jira] [Commented] (FELIX-5138) Felix should log underlying exception on failed bundle update

2017-02-10 Thread Karl Pauls (JIRA) 

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

Karl Pauls commented on FELIX-5138:
---

I committed support for FELIX-5528 in r1782457 which hopefully makes this issue 
obsolete in the sense that this Exception shouldn't happen at this point. 
However, I tried to improve the exception messages as well. 

> Felix should log underlying exception on failed bundle update
> -
>
> Key: FELIX-5138
> URL: https://issues.apache.org/jira/browse/FELIX-5138
> Project: Felix
>  Issue Type: Improvement
>  Components: Framework
>Affects Versions: framework-5.0.1
>Reporter: Jörg Hoh
>Assignee: Karl Pauls
>
> I run an application, which is based on Apache Sling. We recently updated our 
> bundles and I faced this message; as outcome my.custom.bundle wasn't updated 
> properly.
> {noformat}
> 11.12.2015 14:09:36.753 *INFO* [FelixStartLevel] my.custom.bundle BundleEvent 
> RESOLVED
> 11.12.2015 14:09:36.753 *INFO* [FelixStartLevel] my.custom.bundle BundleEvent 
> STARTING
> 11.12.2015 14:09:36.754 INFO [OsgiInstallerImpl] 
> org.apache.sling.installer.core.impl.tasks.BundleUpdateTask Removing failing 
> update task - unable to retry: BundleUpdateTask: 
> TaskResource(url=jcrinstall:/apps/myapp/install/my.custom.bundle-1.5.6-SNAPSHOT.jar,
>  entity=bundle:my.custom.bundle, state=INSTALL, 
> attributes=[org.apache.sling.installer.api.tasks.ResourceTransformer=:28:84:15:,
>  Bundle-SymbolicName=my.custom.bundle, Bundle-Version=1.5.6-SNAPSHOT], 
> digest=1449838063263)
> org.osgi.framework.BundleException: Bundle my.custom.bundle [252] cannot be 
> update, since it is either starting or stopping.
> at org.apache.felix.framework.Felix.updateBundle(Felix.java:2311)
> at org.apache.felix.framework.BundleImpl.update(BundleImpl.java:995)
> at 
> org.apache.sling.installer.core.impl.tasks.BundleUpdateTask.execute(BundleUpdateTask.java:92)
> at 
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.doExecuteTasks(OsgiInstallerImpl.java:847)
> at 
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.executeTasks(OsgiInstallerImpl.java:689)
> at 
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.run(OsgiInstallerImpl.java:265)
> at java.lang.Thread.run(Thread.java:767)
> {noformat}
> According to the code, Felix.updateBundle() prints this message only when 
> acquireBundleLock() throws an IllegalStateException; and this 
> IllegalStatement exception can have 2 different causes.
> It would be good, if the log message contains an information, which of these 
> 2 reasons actually occurred. And it would be even better, if this action is 
> actually retried, as this problem looks like a temporary issue for me.



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

Re: [DISCUSS] Release resolver 1.10.2

2017-02-10 Thread Karl Pauls 
I can do the release next week if you don't mind, as I was planning to
do a framework release anyhow (almost done with FELIX-5528 - just need
a bit more testing).

regards,

Karl

On Fri, Feb 10, 2017 at 8:43 AM, Guillaume Nodet  wrote:
> I'd like to get FELIX-5450 and FELIX-5514 out of the door, so unless
> someone volunteer  to do the resolver 1.10.2 release, i'll give it a try
> next week.
>
> Cheers,
> Guillaume



-- 
Karl Pauls
karlpa...@gmail.com

Re: [DISCUSS] Release resolver 1.10.2

2017-02-10 Thread Jean-Baptiste Onofré 
+1 for me.

Regards
JB

On Feb 10, 2017, 03:44, at 03:44, Guillaume Nodet  wrote:
>I'd like to get FELIX-5450 and FELIX-5514 out of the door, so unless
>someone volunteer  to do the resolver 1.10.2 release, i'll give it a
>try
>next week.
>
>Cheers,
>Guillaume

[jira] [Commented] (FELIX-5527) Bundle plugin Embed-Dependency complains about class files in META-INF

2017-02-10 Thread Mark Raynsford (JIRA) 

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

Mark Raynsford commented on FELIX-5527:
---

In a comment to the bndtools-users list, Neil Bartlett noted that this is a 
current limitation of bndtools:

"Bnd does not yet support java 9."

https://groups.google.com/forum/#!topic/bndtools-users/OrTIEE4zHv8

> Bundle plugin Embed-Dependency complains about class files in META-INF
> --
>
> Key: FELIX-5527
> URL: https://issues.apache.org/jira/browse/FELIX-5527
> Project: Felix
>  Issue Type: Bug
>  Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-3.2.0
> Environment: Linux copperhead 4.8.13-1-ARCH #1 SMP PREEMPT Fri Dec 9 
> 07:24:34 CET 2016 x86_64 GNU/Linux
> openjdk version "1.8.0_121"
> OpenJDK Runtime Environment (build 1.8.0_121-b13)
> OpenJDK 64-Bit Server VM (build 25.121-b13, mixed mode)
> Apache Maven 3.3.9 (NON-CANONICAL_2015-11-23T13:17:27+03:00_root; 
> 2015-11-23T10:17:27+00:00)
> Maven home: /opt/maven
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-8-openjdk/jre
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.8.13-1-arch", arch: "amd64", family: "unix"
>Reporter: Mark Raynsford
>  Labels: maven
>
> As of Java 9, it's no longer a mistake to have included class files in the 
> META-INF directory of a bundle. However, if the Embed-Dependency instruction 
> is used to pack the contents of a jar file into a bundle, and the original 
> jar file happened to have class files in META-INF, the execution fails with 
> an error.
> A repro case is included in the following repository:
> https://github.com/io7m/maven-bundle-plugin-bug-20170207
> Just "mvn clean package".



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