Re: [contribution] a Logback integration with OSGi Log 1.4

[Simon Chemouil]

Ray,

Great!

It seems this bundle has to be started before the OSGi LogService
implementation bundle? I'd expect the Activator to use a service tracker?

Simon

Raymond Auge a écrit le 12/04/2018 à 16:44 :
> As promised here's the repo https://github.com/rotty3000/osgi.to.logback
> 
> - Ray
> 
> On Thu, Apr 12, 2018 at 7:23 AM, Simon Chemouil  wrote:
> 
>> Hi,
>>
>> This sounds great. I'd probably use it! I usually use logback with
>> static loggers but I might migrate (back) to OSGi Log 1.4 and that seems
>> like a nice way to do this smoothly.
>>
>> Simon
>>
>>
>> Raymond Auge a écrit le 11/04/2018 à 19:08 :
>>> Hello everyone,
>>>
>>> I'm wondering if there would be interest in the felix project to accept
>> and
>>> host a small integration between the upcoming Log 1.4 specification with
>>> Logback backend.
>>>
>>> The features I have already are:
>>>
>>> - single bundle impl
>>> - generic LogListener that attempts to be the shortest path from the log
>>> record (LogEntry) creation to the Logback appenders (no intermediaries)
>>> - fully integrates all the record details like location, stackframes,
>> etc.
>>> - allows Logback to manage levels for legacy framework, service and
>> bundle
>>> events in a granular fashion by using canonical logger names
>>> - can react to Logback scan (i.e. autoupdate) to dynamically apply level
>>> changes using the new LoggingAdmin
>>> - fully supports all other logback configuration goodness
>>> - makes it very simply pipe all the various Log APIs to the same
>> appenders
>>> (or not) using the same formats (or not) and control all their log levels
>>> in one place: slf4j is native, but I've tested with log4j 1.2/2.x,
>>> commons-logging, JUL, jboss-logging in the same framework
>>>
>>> Of course Felix doesn't have a Log 1.4 impl yet so that is a
>> consideration.
>>>
>>> This small integration has solved so many of the rather bothersome
>> logging
>>> issues I've been suffering the past years and I'd like to share it with
>>> others.
>>>
>>> Sincerely,
>>>
>>
>>
> 
> 

Re: [contribution] a Logback integration with OSGi Log 1.4

[Simon Chemouil]

Hi,

This sounds great. I'd probably use it! I usually use logback with
static loggers but I might migrate (back) to OSGi Log 1.4 and that seems
like a nice way to do this smoothly.

Simon


Raymond Auge a écrit le 11/04/2018 à 19:08 :
> Hello everyone,
> 
> I'm wondering if there would be interest in the felix project to accept and
> host a small integration between the upcoming Log 1.4 specification with
> Logback backend.
> 
> The features I have already are:
> 
> - single bundle impl
> - generic LogListener that attempts to be the shortest path from the log
> record (LogEntry) creation to the Logback appenders (no intermediaries)
> - fully integrates all the record details like location, stackframes, etc.
> - allows Logback to manage levels for legacy framework, service and bundle
> events in a granular fashion by using canonical logger names
> - can react to Logback scan (i.e. autoupdate) to dynamically apply level
> changes using the new LoggingAdmin
> - fully supports all other logback configuration goodness
> - makes it very simply pipe all the various Log APIs to the same appenders
> (or not) using the same formats (or not) and control all their log levels
> in one place: slf4j is native, but I've tested with log4j 1.2/2.x,
> commons-logging, JUL, jboss-logging in the same framework
> 
> Of course Felix doesn't have a Log 1.4 impl yet so that is a consideration.
> 
> This small integration has solved so many of the rather bothersome logging
> issues I've been suffering the past years and I'd like to share it with
> others.
> 
> Sincerely,
> 

[jira] [Commented] (FELIX-4178) Provide method to access Exception thrown by activate method and/or while instantiation

[Simon Chemouil (JIRA)]

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

Simon Chemouil commented on FELIX-4178:
---

I would find this feature useful as well. I also don't think Christoph is 
changing his story.
It makes sense for Apache Felix SCR to expose an API to have a 
status/diagnostic UI, and to discover why components failed (and get the thrown 
exception). This shouldn't be much of a memory issue if only the last exception 
is kept (in case of bundle or prototype components), and I'm sure there are 
smarter ways to design this.
While exceptions are already logged through the log service, it is not 
practical/future-proof to parse log messages to find those that correspond to 
exceptions thrown during the activate method.

> Provide method to access Exception thrown by activate method and/or while 
> instantiation
> ---
>
> Key: FELIX-4178
> URL: https://issues.apache.org/jira/browse/FELIX-4178
> Project: Felix
>  Issue Type: Improvement
>  Components: Declarative Services (SCR)
>Reporter: Christoph Läubrich
>Assignee: David Jencks
>
> Access to the exception a component throws in the activate method or any 
> exception while try to create instance (e.g. no default constructer, class 
> not found...) would help for diagnostic tools depending on the ScrService.



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

Re: git?

[Simon Chemouil]

Richard S. Hall a écrit le 27/10/2015 21:22 :
> Simon,
> 
> You do realize that in Subversion you can just checkout a given 
> subproject, create a patch against it, then delete it, right?

I do. Well I don't want to sound like a fanboy, but Git allows to deal
with multiple remotes (e.g when maintaining a shared private branch) and
makes branching and feature patches, rebasing them as upstream evolves,
much easier and lighter. I used CVS and SVN for years and I feel Git has
made work easier.

-- 
Simon

Re: git?

[Simon Chemouil]

Benson Margulies wrote:
> There was some discussion a while back about git, which I recall
> (perhaps inaccurately) as vaguely positive. It's a lot easier if each
> releasable thing gets its own git repo.

Hi,

At this point it looks like the switch is going to happen, and there has
been this argument repeated a few times that the current situation with
SVN is not broken and that changing will imply significant pain.

It's most likely true :).

However as a user of Felix and its sub-projects, I'd like to state that
this switch would be very welcome and ease working with Felix and
contributing patches a lot.

First, the Felix SVN repo is humongous and mixes so many sub-projects
that it's a pain to navigate through it to get the right ones, the right
branch, the right commit.

Second, there's the problem of hassle-free contribution: when I
encounter an issue, I just want to just fork a sub-project, and create a
pull request and the associated JIRA ticket, and go back to my routine.
But forking the whole felix project just for a single a component is a
big overhead, and last time I tried the Felix Git repo on GitHub did not
look up-to-date. It might not look like it because you guys have your
environments set up and you spent enough time to do so, but that is an
artificial entry barrier to contribution (not because it's difficult,
but because it's so heavy compared to the Git workflow we got used to).

So while this switch might not go as smoothly as hoped, it will also
benefit users and I believe will help the Felix project get
contributors, new committers and even maybe new sub-projects, as long as
there is no new overhead introduced by the way the switch is made :-)

In my experience having one repo per bundle results in the opposite
overhead (having too many repos to clone, update, etc), and I think
having one repo per sub-project is the right compromise. That's also
we've been doing at work for a while (we had one repo per bundle before
for a long time).

Finally, it would be great not to bump versions for bundles that have
not changed just to avoid having several releases prefixes handled by
the maven-release-plugin within the same repository. So I am not
favourable to systematically making all bundles in a sub-project part of
the same multi-module Maven project (and thus share bundle version by
default) for that reason alone.

Although proper package semantic versioning would make this transparent
at runtime (or 'install' time), it makes it impossible to track releases
and the evolution of the different bundles, and generally feels against
OSGi principles' of proper modules and versions.

A big non-binding +1 from me. :)

-- 
Simon Chemouil

Re: [VOTE] Release Apache Felix maven-bundle-plugin 3.0.0

[Simon Chemouil]

+1!!! (non-binding) :-)

Le 22/09/2015 13:14, dav...@apache.org a écrit :
> Hi all,
> 
> I'm calling a vote on the Felix maven-bundle-plugin release 3.0.0.
> 
> The following issues were resolved:
> FELIX-5047 Disable bnd ScrPlugin by default
> FELIX-5030 Do not require a pom.xml when Polyglot Maven is used
> FELIX-5029 Update to bnd 3.0.0
> 
> Especially the update to bnd 3.0.0 brings many fixes and improvements,
> including support for OSGi Enterprise R6 DS annotations and Metatype
> annotations.
> 
> Given the nature of the new features this release has its version
> increased to the next major version.
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachefelix-1095
> 
> 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 1095 /tmp/felix-mbp-check
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> This vote will remain open for at least 72 hours.
> 
> Best regards,
> 
> David Bosschaert
> 

[jira] [Commented] (FELIX-4857) SCR Gogo commands outputs wrong infos when a component is unsatisfied because of missing configuration

[Simon Chemouil (JIRA)]

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

Simon Chemouil commented on FELIX-4857:
---

Alright, I'll keep you updated on the dev ML. You are right I forgot to update 
the namespace.I will try again asap. Thanks.

> SCR Gogo commands outputs wrong infos when a component is unsatisfied because 
> of missing configuration
> --
>
> Key: FELIX-4857
> URL: https://issues.apache.org/jira/browse/FELIX-4857
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR), Gogo Command
>Affects Versions: gogo.command-0.12.0, scr-1.8.2
>Reporter: Simon Chemouil
>
> The Gogo scr:info command doesn't show when a DS component has 
> Configuration.REQUIRE and is unsatisfied because the configuration is 
> missing. Instead, it marks a reference as unsatisfied even though it is 
> available and consumed elsewhere in the same bundle.
> {noformat}
> $ scr:info 0
> ID: 0
> Name: my-component
> Bundle: my-bundle (56)
> State: unsatisfied 
> Default State: enabled
> Activation: delayed
> Configuration Policy: require
> Activate Method: activate (declared in the descriptor)
> Deactivate Method: deactivate
> Modified Method: -
> Configuration Pid: my-component
> Services: io.lambdacube.service.MyService
> Service Type: service
> Reference: JsonMapper
> Satisfied: unsatisfied
> Service Name: io.lambdacube.core.json.JsonMapper
> Multiple: single
> Optional: mandatory
> Policy: static
> Policy option: reluctant
> (unbound)
> Properties:
> component.id = 0
> component.name = my-component
> {noformat}
> In that example, JsonMapper is actually available. Instead, the scr:info 
> command should state it's unsatisfied because the configuration entry is 
> missing.



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

[jira] [Commented] (FELIX-4857) SCR Gogo commands outputs wrong infos when a component is unsatisfied because of missing configuration

[Simon Chemouil (JIRA)]

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

Simon Chemouil commented on FELIX-4857:
---

I don't know what is the right place to discuss this, but I've given a try to 
trunk. It works fine for current features, but I was unable to get config 
objects (using Annotation classes) to work. SCR fails by stating that "activate 
method [activate] not found; Component will fail". The activate method contains 
my config annotation object as stated in the RFC 190 (as far as I know).

> SCR Gogo commands outputs wrong infos when a component is unsatisfied because 
> of missing configuration
> --
>
> Key: FELIX-4857
> URL: https://issues.apache.org/jira/browse/FELIX-4857
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR), Gogo Command
>Affects Versions: gogo.command-0.12.0, scr-1.8.2
>Reporter: Simon Chemouil
>
> The Gogo scr:info command doesn't show when a DS component has 
> Configuration.REQUIRE and is unsatisfied because the configuration is 
> missing. Instead, it marks a reference as unsatisfied even though it is 
> available and consumed elsewhere in the same bundle.
> {noformat}
> $ scr:info 0
> ID: 0
> Name: my-component
> Bundle: my-bundle (56)
> State: unsatisfied 
> Default State: enabled
> Activation: delayed
> Configuration Policy: require
> Activate Method: activate (declared in the descriptor)
> Deactivate Method: deactivate
> Modified Method: -
> Configuration Pid: my-component
> Services: io.lambdacube.service.MyService
> Service Type: service
> Reference: JsonMapper
> Satisfied: unsatisfied
> Service Name: io.lambdacube.core.json.JsonMapper
> Multiple: single
> Optional: mandatory
> Policy: static
> Policy option: reluctant
> (unbound)
> Properties:
> component.id = 0
> component.name = my-component
> {noformat}
> In that example, JsonMapper is actually available. Instead, the scr:info 
> command should state it's unsatisfied because the configuration entry is 
> missing.



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

[jira] [Commented] (FELIX-4857) SCR Gogo commands outputs wrong infos when a component is unsatisfied because of missing configuration

[Simon Chemouil (JIRA)]

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

Simon Chemouil commented on FELIX-4857:
---

Great. By the way does trunk implement RFC 190 entirely? (or has it become 
Compendium R6 already? I can't find any information on this).

Anyway I'll try to have a look in the upcoming days. Thanks!

> SCR Gogo commands outputs wrong infos when a component is unsatisfied because 
> of missing configuration
> --
>
> Key: FELIX-4857
> URL: https://issues.apache.org/jira/browse/FELIX-4857
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR), Gogo Command
>Affects Versions: gogo.command-0.12.0, scr-1.8.2
>Reporter: Simon Chemouil
>
> The Gogo scr:info command doesn't show when a DS component has 
> Configuration.REQUIRE and is unsatisfied because the configuration is 
> missing. Instead, it marks a reference as unsatisfied even though it is 
> available and consumed elsewhere in the same bundle.
> {noformat}
> $ scr:info 0
> ID: 0
> Name: my-component
> Bundle: my-bundle (56)
> State: unsatisfied 
> Default State: enabled
> Activation: delayed
> Configuration Policy: require
> Activate Method: activate (declared in the descriptor)
> Deactivate Method: deactivate
> Modified Method: -
> Configuration Pid: my-component
> Services: io.lambdacube.service.MyService
> Service Type: service
> Reference: JsonMapper
> Satisfied: unsatisfied
> Service Name: io.lambdacube.core.json.JsonMapper
> Multiple: single
> Optional: mandatory
> Policy: static
> Policy option: reluctant
> (unbound)
> Properties:
> component.id = 0
> component.name = my-component
> {noformat}
> In that example, JsonMapper is actually available. Instead, the scr:info 
> command should state it's unsatisfied because the configuration entry is 
> missing.



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

[jira] [Commented] (FELIX-4851) ConfigAdmin only forwards ConfigurationEvents to ConfigurationListeners which are provided by bundles that are in state ACTIVE

[Simon Chemouil (JIRA)]

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

Simon Chemouil commented on FELIX-4851:
---


I'm on Linux with Apache Maven 3.3.1, a clean local repository and Maven 
central.

I have tens of errors like this:
{noformat}
ERROR: Bundle org.ops4j.pax.tinybundles [15] Error starting 
mvn:org.ops4j.pax.tinybundles/tinybundles/1.0.0 
(org.osgi.framework.BundleException: Unresolved constraint in bundle 
org.ops4j.pax.tinybun
dles [15]: Unable to resolve 15.0: missing requirement [15.0] 
osgi.wiring.package; 
(&(osgi.wiring.package=org.slf4j)(version>=1.6.0)(!(version>=2.0.0))) [caused 
by: Unable to resolve 6.0: missing re
quirement [6.0] osgi.wiring.package; (osgi.wiring.package=javax.xml.parsers)])
org.osgi.framework.BundleException: Unresolved constraint in bundle 
org.ops4j.pax.tinybundles [15]: Unable to resolve 15.0: missing requirement 
[15.0] osgi.wiring.package; (&(osgi.wiring.package=org
.slf4j)(version>=1.6.0)(!(version>=2.0.0))) [caused by: Unable to resolve 6.0: 
missing requirement [6.0] osgi.wiring.package; 
(osgi.wiring.package=javax.xml.parsers)]
{noformat}

Most errors are related to javax packages not being defined in systemPackages() 
in pax exam.



> ConfigAdmin only forwards ConfigurationEvents to ConfigurationListeners which 
> are provided by bundles that are in state ACTIVE
> --
>
> Key: FELIX-4851
> URL: https://issues.apache.org/jira/browse/FELIX-4851
> Project: Felix
>  Issue Type: Bug
>  Components: Configuration Admin
>Affects Versions: configadmin-1.8.2
>Reporter: Jens Offenbach
>Assignee: David Bosschaert
>Priority: Critical
> Fix For: configadmin-1.8.4
>
>
> I am facing a serious problem with the Felix ConfigAdmin in combination with 
> Felix SCR. Let us assume that the SCR bundle becomes activated at last and 
> activates a component that creates a configuration which itself is a 
> precondition for the instantiation of another component 
> (ConfigurationPolicy#REQUIRE). In this case the Felix ConfigAdmin does not 
> deliver the configuration update event to SCR, although SCR has registered a 
> ConfigurationListener in the OSGi Service Registry.
> The problem is caused by line 2029 of the class ConfigurationManager 
> (Version: 1.8.3-SNAPSHOT):
> {code}
> if ( listenerProvider[serviceIndex].getState() == Bundle.ACTIVE && 
> this.listeners[serviceIndex] != null )
> {code}
> In this scenario, the SCR bundle is in state STARTING and reaches the ACTIVE 
> state directly after all available components have been activated. Because of 
> missing Configuration Events caused by the Felix ConfigAdmin, SCR is not able 
> to activate all those components whose preconditions are actually fulfilled. 
> The problem does not occur in combination with the Equinox ConfigAdmin, which 
> does not make the problematic bundle state check.
> I highly recommend removing the bundle state check and change line 2029 into:
> {code}
> if ( this.listeners[serviceIndex] != null ).
> {code}
> It is up to the developer to decide, in which bundle state configuration 
> events are considered to be important or not. In the SCR scenario, the 
> developers rely on the fact that configuration events are delivered 
> independently of their bundle state.



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

[jira] [Commented] (FELIX-4851) ConfigAdmin only forwards ConfigurationEvents to ConfigurationListeners which are provided by bundles that are in state ACTIVE

[Simon Chemouil (JIRA)]

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

Simon Chemouil commented on FELIX-4851:
---


I'm on Linux with Apache Maven 3.3.1, a clean local repository and Maven 
central.

I have tens of errors like this:
{noformat}
ERROR: Bundle org.ops4j.pax.tinybundles [15] Error starting 
mvn:org.ops4j.pax.tinybundles/tinybundles/1.0.0 
(org.osgi.framework.BundleException: Unresolved constraint in bundle 
org.ops4j.pax.tinybun
dles [15]: Unable to resolve 15.0: missing requirement [15.0] 
osgi.wiring.package; 
(&(osgi.wiring.package=org.slf4j)(version>=1.6.0)(!(version>=2.0.0))) [caused 
by: Unable to resolve 6.0: missing re
quirement [6.0] osgi.wiring.package; (osgi.wiring.package=javax.xml.parsers)])
org.osgi.framework.BundleException: Unresolved constraint in bundle 
org.ops4j.pax.tinybundles [15]: Unable to resolve 15.0: missing requirement 
[15.0] osgi.wiring.package; (&(osgi.wiring.package=org
.slf4j)(version>=1.6.0)(!(version>=2.0.0))) [caused by: Unable to resolve 6.0: 
missing requirement [6.0] osgi.wiring.package; 
(osgi.wiring.package=javax.xml.parsers)]
{noformat}

Most errors are related to javax packages not being defined in systemPackages() 
in pax exam.



> ConfigAdmin only forwards ConfigurationEvents to ConfigurationListeners which 
> are provided by bundles that are in state ACTIVE
> --
>
> Key: FELIX-4851
> URL: https://issues.apache.org/jira/browse/FELIX-4851
> Project: Felix
>  Issue Type: Bug
>  Components: Configuration Admin
>Affects Versions: configadmin-1.8.2
>Reporter: Jens Offenbach
>Assignee: David Bosschaert
>Priority: Critical
> Fix For: configadmin-1.8.4
>
>
> I am facing a serious problem with the Felix ConfigAdmin in combination with 
> Felix SCR. Let us assume that the SCR bundle becomes activated at last and 
> activates a component that creates a configuration which itself is a 
> precondition for the instantiation of another component 
> (ConfigurationPolicy#REQUIRE). In this case the Felix ConfigAdmin does not 
> deliver the configuration update event to SCR, although SCR has registered a 
> ConfigurationListener in the OSGi Service Registry.
> The problem is caused by line 2029 of the class ConfigurationManager 
> (Version: 1.8.3-SNAPSHOT):
> {code}
> if ( listenerProvider[serviceIndex].getState() == Bundle.ACTIVE && 
> this.listeners[serviceIndex] != null )
> {code}
> In this scenario, the SCR bundle is in state STARTING and reaches the ACTIVE 
> state directly after all available components have been activated. Because of 
> missing Configuration Events caused by the Felix ConfigAdmin, SCR is not able 
> to activate all those components whose preconditions are actually fulfilled. 
> The problem does not occur in combination with the Equinox ConfigAdmin, which 
> does not make the problematic bundle state check.
> I highly recommend removing the bundle state check and change line 2029 into:
> {code}
> if ( this.listeners[serviceIndex] != null ).
> {code}
> It is up to the developer to decide, in which bundle state configuration 
> events are considered to be important or not. In the SCR scenario, the 
> developers rely on the fact that configuration events are delivered 
> independently of their bundle state.



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

[jira] [Comment Edited] (FELIX-4851) ConfigAdmin only forwards ConfigurationEvents to ConfigurationListeners which are provided by bundles that are in state ACTIVE

[Simon Chemouil (JIRA)]

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

Simon Chemouil edited comment on FELIX-4851 at 4/17/15 1:10 PM:


I'm on Linux with Apache Maven 3.3.1, a clean local repository and Maven 
central.
{noformat}
java version "1.8.0_40"
Java(TM) SE Runtime Environment (build 1.8.0_40-b25)
Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)
{noformat}

I have tens of errors like this:
{noformat}
ERROR: Bundle org.ops4j.pax.tinybundles [15] Error starting 
mvn:org.ops4j.pax.tinybundles/tinybundles/1.0.0 
(org.osgi.framework.BundleException: Unresolved constraint in bundle 
org.ops4j.pax.tinybun
dles [15]: Unable to resolve 15.0: missing requirement [15.0] 
osgi.wiring.package; 
(&(osgi.wiring.package=org.slf4j)(version>=1.6.0)(!(version>=2.0.0))) [caused 
by: Unable to resolve 6.0: missing re
quirement [6.0] osgi.wiring.package; (osgi.wiring.package=javax.xml.parsers)])
org.osgi.framework.BundleException: Unresolved constraint in bundle 
org.ops4j.pax.tinybundles [15]: Unable to resolve 15.0: missing requirement 
[15.0] osgi.wiring.package; (&(osgi.wiring.package=org
.slf4j)(version>=1.6.0)(!(version>=2.0.0))) [caused by: Unable to resolve 6.0: 
missing requirement [6.0] osgi.wiring.package; 
(osgi.wiring.package=javax.xml.parsers)]
{noformat}

Most errors are related to javax packages not being defined in systemPackages() 
in pax exam.

PS: Sorry for the message flood, the JIRA instance is severely lagging.



was (Author: magnet):
I'm on Linux with Apache Maven 3.3.1, a clean local repository and Maven 
central.

I have tens of errors like this:
{noformat}
ERROR: Bundle org.ops4j.pax.tinybundles [15] Error starting 
mvn:org.ops4j.pax.tinybundles/tinybundles/1.0.0 
(org.osgi.framework.BundleException: Unresolved constraint in bundle 
org.ops4j.pax.tinybun
dles [15]: Unable to resolve 15.0: missing requirement [15.0] 
osgi.wiring.package; 
(&(osgi.wiring.package=org.slf4j)(version>=1.6.0)(!(version>=2.0.0))) [caused 
by: Unable to resolve 6.0: missing re
quirement [6.0] osgi.wiring.package; (osgi.wiring.package=javax.xml.parsers)])
org.osgi.framework.BundleException: Unresolved constraint in bundle 
org.ops4j.pax.tinybundles [15]: Unable to resolve 15.0: missing requirement 
[15.0] osgi.wiring.package; (&(osgi.wiring.package=org
.slf4j)(version>=1.6.0)(!(version>=2.0.0))) [caused by: Unable to resolve 6.0: 
missing requirement [6.0] osgi.wiring.package; 
(osgi.wiring.package=javax.xml.parsers)]
{noformat}

Most errors are related to javax packages not being defined in systemPackages() 
in pax exam.

PS: Sorry for the message flood, the JIRA instance is severely lagging.


> ConfigAdmin only forwards ConfigurationEvents to ConfigurationListeners which 
> are provided by bundles that are in state ACTIVE
> --
>
> Key: FELIX-4851
> URL: https://issues.apache.org/jira/browse/FELIX-4851
> Project: Felix
>  Issue Type: Bug
>  Components: Configuration Admin
>Affects Versions: configadmin-1.8.2
>Reporter: Jens Offenbach
>Assignee: David Bosschaert
>Priority: Critical
> Fix For: configadmin-1.8.4
>
>
> I am facing a serious problem with the Felix ConfigAdmin in combination with 
> Felix SCR. Let us assume that the SCR bundle becomes activated at last and 
> activates a component that creates a configuration which itself is a 
> precondition for the instantiation of another component 
> (ConfigurationPolicy#REQUIRE). In this case the Felix ConfigAdmin does not 
> deliver the configuration update event to SCR, although SCR has registered a 
> ConfigurationListener in the OSGi Service Registry.
> The problem is caused by line 2029 of the class ConfigurationManager 
> (Version: 1.8.3-SNAPSHOT):
> {code}
> if ( listenerProvider[serviceIndex].getState() == Bundle.ACTIVE && 
> this.listeners[serviceIndex] != null )
> {code}
> In this scenario, the SCR bundle is in state STARTING and reaches the ACTIVE 
> state directly after all available components have been activated. Because of 
> missing Configuration Events caused by the Felix ConfigAdmin, SCR is not able 
> to activate all those components whose preconditions are actually fulfilled. 
> The problem does not occur in combination with the Equinox ConfigAdmin, which 
> does not make the problematic bundle state check.
> I highly recommend removing the bundle state check and change line 2029 into:
> {code}
> if ( this.listeners[serviceIndex] != null ).
> {c

[jira] [Issue Comment Deleted] (FELIX-4851) ConfigAdmin only forwards ConfigurationEvents to ConfigurationListeners which are provided by bundles that are in state ACTIVE

[Simon Chemouil (JIRA)]

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

Simon Chemouil updated FELIX-4851:
--
Comment: was deleted

(was: 
I'm on Linux with Apache Maven 3.3.1, a clean local repository and Maven 
central.

I have tens of errors like this:
{noformat}
ERROR: Bundle org.ops4j.pax.tinybundles [15] Error starting 
mvn:org.ops4j.pax.tinybundles/tinybundles/1.0.0 
(org.osgi.framework.BundleException: Unresolved constraint in bundle 
org.ops4j.pax.tinybun
dles [15]: Unable to resolve 15.0: missing requirement [15.0] 
osgi.wiring.package; 
(&(osgi.wiring.package=org.slf4j)(version>=1.6.0)(!(version>=2.0.0))) [caused 
by: Unable to resolve 6.0: missing re
quirement [6.0] osgi.wiring.package; (osgi.wiring.package=javax.xml.parsers)])
org.osgi.framework.BundleException: Unresolved constraint in bundle 
org.ops4j.pax.tinybundles [15]: Unable to resolve 15.0: missing requirement 
[15.0] osgi.wiring.package; (&(osgi.wiring.package=org
.slf4j)(version>=1.6.0)(!(version>=2.0.0))) [caused by: Unable to resolve 6.0: 
missing requirement [6.0] osgi.wiring.package; 
(osgi.wiring.package=javax.xml.parsers)]
{noformat}

Most errors are related to javax packages not being defined in systemPackages() 
in pax exam.

)

> ConfigAdmin only forwards ConfigurationEvents to ConfigurationListeners which 
> are provided by bundles that are in state ACTIVE
> --
>
> Key: FELIX-4851
> URL: https://issues.apache.org/jira/browse/FELIX-4851
> Project: Felix
>  Issue Type: Bug
>  Components: Configuration Admin
>Affects Versions: configadmin-1.8.2
>Reporter: Jens Offenbach
>Assignee: David Bosschaert
>Priority: Critical
> Fix For: configadmin-1.8.4
>
>
> I am facing a serious problem with the Felix ConfigAdmin in combination with 
> Felix SCR. Let us assume that the SCR bundle becomes activated at last and 
> activates a component that creates a configuration which itself is a 
> precondition for the instantiation of another component 
> (ConfigurationPolicy#REQUIRE). In this case the Felix ConfigAdmin does not 
> deliver the configuration update event to SCR, although SCR has registered a 
> ConfigurationListener in the OSGi Service Registry.
> The problem is caused by line 2029 of the class ConfigurationManager 
> (Version: 1.8.3-SNAPSHOT):
> {code}
> if ( listenerProvider[serviceIndex].getState() == Bundle.ACTIVE && 
> this.listeners[serviceIndex] != null )
> {code}
> In this scenario, the SCR bundle is in state STARTING and reaches the ACTIVE 
> state directly after all available components have been activated. Because of 
> missing Configuration Events caused by the Felix ConfigAdmin, SCR is not able 
> to activate all those components whose preconditions are actually fulfilled. 
> The problem does not occur in combination with the Equinox ConfigAdmin, which 
> does not make the problematic bundle state check.
> I highly recommend removing the bundle state check and change line 2029 into:
> {code}
> if ( this.listeners[serviceIndex] != null ).
> {code}
> It is up to the developer to decide, in which bundle state configuration 
> events are considered to be important or not. In the SCR scenario, the 
> developers rely on the fact that configuration events are delivered 
> independently of their bundle state.



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

[jira] [Issue Comment Deleted] (FELIX-4851) ConfigAdmin only forwards ConfigurationEvents to ConfigurationListeners which are provided by bundles that are in state ACTIVE

[Simon Chemouil (JIRA)]

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

Simon Chemouil updated FELIX-4851:
--
Comment: was deleted

(was: 
I'm on Linux with Apache Maven 3.3.1, a clean local repository and Maven 
central.

I have tens of errors like this:
{noformat}
ERROR: Bundle org.ops4j.pax.tinybundles [15] Error starting 
mvn:org.ops4j.pax.tinybundles/tinybundles/1.0.0 
(org.osgi.framework.BundleException: Unresolved constraint in bundle 
org.ops4j.pax.tinybun
dles [15]: Unable to resolve 15.0: missing requirement [15.0] 
osgi.wiring.package; 
(&(osgi.wiring.package=org.slf4j)(version>=1.6.0)(!(version>=2.0.0))) [caused 
by: Unable to resolve 6.0: missing re
quirement [6.0] osgi.wiring.package; (osgi.wiring.package=javax.xml.parsers)])
org.osgi.framework.BundleException: Unresolved constraint in bundle 
org.ops4j.pax.tinybundles [15]: Unable to resolve 15.0: missing requirement 
[15.0] osgi.wiring.package; (&(osgi.wiring.package=org
.slf4j)(version>=1.6.0)(!(version>=2.0.0))) [caused by: Unable to resolve 6.0: 
missing requirement [6.0] osgi.wiring.package; 
(osgi.wiring.package=javax.xml.parsers)]
{noformat}

Most errors are related to javax packages not being defined in systemPackages() 
in pax exam.

)

> ConfigAdmin only forwards ConfigurationEvents to ConfigurationListeners which 
> are provided by bundles that are in state ACTIVE
> --
>
> Key: FELIX-4851
> URL: https://issues.apache.org/jira/browse/FELIX-4851
> Project: Felix
>  Issue Type: Bug
>  Components: Configuration Admin
>Affects Versions: configadmin-1.8.2
>Reporter: Jens Offenbach
>Assignee: David Bosschaert
>Priority: Critical
> Fix For: configadmin-1.8.4
>
>
> I am facing a serious problem with the Felix ConfigAdmin in combination with 
> Felix SCR. Let us assume that the SCR bundle becomes activated at last and 
> activates a component that creates a configuration which itself is a 
> precondition for the instantiation of another component 
> (ConfigurationPolicy#REQUIRE). In this case the Felix ConfigAdmin does not 
> deliver the configuration update event to SCR, although SCR has registered a 
> ConfigurationListener in the OSGi Service Registry.
> The problem is caused by line 2029 of the class ConfigurationManager 
> (Version: 1.8.3-SNAPSHOT):
> {code}
> if ( listenerProvider[serviceIndex].getState() == Bundle.ACTIVE && 
> this.listeners[serviceIndex] != null )
> {code}
> In this scenario, the SCR bundle is in state STARTING and reaches the ACTIVE 
> state directly after all available components have been activated. Because of 
> missing Configuration Events caused by the Felix ConfigAdmin, SCR is not able 
> to activate all those components whose preconditions are actually fulfilled. 
> The problem does not occur in combination with the Equinox ConfigAdmin, which 
> does not make the problematic bundle state check.
> I highly recommend removing the bundle state check and change line 2029 into:
> {code}
> if ( this.listeners[serviceIndex] != null ).
> {code}
> It is up to the developer to decide, in which bundle state configuration 
> events are considered to be important or not. In the SCR scenario, the 
> developers rely on the fact that configuration events are delivered 
> independently of their bundle state.



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

[jira] [Comment Edited] (FELIX-4851) ConfigAdmin only forwards ConfigurationEvents to ConfigurationListeners which are provided by bundles that are in state ACTIVE

[Simon Chemouil (JIRA)]

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

Simon Chemouil edited comment on FELIX-4851 at 4/17/15 1:09 PM:


I'm on Linux with Apache Maven 3.3.1, a clean local repository and Maven 
central.

I have tens of errors like this:
{noformat}
ERROR: Bundle org.ops4j.pax.tinybundles [15] Error starting 
mvn:org.ops4j.pax.tinybundles/tinybundles/1.0.0 
(org.osgi.framework.BundleException: Unresolved constraint in bundle 
org.ops4j.pax.tinybun
dles [15]: Unable to resolve 15.0: missing requirement [15.0] 
osgi.wiring.package; 
(&(osgi.wiring.package=org.slf4j)(version>=1.6.0)(!(version>=2.0.0))) [caused 
by: Unable to resolve 6.0: missing re
quirement [6.0] osgi.wiring.package; (osgi.wiring.package=javax.xml.parsers)])
org.osgi.framework.BundleException: Unresolved constraint in bundle 
org.ops4j.pax.tinybundles [15]: Unable to resolve 15.0: missing requirement 
[15.0] osgi.wiring.package; (&(osgi.wiring.package=org
.slf4j)(version>=1.6.0)(!(version>=2.0.0))) [caused by: Unable to resolve 6.0: 
missing requirement [6.0] osgi.wiring.package; 
(osgi.wiring.package=javax.xml.parsers)]
{noformat}

Most errors are related to javax packages not being defined in systemPackages() 
in pax exam.

PS: Sorry for the message flood, the JIRA instance is severely lagging.



was (Author: magnet):

I'm on Linux with Apache Maven 3.3.1, a clean local repository and Maven 
central.

I have tens of errors like this:
{noformat}
ERROR: Bundle org.ops4j.pax.tinybundles [15] Error starting 
mvn:org.ops4j.pax.tinybundles/tinybundles/1.0.0 
(org.osgi.framework.BundleException: Unresolved constraint in bundle 
org.ops4j.pax.tinybun
dles [15]: Unable to resolve 15.0: missing requirement [15.0] 
osgi.wiring.package; 
(&(osgi.wiring.package=org.slf4j)(version>=1.6.0)(!(version>=2.0.0))) [caused 
by: Unable to resolve 6.0: missing re
quirement [6.0] osgi.wiring.package; (osgi.wiring.package=javax.xml.parsers)])
org.osgi.framework.BundleException: Unresolved constraint in bundle 
org.ops4j.pax.tinybundles [15]: Unable to resolve 15.0: missing requirement 
[15.0] osgi.wiring.package; (&(osgi.wiring.package=org
.slf4j)(version>=1.6.0)(!(version>=2.0.0))) [caused by: Unable to resolve 6.0: 
missing requirement [6.0] osgi.wiring.package; 
(osgi.wiring.package=javax.xml.parsers)]
{noformat}

Most errors are related to javax packages not being defined in systemPackages() 
in pax exam.



> ConfigAdmin only forwards ConfigurationEvents to ConfigurationListeners which 
> are provided by bundles that are in state ACTIVE
> --
>
> Key: FELIX-4851
> URL: https://issues.apache.org/jira/browse/FELIX-4851
> Project: Felix
>  Issue Type: Bug
>  Components: Configuration Admin
>Affects Versions: configadmin-1.8.2
>Reporter: Jens Offenbach
>Assignee: David Bosschaert
>Priority: Critical
> Fix For: configadmin-1.8.4
>
>
> I am facing a serious problem with the Felix ConfigAdmin in combination with 
> Felix SCR. Let us assume that the SCR bundle becomes activated at last and 
> activates a component that creates a configuration which itself is a 
> precondition for the instantiation of another component 
> (ConfigurationPolicy#REQUIRE). In this case the Felix ConfigAdmin does not 
> deliver the configuration update event to SCR, although SCR has registered a 
> ConfigurationListener in the OSGi Service Registry.
> The problem is caused by line 2029 of the class ConfigurationManager 
> (Version: 1.8.3-SNAPSHOT):
> {code}
> if ( listenerProvider[serviceIndex].getState() == Bundle.ACTIVE && 
> this.listeners[serviceIndex] != null )
> {code}
> In this scenario, the SCR bundle is in state STARTING and reaches the ACTIVE 
> state directly after all available components have been activated. Because of 
> missing Configuration Events caused by the Felix ConfigAdmin, SCR is not able 
> to activate all those components whose preconditions are actually fulfilled. 
> The problem does not occur in combination with the Equinox ConfigAdmin, which 
> does not make the problematic bundle state check.
> I highly recommend removing the bundle state check and change line 2029 into:
> {code}
> if ( this.listeners[serviceIndex] != null ).
> {code}
> It is up to the developer to decide, in which bundle state configuration 
> events are considered to be important or not. In the SCR scenario, the 
> developers rely on the fact that configuration events are delivered 
> independently of their bundle state.



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

[jira] [Commented] (FELIX-4851) ConfigAdmin only forwards ConfigurationEvents to ConfigurationListeners which are provided by bundles that are in state ACTIVE

[Simon Chemouil (JIRA)]

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

Simon Chemouil commented on FELIX-4851:
---


I'm on Linux with Apache Maven 3.3.1, a clean local repository and Maven 
central.

I have tens of errors like this:
{noformat}
ERROR: Bundle org.ops4j.pax.tinybundles [15] Error starting 
mvn:org.ops4j.pax.tinybundles/tinybundles/1.0.0 
(org.osgi.framework.BundleException: Unresolved constraint in bundle 
org.ops4j.pax.tinybun
dles [15]: Unable to resolve 15.0: missing requirement [15.0] 
osgi.wiring.package; 
(&(osgi.wiring.package=org.slf4j)(version>=1.6.0)(!(version>=2.0.0))) [caused 
by: Unable to resolve 6.0: missing re
quirement [6.0] osgi.wiring.package; (osgi.wiring.package=javax.xml.parsers)])
org.osgi.framework.BundleException: Unresolved constraint in bundle 
org.ops4j.pax.tinybundles [15]: Unable to resolve 15.0: missing requirement 
[15.0] osgi.wiring.package; (&(osgi.wiring.package=org
.slf4j)(version>=1.6.0)(!(version>=2.0.0))) [caused by: Unable to resolve 6.0: 
missing requirement [6.0] osgi.wiring.package; 
(osgi.wiring.package=javax.xml.parsers)]
{noformat}

Most errors are related to javax packages not being defined in systemPackages() 
in pax exam.



> ConfigAdmin only forwards ConfigurationEvents to ConfigurationListeners which 
> are provided by bundles that are in state ACTIVE
> --
>
> Key: FELIX-4851
> URL: https://issues.apache.org/jira/browse/FELIX-4851
> Project: Felix
>  Issue Type: Bug
>  Components: Configuration Admin
>Affects Versions: configadmin-1.8.2
>Reporter: Jens Offenbach
>Assignee: David Bosschaert
>Priority: Critical
> Fix For: configadmin-1.8.4
>
>
> I am facing a serious problem with the Felix ConfigAdmin in combination with 
> Felix SCR. Let us assume that the SCR bundle becomes activated at last and 
> activates a component that creates a configuration which itself is a 
> precondition for the instantiation of another component 
> (ConfigurationPolicy#REQUIRE). In this case the Felix ConfigAdmin does not 
> deliver the configuration update event to SCR, although SCR has registered a 
> ConfigurationListener in the OSGi Service Registry.
> The problem is caused by line 2029 of the class ConfigurationManager 
> (Version: 1.8.3-SNAPSHOT):
> {code}
> if ( listenerProvider[serviceIndex].getState() == Bundle.ACTIVE && 
> this.listeners[serviceIndex] != null )
> {code}
> In this scenario, the SCR bundle is in state STARTING and reaches the ACTIVE 
> state directly after all available components have been activated. Because of 
> missing Configuration Events caused by the Felix ConfigAdmin, SCR is not able 
> to activate all those components whose preconditions are actually fulfilled. 
> The problem does not occur in combination with the Equinox ConfigAdmin, which 
> does not make the problematic bundle state check.
> I highly recommend removing the bundle state check and change line 2029 into:
> {code}
> if ( this.listeners[serviceIndex] != null ).
> {code}
> It is up to the developer to decide, in which bundle state configuration 
> events are considered to be important or not. In the SCR scenario, the 
> developers rely on the fact that configuration events are delivered 
> independently of their bundle state.



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

[jira] [Issue Comment Deleted] (FELIX-4851) ConfigAdmin only forwards ConfigurationEvents to ConfigurationListeners which are provided by bundles that are in state ACTIVE

[Simon Chemouil (JIRA)]

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

Simon Chemouil updated FELIX-4851:
--
Comment: was deleted

(was: 
I'm on Linux with Apache Maven 3.3.1, a clean local repository and Maven 
central.

I have tens of errors like this:
{noformat}
ERROR: Bundle org.ops4j.pax.tinybundles [15] Error starting 
mvn:org.ops4j.pax.tinybundles/tinybundles/1.0.0 
(org.osgi.framework.BundleException: Unresolved constraint in bundle 
org.ops4j.pax.tinybun
dles [15]: Unable to resolve 15.0: missing requirement [15.0] 
osgi.wiring.package; 
(&(osgi.wiring.package=org.slf4j)(version>=1.6.0)(!(version>=2.0.0))) [caused 
by: Unable to resolve 6.0: missing re
quirement [6.0] osgi.wiring.package; (osgi.wiring.package=javax.xml.parsers)])
org.osgi.framework.BundleException: Unresolved constraint in bundle 
org.ops4j.pax.tinybundles [15]: Unable to resolve 15.0: missing requirement 
[15.0] osgi.wiring.package; (&(osgi.wiring.package=org
.slf4j)(version>=1.6.0)(!(version>=2.0.0))) [caused by: Unable to resolve 6.0: 
missing requirement [6.0] osgi.wiring.package; 
(osgi.wiring.package=javax.xml.parsers)]
{noformat}

Most errors are related to javax packages not being defined in systemPackages() 
in pax exam.

)

> ConfigAdmin only forwards ConfigurationEvents to ConfigurationListeners which 
> are provided by bundles that are in state ACTIVE
> --
>
> Key: FELIX-4851
> URL: https://issues.apache.org/jira/browse/FELIX-4851
> Project: Felix
>  Issue Type: Bug
>  Components: Configuration Admin
>Affects Versions: configadmin-1.8.2
>Reporter: Jens Offenbach
>Assignee: David Bosschaert
>Priority: Critical
> Fix For: configadmin-1.8.4
>
>
> I am facing a serious problem with the Felix ConfigAdmin in combination with 
> Felix SCR. Let us assume that the SCR bundle becomes activated at last and 
> activates a component that creates a configuration which itself is a 
> precondition for the instantiation of another component 
> (ConfigurationPolicy#REQUIRE). In this case the Felix ConfigAdmin does not 
> deliver the configuration update event to SCR, although SCR has registered a 
> ConfigurationListener in the OSGi Service Registry.
> The problem is caused by line 2029 of the class ConfigurationManager 
> (Version: 1.8.3-SNAPSHOT):
> {code}
> if ( listenerProvider[serviceIndex].getState() == Bundle.ACTIVE && 
> this.listeners[serviceIndex] != null )
> {code}
> In this scenario, the SCR bundle is in state STARTING and reaches the ACTIVE 
> state directly after all available components have been activated. Because of 
> missing Configuration Events caused by the Felix ConfigAdmin, SCR is not able 
> to activate all those components whose preconditions are actually fulfilled. 
> The problem does not occur in combination with the Equinox ConfigAdmin, which 
> does not make the problematic bundle state check.
> I highly recommend removing the bundle state check and change line 2029 into:
> {code}
> if ( this.listeners[serviceIndex] != null ).
> {code}
> It is up to the developer to decide, in which bundle state configuration 
> events are considered to be important or not. In the SCR scenario, the 
> developers rely on the fact that configuration events are delivered 
> independently of their bundle state.



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

[jira] [Issue Comment Deleted] (FELIX-4851) ConfigAdmin only forwards ConfigurationEvents to ConfigurationListeners which are provided by bundles that are in state ACTIVE

[Simon Chemouil (JIRA)]

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

Simon Chemouil updated FELIX-4851:
--
Comment: was deleted

(was: 
I'm on Linux with Apache Maven 3.3.1, a clean local repository and Maven 
central.

I have tens of errors like this:
{noformat}
ERROR: Bundle org.ops4j.pax.tinybundles [15] Error starting 
mvn:org.ops4j.pax.tinybundles/tinybundles/1.0.0 
(org.osgi.framework.BundleException: Unresolved constraint in bundle 
org.ops4j.pax.tinybun
dles [15]: Unable to resolve 15.0: missing requirement [15.0] 
osgi.wiring.package; 
(&(osgi.wiring.package=org.slf4j)(version>=1.6.0)(!(version>=2.0.0))) [caused 
by: Unable to resolve 6.0: missing re
quirement [6.0] osgi.wiring.package; (osgi.wiring.package=javax.xml.parsers)])
org.osgi.framework.BundleException: Unresolved constraint in bundle 
org.ops4j.pax.tinybundles [15]: Unable to resolve 15.0: missing requirement 
[15.0] osgi.wiring.package; (&(osgi.wiring.package=org
.slf4j)(version>=1.6.0)(!(version>=2.0.0))) [caused by: Unable to resolve 6.0: 
missing requirement [6.0] osgi.wiring.package; 
(osgi.wiring.package=javax.xml.parsers)]
{noformat}

Most errors are related to javax packages not being defined in systemPackages() 
in pax exam.

)

> ConfigAdmin only forwards ConfigurationEvents to ConfigurationListeners which 
> are provided by bundles that are in state ACTIVE
> --
>
> Key: FELIX-4851
> URL: https://issues.apache.org/jira/browse/FELIX-4851
> Project: Felix
>  Issue Type: Bug
>  Components: Configuration Admin
>Affects Versions: configadmin-1.8.2
>Reporter: Jens Offenbach
>Assignee: David Bosschaert
>Priority: Critical
> Fix For: configadmin-1.8.4
>
>
> I am facing a serious problem with the Felix ConfigAdmin in combination with 
> Felix SCR. Let us assume that the SCR bundle becomes activated at last and 
> activates a component that creates a configuration which itself is a 
> precondition for the instantiation of another component 
> (ConfigurationPolicy#REQUIRE). In this case the Felix ConfigAdmin does not 
> deliver the configuration update event to SCR, although SCR has registered a 
> ConfigurationListener in the OSGi Service Registry.
> The problem is caused by line 2029 of the class ConfigurationManager 
> (Version: 1.8.3-SNAPSHOT):
> {code}
> if ( listenerProvider[serviceIndex].getState() == Bundle.ACTIVE && 
> this.listeners[serviceIndex] != null )
> {code}
> In this scenario, the SCR bundle is in state STARTING and reaches the ACTIVE 
> state directly after all available components have been activated. Because of 
> missing Configuration Events caused by the Felix ConfigAdmin, SCR is not able 
> to activate all those components whose preconditions are actually fulfilled. 
> The problem does not occur in combination with the Equinox ConfigAdmin, which 
> does not make the problematic bundle state check.
> I highly recommend removing the bundle state check and change line 2029 into:
> {code}
> if ( this.listeners[serviceIndex] != null ).
> {code}
> It is up to the developer to decide, in which bundle state configuration 
> events are considered to be important or not. In the SCR scenario, the 
> developers rely on the fact that configuration events are delivered 
> independently of their bundle state.



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

[jira] [Commented] (FELIX-4851) ConfigAdmin only forwards ConfigurationEvents to ConfigurationListeners which are provided by bundles that are in state ACTIVE

[Simon Chemouil (JIRA)]

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

Simon Chemouil commented on FELIX-4851:
---


I'm on Linux with Apache Maven 3.3.1, a clean local repository and Maven 
central.

I have tens of errors like this:
{noformat}
ERROR: Bundle org.ops4j.pax.tinybundles [15] Error starting 
mvn:org.ops4j.pax.tinybundles/tinybundles/1.0.0 
(org.osgi.framework.BundleException: Unresolved constraint in bundle 
org.ops4j.pax.tinybun
dles [15]: Unable to resolve 15.0: missing requirement [15.0] 
osgi.wiring.package; 
(&(osgi.wiring.package=org.slf4j)(version>=1.6.0)(!(version>=2.0.0))) [caused 
by: Unable to resolve 6.0: missing re
quirement [6.0] osgi.wiring.package; (osgi.wiring.package=javax.xml.parsers)])
org.osgi.framework.BundleException: Unresolved constraint in bundle 
org.ops4j.pax.tinybundles [15]: Unable to resolve 15.0: missing requirement 
[15.0] osgi.wiring.package; (&(osgi.wiring.package=org
.slf4j)(version>=1.6.0)(!(version>=2.0.0))) [caused by: Unable to resolve 6.0: 
missing requirement [6.0] osgi.wiring.package; 
(osgi.wiring.package=javax.xml.parsers)]
{noformat}

Most errors are related to javax packages not being defined in systemPackages() 
in pax exam.



> ConfigAdmin only forwards ConfigurationEvents to ConfigurationListeners which 
> are provided by bundles that are in state ACTIVE
> --
>
> Key: FELIX-4851
> URL: https://issues.apache.org/jira/browse/FELIX-4851
> Project: Felix
>  Issue Type: Bug
>  Components: Configuration Admin
>Affects Versions: configadmin-1.8.2
>Reporter: Jens Offenbach
>Assignee: David Bosschaert
>Priority: Critical
> Fix For: configadmin-1.8.4
>
>
> I am facing a serious problem with the Felix ConfigAdmin in combination with 
> Felix SCR. Let us assume that the SCR bundle becomes activated at last and 
> activates a component that creates a configuration which itself is a 
> precondition for the instantiation of another component 
> (ConfigurationPolicy#REQUIRE). In this case the Felix ConfigAdmin does not 
> deliver the configuration update event to SCR, although SCR has registered a 
> ConfigurationListener in the OSGi Service Registry.
> The problem is caused by line 2029 of the class ConfigurationManager 
> (Version: 1.8.3-SNAPSHOT):
> {code}
> if ( listenerProvider[serviceIndex].getState() == Bundle.ACTIVE && 
> this.listeners[serviceIndex] != null )
> {code}
> In this scenario, the SCR bundle is in state STARTING and reaches the ACTIVE 
> state directly after all available components have been activated. Because of 
> missing Configuration Events caused by the Felix ConfigAdmin, SCR is not able 
> to activate all those components whose preconditions are actually fulfilled. 
> The problem does not occur in combination with the Equinox ConfigAdmin, which 
> does not make the problematic bundle state check.
> I highly recommend removing the bundle state check and change line 2029 into:
> {code}
> if ( this.listeners[serviceIndex] != null ).
> {code}
> It is up to the developer to decide, in which bundle state configuration 
> events are considered to be important or not. In the SCR scenario, the 
> developers rely on the fact that configuration events are delivered 
> independently of their bundle state.



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

[jira] [Commented] (FELIX-4851) ConfigAdmin only forwards ConfigurationEvents to ConfigurationListeners which are provided by bundles that are in state ACTIVE

[Simon Chemouil (JIRA)]

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

Simon Chemouil commented on FELIX-4851:
---


I'm on Linux with Apache Maven 3.3.1, a clean local repository and Maven 
central.

I have tens of errors like this:
{noformat}
ERROR: Bundle org.ops4j.pax.tinybundles [15] Error starting 
mvn:org.ops4j.pax.tinybundles/tinybundles/1.0.0 
(org.osgi.framework.BundleException: Unresolved constraint in bundle 
org.ops4j.pax.tinybun
dles [15]: Unable to resolve 15.0: missing requirement [15.0] 
osgi.wiring.package; 
(&(osgi.wiring.package=org.slf4j)(version>=1.6.0)(!(version>=2.0.0))) [caused 
by: Unable to resolve 6.0: missing re
quirement [6.0] osgi.wiring.package; (osgi.wiring.package=javax.xml.parsers)])
org.osgi.framework.BundleException: Unresolved constraint in bundle 
org.ops4j.pax.tinybundles [15]: Unable to resolve 15.0: missing requirement 
[15.0] osgi.wiring.package; (&(osgi.wiring.package=org
.slf4j)(version>=1.6.0)(!(version>=2.0.0))) [caused by: Unable to resolve 6.0: 
missing requirement [6.0] osgi.wiring.package; 
(osgi.wiring.package=javax.xml.parsers)]
{noformat}

Most errors are related to javax packages not being defined in systemPackages() 
in pax exam.



> ConfigAdmin only forwards ConfigurationEvents to ConfigurationListeners which 
> are provided by bundles that are in state ACTIVE
> --
>
> Key: FELIX-4851
> URL: https://issues.apache.org/jira/browse/FELIX-4851
> Project: Felix
>  Issue Type: Bug
>  Components: Configuration Admin
>Affects Versions: configadmin-1.8.2
>Reporter: Jens Offenbach
>Assignee: David Bosschaert
>Priority: Critical
> Fix For: configadmin-1.8.4
>
>
> I am facing a serious problem with the Felix ConfigAdmin in combination with 
> Felix SCR. Let us assume that the SCR bundle becomes activated at last and 
> activates a component that creates a configuration which itself is a 
> precondition for the instantiation of another component 
> (ConfigurationPolicy#REQUIRE). In this case the Felix ConfigAdmin does not 
> deliver the configuration update event to SCR, although SCR has registered a 
> ConfigurationListener in the OSGi Service Registry.
> The problem is caused by line 2029 of the class ConfigurationManager 
> (Version: 1.8.3-SNAPSHOT):
> {code}
> if ( listenerProvider[serviceIndex].getState() == Bundle.ACTIVE && 
> this.listeners[serviceIndex] != null )
> {code}
> In this scenario, the SCR bundle is in state STARTING and reaches the ACTIVE 
> state directly after all available components have been activated. Because of 
> missing Configuration Events caused by the Felix ConfigAdmin, SCR is not able 
> to activate all those components whose preconditions are actually fulfilled. 
> The problem does not occur in combination with the Equinox ConfigAdmin, which 
> does not make the problematic bundle state check.
> I highly recommend removing the bundle state check and change line 2029 into:
> {code}
> if ( this.listeners[serviceIndex] != null ).
> {code}
> It is up to the developer to decide, in which bundle state configuration 
> events are considered to be important or not. In the SCR scenario, the 
> developers rely on the fact that configuration events are delivered 
> independently of their bundle state.



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

[jira] [Comment Edited] (FELIX-4851) ConfigAdmin only forwards ConfigurationEvents to ConfigurationListeners which are provided by bundles that are in state ACTIVE

[Simon Chemouil (JIRA)]

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

Simon Chemouil edited comment on FELIX-4851 at 4/17/15 12:50 PM:
-

The fix seems to work for me. I have a test environment where the current 
release of ConfigAdmin consistently fails at updating my DS components and  
switching  the configadmin impl with the current snapshot fixes the problem. 
Tried a few times back and forth and it seems OK. Thanks a lot!

On a related note, the pax-exam integration tests on ConfigAdmin are failing 
with deployment errors using mvn clean install. I had to skipTests to build the 
snapshot. I know that's another issue, but for the record I have fixed it a few 
weeks ago when I was having a look at the current issue and pushed it here 
https://github.com/livingobjects/felix-configadmin. Please tell me if the build 
is broken for you as well so that I can open another issue and extract a patch.

~cziegeler: I opened FELIX-4857 for the scr command issue.


was (Author: magnet):
The fix seems to work for me. I have a test environment where the current 
release of ConfigAdmin consistently fails at updating my DS components and  
switching  the configadmin impl with the current snapshot fixes the problem. 
Tries a few times back and forth and it seems OK. Thanks a lot!

On a related note, the pax-exam integration tests on ConfigAdmin are failing 
with deployment errors using mvn clean install. I had to skipTests to build the 
snapshot. I know that's another issue, but for the record I have fixed it a few 
weeks ago when I was having a look at the current issue and pushed it here 
https://github.com/livingobjects/felix-configadmin. Please tell me if the build 
is broken for you as well so that I can open another issue and extract a patch.

~cziegeler: I opened FELIX-4857 for the scr command issue.

> ConfigAdmin only forwards ConfigurationEvents to ConfigurationListeners which 
> are provided by bundles that are in state ACTIVE
> --
>
> Key: FELIX-4851
> URL: https://issues.apache.org/jira/browse/FELIX-4851
> Project: Felix
>  Issue Type: Bug
>  Components: Configuration Admin
>Affects Versions: configadmin-1.8.2
>Reporter: Jens Offenbach
>Assignee: David Bosschaert
>Priority: Critical
> Fix For: configadmin-1.8.4
>
>
> I am facing a serious problem with the Felix ConfigAdmin in combination with 
> Felix SCR. Let us assume that the SCR bundle becomes activated at last and 
> activates a component that creates a configuration which itself is a 
> precondition for the instantiation of another component 
> (ConfigurationPolicy#REQUIRE). In this case the Felix ConfigAdmin does not 
> deliver the configuration update event to SCR, although SCR has registered a 
> ConfigurationListener in the OSGi Service Registry.
> The problem is caused by line 2029 of the class ConfigurationManager 
> (Version: 1.8.3-SNAPSHOT):
> {code}
> if ( listenerProvider[serviceIndex].getState() == Bundle.ACTIVE && 
> this.listeners[serviceIndex] != null )
> {code}
> In this scenario, the SCR bundle is in state STARTING and reaches the ACTIVE 
> state directly after all available components have been activated. Because of 
> missing Configuration Events caused by the Felix ConfigAdmin, SCR is not able 
> to activate all those components whose preconditions are actually fulfilled. 
> The problem does not occur in combination with the Equinox ConfigAdmin, which 
> does not make the problematic bundle state check.
> I highly recommend removing the bundle state check and change line 2029 into:
> {code}
> if ( this.listeners[serviceIndex] != null ).
> {code}
> It is up to the developer to decide, in which bundle state configuration 
> events are considered to be important or not. In the SCR scenario, the 
> developers rely on the fact that configuration events are delivered 
> independently of their bundle state.



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

[jira] [Commented] (FELIX-4851) ConfigAdmin only forwards ConfigurationEvents to ConfigurationListeners which are provided by bundles that are in state ACTIVE

[Simon Chemouil (JIRA)]

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

Simon Chemouil commented on FELIX-4851:
---

The fix seems to work for me. I have a test environment where the current 
release of ConfigAdmin consistently fails at updating my DS components and  
switching  the configadmin impl with the current snapshot fixes the problem. 
Tries a few times back and forth and it seems OK. Thanks a lot!

On a related note, the pax-exam integration tests on ConfigAdmin are failing 
with deployment errors using mvn clean install. I had to skipTests to build the 
snapshot. I know that's another issue, but for the record I have fixed it a few 
weeks ago when I was having a look at the current issue and pushed it here 
https://github.com/livingobjects/felix-configadmin. Please tell me if the build 
is broken for you as well so that I can open another issue and extract a patch.

~cziegeler: I opened FELIX-4857 for the scr command issue.

> ConfigAdmin only forwards ConfigurationEvents to ConfigurationListeners which 
> are provided by bundles that are in state ACTIVE
> --
>
> Key: FELIX-4851
> URL: https://issues.apache.org/jira/browse/FELIX-4851
> Project: Felix
>  Issue Type: Bug
>  Components: Configuration Admin
>Affects Versions: configadmin-1.8.2
>Reporter: Jens Offenbach
>Assignee: David Bosschaert
>Priority: Critical
> Fix For: configadmin-1.8.4
>
>
> I am facing a serious problem with the Felix ConfigAdmin in combination with 
> Felix SCR. Let us assume that the SCR bundle becomes activated at last and 
> activates a component that creates a configuration which itself is a 
> precondition for the instantiation of another component 
> (ConfigurationPolicy#REQUIRE). In this case the Felix ConfigAdmin does not 
> deliver the configuration update event to SCR, although SCR has registered a 
> ConfigurationListener in the OSGi Service Registry.
> The problem is caused by line 2029 of the class ConfigurationManager 
> (Version: 1.8.3-SNAPSHOT):
> {code}
> if ( listenerProvider[serviceIndex].getState() == Bundle.ACTIVE && 
> this.listeners[serviceIndex] != null )
> {code}
> In this scenario, the SCR bundle is in state STARTING and reaches the ACTIVE 
> state directly after all available components have been activated. Because of 
> missing Configuration Events caused by the Felix ConfigAdmin, SCR is not able 
> to activate all those components whose preconditions are actually fulfilled. 
> The problem does not occur in combination with the Equinox ConfigAdmin, which 
> does not make the problematic bundle state check.
> I highly recommend removing the bundle state check and change line 2029 into:
> {code}
> if ( this.listeners[serviceIndex] != null ).
> {code}
> It is up to the developer to decide, in which bundle state configuration 
> events are considered to be important or not. In the SCR scenario, the 
> developers rely on the fact that configuration events are delivered 
> independently of their bundle state.



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

[jira] [Created] (FELIX-4857) SCR Gogo commands outputs wrong infos when a component is unsatisfied because of missing configuration

[Simon Chemouil (JIRA)]

Simon Chemouil created FELIX-4857:
-

 Summary: SCR Gogo commands outputs wrong infos when a component is 
unsatisfied because of missing configuration
 Key: FELIX-4857
 URL: https://issues.apache.org/jira/browse/FELIX-4857
 Project: Felix
  Issue Type: Bug
  Components: Declarative Services (SCR), Gogo Command
Affects Versions: scr-1.8.2, gogo.command-0.12.0
Reporter: Simon Chemouil


The Gogo scr:info command doesn't show when a DS component has 
Configuration.REQUIRE and is unsatisfied because the configuration is missing. 
Instead, it marks a reference as unsatisfied even though it is available and 
consumed elsewhere in the same bundle.

{noformat}
$ scr:info 0
ID: 0
Name: my-component
Bundle: my-bundle (56)
State: unsatisfied 
Default State: enabled
Activation: delayed
Configuration Policy: require
Activate Method: activate (declared in the descriptor)
Deactivate Method: deactivate
Modified Method: -
Configuration Pid: my-component
Services: io.lambdacube.service.MyService
Service Type: service
Reference: JsonMapper
Satisfied: unsatisfied
Service Name: io.lambdacube.core.json.JsonMapper
Multiple: single
Optional: mandatory
Policy: static
Policy option: reluctant
(unbound)
Properties:
component.id = 0
component.name = my-component
{noformat}

In that example, JsonMapper is actually available. Instead, the scr:info 
command should state it's unsatisfied because the configuration entry is 
missing.



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

[jira] [Commented] (FELIX-4851) ConfigAdmin only forwards ConfigurationEvents to ConfigurationListeners which are provided by bundles that are in state ACTIVE

[Simon Chemouil (JIRA)]

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

Simon Chemouil commented on FELIX-4851:
---

~davidb: Thanks. I'll try it right now but that will take some time, I know one 
of our integration servers used to always fail (on my dev machine, it rarely 
happened)
~cziegeler: Sure thing.

> ConfigAdmin only forwards ConfigurationEvents to ConfigurationListeners which 
> are provided by bundles that are in state ACTIVE
> --
>
> Key: FELIX-4851
> URL: https://issues.apache.org/jira/browse/FELIX-4851
> Project: Felix
>  Issue Type: Bug
>  Components: Configuration Admin
>Affects Versions: configadmin-1.8.2
>Reporter: Jens Offenbach
>Assignee: David Bosschaert
>Priority: Critical
> Fix For: configadmin-1.8.4
>
>
> I am facing a serious problem with the Felix ConfigAdmin in combination with 
> Felix SCR. Let us assume that the SCR bundle becomes activated at last and 
> activates a component that creates a configuration which itself is a 
> precondition for the instantiation of another component 
> (ConfigurationPolicy#REQUIRE). In this case the Felix ConfigAdmin does not 
> deliver the configuration update event to SCR, although SCR has registered a 
> ConfigurationListener in the OSGi Service Registry.
> The problem is caused by line 2029 of the class ConfigurationManager 
> (Version: 1.8.3-SNAPSHOT):
> {code}
> if ( listenerProvider[serviceIndex].getState() == Bundle.ACTIVE && 
> this.listeners[serviceIndex] != null )
> {code}
> In this scenario, the SCR bundle is in state STARTING and reaches the ACTIVE 
> state directly after all available components have been activated. Because of 
> missing Configuration Events caused by the Felix ConfigAdmin, SCR is not able 
> to activate all those components whose preconditions are actually fulfilled. 
> The problem does not occur in combination with the Equinox ConfigAdmin, which 
> does not make the problematic bundle state check.
> I highly recommend removing the bundle state check and change line 2029 into:
> {code}
> if ( this.listeners[serviceIndex] != null ).
> {code}
> It is up to the developer to decide, in which bundle state configuration 
> events are considered to be important or not. In the SCR scenario, the 
> developers rely on the fact that configuration events are delivered 
> independently of their bundle state.



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

[DISCUSS] Release config admin 1.8.3

[Simon Chemouil]

Hi,

Since I've seen a bunch of these discuss / release threads lately, I
thought I'd propose one as well ;).

Jens Offenbach reported FELIX-4851[1] a few days ago which has been a
blocker for us both (separately) to use Felix SCR + Config Admin in
production.

It is a critical bug that prevents using Felix ConfigAdmin
implementation to create DS components safely. It's a tricky problem to
debug so who knows how many more experienced it? The same program can
work on some machines or OSes and not on others, depending on how much
time a bundle needs to go from states STARTING to ACTIVE (e.g, a recent
mail "ConfigAdmin 1.8.2 does not call ManagedServiceFactory updates
method" by Balazs Zsoldos in which he states his code doesn't work on
Windows but works on Linux; and works when the configuration is updated
again; that might be the cause?).

As far as I know there have been a few other fixes that would be nice to
see released, but this is the main blocker that imo justifies a release.

I'm not a committer on Felix so I can't propose to apply the patch and
cut the release, but maybe someone will step up? :-)

What do you think?

Thanks,

[1] https://issues.apache.org/jira/browse/FELIX-4851
-- 
Simon Chemouil

[jira] [Commented] (FELIX-4851) ConfigAdmin only forwards ConfigurationEvents to ConfigurationListeners which are provided by bundles that are in state ACTIVE

[Simon Chemouil (JIRA)]

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

Simon Chemouil commented on FELIX-4851:
---

Oh thanks a lot. We're facing the same problem that has been plaguing us for 
some time, and I was thinking to try to find exactly what's happening this 
afternoon, but you just made that useless :).

My workaround so far has been to call configAdmin.getConfiguration(configPid, 
null).update(properties); after all bundles are in the ACTIVE state, which is 
very ugly. 

I believe this fix alone, if it's approved, warrants a new release!

I might as well report that Felix SCR's "scr:info" Gogo command is outputing 
wrong info when the problem happens; it seems it has no way to tell a component 
is unsatisfied because the required configuration was not provided, an instead 
the first required service reference is stated as unsatisfied, even though the 
service is indeed provided and used elsewhere in the same bundle.

> ConfigAdmin only forwards ConfigurationEvents to ConfigurationListeners which 
> are provided by bundles that are in state ACTIVE
> --
>
> Key: FELIX-4851
> URL: https://issues.apache.org/jira/browse/FELIX-4851
> Project: Felix
>  Issue Type: Bug
>  Components: Configuration Admin
>Affects Versions: configadmin-1.8.2
>Reporter: Jens Offenbach
> Fix For: configadmin-1.8.4
>
>
> I am facing a serious problem with the Felix ConfigAdmin in combination with 
> Felix SCR. Let us assume that the SCR bundle becomes activated at last and 
> activates a component that creates a configuration which itself is a 
> precondition for the instantiation of another component 
> (ConfigurationPolicy#REQUIRE). In this case the Felix ConfigAdmin does not 
> deliver the configuration update event to SCR, although SCR has registered a 
> ConfigurationListener in the OSGi Service Registry.
> The problem is caused by line 2029 of the class ConfigurationManager 
> (Version: 1.8.3-SNAPSHOT):
> {code}
> if ( listenerProvider[serviceIndex].getState() == Bundle.ACTIVE && 
> this.listeners[serviceIndex] != null )
> {code}
> In this scenario, the SCR bundle is in state STARTING and reaches the ACTIVE 
> state directly after all available components have been activated. Because of 
> missing Configuration Events caused by the Felix ConfigAdmin, SCR is not able 
> to activate all those components whose preconditions are actually fulfilled. 
> The problem does not occur in combination with the Equinox ConfigAdmin, which 
> does not make the problematic bundle state check.
> I highly recommend removing the bundle state check and change line 2029 into:
> {code}
> if ( this.listeners[serviceIndex] != null ).
> {code}
> It is up to the developer to decide, in which bundle state configuration 
> events are considered to be important or not. In the SCR scenario, the 
> developers rely on the fact that configuration events are delivered 
> independently of their bundle state.



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

[jira] [Closed] (FELIX-3618) [Framework] Should not allow bundles to use generic cap/req headers for osgi.wiring.* namespaces

[Simon Chemouil (JIRA)]

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

Simon Chemouil closed FELIX-3618.
-


Fixed

> [Framework] Should not allow bundles to use generic cap/req headers for 
> osgi.wiring.* namespaces
> 
>
> Key: FELIX-3618
> URL: https://issues.apache.org/jira/browse/FELIX-3618
> Project: Felix
>  Issue Type: Bug
>  Components: Framework
>Affects Versions: framework-4.0.3
>    Reporter: Simon Chemouil
>Assignee: Richard S. Hall
>Priority: Minor
> Fix For: framework-4.2.0
>
>
> I think I found a bug while I playing with 4.3's Bundle Capabilities.
> I tried to convert a simple Export-Package to Provide-Capability.
> Core specification 5.0, §3.3.3 defines the grammar for Provide-Compatibility 
> headers:Provide-Capability ::= capability ( ',' capability )*
> capability ::= name-space 
> ( ’;’ directive | typed-attr )*
> name-space ::= symbolic-name
> typed-attr ::= extended ( ’:’ type ) ’=’ argument
> type ::= scalar | list
> scalar ::= ’String’ | ’Version’ | ’Long’ 
> |   ’Double’ 
> list ::= ’List<’ scalar ’>’
> With my interpretation of the spec:
> Export-Package: com.test.api; version="1.0.0"
> becomes:
> Provide-Capability: osgi.wiring.package; osgi.wiring.package=com.test.api; 
> version:Version=1.0.0
> where osgi.wiring.package is both the namespace and the attribute name for 
> the package name. Please note that the namespace is mandatory.
> This is consistent with the Require-Capability statement:
> osgi.wiring.package; 
> (&(osgi.wiring.package=com.test.api)(version>=1.0.0)(!(version>=2.0.0))) 
> resolved by:
>osgi.wiring.package; com.test.api 1.0.0 from com.test.api [41]
> If I use this header and install my bundle, using Felix 4.0.3 I get:
> g! inspect c * 41
> com.test.api [41] provides:
> ---
> osgi.wiring.bundle; com.test.api 1.0.0 [UNUSED]
> osgi.wiring.host; com.test.api 1.0.0 [UNUSED]
> osgi.wiring.package; com.test.api 1.0.0 required by:
>com.test.consumer [36]
> osgi.wiring.package; com.test.api 1.0.0 [UNUSED]
> g! 
> Note that the same package is advised as exported *twice* by the bundle with 
> only the first one wired.
> Now, if I use Export-Package, it is exported just once as expected,
> The only way with Provide-Capability to get it exported just once is to omit 
> the namespace, as in:
> Provide-Capability: osgi.wiring.package=com.test.api; version:Version=1.0.0
> However, this is not compliant with the spec, since the namespace is 
> mandatory.
> Finally, a last test where the namespace osgi.wiring.package has no 
> attributes or directives fail with a NullPointerException, it should probably 
> be handled gracefully. 
> Provide-Capability: osgi.wiring.package
> Stacktrace:
> g! start 62
> ERROR: Unable to resolve 62.0 (java.lang.NullPointerException)
> java.lang.NullPointerException
>   at 
> org.apache.felix.framework.BundleWiringImpl.(BundleWiringImpl.java:270)
>   at 
> org.apache.felix.framework.StatefulResolver.markResolvedRevisions(StatefulResolver.java:650)
>   at 
> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:189)
>   at 
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3819)
>   at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
>   at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
>   at org.apache.felix.gogo.command.Basic.start(Basic.java:729)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

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

[jira] [Commented] (FELIX-3749) Refactor the manipulator for better (and extensible) annotation support

[Simon Chemouil (JIRA)]

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

Simon Chemouil commented on FELIX-3749:
---

This seems great, thanks Guillaume! 
How does the new spi mechanism deal with old annotation handlers (that contain 
either ipojo or handler in their package)?

Do you plan on updating the website with some documentation on how to define 
custom handlers? That would be very welcome! 

Thanks again!

> Refactor the manipulator for better (and extensible) annotation support
> ---
>
> Key: FELIX-3749
> URL: https://issues.apache.org/jira/browse/FELIX-3749
> Project: Felix
>  Issue Type: Improvement
>  Components: iPOJO
>Reporter: Guillaume Sauthier
>Assignee: Clement Escoffier
> Fix For: ipojo-manipulator-1.8.8
>
> Attachments: FELIX-3749.patch
>
>
> The manipulator should be extensible for its annotation support.
> Currently, only a fixed set of annotations is supported (hardcoded), and the 
> only way to declares annotation for the manipulator is to follow some naming 
> conventions ("handler" or "ipojo" in the package's name for example).
> I want to be able to say to the manipulator that I want a given behavior to 
> be associated to a particular annotation.
> I also want to easily add to the manipulator external annotation supporting 
> "modules".

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

Re: [VOTE] Release of iPOJO Manipulator 1.8.6 and iPOJO Runtime 1.8.4

[Simon Chemouil]

+1 (non-binding)

This release fixes several blockers for us (we're on trunk just to
work), it's very welcome.

Thanks Clément!

Simon

On Sun, Oct 28, 2012 at 10:01 PM, Göktürk Gezer  wrote:
> +1 (non-binding)
>
>
> Thanks,
> Gokturk
>
> On Sun, Oct 28, 2012 at 6:30 PM, Clement Escoffier <
> clement.escoff...@gmail.com> wrote:
>
>> Hi,
>>
>> It's time to cut a release of the iPOJO Manipulator (1.8.6) and runtime
>> project (1.8.4).
>>
>> This releases contains:
>> * iPOJO Manipulator 1.8.6
>> * maven-ipojo-plugin 1.8.6
>> * iPOJO Ant Task 1.8.6
>> * iPOJO BND Plugin 1.8.6
>> * iPOJO Core 1.8.4
>> * iPOJO Composite 1.8.4
>> * iPOJO Annotations 1.8.4
>> * iPOJO Runtime Project 1.8.4
>>
>> Those releases contain a lot of bugs fixes. The changelogs are below.
>>
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapachefelix-172/
>>
>> 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 172 /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 (at least).
>>
>> Regards,
>>
>> Clement
>>
>> Changelog of the manipulator project (1.8.6):
>> * [FELIX-3461] - Re-manipulation with annotated component produces
>> corrupted MANIFEST
>> * [FELIX-3466] - Pojoization.directoryManipulation() does not take
>> MANIFEST file location into account.
>> * [FELIX-3508] - IPojo Manipulator left out 'array of enums' in
>> generated metadata
>> * [FELIX-3539] - iPOJO Manipulator failed on classes containing
>> expanded frames
>> * [FELIX-3573] - IPojo bytecode manipulation generates a duplicate
>> local variable
>> * [FELIX-3574] - IPojo bytecode manipulation looses method argument
>> names
>> * [FELIX-3621] - Two dimensional array as argument to a method in a
>> component
>>
>> Changelog of the runtime project (1.8.4):
>> * [FELIX-3451] - "instance.name" attribute not recognized
>> * [FELIX-3500] - InstanceManager concurrency issue: "A methodID cannot
>> be associated with a method from the POJO class"
>> * [FELIX-3501] - IPojo FactoryStateListener doesn't get notified while
>> stopping factory
>> * [FELIX-3545] - Memory leak when unregistering a component used by an
>> aggregate dependency with an unbind callback
>> * [FELIX-3548] - Concurrent access during startup
>> * [FELIX-3567] - iPOJO Configuration Handler should not reuse the
>> dictionary object from the configuration admin
>> * [FELIX-3576] - iPOJO fails when using constructor injection and
>> expecting BundleContext in ctor
>> * [FELIX-3599] - Problem with 'subservice action="instantiate"' in
>> ipojo composite
>> * [FELIX-3621] - Two dimensional array as argument to a method in a
>> component
>> * [FELIX-3672] - Potential Concurrent Modification Exception when a
>> bundle is stopped
>> * [FELIX-3560] - Extensions to IPojo's Factory and ComponentInstance
>> documentation for custom handlers

[jira] [Commented] (FELIX-3621) Two dimensional array as argument to a method in a component

[Simon Chemouil (JIRA)]

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

Simon Chemouil commented on FELIX-3621:
---

Seems good to me, my own tests work fine. Thanks!

> Two dimensional array as argument to a method in a component
> 
>
> Key: FELIX-3621
> URL: https://issues.apache.org/jira/browse/FELIX-3621
> Project: Felix
>  Issue Type: Bug
>  Components: iPOJO
>Affects Versions: iPOJO-1.8.0
> Environment: Ubuntu 11.04, Java Sun 1.6.0_26, Felix 4.1.0-SNAPSHOT, 
> Maven iPOJO Version 1.8.0
>Reporter: Remi Druilhe
>Assignee: Clement Escoffier
> Fix For: ipojo-core-1.8.4
>
> Attachments: felix3621.patch, test.zip
>
>
> I recently tried to pass a two dimensional array to a private method but when 
> I start my bundle into Felix, the factory of my component is created but not 
> the instance. Note that the compilation does not warn me.
> If I comment this code, there is no more problem. I tried using the 
> maven-ipojo 1.8.0 and 1.9.0-SNAPSHOT, same problem.

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

[jira] [Commented] (FELIX-3621) Two dimensional array as argument to a method in a component

[Simon Chemouil (JIRA)]

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

Simon Chemouil commented on FELIX-3621:
---

I've fixed the bug and ran some tests (more extensive than the attached 
testcase) and it seems to work.

As Clement said, it's a name mangling problem in the flag member of methods 
containing multi-dimensional arrays (two or higher). My patch keeps the current 
mangling scheme of using underscores (_'s) in place of array brackets, but 
since it now supports multi-dimensional arrays there can be 4, 6, 8, .. 
underscores in the flag name depending of the array's dimension.  Currently the 
manipulator does not depend on Common Utils or a similar library that has nice 
String utils so there's a ugly Stringbuilder concatenating underscores in the 
patch, but other than that it's pretty straightforward. I am too lazy to 
include unit tests for this, but in the worst case scenario it will work as bad 
as currently ;)

Maybe for inclusion in 1.9.0?

> Two dimensional array as argument to a method in a component
> 
>
> Key: FELIX-3621
> URL: https://issues.apache.org/jira/browse/FELIX-3621
> Project: Felix
>  Issue Type: Bug
>  Components: iPOJO
>Affects Versions: iPOJO-1.8.0
> Environment: Ubuntu 11.04, Java Sun 1.6.0_26, Felix 4.1.0-SNAPSHOT, 
> Maven iPOJO Version 1.8.0
>Reporter: Remi Druilhe
>Assignee: Clement Escoffier
> Attachments: felix3621.patch, test.zip
>
>
> I recently tried to pass a two dimensional array to a private method but when 
> I start my bundle into Felix, the factory of my component is created but not 
> the instance. Note that the compilation does not warn me.
> If I comment this code, there is no more problem. I tried using the 
> maven-ipojo 1.8.0 and 1.9.0-SNAPSHOT, same problem.

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

[jira] [Updated] (FELIX-3621) Two dimensional array as argument to a method in a component

[Simon Chemouil (JIRA)]

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

Simon Chemouil updated FELIX-3621:
--

Attachment: felix3621.patch

A patch that solves the issue. 

> Two dimensional array as argument to a method in a component
> 
>
> Key: FELIX-3621
> URL: https://issues.apache.org/jira/browse/FELIX-3621
> Project: Felix
>  Issue Type: Bug
>  Components: iPOJO
>Affects Versions: iPOJO-1.8.0
> Environment: Ubuntu 11.04, Java Sun 1.6.0_26, Felix 4.1.0-SNAPSHOT, 
> Maven iPOJO Version 1.8.0
>Reporter: Remi Druilhe
>Assignee: Clement Escoffier
> Attachments: felix3621.patch, test.zip
>
>
> I recently tried to pass a two dimensional array to a private method but when 
> I start my bundle into Felix, the factory of my component is created but not 
> the instance. Note that the compilation does not warn me.
> If I comment this code, there is no more problem. I tried using the 
> maven-ipojo 1.8.0 and 1.9.0-SNAPSHOT, same problem.

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

[jira] [Created] (FELIX-3618) Provide-Capability with osgi.wiring.package not spec compliant

[Simon Chemouil (JIRA)]

Simon Chemouil created FELIX-3618:
-

 Summary: Provide-Capability with osgi.wiring.package not spec 
compliant
 Key: FELIX-3618
 URL: https://issues.apache.org/jira/browse/FELIX-3618
 Project: Felix
  Issue Type: Bug
  Components: Framework
Affects Versions: framework-4.0.3
Reporter: Simon Chemouil
Priority: Minor


I think I found a bug while I playing with 4.3's Bundle Capabilities.

I tried to convert a simple Export-Package to Provide-Capability.

Core specification 5.0, §3.3.3 defines the grammar for Provide-Compatibility 
headers:Provide-Capability ::= capability ( ',' capability )*
capability ::= name-space 
( ’;’ directive | typed-attr )*
name-space ::= symbolic-name
typed-attr ::= extended ( ’:’ type ) ’=’ argument
type ::= scalar | list
scalar ::= ’String’ | ’Version’ | ’Long’ 
|   ’Double’ 
list ::= ’List<’ scalar ’>’


With my interpretation of the spec:

Export-Package: com.test.api; version="1.0.0"

becomes:

Provide-Capability: osgi.wiring.package; osgi.wiring.package=com.test.api; 
version:Version=1.0.0

where osgi.wiring.package is both the namespace and the attribute name for the 
package name. Please note that the namespace is mandatory.

This is consistent with the Require-Capability statement:
osgi.wiring.package; 
(&(osgi.wiring.package=com.test.api)(version>=1.0.0)(!(version>=2.0.0))) 
resolved by:
   osgi.wiring.package; com.test.api 1.0.0 from com.test.api [41]


If I use this header and install my bundle, using Felix 4.0.3 I get:

g! inspect c * 41
com.test.api [41] provides:
---
osgi.wiring.bundle; com.test.api 1.0.0 [UNUSED]
osgi.wiring.host; com.test.api 1.0.0 [UNUSED]
osgi.wiring.package; com.test.api 1.0.0 required by:
   com.test.consumer [36]
osgi.wiring.package; com.test.api 1.0.0 [UNUSED]
g! 

Note that the same package is advised as exported *twice* by the bundle with 
only the first one wired.


Now, if I use Export-Package, it is exported just once as expected,
The only way with Provide-Capability to get it exported just once is to omit 
the namespace, as in:

Provide-Capability: osgi.wiring.package=com.test.api; version:Version=1.0.0

However, this is not compliant with the spec, since the namespace is mandatory.

Finally, a last test where the namespace osgi.wiring.package has no attributes 
or directives fail with a NullPointerException, it should probably be handled 
gracefully. 
Provide-Capability: osgi.wiring.package

Stacktrace:
g! start 62
ERROR: Unable to resolve 62.0 (java.lang.NullPointerException)
java.lang.NullPointerException
at 
org.apache.felix.framework.BundleWiringImpl.(BundleWiringImpl.java:270)
at 
org.apache.felix.framework.StatefulResolver.markResolvedRevisions(StatefulResolver.java:650)
at 
org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:189)
at 
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3819)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
at org.apache.felix.gogo.command.Basic.start(Basic.java:729)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: felix.jar in Maven Central

[Simon Chemouil]

On Wed, Jun 20, 2012 at 3:17 PM, Karl Pauls  wrote:
> If you are talking about the framework its available as:
>
> org.apache.felix:org.apache.felix.framework

That's exactly what I needed. I was looking for that name, filtering
on org.apache.felix groupid on search.maven.org and did not see there
were several pages! I was a bit surprised not to find it, so the
mystery is solved. Next time I'll browse
http://repo1.maven.org/maven2/org/apache/felix/ directly!


> However, the felix.jar is just a rename of:
>
> org.apache.felix:org.apache.felix.main
>
> so if you really need the main, just depend on it.

Actually I don't need the main :).

Thanks a lot for the quick reply,

-- 
Simon

> regards,
>
> Karl
>
> On Wed, Jun 20, 2012 at 3:10 PM, Simon Chemouil  wrote:
>> Hi,
>>
>> I'm currently setting up an Android app that embeds Felix, and I want
>> to use Maven for the build. I need to have a (Maven) dependency on
>> felix.jar (i.e, the Felix core framework that resides in the bin/
>> directory of the Felix main distribution) but it seems this Jar has
>> not been deployed to Maven Central since 2009.
>>
>> For now, I installed the JAR in my local repository manually, but this
>> requires every developer to do so. I also guess it would be possible
>> to have a dependency on the Felix main distribution zip file
>> (available in Maven Central), do some maven-fu to unzip it using
>> maven-dependencies-plugin and somehow setup the project, but really,
>> I'm just looking for felix.jar :-).
>>
>> If it's somewhere, could you point it to me or would it be possible to
>> start deploying felix.jar to Central as well as the Felix main
>> distribution for these "embedded Felix" use cases?
>>
>> Thanks,
>>
>> --
>> Simon
>
>
>
> --
> Karl Pauls
> karlpa...@gmail.com
> http://twitter.com/karlpauls
> http://www.linkedin.com/in/karlpauls
> https://profiles.google.com/karlpauls

felix.jar in Maven Central

[Simon Chemouil]

Hi,

I'm currently setting up an Android app that embeds Felix, and I want
to use Maven for the build. I need to have a (Maven) dependency on
felix.jar (i.e, the Felix core framework that resides in the bin/
directory of the Felix main distribution) but it seems this Jar has
not been deployed to Maven Central since 2009.

For now, I installed the JAR in my local repository manually, but this
requires every developer to do so. I also guess it would be possible
to have a dependency on the Felix main distribution zip file
(available in Maven Central), do some maven-fu to unzip it using
maven-dependencies-plugin and somehow setup the project, but really,
I'm just looking for felix.jar :-).

If it's somewhere, could you point it to me or would it be possible to
start deploying felix.jar to Central as well as the Felix main
distribution for these "embedded Felix" use cases?

Thanks,

-- 
Simon

[jira] [Commented] (FELIX-2899) [GSoc 2011]Bndtools based OSGi bundles maker project

[Simon Chemouil (JIRA)]

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

Simon Chemouil commented on FELIX-2899:
---

Hi, commenting because I had a similar idea some time ago, and reached the same 
conclusion as Peter that identifying strongly connected components in the 
static dependency graph of Java classes (and packages) is the best bet. And 
there's already an optimal algorithm for that ;-). Refinements & 
parametrization should come later (e.g: should the tool be allowed to move 
classes to another package, should interfaces be extracted for API needs, 
should factories be created and exposed as a DS component, etc).

Anyway, after thinking about this for some time, I came to the conclusion that 
doing an "out of the box" solution is a lot of work, and probably make a very 
intense GSoC :-).

If there was such a tool, it would definitely be an enabler for OSGi and allow 
many projects (including many open source Java projects) to become more modular 
at a much lower cost. I hope the GSoC team will accept it.

When they do, good luck with the coding :-).

> [GSoc 2011]Bndtools based OSGi bundles maker project
> 
>
> Key: FELIX-2899
> URL: https://issues.apache.org/jira/browse/FELIX-2899
> Project: Felix
>  Issue Type: Task
> Environment: Eclipse platform, this project add a new tool for Felix 
> users to improve OSGi bundles development process in Eclipse environment
>Reporter: Tiger Gui
>Assignee: Peter Kriens
>  Labels: gsoc, gsoc2011, mentor, mentoring
>   Original Estimate: 1680h
>  Remaining Estimate: 1680h
>
> OSGi(Open Service Gateway Initiative) is a worldwide consortium of technology 
> innovators that advances a proven and 
> mature process to create open specifications that enable the modular assembly 
> of software built with Java technology.
> It is becoming more and more popular in Java Desktop or Web application 
> developmenent especially when we are working on 
> some huge project, as it is growing more and more complex, OSGi can help 
> us.Developing with OSGi technology means 
> developing bundles: the OSGi components. Bundles are modules. 
> OSGi is a good thing, but coin has two sides. Usually the development process 
> with OSGi will be more troublesome. Suppose 
> that we are in this scenario. We use a interface Greeting to say hello to our 
> customers , but we should say different words to different kind of customers
> , so we have two implemention class for Greeting interface, we 
> name them BasicGreeting and GreatGreeting.
> If we develop this application in a traditional OSGi way, we should create at 
> lease 3 projects (or bundles) in our IDE (Eclipse for example).
> one service define bundle, two service supply bundles, it's a long list in 
> our workspace.Isn't it troublesome? If we just 
> write these codes in a Jave project and some tool can help us to split this 
> project in OSGi way and export 3 jar files, isn't it cool?
> So i want to build OSGi split tool for Java project, it can also be used to 
> split and refactor our exist huge project in OSGi way. This 
> is very important. In some huge application, how to manage components in a 
> convinent way is an art, so far, OSGi is the best solution
> that we can find. But the refactor and split for exist huge project is 
> complex and painful. This tool will help us to do this job.
> We want to build a bnd(tools) based OSGi bunlles maker project, it will help 
> us analyse java application and split the whole project into several OSGi 
> bundles.
> Suppose that we write code in good style, define service in interface, 
> implement the service by the implemention class of the interface 
> and put similar service in a package. This tool can analyse source code, 
> supply vari-size grained split and refactor suggestions, show 
> the analyse result in a GUI view and we can change split solution manually, 
> then it will split the project into several projects.
> Function lists:
> 1. configuration 
> Define default split/refactor solution for this tool. For example,assign 
> default interface split particle or package split partical. Or may be 
> we can just split the project by function module define, similar with 
> M(Module)-V(View)-C(control) develop pattern. Or in some other ways.
> 2. analyse module
> It can analyse project source code, make clear of class dependency 
> relationship and give us a graphical view analyse result, this is default
> split solution, and we can change it as we like.
> The trick 

[jira] Issue Comment Edited: (FELIX-2819) packageinfo files in src/main/java are ignored

[Simon Chemouil (JIRA)]

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

Simon Chemouil edited comment on FELIX-2819 at 2/4/11 9:17 PM:
---

By the way, if you're not doing it already (or for people who might read this 
issue), here's the cleanest workaround :

{code:XML}
   





src/main/resources





${project.build.sourceDirectory}

**/*.java
**/.*






${project.build.sourceDirectory}

**/packageinfo







   
{code}
On our project we put the "include all resources that are in src/" rule in a 
parent POM... Of course, it would still be nice if maven-bundle-plugin would 
manage bnd-related files out-of-the-box.

Hope this helps,

Simon

Edit: formating is completely messed up... 

  was (Author: magnet):
By the way, if you're not doing it already (or for people who might read 
this issue), here's the cleanest workaround :

{code:XML}
   





src/main/resources





${project.build.sourceDirectory}

**/*.java
**/.*






${project.build.sourceDirectory}

**/packageinfo







   
{code}
On our project we put the "include all resources that are in src/" rule in a 
parent POM... Of course, it would still be nice if maven-bundle-plugin would 
manage bnd-related files out-of-the-box.

Hope this helps,

Simon
  
> packageinfo files in src/main/java are ignored
> --
>
> Key: FELIX-2819
> URL: https://issues.apache.org/jira/browse/FELIX-2819
> Project: Felix
>  Issue Type: Bug
>  Components: Maven Bundle Plugin
>Reporter: Alasdair Nottingham
>
> The bnd tool can pick up the package version from a packageinfo file if it is 
> stored next to the java files.
> The maven-bundle-plugin will only include them in the jar, and make them 
> visible to bnd if they are in the src/main/resources directory. I would like 
> to use these files for specifying versions, rather than putting it in the 
> pom. This allows me to specify the version once in this file even if it is 
> repackaged in a different jar later.
> The problem is I have to put the files into src/main/resources which 
> significantly reduces the chance of updating them when a change is made. 
> Could the maven-bundle-plugin be updated to put the packageinfo files from 
> src/main/java into the jar before calling bnd?
> Thanks
> Alasdair

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

[jira] Issue Comment Edited: (FELIX-2819) packageinfo files in src/main/java are ignored

[Simon Chemouil (JIRA)]

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

Simon Chemouil edited comment on FELIX-2819 at 2/4/11 9:14 PM:
---

By the way, if you're not doing it already (or for people who might read this 
issue), here's the cleanest workaround :

{code:XML}
   





src/main/resources





${project.build.sourceDirectory}

**/*.java
**/.*






${project.build.sourceDirectory}

**/packageinfo







   
{code}
On our project we put the "include all resources that are in src/" rule in a 
parent POM... Of course, it would still be nice if maven-bundle-plugin would 
manage bnd-related files out-of-the-box.

Hope this helps,

Simon

  was (Author: magnet):
By the way, if you're not doing it already (or for people who might read 
this issue), here's the cleanest workaround :

   





src/main/resources





${project.build.sourceDirectory}

**/*.java
**/.*






${project.build.sourceDirectory}

**/packageinfo







   

On our project we put the "include all resources that are in src/" rule in a 
parent POM... Of course, it would still be nice if maven-bundle-plugin would 
manage bnd-related files out-of-the-box.

Hope this helps,

Simon
  
> packageinfo files in src/main/java are ignored
> --
>
> Key: FELIX-2819
> URL: https://issues.apache.org/jira/browse/FELIX-2819
> Project: Felix
>  Issue Type: Bug
>  Components: Maven Bundle Plugin
>Reporter: Alasdair Nottingham
>
> The bnd tool can pick up the package version from a packageinfo file if it is 
> stored next to the java files.
> The maven-bundle-plugin will only include them in the jar, and make them 
> visible to bnd if they are in the src/main/resources directory. I would like 
> to use these files for specifying versions, rather than putting it in the 
> pom. This allows me to specify the version once in this file even if it is 
> repackaged in a different jar later.
> The problem is I have to put the files into src/main/resources which 
> significantly reduces the chance of updating them when a change is made. 
> Could the maven-bundle-plugin be updated to put the packageinfo files from 
> src/main/java into the jar before calling bnd?
> Thanks
> Alasdair

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

[jira] Commented: (FELIX-2819) packageinfo files in src/main/java are ignored

[Simon Chemouil (JIRA)]

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

Simon Chemouil commented on FELIX-2819:
---

By the way, if you're not doing it already (or for people who might read this 
issue), here's the cleanest workaround :

   





src/main/resources





${project.build.sourceDirectory}

**/*.java
**/.*






${project.build.sourceDirectory}

**/packageinfo







   

On our project we put the "include all resources that are in src/" rule in a 
parent POM... Of course, it would still be nice if maven-bundle-plugin would 
manage bnd-related files out-of-the-box.

Hope this helps,

Simon

> packageinfo files in src/main/java are ignored
> --
>
> Key: FELIX-2819
> URL: https://issues.apache.org/jira/browse/FELIX-2819
> Project: Felix
>  Issue Type: Bug
>  Components: Maven Bundle Plugin
>Reporter: Alasdair Nottingham
>
> The bnd tool can pick up the package version from a packageinfo file if it is 
> stored next to the java files.
> The maven-bundle-plugin will only include them in the jar, and make them 
> visible to bnd if they are in the src/main/resources directory. I would like 
> to use these files for specifying versions, rather than putting it in the 
> pom. This allows me to specify the version once in this file even if it is 
> repackaged in a different jar later.
> The problem is I have to put the files into src/main/resources which 
> significantly reduces the chance of updating them when a change is made. 
> Could the maven-bundle-plugin be updated to put the packageinfo files from 
> src/main/java into the jar before calling bnd?
> Thanks
> Alasdair

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

[jira] Commented: (FELIX-2819) packageinfo files in src/main/java are ignored

[Simon Chemouil (JIRA)]

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

Simon Chemouil commented on FELIX-2819:
---

This would be nice indeed.

Just for the record (you might find it useful), we use the @Version bnd 
annotation on the package statement in the package-info.java file to achieve 
the same, and Maven is happy with this since it's a Java source file.

E.g,

@Version("1.0.2")
package com.mycompany.myproject.mypackage

import aQute.bnd.annotation;

One thing nice with this is that it's possible to use a String constant defined 
in a Java class, for those times when we want to make the version a part of the 
Java API... And this usage finally makes package-info.java interesting for more 
than just package javadoc. Drawbacks are that we depend on bnd.annotation's JAR 
at compile time only for manifest generation, and that no tool that I know of 
updates these versions when the API evolves.

Hope this helps.

> packageinfo files in src/main/java are ignored
> --
>
> Key: FELIX-2819
> URL: https://issues.apache.org/jira/browse/FELIX-2819
> Project: Felix
>  Issue Type: Bug
>  Components: Maven Bundle Plugin
>Reporter: Alasdair Nottingham
>
> The bnd tool can pick up the package version from a packageinfo file if it is 
> stored next to the java files.
> The maven-bundle-plugin will only include them in the jar, and make them 
> visible to bnd if they are in the src/main/resources directory. I would like 
> to use these files for specifying versions, rather than putting it in the 
> pom. This allows me to specify the version once in this file even if it is 
> repackaged in a different jar later.
> The problem is I have to put the files into src/main/resources which 
> significantly reduces the chance of updating them when a change is made. 
> Could the maven-bundle-plugin be updated to put the packageinfo files from 
> src/main/java into the jar before calling bnd?
> Thanks
> Alasdair

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