[jira] [Updated] (FELIX-5007) Manipulator error : "Prohibited package name: java.io" when a maven dependency defines java.io.IOException
[
https://issues.apache.org/jira/browse/FELIX-5007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Bourret updated FELIX-5007:
--
Attachment: Fix_FELIX-5007_(proposal).patch
Here is a patch proposal.
It overrides the {{IsolatedClassLoader.findClass()}} method. If {{name}} starts
with {{"java."}} it preventively throws a {{ClassNotFoundException}}.
The calling {{loadClass()}} method then delegates to its parent (if any).
> Manipulator error : "Prohibited package name: java.io" when a maven
> dependency defines java.io.IOException
> --
>
> Key: FELIX-5007
> URL: https://issues.apache.org/jira/browse/FELIX-5007
> Project: Felix
> Issue Type: Bug
> Components: iPOJO
>Affects Versions: ipojo-manipulator-1.12.1
> Environment: OS name: "linux", version: "3.13.0-62-generic", arch:
> "amd64", family: "unix"
> Java version: 1.8.0_60, vendor: Oracle Corporation
> Apache Maven 3.3.3 (7994120775791599e205a5524ec3e0dfe41d4a06;
> 2015-04-22T13:57:37+02:00)
>Reporter: Pierre Bourret
>Priority: Minor
> Attachments: Fix_FELIX-5007_(proposal).patch
>
>
> While building a project with many sub-modules, the maven-ipojo-plugin fails
> and gives me this error:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.felix:maven-ipojo-plugin:1.12.1:ipojo-bundle (default) on project
> roboconf-dm-rest-services: Execution default of goal
> org.apache.felix:maven-ipojo-plugin:1.12.1:ipojo-bundle failed:
> java.lang.SecurityException: Prohibited package name: java.io -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.felix:maven-ipojo-plugin:1.12.1:ipojo-bundle (default) on
> project roboconf-dm-rest-services: Execution default of goal
> org.apache.felix:maven-ipojo-plugin:1.12.1:ipojo-bundle failed:
> java.lang.SecurityException: Prohibited package name: java.io
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:862)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:286)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:197)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default of goal org.apache.felix:maven-ipojo-plugin:1.12.1:ipojo-bundle
> failed: java.lang.SecurityException: Prohibited package name: java.io
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 20 more
> Caused by: java.lang.RuntimeException: java.lang.SecurityException:
> Prohibited package name: java.io
> at
> org.apache.felix.ipojo.manipulation.ClassLoaderAwareClassWriter.getCommonSuperClass(ClassLoaderAwareClassWriter.java:74)
> at org.objectweb.asm.ClassWriter.a(Unknown Source)
> at org.objectweb.asm.Frame.a(Unknown Source)
> at org.objectweb.asm.Frame.a(Unknown Source)
> at org.objectweb.asm.MethodWriter.visitMaxs(Unknown Source)
> at org.objectweb.asm.MethodVisitor.visitMaxs(Unknown Source)
> at
[jira] [Created] (FELIX-5007) Manipulator error : Prohibited package name: java.io when a maven dependency defines java.io.IOException
Pierre Bourret created FELIX-5007:
-
Summary: Manipulator error : Prohibited package name: java.io
when a maven dependency defines java.io.IOException
Key: FELIX-5007
URL: https://issues.apache.org/jira/browse/FELIX-5007
Project: Felix
Issue Type: Bug
Components: iPOJO
Affects Versions: ipojo-manipulator-1.12.1
Environment: OS name: linux, version: 3.13.0-62-generic, arch:
amd64, family: unix
Java version: 1.8.0_60, vendor: Oracle Corporation
Apache Maven 3.3.3 (7994120775791599e205a5524ec3e0dfe41d4a06;
2015-04-22T13:57:37+02:00)
Reporter: Pierre Bourret
Priority: Minor
While building a project with many sub-modules, the maven-ipojo-plugin fails
and gives me this error:
{noformat}
[ERROR] Failed to execute goal
org.apache.felix:maven-ipojo-plugin:1.12.1:ipojo-bundle (default) on project
roboconf-dm-rest-services: Execution default of goal
org.apache.felix:maven-ipojo-plugin:1.12.1:ipojo-bundle failed:
java.lang.SecurityException: Prohibited package name: java.io - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.felix:maven-ipojo-plugin:1.12.1:ipojo-bundle (default) on project
roboconf-dm-rest-services: Execution default of goal
org.apache.felix:maven-ipojo-plugin:1.12.1:ipojo-bundle failed:
java.lang.SecurityException: Prohibited package name: java.io
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:862)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:286)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:197)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default
of goal org.apache.felix:maven-ipojo-plugin:1.12.1:ipojo-bundle failed:
java.lang.SecurityException: Prohibited package name: java.io
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
... 20 more
Caused by: java.lang.RuntimeException: java.lang.SecurityException: Prohibited
package name: java.io
at
org.apache.felix.ipojo.manipulation.ClassLoaderAwareClassWriter.getCommonSuperClass(ClassLoaderAwareClassWriter.java:74)
at org.objectweb.asm.ClassWriter.a(Unknown Source)
at org.objectweb.asm.Frame.a(Unknown Source)
at org.objectweb.asm.Frame.a(Unknown Source)
at org.objectweb.asm.MethodWriter.visitMaxs(Unknown Source)
at org.objectweb.asm.MethodVisitor.visitMaxs(Unknown Source)
at org.objectweb.asm.util.CheckMethodAdapter.visitMaxs(Unknown Source)
at org.objectweb.asm.commons.LocalVariablesSorter.visitMaxs(Unknown
Source)
at org.objectweb.asm.ClassReader.a(Unknown Source)
at org.objectweb.asm.ClassReader.b(Unknown Source)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at
org.apache.felix.ipojo.manipulation.Manipulator.manipulate(Manipulator.java:135)
at
org.apache.felix.ipojo.manipulator.ManipulationEngine.generate(ManipulationEngine.java:142)
at
[jira] [Commented] (FELIX-4802) Aggregate Dependency with Field Injection does not respect SERVICE_RANKING
[
https://issues.apache.org/jira/browse/FELIX-4802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14329058#comment-14329058
]
Pierre Bourret commented on FELIX-4802:
---
Hi,
I think you should use the dynamic-priority binding policy for your dependency:
{code:java}
@Requires(policy=BindingPolicy.DYNAMIC_PRIORITY)
private Hello m_hellos[]; // Array = Aggregate
{code}
The iPOJO documentation is quite clear :
[http://felix.apache.org/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/service-requirement-handler.html#managing-resilience-to-dynamism-binding-policies]
{quote}
* Dynamic policy (default): the binding are managed dynamically. At each
injection, the same provider is injected if the provider is always available.
Else a new one is chosen. For aggregate dependency, *the array order does not
change*; new providers are placed at the end of the array.
[…]
* Dynamic-priority policy: the binding is managed dynamically but the injected
provider is selected by using a ranking policy. Two injections can return two
different providers, is a new provider is 'better' than the previous one,
despite the first one is always available. For aggregate dependency, *the array
is sorted*.
{quote}
If you want to always keep your array sorted, use the dynamic priority policy.
Aggregate Dependency with Field Injection does not respect SERVICE_RANKING
--
Key: FELIX-4802
URL: https://issues.apache.org/jira/browse/FELIX-4802
Project: Felix
Issue Type: Bug
Components: iPOJO
Affects Versions: ipojo-runtime-1.12.1
Environment: I found this using Apache Karaf 3.0.3
Reporter: Andy Phillips
I found an issue with the Aggregate Dependency with Field Injection where i
have a list of services that i would like to maintain with a manager. The
order of the services is important.
I noticed that the field injection, say:
@Component
public class HelloConsumer {
@Requires
private Hello m_hellos[]; // Array = Aggregate
public doSomething() {
for(int I = 0; I m_hellos.length; i++) {
System.out.println(m_hellos[i].getMessage());
}
}
}
The initial list when the instance is created appears to respect the
SERVICE_RANKING, but subequent modifications (say you install a new bundle
with an additional hello) does not respect the SERVICE_RANKING in the
order. I will have to end up do my own sorting on the list prior to using
the field.
Is this normal? I feel that the SERVICE_RANKING should always be respected
on the list of m_hellos[]s
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-4138) TypeDeclaration calls factory.dispose() even if it already has been disposed (externally)
[ https://issues.apache.org/jira/browse/FELIX-4138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13686540#comment-13686540 ] Pierre Bourret commented on FELIX-4138: --- Stack trace: ERROR: Bundle org.apache.felix.ipojo [13] EventDispatcher: Error during dispatch. (java.lang.NullPointerException) java.lang.NullPointerException at org.apache.felix.ipojo.IPojoFactory.removeFactoryStateListener(IPojoFactory.java:518) at org.apache.felix.ipojo.extender.internal.linker.ManagedType$ExtensionSupport.removedService(ManagedType.java:241) at org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:956) at org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:864) at org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341) at org.osgi.util.tracker.ServiceTracker.close(ServiceTracker.java:375) at org.apache.felix.ipojo.extender.internal.linker.ManagedType.stop(ManagedType.java:167) at org.apache.felix.ipojo.extender.internal.linker.DeclarationLinker.removedService(DeclarationLinker.java:107) at org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:956) at org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:864) at org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341) at org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:902) at org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932) at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793) at org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543) at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4401) at org.apache.felix.framework.Felix.access$000(Felix.java:74) at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:390) at org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:151) at org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127) at org.apache.felix.ipojo.extender.internal.AbstractService.stop(AbstractService.java:73) at org.apache.felix.ipojo.extender.internal.processor.ComponentsBundleProcessor$ComponentsAndInstances.stop(ComponentsBundleProcessor.java:223) at org.apache.felix.ipojo.extender.internal.processor.ComponentsBundleProcessor.deactivate(ComponentsBundleProcessor.java:112) at org.apache.felix.ipojo.extender.internal.processor.ChainedBundleProcessor.deactivate(ChainedBundleProcessor.java:100) at org.apache.felix.ipojo.extender.internal.Extender$1.removedBundle(Extender.java:173) at org.osgi.util.tracker.BundleTracker$Tracked.customizerRemoved(BundleTracker.java:491) at org.osgi.util.tracker.BundleTracker$Tracked.customizerRemoved(BundleTracker.java:414) at org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341) at org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:449) 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:4385) at org.apache.felix.framework.Felix.stopBundle(Felix.java:2508) at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1297) at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:304) at java.lang.Thread.run(Thread.java:679) TypeDeclaration calls factory.dispose() even if it already has been disposed (externally) - Key: FELIX-4138 URL: https://issues.apache.org/jira/browse/FELIX-4138 Project: Felix Issue Type: Bug Components: iPOJO Affects Versions: ipojo-runtime-1.10 Reporter: Pierre Bourret In some tests, I manually destroy an iPOJO factory by calling IPojoFactory.dispose() However, on framweork shutdown, the associated type declaration tries to call the same method again, without checking the factory actual state. It may also be possible that the TypeDeclaration is not unbound despite the fact the factory is not active anymore. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA
[jira] [Created] (FELIX-4138) TypeDeclaration calls factory.dispose() even if it already has been disposed (externally)
Pierre Bourret created FELIX-4138: - Summary: TypeDeclaration calls factory.dispose() even if it already has been disposed (externally) Key: FELIX-4138 URL: https://issues.apache.org/jira/browse/FELIX-4138 Project: Felix Issue Type: Bug Components: iPOJO Affects Versions: ipojo-runtime-1.10 Reporter: Pierre Bourret In some tests, I manually destroy an iPOJO factory by calling IPojoFactory.dispose() However, on framweork shutdown, the associated type declaration tries to call the same method again, without checking the factory actual state. It may also be possible that the TypeDeclaration is not unbound despite the fact the factory is not active anymore. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-4116) Ability to listen for component service dependencies, providings, configuration properties, ...
[ https://issues.apache.org/jira/browse/FELIX-4116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Bourret updated FELIX-4116: -- Attachment: (was: FELIX-4116_Ability_to_listen_for_component_service_dependencies_providings_configuration_properties.patch) Ability to listen for component service dependencies, providings, configuration properties, ... --- Key: FELIX-4116 URL: https://issues.apache.org/jira/browse/FELIX-4116 Project: Felix Issue Type: New Feature Components: iPOJO Environment: N/A Reporter: Pierre Bourret iPOJO offers the ability to be notified when a service arrives/is modified/leaves a dependency. However this notifications happens _inside_ the component, via dependency callbacks (@Bind, @Unbind, @Modified). What would be cool is to listen to this events _externally_, with listeners on the DependencyModel. Is is possible right now to do this with a hack of the DependencyCallbacks (lots of reflection, ugly code). So what just lacks is the API to register/unregister listeners + the listener interface. Same thing for service providings : we should be able to be notified when a component start/stop to provide a service. It is possible to listen to all services with the good instance.name, but this is not really elegant, and there might be issues with isolated ServiceContext (composite). Registering a listener on the ProvidedService seems a better approach IMO. Same point for configuration, like the @Updated callback, but external. For sure there are lots of other component things to listen to... ;) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-4116) Ability to listen for component service dependencies, providings, configuration properties, ...
[ https://issues.apache.org/jira/browse/FELIX-4116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Bourret updated FELIX-4116: -- Attachment: FELIX-4116_Ability_to_listen_for_component_service_dependencies_providings_configuration_properties.patch Updated patch : previous version prevents handlers to release the listeners. Now they clear the listener list when they get disposed Ability to listen for component service dependencies, providings, configuration properties, ... --- Key: FELIX-4116 URL: https://issues.apache.org/jira/browse/FELIX-4116 Project: Felix Issue Type: New Feature Components: iPOJO Environment: N/A Reporter: Pierre Bourret Attachments: FELIX-4116_Ability_to_listen_for_component_service_dependencies_providings_configuration_properties.patch iPOJO offers the ability to be notified when a service arrives/is modified/leaves a dependency. However this notifications happens _inside_ the component, via dependency callbacks (@Bind, @Unbind, @Modified). What would be cool is to listen to this events _externally_, with listeners on the DependencyModel. Is is possible right now to do this with a hack of the DependencyCallbacks (lots of reflection, ugly code). So what just lacks is the API to register/unregister listeners + the listener interface. Same thing for service providings : we should be able to be notified when a component start/stop to provide a service. It is possible to listen to all services with the good instance.name, but this is not really elegant, and there might be issues with isolated ServiceContext (composite). Registering a listener on the ProvidedService seems a better approach IMO. Same point for configuration, like the @Updated callback, but external. For sure there are lots of other component things to listen to... ;) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-4114) iPOJO ProvidedServiceDescription does not expose policy CreationStrategy
[ https://issues.apache.org/jira/browse/FELIX-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13683441#comment-13683441 ] Pierre Bourret commented on FELIX-4114: --- Great! Thanks It seems fine to close this issue as soon as changes are released. iPOJO ProvidedServiceDescription does not expose policy CreationStrategy -- Key: FELIX-4114 URL: https://issues.apache.org/jira/browse/FELIX-4114 Project: Felix Issue Type: Bug Components: iPOJO Affects Versions: ipojo-runtime-1.10 Environment: N/A Reporter: Pierre Bourret Assignee: Clement Escoffier Priority: Minor Fix For: ipojo-runtime-1.10.1 Attachments: FELIX-4114_iPOJO_ProvidedServiceDescription_does_not_expose_policy_and_CreationStrategy.patch The provided service handler description (ProvidedServiceDescription) allows to retrieve some useful info about the provided service, but the service factory policy and/or the creation strategy are hidden. It would be nice to access both of these properties : - the policy : SINGLETON_STRATEGY, SERVICE_STRATEGY, STATIC_STRATEGY or INSTANCE_STRATEGY - the CreationStrategy implementation class. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-4116) Ability to listen for component service dependencies, providings, configuration properties, ...
[ https://issues.apache.org/jira/browse/FELIX-4116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Bourret updated FELIX-4116: -- Attachment: FELIX-4116_Ability_to_listen_for_component_service_dependencies_providings_configuration_properties.patch Here is a patch for the iPOJO component listeners: - on configuration (tested) - on provided services (tested) - on service dependencies (NOT tested) Unfortunately I miss some time to test the listeners on service dependencies, which really are the more complicated things to listen to... Ability to listen for component service dependencies, providings, configuration properties, ... --- Key: FELIX-4116 URL: https://issues.apache.org/jira/browse/FELIX-4116 Project: Felix Issue Type: New Feature Components: iPOJO Environment: N/A Reporter: Pierre Bourret Attachments: FELIX-4116_Ability_to_listen_for_component_service_dependencies_providings_configuration_properties.patch iPOJO offers the ability to be notified when a service arrives/is modified/leaves a dependency. However this notifications happens _inside_ the component, via dependency callbacks (@Bind, @Unbind, @Modified). What would be cool is to listen to this events _externally_, with listeners on the DependencyModel. Is is possible right now to do this with a hack of the DependencyCallbacks (lots of reflection, ugly code). So what just lacks is the API to register/unregister listeners + the listener interface. Same thing for service providings : we should be able to be notified when a component start/stop to provide a service. It is possible to listen to all services with the good instance.name, but this is not really elegant, and there might be issues with isolated ServiceContext (composite). Registering a listener on the ProvidedService seems a better approach IMO. Same point for configuration, like the @Updated callback, but external. For sure there are lots of other component things to listen to... ;) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-4116) Ability to listen for component service dependencies, providings, configuration properties, ...
[ https://issues.apache.org/jira/browse/FELIX-4116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13681228#comment-13681228 ] Pierre Bourret commented on FELIX-4116: --- Work started here : https://github.com/bourretp/felix/tree/feature/component-listeners Already got listeners for provided services and configuration. For configuration, listeners are called when an _external_ reconfiguration_ occurs. Notifying listeners each time the POJO change a field value would dramatically slow down the component and expose inconsistent intermediate state to the listeners. Listeners on service dependencies are ongoing... Ability to listen for component service dependencies, providings, configuration properties, ... --- Key: FELIX-4116 URL: https://issues.apache.org/jira/browse/FELIX-4116 Project: Felix Issue Type: New Feature Components: iPOJO Environment: N/A Reporter: Pierre Bourret iPOJO offers the ability to be notified when a service arrives/is modified/leaves a dependency. However this notifications happens _inside_ the component, via dependency callbacks (@Bind, @Unbind, @Modified). What would be cool is to listen to this events _externally_, with listeners on the DependencyModel. Is is possible right now to do this with a hack of the DependencyCallbacks (lots of reflection, ugly code). So what just lacks is the API to register/unregister listeners + the listener interface. Same thing for service providings : we should be able to be notified when a component start/stop to provide a service. It is possible to listen to all services with the good instance.name, but this is not really elegant, and there might be issues with isolated ServiceContext (composite). Registering a listener on the ProvidedService seems a better approach IMO. Same point for configuration, like the @Updated callback, but external. For sure there are lots of other component things to listen to... ;) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-4116) Ability to listen for component service dependencies, providings, configuration properties, ...
Pierre Bourret created FELIX-4116: - Summary: Ability to listen for component service dependencies, providings, configuration properties, ... Key: FELIX-4116 URL: https://issues.apache.org/jira/browse/FELIX-4116 Project: Felix Issue Type: New Feature Components: iPOJO Environment: N/A Reporter: Pierre Bourret iPOJO offers the ability to be notified when a service arrives/is modified/leaves a dependency. However this notifications happens _inside_ the component, via dependency callbacks (@Bind, @Unbind, @Modified). What would be cool is to listen to this events _externally_, with listeners on the DependencyModel. Is is possible right now to do this with a hack of the DependencyCallbacks (lots of reflection, ugly code). So what just lacks is the API to register/unregister listeners + the listener interface. Same thing for service providings : we should be able to be notified when a component start/stop to provide a service. It is possible to listen to all services with the good instance.name, but this is not really elegant, and there might be issues with isolated ServiceContext (composite). Registering a listener on the ProvidedService seems a better approach IMO. Same point for configuration, like the @Updated callback, but external. For sure there are lots of other component things to listen to... ;) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-4114) iPOJO ProvidedServiceDescription does not expose policy CreationStrategy
Pierre Bourret created FELIX-4114: - Summary: iPOJO ProvidedServiceDescription does not expose policy CreationStrategy Key: FELIX-4114 URL: https://issues.apache.org/jira/browse/FELIX-4114 Project: Felix Issue Type: Bug Components: iPOJO Affects Versions: ipojo-runtime-1.10 Environment: N/A Reporter: Pierre Bourret Priority: Minor The provided service handler description (ProvidedServiceDescription) allows to retrieve some useful info about the provided service, but the service factory policy and/or the creation strategy are hidden. It would be nice to access both of these properties : - the policy : SINGLETON_STRATEGY, SERVICE_STRATEGY, STATIC_STRATEGY or INSTANCE_STRATEGY - the CreationStrategy implementation class. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-4114) iPOJO ProvidedServiceDescription does not expose policy CreationStrategy
[ https://issues.apache.org/jira/browse/FELIX-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Bourret updated FELIX-4114: -- Attachment: FELIX-4114_iPOJO_ProvidedServiceDescription_does_not_expose_policy_and_CreationStrategy.patch Attached patch defines getPolicy() and getCreationStrategy() in both ProvidedService and ProvidedServiceDescription classes. A new virtual policy has been defined, CUSTOM_POLICY, that means that the service providing has a customized creation strategy. iPOJO ProvidedServiceDescription does not expose policy CreationStrategy -- Key: FELIX-4114 URL: https://issues.apache.org/jira/browse/FELIX-4114 Project: Felix Issue Type: Bug Components: iPOJO Affects Versions: ipojo-runtime-1.10 Environment: N/A Reporter: Pierre Bourret Priority: Minor Attachments: FELIX-4114_iPOJO_ProvidedServiceDescription_does_not_expose_policy_and_CreationStrategy.patch The provided service handler description (ProvidedServiceDescription) allows to retrieve some useful info about the provided service, but the service factory policy and/or the creation strategy are hidden. It would be nice to access both of these properties : - the policy : SINGLETON_STRATEGY, SERVICE_STRATEGY, STATIC_STRATEGY or INSTANCE_STRATEGY - the CreationStrategy implementation class. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-4115) NPE in DependencyModel.getService() when @Bind method throws an exception
Pierre Bourret created FELIX-4115: - Summary: NPE in DependencyModel.getService() when @Bind method throws an exception Key: FELIX-4115 URL: https://issues.apache.org/jira/browse/FELIX-4115 Project: Felix Issue Type: Bug Components: iPOJO Affects Versions: ipojo-runtime-1.10 Environment: Linux 3.5.0-32-generic #53-Ubuntu SMP Wed May 29 20:23:04 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux java version 1.6.0_27 OpenJDK Runtime Environment (IcedTea6 1.12.5) (6b27-1.12.5-0ubuntu0.12.10.1) OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode) Reporter: Pierre Bourret When a service binding callback throws an exception, the associated DependencyModel fails with an NPE. In the following log, the first exception is provoked. However, the second one is a bug inside the DependencyModel (m_tracker is null). 2013.06.10 16:28:23 ERROR - Bundle: bugs.bug - [ERROR] : The method bindInstance in the implementation class bugs.NaughtyBinder throws an exception : E ≠ mc² - java.lang.NullPointerException: E ≠ mc² at bugs.NaughtyBinder.__M_bindInstance(NaughtyBinder.java:14) at bugs.NaughtyBinder.bindInstance(NaughtyBinder.java) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.apache.felix.ipojo.util.Callback.call(Callback.java:260) at org.apache.felix.ipojo.handlers.dependency.DependencyCallback.callOnInstance(DependencyCallback.java:309) at org.apache.felix.ipojo.handlers.dependency.Dependency.invokeCallback(Dependency.java:330) at org.apache.felix.ipojo.handlers.dependency.Dependency.onObjectCreation(Dependency.java:282) at org.apache.felix.ipojo.handlers.dependency.DependencyHandler.__M_onCreation(DependencyHandler.java:702) at org.apache.felix.ipojo.handlers.dependency.DependencyHandler.onCreation(DependencyHandler.java) at org.apache.felix.ipojo.InstanceManager.getPojoObject(InstanceManager.java:934) at org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHandler.__M_stateChanged(LifecycleCallbackHandler.java:156) at org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHandler.stateChanged(LifecycleCallbackHandler.java) at org.apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:536) at org.apache.felix.ipojo.InstanceManager.start(InstanceManager.java:418) at org.apache.felix.ipojo.ComponentFactory.createInstance(ComponentFactory.java:178) at org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:307) at org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:234) at org.apache.felix.ipojo.extender.internal.linker.ManagedType$InstanceSupport$1.call(ManagedType.java:285) at org.apache.felix.ipojo.extender.internal.linker.ManagedType$InstanceSupport$1.call(ManagedType.java:279) at org.apache.felix.ipojo.extender.internal.queue.JobInfoCallable.call(JobInfoCallable.java:100) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:679) 2013.06.10 16:28:23 ERROR - Bundle: bugs.bug - [ERROR] bugs.NaughtyBinder : null - java.lang.NullPointerException at org.apache.felix.ipojo.util.DependencyModel.getService(DependencyModel.java:948) at org.apache.felix.ipojo.util.DependencyModel.getService(DependencyModel.java:938) at org.apache.felix.ipojo.handlers.dependency.Dependency.onObjectCreation(Dependency.java:280) at org.apache.felix.ipojo.handlers.dependency.DependencyHandler.__M_onCreation(DependencyHandler.java:702) at org.apache.felix.ipojo.handlers.dependency.DependencyHandler.onCreation(DependencyHandler.java) at org.apache.felix.ipojo.InstanceManager.getPojoObject(InstanceManager.java:934) at org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHandler.__M_stateChanged(LifecycleCallbackHandler.java:156) at org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHandler.stateChanged(LifecycleCallbackHandler.java) at org.apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:536) at org.apache.felix.ipojo.InstanceManager.start(InstanceManager.java:418) at
[jira] [Updated] (FELIX-4115) NPE in DependencyModel.getService() when @Bind method throws an exception
[ https://issues.apache.org/jira/browse/FELIX-4115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Bourret updated FELIX-4115: -- Attachment: bug-project.zip Attached here : a simple project to reproduce the bug It creates an instance of a component that throws a NullPointerException in its bindInstance method (the provoked exception). NPE in DependencyModel.getService() when @Bind method throws an exception - Key: FELIX-4115 URL: https://issues.apache.org/jira/browse/FELIX-4115 Project: Felix Issue Type: Bug Components: iPOJO Affects Versions: ipojo-runtime-1.10 Environment: Linux 3.5.0-32-generic #53-Ubuntu SMP Wed May 29 20:23:04 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux java version 1.6.0_27 OpenJDK Runtime Environment (IcedTea6 1.12.5) (6b27-1.12.5-0ubuntu0.12.10.1) OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode) Reporter: Pierre Bourret Attachments: bug-project.zip When a service binding callback throws an exception, the associated DependencyModel fails with an NPE. In the following log, the first exception is provoked. However, the second one is a bug inside the DependencyModel (m_tracker is null). 2013.06.10 16:28:23 ERROR - Bundle: bugs.bug - [ERROR] : The method bindInstance in the implementation class bugs.NaughtyBinder throws an exception : E ≠ mc² - java.lang.NullPointerException: E ≠ mc² at bugs.NaughtyBinder.__M_bindInstance(NaughtyBinder.java:14) at bugs.NaughtyBinder.bindInstance(NaughtyBinder.java) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.apache.felix.ipojo.util.Callback.call(Callback.java:260) at org.apache.felix.ipojo.handlers.dependency.DependencyCallback.callOnInstance(DependencyCallback.java:309) at org.apache.felix.ipojo.handlers.dependency.Dependency.invokeCallback(Dependency.java:330) at org.apache.felix.ipojo.handlers.dependency.Dependency.onObjectCreation(Dependency.java:282) at org.apache.felix.ipojo.handlers.dependency.DependencyHandler.__M_onCreation(DependencyHandler.java:702) at org.apache.felix.ipojo.handlers.dependency.DependencyHandler.onCreation(DependencyHandler.java) at org.apache.felix.ipojo.InstanceManager.getPojoObject(InstanceManager.java:934) at org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHandler.__M_stateChanged(LifecycleCallbackHandler.java:156) at org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHandler.stateChanged(LifecycleCallbackHandler.java) at org.apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:536) at org.apache.felix.ipojo.InstanceManager.start(InstanceManager.java:418) at org.apache.felix.ipojo.ComponentFactory.createInstance(ComponentFactory.java:178) at org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:307) at org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:234) at org.apache.felix.ipojo.extender.internal.linker.ManagedType$InstanceSupport$1.call(ManagedType.java:285) at org.apache.felix.ipojo.extender.internal.linker.ManagedType$InstanceSupport$1.call(ManagedType.java:279) at org.apache.felix.ipojo.extender.internal.queue.JobInfoCallable.call(JobInfoCallable.java:100) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:679) 2013.06.10 16:28:23 ERROR - Bundle: bugs.bug - [ERROR] bugs.NaughtyBinder : null - java.lang.NullPointerException at org.apache.felix.ipojo.util.DependencyModel.getService(DependencyModel.java:948) at org.apache.felix.ipojo.util.DependencyModel.getService(DependencyModel.java:938) at org.apache.felix.ipojo.handlers.dependency.Dependency.onObjectCreation(Dependency.java:280) at org.apache.felix.ipojo.handlers.dependency.DependencyHandler.__M_onCreation(DependencyHandler.java:702) at org.apache.felix.ipojo.handlers.dependency.DependencyHandler.onCreation(DependencyHandler.java) at org.apache.felix.ipojo.InstanceManager.getPojoObject(InstanceManager.java:934) at
[jira] [Created] (FELIX-4111) TypeDeclarations for handlers do not expose namespace (explicitly)
Pierre Bourret created FELIX-4111: - Summary: TypeDeclarations for handlers do not expose namespace (explicitly) Key: FELIX-4111 URL: https://issues.apache.org/jira/browse/FELIX-4111 Project: Felix Issue Type: Bug Components: iPOJO Affects Versions: ipojo-runtime-1.10 Environment: N/A Reporter: Pierre Bourret Priority: Minor The TypeDeclaration services allows to retrieve the component types that have been declared, and their current status (bound/unbound , reason, ...) However, there is something missing about iPOJO handlers : their TypeDeclaration services do not allow to retrieve their namespaces. For example, the dependency handler TypeDeclaration.getComponentName() method returns requires. It would be very appreciable to retrieve the namespace information via the getComponentName() method (or getComponentNameSpace() ?). One possible workaround it to retrieve the namespace from the component metadata : String ns = typeDeclaration().getComponentMetadata().getAttribute(namespace); It is not very elegant since it relies on iPOJO internals (the metadata structure) and it returns null for iPOJO core handlers (instead of the org.apache.felix.ipojo namespace) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-4111) TypeDeclarations for handlers do not expose namespace (explicitly)
[ https://issues.apache.org/jira/browse/FELIX-4111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Bourret updated FELIX-4111: -- Attachment: FELIX-4111_possible_fix__TypeDeclarations_for_handlers_do_not_expose_namespace_explicitly.patch Here is a possible fix for this issue. I've added a method getComponentNameSpace() that returns the namespace (retrieved from metadata). If the targeted iPOJO extension is handler and the component metadata doesn't define the namespace attribute, the method returns the implicit namespace (for core handlers) : org.apache.felix.ipojo TypeDeclarations for handlers do not expose namespace (explicitly) -- Key: FELIX-4111 URL: https://issues.apache.org/jira/browse/FELIX-4111 Project: Felix Issue Type: Bug Components: iPOJO Affects Versions: ipojo-runtime-1.10 Environment: N/A Reporter: Pierre Bourret Priority: Minor Attachments: FELIX-4111_possible_fix__TypeDeclarations_for_handlers_do_not_expose_namespace_explicitly.patch The TypeDeclaration services allows to retrieve the component types that have been declared, and their current status (bound/unbound , reason, ...) However, there is something missing about iPOJO handlers : their TypeDeclaration services do not allow to retrieve their namespaces. For example, the dependency handler TypeDeclaration.getComponentName() method returns requires. It would be very appreciable to retrieve the namespace information via the getComponentName() method (or getComponentNameSpace() ?). One possible workaround it to retrieve the namespace from the component metadata : String ns = typeDeclaration().getComponentMetadata().getAttribute(namespace); It is not very elegant since it relies on iPOJO internals (the metadata structure) and it returns null for iPOJO core handlers (instead of the org.apache.felix.ipojo namespace) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3930) New Interceptor model for handlers
[ https://issues.apache.org/jira/browse/FELIX-3930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13678029#comment-13678029 ] Pierre Bourret commented on FELIX-3930: --- Here is a proposal for a new interception model : https://github.com/bourretp/felix/tree/feature/interception-api It is based on the Interceptor pattern customized for POJOs. Constructors method invocations + field access can be intercepted, arguments/return value can be injected/changed/removed. For methods, the real method invocation can be completely skipped (e.g. a cache-handler) For constructors, the choice of the correct constructor to call depends on the actual type of the injected arguments. An error is raised if no suitable constructor can be found. A warning occurs if there is an ambiguity (and the first one is chosen) For fields, nothing special, except that the injected values are _really_ put in the POJO fields... Really nice for debugging. All injected references are cleared when the component is stopped, to avoid keeping stale references of services and blocking bundle GC. Documentation is _ongoing_, and implementation is still open to fixes/enhancement. One _big_ blot : this proposition, especially changes in the manipulator, break compatibility with iPOJO components built with previous versions of the manipulator. Keeping this compatibility seems really complicated (at east). So this feature cannot be integrated in the mainline now, and must wait for iPOJO version 2.0.0. New Interceptor model for handlers -- Key: FELIX-3930 URL: https://issues.apache.org/jira/browse/FELIX-3930 Project: Felix Issue Type: Improvement Components: iPOJO Reporter: Clement Escoffier Assignee: Clement Escoffier Define and implement a new interceptor model. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-4054) Use current factory version to generate instance name if required
[ https://issues.apache.org/jira/browse/FELIX-4054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13650173#comment-13650173 ] Pierre Bourret commented on FELIX-4054: --- Fix confirmed (trunk r1479678) : Got 2 factories with the same name BarImpl and 2 different versions : null (no version set) and 2.0.0 First instance created with null factory is named : BarImpl-0 First instance created with 2.0.0 factory is named BarImpl-0-2.0.0 (No instance name is provided for these 2 creations, to force name generation) Before the fix, the second instance creation failed because of a generated name conflict (both were BarImpl-0) Use current factory version to generate instance name if required - Key: FELIX-4054 URL: https://issues.apache.org/jira/browse/FELIX-4054 Project: Felix Issue Type: Bug Components: iPOJO Affects Versions: ipojo-runtime-1.8.6 Reporter: Clement Escoffier Assignee: Clement Escoffier Fix For: ipojo-runtime-1.10 When two factories of different versions are installed, the unique name generation should use the factory version if a conflict is detected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (FELIX-2779) iPOJO manipulator badly supports custom annotation attributes of type Class
[
https://issues.apache.org/jira/browse/FELIX-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Bourret closed FELIX-2779.
-
OK : tested with iPOJO-1.8.0
iPOJO manipulator badly supports custom annotation attributes of type Class
---
Key: FELIX-2779
URL: https://issues.apache.org/jira/browse/FELIX-2779
Project: Felix
Issue Type: Bug
Components: iPOJO
Affects Versions: iPOJO-1.6.0
Reporter: Pierre Bourret
Assignee: Clement Escoffier
Priority: Minor
Fix For: iPOJO-1.8.0
Attachments:
FixBadClassParameterHandlingInCustomAnnotationVisitor.patch
I've written a custom handler and its corresponding annotation :
public @interface Portlet {
...
Class? extends PortletPresentation portletClass();
...
}
Then I've defined a component using this annotation :
@Component
@Portlet(..., portletClass=DummyComponentPortletImpl.class)
public class DummyComponentImpl {
...
}
The problem is that the metadata computed by the manipulator doesn't hold the
right value for the portletClass attribute :
I got Lfr/liglab/adele/icasa/portal/impl/test/DummyComponentPortletImpl;
instead of fr.liglab.adele.icasa.portal.impl.test.DummyComponentPortletImpl.
Despite it is still possible to deduce the original class name from this
strange string, isn't the attribute value supposed to contain the real class
name instead of a Java internal type name ?
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (FELIX-2779) iPOJO manipulator badly supports custom annotation attributes of type Class
iPOJO manipulator badly supports custom annotation attributes of type Class
---
Key: FELIX-2779
URL: https://issues.apache.org/jira/browse/FELIX-2779
Project: Felix
Issue Type: Bug
Components: iPOJO
Affects Versions: iPOJO-1.6.0
Reporter: Pierre Bourret
Priority: Minor
I've written a custom handler and its corresponding annotation :
public @interface Portlet {
...
Class? extends PortletPresentation portletClass();
...
}
Then I've defined a component using this annotation :
@Component
@Portlet(..., portletClass=DummyComponentPortletImpl.class)
public class DummyComponentImpl {
...
}
The problem is that the metadata computed by the manipulator doesn't hold the
right value for the portletClass attribute :
I got Lfr/liglab/adele/icasa/portal/impl/test/DummyComponentPortletImpl;
instead of fr.liglab.adele.icasa.portal.impl.test.DummyComponentPortletImpl.
Despite it is still possible to deduce the original class name from this
strange string, isn't the attribute value supposed to contain the real class
name instead of a Java internal type name ?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2779) iPOJO manipulator badly supports custom annotation attributes of type Class
[
https://issues.apache.org/jira/browse/FELIX-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Bourret updated FELIX-2779:
--
Attachment: FixBadClassParameterHandlingInCustomAnnotationVisitor.patch
The problem is that the visit(String, Object) method of the
CustomAnnotationVisitor is called with a org.objectweb.asm.Type parameter when
the annotation attribute type is a Class. The Type.toString() method returns
the internal type name, so getClassName() must be used instead.
Here is a patch that solves the problem in my case. It also handles the case of
Class[] annotation attribute type.
iPOJO manipulator badly supports custom annotation attributes of type Class
---
Key: FELIX-2779
URL: https://issues.apache.org/jira/browse/FELIX-2779
Project: Felix
Issue Type: Bug
Components: iPOJO
Affects Versions: iPOJO-1.6.0
Reporter: Pierre Bourret
Priority: Minor
Attachments:
FixBadClassParameterHandlingInCustomAnnotationVisitor.patch
I've written a custom handler and its corresponding annotation :
public @interface Portlet {
...
Class? extends PortletPresentation portletClass();
...
}
Then I've defined a component using this annotation :
@Component
@Portlet(..., portletClass=DummyComponentPortletImpl.class)
public class DummyComponentImpl {
...
}
The problem is that the metadata computed by the manipulator doesn't hold the
right value for the portletClass attribute :
I got Lfr/liglab/adele/icasa/portal/impl/test/DummyComponentPortletImpl;
instead of fr.liglab.adele.icasa.portal.impl.test.DummyComponentPortletImpl.
Despite it is still possible to deduce the original class name from this
strange string, isn't the attribute value supposed to contain the real class
name instead of a Java internal type name ?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2686) iPOJO external handlers should have consistent namespaces
[ https://issues.apache.org/jira/browse/FELIX-2686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Bourret updated FELIX-2686: -- Attachment: changed-eventadmin-handler-namespace.patch.gz Here is the patch for the eventadmin handler... The new namespace no longer uses the deprecated 'Publisher' annotation and XML element (changed to 'Publishes', see FELIX-2621) iPOJO external handlers should have consistent namespaces - Key: FELIX-2686 URL: https://issues.apache.org/jira/browse/FELIX-2686 Project: Felix Issue Type: Improvement Components: iPOJO Affects Versions: iPOJO-1.6.0 Reporter: Pierre Bourret Priority: Trivial Attachments: changed-eventadmin-handler-namespace.patch.gz, changed-jmx-handler-namespace-2.patch.gz The iPOJO external handlers have different namespaces, and it's confusing. These namespaces must be changed in order to have a coherent naming convention. Nevertheless, backward compatibility must be kept, so existing components can still be used with new versions of handlers -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2686) iPOJO external handlers should have consistent namespaces
[ https://issues.apache.org/jira/browse/FELIX-2686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Bourret updated FELIX-2686: -- Attachment: changed-extender-handler-namespace.patch.gz Patch for the extender pattern handler. iPOJO external handlers should have consistent namespaces - Key: FELIX-2686 URL: https://issues.apache.org/jira/browse/FELIX-2686 Project: Felix Issue Type: Improvement Components: iPOJO Affects Versions: iPOJO-1.6.0 Reporter: Pierre Bourret Priority: Trivial Attachments: changed-eventadmin-handler-namespace.patch.gz, changed-extender-handler-namespace.patch.gz, changed-jmx-handler-namespace-2.patch.gz The iPOJO external handlers have different namespaces, and it's confusing. These namespaces must be changed in order to have a coherent naming convention. Nevertheless, backward compatibility must be kept, so existing components can still be used with new versions of handlers -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2686) iPOJO external handlers should have consistent namespaces
[ https://issues.apache.org/jira/browse/FELIX-2686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Bourret updated FELIX-2686: -- Attachment: changed-jmx-handler-namespace-2.patch.gz There is a bug in the patch for the JMX handler : the old syntax is not accepted any more by the handler. I have corrected this bug and added a test case to check the old syntax compatibility. This new patch fixes the problem. I'm naughty... All apologies ! iPOJO external handlers should have consistent namespaces - Key: FELIX-2686 URL: https://issues.apache.org/jira/browse/FELIX-2686 Project: Felix Issue Type: Improvement Components: iPOJO Affects Versions: iPOJO-1.6.0 Reporter: Pierre Bourret Priority: Trivial Fix For: iPOJO-1.8.0 Attachments: changed-jmx-handler-namespace-2.patch.gz, changed-jmx-handler-namespace.patch.gz The iPOJO external handlers have different namespaces, and it's confusing. These namespaces must be changed in order to have a coherent naming convention. Nevertheless, backward compatibility must be kept, so existing components can still be used with new versions of handlers -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2686) iPOJO external handlers should have consistent namespaces
[ https://issues.apache.org/jira/browse/FELIX-2686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Bourret updated FELIX-2686: -- Attachment: (was: changed-jmx-handler-namespace.patch.gz) iPOJO external handlers should have consistent namespaces - Key: FELIX-2686 URL: https://issues.apache.org/jira/browse/FELIX-2686 Project: Felix Issue Type: Improvement Components: iPOJO Affects Versions: iPOJO-1.6.0 Reporter: Pierre Bourret Priority: Trivial Fix For: iPOJO-1.8.0 Attachments: changed-jmx-handler-namespace-2.patch.gz The iPOJO external handlers have different namespaces, and it's confusing. These namespaces must be changed in order to have a coherent naming convention. Nevertheless, backward compatibility must be kept, so existing components can still be used with new versions of handlers -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2686) iPOJO external handlers should have consistent namespaces
[ https://issues.apache.org/jira/browse/FELIX-2686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Bourret updated FELIX-2686: -- Attachment: changed-jmx-handler-namespace.patch.gz Here is the patch for the JMX handler ! (very little refactoring of the code also) Be careful that some annotations have been moved. Here is the trace of the changes : D annotations/src/main/java/org/apache/felix/ipojo/handlers/jmx/JMXMethod.java D annotations/src/main/java/org/apache/felix/ipojo/handlers/jmx/JMXProperty.java D annotations/src/main/java/org/apache/felix/ipojo/handlers/jmx/JMXBean.java A annotations/src/main/java/org/apache/felix/ipojo/handler/jmx A annotations/src/main/java/org/apache/felix/ipojo/handler/jmx/JMXMethod.java A annotations/src/main/java/org/apache/felix/ipojo/handler/jmx/JMXProperty.java A annotations/src/main/java/org/apache/felix/ipojo/handler/jmx/JMXBean.java M annotations/pom.xml M tests/handler/jmx/src/main/java/org/apache/felix/ipojo/test/component/SimpleManagedComponentAnnotated.java M tests/handler/jmx/src/main/java/org/apache/felix/ipojo/test/MBeanTests.java M tests/handler/jmx/src/main/resources/metadata.xml M handler/jmx/metadata.xml M handler/jmx/src/main/java/org/apache/felix/ipojo/handlers/jmx/MBeanHandler.java iPOJO external handlers should have consistent namespaces - Key: FELIX-2686 URL: https://issues.apache.org/jira/browse/FELIX-2686 Project: Felix Issue Type: Improvement Components: iPOJO Affects Versions: iPOJO-1.6.0 Reporter: Pierre Bourret Priority: Trivial Fix For: iPOJO-1.8.0 Attachments: changed-jmx-handler-namespace.patch.gz The iPOJO external handlers have different namespaces, and it's confusing. These namespaces must be changed in order to have a coherent naming convention. Nevertheless, backward compatibility must be kept, so existing components can still be used with new versions of handlers -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2686) iPOJO external handlers should have consistent namespaces
iPOJO external handlers should have consistent namespaces - Key: FELIX-2686 URL: https://issues.apache.org/jira/browse/FELIX-2686 Project: Felix Issue Type: Improvement Components: iPOJO Affects Versions: iPOJO-1.6.0 Reporter: Pierre Bourret Priority: Trivial Fix For: iPOJO-1.8.0 The iPOJO external handlers have different namespaces, and it's confusing. These namespaces must be changed in order to have a coherent naming convention. Nevertheless, backward compatibility must be kept, so existing components can still be used with new versions of handlers -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2686) iPOJO external handlers should have consistent namespaces
[ https://issues.apache.org/jira/browse/FELIX-2686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12928202#action_12928202 ] Pierre Bourret commented on FELIX-2686: --- Here is a list of the current handlers namespaces : (NOW) - org.apache.felix.ipojo.whiteboard (iPOJO Whiteboard pattern handler 1.4.0) - org.apache.felix.ipojo.extender (iPOJO Extender pattern handler 1.4.0 ) - org.apache.felix.ipojo.handlers.jmx (iPOJO JMX handler 1.4.0) - org.apache.felix.ipojo.handlers.event (iPOJO Event Admin handler 1.6.0) - org.apache.felix.ipojo.handler.temporal(iPOJO Temporal Dependency handler 1.6.0) The idea is to use the same namespace prefix for these handlers : org.apache.felix.ipojo.handler. . (PROPOSITION) - org.apache.felix.ipojo.handler.whiteboard - org.apache.felix.ipojo.handler.extender - org.apache.felix.ipojo.handler.jmx - org.apache.felix.ipojo.handler.event - org.apache.felix.ipojo.handler.temporal iPOJO external handlers should have consistent namespaces - Key: FELIX-2686 URL: https://issues.apache.org/jira/browse/FELIX-2686 Project: Felix Issue Type: Improvement Components: iPOJO Affects Versions: iPOJO-1.6.0 Reporter: Pierre Bourret Priority: Trivial Fix For: iPOJO-1.8.0 The iPOJO external handlers have different namespaces, and it's confusing. These namespaces must be changed in order to have a coherent naming convention. Nevertheless, backward compatibility must be kept, so existing components can still be used with new versions of handlers -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2392) Felix framework uses a Java5 method
Felix framework uses a Java5 method
---
Key: FELIX-2392
URL: https://issues.apache.org/jira/browse/FELIX-2392
Project: Felix
Issue Type: Bug
Components: Framework
Affects Versions: framework-2.0.5
Environment: Linux Ubuntu i386, OpenMika VM 1.4.6
Reporter: Pierre Bourret
The Felix framework uses the String.contains(CharSequence) method that is part
of the OSGi minimum EE. This result in a failure when launching Felix in Java
1.4 and lower EE (such as Mika).
org.apache.felix.framework.Felix.java:3699
if (toRet.contains(${pom))
should, by example, be replaced by
if (toRet.indexOf(${pom) = 0)
(sorry, no patch quickly available ;)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2392) Felix framework uses a Java5 method
[
https://issues.apache.org/jira/browse/FELIX-2392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Bourret updated FELIX-2392:
--
Description:
The Felix framework uses the String.contains(CharSequence) method that is NOT
part of the OSGi minimum EE. This result in a failure when launching Felix in
Java 1.4 and lower EE (such as Mika).
org.apache.felix.framework.Felix.java:3699
if (toRet.contains(${pom))
should, by example, be replaced by
if (toRet.indexOf(${pom) = 0)
(sorry, no patch quickly available ;)
was:
The Felix framework uses the String.contains(CharSequence) method that is part
of the OSGi minimum EE. This result in a failure when launching Felix in Java
1.4 and lower EE (such as Mika).
org.apache.felix.framework.Felix.java:3699
if (toRet.contains(${pom))
should, by example, be replaced by
if (toRet.indexOf(${pom) = 0)
(sorry, no patch quickly available ;)
Felix framework uses a Java5 method
---
Key: FELIX-2392
URL: https://issues.apache.org/jira/browse/FELIX-2392
Project: Felix
Issue Type: Bug
Components: Framework
Affects Versions: framework-2.0.5
Environment: Linux Ubuntu i386, OpenMika VM 1.4.6
Reporter: Pierre Bourret
Original Estimate: 0.08h
Remaining Estimate: 0.08h
The Felix framework uses the String.contains(CharSequence) method that is NOT
part of the OSGi minimum EE. This result in a failure when launching Felix in
Java 1.4 and lower EE (such as Mika).
org.apache.felix.framework.Felix.java:3699
if (toRet.contains(${pom))
should, by example, be replaced by
if (toRet.indexOf(${pom) = 0)
(sorry, no patch quickly available ;)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2392) Felix framework uses a Java5 method
[ https://issues.apache.org/jira/browse/FELIX-2392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12875627#action_12875627 ] Pierre Bourret commented on FELIX-2392: --- I've tested the snapshot version of Felix ; it seems that the provided bundle-repository and Gogo shell both uses non-OSGi Minimum methods, so it crashes too (see the trace hereafter). But when removing/replacing them by the classic shell, it works ! The framework itself can run on OSGi/Minimum EE, but the main distribution (the one i've tested) now requires higher EE. Should a new issue be created ? Closing this one as errors are no more related to the framework. Stack trace provided for informational puposes only -- using snapshot org.apache.felix.main.distribution-2.1.0-20100531-22-3 ERROR: Error starting file:/home/bourretp/Projects/Experiments/felix-framework-2.1.0-SNAPSHOT/bundle/org.apache.felix.bundlerepository-1.6.2.jar (org.osgi.framework.BundleException: Activator start error in bundle org.apache.felix.bundlerepository [1].) java.lang.ExceptionInInitializerError at org.apache.felix.bundlerepository.impl.DataModelHelperImpl.getVersion(DataModelHelperImpl.java:878) at org.apache.felix.bundlerepository.impl.DataModelHelperImpl.populate(DataModelHelperImpl.java:520) at org.apache.felix.bundlerepository.impl.LocalResourceImpl.initialize(LocalResourceImpl.java:55) at org.apache.felix.bundlerepository.impl.LocalResourceImpl.init(LocalResourceImpl.java:38) at org.apache.felix.bundlerepository.impl.SystemRepositoryImpl.init(SystemRepositoryImpl.java:40) at org.apache.felix.bundlerepository.impl.RepositoryAdminImpl.init(RepositoryAdminImpl.java:67) at org.apache.felix.bundlerepository.impl.Activator.start(Activator.java:70) at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:633) at org.apache.felix.framework.Felix.activateBundle(Felix.java:1828) at org.apache.felix.framework.Felix.startBundle(Felix.java:1750) at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1168) at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264) Caused by: java.lang.ClassNotFoundException: SystemClassLoader couldn't find java.util.regex.Pattern at wonka.vm.SystemClassLoader.findClass(SystemClassLoader.java:220) at wonka.vm.SystemClassLoader.loadClass(SystemClassLoader.java:373) at java.lang.ClassLoader.loadClass(ClassLoader.java:255) at java.lang.ClassLoader.loadClass(ClassLoader.java:255) at org.apache.felix.utils.version.VersionCleaner.clinit(VersionCleaner.java:29) at org.apache.felix.utils.version.VersionCleaner.clinit(VersionCleaner.java:29) at org.apache.felix.bundlerepository.impl.DataModelHelperImpl.getVersion(DataModelHelperImpl.java:878) at org.apache.felix.bundlerepository.impl.DataModelHelperImpl.populate(DataModelHelperImpl.java:520) at org.apache.felix.bundlerepository.impl.LocalResourceImpl.initialize(LocalResourceImpl.java:55) at org.apache.felix.bundlerepository.impl.LocalResourceImpl.init(LocalResourceImpl.java:38) at org.apache.felix.bundlerepository.impl.SystemRepositoryImpl.init(SystemRepositoryImpl.java:40) at org.apache.felix.bundlerepository.impl.RepositoryAdminImpl.init(RepositoryAdminImpl.java:67) at org.apache.felix.bundlerepository.impl.Activator.start(Activator.java:70) at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:633) at org.apache.felix.framework.Felix.activateBundle(Felix.java:1828) at org.apache.felix.framework.Felix.startBundle(Felix.java:1750) at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1168) at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264) ERROR: Error starting file:/home/bourretp/Projects/Experiments/felix-framework-2.1.0-SNAPSHOT/bundle/org.apache.felix.gogo.runtime-0.5.0-SNAPSHOT.jar (org.osgi.framework.BundleException: Activator start error in bundle org.apache.felix.gogo.runtime [3].) java.lang.ExceptionInInitializerError at org.apache.felix.gogo.runtime.activator.Activator.start(Activator.java:55) at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:633) at org.apache.felix.framework.Felix.activateBundle(Felix.java:1828) at org.apache.felix.framework.Felix.startBundle(Felix.java:1750) at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1168) at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264) Caused by: java.lang.NullPointerException at java.lang.Class.desiredAssertionStatus(Class.java:764) at
[jira] Closed: (FELIX-2392) Felix framework uses a Java5 method
[
https://issues.apache.org/jira/browse/FELIX-2392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Bourret closed FELIX-2392.
-
Tested ! OK
Felix framework uses a Java5 method
---
Key: FELIX-2392
URL: https://issues.apache.org/jira/browse/FELIX-2392
Project: Felix
Issue Type: Bug
Components: Framework
Affects Versions: framework-2.0.5
Environment: Linux Ubuntu i386, OpenMika VM 1.4.6
Reporter: Pierre Bourret
Assignee: Richard S. Hall
Priority: Minor
Fix For: framework-3.0.0
Original Estimate: 0.08h
Remaining Estimate: 0.08h
The Felix framework uses the String.contains(CharSequence) method that is NOT
part of the OSGi minimum EE. This result in a failure when launching Felix in
Java 1.4 and lower EE (such as Mika).
org.apache.felix.framework.Felix.java:3699
if (toRet.contains(${pom))
should, by example, be replaced by
if (toRet.indexOf(${pom) = 0)
(sorry, no patch quickly available ;)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2392) Felix framework uses a Java5 method
[
https://issues.apache.org/jira/browse/FELIX-2392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12875690#action_12875690
]
Pierre Bourret commented on FELIX-2392:
---
The Pattern class is available is the JRE/JDK 1.4, but is neither in the OSGi
minimum EE not in the OSGi foundation profile (both based, AFAIK, on Java 1.3).
The VM I use only provides one of these two EE (I don't know exactly which one
;) and so fails to load the bundle repository bundle.
So the bundle repository do not use Java5, but it needs more than a standard
OSGi EE. As it limits its use on limited/embedded platforms, I think an
(minor;) issue should be opened for it, but it's only a suggestion...
Felix framework uses a Java5 method
---
Key: FELIX-2392
URL: https://issues.apache.org/jira/browse/FELIX-2392
Project: Felix
Issue Type: Bug
Components: Framework
Affects Versions: framework-2.0.5
Environment: Linux Ubuntu i386, OpenMika VM 1.4.6
Reporter: Pierre Bourret
Assignee: Richard S. Hall
Priority: Minor
Fix For: framework-3.0.0
Original Estimate: 0.08h
Remaining Estimate: 0.08h
The Felix framework uses the String.contains(CharSequence) method that is NOT
part of the OSGi minimum EE. This result in a failure when launching Felix in
Java 1.4 and lower EE (such as Mika).
org.apache.felix.framework.Felix.java:3699
if (toRet.contains(${pom))
should, by example, be replaced by
if (toRet.indexOf(${pom) = 0)
(sorry, no patch quickly available ;)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1985) Whitespace sensitivity in the Include-Resource instruction.
Whitespace sensitivity in the Include-Resource instruction.
---
Key: FELIX-1985
URL: https://issues.apache.org/jira/browse/FELIX-1985
Project: Felix
Issue Type: Bug
Components: Maven Bundle Plugin
Affects Versions: maven-bundle-plugin-2.0.1
Environment: Linux quartz 2.6.31-17-generic #54-Ubuntu SMP Thu Dec 10
17:01:44 UTC 2009 x86_64 GNU/Linux
Reporter: Pierre Bourret
Priority: Minor
With the following maven-bundle-plugin configuration :
plugin
groupIdorg.apache.felix/groupId
artifactIdmaven-bundle-plugin/artifactId
version2.0.1/version
extensionstrue/extensions
configuration
instructions
...
Include-Resource
{maven-resources},
META-INF/LICENSE=LICENSE,
META-INF/NOTICE=NOTICE
/Include-Resource
/instructions
/configuration
/plugin
I get these errors :
[ERROR] Error building bundle
org.ow2.chameleon.handies:org.ow2.chameleon.handies.ipojo-tccl-handler:bundle:0.0.1-SNAPSHOT
: Input file does not exist: LICENSE~
[ERROR] Error building bundle
org.ow2.chameleon.handies:org.ow2.chameleon.handies.ipojo-tccl-handler:bundle:0.0.1-SNAPSHOT
: Input file does not exist: NOTICE~
[ERROR] Error(s) found in bundle configuration
(Note the trailing '~' at the end of the real file names)
But when I insert whitespaces around the '=' symbol (either before or after
it), it works : neither error nor warning.
Include-Resource
{maven-resources},
META-INF/LICENSE =LICENSE,
META-INF/NOTICE= NOTICE
/Include-Resource
[INFO] BUILD SUCCESSFUL
The first configuration (the one without spaces around '=') works with the
1.4.3 version of the maven-bundle-plugin.
Is this a regression ? Or maybe the syntax of the Include-Resource instruction
has changed since the 1.4.3 version (may it affect other instruction too ?).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1985) Whitespace sensitivity in the Include-Resource instruction.
[
https://issues.apache.org/jira/browse/FELIX-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12799806#action_12799806
]
Pierre Bourret commented on FELIX-1985:
---
First, thanks for reacting so fast !
I have run maven with the -X flag and have noticed that the LICENSE and NOTICE
files are included twice. After checking again the pom hierarchy, I've found
that the parent pom of my project already contains resource instructions to
add LICENSE and NOTICE in the project resources. So the entries in the
bundle-plugin configuration are redundant. You're right !
It was my fault... Sorry to report a non-issue. I'm going to close this
immediately...
Whitespace sensitivity in the Include-Resource instruction.
---
Key: FELIX-1985
URL: https://issues.apache.org/jira/browse/FELIX-1985
Project: Felix
Issue Type: Bug
Components: Maven Bundle Plugin
Affects Versions: maven-bundle-plugin-2.0.1
Environment: Linux quartz 2.6.31-17-generic #54-Ubuntu SMP Thu Dec 10
17:01:44 UTC 2009 x86_64 GNU/Linux
Reporter: Pierre Bourret
Priority: Minor
With the following maven-bundle-plugin configuration :
plugin
groupIdorg.apache.felix/groupId
artifactIdmaven-bundle-plugin/artifactId
version2.0.1/version
extensionstrue/extensions
configuration
instructions
...
Include-Resource
{maven-resources},
META-INF/LICENSE=LICENSE,
META-INF/NOTICE=NOTICE
/Include-Resource
/instructions
/configuration
/plugin
I get these errors :
[ERROR] Error building bundle
org.ow2.chameleon.handies:org.ow2.chameleon.handies.ipojo-tccl-handler:bundle:0.0.1-SNAPSHOT
: Input file does not exist: LICENSE~
[ERROR] Error building bundle
org.ow2.chameleon.handies:org.ow2.chameleon.handies.ipojo-tccl-handler:bundle:0.0.1-SNAPSHOT
: Input file does not exist: NOTICE~
[ERROR] Error(s) found in bundle configuration
(Note the trailing '~' at the end of the real file names)
But when I insert whitespaces around the '=' symbol (either before or after
it), it works : neither error nor warning.
Include-Resource
{maven-resources},
META-INF/LICENSE =LICENSE,
META-INF/NOTICE= NOTICE
/Include-Resource
[INFO] BUILD SUCCESSFUL
The first configuration (the one without spaces around '=') works with the
1.4.3 version of the maven-bundle-plugin.
Is this a regression ? Or maybe the syntax of the Include-Resource
instruction has changed since the 1.4.3 version (may it affect other
instruction too ?).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1938) Bad error message when an Event Subscriber does not set the data type and data key
[
https://issues.apache.org/jira/browse/FELIX-1938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12789394#action_12789394
]
Pierre Bourret commented on FELIX-1938:
---
Right ! The subscriber configuration parser do not check that if the data-type
attribute is provided, the data-key attribute is set. The handler consider that
a subscriber configured in this manner is not a data-subscriber beacause the
data-key is not set, and so try to find the classical event callback (the one
that receive org.osgi.service.event.Event).
The attached patch should fix this. Because of a lack of time, it has not been
tested, so please send feedback :)
Bad error message when an Event Subscriber does not set the data type and
data key
--
Key: FELIX-1938
URL: https://issues.apache.org/jira/browse/FELIX-1938
Project: Felix
Issue Type: Bug
Components: iPOJO
Affects Versions: iPOJO-1.4.0
Reporter: Clement Escoffier
The event admin handler should do a better job in reporting error. Especially
the following subscriber (missing the data_key attribute):
@Subscriber(name = tdmEventSubscriber-1, topics = tdmEventTopic,
data_type = java.lang.String)
public void receive(String msg) {
System.out.println([DATA RECEIVER] Receive event on tdmEventTopic :
+ msg);
}
will throw this exception:
- [ERROR] de.akquinet.gomobile.ea.test.SubscriberTest : Cannot find callback
method receive(org.osgi.service.event.Event)
[ERROR] IPOJO-Extender : An error occurs when analyzing the content or
starting the management of 17
java.lang.IllegalStateException: Cannot find callback method
receive(org.osgi.service.event.Event)
at
org.apache.felix.ipojo.IPojoFactory.computeDescription(IPojoFactory.java:673)
at
org.apache.felix.ipojo.IPojoFactory.computeFactoryState(IPojoFactory.java:700)
at
org.apache.felix.ipojo.ComponentFactory.addedService(ComponentFactory.java:358)
at
org.apache.felix.ipojo.util.Tracker$Tracked.trackAdding(Tracker.java:709)
at
org.apache.felix.ipojo.util.Tracker$Tracked.trackInitialServices(Tracker.java:595)
at org.apache.felix.ipojo.util.Tracker.open(Tracker.java:203)
at
org.apache.felix.ipojo.ComponentFactory.starting(ComponentFactory.java:235)
at org.apache.felix.ipojo.IPojoFactory.start(IPojoFactory.java:574)
at
org.apache.felix.ipojo.Extender.createAbstractFactory(Extender.java:426)
at org.apache.felix.ipojo.Extender.parse(Extender.java:264)
at org.apache.felix.ipojo.Extender.startManagementFor(Extender.java:208)
at org.apache.felix.ipojo.Extender.access$600(Extender.java:52)
at org.apache.felix.ipojo.Extender$CreatorThread.run(Extender.java:669)
at java.lang.Thread.run(Thread.java:637)
The handler has detected a problem but try to use a wrong method
(receiver(Event) instead of reporting the bad configuration and rejecting it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1938) Bad error message when an Event Subscriber does not set the data type and data key
[
https://issues.apache.org/jira/browse/FELIX-1938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Bourret updated FELIX-1938:
--
Attachment: checkMissingDataKeyAttribute.diff
The patch that checks the presence of the data-key attribute when the data-type
attribute is provided.
Bad error message when an Event Subscriber does not set the data type and
data key
--
Key: FELIX-1938
URL: https://issues.apache.org/jira/browse/FELIX-1938
Project: Felix
Issue Type: Bug
Components: iPOJO
Affects Versions: iPOJO-1.4.0
Reporter: Clement Escoffier
Attachments: checkMissingDataKeyAttribute.diff
The event admin handler should do a better job in reporting error. Especially
the following subscriber (missing the data_key attribute):
@Subscriber(name = tdmEventSubscriber-1, topics = tdmEventTopic,
data_type = java.lang.String)
public void receive(String msg) {
System.out.println([DATA RECEIVER] Receive event on tdmEventTopic :
+ msg);
}
will throw this exception:
- [ERROR] de.akquinet.gomobile.ea.test.SubscriberTest : Cannot find callback
method receive(org.osgi.service.event.Event)
[ERROR] IPOJO-Extender : An error occurs when analyzing the content or
starting the management of 17
java.lang.IllegalStateException: Cannot find callback method
receive(org.osgi.service.event.Event)
at
org.apache.felix.ipojo.IPojoFactory.computeDescription(IPojoFactory.java:673)
at
org.apache.felix.ipojo.IPojoFactory.computeFactoryState(IPojoFactory.java:700)
at
org.apache.felix.ipojo.ComponentFactory.addedService(ComponentFactory.java:358)
at
org.apache.felix.ipojo.util.Tracker$Tracked.trackAdding(Tracker.java:709)
at
org.apache.felix.ipojo.util.Tracker$Tracked.trackInitialServices(Tracker.java:595)
at org.apache.felix.ipojo.util.Tracker.open(Tracker.java:203)
at
org.apache.felix.ipojo.ComponentFactory.starting(ComponentFactory.java:235)
at org.apache.felix.ipojo.IPojoFactory.start(IPojoFactory.java:574)
at
org.apache.felix.ipojo.Extender.createAbstractFactory(Extender.java:426)
at org.apache.felix.ipojo.Extender.parse(Extender.java:264)
at org.apache.felix.ipojo.Extender.startManagementFor(Extender.java:208)
at org.apache.felix.ipojo.Extender.access$600(Extender.java:52)
at org.apache.felix.ipojo.Extender$CreatorThread.run(Extender.java:669)
at java.lang.Thread.run(Thread.java:637)
The handler has detected a problem but try to use a wrong method
(receiver(Event) instead of reporting the bad configuration and rejecting it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1839) iPOJO Strange Bundle-SymbolicName: org.apache.felix.org.apache.felix.ipojo.annotations
[ https://issues.apache.org/jira/browse/FELIX-1839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12773125#action_12773125 ] Pierre Bourret commented on FELIX-1839: --- Duplicate of FELIX-1557 iPOJO Strange Bundle-SymbolicName: org.apache.felix.org.apache.felix.ipojo.annotations -- Key: FELIX-1839 URL: https://issues.apache.org/jira/browse/FELIX-1839 Project: Felix Issue Type: Bug Affects Versions: iPOJO-1.4.0 Reporter: Kai Toedter Priority: Minor The current Bundle-SymbolicName of the annotations bundle is org.apache.felix.org.apache.felix.ipojo.annotations. Change it to org.apache.felix.ipojo.annotations -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1840) iPOJO Create Eclipse Sample Project MyiPOJOBundle.zip with iPOJO 1.4.0
[ https://issues.apache.org/jira/browse/FELIX-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12773122#action_12773122 ] Pierre Bourret commented on FELIX-1840: --- Fixed. The new MyiPOJOBundle.zip now uses iPOJO 1.4 (core, api, annotations, composites) and the iPOJO Ant plugin 1.4.2. This file should be available tomorrow... iPOJO Create Eclipse Sample Project MyiPOJOBundle.zip with iPOJO 1.4.0 -- Key: FELIX-1840 URL: https://issues.apache.org/jira/browse/FELIX-1840 Project: Felix Issue Type: Bug Affects Versions: iPOJO-1.4.0 Reporter: Kai Toedter At http://felix.apache.org/site/apache-felix-ipojo-eclipse-integration.html you can download http://felix.apache.org/site/apache-felix-ipojo-eclipse-integration.data/MyiPOJOBundle.zip. This sample is still based on iPOJO 1.2.0. Please update to 1.4.0 and integrate the new Eclipse feature: The 1.4.0+ iPOJO manipulator allows manipulating classes from a directory (FELIX-943). This feature is very convenient for the Eclipse integration because it avoids creating the Jar and unzipping it inside the Eclipse build directory. Moreover, it allows reusing the Java Eclipse builder (compiling classes). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1557) Cosmetic change of the Bundle-Name and Bundle-SymbolicName in iPOJO annotations.
Cosmetic change of the Bundle-Name and Bundle-SymbolicName in iPOJO annotations. Key: FELIX-1557 URL: https://issues.apache.org/jira/browse/FELIX-1557 Project: Felix Issue Type: Bug Components: iPOJO Affects Versions: iPOJO-1.4.0 Environment: all Reporter: Pierre Bourret Priority: Trivial Fix For: iPOJO-1.6.0 The iPOJO Annotations bundle suffer from tiny inconsistencies in its header : *) The Bundle-SymbolicName is org.apache.felix.org.apache.felix.ipojo.annotations but should be org.apache.felix.ipojo.annotations. *) The Bundle-Name is iPOJO Annotations but should be Apache Felix iPOJO Annotations. Fixing this issue may also impact OBR dependency resolution (capability changes). -- TRACE OF iPOJO BUNDLES LIST -- - ps -s ... [ 6] [Active ] [1] org.apache.felix.ipojo (1.4.0) [ 7] [Active ] [1] org.apache.felix.org.apache.felix.ipojo.annotations (1.4.0) [ 8] [Active ] [1] org.apache.felix.ipojo.composite (1.4.0) [ 9] [Active ] [1] org.apache.felix.ipojo.handler.extender (1.4.0) ... - ps ... [ 6] [Active ] [1] Apache Felix iPOJO (1.4.0) [ 7] [Active ] [1] iPOJO Annotations (1.4.0) [ 8] [Active ] [1] Apache Felix iPOJO Composite (1.4.0) [ 9] [Active ] [1] Apache Felix iPOJO Extender Pattern Handler (1.4.0) ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (FELIX-1302) Manipulator never ignore annotations
[ https://issues.apache.org/jira/browse/FELIX-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12728600#action_12728600 ] Pierre Bourret edited comment on FELIX-1302 at 7/8/09 3:24 AM: --- The behaviour of the corrected manipulator has been tested and approved. Closing issue... was (Author: pierre.bourret): The behaviour of the corrected manipulator have been tested and approved. Closing issue... Manipulator never ignore annotations Key: FELIX-1302 URL: https://issues.apache.org/jira/browse/FELIX-1302 Project: Felix Issue Type: Bug Components: iPOJO Affects Versions: iPOJO-1.2.0 Environment: All Reporter: Pierre Bourret Priority: Minor Fix For: iPOJO-1.4.0 Original Estimate: 0h Remaining Estimate: 0h The manipulator seems to always process annotations, even when the user explicitly indicate to ignore them (via the iPOJO ant or maven plugin). The org.apache.felix.ipojo.manipulator.Pojoization class has a private m_ignoreAnnotations boolean field, that is initialized to false (Java default value). The only method that modify this field is setAnnotationProcessing, that takes no parameters and set (unthinking) the field to false. This method should take a boolean parameter indicating if the annotations must be processed or ignored. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1302) Manipulator never ignore annotations
[ https://issues.apache.org/jira/browse/FELIX-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Bourret closed FELIX-1302. - The behaviour of the corrected manipulator have been tested and approved. Closing issue... Manipulator never ignore annotations Key: FELIX-1302 URL: https://issues.apache.org/jira/browse/FELIX-1302 Project: Felix Issue Type: Bug Components: iPOJO Affects Versions: iPOJO-1.2.0 Environment: All Reporter: Pierre Bourret Priority: Minor Fix For: iPOJO-1.4.0 Original Estimate: 0h Remaining Estimate: 0h The manipulator seems to always process annotations, even when the user explicitly indicate to ignore them (via the iPOJO ant or maven plugin). The org.apache.felix.ipojo.manipulator.Pojoization class has a private m_ignoreAnnotations boolean field, that is initialized to false (Java default value). The only method that modify this field is setAnnotationProcessing, that takes no parameters and set (unthinking) the field to false. This method should take a boolean parameter indicating if the annotations must be processed or ignored. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1302) Manipulator never ignore annotations
Manipulator never ignore annotations Key: FELIX-1302 URL: https://issues.apache.org/jira/browse/FELIX-1302 Project: Felix Issue Type: Bug Components: iPOJO Affects Versions: iPOJO-1.2.0 Environment: All Reporter: Pierre Bourret Priority: Minor The manipulator seems to always process annotations, even when the user explicitly indicate to ignore them (via the iPOJO ant or maven plugin). The org.apache.felix.ipojo.manipulator.Pojoization class has a private m_ignoreAnnotations boolean field, that is initialized to false (Java default value). The only method that modify this field is setAnnotationProcessing, that takes no parameters and set (unthinking) the field to false. This method should take a boolean parameter indicating if the annotations must be processed or ignored. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1183) iPOJO JMX handler doesn't rethrow exceptions
[ https://issues.apache.org/jira/browse/FELIX-1183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Bourret updated FELIX-1183: -- Attachment: JMX-handler-rethrow-exceptions.patch The invoke method displays the exceptions on the gateway. According to the JMX API, it must wrap the called method exception in a MBeanException, and re-throw it, in order to advise the caller. As the InvocationTargetException (thrown from the Callback.call() method) wraps a Throwable, not an Exception, it is directly wrapped in the MBeanException. So if the method throws an exception e , here is the exceptions chain received by the caller : MBeanException ... Caused by : InvocationTargetException ... Caused by : e Any reflection exception while trying to invoke the method will result in a ReflectionException (wrapping the cause). The patch should follow very shortly. Thx to the reporter for identifying the source of this issue so fast... iPOJO JMX handler doesn't rethrow exceptions - Key: FELIX-1183 URL: https://issues.apache.org/jira/browse/FELIX-1183 Project: Felix Issue Type: Bug Components: iPOJO Affects Versions: iPOJO-1.4.0 Environment: SNAPSHOT version, SVN revision 37639 Reporter: S. Ali Tokmen Attachments: JMX-handler-rethrow-exceptions.patch When we create an MBean with iPOJO (metadata-based dynamic MBean), if any method invoke throws an exception, the exception is not rethrown to the caller. Instead, the exception's stack trace is printed back on the OSGi gateway's system.out and the JMX caller gets a null return. Normally, we expect the JMX call to throw an exception if the MBean has thrown one. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-898) iPOJO Eclipse plugin is not installable with 3.4.1
[ https://issues.apache.org/jira/browse/FELIX-898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12666598#action_12666598 ] Pierre Bourret commented on FELIX-898: -- I've installed the iPOJO Eclipse plugin 1.0.0 on of Eclipse 3.4.1 without experiencing any problem. I cannot replay your issue. I checked the version of your involved plugin (org.eclipse.ltk.core.refactoring) and the version your talking about [3.5.0.v20081209-0100] is higher than mine [3.4.1.r341_v20080716-0800]. The plugin seems to work perfectly. Maybe you could send me your Eclipse version/configuration so I can try to reproduce the problem. P.S. : There are some posts on the Eclipse EMF forum for the same missing dependency (exactly the same version) on the latest EMF CDO pre-release version (2.0.0M4). Maybe you have an (unexplained) indirect dependency on this plugin. iPOJO Eclipse plugin is not installable with 3.4.1 -- Key: FELIX-898 URL: https://issues.apache.org/jira/browse/FELIX-898 Project: Felix Issue Type: Bug Components: iPOJO Affects Versions: iPOJO-1.0.0 Reporter: Kai Toedter When you try to install the Ec lipse Plugin, a dependency to the language toolkit could not be resolved, error message: Cannot find a solution satisfying the following requirements org.eclipse.ltk.core.refactoring [3.5.0.v20081209-0100]. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
