[jira] [Commented] (FELIX-3451) "instance.name" attribute not recognized
[ https://issues.apache.org/jira/browse/FELIX-3451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13254272#comment-13254272 ] Clement Escoffier commented on FELIX-3451: -- Hi, I've tried both and got: Validating Component Comanche HTTP Server ready on port 8088. Load http://localhost:8088/src/comanche_iPOJO/gnu.jpg Waiting for something to happen... Which looks not too bad. > "instance.name" attribute not recognized > > > Key: FELIX-3451 > URL: https://issues.apache.org/jira/browse/FELIX-3451 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: ipojo-composite-1.8.2 > Environment: Mac OS X Lion 10.7.3, Java 1.6.0_31, System Bundle > (4.0.2), Apache Felix Bundle Repository (1.6.6), Apache Felix iPOJO > (1.9.0.SNAPSHOT), Apache Felix iPOJO API (1.7.0.SNAPSHOT), Apache Felix iPOJO > Arch Command (1.7.0.SNAPSHOT), Apache Felix iPOJO Composite (1.9.0.SNAPSHOT), > Apache Felix Shell Service (1.4.2), Apache Felix Shell TUI (1.4.1) >Reporter: Fabio Lattario Fonseca >Priority: Minor > Labels: composite, instance, ipojo, name, newbie, xml > Fix For: ipojo-composite-1.8.2 > > Attachments: bad_pom.xml, comanche_iPOJO_composite.tgz, good_pom.xml > > > When using the attribute "instance.name" to give a name for a component > instance inside a composite, the name is not being assigned properly. On the > other hand, if the deprecated attribute "name" is used, the instance gets the > right name. -- 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
[jira] [Created] (FELIX-3462) Nicer Manifest formatting does not work in maven bundle plugin
Nicer Manifest formatting does not work in maven bundle plugin -- Key: FELIX-3462 URL: https://issues.apache.org/jira/browse/FELIX-3462 Project: Felix Issue Type: Bug Components: Maven Bundle Plugin Affects Versions: maven-bundle-plugin-2.3.7 Reporter: Christian Schneider Fix For: maven-bundle-plugin-2.3.8 Version 2.3.6 introduced the nicer formatting for manifests where after each e.g. Import package a newline should happen. This never worked for me. I already asked on the original issue but never got an answer. -- 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-manipulation generates corrupted MANIFEST on annotated components.
Hi Everyone, As i was trying to integrate IPojo manipulation into eclipse environment, i noticed re-manipulation without cleaning corrupts the MANIFEST file even though it does not brake manipulated class files. Re-manipulated MANIFEST is lacking some handler declarations and "manipulation" section contains entries for fields and methods those are IPojo generated ones, which brakes down everything. I created a jira: https://issues.apache.org/jira/browse/FELIX-3461 with a patch to fix. I will document the fix here briefly, so that you guys can tell me if anything brakes some part of code that i don't know. * First problem is ManipulatedMetadataFilter class which is simply ignoring elements if some of their attributes contain manipulation headers. This behavior ends up in ignoring elements whose values are dependent on methods like transition callbacks(Validate-Invalidate), since the re-manipulation process will read methods with their mangled names. And filter was also missing some manipulation headers too, causing manipulation section to contain extra entries. I removed the filter logic from code and injected a ManipulationMetadataFixer which is called before any manipulation medata is rendered. It fixes the mangled method names and performs a structered clean-up on manipulation elements. * After using Fixer there were two main problems left: -> Bind/Unbind/Modified metadatas were being lost and @Property on methods were lacking property names after re-manipulation :: Solved by adding necessary checks into BindAnnotationsParser and PropertyAnnotationParser classes's visitEnd() methods. -> Constructor injection parameters were being assigned wrong class types after re-manipulation :: While generating new constructor based on existing one argument annotations were being transferred to new one without changing their index. While this is valid action, it falsify the fetched type of injection annotations at re-manipulation. At ClassChecker i added an exception for @Property and @Requires annotation types to remain attached to original constructor, also overrided visitParameterAnnotation() method in ConstructorCodeAdaptor class to forbid those two annotation to go into generated constructor. Tested those changes against an IPojo component containing all current ipojo annotations + custom annotations to produce same MANIFEST after multiple manipulation attempts. Regards, Gokturk
[jira] [Commented] (FELIX-3451) "instance.name" attribute not recognized
[ https://issues.apache.org/jira/browse/FELIX-3451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13254242#comment-13254242 ] Fabio Lattario Fonseca commented on FELIX-3451: --- I have just stepped on a weird behavior. I don't know if this is related to this JIRA anymore, but you may want to analyze this. In the process of changing the "name" attribute to "instance.name" attribute, I forgot to change it in the last instance. When I started the composite bundle I received a strange error message: [WARNING] comanche.backend : The 'name' (RequestAnalyzer) attribute, used as the instance name, is deprecated, please use the 'instance.name' attribute [WARNING] org.apache.comanche.basicLogger.BasicLogger : The 'name' (RequestAnalyzer) attribute, used as the instance name, is deprecated, please use the 'instance.name' attribute [WARNING] FileRH : The 'name' (RequestAnalyzer) attribute, used as the instance name, is deprecated, please use the 'instance.name' attribute [ERROR] FileRH : The configuration is not acceptable : Name already used [ERROR] comanche.requestHandler : A factory is available for the configuration but the configuration is not acceptable org.apache.felix.ipojo.UnacceptableConfiguration: FileRH : Name already used : RequestAnalyzer at org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:290) at org.apache.felix.ipojo.composite.FactoryProxy.createComponentInstance(FactoryProxy.java:87) at org.apache.felix.ipojo.composite.instance.InstanceHandler.__createInstance(InstanceHandler.java:160) [...] [WARNING] ErrorRH : The 'name' (RequestAnalyzer) attribute, used as the instance name, is deprecated, please use the 'instance.name' attribute [ERROR] ErrorRH : The configuration is not acceptable : Name already used [ERROR] comanche.requestHandler : A factory is available for the configuration but the configuration is not acceptable org.apache.felix.ipojo.UnacceptableConfiguration: ErrorRH : Name already used : RequestAnalyzer at org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:290) at org.apache.felix.ipojo.composite.FactoryProxy.createComponentInstance(FactoryProxy.java:87) at org.apache.felix.ipojo.composite.instance.InstanceHandler.__createInstance(InstanceHandler.java:160) at org.apache.felix.ipojo.composite.instance.InstanceHandler.createInstance(InstanceHandler.java) [...] [ERROR] FileRH : The configuration is not acceptable : Name already used [ERROR] comanche.requestHandler : A factory is available for the configuration but the configuration is not acceptable org.apache.felix.ipojo.UnacceptableConfiguration: FileRH : Name already used : RequestAnalyzer at org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:290) at org.apache.felix.ipojo.composite.FactoryProxy.createComponentInstance(FactoryProxy.java:87) at org.apache.felix.ipojo.composite.instance.InstanceHandler.__createInstance(InstanceHandler.java:160) [...] [ERROR] ErrorRH : The configuration is not acceptable : Name already used [ERROR] comanche.requestHandler : A factory is available for the configuration but the configuration is not acceptable org.apache.felix.ipojo.UnacceptableConfiguration: ErrorRH : Name already used : RequestAnalyzer at org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:290) at org.apache.felix.ipojo.composite.FactoryProxy.createComponentInstance(FactoryProxy.java:87) [...] The first warning is right. I tried to use the "name" attribute when instantiating the "comanche.backend" composite. But the second and third warnings don't make sense for me. I think the errors don't make sense either, because I have not used the same name for more than one component or composite. I will attach the pom.xml for the org.apache.comanche maven module for you to be able to reproduce the scenery when everything works and the other one, that produces the error above. Thanks! > "instance.name" attribute not recognized > > > Key: FELIX-3451 > URL: https://issues.apache.org/jira/browse/FELIX-3451 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: ipojo-composite-1.8.2 > Environment: Mac OS X Lion 10.7.3, Java 1.6.0_31, System Bundle > (4.0.2), Apache Felix Bundle Repository (1.6.6), Apache Felix iPOJO > (1.9.0.SNAPSHOT), Apache Felix iPOJO API (1.7.0.SNAPSHOT), Apache Felix iPOJO > Arch Command (1.7.0.SNAPSHOT), Apache Felix iPOJO Composite (1.9.0.SNAPSHOT), > Apache Felix Shell Service (1.4.2), Apache Felix Shell TUI (1.4.1) >Reporter: Fabio Lattario Fonseca >Priority: Minor > La
[jira] [Updated] (FELIX-3451) "instance.name" attribute not recognized
[ https://issues.apache.org/jira/browse/FELIX-3451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fabio Lattario Fonseca updated FELIX-3451: -- Attachment: good_pom.xml bad_pom.xml > "instance.name" attribute not recognized > > > Key: FELIX-3451 > URL: https://issues.apache.org/jira/browse/FELIX-3451 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: ipojo-composite-1.8.2 > Environment: Mac OS X Lion 10.7.3, Java 1.6.0_31, System Bundle > (4.0.2), Apache Felix Bundle Repository (1.6.6), Apache Felix iPOJO > (1.9.0.SNAPSHOT), Apache Felix iPOJO API (1.7.0.SNAPSHOT), Apache Felix iPOJO > Arch Command (1.7.0.SNAPSHOT), Apache Felix iPOJO Composite (1.9.0.SNAPSHOT), > Apache Felix Shell Service (1.4.2), Apache Felix Shell TUI (1.4.1) >Reporter: Fabio Lattario Fonseca >Priority: Minor > Labels: composite, instance, ipojo, name, newbie, xml > Fix For: ipojo-composite-1.8.2 > > Attachments: bad_pom.xml, comanche_iPOJO_composite.tgz, good_pom.xml > > > When using the attribute "instance.name" to give a name for a component > instance inside a composite, the name is not being assigned properly. On the > other hand, if the deprecated attribute "name" is used, the instance gets the > right name. -- 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
[jira] [Commented] (FELIX-3451) "instance.name" attribute not recognized
[ https://issues.apache.org/jira/browse/FELIX-3451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13254235#comment-13254235 ] Fabio Lattario Fonseca commented on FELIX-3451: --- Ohhh, c'mon... :-/ You are right! It is a problem with my metadata indeed. Everything worked now. Didn't know I could configure the instance like that, with the "property" key. I thought the "instance.name" could be used in the same way as the "name" attribute, in previous version, directly in the "instance" key. I think the dot in "instance.name" may prevent it from be used like that, uh? Or it is just the new way to create an instance? Thanks a lot and sorry for the false bug alarm. > "instance.name" attribute not recognized > > > Key: FELIX-3451 > URL: https://issues.apache.org/jira/browse/FELIX-3451 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: ipojo-composite-1.8.2 > Environment: Mac OS X Lion 10.7.3, Java 1.6.0_31, System Bundle > (4.0.2), Apache Felix Bundle Repository (1.6.6), Apache Felix iPOJO > (1.9.0.SNAPSHOT), Apache Felix iPOJO API (1.7.0.SNAPSHOT), Apache Felix iPOJO > Arch Command (1.7.0.SNAPSHOT), Apache Felix iPOJO Composite (1.9.0.SNAPSHOT), > Apache Felix Shell Service (1.4.2), Apache Felix Shell TUI (1.4.1) >Reporter: Fabio Lattario Fonseca >Priority: Minor > Labels: composite, instance, ipojo, name, newbie, xml > Fix For: ipojo-composite-1.8.2 > > Attachments: comanche_iPOJO_composite.tgz > > > When using the attribute "instance.name" to give a name for a component > instance inside a composite, the name is not being assigned properly. On the > other hand, if the deprecated attribute "name" is used, the instance gets the > right name. -- 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
[jira] [Updated] (FELIX-3461) Re-manipulation with annotated component produces corrupted MANIFEST
[ https://issues.apache.org/jira/browse/FELIX-3461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Göktürk Gezer updated FELIX-3461: - Attachment: org.apache.felix.ipojo.manipulator.patch Fix for bug. Tested against all current ipojo annotations and custom annotations to produce same MANIFEST after re-manipulation on both directory and jar-file. > Re-manipulation with annotated component produces corrupted MANIFEST > > > Key: FELIX-3461 > URL: https://issues.apache.org/jira/browse/FELIX-3461 > Project: Felix > Issue Type: Bug > Components: iPOJO >Reporter: Göktürk Gezer > Labels: ipojo-manipulator > Attachments: org.apache.felix.ipojo.manipulator.patch > > > As the manipulation process alters the annotations of original classes on > generated ones. It leaves it in inconsistent state for re-manipulation. While > re-manipulation process does not touch classes, re-manipulated bundle is > unable to function because of a corrupted MANIFEST. > Broken MANIFEST is missing some handler declarations because of the filters > and have entries in manipulation section those should have been hided. -- 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
[jira] [Created] (FELIX-3461) Re-manipulation with annotated component produces corrupted MANIFEST
Re-manipulation with annotated component produces corrupted MANIFEST Key: FELIX-3461 URL: https://issues.apache.org/jira/browse/FELIX-3461 Project: Felix Issue Type: Bug Components: iPOJO Reporter: Göktürk Gezer As the manipulation process alters the annotations of original classes on generated ones. It leaves it in inconsistent state for re-manipulation. While re-manipulation process does not touch classes, re-manipulated bundle is unable to function because of a corrupted MANIFEST. Broken MANIFEST is missing some handler declarations because of the filters and have entries in manipulation section those should have been hided. -- 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
[jira] [Commented] (FELIX-2872) Provide a way to have an easier to read manifest
[
https://issues.apache.org/jira/browse/FELIX-2872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13254191#comment-13254191
]
Christian Schneider commented on FELIX-2872:
This does not seem to work. Is there any switch to active the formatting?
> Provide a way to have an easier to read manifest
>
>
> Key: FELIX-2872
> URL: https://issues.apache.org/jira/browse/FELIX-2872
> Project: Felix
> Issue Type: Improvement
> Components: Maven Bundle Plugin
>Reporter: Guillaume Nodet
>Assignee: Stuart McCulloch
> Fix For: maven-bundle-plugin-2.3.6
>
>
> It should be possible to have a easier to read generated manifest, with
> newlines after commas in comma separated list.
> We'd still have to abide by the 80 charachters (or so) per line rule,
> something like:
> {code}
> Require-Bundle: org.eclipse.ui,
> org.eclipse.core.databinding,
> org.eclipse.core.databinding.beans
> {code}
> This of course could be made optional / configurable.
--
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
[jira] [Commented] (FELIX-3451) "instance.name" attribute not recognized
[ https://issues.apache.org/jira/browse/FELIX-3451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13254157#comment-13254157 ] Clement Escoffier commented on FELIX-3451: -- Hi, I think it's just an issue in your metadata: Then I get: instance name="comanche.backend-0" state="invalid" bundle="11" component.type="comanche.backend" [...] services service architecture.instance="mytest123" factory.name="architecture" instance.name="architecture-6" objectclass="[org.apache.felix.ipojo.architecture.Architecture]" service.id="11" containedinstances instance name="mytest123" state="invalid" bundle="11" component.type="comanche.requestHandler" [...] > "instance.name" attribute not recognized > > > Key: FELIX-3451 > URL: https://issues.apache.org/jira/browse/FELIX-3451 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: ipojo-composite-1.8.2 > Environment: Mac OS X Lion 10.7.3, Java 1.6.0_31, System Bundle > (4.0.2), Apache Felix Bundle Repository (1.6.6), Apache Felix iPOJO > (1.9.0.SNAPSHOT), Apache Felix iPOJO API (1.7.0.SNAPSHOT), Apache Felix iPOJO > Arch Command (1.7.0.SNAPSHOT), Apache Felix iPOJO Composite (1.9.0.SNAPSHOT), > Apache Felix Shell Service (1.4.2), Apache Felix Shell TUI (1.4.1) >Reporter: Fabio Lattario Fonseca >Priority: Minor > Labels: composite, instance, ipojo, name, newbie, xml > Fix For: ipojo-composite-1.8.2 > > Attachments: comanche_iPOJO_composite.tgz > > > When using the attribute "instance.name" to give a name for a component > instance inside a composite, the name is not being assigned properly. On the > other hand, if the deprecated attribute "name" is used, the instance gets the > right name. -- 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
[jira] [Resolved] (FELIX-3374) Use of java.lang.Properties in iPOJO Core
[ https://issues.apache.org/jira/browse/FELIX-3374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier resolved FELIX-3374. -- Resolution: Fixed Fix Version/s: ipojo-core-1.8.2 > Use of java.lang.Properties in iPOJO Core > - > > Key: FELIX-3374 > URL: https://issues.apache.org/jira/browse/FELIX-3374 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: iPOJO-1.8.0 > Environment: JRE 6 > Apache Felix Framework 4.0.2 >Reporter: Armin Felke >Assignee: Clement Escoffier > Fix For: ipojo-core-1.8.2 > > > Setting the instance property "requires.filters" when property propagation is > enabled for the component, results in the following error message: > "[ERROR] : The propagated property requires.filters cannot be created > correctly : Constructor not found exception during the creation of class > java.util.Properties : java.util.Properties.(java.lang.String)" > It seems that iPOJO tries to create java.util.Properties as service property > values incorrectly. > Btw, I am just curious, what is the current policy for handling collections > of string/value pairs in the iPOJO/Felix source code? Class > java.util.Directory seems to be obsolete and Properties is not as universal > as the java.util.Map<> interface. -- 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
[jira] [Commented] (FELIX-3374) Use of java.lang.Properties in iPOJO Core
[ https://issues.apache.org/jira/browse/FELIX-3374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13254130#comment-13254130 ] Clement Escoffier commented on FELIX-3374: -- Hi, I've fixed the issue in the trunk. We're using Dictionary / Properties because the OSGi specification is relying on them (OSGi R 4.0, 4.1 and 4.2). It seems that there is some effort to update the API, but I didn't check so far. So, as the OSGi api is using such objects, we have decided to use them in iPOJO to be consistent. However, we probably will update this in iPOJO 2.0. > Use of java.lang.Properties in iPOJO Core > - > > Key: FELIX-3374 > URL: https://issues.apache.org/jira/browse/FELIX-3374 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: iPOJO-1.8.0 > Environment: JRE 6 > Apache Felix Framework 4.0.2 >Reporter: Armin Felke >Assignee: Clement Escoffier > > Setting the instance property "requires.filters" when property propagation is > enabled for the component, results in the following error message: > "[ERROR] : The propagated property requires.filters cannot be created > correctly : Constructor not found exception during the creation of class > java.util.Properties : java.util.Properties.(java.lang.String)" > It seems that iPOJO tries to create java.util.Properties as service property > values incorrectly. > Btw, I am just curious, what is the current policy for handling collections > of string/value pairs in the iPOJO/Felix source code? Class > java.util.Directory seems to be obsolete and Properties is not as universal > as the java.util.Map<> interface. -- 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
[jira] [Commented] (FELIX-3456) Component ignores required static service addition when in Activating state
[ https://issues.apache.org/jira/browse/FELIX-3456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13254080#comment-13254080 ] Felix Meschberger commented on FELIX-3456: -- > A colleague tried a completely asynchronous model for service events in scr > and although start seemed to work, > stopping resulted in a lot of work on stopped bundles and component objects Been there done that ... SCR was fully asynchronous at one point in time. Stopping failed miserably because services have been gone when the component was about to be stopped and expected statically bound services to still be available. Startup worked correctly and the spec does not favor one or the other (I think there is nothing about synchronicity in the spec). I converted to synchronous startup to have better control during system startup (namely to have all components activated when the FRAMEWORK_STARTED event is fired by the framework). In fact, it is quite nice to have all components fuly handled once the bundle's STARTED or STOPPED event is fired. (This is one of my concerns with blueprint which is asynchronous and makes it hard to reason about system state). Overall and in hindsight it looks like synchronous startup is preferable to asynchronous startup. BTW: The last time I checked, Equinox DS was also fully synchronous. > We might have an internal and external state. In your proposal thread 2 waits for the lock and thus thread 1 and thread 2 are susceptive to deadlocks. Particularly if you take another service into account The reason for this is, that when a service is supplied we are called back from the framework and thus have to be extremely carefull since the framework may still hold locks (for example bundle locks during bundle start) > Component ignores required static service addition when in Activating state > --- > > Key: FELIX-3456 > URL: https://issues.apache.org/jira/browse/FELIX-3456 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-1.6.0 > Environment: Using org.apache.felix.scr svn rev 1298268 on Mac >Reporter: Richard Ellis >Priority: Critical > Attachments: FELIX-3456-1.diff > > > I have a component with two required static service references (A and B). In > my scenario A and B are registered nearly simultaneously on different threads > and this causes the DependencyManager to ignore the addition of one of these > two services (B). This causes the component to remain unsatisfied and never > activate, since the service that was ignored is not re-registered at any time > and nothing subsequently causes the component to re-activate. > This happens as follows: > 12:30:59:317 Thread 1 - Registers Service B/257 > 12:30:59:320 Thread 2 - Registers Service A/258 > 12:30:59:320 Thread 2 - Dependency Manager: Adding Service A/258 > 12:30:59:321 Thread 2 - Dependency Manager: Service serviceA registered, > activate component > 12:30:59:321 Thread 2 - State transition : Unsatisfied -> Activating > 12:30:59:321 Thread 2 - Activating component > 12:30:59:321 Thread 1 - Dependency Manager: Adding Service B/257 > 12:30:59:321 Thread 2 - Dependency not satisfied: serviceB > 12:30:59:321 Thread 1 - Dependency Manager: Added service serviceB is ignored > for static reference <--- I believe we end up here because Thread 2 has moved > the component from Unsatisfied to Activating and the reference is a static > reference > 12:30:59:321 Thread 2 - Not all dependencies satisified, cannot activate > 12:30:59:321 Thread 2 - State transition : Activating -> Unsatisfied > Because the addition of Service B has been ignored and serviceB is a required > dependency my component then never activates even though my reqiured service > is present. > There is a comment in DependencyManager#serviceAdded method: > // FELIX-1413: if the dependency is static and the component is > // satisfied (active) added services are not considered until > // the component is reactivated for other reasons. > This suggests that the static service should only be ignored if the component > is satisfied(active), which would be correct, but in this case the component > is only activating (and will fail to activate because one of the two > dependencies is not yet satisfied) and there is no check of state at this > time. > A simple fix would be to check the state of the component as well as if the > service is static e.g. > replace if ( m_dependencyMetadata.isStatic() ) > with if ( m_dependencyMetadata.isStatic() && m_componentManager.getState() == > AbstractComponentManager.STATE_ACTIVE ) > This is an easy fix, but I guess may leave a small window where a static > reference could get replaced while a compon
[jira] [Resolved] (FELIX-3380) minor javadoc corrections in @Temporal annotation
[ https://issues.apache.org/jira/browse/FELIX-3380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier resolved FELIX-3380. -- Resolution: Fixed Fix Version/s: (was: ipojo-core-1.8.2) ipojo-temporal-dependency-handler-1.8.0 Fixed in trunk since quite some time. > minor javadoc corrections in @Temporal annotation > - > > Key: FELIX-3380 > URL: https://issues.apache.org/jira/browse/FELIX-3380 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: iPOJO-1.8.0 >Reporter: Reuben Garrett >Assignee: Clement Escoffier >Priority: Trivial > Labels: javadoc > Fix For: ipojo-temporal-dependency-handler-1.8.0 > > Attachments: FELIX-3380-1.diff > > Original Estimate: 5m > Remaining Estimate: 5m > > correct documented default for timeout from "true" to 3000 > http://svn.apache.org/repos/asf/felix/releases/org.apache.felix.ipojo.annotations-1.8.0/src/main/java/org/apache/felix/ipojo/handler/temporal/Temporal.java -- 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
[jira] [Created] (FELIX-3460) Warning for duplicate package imports
Warning for duplicate package imports - Key: FELIX-3460 URL: https://issues.apache.org/jira/browse/FELIX-3460 Project: Felix Issue Type: Improvement Components: Maven Bundle Plugin Affects Versions: maven-bundle-plugin-2.3.4 Reporter: Basil Brunner Priority: Minor Recently I had a problem with an invalid manifest due to a duplicate package import statement. It would be helpful if the Maven Bundle Plugin displays an error message if there is a duplicate package import. -- 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
[jira] [Created] (FELIX-3459) Loading of bundle with duplicate import fails silently
Loading of bundle with duplicate import fails silently
--
Key: FELIX-3459
URL: https://issues.apache.org/jira/browse/FELIX-3459
Project: Felix
Issue Type: Bug
Components: File Install
Affects Versions: fileinstall-3.1.10
Environment: Felix 4.0.2
Reporter: Basil Brunner
Loading a bundle with an invalid Import-Package definition (in my case,
org.slf4j was imported twice) fails silently. No error message is displayed and
the bundle doesn't show up in the bundle list.
Installing the same bundle with the felix:install command displays an error
message ("duplicate import"). It would be helpful if the same error message is
displayed while loading the bundle with the file install bundle.
--
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
