[jira] [Resolved] (FELIX-3500) InstanceManager concurrency issue: "A methodID cannot be associated with a method from the POJO class"
[
https://issues.apache.org/jira/browse/FELIX-3500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clement Escoffier resolved FELIX-3500.
--
Resolution: Fixed
Fix Version/s: ipojo-core-1.8.4
> InstanceManager concurrency issue: "A methodID cannot be associated with a
> method from the POJO class"
> --
>
> Key: FELIX-3500
> URL: https://issues.apache.org/jira/browse/FELIX-3500
> Project: Felix
> Issue Type: Bug
> Components: iPOJO
>Affects Versions: ipojo-core-1.8.2
>Reporter: Francois Valdy
>Assignee: Clement Escoffier
> Fix For: ipojo-core-1.8.4
>
>
> InstanceManager.getMethodByID(String) claims to be thread-safe (or not to
> require synchronization) but is not.
> It results in random messages "A methodID cannot be associated with a method
> from the POJO class" (which were downgraded from ERROR to INFO), but has
> unknown side effect bugs (as it returns null for valid methods when that
> happens).
> If 2 threads call this method with the same parameter:
> - both won't find it in the cache (m_methods.get(methodId) == null)
> - one will register it: !m_methods.containsValue(mets[i]) is true
> - second thread will NOT register it (because the first one did, hence the
> value is in the map), and will return null <-- bug
> Other issues may occur from the fact that an HashMap (unsafe) is used without
> synchronization, for instance a well-known infinite loop.
> I think one fix (to keep the same method semantics) under J2SE 1.3 would be
> to:
> - use Hashtable instead of HashMap (safe as the value is never null)
> - replace the code within the loop by:
> if (m_methods.containsValue(mets[i]))
> {
> method = (Method) m_methods.get(methodId);
> if (method != null)
> {
> return method;
> }
> }
> else if
> (MethodMetadata.computeMethodId(mets[i]).equals(methodId))
> {
> // Store the new methodId
> m_methods.put(methodId, mets[i]);
> return mets[i];
> }
> However I'm not sure about the purpose of the containsValue check purpose
> (which is also very expensive as it traverses the entire map).
> Thanks.
--
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-3539) iPOJO Manipulator failed on classes containing expanded frames
[
https://issues.apache.org/jira/browse/FELIX-3539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clement Escoffier resolved FELIX-3539.
--
Resolution: Fixed
Fixed din trunk
> iPOJO Manipulator failed on classes containing expanded frames
> --
>
> Key: FELIX-3539
> URL: https://issues.apache.org/jira/browse/FELIX-3539
> Project: Felix
> Issue Type: Bug
> Components: iPOJO
>Affects Versions: ipojo-manipulator-1.8.4
> Reporter: Clement Escoffier
> Assignee: Clement Escoffier
> Fix For: ipojo-manipulator-1.8.6
>
>
> When a class contains expanded thread the manipulator throws an error:
> {code}
> ClassReader.accept() should be called with EXPAND_FRAMES flag
> {code}
--
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] [Assigned] (FELIX-3545) Memory leak when unregistering a component used by an aggregate dependency with an unbind callback
[ https://issues.apache.org/jira/browse/FELIX-3545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier reassigned FELIX-3545: Assignee: Clement Escoffier > Memory leak when unregistering a component used by an aggregate dependency > with an unbind callback > -- > > Key: FELIX-3545 > URL: https://issues.apache.org/jira/browse/FELIX-3545 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: ipojo-core-1.8.2 > Environment: Felix distribution 4.0.2, iPojo 1.8.2, Oracle JVM > 1.6.0_u31, W7x64 >Reporter: Julien MASSENET >Assignee: Clement Escoffier > Attachments: issue_showcase.zip > > > When using aggregate dependencies in an iPojo instance, any injected > dependency instance that is unbound when using an unbind callback will leak > in memory. > How to reproduce using the attached sample project: > - Build the provided bundles using maven (mvn clean install) > - Start the OSGi environment, install and start the two bundle (consumer and > provider) > > The consumer bundle prints: 'Binding a new service; it says 'Bonjour !'' > - Uninstall the provider bundle > > The consumer bundle prints: 'Unbinding a service; it says 'Au revoir !'' > - Take a heap dump using you favorite tool (VisualVM snapshot is provided) > - Search for instances of provider.french.impl.FrenchGreet > > Expected result: > - No instances can be found > > Actual result: > - One instance is found > Using svn revision 1349288 as the reference, here is my understanding of the > issue: > > The problem lies in the > org.apache.felix.ipojo.util.DependencyModel.manageDeparture(ServiceReference, > Object) method. > > The service instance is removed from the m_serviceObjects map as the first > step into the method, which is the expected behavior. Later, the > onServiceDeparture method is called, which finally invokes the > org.apache.felix.ipojo.handlers.dependency.Dependency.invokeCallback(DependencyCallback, > ServiceReference, Object) method. > > In this method, a call to > org.apache.felix.ipojo.util.DependencyModel.getService(ServiceReference) is > made, which puts back the instance in the m_serviceObjects map. This > reference can never be cleared (unless the provider also goes away, in which > case all instances are released), thus resulting in a leak. -- 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-3539) iPOJO Manipulator failed on classes containing expanded frames
Clement Escoffier created FELIX-3539:
Summary: iPOJO Manipulator failed on classes containing expanded
frames
Key: FELIX-3539
URL: https://issues.apache.org/jira/browse/FELIX-3539
Project: Felix
Issue Type: Bug
Components: iPOJO
Affects Versions: ipojo-manipulator-1.8.4
Reporter: Clement Escoffier
Assignee: Clement Escoffier
Fix For: ipojo-manipulator-1.8.6
When a class contains expanded thread the manipulator throws an error:
{code}
ClassReader.accept() should be called with EXPAND_FRAMES flag
{code}
--
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-3466) Pojoization.directoryManipulation() does not take MANIFEST file location into account.
[
https://issues.apache.org/jira/browse/FELIX-3466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13289976#comment-13289976
]
Clement Escoffier commented on FELIX-3466:
--
Could you add a unit test, just to avoid I mess up everything later ?
> Pojoization.directoryManipulation() does not take MANIFEST file location into
> account.
> --
>
> Key: FELIX-3466
> URL: https://issues.apache.org/jira/browse/FELIX-3466
> Project: Felix
> Issue Type: Bug
> Components: iPOJO
>Affects Versions: ipojo-manipulator-1.8.4
>Reporter: Göktürk Gezer
> Labels: ipojo, ipojo-manipulator
> Fix For: ipojo-manipulator-1.8.6
>
> Attachments: org.apache.felix.ipojo.manipulator.patch
>
>
> Pojoization.directoryManipulation(File dir,File metadata,File manifest)
> method does not use the given manifest file location while saving it. Instead
> it uses a hard-coded ${project.output}/target/classes/META-INF/MANIFEST.MF
> path.
> It should be modified to write back its changes to the given file when given
> file is not null.
--
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: [VOTE] Release Felix Configuration Admin version 1.4.0
+1, Regards, Clement Sent from my iPhone On 04.06.2012, at 13:49, Alex Karasulu wrote: > +1 > > On Mon, Jun 4, 2012 at 12:06 PM, Karl Pauls wrote: > >> +1 >> >> regards, >> >> Karl >> >> On Sun, Jun 3, 2012 at 5:13 PM, Jamie G. wrote: >>> +1 (non-binding) >>> >>> cheers, >>> Jamie >>> >>> On Fri, Jun 1, 2012 at 6:42 PM, Felix Meschberger >> wrote: Hi, Am 01.06.2012 um 20:20 schrieb Richard S. Hall: > +1 > > Not that it matters too much to me, but don't we normally include a > Maven source JAR in our releases? I don't see one here. Yes, we do.. Hmm, will look into why this happened. Regards Felix > > -> richard > > On 5/30/12 09:20 , Felix Meschberger wrote: >> Hi, >> >> This is a vote on version 1.4.0 of the Felix Configuration Admin >> Service implementation. The corner stones of this release a re compliance >> with the latest Configuration Admin Service specification (version 1.4 as >> published in Compendium 4.3 specification). >> >> At the same time, this is basically the same code, which is also used >> as the reference implementation for the Configuration Admin 1.4 >> specification. As such this release, of course also passes the CT for the >> Configuration Admin 1.4. >> >> The main big difference to earlier releases of this bundle is, that >> this build requires a Java 5 or newer platform to run because the embedded >> OSGi classes are compiled for Java 5 and are using generics. Great care has >> nevertheless been taken to not actually require Java 5 platform or API >> features. So, after recompiling the OSGi classes and this bundle using the >> target "jsr14" this bundle is expected to run on Java 1.4 compliant >> platforms. >> >> The next release coming soon will implement version 1.5 of the >> Configuration Admin specification to be published in the upcoming >> Compendium 5 specification. >> >> We solved 22 issues in this release: >> >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12316414 >> >> Staging repository: >> >> https://repository.apache.org/content/repositories/orgapachefelix-157/ >> >> 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 157 /tmp/felix-staging >> >> Please vote to approve this release: >> >> [ ] +1 Approve the release >> [ ] -1 Veto the release (please provide specific comments) >> >> This vote will be open for 72 hours. >> >> Regards >> Felix >> >> >> >> -- >> Karl Pauls >> karlpa...@gmail.com >> http://twitter.com/karlpauls >> http://www.linkedin.com/in/karlpauls >> https://profiles.google.com/karlpauls >> > > > > -- > Best Regards, > -- Alex
Re: [VOTE] Release Apache Felix Web Console 4.0.0 and plugins
+1, Regards, Clement Sent from my iPhone On 04.06.2012, at 13:48, Alex Karasulu wrote: > +1 > > On Mon, Jun 4, 2012 at 12:03 PM, Karl Pauls wrote: > >> +1 >> >> regards, >> >> Karl >> >> On Mon, Jun 4, 2012 at 9:30 AM, Carsten Ziegeler >> wrote: >>> +1 >>> >>> Carsten >>> >>> 2012/6/3 Jamie G. : +1 (non-binding) Cheers, Jamie On Fri, Jun 1, 2012 at 5:10 PM, Felix Meschberger >> wrote: > Hi, > > Am 01.06.2012 um 20:33 schrieb Richard S. Hall: > >> +1 >> >> No changelog in OBR plugin. > > Right. I added it after cutting the release. > > Regards > Felix > >> >> -> richard >> >> On 6/1/12 11:45 , Felix Meschberger wrote: >>> Hi, >>> >>> This is a large vote on the Web Console and a number of plugins >> extracted from the web console or updated since the last release. >>> >>> I bumped the Web Console to version 4 because it now only comes in >> the "bare" variant. That is the JSON and Commons FileUpload dependencies >> are not part of the Web Console bundle any longer and must be installed >> separately. For JSON, the Geronimo JSON bundle may be used while the >> Commons FileUpload library already comes as a bundle. >>> >>> In addition a number of plugins have been ripped out of the Web >> Console into separate bundles: DS and OBR. The Memory Usage plugin has been >> updated. The Package Admin and UPnP plugins are new plugins. >>> >>> Here are the links to the JIRA fixed versions: >>> >>> Web Console 4.0.0 >>> https://issues.apache.org/jira/browse/FELIX/fixforversion/12316160 >>> >>> DS Plugin 1.0 >>> https://issues.apache.org/jira/browse/FELIX/fixforversion/12317872 >>> >>> Memory Usage Plugin 1.0.4 >>> https://issues.apache.org/jira/browse/FELIX/fixforversion/12314875 >>> >>> OBR Plugin 1.0 >>> https://issues.apache.org/jira/browse/FELIX/fixforversion/12317956 >>> >>> PackageAdmin Plugin 1.0.0 >>> https://issues.apache.org/jira/browse/FELIX/fixforversion/12316672 >>> >>> UPnP Plugin 1.0.2 >>> https://issues.apache.org/jira/browse/FELIX/fixforversion/12314879 >>> >>> >>> Staging repository: >>> >> https://repository.apache.org/content/repositories/orgapachefelix-174/ >>> >>> 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 174 /tmp/felix-staging >>> >>> Please vote to approve this release: >>> >>> [ ] +1 Approve the release >>> [ ] -1 Veto the release (please provide specific comments) >>> >>> This vote will be open for at least 72 hours (due to weekend and >> large number of artifacts). >>> >>> Regards >>> Felix > >>> >>> >>> >>> -- >>> Carsten Ziegeler >>> cziege...@apache.org >> >> >> >> -- >> Karl Pauls >> karlpa...@gmail.com >> http://twitter.com/karlpauls >> http://www.linkedin.com/in/karlpauls >> https://profiles.google.com/karlpauls >> > > > > -- > Best Regards, > -- Alex
Re: [VOTE] Release Felix Configuration Admin version 1.4.0
+1, Regards, Clement On 30.05.2012, at 15:20, Felix Meschberger wrote: > Hi, > > This is a vote on version 1.4.0 of the Felix Configuration Admin Service > implementation. The corner stones of this release a re compliance with the > latest Configuration Admin Service specification (version 1.4 as published in > Compendium 4.3 specification). > > At the same time, this is basically the same code, which is also used as the > reference implementation for the Configuration Admin 1.4 specification. As > such this release, of course also passes the CT for the Configuration Admin > 1.4. > > The main big difference to earlier releases of this bundle is, that this > build requires a Java 5 or newer platform to run because the embedded OSGi > classes are compiled for Java 5 and are using generics. Great care has > nevertheless been taken to not actually require Java 5 platform or API > features. So, after recompiling the OSGi classes and this bundle using the > target "jsr14" this bundle is expected to run on Java 1.4 compliant platforms. > > The next release coming soon will implement version 1.5 of the Configuration > Admin specification to be published in the upcoming Compendium 5 > specification. > > We solved 22 issues in this release: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12316414 > > Staging repository: > https://repository.apache.org/content/repositories/orgapachefelix-157/ > > 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 157 /tmp/felix-staging > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Veto the release (please provide specific comments) > > This vote will be open for 72 hours. > > Regards > Felix
[jira] [Resolved] (FELIX-3501) IPojo FactoryStateListener doesn't get notified while stopping factory
[ https://issues.apache.org/jira/browse/FELIX-3501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier resolved FELIX-3501. -- Resolution: Fixed Fix Version/s: (was: iPOJO-1.8.0) ipojo-core-1.8.4 Was fixed in trunk. Waiting for confirmation. > IPojo FactoryStateListener doesn't get notified while stopping factory > -- > > Key: FELIX-3501 > URL: https://issues.apache.org/jira/browse/FELIX-3501 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: iPOJO-1.8.0 >Reporter: Göktürk Gezer > Assignee: Clement Escoffier > Labels: ipojo > Fix For: ipojo-core-1.8.4 > > > When stopping/uninstalling bundle of some IPojo component, > FactoryStateListener references don't get notified. -- 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-3508) IPojo Manipulator left out 'array of enums' in generated metadata
[ https://issues.apache.org/jira/browse/FELIX-3508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier resolved FELIX-3508. -- Resolution: Fixed Fixed in trunk > IPojo Manipulator left out 'array of enums' in generated metadata > - > > Key: FELIX-3508 > URL: https://issues.apache.org/jira/browse/FELIX-3508 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: ipojo-manipulator-1.8.4 >Reporter: Göktürk Gezer >Assignee: Clement Escoffier >Priority: Minor > Labels: ipojo, ipojo-manipulator > Fix For: ipojo-manipulator-1.8.6 > > > Manipulation process recognizes enums as annotation attribute in custom > handler annotations. However it fails to recognize array of enums, and these > arrays does not goes into generated IPojo component metadata for custom > handler. -- 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-3508) IPojo Manipulator left out 'array of enums' in generated metadata
[ https://issues.apache.org/jira/browse/FELIX-3508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13278045#comment-13278045 ] Clement Escoffier commented on FELIX-3508: -- I've reproduced the issue (and wrote a test). It seems that they are just completely ignored. > IPojo Manipulator left out 'array of enums' in generated metadata > - > > Key: FELIX-3508 > URL: https://issues.apache.org/jira/browse/FELIX-3508 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: ipojo-manipulator-1.8.4 > Reporter: Göktürk Gezer >Assignee: Clement Escoffier >Priority: Minor > Labels: ipojo, ipojo-manipulator > Fix For: ipojo-manipulator-1.8.6 > > > Manipulation process recognizes enums as annotation attribute in custom > handler annotations. However it fails to recognize array of enums, and these > arrays does not goes into generated IPojo component metadata for custom > handler. -- 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] [Assigned] (FELIX-3501) IPojo FactoryStateListener doesn't get notified while stopping factory
[ https://issues.apache.org/jira/browse/FELIX-3501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier reassigned FELIX-3501: Assignee: Clement Escoffier > IPojo FactoryStateListener doesn't get notified while stopping factory > -- > > Key: FELIX-3501 > URL: https://issues.apache.org/jira/browse/FELIX-3501 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: iPOJO-1.8.0 >Reporter: Göktürk Gezer > Assignee: Clement Escoffier > Labels: ipojo > Fix For: iPOJO-1.8.0 > > > When stopping/uninstalling bundle of some IPojo component, > FactoryStateListener references don't get notified. -- 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] [Assigned] (FELIX-3508) IPojo Manipulator left out 'array of enums' in generated metadata
[ https://issues.apache.org/jira/browse/FELIX-3508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier reassigned FELIX-3508: Assignee: Clement Escoffier > IPojo Manipulator left out 'array of enums' in generated metadata > - > > Key: FELIX-3508 > URL: https://issues.apache.org/jira/browse/FELIX-3508 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: ipojo-manipulator-1.8.4 >Reporter: Göktürk Gezer >Assignee: Clement Escoffier >Priority: Minor > Labels: ipojo, ipojo-manipulator > Fix For: ipojo-manipulator-1.8.6 > > > Manipulation process recognizes enums as annotation attribute in custom > handler annotations. However it fails to recognize array of enums, and these > arrays does not goes into generated IPojo component metadata for custom > handler. -- 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-3451) "instance.name" attribute not recognized
[ https://issues.apache.org/jira/browse/FELIX-3451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier updated FELIX-3451: - Fix Version/s: (was: ipojo-composite-1.8.2) ipojo-composite-1.8.4 > "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.4 > > 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] [Closed] (FELIX-3130) Nested composites throws StackOverflowError on instantiation
[ https://issues.apache.org/jira/browse/FELIX-3130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier closed FELIX-3130. iPOJO Compiste 1.8.2 was released. > Nested composites throws StackOverflowError on instantiation > > > Key: FELIX-3130 > URL: https://issues.apache.org/jira/browse/FELIX-3130 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: iPOJO-1.8.0 >Reporter: Thiago Souza > Assignee: Clement Escoffier > Fix For: ipojo-composite-1.8.2 > > Attachments: stackoverflow.txt > > > The following metadata.xml describes a composite with another nested > composite. Instantiating "composite-external" throws a StackOverflowError > > xmlns:c="org.apache.felix.ipojo.composite"> > > > > > > > > > > > -- 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-3081) Integrate the online-manipulator in iPOJO Core
[ https://issues.apache.org/jira/browse/FELIX-3081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier resolved FELIX-3081. -- Resolution: Fixed Was done. > Integrate the online-manipulator in iPOJO Core > -- > > Key: FELIX-3081 > URL: https://issues.apache.org/jira/browse/FELIX-3081 > Project: Felix > Issue Type: Improvement > Reporter: Clement Escoffier > Assignee: Clement Escoffier > Fix For: ipojo-core-1.8.2 > > > The online-manipulator providing the ipojo:// url handler is in its own > bundle. It could be integrated to iPOJO Core making more easy to use it. -- 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
[RESULT][VOTE] Release of iPOJO Runtime 1.8.2
Hi, It's time to close the vote. The vote is successful with the following results: +1: Guillaume Sauthier, Richard Hall, Karl Pauls, Clement Escoffier I'll publish the binaries and update the web site asap. Thanks and Regards, Clement On 21.04.2012, at 18:40, Clement Escoffier wrote: > Hi, > > It's time to cut a release of the iPOJO Runtime project (1.8.2). > > This releases contains: > * iPOJO Core 1.8.2 > * iPOJO Composite 1.8.2 > * iPOJO Annotations 1.8.2 > * iPOJO Runtime Project 1.8.2 > > (the changelog is included below) > > Staging repository: > https://repository.apache.org/content/repositories/orgapachefelix-079/ > > 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 079 /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: > ** Bug > * [FELIX-2893] - Properties are not propagate to service by default > * [FELIX-2902] - Service properties added by propagation overrides > already existing properties > * [FELIX-2907] - Problem calling _setInstanceManager on guice enhanced > classe > * [FELIX-2981] - Unable to remove configuration properties using iPOJO's > configuration handler > * [FELIX-2989] - Using a Service Controller set to true can trigger a > service registration-unregistration-registration sequence > * [FELIX-2995] - The service properties are updated despite there is no > changes > * [FELIX-3009] - Abstract classes as service specifications generates > warnings at runtime > * [FELIX-3075] - Change to ServiceController status in current trunk does > not re-register service > * [FELIX-3130] - Nested composites throws StackOverflowError on > instantiation > * [FELIX-3172] - Error when calling BundleContext.register(Class, Object, > Dictionary) > * [FELIX-3192] - Service properties are not updated if the properties > were already propagated > * [FELIX-3271] - On KF, the Instance singleton strategy throws an > UnsupportedOperationException when stopping > * [FELIX-3323] - Ipojo composite throw ClassCastException when > configuration is updated thru ConfigAdmin > * [FELIX-3356] - Objectweb ASM Clashes with IPojo > * [FELIX-3374] - Use of java.lang.Properties in iPOJO Core > * [FELIX-3451] - "instance.name" attribute not recognized > > ** Improvement > * [FELIX-3036] - Add IPOJO-Components header support > * [FELIX-3081] - Integrate the online-manipulator in iPOJO Core > * [FELIX-3144] - Method interceptors should receive Method or Constructor > objects > * [FELIX-3155] - Allow identifying iPojo extensions by a namespace > qualified name > * [FELIX-3190] - iPOJO Factories doesn't give access to the complete > Metadata model > * [FELIX-3252] - Merge the online manipulator into iPOJO Core > * [FELIX-3326] - Accessing IPojo-Component's all inherited classes and > all implemented interfaces in PrimitiveTypeDescription > * [FELIX-3380] - minor javadoc corrections in @Temporal annotation > > ** New Feature > * [FELIX-2932] - Allows disabling the asynchronous processing in the > iPOJO Extender
Re: [VOTE] Release of iPOJO Runtime 1.8.2
Hi, On 08.05.2012, at 22:18, Richard S. Hall wrote: > +1 > > Minor issues: > > * Copyright year not updated in annotations and composite. Fixed in trunk. > * The NOTICE/DEPS file seem out of sync for the runtime project. What > actually is the runtime project? Just an aggregation of the other > projects? > The runtime project is not an aggregator 'per se' (it does not produce a runnable artifact), but the distributions, created by this project, contain all the other projects. So, I think that the NOTICE and DEPENDENCIES must aggregate all the other ones. I've updated the funk to reflect those changes. Regards, Clement > > -> richard > > On 4/21/12 12:40 , Clement Escoffier wrote: >> Hi, >> >> It's time to cut a release of the iPOJO Runtime project (1.8.2). >> >> This releases contains: >> * iPOJO Core 1.8.2 >> * iPOJO Composite 1.8.2 >> * iPOJO Annotations 1.8.2 >> * iPOJO Runtime Project 1.8.2 >> >> (the changelog is included below) >> >> Staging repository: >> https://repository.apache.org/content/repositories/orgapachefelix-079/ >> >> 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 079 /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: >> ** Bug >> * [FELIX-2893] - Properties are not propagate to service by default >> * [FELIX-2902] - Service properties added by propagation overrides >> already existing properties >> * [FELIX-2907] - Problem calling _setInstanceManager on guice enhanced >> classe >> * [FELIX-2981] - Unable to remove configuration properties using iPOJO's >> configuration handler >> * [FELIX-2989] - Using a Service Controller set to true can trigger a >> service registration-unregistration-registration sequence >> * [FELIX-2995] - The service properties are updated despite there is no >> changes >> * [FELIX-3009] - Abstract classes as service specifications generates >> warnings at runtime >> * [FELIX-3075] - Change to ServiceController status in current trunk >> does not re-register service >> * [FELIX-3130] - Nested composites throws StackOverflowError on >> instantiation >> * [FELIX-3172] - Error when calling BundleContext.register(Class, >> Object, Dictionary) >> * [FELIX-3192] - Service properties are not updated if the properties >> were already propagated >> * [FELIX-3271] - On KF, the Instance singleton strategy throws an >> UnsupportedOperationException when stopping >> * [FELIX-3323] - Ipojo composite throw ClassCastException when >> configuration is updated thru ConfigAdmin >> * [FELIX-3356] - Objectweb ASM Clashes with IPojo >> * [FELIX-3374] - Use of java.lang.Properties in iPOJO Core >> * [FELIX-3451] - "instance.name" attribute not recognized >> >> ** Improvement >> * [FELIX-3036] - Add IPOJO-Components header support >> * [FELIX-3081] - Integrate the online-manipulator in iPOJO Core >> * [FELIX-3144] - Method interceptors should receive Method or >> Constructor objects >> * [FELIX-3155] - Allow identifying iPojo extensions by a namespace >> qualified name >> * [FELIX-3190] - iPOJO Factories doesn't give access to the complete >> Metadata model >> * [FELIX-3252] - Merge the online manipulator into iPOJO Core >> * [FELIX-3326] - Accessing IPojo-Component's all inherited classes and >> all implemented interfaces in PrimitiveTypeDescription >> * [FELIX-3380] - minor javadoc corrections in @Temporal annotation >> >> ** New Feature >> * [FELIX-2932] - Allows disabling the asynchronous processing in the >> iPOJO Extender
Re: [VOTE] Release of iPOJO Runtime 1.8.2
+1, Regards, Clement On 21.04.2012, at 18:40, Clement Escoffier wrote: > Hi, > > It's time to cut a release of the iPOJO Runtime project (1.8.2). > > This releases contains: > * iPOJO Core 1.8.2 > * iPOJO Composite 1.8.2 > * iPOJO Annotations 1.8.2 > * iPOJO Runtime Project 1.8.2 > > (the changelog is included below) > > Staging repository: > https://repository.apache.org/content/repositories/orgapachefelix-079/ > > 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 079 /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: > ** Bug > * [FELIX-2893] - Properties are not propagate to service by default > * [FELIX-2902] - Service properties added by propagation overrides > already existing properties > * [FELIX-2907] - Problem calling _setInstanceManager on guice enhanced > classe > * [FELIX-2981] - Unable to remove configuration properties using iPOJO's > configuration handler > * [FELIX-2989] - Using a Service Controller set to true can trigger a > service registration-unregistration-registration sequence > * [FELIX-2995] - The service properties are updated despite there is no > changes > * [FELIX-3009] - Abstract classes as service specifications generates > warnings at runtime > * [FELIX-3075] - Change to ServiceController status in current trunk does > not re-register service > * [FELIX-3130] - Nested composites throws StackOverflowError on > instantiation > * [FELIX-3172] - Error when calling BundleContext.register(Class, Object, > Dictionary) > * [FELIX-3192] - Service properties are not updated if the properties > were already propagated > * [FELIX-3271] - On KF, the Instance singleton strategy throws an > UnsupportedOperationException when stopping > * [FELIX-3323] - Ipojo composite throw ClassCastException when > configuration is updated thru ConfigAdmin > * [FELIX-3356] - Objectweb ASM Clashes with IPojo > * [FELIX-3374] - Use of java.lang.Properties in iPOJO Core > * [FELIX-3451] - "instance.name" attribute not recognized > > ** Improvement > * [FELIX-3036] - Add IPOJO-Components header support > * [FELIX-3081] - Integrate the online-manipulator in iPOJO Core > * [FELIX-3144] - Method interceptors should receive Method or Constructor > objects > * [FELIX-3155] - Allow identifying iPojo extensions by a namespace > qualified name > * [FELIX-3190] - iPOJO Factories doesn't give access to the complete > Metadata model > * [FELIX-3252] - Merge the online manipulator into iPOJO Core > * [FELIX-3326] - Accessing IPojo-Component's all inherited classes and > all implemented interfaces in PrimitiveTypeDescription > * [FELIX-3380] - minor javadoc corrections in @Temporal annotation > > ** New Feature > * [FELIX-2932] - Allows disabling the asynchronous processing in the > iPOJO Extender
[jira] [Assigned] (FELIX-3500) InstanceManager concurrency issue: "A methodID cannot be associated with a method from the POJO class"
[
https://issues.apache.org/jira/browse/FELIX-3500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clement Escoffier reassigned FELIX-3500:
Assignee: Clement Escoffier
> InstanceManager concurrency issue: "A methodID cannot be associated with a
> method from the POJO class"
> --
>
> Key: FELIX-3500
> URL: https://issues.apache.org/jira/browse/FELIX-3500
> Project: Felix
> Issue Type: Bug
> Components: iPOJO
>Affects Versions: ipojo-core-1.8.2
>Reporter: Francois Valdy
>Assignee: Clement Escoffier
>
> InstanceManager.getMethodByID(String) claims to be thread-safe (or not to
> require synchronization) but is not.
> It results in random messages "A methodID cannot be associated with a method
> from the POJO class" (which were downgraded from ERROR to INFO), but has
> unknown side effect bugs (as it returns null for valid methods when that
> happens).
> If 2 threads call this method with the same parameter:
> - both won't find it in the cache (m_methods.get(methodId) == null)
> - one will register it: !m_methods.containsValue(mets[i]) is true
> - second thread will NOT register it (because the first one did, hence the
> value is in the map), and will return null <-- bug
> Other issues may occur from the fact that an HashMap (unsafe) is used without
> synchronization, for instance a well-known infinite loop.
> I think one fix (to keep the same method semantics) under J2SE 1.3 would be
> to:
> - use Hashtable instead of HashMap (safe as the value is never null)
> - replace the code within the loop by:
> if (m_methods.containsValue(mets[i]))
> {
> method = (Method) m_methods.get(methodId);
> if (method != null)
> {
> return method;
> }
> }
> else if
> (MethodMetadata.computeMethodId(mets[i]).equals(methodId))
> {
> // Store the new methodId
> m_methods.put(methodId, mets[i]);
> return mets[i];
> }
> However I'm not sure about the purpose of the containsValue check purpose
> (which is also very expensive as it traverses the entire map).
> Thanks.
--
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: [VOTE] Release FileInstall 3.2.2
+1, Regards, Clement On 18.04.2012, at 09:41, Guillaume Nodet wrote: > We solved 18 issues in this > release:https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12320555&styleName=Html&projectId=12310100 > There are still 9 outstanding > issues:https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+FELIX+AND+component+%3D+%22File+Install%22+AND+status+%3D+Open+ORDER+BY+priority+DESC&mode=hideThree > of those are bugs and will have to be fixed in a following up > maintenance release. > > Staging repository: > https://repository.apache.org/content/repositories/orgapachefelix-069/ > 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 069 /tmp/felix-staging > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Veto the release (please provide specific comments) > > This vote will be open for at least 72 hours. > > > -- > > Guillaume Nodet > > Blog: http://gnodet.blogspot.com/ > > FuseSource, Integration everywhere > http://fusesource.com
[VOTE] Release of iPOJO Runtime 1.8.2
Hi, It's time to cut a release of the iPOJO Runtime project (1.8.2). This releases contains: * iPOJO Core 1.8.2 * iPOJO Composite 1.8.2 * iPOJO Annotations 1.8.2 * iPOJO Runtime Project 1.8.2 (the changelog is included below) Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-079/ 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 079 /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: ** Bug * [FELIX-2893] - Properties are not propagate to service by default * [FELIX-2902] - Service properties added by propagation overrides already existing properties * [FELIX-2907] - Problem calling _setInstanceManager on guice enhanced classe * [FELIX-2981] - Unable to remove configuration properties using iPOJO's configuration handler * [FELIX-2989] - Using a Service Controller set to true can trigger a service registration-unregistration-registration sequence * [FELIX-2995] - The service properties are updated despite there is no changes * [FELIX-3009] - Abstract classes as service specifications generates warnings at runtime * [FELIX-3075] - Change to ServiceController status in current trunk does not re-register service * [FELIX-3130] - Nested composites throws StackOverflowError on instantiation * [FELIX-3172] - Error when calling BundleContext.register(Class, Object, Dictionary) * [FELIX-3192] - Service properties are not updated if the properties were already propagated * [FELIX-3271] - On KF, the Instance singleton strategy throws an UnsupportedOperationException when stopping * [FELIX-3323] - Ipojo composite throw ClassCastException when configuration is updated thru ConfigAdmin * [FELIX-3356] - Objectweb ASM Clashes with IPojo * [FELIX-3374] - Use of java.lang.Properties in iPOJO Core * [FELIX-3451] - "instance.name" attribute not recognized ** Improvement * [FELIX-3036] - Add IPOJO-Components header support * [FELIX-3081] - Integrate the online-manipulator in iPOJO Core * [FELIX-3144] - Method interceptors should receive Method or Constructor objects * [FELIX-3155] - Allow identifying iPojo extensions by a namespace qualified name * [FELIX-3190] - iPOJO Factories doesn't give access to the complete Metadata model * [FELIX-3252] - Merge the online manipulator into iPOJO Core * [FELIX-3326] - Accessing IPojo-Component's all inherited classes and all implemented interfaces in PrimitiveTypeDescription * [FELIX-3380] - minor javadoc corrections in @Temporal annotation ** New Feature * [FELIX-2932] - Allows disabling the asynchronous processing in the iPOJO Extender
[jira] [Issue Comment Edited] (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:comment-tabpanel&focusedCommentId=13255683#comment-13255683 ] Clement Escoffier edited comment on FELIX-3461 at 4/17/12 4:11 PM: --- I've applied a mix of both patch + some spices from me. Please check with the trunk version. was (Author: clement.escoffier): I've applied a mix of both patch + some spices from me. > 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 >Assignee: Clement Escoffier > Labels: ipojo-manipulator > Fix For: ipojo-manipulator-1.8.6 > > Attachments: FELIX-3461-GSA.patch, > 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] [Resolved] (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 ] Clement Escoffier resolved FELIX-3461. -- Resolution: Fixed Fix Version/s: ipojo-manipulator-1.8.6 Assignee: Clement Escoffier I've applied a mix of both patch + some spices from me. > 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 >Assignee: Clement Escoffier > Labels: ipojo-manipulator > Fix For: ipojo-manipulator-1.8.6 > > Attachments: FELIX-3461-GSA.patch, > 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] [Commented] (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:comment-tabpanel&focusedCommentId=13255625#comment-13255625 ] Clement Escoffier commented on FELIX-3461: -- For information here is the test: https://gist.github.com/2406634 > 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: FELIX-3461-GSA.patch, > 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] [Commented] (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:comment-tabpanel&focusedCommentId=13255621#comment-13255621 ] Clement Escoffier commented on FELIX-3461: -- In my test I don't write the manifest as I just read the Element-Attribute structure (it's really a unit test). I don't see the 'transition methods gone' effect. The metadata re not correct but still here: callback transition="validate" method="__M_start", instance component="test.PlentyOfAnnotations" I've all the other effects. So I can now have a look to your patch and check what it is doing 'for real'. > 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: FELIX-3461-GSA.patch, > 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] [Commented] (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:comment-tabpanel&focusedCommentId=13255610#comment-13255610 ] Clement Escoffier commented on FELIX-3461: -- Hi, I've reproduced part (all?) of the issue. I've a class with PlentyOfAnnotations - including constructor, class, field and method annotations. It use both iPOJO core annotations but also external handler annotations. * I extract the metadata from the class - the metadata are ok * I manipulate the class a first time - manipulation metadata ok * I extract a second times the metadata from the manipulated class - the metadata are not ok... the method are wrong and the index parameters are shift by 1. * I manipulate a second time - manipulation metadata ok but including all the new methods. My test is checking both the manipulation (and the computation of the manipulation metadata) and the metadata collected from the classes. Do I cover everything ? > 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: FELIX-3461-GSA.patch, > 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] [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=13255334#comment-13255334 ] Clement Escoffier commented on FELIX-3451: -- Yes it is. Jira says it's the revision #1326271. > "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
Re: Re-manipulation generates corrupted MANIFEST on annotated components.
Hi, We started looking at it. Guillaume did some work on it. So, first the second evaluation of the annotations is definitely a bug. We're now trying to be sure we're not breaking something somewhere (like the component filter). So you can be sure we will fix the issue. The patch or a slightly different version will be applied this week. I'm focussing on an ipojo core and composite release, and then back to the manipulator. Regards, Clement Sent from my iPhone On 16.04.2012, at 17:42, Göktürk Gezer wrote: > Hi Devs, > > Sorry for pressuring but this is blocker for us in ApacheDS. Could some one > please evaluate the issue and the patch? We really need to know whether > it'll be fixed or not? > > Thanks, > Gokturk > > On Sun, Apr 15, 2012 at 1:11 AM, Göktürk Gezer wrote: > >> 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] [Resolved] (FELIX-3356) Objectweb ASM Clashes with IPojo
[ https://issues.apache.org/jira/browse/FELIX-3356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier resolved FELIX-3356. -- Resolution: Fixed Fix Version/s: (was: ipojo-manipulator-1.8.6) ipojo-core-1.8.2 Fixed in trunk. ASM packages are now private to iPOJO bundles > Objectweb ASM Clashes with IPojo > > > Key: FELIX-3356 > URL: https://issues.apache.org/jira/browse/FELIX-3356 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: ipojo-manipulator-1.8.4 >Reporter: Bob Ziuchkovski > Assignee: Clement Escoffier >Priority: Minor > Fix For: ipojo-core-1.8.2 > > > Ipojo automatically imports org.apache.felix.ipojo.architecture for bundles > that it manages, and org.apache.felix.ipojo.architecture is marked as using > org.objectweb.asm. This creates conflicts for any ipojo-managed bundle that > wishes to import and use a different objectweb asm version (i.e. 4.0) for > non-ipojo purposes. See the below output for an example: > Error executing command: Error starting bundles: > Unable to start bundle 107: Uses constraint violation. Unable to > resolve bundle revision test.service [107.0] because it is exposed to package > 'org.objectweb.asm' from bundle revisions org.objectweb.asm.all [98.0] and > org.apache.felix.ipojo [99.0] via two dependency chains. > Chain 1: > test.service [107.0] > import: > (&(osgi.wiring.package=org.objectweb.asm)(version>=4.0.0)(!(version>=5.0.0))) > | > export: osgi.wiring.package=org.objectweb.asm > org.objectweb.asm.all [98.0] > Chain 2: > test.service [107.0] > import: > (&(osgi.wiring.package=org.apache.felix.ipojo.architecture)(version>=1.8.0)) > | > export: osgi.wiring.package=org.apache.felix.ipojo.architecture; > uses:=org.objectweb.asm > export: osgi.wiring.package=org.objectweb.asm > org.apache.felix.ipojo [99.0] -- 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=13254281#comment-13254281 ] Clement Escoffier commented on FELIX-3451: -- Oups... sorry it seems that I've changed something in my code. I've committed my fix. > "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] [Updated] (FELIX-3421) Blocked Thread while shutting down Felix during iPojo service registration
[ https://issues.apache.org/jira/browse/FELIX-3421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier updated FELIX-3421: - Component/s: Framework > Blocked Thread while shutting down Felix during iPojo service registration > -- > > Key: FELIX-3421 > URL: https://issues.apache.org/jira/browse/FELIX-3421 > Project: Felix > Issue Type: Bug > Components: Framework, iPOJO >Affects Versions: iPOJO-1.8.0 > Environment: Win 7 / Java 1.6 >Reporter: David GAY > Labels: block, bundle, ipojo, lock, thread > Attachments: threaddump-186501972.tdump > > > Problem when Felix is starting up and iPojo services are still registering > while and in the meantime a stop Felix is requested. > The code to stop Felix is : getBundle(0).stop() > By looking at the Thread Dump it appears that iPojo is synchronously dealing > with a bundle being stopped while at the same time trying to register a > service for that bundle. > Since the component framework is holding and/or needs its own internal lock > when dealing with the stopped bundle and registering the service, we get into > a deadlock situation, since both threads also need the bundle lock too. > ThreadDump (full TD in attachement): > "FelixStartLevel" daemon prio=6 tid=0x06d6c000 nid=0xb00 waiting for > monitor entry [0x07fbf000] >java.lang.Thread.State: BLOCKED (on object monitor) > at > org.apache.felix.ipojo.IPojoFactory.removeFactoryStateListener(IPojoFactory.java:491) > - waiting to lock <0xc048c790> (a > org.apache.felix.ipojo.ComponentFactory) > at > org.apache.felix.ipojo.InstanceCreator.removeFactory(InstanceCreator.java:187) > at > org.apache.felix.ipojo.Extender.closeManagementFor(Extender.java:156) > at > org.apache.felix.ipojo.Extender.bundleChanged(Extender.java:129) > at > org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:868) > at > org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:789) > at > org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:514) > at > org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4245) > at > org.apache.felix.framework.Felix.stopBundle(Felix.java:2352) > at > org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1215) > at > org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295) > at java.lang.Thread.run(Unknown Source) > "Thread-2" daemon prio=6 tid=0x07050800 nid=0x6d8 in Object.wait() > [0x084bd000] >java.lang.Thread.State: WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > - waiting on <0xc029d238> (a [Ljava.lang.Object;) > at java.lang.Object.wait(Object.java:485) > at > org.apache.felix.framework.Felix.acquireBundleLock(Felix.java:4872) > - locked <0xc029d238> (a [Ljava.lang.Object;) > at > org.apache.felix.framework.Felix.registerService(Felix.java:3206) > at > org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346) > at > org.apache.felix.ipojo.IPojoContext.registerService(IPojoContext.java:338) > at > org.apache.felix.ipojo.handlers.providedservice.ProvidedService.registerService(ProvidedService.java:345) > - locked <0xeafc8ea0> (a > org.apache.felix.ipojo.handlers.providedservice.ProvidedService) > at > org.apache.felix.ipojo.handlers.providedservice.ProvidedServiceHandler.__stateChanged(ProvidedServiceHandler.java:494) > at > org.apache.felix.ipojo.handlers.providedservice.ProvidedServiceHandler.stateChanged(ProvidedServiceHandler.java) > at > org.apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:471) > at > org.apache.felix.ipojo.InstanceManager.start(InstanceManager.java:353) > at > org.apache.felix.ipojo.ComponentFactory.createInstance(ComponentFactory.java:166) > at > org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:301) >
[jira] [Commented] (FELIX-3421) Blocked Thread while shutting down Felix during iPojo service registration
[ https://issues.apache.org/jira/browse/FELIX-3421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13254276#comment-13254276 ] Clement Escoffier commented on FELIX-3421: -- Hi, >From the thread dump, it's not clear it's related to iPOJO. iPOJO is creating a component instance and to achieve this hold the lock on the factory (to avoid any state change while registering an instance). At the same time, Felix is stopped and so, the factory is stopped. The stopping process of the factory has to wait to acquire the factory lock. This is normal and expected. The issue I don't get is why Felix is stucked during the service registration. As the registration is stucked, the instance creation never returns and as a consequence the lock on the factory is never released. > Blocked Thread while shutting down Felix during iPojo service registration > -- > > Key: FELIX-3421 > URL: https://issues.apache.org/jira/browse/FELIX-3421 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: iPOJO-1.8.0 > Environment: Win 7 / Java 1.6 >Reporter: David GAY > Labels: block, bundle, ipojo, lock, thread > Attachments: threaddump-186501972.tdump > > > Problem when Felix is starting up and iPojo services are still registering > while and in the meantime a stop Felix is requested. > The code to stop Felix is : getBundle(0).stop() > By looking at the Thread Dump it appears that iPojo is synchronously dealing > with a bundle being stopped while at the same time trying to register a > service for that bundle. > Since the component framework is holding and/or needs its own internal lock > when dealing with the stopped bundle and registering the service, we get into > a deadlock situation, since both threads also need the bundle lock too. > ThreadDump (full TD in attachement): > "FelixStartLevel" daemon prio=6 tid=0x06d6c000 nid=0xb00 waiting for > monitor entry [0x07fbf000] >java.lang.Thread.State: BLOCKED (on object monitor) > at > org.apache.felix.ipojo.IPojoFactory.removeFactoryStateListener(IPojoFactory.java:491) > - waiting to lock <0xc048c790> (a > org.apache.felix.ipojo.ComponentFactory) > at > org.apache.felix.ipojo.InstanceCreator.removeFactory(InstanceCreator.java:187) > at > org.apache.felix.ipojo.Extender.closeManagementFor(Extender.java:156) > at > org.apache.felix.ipojo.Extender.bundleChanged(Extender.java:129) > at > org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:868) > at > org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:789) > at > org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:514) > at > org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4245) > at > org.apache.felix.framework.Felix.stopBundle(Felix.java:2352) > at > org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1215) > at > org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295) > at java.lang.Thread.run(Unknown Source) > "Thread-2" daemon prio=6 tid=0x07050800 nid=0x6d8 in Object.wait() > [0x084bd000] >java.lang.Thread.State: WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > - waiting on <0xc029d238> (a [Ljava.lang.Object;) > at java.lang.Object.wait(Object.java:485) > at > org.apache.felix.framework.Felix.acquireBundleLock(Felix.java:4872) > - locked <0xc029d238> (a [Ljava.lang.Object;) > at > org.apache.felix.framework.Felix.registerService(Felix.java:3206) > at > org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346) > at > org.apache.felix.ipojo.IPojoContext.registerService(IPojoContext.java:338) > at > org.apache.felix.ipojo.handlers.providedservice.ProvidedService.registerService(ProvidedService.java:345) > - locked <0xeafc8ea0> (a > org.apache.felix.ipojo.handlers.providedservice.ProvidedService) > at > org.apache.felix.ipojo.handlers.provide
[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] [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] [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] [Commented] (FELIX-3323) Ipojo composite throw ClassCastException when configuration is updated thru ConfigAdmin
[ https://issues.apache.org/jira/browse/FELIX-3323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13250512#comment-13250512 ] Clement Escoffier commented on FELIX-3323: -- Now that the new manipulator is released, we will plan a release of the core and composite. > Ipojo composite throw ClassCastException when configuration is updated thru > ConfigAdmin > --- > > Key: FELIX-3323 > URL: https://issues.apache.org/jira/browse/FELIX-3323 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: iPOJO-1.8.0 > Environment: Windows 7 - Felix 4.0.2 - Java 1.6.0_26 >Reporter: David GAY >Assignee: Clement Escoffier > Labels: composite, configurationadmin, ipojo > Fix For: ipojo-composite-1.8.2, ipojo-core-1.8.2 > > > 1- Declare an iPojo composite > 2- Create a configuration in ConfigAdmin for the composite > 3- Update the configuration in ConfigAdmin > A ClassCastException is raised when the configuration is updated, for example > : > *ERROR* [org.apache.felix.ipojo.Factory, > org.osgi.service.cm.ManagedServiceFactory, id=38, bundle=14]: Unexpected > problem updating Configuration > PID=foo.compo.26ec176f-6860-4100-a538-b5fb523d4a1f, fac > toryPID=foo.compo, > bundleLocation=file:../foo-composite/target/foo-composite-1.0.0-SNAPSHOT.jar > java.lang.ClassCastException: > org.apache.felix.ipojo.composite.CompositeManager cannot be cast to > org.apache.felix.ipojo.InstanceManager > at org.apache.felix.ipojo.IPojoFactory.updated(IPojoFactory.java:627) > at > org.apache.felix.cm.impl.ConfigurationManager$UpdateConfiguration.run(ConfigurationManager.java:1567) > at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:104) > at java.lang.Thread.run(Unknown Source) > A complete test project is available to reproduce the problem in this message > : http://old.nabble.com/iPojo-Composite-to33188907.html -- 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
[RESULT][VOTE] Release of the iPOJO Manipulator 1.8.4
Hi, It's time to close this vote. +1 votes from Guillaume Sauthier, Richard S. Hall, Felix Meschberger, Karl Pauls and Clement Escoffier The vote is successful. I will make the released artifacts available as soon as possible. Thanks and Regards, Clement On 30.03.2012, at 11:13, Clement Escoffier wrote: > Hi, > > It's time to cut a release of the iPOJO Manipulator project (1.8.4). > > This releases contains: > * org.apache.felix.ipojo.manipulator 1.8.4 > * maven-ipojo-plugin 1.8.4 > * ipojo-ant-task 1.8.4 > * bnd-ipojo-plugin 1.8.4 > * manipulator-project 1.8.4 > > (the changelog is included below) > > Staging repository: > https://repository.apache.org/content/repositories/orgapachefelix-129/ > > 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 129 /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: > ** Bug > * [FELIX-3297] - iPOJO Manipulator throws ClassNotFoundException > * [FELIX-3359] - Turn around to avoid to use the split verifier on Java 7 > * [FELIX-3389] - Bnd iPOJO Plugin ignores annotated components > * [FELIX-3391] - Unexpected warning when using bnd-ipojo-plugin > > ** Improvement > * [FELIX-3384] - Ensure maven-ipojo-plugin is thread-safe for parallel > maven builds >
Re: [VOTE] Release of the iPOJO Manipulator 1.8.4
Hi, On 04.04.2012, at 19:51, Richard S. Hall wrote: > +1 > > Minor notes: > > * The change log for manipulator doesn't appear to have a title for > this version...probably just fix it in trunk. Done. > * Why are we creating the -bin.tar.gz and -bin.zip files for these > artifacts? I don't recall these being generated before for releases > and we don't offer them in any way, do we? I still didn't migrate to the latest parent pom. It's on the roadmap, so probably the next version won't have such artifacts. Regards, Clement > > -> richard > > On 3/30/12 05:13 , Clement Escoffier wrote: >> Hi, >> >> It's time to cut a release of the iPOJO Manipulator project (1.8.4). >> >> This releases contains: >> * org.apache.felix.ipojo.manipulator 1.8.4 >> * maven-ipojo-plugin 1.8.4 >> * ipojo-ant-task 1.8.4 >> * bnd-ipojo-plugin 1.8.4 >> * manipulator-project 1.8.4 >> >> (the changelog is included below) >> >> Staging repository: >> https://repository.apache.org/content/repositories/orgapachefelix-129/ >> >> 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 129 /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: >> ** Bug >> * [FELIX-3297] - iPOJO Manipulator throws ClassNotFoundException >> * [FELIX-3359] - Turn around to avoid to use the split verifier on Java 7 >> * [FELIX-3389] - Bnd iPOJO Plugin ignores annotated components >> * [FELIX-3391] - Unexpected warning when using bnd-ipojo-plugin >> >> ** Improvement >> * [FELIX-3384] - Ensure maven-ipojo-plugin is thread-safe for parallel >> maven builds >> >>
Re: [VOTE] Release of the iPOJO Manipulator 1.8.4
+1, Regards, Clement On 05.04.2012, at 15:51, Karl Pauls wrote: > +1 > > regards, > > Karl > > On Thu, Apr 5, 2012 at 2:12 PM, Felix Meschberger wrote: >> +1 >> >> Regards >> Felix >> >> Am 30.03.2012 um 11:13 schrieb Clement Escoffier: >> >>> Hi, >>> >>> It's time to cut a release of the iPOJO Manipulator project (1.8.4). >>> >>> This releases contains: >>> * org.apache.felix.ipojo.manipulator 1.8.4 >>> * maven-ipojo-plugin 1.8.4 >>> * ipojo-ant-task 1.8.4 >>> * bnd-ipojo-plugin 1.8.4 >>> * manipulator-project 1.8.4 >>> >>> (the changelog is included below) >>> >>> Staging repository: >>> https://repository.apache.org/content/repositories/orgapachefelix-129/ >>> >>> 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 129 /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: >>> ** Bug >>>* [FELIX-3297] - iPOJO Manipulator throws ClassNotFoundException >>>* [FELIX-3359] - Turn around to avoid to use the split verifier on Java 7 >>>* [FELIX-3389] - Bnd iPOJO Plugin ignores annotated components >>>* [FELIX-3391] - Unexpected warning when using bnd-ipojo-plugin >>> >>> ** Improvement >>>* [FELIX-3384] - Ensure maven-ipojo-plugin is thread-safe for parallel >>> maven builds >>> >> > > > > -- > Karl Pauls > karlpa...@gmail.com > http://twitter.com/karlpauls > http://www.linkedin.com/in/karlpauls > https://profiles.google.com/karlpauls
[VOTE] Release of the iPOJO Manipulator 1.8.4
Hi, It's time to cut a release of the iPOJO Manipulator project (1.8.4). This releases contains: * org.apache.felix.ipojo.manipulator 1.8.4 * maven-ipojo-plugin 1.8.4 * ipojo-ant-task 1.8.4 * bnd-ipojo-plugin 1.8.4 * manipulator-project 1.8.4 (the changelog is included below) Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-129/ 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 129 /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: ** Bug * [FELIX-3297] - iPOJO Manipulator throws ClassNotFoundException * [FELIX-3359] - Turn around to avoid to use the split verifier on Java 7 * [FELIX-3389] - Bnd iPOJO Plugin ignores annotated components * [FELIX-3391] - Unexpected warning when using bnd-ipojo-plugin ** Improvement * [FELIX-3384] - Ensure maven-ipojo-plugin is thread-safe for parallel maven builds
[jira] [Updated] (FELIX-3356) Objectweb ASM Clashes with IPojo
[ https://issues.apache.org/jira/browse/FELIX-3356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier updated FELIX-3356: - Fix Version/s: (was: ipojo-manipulator-1.8.4) (was: ipojo-core-1.8.2) (was: ipojo-composite-1.8.2) ipojo-manipulator-1.8.6 Affects Version/s: (was: ipojo-manipulator-1.8.2) (was: iPOJO-1.8.0) ipojo-manipulator-1.8.4 > Objectweb ASM Clashes with IPojo > > > Key: FELIX-3356 > URL: https://issues.apache.org/jira/browse/FELIX-3356 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: ipojo-manipulator-1.8.4 >Reporter: Bob Ziuchkovski > Assignee: Clement Escoffier >Priority: Minor > Fix For: ipojo-manipulator-1.8.6 > > > Ipojo automatically imports org.apache.felix.ipojo.architecture for bundles > that it manages, and org.apache.felix.ipojo.architecture is marked as using > org.objectweb.asm. This creates conflicts for any ipojo-managed bundle that > wishes to import and use a different objectweb asm version (i.e. 4.0) for > non-ipojo purposes. See the below output for an example: > Error executing command: Error starting bundles: > Unable to start bundle 107: Uses constraint violation. Unable to > resolve bundle revision test.service [107.0] because it is exposed to package > 'org.objectweb.asm' from bundle revisions org.objectweb.asm.all [98.0] and > org.apache.felix.ipojo [99.0] via two dependency chains. > Chain 1: > test.service [107.0] > import: > (&(osgi.wiring.package=org.objectweb.asm)(version>=4.0.0)(!(version>=5.0.0))) > | > export: osgi.wiring.package=org.objectweb.asm > org.objectweb.asm.all [98.0] > Chain 2: > test.service [107.0] > import: > (&(osgi.wiring.package=org.apache.felix.ipojo.architecture)(version>=1.8.0)) > | > export: osgi.wiring.package=org.apache.felix.ipojo.architecture; > uses:=org.objectweb.asm > export: osgi.wiring.package=org.objectweb.asm > org.apache.felix.ipojo [99.0] -- 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-3286) Update POM to use the new parent
[ https://issues.apache.org/jira/browse/FELIX-3286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier updated FELIX-3286: - Fix Version/s: (was: ipojo-manipulator-1.8.4) (was: ipojo-core-1.8.2) (was: ipojo-composite-1.8.2) ipojo-manipulator-1.8.6 Affects Version/s: ipojo-manipulator-1.8.4 > Update POM to use the new parent > > > Key: FELIX-3286 > URL: https://issues.apache.org/jira/browse/FELIX-3286 > Project: Felix > Issue Type: Improvement > Components: iPOJO >Affects Versions: ipojo-manipulator-1.8.4 > Reporter: Clement Escoffier > Assignee: Clement Escoffier > Fix For: ipojo-manipulator-1.8.6 > > -- 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-3391) Unexpected warning when using bnd-ipojo-plugin
[ https://issues.apache.org/jira/browse/FELIX-3391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier resolved FELIX-3391. -- Resolution: Fixed Fix Version/s: ipojo-manipulator-1.8.4 Fixed in trunk. Please confirm the fix, then I'll cut a release of the manipulator. > Unexpected warning when using bnd-ipojo-plugin > -- > > Key: FELIX-3391 > URL: https://issues.apache.org/jira/browse/FELIX-3391 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: ipojo-manipulator-1.8.2 >Reporter: Loris Bouzonnet > Assignee: Clement Escoffier >Priority: Minor > Fix For: ipojo-manipulator-1.8.4 > > Attachments: > FELIX--_Duplicate_component_type_warnings_with_ipojo-bnd-plugin.patch > > > When I declare a component with the annotation @Component and I declare the > instance in a metadata.xml file (not the component), I'm getting the > following warning for each compenent type: > [WARNING] Bundle org.jdoe:foo:bundle:2.0.0-SNAPSHOT : The component type > org.jdoe.FooComponent is duplicated. -- 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] [Assigned] (FELIX-3391) Unexpected warning when using bnd-ipojo-plugin
[ https://issues.apache.org/jira/browse/FELIX-3391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier reassigned FELIX-3391: Assignee: Clement Escoffier > Unexpected warning when using bnd-ipojo-plugin > -- > > Key: FELIX-3391 > URL: https://issues.apache.org/jira/browse/FELIX-3391 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: ipojo-manipulator-1.8.2 >Reporter: Loris Bouzonnet > Assignee: Clement Escoffier >Priority: Minor > Attachments: > FELIX--_Duplicate_component_type_warnings_with_ipojo-bnd-plugin.patch > > > When I declare a component with the annotation @Component and I declare the > instance in a metadata.xml file (not the component), I'm getting the > following warning for each compenent type: > [WARNING] Bundle org.jdoe:foo:bundle:2.0.0-SNAPSHOT : The component type > org.jdoe.FooComponent is duplicated. -- 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] [Assigned] (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 reassigned FELIX-3374: Assignee: Clement Escoffier > 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] [Resolved] (FELIX-3389) Bnd iPOJO Plugin ignores annotated components
[
https://issues.apache.org/jira/browse/FELIX-3389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clement Escoffier resolved FELIX-3389.
--
Resolution: Fixed
Fix Version/s: ipojo-manipulator-1.8.4
Assignee: Clement Escoffier
Fixed in trunk (snapshots were also deployed)
> Bnd iPOJO Plugin ignores annotated components
> -
>
> Key: FELIX-3389
> URL: https://issues.apache.org/jira/browse/FELIX-3389
> Project: Felix
> Issue Type: Bug
> Components: iPOJO
>Affects Versions: ipojo-manipulator-1.8.2
>Reporter: Guillaume Sauthier
> Assignee: Clement Escoffier
> Fix For: ipojo-manipulator-1.8.4
>
> Attachments:
> 0001-FELIX-FELIX-3389-Bnd-iPOJO-Plugin-ignores-annotated-.patch
>
>
> The bnd plugin uses the ${classes} Bnd macro to query the system for classes
> annotated with @Component or @Handler.
> The query format in use was "@Component|@Handler" but it was not the expected
> Bnd format.
> An appropriate Bnd annotation query should looks like
> "org.apache.felix.ipojo.annotations.*"
--
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-3384) Ensure maven-ipojo-plugin is thread-safe for parallel maven builds
[ https://issues.apache.org/jira/browse/FELIX-3384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier resolved FELIX-3384. -- Resolution: Fixed Fix Version/s: ipojo-manipulator-1.8.4 Fixed in trunk. After having check all our dependencies, I've marked the plugin as @threadSafe. > Ensure maven-ipojo-plugin is thread-safe for parallel maven builds > -- > > Key: FELIX-3384 > URL: https://issues.apache.org/jira/browse/FELIX-3384 > Project: Felix > Issue Type: Improvement > Components: iPOJO >Affects Versions: ipojo-manipulator-1.8.2 >Reporter: Bob Ziuchkovski > Assignee: Clement Escoffier >Priority: Minor > Fix For: ipojo-manipulator-1.8.4 > > > Maven 3 supports parallel build execution. Given the fact that osgi projects > are generally composed of numerous maven bundle subprojects, it makes sense > to support parallel build execution in maven-ipojo-plugin to accelerate > project compilation. Hence I am humbly requesting this improvement. > Maven plugins that are thread-safe should be marked @threadSafe. See > https://cwiki.apache.org/MAVEN/parallel-builds-in-maven-3.html for details. -- 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] [Issue Comment Edited] (FELIX-3384) Ensure maven-ipojo-plugin is thread-safe for parallel maven builds
[ https://issues.apache.org/jira/browse/FELIX-3384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13227425#comment-13227425 ] Clement Escoffier edited comment on FELIX-3384 at 3/12/12 10:58 AM: Fixed in trunk. After having checked all our dependencies, I've marked the plugin as @threadSafe. was (Author: clement.escoffier): Fixed in trunk. After having check all our dependencies, I've marked the plugin as @threadSafe. > Ensure maven-ipojo-plugin is thread-safe for parallel maven builds > -- > > Key: FELIX-3384 > URL: https://issues.apache.org/jira/browse/FELIX-3384 > Project: Felix > Issue Type: Improvement > Components: iPOJO >Affects Versions: ipojo-manipulator-1.8.2 >Reporter: Bob Ziuchkovski >Assignee: Clement Escoffier >Priority: Minor > Fix For: ipojo-manipulator-1.8.4 > > > Maven 3 supports parallel build execution. Given the fact that osgi projects > are generally composed of numerous maven bundle subprojects, it makes sense > to support parallel build execution in maven-ipojo-plugin to accelerate > project compilation. Hence I am humbly requesting this improvement. > Maven plugins that are thread-safe should be marked @threadSafe. See > https://cwiki.apache.org/MAVEN/parallel-builds-in-maven-3.html for details. -- 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] [Assigned] (FELIX-3384) Ensure maven-ipojo-plugin is thread-safe for parallel maven builds
[ https://issues.apache.org/jira/browse/FELIX-3384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier reassigned FELIX-3384: Assignee: Clement Escoffier > Ensure maven-ipojo-plugin is thread-safe for parallel maven builds > -- > > Key: FELIX-3384 > URL: https://issues.apache.org/jira/browse/FELIX-3384 > Project: Felix > Issue Type: Improvement > Components: iPOJO >Affects Versions: ipojo-manipulator-1.8.2 >Reporter: Bob Ziuchkovski > Assignee: Clement Escoffier >Priority: Minor > > Maven 3 supports parallel build execution. Given the fact that osgi projects > are generally composed of numerous maven bundle subprojects, it makes sense > to support parallel build execution in maven-ipojo-plugin to accelerate > project compilation. Hence I am humbly requesting this improvement. > Maven plugins that are thread-safe should be marked @threadSafe. See > https://cwiki.apache.org/MAVEN/parallel-builds-in-maven-3.html for details. -- 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-3384) Ensure maven-ipojo-plugin is thread-safe for parallel maven builds
[ https://issues.apache.org/jira/browse/FELIX-3384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13227385#comment-13227385 ] Clement Escoffier commented on FELIX-3384: -- Hi, The maven-ipojo-plugin is not marked as thread-safe because it's relying on libraries which are nto thread-safe. However, I just checked the wiki page, and it say that some libraries have fixed those issues, so we need to update the dependencies and redo the checklist. We also need to have a look to the new manipulator. All non-final static members should be _eradicated_. > Ensure maven-ipojo-plugin is thread-safe for parallel maven builds > -- > > Key: FELIX-3384 > URL: https://issues.apache.org/jira/browse/FELIX-3384 > Project: Felix > Issue Type: Improvement > Components: iPOJO >Affects Versions: ipojo-manipulator-1.8.2 >Reporter: Bob Ziuchkovski >Priority: Minor > > Maven 3 supports parallel build execution. Given the fact that osgi projects > are generally composed of numerous maven bundle subprojects, it makes sense > to support parallel build execution in maven-ipojo-plugin to accelerate > project compilation. Hence I am humbly requesting this improvement. > Maven plugins that are thread-safe should be marked @threadSafe. See > https://cwiki.apache.org/MAVEN/parallel-builds-in-maven-3.html for details. -- 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-3380) minor javadoc corrections in @Temporal annotation
[ https://issues.apache.org/jira/browse/FELIX-3380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13226282#comment-13226282 ] Clement Escoffier commented on FELIX-3380: -- Patch applied un trunk. BTW, You don't have to rename files when generating a patch. > 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-core-1.8.2 > > 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] [Updated] (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 updated FELIX-3380: - Affects Version/s: iPOJO-1.8.0 Fix Version/s: ipojo-core-1.8.2 Assignee: Clement Escoffier > 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-core-1.8.2 > > 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] [Commented] (FELIX-3380) minor javadoc corrections in @Temporal annotation
[ https://issues.apache.org/jira/browse/FELIX-3380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13226220#comment-13226220 ] Clement Escoffier commented on FELIX-3380: -- Hi, Your patch looks good. Will apply it right now. > 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 >Priority: Trivial > Labels: javadoc > Fix For: ipojo-core-1.8.2 > > 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
Re: [VOTE] shell 1.4.3 release
+1, Regards, Clement On 07.03.2012, at 17:50, Richard S. Hall wrote: > +1 > > -> richard > > On 3/6/12 10:15 , Karl Pauls wrote: >> I would like to call a vote on the shell 1.4.3 release. >> >> Staging repository: >> https://repository.apache.org/content/repositories/orgapachefelix-056/ >> >> 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 056 /tmp/felix-staging >> >> Please vote to approve this release: >> >> [ ] +1 Approve the release >> [ ] -1 Veto the release (please provide specific comments)
[jira] [Resolved] (FELIX-3359) Turn around to avoid to use the split verifier on Java 7
[ https://issues.apache.org/jira/browse/FELIX-3359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier resolved FELIX-3359. -- Resolution: Fixed Fixed in trunk. > Turn around to avoid to use the split verifier on Java 7 > > > Key: FELIX-3359 > URL: https://issues.apache.org/jira/browse/FELIX-3359 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: ipojo-manipulator-1.8.2 > Reporter: Clement Escoffier > Assignee: Clement Escoffier > Fix For: ipojo-manipulator-1.8.4 > > -- 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-3356) Objectweb ASM Clashes with IPojo
[ https://issues.apache.org/jira/browse/FELIX-3356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier updated FELIX-3356: - Affects Version/s: iPOJO-1.8.0 ipojo-manipulator-1.8.2 Fix Version/s: ipojo-manipulator-1.8.4 ipojo-core-1.8.2 ipojo-composite-1.8.2 > Objectweb ASM Clashes with IPojo > > > Key: FELIX-3356 > URL: https://issues.apache.org/jira/browse/FELIX-3356 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: iPOJO-1.8.0, ipojo-manipulator-1.8.2 >Reporter: Bob Ziuchkovski > Assignee: Clement Escoffier >Priority: Minor > Fix For: ipojo-composite-1.8.2, ipojo-core-1.8.2, > ipojo-manipulator-1.8.4 > > > Ipojo automatically imports org.apache.felix.ipojo.architecture for bundles > that it manages, and org.apache.felix.ipojo.architecture is marked as using > org.objectweb.asm. This creates conflicts for any ipojo-managed bundle that > wishes to import and use a different objectweb asm version (i.e. 4.0) for > non-ipojo purposes. See the below output for an example: > Error executing command: Error starting bundles: > Unable to start bundle 107: Uses constraint violation. Unable to > resolve bundle revision test.service [107.0] because it is exposed to package > 'org.objectweb.asm' from bundle revisions org.objectweb.asm.all [98.0] and > org.apache.felix.ipojo [99.0] via two dependency chains. > Chain 1: > test.service [107.0] > import: > (&(osgi.wiring.package=org.objectweb.asm)(version>=4.0.0)(!(version>=5.0.0))) > | > export: osgi.wiring.package=org.objectweb.asm > org.objectweb.asm.all [98.0] > Chain 2: > test.service [107.0] > import: > (&(osgi.wiring.package=org.apache.felix.ipojo.architecture)(version>=1.8.0)) > | > export: osgi.wiring.package=org.apache.felix.ipojo.architecture; > uses:=org.objectweb.asm > export: osgi.wiring.package=org.objectweb.asm > org.apache.felix.ipojo [99.0] -- 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-3356) Objectweb ASM Clashes with IPojo
[ https://issues.apache.org/jira/browse/FELIX-3356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13212443#comment-13212443 ] Clement Escoffier commented on FELIX-3356: -- iPOJO should keep ASM private. Because ven if we plan to switch to ASM 4.0, it does not fix the issue with bundle requiring ASM 3.0 (APIs absolutely not compatible). So, iPOJO core, composite and online manipulator should not export ASM packages. > Objectweb ASM Clashes with IPojo > > > Key: FELIX-3356 > URL: https://issues.apache.org/jira/browse/FELIX-3356 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: iPOJO-1.8.0, ipojo-manipulator-1.8.2 >Reporter: Bob Ziuchkovski > Assignee: Clement Escoffier >Priority: Minor > Fix For: ipojo-composite-1.8.2, ipojo-core-1.8.2, > ipojo-manipulator-1.8.4 > > > Ipojo automatically imports org.apache.felix.ipojo.architecture for bundles > that it manages, and org.apache.felix.ipojo.architecture is marked as using > org.objectweb.asm. This creates conflicts for any ipojo-managed bundle that > wishes to import and use a different objectweb asm version (i.e. 4.0) for > non-ipojo purposes. See the below output for an example: > Error executing command: Error starting bundles: > Unable to start bundle 107: Uses constraint violation. Unable to > resolve bundle revision test.service [107.0] because it is exposed to package > 'org.objectweb.asm' from bundle revisions org.objectweb.asm.all [98.0] and > org.apache.felix.ipojo [99.0] via two dependency chains. > Chain 1: > test.service [107.0] > import: > (&(osgi.wiring.package=org.objectweb.asm)(version>=4.0.0)(!(version>=5.0.0))) > | > export: osgi.wiring.package=org.objectweb.asm > org.objectweb.asm.all [98.0] > Chain 2: > test.service [107.0] > import: > (&(osgi.wiring.package=org.apache.felix.ipojo.architecture)(version>=1.8.0)) > | > export: osgi.wiring.package=org.apache.felix.ipojo.architecture; > uses:=org.objectweb.asm > export: osgi.wiring.package=org.objectweb.asm > org.apache.felix.ipojo [99.0] -- 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] [Assigned] (FELIX-3356) Objectweb ASM Clashes with IPojo
[ https://issues.apache.org/jira/browse/FELIX-3356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier reassigned FELIX-3356: Assignee: Clement Escoffier > Objectweb ASM Clashes with IPojo > > > Key: FELIX-3356 > URL: https://issues.apache.org/jira/browse/FELIX-3356 > Project: Felix > Issue Type: Bug > Components: iPOJO >Reporter: Bob Ziuchkovski > Assignee: Clement Escoffier >Priority: Minor > > Ipojo automatically imports org.apache.felix.ipojo.architecture for bundles > that it manages, and org.apache.felix.ipojo.architecture is marked as using > org.objectweb.asm. This creates conflicts for any ipojo-managed bundle that > wishes to import and use a different objectweb asm version (i.e. 4.0) for > non-ipojo purposes. See the below output for an example: > Error executing command: Error starting bundles: > Unable to start bundle 107: Uses constraint violation. Unable to > resolve bundle revision test.service [107.0] because it is exposed to package > 'org.objectweb.asm' from bundle revisions org.objectweb.asm.all [98.0] and > org.apache.felix.ipojo [99.0] via two dependency chains. > Chain 1: > test.service [107.0] > import: > (&(osgi.wiring.package=org.objectweb.asm)(version>=4.0.0)(!(version>=5.0.0))) > | > export: osgi.wiring.package=org.objectweb.asm > org.objectweb.asm.all [98.0] > Chain 2: > test.service [107.0] > import: > (&(osgi.wiring.package=org.apache.felix.ipojo.architecture)(version>=1.8.0)) > | > export: osgi.wiring.package=org.apache.felix.ipojo.architecture; > uses:=org.objectweb.asm > export: osgi.wiring.package=org.objectweb.asm > org.apache.felix.ipojo [99.0] -- 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-3359) Turn around to avoid to use the split verifier on Java 7
Turn around to avoid to use the split verifier on Java 7 Key: FELIX-3359 URL: https://issues.apache.org/jira/browse/FELIX-3359 Project: Felix Issue Type: Bug Components: iPOJO Affects Versions: ipojo-manipulator-1.8.2 Reporter: Clement Escoffier Assignee: Clement Escoffier Fix For: ipojo-manipulator-1.8.4 -- 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-3297) iPOJO Manipulator throws ClassNotFoundException
[ https://issues.apache.org/jira/browse/FELIX-3297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13204669#comment-13204669 ] Clement Escoffier commented on FELIX-3297: -- Runtime. It instructs the JVM to not check the frames. > iPOJO Manipulator throws ClassNotFoundException > --- > > Key: FELIX-3297 > URL: https://issues.apache.org/jira/browse/FELIX-3297 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: ipojo-manipulator-1.8.2 > Reporter: Clement Escoffier > Assignee: Clement Escoffier >Priority: Critical > Fix For: ipojo-manipulator-1.8.4 > > > The new iPOJO manipulator (1.8.2) asks ASM to compute the bytecode frames. > However, this may require ASM to load classes (dependencies of the > manipulated class). If this classloading fails, the maniulatoion is aborted > with a: > java.lang.RuntimeException: java.lang.ClassNotFoundException: _THE_CLASS_ -- 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-3323) Ipojo composite throw ClassCastException when configuration is updated thru ConfigAdmin
[ https://issues.apache.org/jira/browse/FELIX-3323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier resolved FELIX-3323. -- Resolution: Fixed Fix Version/s: ipojo-core-1.8.2 ipojo-composite-1.8.2 Assignee: Clement Escoffier > Ipojo composite throw ClassCastException when configuration is updated thru > ConfigAdmin > --- > > Key: FELIX-3323 > URL: https://issues.apache.org/jira/browse/FELIX-3323 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: iPOJO-1.8.0 > Environment: Windows 7 - Felix 4.0.2 - Java 1.6.0_26 >Reporter: David GAY >Assignee: Clement Escoffier > Labels: composite, configurationadmin, ipojo > Fix For: ipojo-composite-1.8.2, ipojo-core-1.8.2 > > > 1- Declare an iPojo composite > 2- Create a configuration in ConfigAdmin for the composite > 3- Update the configuration in ConfigAdmin > A ClassCastException is raised when the configuration is updated, for example > : > *ERROR* [org.apache.felix.ipojo.Factory, > org.osgi.service.cm.ManagedServiceFactory, id=38, bundle=14]: Unexpected > problem updating Configuration > PID=foo.compo.26ec176f-6860-4100-a538-b5fb523d4a1f, fac > toryPID=foo.compo, > bundleLocation=file:../foo-composite/target/foo-composite-1.0.0-SNAPSHOT.jar > java.lang.ClassCastException: > org.apache.felix.ipojo.composite.CompositeManager cannot be cast to > org.apache.felix.ipojo.InstanceManager > at org.apache.felix.ipojo.IPojoFactory.updated(IPojoFactory.java:627) > at > org.apache.felix.cm.impl.ConfigurationManager$UpdateConfiguration.run(ConfigurationManager.java:1567) > at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:104) > at java.lang.Thread.run(Unknown Source) > A complete test project is available to reproduce the problem in this message > : http://old.nabble.com/iPojo-Composite-to33188907.html -- 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-3323) Ipojo composite throw ClassCastException when configuration is updated thru ConfigAdmin
[ https://issues.apache.org/jira/browse/FELIX-3323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13204640#comment-13204640 ] Clement Escoffier commented on FELIX-3323: -- Ohoh ! Stupid and simple bug, an unexpected and useless cast... I got your example running and working. Thanks ! > Ipojo composite throw ClassCastException when configuration is updated thru > ConfigAdmin > --- > > Key: FELIX-3323 > URL: https://issues.apache.org/jira/browse/FELIX-3323 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: iPOJO-1.8.0 > Environment: Windows 7 - Felix 4.0.2 - Java 1.6.0_26 >Reporter: David GAY > Labels: composite, configurationadmin, ipojo > > 1- Declare an iPojo composite > 2- Create a configuration in ConfigAdmin for the composite > 3- Update the configuration in ConfigAdmin > A ClassCastException is raised when the configuration is updated, for example > : > *ERROR* [org.apache.felix.ipojo.Factory, > org.osgi.service.cm.ManagedServiceFactory, id=38, bundle=14]: Unexpected > problem updating Configuration > PID=foo.compo.26ec176f-6860-4100-a538-b5fb523d4a1f, fac > toryPID=foo.compo, > bundleLocation=file:../foo-composite/target/foo-composite-1.0.0-SNAPSHOT.jar > java.lang.ClassCastException: > org.apache.felix.ipojo.composite.CompositeManager cannot be cast to > org.apache.felix.ipojo.InstanceManager > at org.apache.felix.ipojo.IPojoFactory.updated(IPojoFactory.java:627) > at > org.apache.felix.cm.impl.ConfigurationManager$UpdateConfiguration.run(ConfigurationManager.java:1567) > at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:104) > at java.lang.Thread.run(Unknown Source) > A complete test project is available to reproduce the problem in this message > : http://old.nabble.com/iPojo-Composite-to33188907.html -- 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-3297) iPOJO Manipulator throws ClassNotFoundException
[ https://issues.apache.org/jira/browse/FELIX-3297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier resolved FELIX-3297. -- Resolution: Fixed I've rolled back the Java 7 Frame support for now, as it sounds a lot more complex than expected. So, without this, we turn around this issue. On Java 7, you needs to use the -XX:-UseSplitVerifier JVM option > iPOJO Manipulator throws ClassNotFoundException > --- > > Key: FELIX-3297 > URL: https://issues.apache.org/jira/browse/FELIX-3297 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: ipojo-manipulator-1.8.2 >Reporter: Clement Escoffier > Assignee: Clement Escoffier >Priority: Critical > Fix For: ipojo-manipulator-1.8.4 > > > The new iPOJO manipulator (1.8.2) asks ASM to compute the bytecode frames. > However, this may require ASM to load classes (dependencies of the > manipulated class). If this classloading fails, the maniulatoion is aborted > with a: > java.lang.RuntimeException: java.lang.ClassNotFoundException: _THE_CLASS_ -- 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-3326) Accessing IPojo-Component's all inherited classes and all implemented interfaces in PrimitiveTypeDescription
[ https://issues.apache.org/jira/browse/FELIX-3326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13204633#comment-13204633 ] Clement Escoffier commented on FELIX-3326: -- Hi, I've applied the patch in the trunk (just check that we actually are on a primitive component). Thanks, > Accessing IPojo-Component's all inherited classes and all implemented > interfaces in PrimitiveTypeDescription > > > Key: FELIX-3326 > URL: https://issues.apache.org/jira/browse/FELIX-3326 > Project: Felix > Issue Type: Improvement > Components: iPOJO >Reporter: Göktürk Gezer >Assignee: Clement Escoffier > Fix For: ipojo-core-1.8.2 > > Attachments: ComponentFactory.java.patch > > > Ability to retrieve component's inherited classes and implemented interfaces > through PrimitiveTypeDescription for components those are not used > ProvidedService Handler. -- 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-3326) Accessing IPojo-Component's all inherited classes and all implemented interfaces in PrimitiveTypeDescription
[ https://issues.apache.org/jira/browse/FELIX-3326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier resolved FELIX-3326. -- Resolution: Fixed Fix Version/s: ipojo-core-1.8.2 > Accessing IPojo-Component's all inherited classes and all implemented > interfaces in PrimitiveTypeDescription > > > Key: FELIX-3326 > URL: https://issues.apache.org/jira/browse/FELIX-3326 > Project: Felix > Issue Type: Improvement > Components: iPOJO >Reporter: Göktürk Gezer > Assignee: Clement Escoffier > Fix For: ipojo-core-1.8.2 > > Attachments: ComponentFactory.java.patch > > > Ability to retrieve component's inherited classes and implemented interfaces > through PrimitiveTypeDescription for components those are not used > ProvidedService Handler. -- 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] [Work started] (FELIX-3326) Accessing IPojo-Component's all inherited classes and all implemented interfaces in PrimitiveTypeDescription
[ https://issues.apache.org/jira/browse/FELIX-3326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on FELIX-3326 started by Clement Escoffier. > Accessing IPojo-Component's all inherited classes and all implemented > interfaces in PrimitiveTypeDescription > > > Key: FELIX-3326 > URL: https://issues.apache.org/jira/browse/FELIX-3326 > Project: Felix > Issue Type: Improvement > Components: iPOJO >Reporter: Göktürk Gezer > Assignee: Clement Escoffier > Attachments: ComponentFactory.java.patch > > > Ability to retrieve component's inherited classes and implemented interfaces > through PrimitiveTypeDescription for components those are not used > ProvidedService Handler. -- 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] [Work started] (FELIX-3297) iPOJO Manipulator throws ClassNotFoundException
[ https://issues.apache.org/jira/browse/FELIX-3297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on FELIX-3297 started by Clement Escoffier. > iPOJO Manipulator throws ClassNotFoundException > --- > > Key: FELIX-3297 > URL: https://issues.apache.org/jira/browse/FELIX-3297 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: ipojo-manipulator-1.8.2 > Reporter: Clement Escoffier > Assignee: Clement Escoffier >Priority: Critical > Fix For: ipojo-manipulator-1.8.4 > > > The new iPOJO manipulator (1.8.2) asks ASM to compute the bytecode frames. > However, this may require ASM to load classes (dependencies of the > manipulated class). If this classloading fails, the maniulatoion is aborted > with a: > java.lang.RuntimeException: java.lang.ClassNotFoundException: _THE_CLASS_ -- 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] [Assigned] (FELIX-3326) Accessing IPojo-Component's all inherited classes and all implemented interfaces in PrimitiveTypeDescription
[ https://issues.apache.org/jira/browse/FELIX-3326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier reassigned FELIX-3326: Assignee: Clement Escoffier > Accessing IPojo-Component's all inherited classes and all implemented > interfaces in PrimitiveTypeDescription > > > Key: FELIX-3326 > URL: https://issues.apache.org/jira/browse/FELIX-3326 > Project: Felix > Issue Type: Improvement > Components: iPOJO >Reporter: Göktürk Gezer > Assignee: Clement Escoffier > Attachments: ComponentFactory.java.patch > > > Ability to retrieve component's inherited classes and implemented interfaces > through PrimitiveTypeDescription for components those are not used > ProvidedService Handler. -- 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-3297) iPOJO Manipulator throws ClassNotFoundException
iPOJO Manipulator throws ClassNotFoundException --- Key: FELIX-3297 URL: https://issues.apache.org/jira/browse/FELIX-3297 Project: Felix Issue Type: Bug Components: iPOJO Affects Versions: ipojo-manipulator-1.8.2 Reporter: Clement Escoffier Assignee: Clement Escoffier Priority: Critical Fix For: ipojo-manipulator-1.8.4 The new iPOJO manipulator (1.8.2) asks ASM to compute the bytecode frames. However, this may require ASM to load classes (dependencies of the manipulated class). If this classloading fails, the maniulatoion is aborted with a: java.lang.RuntimeException: java.lang.ClassNotFoundException: _THE_CLASS_ -- 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-3286) Update POM to use the new parent
Update POM to use the new parent Key: FELIX-3286 URL: https://issues.apache.org/jira/browse/FELIX-3286 Project: Felix Issue Type: Improvement Components: iPOJO Reporter: Clement Escoffier Assignee: Clement Escoffier Fix For: ipojo-composite-1.8.2, ipojo-core-1.8.2, ipojo-manipulator-1.8.4 -- 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
[RESULT][VOTE] Release Felix iPOJO Manipulator version 1.8.2
Hi, It's time to close the vote. The vote is successful. I will upload the artifacts ASAP. Thanks and regards, Clement On 06.12.2011, at 18:52, Clement Escoffier wrote: > Hi, > > It's time to cut a release of the iPOJO Manipulator project (1.8.2). > > The release is a bit different this time, has I've released a couple of > artifacts in once (we have aggregated all manipulator front-end in one Maven > reactor), so this releases contains: > * org.apache.felix.ipojo.metadata 1.6.0 > * org.apache.felix.ipojo.manipulator 1.8.2 > * maven-ipojo-plugin 1.8.2 > * ipojo-ant-task 1.8.2 > * bnd-ipojo-plugin 1.8.2 (new module) > * manipulator-project (1.8.2) > > (the changelog is included below) > > Staging repository: > https://repository.apache.org/content/repositories/orgapachefelix-294/ > > 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 294 /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: > ** Bug > * [FELIX-2825] - The maven-ipojo-plugin does not replace component > classes in WAR files > * [FELIX-2829] - The maven-ipojo-plugin archetype descriptor is not > conform > * [FELIX-2833] - The maven-ipojo-plugin does not support manipulating > artifact with a classifier > * [FELIX-3012] - "Duplicate name&signature" problem > * [FELIX-3098] - iPOJO new manipulator crashes when using a custom > reporter > * [FELIX-3145] - VerifyError on Java 7 > * [FELIX-3249] - iPOJO Bnd Plugin do not write all the metadatas in the > manifest > > ** Improvement > * [FELIX-3017] - The manipulator should return the original class if it's > already manipulated > * [FELIX-3078] - Introduce resource abstraction in the iPOJO manipulator > * [FELIX-3079] - Adapt the Ant task and the maven plugin to use the new > manipulator capabilities > * [FELIX-3080] - Implement a BND plugin for iPOJO > * [FELIX-3131] - Elements and attributes should conserve the insertion > order > * [FELIX-3204] - @Temporal should handle instantiation-time properties > * [FELIX-3244] - Manipulator : DefaultManifestBuilder should be more > extensible
Re: [VOTE] Release Felix iPOJO Manipulator version 1.8.2
+1, Regards, Clement On 06.12.2011, at 18:52, Clement Escoffier wrote: > Hi, > > It's time to cut a release of the iPOJO Manipulator project (1.8.2). > > The release is a bit different this time, has I've released a couple of > artifacts in once (we have aggregated all manipulator front-end in one Maven > reactor), so this releases contains: > * org.apache.felix.ipojo.metadata 1.6.0 > * org.apache.felix.ipojo.manipulator 1.8.2 > * maven-ipojo-plugin 1.8.2 > * ipojo-ant-task 1.8.2 > * bnd-ipojo-plugin 1.8.2 (new module) > * manipulator-project (1.8.2) > > (the changelog is included below) > > Staging repository: > https://repository.apache.org/content/repositories/orgapachefelix-294/ > > 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 294 /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: > ** Bug > * [FELIX-2825] - The maven-ipojo-plugin does not replace component > classes in WAR files > * [FELIX-2829] - The maven-ipojo-plugin archetype descriptor is not > conform > * [FELIX-2833] - The maven-ipojo-plugin does not support manipulating > artifact with a classifier > * [FELIX-3012] - "Duplicate name&signature" problem > * [FELIX-3098] - iPOJO new manipulator crashes when using a custom > reporter > * [FELIX-3145] - VerifyError on Java 7 > * [FELIX-3249] - iPOJO Bnd Plugin do not write all the metadatas in the > manifest > > ** Improvement > * [FELIX-3017] - The manipulator should return the original class if it's > already manipulated > * [FELIX-3078] - Introduce resource abstraction in the iPOJO manipulator > * [FELIX-3079] - Adapt the Ant task and the maven plugin to use the new > manipulator capabilities > * [FELIX-3080] - Implement a BND plugin for iPOJO > * [FELIX-3131] - Elements and attributes should conserve the insertion > order > * [FELIX-3204] - @Temporal should handle instantiation-time properties > * [FELIX-3244] - Manipulator : DefaultManifestBuilder should be more > extensible
[jira] [Resolved] (FELIX-3271) On KF, the Instance singleton strategy throws an UnsupportedOperationException when stopping
[ https://issues.apache.org/jira/browse/FELIX-3271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier resolved FELIX-3271. -- Resolution: Fixed Assignee: Clement Escoffier Fixed in trunk. > On KF, the Instance singleton strategy throws an > UnsupportedOperationException when stopping > > > Key: FELIX-3271 > URL: https://issues.apache.org/jira/browse/FELIX-3271 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: iPOJO-1.8.0 > Reporter: Clement Escoffier > Assignee: Clement Escoffier > Fix For: ipojo-core-1.8.2 > > > When we stop a bundle including an instance providing a service using the > INSTANCE creation strategy, KF is calling hashCode on the registered proxy. > This method is not supported and so we get an UnsupportedOperationException. -- 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-3271) On KF, the Instance singleton strategy throws an UnsupportedOperationException when stopping
On KF, the Instance singleton strategy throws an UnsupportedOperationException when stopping Key: FELIX-3271 URL: https://issues.apache.org/jira/browse/FELIX-3271 Project: Felix Issue Type: Bug Components: iPOJO Affects Versions: iPOJO-1.8.0 Reporter: Clement Escoffier Fix For: ipojo-core-1.8.2 When we stop a bundle including an instance providing a service using the INSTANCE creation strategy, KF is calling hashCode on the registered proxy. This method is not supported and so we get an UnsupportedOperationException. -- 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-3204) @Temporal should handle instantiation-time properties
[ https://issues.apache.org/jira/browse/FELIX-3204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13169177#comment-13169177 ] Clement Escoffier commented on FELIX-3204: -- I've applied the patch. Thanks ! > @Temporal should handle instantiation-time properties > - > > Key: FELIX-3204 > URL: https://issues.apache.org/jira/browse/FELIX-3204 > Project: Felix > Issue Type: Improvement > Components: iPOJO >Reporter: Thomas Calmant >Assignee: Clement Escoffier > Fix For: ipojo-manipulator-1.8.2, > ipojo-temporal-dependency-handler-1.8.0 > > Attachments: field-filters.patch, temporal_annotation.patch > > > The temporal handler (@Temporal) should act like the dependency handler > (@Requires), by handling "requires.filters" and "requires.from" entries in a > component instance configuration. -- 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: [VOTE] Release Felix iPOJO Manipulator version 1.8.2
Hi, Even if it's a regression, it's not critical as it happens on pretty rare case (I wasn't able to reproduce it with our applications). So, the bug will be fixed in the next version (when we find a way to fix it for all front-ends). So, the vote goes forward. Regards, Clement On 08.12.2011, at 04:38, Richard S. Hall wrote: > On 12/7/11 11:56, Guillaume Sauthier (Objectweb) wrote: >> I tried both the new maven-ipojo-plugin and the bnd-ipojo-plugin >> And I see regressions during JOnAS maven build ... :'( >> >> We've started to look at the problem with Clement, but it doesn't look so >> simple to solve. >> >> I don't know if this should be considered as a blocker for this release or >> if the resolution can wait for a minor bug fix release ... > > There really are no release blockers for bugs, it's just up to Clement to > decide if he wants the release to go forward or not. > > -> richard > >> >> --G >> >> 2011/12/6 Clement Escoffier >> >>> Hi, >>> >>> It's time to cut a release of the iPOJO Manipulator project (1.8.2). >>> >>> The release is a bit different this time, has I've released a couple of >>> artifacts in once (we have aggregated all manipulator front-end in one >>> Maven reactor), so this releases contains: >>> * org.apache.felix.ipojo.metadata 1.6.0 >>> * org.apache.felix.ipojo.manipulator 1.8.2 >>> * maven-ipojo-plugin 1.8.2 >>> * ipojo-ant-task 1.8.2 >>> * bnd-ipojo-plugin 1.8.2 (new module) >>> * manipulator-project (1.8.2) >>> >>> (the changelog is included below) >>> >>> Staging repository: >>> https://repository.apache.org/content/repositories/orgapachefelix-294/ >>> >>> 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 294 /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: >>> ** Bug >>>* [FELIX-2825] - The maven-ipojo-plugin does not replace component >>> classes in WAR files >>>* [FELIX-2829] - The maven-ipojo-plugin archetype descriptor is not >>> conform >>>* [FELIX-2833] - The maven-ipojo-plugin does not support manipulating >>> artifact with a classifier >>>* [FELIX-3012] - "Duplicate name&signature" problem >>>* [FELIX-3098] - iPOJO new manipulator crashes when using a custom >>> reporter >>>* [FELIX-3145] - VerifyError on Java 7 >>>* [FELIX-3249] - iPOJO Bnd Plugin do not write all the metadatas in the >>> manifest >>> >>> ** Improvement >>>* [FELIX-3017] - The manipulator should return the original class if >>> it's already manipulated >>>* [FELIX-3078] - Introduce resource abstraction in the iPOJO manipulator >>>* [FELIX-3079] - Adapt the Ant task and the maven plugin to use the new >>> manipulator capabilities >>>* [FELIX-3080] - Implement a BND plugin for iPOJO >>>* [FELIX-3131] - Elements and attributes should conserve the insertion >>> order >>>* [FELIX-3204] - @Temporal should handle instantiation-time properties >>>* [FELIX-3244] - Manipulator : DefaultManifestBuilder should be more >>> extensible
[VOTE] Release Felix iPOJO Manipulator version 1.8.2
Hi, It's time to cut a release of the iPOJO Manipulator project (1.8.2). The release is a bit different this time, has I've released a couple of artifacts in once (we have aggregated all manipulator front-end in one Maven reactor), so this releases contains: * org.apache.felix.ipojo.metadata 1.6.0 * org.apache.felix.ipojo.manipulator 1.8.2 * maven-ipojo-plugin 1.8.2 * ipojo-ant-task 1.8.2 * bnd-ipojo-plugin 1.8.2 (new module) * manipulator-project (1.8.2) (the changelog is included below) Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-294/ 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 294 /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: ** Bug * [FELIX-2825] - The maven-ipojo-plugin does not replace component classes in WAR files * [FELIX-2829] - The maven-ipojo-plugin archetype descriptor is not conform * [FELIX-2833] - The maven-ipojo-plugin does not support manipulating artifact with a classifier * [FELIX-3012] - "Duplicate name&signature" problem * [FELIX-3098] - iPOJO new manipulator crashes when using a custom reporter * [FELIX-3145] - VerifyError on Java 7 * [FELIX-3249] - iPOJO Bnd Plugin do not write all the metadatas in the manifest ** Improvement * [FELIX-3017] - The manipulator should return the original class if it's already manipulated * [FELIX-3078] - Introduce resource abstraction in the iPOJO manipulator * [FELIX-3079] - Adapt the Ant task and the maven plugin to use the new manipulator capabilities * [FELIX-3080] - Implement a BND plugin for iPOJO * [FELIX-3131] - Elements and attributes should conserve the insertion order * [FELIX-3204] - @Temporal should handle instantiation-time properties * [FELIX-3244] - Manipulator : DefaultManifestBuilder should be more extensible
[jira] [Resolved] (FELIX-3252) Merge the online manipulator into iPOJO Core
[ https://issues.apache.org/jira/browse/FELIX-3252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier resolved FELIX-3252. -- Resolution: Fixed Fixed in trunk > Merge the online manipulator into iPOJO Core > > > Key: FELIX-3252 > URL: https://issues.apache.org/jira/browse/FELIX-3252 > Project: Felix > Issue Type: Improvement > Components: iPOJO > Reporter: Clement Escoffier > Assignee: Clement Escoffier > Fix For: ipojo-core-1.8.2 > > > The online-manipulator is separated bundle. It should be embedded into the > iPOJO Core 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
[jira] [Created] (FELIX-3252) Merge the online manipulator into iPOJO Core
Merge the online manipulator into iPOJO Core Key: FELIX-3252 URL: https://issues.apache.org/jira/browse/FELIX-3252 Project: Felix Issue Type: Improvement Components: iPOJO Reporter: Clement Escoffier Assignee: Clement Escoffier Fix For: ipojo-core-1.8.2 The online-manipulator is separated bundle. It should be embedded into the iPOJO Core 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
[jira] [Resolved] (FELIX-3080) Implement a BND plugin for iPOJO
[ https://issues.apache.org/jira/browse/FELIX-3080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier resolved FELIX-3080. -- Resolution: Fixed We now have a working iPOJO plugin for BND. Thanks to Guillaume Sauthier for this great work. > Implement a BND plugin for iPOJO > > > Key: FELIX-3080 > URL: https://issues.apache.org/jira/browse/FELIX-3080 > Project: Felix > Issue Type: Improvement > Components: iPOJO > Reporter: Clement Escoffier > Assignee: Clement Escoffier > Fix For: ipojo-manipulator-1.8.2 > > > The new iPOJO manipulator would be easily embeddable inside a BND plugin. -- 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-3244) Manipulator : DefaultManifestBuilder should be more extensible
[ https://issues.apache.org/jira/browse/FELIX-3244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier resolved FELIX-3244. -- Resolution: Fixed Fix Version/s: ipojo-manipulator-1.8.2 Assignee: Clement Escoffier I've applied the patch. Thanks ! > Manipulator : DefaultManifestBuilder should be more extensible > -- > > Key: FELIX-3244 > URL: https://issues.apache.org/jira/browse/FELIX-3244 > Project: Felix > Issue Type: Improvement > Components: iPOJO >Affects Versions: ipojo-manipulator-1.8.2 >Reporter: Thomas Calmant > Assignee: Clement Escoffier > Fix For: ipojo-manipulator-1.8.2 > > Attachments: patch > > > To always return the same manifest content, the iPOJO plug-in for Eclipse > needs to modify the Manifest object as soon as possible. > The best moment to do it seems to be when parseHeader is called, so it may be > overridable. -- 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-3249) iPOJO Bnd Plugin do not write all the metadatas in the manifest
[
https://issues.apache.org/jira/browse/FELIX-3249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clement Escoffier resolved FELIX-3249.
--
Resolution: Fixed
Fix Version/s: ipojo-manipulator-1.8.2
Assignee: Clement Escoffier
Fixed in trunk.
I've applied the patch.
Thanks !
> iPOJO Bnd Plugin do not write all the metadatas in the manifest
> ---
>
> Key: FELIX-3249
> URL: https://issues.apache.org/jira/browse/FELIX-3249
> Project: Felix
> Issue Type: Bug
> Components: iPOJO
>Reporter: Guillaume Sauthier
>Assignee: Clement Escoffier
> Fix For: ipojo-manipulator-1.8.2
>
> Attachments: FELIX-3249.patch
>
>
> The iPOJO Bnd Plugin do not write all the metadatas in the manifest.
> For example, the following XML content, will only produce a IPOJO-Components
> manifest header with the last .
> {code:xml}
>
>
>
>
>
> {code}
--
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-3145) VerifyError on Java 7
[ https://issues.apache.org/jira/browse/FELIX-3145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13160132#comment-13160132 ] Clement Escoffier commented on FELIX-3145: -- Which version of ASM are you using ? To fix this issue, I've also bump the ASM version. > VerifyError on Java 7 > - > > Key: FELIX-3145 > URL: https://issues.apache.org/jira/browse/FELIX-3145 > Project: Felix > Issue Type: Bug > Components: iPOJO > Environment: java 1.7.0 > ant 1.8.2 > felix 3.2.2 > ipojo 1.6.0 1.6.2 1.8.0 > bnd-task : bnd-0.0.401.jar > Ubuntu Linux > Reporter: Clement Escoffier >Assignee: Clement Escoffier > Fix For: ipojo-manipulator-1.8.2 > > > The manipulator must use a more recent version of ASM to avoid the following > issue: > java.lang.VerifyError: Expecting a stackmap frame at branch target 5 in > method > acme.world.EmptyHelloNonImmediate._setInstanceManager(Lorg/apache/felix/ipojo/InstanceManager;)V > at offset 1 -- 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-3204) @Temporal should handle instantiation-time properties
[ https://issues.apache.org/jira/browse/FELIX-3204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier resolved FELIX-3204. -- Resolution: Fixed Fix Version/s: ipojo-temporal-dependency-handler-1.8.0 ipojo-manipulator-1.8.2 Fixed in trunk * Added the support of temporal.from, temporal.filters (with fallback to requires.from and requires.filters) to the temporal dependency handler * Added an id attribute * Updated the XSD file Artifacts will be soon available from apache.snapshots. > @Temporal should handle instantiation-time properties > - > > Key: FELIX-3204 > URL: https://issues.apache.org/jira/browse/FELIX-3204 > Project: Felix > Issue Type: Improvement > Components: iPOJO >Reporter: Thomas Calmant > Assignee: Clement Escoffier > Fix For: ipojo-manipulator-1.8.2, > ipojo-temporal-dependency-handler-1.8.0 > > Attachments: field-filters.patch > > > The temporal handler (@Temporal) should act like the dependency handler > (@Requires), by handling "requires.filters" and "requires.from" entries in a > component instance configuration. -- 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] [Assigned] (FELIX-3204) @Temporal should handle instantiation-time properties
[ https://issues.apache.org/jira/browse/FELIX-3204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier reassigned FELIX-3204: Assignee: Clement Escoffier > @Temporal should handle instantiation-time properties > - > > Key: FELIX-3204 > URL: https://issues.apache.org/jira/browse/FELIX-3204 > Project: Felix > Issue Type: Improvement > Components: iPOJO >Reporter: Thomas Calmant > Assignee: Clement Escoffier > Attachments: field-filters.patch > > > The temporal handler (@Temporal) should act like the dependency handler > (@Requires), by handling "requires.filters" and "requires.from" entries in a > component instance configuration. -- 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-2996) iPOJO doesn't generate Import-Package correctly
[
https://issues.apache.org/jira/browse/FELIX-2996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clement Escoffier resolved FELIX-2996.
--
Resolution: Won't Fix
Assignee: Clement Escoffier
The manipulator was reimplemented in the mean time, and the way we're computing
imported packages has changed. Please check if the issue is still valid.
> iPOJO doesn't generate Import-Package correctly
> ---
>
> Key: FELIX-2996
> URL: https://issues.apache.org/jira/browse/FELIX-2996
> Project: Felix
> Issue Type: Bug
> Components: iPOJO
>Affects Versions: iPOJO-1.6.0
>Reporter: Rémy Masson
>Assignee: Clement Escoffier
> Labels: import, manifest, package
>
> We're having troubles with generating a manifest using BND and iPOJO. The
> problem resides in iPOJO not adding referred packages (from @Provides
> annotations in components in our case) to the imported packages of the
> manifest.
> I noticed the iPOJO task is supposed to be adding them, and by checking the
> code implementation, I found the issue in the Pojoization class which is
> called during manipulation. When fetching referred packages, it looks for the
> "specification" attribute instead of looking for the "specifications"
> attribute, which results in failing to find any referred package.
> However fixing that doesn't completely solve our problem. We encountered
> another issue (after fixing the issue locally in Pojoization.java): imports
> are added naked, and it doesn't seem possible to add attribute such as the
> "version=x.x.x" which we need.
> BND however implements such a mechanism - when told to process a given
> bundle, it will take a .bnd file. The .bnd file may then contain attributes,
> such as "im.an.example.*;version=6.6.6". It will, for packages which fit the
> wildcard, use the provided version for added package imports. Could that be
> implemented in some sort of way in iPOJO?
> I looked into why BND wasn't adding the package of the @Provided interfaces
> to the imported packages: the issue lies into the @Provide annotation having
> a CLASS retention policy. BND will only consider RUNTIME retained
> annotations, which kind of makes sense to me. Could it be possible to have
> that annotation retained at runtime?
> The annotation solution definitely looks simpler to do than implementing an
> attribute mechanism. It implies that tools such as BND will be able to tell
> which packages are needed at runtime. However, the existing implementation
> ("specification" instead of "specifications" and import overwriting) would
> still need fixing.
> For reference, here are the code excerpts showing the introduced existing
> problems:
> ## Pojoization.getReferredPackages()
> [..]
> String att = elems[j].getAttribute("specification");
> [..]
> ## I also noticed another issue with the Pojoization.setImports(Attribute)
> method, which overrides any existing package import with a blank one:
> // Add referred imports from the metadata
> for (int i = 0; i < m_referredPackages.size(); i++) {
> String pack = (String) m_referredPackages.get(i);
> imports.put(pack, new TreeMap());
> }
> ... meaning any previously existing import with specific pieces of
> information such as the package version will get deleted.
--
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-3030) Bind/Unbind and lifecycle
[
https://issues.apache.org/jira/browse/FELIX-3030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clement Escoffier resolved FELIX-3030.
--
Resolution: Won't Fix
Assignee: Clement Escoffier
> Bind/Unbind and lifecycle
> -
>
> Key: FELIX-3030
> URL: https://issues.apache.org/jira/browse/FELIX-3030
> Project: Felix
> Issue Type: Bug
> Components: iPOJO
>Affects Versions: iPOJO-1.8.0
>Reporter: Yann Diorcet
> Assignee: Clement Escoffier
>
> According to my
> post(http://old.nabble.com/iPojo-lifecycle-and-dependencies-p32003301.html).
> It seems that there is a problem with the lifecycle and dependencies.
> @Component
> @Instantiate
> public final class Abcd {
> @Requires
> private Efg efg;
> @Validate
> private void start() {
> }
> @Invalidate
> private void stop() {
> }
> @Bind(aggregate = true, optional = true)
> private void bindXyz(final Xyz service) {
> }
> @Unbind
> private void unbindXyz(final Xyz service) {
> }
> }
> Scenario 1:
> -A new service(Efg1) provides Efg
> -A new service(Xyz1) provides Xyz
> -The component Abcd is instantiated
> -The bind() is called with Xyz1
> -The start() of the component is called
> -The Efg1 is unregistered
> -The component is invalidated (Efg1 is gone) stop() is called
> -During the time that my component is invalidated, if a new Xyz service(Xyz2)
> is registred (from an another bundle for example) bindXyz() is called
> -After that, if i stop my bundle, my component will be stopped but
> unbindXyz() will be not called(neither for Xyz1 nor Xyz2).
> Scenario 2:
> -A new service(Efg1) provides Efg
> -A new service(Xyz1) provides Xyz
> -The component Abcd is instantiated
> -The bind() is called with Xyz1
> -The start() of the component is called
> -The Efg1 is unregistered
> -The component is invalidated (Efg1 is gone) stop() is called
> -A new service(Efg2) provides Efg
> -The start() of the component is called
> Why all the already existing services are bound at the creation of the
> component and not unbound at the "destruction" of the component?
> Another solution: Why don't bind the optional services at the validation of
> the component and unbind them at the invalidation (like it seems to be done
> with not optional service)?
--
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-3030) Bind/Unbind and lifecycle
[
https://issues.apache.org/jira/browse/FELIX-3030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13154057#comment-13154057
]
Clement Escoffier commented on FELIX-3030:
--
The issue here is the mix between the instance lifecycle (VALID / INVALID) and
the service dynamism (BIND/UNBIND). I understand your issue, but the promoted
model is to clean everything during the @Invalidate callback, and not expecting
an @Unbind callback. Indeed, if we call the unbind callback, how does the code
knows if it's just an unbind of a used service or if it's an invalidation.
> Bind/Unbind and lifecycle
> -
>
> Key: FELIX-3030
> URL: https://issues.apache.org/jira/browse/FELIX-3030
> Project: Felix
> Issue Type: Bug
> Components: iPOJO
>Affects Versions: iPOJO-1.8.0
>Reporter: Yann Diorcet
>
> According to my
> post(http://old.nabble.com/iPojo-lifecycle-and-dependencies-p32003301.html).
> It seems that there is a problem with the lifecycle and dependencies.
> @Component
> @Instantiate
> public final class Abcd {
> @Requires
> private Efg efg;
> @Validate
> private void start() {
> }
> @Invalidate
> private void stop() {
> }
> @Bind(aggregate = true, optional = true)
> private void bindXyz(final Xyz service) {
> }
> @Unbind
> private void unbindXyz(final Xyz service) {
> }
> }
> Scenario 1:
> -A new service(Efg1) provides Efg
> -A new service(Xyz1) provides Xyz
> -The component Abcd is instantiated
> -The bind() is called with Xyz1
> -The start() of the component is called
> -The Efg1 is unregistered
> -The component is invalidated (Efg1 is gone) stop() is called
> -During the time that my component is invalidated, if a new Xyz service(Xyz2)
> is registred (from an another bundle for example) bindXyz() is called
> -After that, if i stop my bundle, my component will be stopped but
> unbindXyz() will be not called(neither for Xyz1 nor Xyz2).
> Scenario 2:
> -A new service(Efg1) provides Efg
> -A new service(Xyz1) provides Xyz
> -The component Abcd is instantiated
> -The bind() is called with Xyz1
> -The start() of the component is called
> -The Efg1 is unregistered
> -The component is invalidated (Efg1 is gone) stop() is called
> -A new service(Efg2) provides Efg
> -The start() of the component is called
> Why all the already existing services are bound at the creation of the
> component and not unbound at the "destruction" of the component?
> Another solution: Why don't bind the optional services at the validation of
> the component and unbind them at the invalidation (like it seems to be done
> with not optional service)?
--
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-3204) @Temporal should handle instantiation-time properties
[ https://issues.apache.org/jira/browse/FELIX-3204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13154053#comment-13154053 ] Clement Escoffier commented on FELIX-3204: -- In the future (2.0 ?) the temporal dependency handler will be merges into the dependency handler. However, your patch looks good, I will just add the id attribute, and do some tests. > @Temporal should handle instantiation-time properties > - > > Key: FELIX-3204 > URL: https://issues.apache.org/jira/browse/FELIX-3204 > Project: Felix > Issue Type: Improvement > Components: iPOJO >Reporter: Thomas Calmant > Attachments: field-filters.patch > > > The temporal handler (@Temporal) should act like the dependency handler > (@Requires), by handling "requires.filters" and "requires.from" entries in a > component instance configuration. -- 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-3145) VerifyError on Java 7
[ https://issues.apache.org/jira/browse/FELIX-3145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier resolved FELIX-3145. -- Resolution: Fixed Fixed in trunk. The new manipulator and the ant tasks are also deployed to the Maven apache.snapshots repository (https://repository.apache.org/content/repositories/snapshots/org/apache/felix/) > VerifyError on Java 7 > - > > Key: FELIX-3145 > URL: https://issues.apache.org/jira/browse/FELIX-3145 > Project: Felix > Issue Type: Bug > Components: iPOJO > Environment: java 1.7.0 > ant 1.8.2 > felix 3.2.2 > ipojo 1.6.0 1.6.2 1.8.0 > bnd-task : bnd-0.0.401.jar > Ubuntu Linux >Reporter: Clement Escoffier >Assignee: Clement Escoffier > Fix For: ipojo-manipulator-1.8.2 > > > The manipulator must use a more recent version of ASM to avoid the following > issue: > java.lang.VerifyError: Expecting a stackmap frame at branch target 5 in > method > acme.world.EmptyHelloNonImmediate._setInstanceManager(Lorg/apache/felix/ipojo/InstanceManager;)V > at offset 1 -- 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] [Issue Comment Edited] (FELIX-3145) VerifyError on Java 7
[ https://issues.apache.org/jira/browse/FELIX-3145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13149521#comment-13149521 ] Clement Escoffier edited comment on FELIX-3145 at 11/14/11 9:55 AM: There is two issues: * ASM must be updated * the manipulator must compute the frames Running with -XX:-UseSplitVerifier makes it works. was (Author: clement.escoffier): There is two issues: * ASM must be updated * the manipulator must compute the frames > VerifyError on Java 7 > - > > Key: FELIX-3145 > URL: https://issues.apache.org/jira/browse/FELIX-3145 > Project: Felix > Issue Type: Bug > Components: iPOJO > Environment: java 1.7.0 > ant 1.8.2 > felix 3.2.2 > ipojo 1.6.0 1.6.2 1.8.0 > bnd-task : bnd-0.0.401.jar > Ubuntu Linux >Reporter: Clement Escoffier >Assignee: Clement Escoffier > Fix For: ipojo-manipulator-1.8.2 > > > The manipulator must use a more recent version of ASM to avoid the following > issue: > java.lang.VerifyError: Expecting a stackmap frame at branch target 5 in > method > acme.world.EmptyHelloNonImmediate._setInstanceManager(Lorg/apache/felix/ipojo/InstanceManager;)V > at offset 1 -- 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-3145) VerifyError on Java 7
[ https://issues.apache.org/jira/browse/FELIX-3145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13149521#comment-13149521 ] Clement Escoffier commented on FELIX-3145: -- There is two issues: * ASM must be updated * the manipulator must compute the frames > VerifyError on Java 7 > - > > Key: FELIX-3145 > URL: https://issues.apache.org/jira/browse/FELIX-3145 > Project: Felix > Issue Type: Bug > Components: iPOJO > Environment: java 1.7.0 > ant 1.8.2 > felix 3.2.2 > ipojo 1.6.0 1.6.2 1.8.0 > bnd-task : bnd-0.0.401.jar > Ubuntu Linux >Reporter: Clement Escoffier >Assignee: Clement Escoffier > Fix For: ipojo-manipulator-1.8.2 > > > The manipulator must use a more recent version of ASM to avoid the following > issue: > java.lang.VerifyError: Expecting a stackmap frame at branch target 5 in > method > acme.world.EmptyHelloNonImmediate._setInstanceManager(Lorg/apache/felix/ipojo/InstanceManager;)V > at offset 1 -- 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-3192) Service properties are not updated if the properties were already propagated
[ https://issues.apache.org/jira/browse/FELIX-3192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier resolved FELIX-3192. -- Resolution: Fixed Fixed in trunk > Service properties are not updated if the properties were already propagated > > > Key: FELIX-3192 > URL: https://issues.apache.org/jira/browse/FELIX-3192 > Project: Felix > Issue Type: Bug > Components: iPOJO > Reporter: Clement Escoffier > Assignee: Clement Escoffier > Fix For: ipojo-core-1.8.2 > > > If a property is propagated to the service registration and if this property > was already propagated, the value is not updated. -- 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-3190) iPOJO Factories doesn't give access to the complete Metadata model
[ https://issues.apache.org/jira/browse/FELIX-3190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier resolved FELIX-3190. -- Resolution: Fixed Fix Version/s: ipojo-core-1.8.2 Fixed in trunk. I've added Factory.getComponentMetadata() > iPOJO Factories doesn't give access to the complete Metadata model > -- > > Key: FELIX-3190 > URL: https://issues.apache.org/jira/browse/FELIX-3190 > Project: Felix > Issue Type: Improvement > Components: iPOJO >Reporter: Thomas Calmant >Assignee: Clement Escoffier >Priority: Minor > Fix For: ipojo-core-1.8.2 > > > Hi, > I'm trying to read the complete description of component type through its > Factory, before any instance of this component exists. > It seems that Factory.getDescription() retrieves only a sub-set of this > description, whereas the complete one is hidden in a protected > "m_componentMetadata" field. > My current workaround consists to read the field using reflection, but it's > not a natural way to do it. > Would it be possible to add a method like "Element getComponentMetadata()" in > the Factory interface to access to this field, or to a copy of it ? > Thanks, > Thomas -- 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-3193) Update the temporal dependency handler to use the new iPOJO Method interceptor API
[ https://issues.apache.org/jira/browse/FELIX-3193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier resolved FELIX-3193. -- Resolution: Fixed Fixed in trunk. The temporal handler requires iPOJO 1.9.0-SNAPSHOT (core 1.8.2 will be released soon) > Update the temporal dependency handler to use the new iPOJO Method > interceptor API > -- > > Key: FELIX-3193 > URL: https://issues.apache.org/jira/browse/FELIX-3193 > Project: Felix > Issue Type: Bug > Components: iPOJO > Reporter: Clement Escoffier > Assignee: Clement Escoffier > Fix For: ipojo-temporal-dependency-handler-1.8.0 > > > The handler must be adapted to use the new MethodInterceptor methods -- 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-3193) Update the temporal dependency handler to use the new iPOJO Method interceptor API
Update the temporal dependency handler to use the new iPOJO Method interceptor API -- Key: FELIX-3193 URL: https://issues.apache.org/jira/browse/FELIX-3193 Project: Felix Issue Type: Bug Components: iPOJO Reporter: Clement Escoffier Assignee: Clement Escoffier Fix For: ipojo-temporal-dependency-handler-1.8.0 The handler must be adapted to use the new MethodInterceptor methods -- 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-3192) Service properties are not updated if the properties were already propagated
Service properties are not updated if the properties were already propagated Key: FELIX-3192 URL: https://issues.apache.org/jira/browse/FELIX-3192 Project: Felix Issue Type: Bug Components: iPOJO Reporter: Clement Escoffier Assignee: Clement Escoffier Fix For: ipojo-core-1.8.2 If a property is propagated to the service registration and if this property was already propagated, the value is not updated. -- 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
