Re: modelling gogo command descriptions

[David Jencks]

I think a json or text based approach is essential.  It’s been a while but as I 
recall in DS with annotated commands, I could not find any way to make the 
information from the annotations available to gogo if DS started before gogo; 
once the command class was loaded without the gogo annotations there was no way 
to go back and get the annotations.  Perhaps someone has solved this problem 
since, but any code complexity around this is silly.

david jencks

> On Oct 21, 2018, at 11:55 PM, Raymond Auge  wrote:
> 
> On Mon, Oct 22, 2018 at 8:47 AM Guillaume Nodet  > wrote:
> 
>> Afaik, gogo supports overriden methods, so you can have multiple methods
>> for a single command (for example the "cd" command).
>> I'm not sure that adding this metadata to the function name will be very
>> easy.
>> 
>> Maybe a possible way would be to have a json file containing the metadata
>> in a know location so that the "help" command could load them on demand and
>> have them generated by a maven plugin at build time ?
>> 
> 
> That sounds interesting! It does force gogo into having to fetch the bundle
> from the ServiceReference in order to fetch the resources, but I don't
> think that's a deal breaker.
> 
> Any other opinions?
> 
> - Ray
> 
> 
>> 
>> Le lun. 22 oct. 2018 à 05:59, Raymond Auge  a
>> écrit :
>> 
>>> Hey all,
>>> 
>>> In a recent conversation with Thomas Watson we touched on moving some
>>> commands into their implementation bundles. For instance, log commands
>>> should be in the log service impl, etc.
>>> 
>>> However we don't want to lose the @Descriptor & @Parameter features to
>>> describe the commands. On the other hand, we should not be coupled to the
>>> `org.apache.felix.service.command` package.
>>> 
>>> My first notion was to use Bundle annotations, but obviously those are
>> not
>>> visible at runtime when the command processor handles the commands.
>>> 
>>> Then I was thinking of encoding the information as either an additional
>>> service property on the command service. However the alignment,
>>> particularly, with the property `osgi.command.function`, which is an
>> array,
>>> makes this a little weird.
>>> 
>>> Then I thought maybe we could extend the encoding of
>>> `osgi.command.function` to use the OSGi package syntax which would
>> continue
>>> to make any existing values compatible (since they would be just keys,
>>> while allowing for additional "attributes", such as description and
>>> parameters to be added. It's certainly not perfect.
>>> 
>>> Anyone have thoughts on ways of encoding this?
>>> 
>>> --
>>> *Raymond Augé* 
>>> (@rotty3000)
>>> Senior Software Architect *Liferay, Inc.* 
>>> (@Liferay)
>>> Board Member & EEG Co-Chair, OSGi Alliance 
>>> (@OSGiAlliance)
>>> 
>> 
>> 
>> --
>> 
>> Guillaume Nodet
>> 
> 
> 
> -- 
> *Raymond Augé*  >
> (@rotty3000)
> Senior Software Architect *Liferay, Inc.*  >
> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance  > (@OSGiAlliance)

[jira] [Updated] (FELIX-5971) No warning should be emitted for Import-Packages pointing to javax.* being part of JRE

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated FELIX-5971:
---
Component/s: Tooling

> No warning should be emitted for Import-Packages pointing to javax.* being 
> part of JRE
> --
>
> Key: FELIX-5971
> URL: https://issues.apache.org/jira/browse/FELIX-5971
> Project: Felix
>  Issue Type: Bug
>  Components: Tooling
>Affects Versions: osgicheck-maven-plugin 0.1.0
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: osgicheck-maven-plugin 0.2.0
>
>
> E.g. when referencing some classes from 
> [https://docs.oracle.com/en/java/javase/11/docs/api/java.management/javax/management/package-summary.html,]
>  bnd generates an import-package statement towards this package without a 
> version range (as this packages is exported from the JRE itself). In this 
> case the warning should be prevented, as this is totally valid.
> For that we probably need to maintain a whitelist of packages being exposed 
> by the system bundle (0) from the underlying JRE



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (FELIX-5971) No warning should be emitted for Import-Packages pointing to javax.* being part of JRE

[Konrad Windszus (JIRA)]

Konrad Windszus created FELIX-5971:
--

 Summary: No warning should be emitted for Import-Packages pointing 
to javax.* being part of JRE
 Key: FELIX-5971
 URL: https://issues.apache.org/jira/browse/FELIX-5971
 Project: Felix
  Issue Type: Bug
Affects Versions: osgicheck-maven-plugin 0.1.0
Reporter: Konrad Windszus
 Fix For: osgicheck-maven-plugin 0.2.0


E.g. when referencing some classes from 
[https://docs.oracle.com/en/java/javase/11/docs/api/java.management/javax/management/package-summary.html,]
 bnd generates an import-package statement towards this package without a 
version range (as this packages is exported from the JRE itself). In this case 
the warning should be prevented, as this is totally valid.

For that we probably need to maintain a whitelist of packages being exposed by 
the system bundle (0) from the underlying JRE



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FELIX-5959) Exception on changecount timer timeout

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on FELIX-5959:
-

Ray just explained it to, this can basically happening if for example 
configuration admin starts sending out configuration events and down the change 
some receiver is shutting down configuration admin. In that case the thread has 
already the lock

> Exception on changecount timer timeout
> --
>
> Key: FELIX-5959
> URL: https://issues.apache.org/jira/browse/FELIX-5959
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Reporter: Raymond Augé
>Assignee: Raymond Augé
>Priority: Major
> Fix For: scr-2.1.12
>
>
> When running a large system with complex and deeply nested component graph, 
> the changecount timer can time out resulting in exceptions like:
> {code}
> [junit] java.lang.IllegalStateException: Timer already cancelled.
> [junit]   at java.util.Timer.sched(Timer.java:397)
> [junit]   at java.util.Timer.schedule(Timer.java:193)
> [junit]   at 
> org.apache.felix.scr.impl.ComponentRegistry.updateChangeCount(ComponentRegistry.java:722)
> [junit]   at 
> org.apache.felix.scr.impl.BundleComponentActivator.updateChangeCount(BundleComponentActivator.java:777)
> [junit]   at 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.setState(AbstractComponentManager.java:1420)
> [junit]   at 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:806)
> [junit]   at 
> org.apache.felix.scr.impl.manager.DependencyManager.deactivateComponentManager(DependencyManager.java:2330)
> [junit]   at 
> org.apache.felix.scr.impl.manager.DependencyManager.access$400(DependencyManager.java:56)
> [junit]   at 
> org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.removedService(DependencyManager.java:1125)
> [junit]   at 
> org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.removedService(DependencyManager.java:1007)
> [junit]   at 
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:1242)
> [junit]   at 
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:1137)
> [junit]   at 
> org.apache.felix.scr.impl.manager.ServiceTracker$AbstractTracked.untrack(ServiceTracker.java:997)
> [junit]   at 
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:1176)
> [junit]   at 
> org.apache.felix.scr.impl.BundleComponentActivator$ListenerInfo.serviceChanged(BundleComponentActivator.java:125)
> [junit]   at 
> org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:109)
> [junit]   at 
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:891)
> [junit]   at 
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:804)
> [junit]   at 
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:222)
> [junit]   at 
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.unregisterServices(ServiceRegistry.java:668)
> [junit]   at 
> org.eclipse.osgi.internal.framework.BundleContextImpl.close(BundleContextImpl.java:96)
> [junit]   at 
> org.eclipse.osgi.internal.framework.EquinoxBundle.stopWorker0(EquinoxBundle.java:1018)
> [junit]   at 
> org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.stopWorker(EquinoxBundle.java:359)
> [junit]   at org.eclipse.osgi.container.Module.doStop(Module.java:636)
> [junit]   at org.eclipse.osgi.container.Module.stop(Module.java:498)
> [junit]   at 
> org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.decStartLevel(ModuleContainer.java:1723)
> [junit]   at 
> org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1642)
> [junit]   at 
> org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1555)
> [junit]   at 
> org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)
> [junit]   at 
> org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
> [junit]   at 
> org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)
> {code}
> There are two issues:
> - the timeout is not configurable (hard coded to {{5000L}})
> - the exception is not handled in a safe way (i.e. logged to an appropriate 
> log which en

[jira] [Closed] (FELIX-5967) DM does not support java9+

[Pierre De Rop (JIRA)]

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

Pierre De Rop closed FELIX-5967.


> DM does not support java9+
> --
>
> Key: FELIX-5967
> URL: https://issues.apache.org/jira/browse/FELIX-5967
> Project: Felix
>  Issue Type: Improvement
>Affects Versions: org.apache.felix.dependencymanager-r8
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Major
> Fix For: org.apache.felix.dependencymanager-r13
>
>
> Dependency Manager can't be built/used on java9+ (9,10,11), because of the 
> following issues:
> 1) for configuration types, when we parse interface "default methods", the 
> way we are parsing does not work in java 9+, and a patch must be applied.
> See [1].
> 2) for dm-lambda, the way to parse the lambda parameter names for "fluent" 
> service properties (which requires the -parameters javac option) does not  
> work in java 9+. 
> For example, the following does not work
> {code:java}
> component(comp -> comp.impl(Foo.class).provides(FooService.class, property -> 
> "service property value"));{code}
> So, the "property" lambda parameter name can't be parsed in Java9+. This is 
> likely because starting from java9, the -parameters option is not generating 
> anymore the metadata for the lambda parameter names (see [2]).  For the 
> moment, the fluent service properties willl work only using java8, but not 
> anymore on java9+, and the most reasonable thing is to deprecate the usage of 
> fluent service properties, meaning that instead of:
> {code:java}
> component(comp -> comp.impl(Foo.class).provides(FooService.class, property -> 
> "service property value"));{code}
> you then must replace by:
> {code:java}
> component(comp -> comp.impl(Foo.class).provides(FooService.class, 
> "property","service property value"));{code}
> So, the fluent service properties must be commented as in restriction if 
> java9+ is used. No need to bump the dm-lambda bundle version, becaue it still 
> works using java8.
> 3) the gradle version needs to be updated, and for java11 support, the 
> "--no-daemon" option must be used when building.
> [1]  
> [https://dzone.com/articles/correct-reflective-access-to-interface-default-methods]
> [2] https://bugs.openjdk.java.net/browse/JDK-8138729



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (FELIX-5957) Check if a default implementation is used only on optional dependencies

[Pierre De Rop (JIRA)]

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

Pierre De Rop closed FELIX-5957.


> Check if a default implementation is used only on optional dependencies
> ---
>
> Key: FELIX-5957
> URL: https://issues.apache.org/jira/browse/FELIX-5957
> Project: Felix
>  Issue Type: Improvement
>  Components: Dependency Manager Annotations
>Affects Versions: org.apache.felix.dependencymanager-r1
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Minor
> Fix For: org.apache.felix.dependencymanager-r13
>
>
> When an optional dependency is defined on a class field, then a NullObject is 
> injected in case the dependency is unavailable.
> Now, it is possible to also set a default implementation using the 
> ServiceDependency.defaultImpl attribute. This attribute refers to class that 
> will be used when the service dependency is unavailable.
> For example:
> {code:java}
> @Component
> class MyComponent {
> @ServiceDependency(required=false, defaultImpl=MyDefaultImpl.class) 
> Dependency m_èdependency;
> }
> {code}
> But it is an error to use the defaultImpl attribute when the dependency is 
> required or when the dependency is not applied on a class field. So, the DM 
> annocation scanner should report an error in such a case.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (FELIX-5960) Do not supply MD5 checksum

[Pierre De Rop (JIRA)]

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

Pierre De Rop closed FELIX-5960.


> Do not supply MD5 checksum
> --
>
> Key: FELIX-5960
> URL: https://issues.apache.org/jira/browse/FELIX-5960
> Project: Felix
>  Issue Type: Task
>  Components: Dependency Manager
>Affects Versions: dependencymanager-2.0.1
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Trivial
> Fix For: org.apache.felix.dependencymanager-r13
>
>
> Due to Apache release policy updates, we should not supply anymore MD5 
> checksum when signing release candidates.
> For DM, the signStaging task in the release/build.gradle should then be 
> updated accordingly, and the DM check_staged_release.sh should not check 
> anymore MD5 checksum.
> It seems that the SHA-1 checksum should also not be supplied but I see that 
> they are still supplied by the other felix sub projects. So, for the moment, 
> let's only remove MD5 checksum.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (FELIX-5336) Add support for prototype scope services in DM4

[Pierre De Rop (JIRA)]

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

Pierre De Rop closed FELIX-5336.


> Add support for prototype scope services in DM4
> ---
>
> Key: FELIX-5336
> URL: https://issues.apache.org/jira/browse/FELIX-5336
> Project: Felix
>  Issue Type: New Feature
>  Components: Dependency Manager, Dependency Manager Annotations, 
> Dependency Manager Lambda, Dependency Manager Runtime
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Major
> Fix For: org.apache.felix.dependencymanager-r13
>
> Attachments: FELIX-5336.tgz
>
>
> In the users mailing list, there is a wish to add support in DM4 for OSGi 
> prototype scope services, which allows any service consumer to get its own 
> instance of a given service dependency.
> See http://www.mail-archive.com/users@felix.apache.org/msg17473.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (FELIX-5941) DM APi enhancements

[Pierre De Rop (JIRA)]

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

Pierre De Rop closed FELIX-5941.


> DM APi enhancements
> ---
>
> Key: FELIX-5941
> URL: https://issues.apache.org/jira/browse/FELIX-5941
> Project: Felix
>  Issue Type: Improvement
>  Components: Dependency Manager
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Minor
> Fix For: org.apache.felix.dependencymanager-r13
>
>
> in [https://github.com/pderop/dm.enhanced,] some enhancements have been done 
> regarding the dm API, and the intent of this issue is to merge the 
> improvements into the felix trunk:
>  * the api to define aspects and adapters have been reworked (but dm API 
> remains {{backward compatible}})
>  * you can now declare multiple property type interfaces when using 
> Configuration Dependency or Factory Components (this was needed to implement 
> the enhancements for the annotations)
>  * configuration dependency using metatypes can now declare property types
>  * Allow to specify if propagated configuration dependencies must override 
> service service properties (it was not possible to override service 
> properties with propagated service properties so far)
>  * Added the following signatures in Component interface:
>  ** setInterface(Class serviceName, Dictionary properties)
>  ** setInterface(Class[] serviceNames, Dictionary properties)
> h3. *Aspect/Adapters Api enhancements*
> So far, aspects or adapters were defined using many methods from 
> DependencyManager or DependencyActivatorBase classes:
> For example, in DependencyManager.java, we currently have many signatures
> {code:java}
> public class DependencyManager {
> public Component createAdapterService(Class serviceInterface, String 
> serviceFilter) {...}
> public Component createAdapterService(Class serviceInterface, String 
> serviceFilter, String autoConfig) {...}
> public Component createAdapterService(Class serviceInterface, String 
> serviceFilter, String add, String change, String remove) {...}
> public Component createAdapterService(Class serviceInterface, String 
> serviceFilter, String add, String change, String remove, String swap) {...}
> public Component createAdapterService(Class serviceInterface, String 
> serviceFilter, String autoConfig, Object callbackInstance, String add, String 
> change, String remove, String swap, boolean propagate) {...}
> 
> public Component createFactoryConfigurationAdapterService(String 
> factoryPid, String update, boolean propagate) {...}
> public Component createFactoryConfigurationAdapterService(String 
> factoryPid, String update, boolean propagate, Object callbackInstance) {...}
> public Component createFactoryConfigurationAdapterService(String 
> factoryPid, String update, boolean propagate, Class configType) {...}
> public Component createFactoryConfigurationAdapterService(String 
> factoryPid, String update, boolean propagate, Object callbackInstance, 
> Class configType) {...}
> public Component createAdapterFactoryConfigurationService(String 
> factoryPid, String update, boolean propagate,String heading, String desc, 
> String localization, PropertyMetaData[] propertiesMetaData) {...}
> 
> public Component createBundleAdapterService(int bundleStateMask, String 
> bundleFilter, boolean propagate) {...}
> public Component createBundleAdapterService(int bundleStateMask, String 
> bundleFilter, boolean propagate, Object callbackInstance, String add, String 
> change, String remove) {...}
> 
> public Component createResourceAdapterService(String resourceFilter, 
> boolean propagate, Object callbackInstance, String callbackChanged) {...}
> public Component createResourceAdapterService(String resourceFilter, 
> boolean propagate, Object callbackInstance, String callbackSet, String 
> callbackChanged)
> public Component createResourceAdapterService(String resourceFilter, 
> Object propagateCallbackInstance, String propagateCallbackMethod, Object 
> callbackInstance, String callbackChanged) {...}
> public Component createResourceAdapterService(String resourceFilter, 
> Object propagateCallbackInstance, String propagateCallbackMethod, Object 
> callbackInstance, String callbackSet, String callbackChanged) {...}
> 
> public Component createAspectService(Class serviceInterface, String 
> serviceFilter, int ranking, String autoConfig) {...}
> public Component createAspectService(Class serviceInterface, String 
> serviceFilter, int ranking) {...}
> public Component createAspectService(Class serviceInterface, String 
> serviceFilter, int ranking, String add, String change, String remove) {...}
> public Component createAspectService(Class serviceInterface, String 
> serviceFilter, int ranking, String

[jira] [Closed] (FELIX-5956) NPE when invoking a lifecycle runnable method from init method

[Pierre De Rop (JIRA)]

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

Pierre De Rop closed FELIX-5956.


> NPE when invoking a lifecycle runnable method from init method
> --
>
> Key: FELIX-5956
> URL: https://issues.apache.org/jira/browse/FELIX-5956
> Project: Felix
>  Issue Type: Bug
>  Components: Dependency Manager Runtime
>Affects Versions: org.apache.felix.dependencymanager-r1
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Major
> Fix For: org.apache.felix.dependencymanager-r13
>
>
> When you use a DM lifecycle controller in order to trigger component 
> activation from the @Init method, a NPE is throw if you invoke the lifecylce 
> runnable from the init method.
> For example, the following code:
> {code:java}
> @Component
> public class MyServiceImpl implements MyService {
> @LifecycleController
> volatile Runnable _start;
> @Init
> void init() {
> _start.run(); // immediately trigger service activation
> }
> }
> {code}
> produces the following NPE:
> {code}
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.felix.dm.runtime.ToggleServiceDependency.activate(ToggleServiceDependency.java:49)
>   at 
> org.apache.felix.dm.runtime.ServiceLifecycleHandler$ComponentStarter.run(ServiceLifecycleHandler.java:431)
>   at 
> org.apache.felix.dependencymanager.samples.hello.annot.ServiceProviderImpl.init(ServiceProviderImpl.java:47)
>   ... 65 more
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (FELIX-5939) DM annotations enhancements

[Pierre De Rop (JIRA)]

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

Pierre De Rop closed FELIX-5939.


> DM annotations enhancements
> ---
>
> Key: FELIX-5939
> URL: https://issues.apache.org/jira/browse/FELIX-5939
> Project: Felix
>  Issue Type: Improvement
>  Components: Dependency Manager Annotations, Dependency Manager 
> Runtime
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Minor
> Fix For: org.apache.felix.dependencymanager-r13
>
>
> Some DM annotations improvements have been done regarding DM Annotation in 
> this github project: [https://github.com/pderop/dm.enhanced,] and the intent 
> is to merge the improvements to the felix trunk.
> Essentially, the following DM annotations enhancements and modifications have 
> been done:
>  * in OSGi R7, declarative service now provides a @ComponentPropertyType 
> annotation that can be used to defined user defined property type 
> annotations. Now this annotation is used by other R7 libraries, like jaxrs 
> whiteboard R7 API. So the DM annotation scanner has been enhanced for the 
> support of the DS @ComponentPropertyType, allowing you to reuse user defined 
> annotations from other r7 libraries (whiteboad, etc ...). The dm annotation 
> plugin has been enhanced by reusing some part of the ds annotation scanner 
> from bndlib, which is full of reusable useful code which has been applied to 
> dm (scanning of property types, PREFIX_, etc ...). For consistency api 
> reasons, a new @PropertyType annotation has also been added to the DM 
> annotation API: this annotation has the same semantics has the DS 
> @ComponentPropertyType annotations.
>  * allow ServiceDependency to auto detect the service type when the 
> annotation is applied on a collection class field
>  * removed FactoryComponentAdapterService (some attributes have been added in 
> the Component annotation in order to declare factory pid components with the 
> @Component annotation)
>  * removed some old annotations / attributes. The attributes and annotations 
> related to metatype have been removed since you can now use the standard 
> metatype annotations. if users need to use old version, then the previous old 
> 4.2.1 annotations can be used, because the dm runtime is compatible with old 
> and new annotations version.
>  * removed "dereference" attribute in ServiceDependencyAnnotation, because we 
> can now infer if the service dependency callbacks accepts a ServiceReference 
> or a ServiceObjects parameter
> Since some incompatible changes have been made, the major version of the 
> annotation bundle has been bumped to 5.0.0.
> *User defined property types examples:*
> So far, you could define component service properties using DM @Property 
> annotation, and component configuration could be declared as user defined 
> interfaces. You can now declare user-defined annotations which can be used to 
> specify both service properties and component configuration. It means that 
> instead of declaring service properties using @Property annotation, you can 
> now use your own annotations (which must be annotated with the new 
> @PropertyType annotation, or using the standard @ComponentPropertyType 
> annotation.
> For example, let’s assume your write an OSGi r7 jaxrs servlet context which 
> needs the two following service properties:
> {code:java}
> osgi.http.whiteboard.context.name
> osgi.http.whiteboard.context.path
> {code}
> Then you can first define your own annotation (but you could also reuse the 
> default annotations provided by the new jaxrs whiteboard r7 api, from the 
> org.osgi.service.jaxrs.whiteboard.propertytypes package):
>  
> {code:java}
> import org.apache.felix.dependencymanager.annotation.PropertyType;
> @PropertyType
> @interface ServletContext {
> String osgi_http_whiteboard_context_name() default AppServletContext.NAME;
> String osgi_http_whiteboard_context_path();
> }
> {code}
> In the above, the underscore is mapped to ".", and you can apply the above 
> annotation on top of your component like this:
> {code:java}
>  @Component
>  @ServletContext(osgi_http_whiteboard_context_path="/game")
>  public class AppServletContext extends ServletContextHelper {
>  }
> {code}
> You can also use configuration admin service in order to override the default 
> service properties:
> {code:java}
>  @Component
>  @ServletContext(osgi_http_whiteboard_context_path="/game")
>  public class AppServletContext extends ServletContextHelper {
>     @ConfigurationDependency(propagate=true, pid="my.pid")
>     void updated(ServletContext cnf) {
>         // if some properties are not present in the configuration, then the 
> ones used in the
>         // annotation will be used.
>         // The configuration admin properties, if defined, will override

[jira] [Closed] (FELIX-5937) Refactor DM bndtools/gradle project

[Pierre De Rop (JIRA)]

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

Pierre De Rop closed FELIX-5937.


> Refactor DM bndtools/gradle project
> ---
>
> Key: FELIX-5937
> URL: https://issues.apache.org/jira/browse/FELIX-5937
> Project: Felix
>  Issue Type: Improvement
>  Components: Dependency Manager, Dependency Manager Shell
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Minor
> Fix For: org.apache.felix.dependencymanager-r13
>
>
> The DM gradle project structure has been enhanced (see [1]) and I'd like to 
> merge the enhancements in the felix trunk.
> Mainly:
>  * all build time binary dependencies are now downloaded from maven central 
> using the bndtools "aQute.bnd.repository.maven.provider.MavenBndRepository".
>  * The gradle wrapper is not commited anymore and is downloaded by the 
> "gradlew" scripts.
>  * Fixed some issues in the release/build.gradle script, which now allows to 
> interactively specify the PGP key when calling the "gradlew signStaging" task
> The consequence of this is that we don't need anymore to deliver a 
> "-deps.zip" bundle which was containing so far build-time binary dependencies.
> [1]https://github.com/pderop/dm.enhanced



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (FELIX-5955) Move changelog.txt to toplevel project dir

[Pierre De Rop (JIRA)]

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

Pierre De Rop closed FELIX-5955.


> Move changelog.txt to toplevel project dir
> --
>
> Key: FELIX-5955
> URL: https://issues.apache.org/jira/browse/FELIX-5955
> Project: Felix
>  Issue Type: Bug
>  Components: Dependency Manager
>Affects Versions: org.apache.felix.dependencymanager-r1
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Trivial
> Fix For: org.apache.felix.dependencymanager-r13
>
>
> Currently, chanlogs are stored in each dependency manager sub projects.
> But the download felix link requires the changelog to be located at the 
> toplevel source project directory. Moreover, it's easier to maintain one 
> single changelog.txt file instead of having one for each DM sub projects.
> let's have a single changelog.txt file stored in the DM toplevel source 
> directory (dependencymanager/changelog;txt).
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (FELIX-5768) DM Lambda stop callback not being called

[Pierre De Rop (JIRA)]

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

Pierre De Rop closed FELIX-5768.


> DM Lambda stop callback not being called
> 
>
> Key: FELIX-5768
> URL: https://issues.apache.org/jira/browse/FELIX-5768
> Project: Felix
>  Issue Type: Bug
>  Components: Dependency Manager Lambda
>Affects Versions: org.apache.felix.dependencymanager-r8
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Blocker
> Fix For: org.apache.felix.dependencymanager-r13
>
> Attachments: org.apache.felix.dependencymanager.lambda-1.1.2.jar
>
>
> It has been reported from the felix users mailing list an issue where a 
> component defined with dm-lambda API is never called in its "stop" callback 
> when the bundle is stopped.
> indeed, the dm-lambda DependencyManagerActivator.stop method has a bug and 
> does not clear the dependency manager when the bundle is stopped: the current 
> code of the DependencyManagerActivator.stop method is this:
> {code}
> public void stop(BundleContext context) throws Exception {
> destroy();
> }
> {code}
> and of course, the manager must be cleared, like it is the case with the 
> original DependencyActivatorBase.stop method:
> {code}
> public void stop(BundleContext context) throws Exception {
> destroy();
> m_manager.clear();
> }
> {code}
> it is too bad that no tests were testing this so basic behavior, so I will 
> first add it soon.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (FELIX-5716) Dead Lock in DM

[Pierre De Rop (JIRA)]

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

Pierre De Rop closed FELIX-5716.


> Dead Lock in DM
> ---
>
> Key: FELIX-5716
> URL: https://issues.apache.org/jira/browse/FELIX-5716
> Project: Felix
>  Issue Type: Bug
>Affects Versions: org.apache.felix.dependencymanager-r1
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Critical
> Fix For: org.apache.felix.dependencymanager-r13
>
> Attachments: deadlock.proposed.patch.txt
>
>
> I just found an unfortunate deadlock when using latest DM r11 and latest SCR 
> 2.0.12 in the same JVM.
> I believe that the same issue applies to both DM and SCR (I may have to open 
> a seperate issue for SCR).
> First, here is the deadlock:
> {code}
> Found one Java-level deadlock:
> =
> "CM Event Dispatcher (Fire ConfigurationEvent: 
> pid=com.alcatel.as.http.ioh.impl.HttpIOH)":
>   waiting to lock monitor 0x7f8188004538 (object 0xeb38d420, a 
> org.apache.felix.dm.tracker.ServiceTracker$Tracked),
>   which is held by "FelixDispatchQueue"
> "FelixDispatchQueue":
>   waiting for ownable synchronizer 0xc0699f30, (a 
> java.util.concurrent.locks.ReentrantLock$FairSync),
>   which is held by "CM Event Dispatcher (Fire ConfigurationEvent: 
> pid=com.alcatel.as.http.ioh.impl.HttpIOH)"
> Java stack information for the threads listed above:
> ===
> "CM Event Dispatcher (Fire ConfigurationEvent: 
> pid=com.alcatel.as.http.ioh.impl.HttpIOH)":
> at 
> org.apache.felix.dm.tracker.ServiceTracker$Tracked.serviceChangedHideAspects(ServiceTracker.java:1140)
> - waiting to lock <0xeb38d420> (a 
> org.apache.felix.dm.tracker.ServiceTracker$Tracked)
> at 
> org.apache.felix.dm.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:1054)
> at 
> org.apache.felix.framework.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:990)
> at 
> org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:838)
> at 
> org.apache.felix.framework.EventDispatcher.fireServiceEvent(EventDispatcher.java:545)
> at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4579)
> at org.apache.felix.framework.Felix.access$000(Felix.java:105)
> at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:419)
> at 
> org.apache.felix.framework.ServiceRegistry.servicePropertiesModified(ServiceRegistry.java:588)
> at 
> org.apache.felix.framework.ServiceRegistrationImpl.setProperties(ServiceRegistrationImpl.java:131)
> at 
> org.apache.felix.scr.impl.manager.SingleComponentManager.updateServiceRegistration(SingleComponentManager.java:558)
> at 
> org.apache.felix.scr.impl.manager.SingleComponentManager.modify(SingleComponentManager.java:755)
> at 
> org.apache.felix.scr.impl.manager.SingleComponentManager.reconfigure(SingleComponentManager.java:645)
> at 
> org.apache.felix.scr.impl.manager.SingleComponentManager.reconfigure(SingleComponentManager.java:609)
> at 
> org.apache.felix.scr.impl.manager.ConfigurableComponentHolder.configurationUpdated(ConfigurableComponentHolder.java:426)
> at 
> org.apache.felix.scr.impl.manager.RegionConfigurationSupport.configurationEvent(RegionConfigurationSupport.java:284)
> at 
> org.apache.felix.scr.impl.manager.RegionConfigurationSupport$1.configurationEvent(RegionConfigurationSupport.java:89)
> at 
> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2090)
> at 
> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2058)
> at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:141)
> at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:109)
> at java.lang.Thread.run(Thread.java:748)
> "FelixDispatchQueue":
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for  <0xc0699f30> (a 
> java.util.concurrent.locks.ReentrantLock$FairSync)
> at 
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireNanos(AbstractQueuedSynchronizer.java:934)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireNanos(AbstractQueuedSynchronizer.java:1247)
> at 
> java.util.concurrent.locks.ReentrantLock.tryLock(ReentrantLock.java:442)
> at 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.obtainLock(AbstractComponentManager.java:228)
> at 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.obtainStat

[jira] [Closed] (FELIX-5683) getServiceProperties returns null instead of empty dictionary

[Pierre De Rop (JIRA)]

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

Pierre De Rop closed FELIX-5683.


> getServiceProperties returns null instead of empty dictionary
> -
>
> Key: FELIX-5683
> URL: https://issues.apache.org/jira/browse/FELIX-5683
> Project: Felix
>  Issue Type: Bug
>  Components: Dependency Manager
>Affects Versions: org.apache.felix.dependencymanager-r9
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Minor
> Fix For: org.apache.felix.dependencymanager-r13
>
>
> There are two issues:
> 1)
> In the felix users mailing list (see [1]), Bram reported the following:
> when you set a component service properties like this:
> {code}
> Component component = 
> m_dependencyManager.createComponent().setInterface(ApplicationService.class.getName(),new
>  Properties());
> component.getServiceProperties().put("a", "b");
> {code}
> then you get a NPE because the component.getServiceProperties() method 
> returns null instead of the empty dictionary that has been set in the 
> setInterfaceMethod.
> This is a regression made in r9 release, in the FELIX-5522 where a 
> refactoring was done regarding aspect service properties.
> A fix can be made in order to behave like before (that is : avoid the NPE). 
> 2)
> Bram, I may be wrong but I think that one new issue is that the dictionary 
> returned by the getServiceProperties() method was so far (since the initial 
> version of felix dm 2.0.1) a copy of the service properties dictionary 
> maintained in the ComponentImpl, so if you would like to do set service 
> properties like this:
> {code}
> Component component = 
> m_dependencyManager.createComponent().setInterface(ApplicationService.class.getName(),new
>  Properties());
> component.getServiceProperties().put("a", "b");
> m_dependencyManager.add(component);  // won't add "a=b" properties
> {code}
> then the "a" property will be set in the copy of the internal dictionary 
> returned by the getServiceProperties() method, and the "a=b" service 
> properties won't be set when the component is added in the 
> m_dependencyManager.
> So, if what I'm saying is correct and if you would like to see this new 
> behavior implemented, please open a new jira issue and I will manage to 
> implement it; thanks
> PS: I'm now fixing the 1) regression, in order to avoid the NPE.
> [1] http://www.mail-archive.com/users%40felix.apache.org/msg17939.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [RESULT] [VOTE] Apache Felix Dependency Manager Release R13

[Pierre De Rop]

Hi;

The vote passed with 7 binding votes (Carsten Ziegeler, Raymond Augé, David
Bosschaert, Jan Willem Janssen, Jean-Baptiste Onofré, Karl Pauls, Pierre De
Rop), and 3 non binding votes (Francois Papon, Juan Manuel Calderon, Cédric
Dos Santos)

Thanks everyone for your votes, I'll release the artifacts asap.

kind regards
Pierre


On Mon, Oct 22, 2018 at 10:46 AM Pierre De Rop 
wrote:

> +1
>
> regards
> Pierre
>
> On Thu, Oct 18, 2018 at 5:47 PM Karl Pauls  wrote:
>
>> +1
>>
>> regards,
>>
>> Karl
>>
>> On Thursday, October 18, 2018, Jean-Baptiste Onofré 
>> wrote:
>>
>> > +1
>> >
>> > Regards
>> > JB
>> >
>> > Le 18 oct. 2018 à 16:59, à 16:59, David Bosschaert <
>> > david.bosscha...@gmail.com> a écrit:
>> > >+1
>> > >
>> > >David
>> > >
>> > >On Wed, 17 Oct 2018 at 22:59, Pierre De Rop 
>> > >wrote:
>> > >
>> > >> Hello everyone;
>> > >>
>> > >> After a failed attempt to release the R12 version, I call for a vote
>> > >on
>> > >> the Dependency Manager top level release R13.
>> > >> The major issue for the service scope has been fixed (see
>> > >FELIX-5336), and
>> > >> DM can now be built/run using Java9,10,11 (see FELIX-5967).
>> > >>
>> > >> release notes:
>> > >>
>> > >> ** Bug
>> > >> * [FELIX-5683] - getServiceProperties returns null instead of
>> > >empty
>> > >> dictionary
>> > >> * [FELIX-5716] - Dead Lock in DM
>> > >> * [FELIX-5768] - DM Lambda stop callback not being called
>> > >> * [FELIX-5955] - Move changelog.txt to toplevel project dir
>> > >> * [FELIX-5956] - NPE when invoking a lifecycle runnable method
>> > >from
>> > >> init method
>> > >>
>> > >> ** New Feature
>> > >> * [FELIX-5336] - Add support for prototype scope services in DM4
>> > >>
>> > >> ** Improvement
>> > >> * [FELIX-5937] - Refactor DM bndtools/gradle project
>> > >> * [FELIX-5939] - DM annotations enhancements
>> > >> * [FELIX-5941] - DM APi enhancements
>> > >> * [FELIX-5957] - Check if a default implementation is used only
>> > >on
>> > >> optional dependencies
>> > >> * [FELIX-5967] - DM does not support java9+
>> > >>
>> > >> ** Task
>> > >> * [FELIX-5960] - Do not supply MD5 checksum
>> > >>
>> > >> You can use this UNIX script to download the release and verify the
>> > >> signatures:
>> > >>
>> > >>
>> > >>
>> > >>
>> > >http://svn.apache.org/repos/asf/felix/trunk/dependencymanager/release/
>> > check_staged_release.sh
>> > >>
>> > >> Usage:
>> > >>
>> > >>  sh check_staged_release.sh r13 /tmp/felix-staging
>> > >>
>> > >> This script, unlike the original Felix check_stage_release.sh, is
>> > >specific
>> > >> to the Dependency Manager release process (see FELIX-4818) and will
>> > >> download staging from https://dist.apache.org/repos/dist/dev/felix
>> > >instead
>> > >> of http://repository.apache.org/content/repositories.
>> > >>
>> > >> To rebuild the DM binaries from the source, you can refer to
>> > >>
>> > >>
>> > >>
>> > >>
>> > >
>> https://svn.apache.org/repos/asf/felix/trunk/dependencymanager/release/
>> > resources/src/README.src
>> > >>
>> > >> Unlike with previous R11 version, there is no
>> > >> org.apache.felix.dependencymanager-r11-deps.zip anymore.
>> > >> Before building the source, if you use an http proxy then you must
>> > >set the
>> > >> following environment variables:
>> > >> (check README.src):
>> > >>
>> > >> export GRADLE_OPTS="-Dhttps.proxyHost=www.somehost.org
>> > >> -Dhttps.proxyPort=port"
>> > >> export http_proxy=www.somehost.org:port
>> > >> export https_proxy=www.somehost.org:port
>> > >>
>> > >> And when building with java9/10/11, please use the "--no-daemon"
>> > >gradlew
>> > >> option.
>> > >>
>> > >> Please cast your votes to approve this release:
>> > >>
>> > >> [ ] +1 Approve the release
>> > >> [ ] -1 Veto the release (please provide specific comments)
>> > >>
>> > >> This vote will be open for 72 hours.
>> > >>
>> > >> thanks & regards;
>> > >> /Pierre
>> > >>
>> >
>>
>>
>> --
>> Karl Pauls
>> karlpa...@gmail.com
>>
>

Re: [VOTE] Apache Felix Dependency Manager Release R13

[Pierre De Rop]

+1

regards
Pierre

On Thu, Oct 18, 2018 at 5:47 PM Karl Pauls  wrote:

> +1
>
> regards,
>
> Karl
>
> On Thursday, October 18, 2018, Jean-Baptiste Onofré 
> wrote:
>
> > +1
> >
> > Regards
> > JB
> >
> > Le 18 oct. 2018 à 16:59, à 16:59, David Bosschaert <
> > david.bosscha...@gmail.com> a écrit:
> > >+1
> > >
> > >David
> > >
> > >On Wed, 17 Oct 2018 at 22:59, Pierre De Rop 
> > >wrote:
> > >
> > >> Hello everyone;
> > >>
> > >> After a failed attempt to release the R12 version, I call for a vote
> > >on
> > >> the Dependency Manager top level release R13.
> > >> The major issue for the service scope has been fixed (see
> > >FELIX-5336), and
> > >> DM can now be built/run using Java9,10,11 (see FELIX-5967).
> > >>
> > >> release notes:
> > >>
> > >> ** Bug
> > >> * [FELIX-5683] - getServiceProperties returns null instead of
> > >empty
> > >> dictionary
> > >> * [FELIX-5716] - Dead Lock in DM
> > >> * [FELIX-5768] - DM Lambda stop callback not being called
> > >> * [FELIX-5955] - Move changelog.txt to toplevel project dir
> > >> * [FELIX-5956] - NPE when invoking a lifecycle runnable method
> > >from
> > >> init method
> > >>
> > >> ** New Feature
> > >> * [FELIX-5336] - Add support for prototype scope services in DM4
> > >>
> > >> ** Improvement
> > >> * [FELIX-5937] - Refactor DM bndtools/gradle project
> > >> * [FELIX-5939] - DM annotations enhancements
> > >> * [FELIX-5941] - DM APi enhancements
> > >> * [FELIX-5957] - Check if a default implementation is used only
> > >on
> > >> optional dependencies
> > >> * [FELIX-5967] - DM does not support java9+
> > >>
> > >> ** Task
> > >> * [FELIX-5960] - Do not supply MD5 checksum
> > >>
> > >> You can use this UNIX script to download the release and verify the
> > >> signatures:
> > >>
> > >>
> > >>
> > >>
> > >http://svn.apache.org/repos/asf/felix/trunk/dependencymanager/release/
> > check_staged_release.sh
> > >>
> > >> Usage:
> > >>
> > >>  sh check_staged_release.sh r13 /tmp/felix-staging
> > >>
> > >> This script, unlike the original Felix check_stage_release.sh, is
> > >specific
> > >> to the Dependency Manager release process (see FELIX-4818) and will
> > >> download staging from https://dist.apache.org/repos/dist/dev/felix
> > >instead
> > >> of http://repository.apache.org/content/repositories.
> > >>
> > >> To rebuild the DM binaries from the source, you can refer to
> > >>
> > >>
> > >>
> > >>
> > >https://svn.apache.org/repos/asf/felix/trunk/dependencymanager/release/
> > resources/src/README.src
> > >>
> > >> Unlike with previous R11 version, there is no
> > >> org.apache.felix.dependencymanager-r11-deps.zip anymore.
> > >> Before building the source, if you use an http proxy then you must
> > >set the
> > >> following environment variables:
> > >> (check README.src):
> > >>
> > >> export GRADLE_OPTS="-Dhttps.proxyHost=www.somehost.org
> > >> -Dhttps.proxyPort=port"
> > >> export http_proxy=www.somehost.org:port
> > >> export https_proxy=www.somehost.org:port
> > >>
> > >> And when building with java9/10/11, please use the "--no-daemon"
> > >gradlew
> > >> option.
> > >>
> > >> Please cast your votes to approve this release:
> > >>
> > >> [ ] +1 Approve the release
> > >> [ ] -1 Veto the release (please provide specific comments)
> > >>
> > >> This vote will be open for 72 hours.
> > >>
> > >> thanks & regards;
> > >> /Pierre
> > >>
> >
>
>
> --
> Karl Pauls
> karlpa...@gmail.com
>