[jira] [Commented] (FELIX-2816) dependency manager calls init() twice
[
https://issues.apache.org/jira/browse/FELIX-2816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13144113#comment-13144113
]
Xander Uiterlinden commented on FELIX-2816:
---
This is most likely caused by overlapping init methods. One for the servlet
init and one for the component lifecycle callback method. It can be resolved by
specifying another name for the init callback for the component lifecycle by
using the Component.setCallbacks method.
> dependency manager calls init() twice
> -
>
> Key: FELIX-2816
> URL: https://issues.apache.org/jira/browse/FELIX-2816
> Project: Felix
> Issue Type: Bug
> Components: Dependency Manager
>Reporter: Derek Baum
>
> Log messages are placed at the beginning of the component lifecycle methods
> (init, start, stop, destroy).
> The number is the hashCode, which shows that init() is called twice on the
> same Object, without intervening stop() or destroy():
> [Debug] [ ] MyServlet 1397120162 init: update=60
> [Debug] [ ] MyServlet 1397120162 start: endpoint=/myservlet period=60
> history=null
> [Debug] [ ] MyServlet 1397120162 init: update=60
> [Debug] [ ] MyServlet add: gx2
> [Debug] [ ] MyServlet add: denzil
> The component is created as follows:
> manager.add(createComponent()
> .setImplementation(MyServlet.class)
> .add(createConfigurationDependency()
> .setPropagate(true)
> .setPid(PID))
> .add(createServiceDependency()
>
> .setService(HttpService.class).setRequired(true))
> .add(createServiceDependency()
> .setService(UserAdmin.class).setRequired(true))
> .add(createServiceDependency()
>
> .setService(MyStateStore.class).setRequired(false)
> .setCallbacks("addStore",
> "removeStore"))
> .add(createServiceDependency()
>
> .setService(HistoryService.class).setRequired(false))
> .add(createServiceDependency()
>
> .setService(LogService.class).setRequired(false))
> );
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-3201) Offer more functional callback methods for services that have aspects on them.
[ https://issues.apache.org/jira/browse/FELIX-3201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Offermans resolved FELIX-3201. - Resolution: Fixed Reviewed and committed both patches. > Offer more functional callback methods for services that have aspects on them. > -- > > Key: FELIX-3201 > URL: https://issues.apache.org/jira/browse/FELIX-3201 > Project: Felix > Issue Type: Improvement > Components: Dependency Manager > Environment: n/a >Reporter: Xander Uiterlinden >Assignee: Marcel Offermans > Labels: features > Attachments: dm-core-patch.txt, dm-test-patch.txt > > > When programmatically adding service dependencies using the Apache felix > dependency manager there are two ways to have the component brought its > dependencies when they come available. These are the following: > - have the service injected in the component; this is usually sufficient for > cases where there's only one service expected to satisfy the dependency > (1-to-1) . > - explicitly specify callback methods; callbacks can be used when there might > be more than one service satisfying the dependency (1-to-n). When a > dependency is marked optional, the callback method also helps to determine > when the dependency actually became satisfied. > When using callback methods with the dependency manager you can specify the > following callbacks: > - added; gets called when the service required has become available. > - changed; gets called when the service properties of a added required > service have changed. > - removed; gets called when the service required has become unavailable. > At first these callbacks seem pretty simple. Just add the service to the > component's internal administration on the added callback and remove it from > the administration whenever the removed callback is called. But, the > dependency manager also supports the concept of aspect services which make > using the callback method in a correct way a bit more difficult. > Aspect services are services that are put on top of another service while > still implementing the original service's interface. They allow you to > implement cross-cutting functional requirements. > In the OSGi service registry aspect services are individual services just > like 'regular' singleton services. When using callback methods for > dependencies a component is informed of the add/remove of an aspect service, > just like it is when a 'regular' service is added/removed. When using > injection for dependencies the aspect is transparently injected. The > callbacks also handling aspect services the same way as 'regular' services > makes it difficult for a component developer to correctly implement these > callbacks. > For example take the following scenario: > Component A expresses a service dependency to Service B. > Without any aspects in the container the following callbacks would be added > on Component A. > added(Service B) > But whenever there's an aspect running on top of Service B, the order of > callbacks would be as follows: > added(Service B) > added(Service B aspect) > removed(Service B) > When backed by a typical HashMap administration this would result in: > put(B.id, B) > put(B.id, B) > remove(B.id) > This sequence would result in an empty Map, which is not a desirable > situation. In order to ease the dependency handling an additional callback > method is needed which hides the complexity as described above and translates > the callbacks to the following more functional callbacks: > added; called when the service required has become available. > swapped; called when the service required needs to be replaced due to add or > removal of an aspect. This to be sure the component uses the aspect that's on > top of the aspect chain for the required service. > changed; called when the service properties of an added required service have > changed. > removed; called when the service required has become unavailable. > With these callbacks a developer does not have to worry about the possible > sequences in which added/removed can occur. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (FELIX-3201) Offer more functional callback methods for services that have aspects on them.
[ https://issues.apache.org/jira/browse/FELIX-3201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Offermans reassigned FELIX-3201: --- Assignee: Marcel Offermans > Offer more functional callback methods for services that have aspects on them. > -- > > Key: FELIX-3201 > URL: https://issues.apache.org/jira/browse/FELIX-3201 > Project: Felix > Issue Type: Improvement > Components: Dependency Manager > Environment: n/a >Reporter: Xander Uiterlinden >Assignee: Marcel Offermans > Labels: features > Attachments: dm-core-patch.txt, dm-test-patch.txt > > > When programmatically adding service dependencies using the Apache felix > dependency manager there are two ways to have the component brought its > dependencies when they come available. These are the following: > - have the service injected in the component; this is usually sufficient for > cases where there's only one service expected to satisfy the dependency > (1-to-1) . > - explicitly specify callback methods; callbacks can be used when there might > be more than one service satisfying the dependency (1-to-n). When a > dependency is marked optional, the callback method also helps to determine > when the dependency actually became satisfied. > When using callback methods with the dependency manager you can specify the > following callbacks: > - added; gets called when the service required has become available. > - changed; gets called when the service properties of a added required > service have changed. > - removed; gets called when the service required has become unavailable. > At first these callbacks seem pretty simple. Just add the service to the > component's internal administration on the added callback and remove it from > the administration whenever the removed callback is called. But, the > dependency manager also supports the concept of aspect services which make > using the callback method in a correct way a bit more difficult. > Aspect services are services that are put on top of another service while > still implementing the original service's interface. They allow you to > implement cross-cutting functional requirements. > In the OSGi service registry aspect services are individual services just > like 'regular' singleton services. When using callback methods for > dependencies a component is informed of the add/remove of an aspect service, > just like it is when a 'regular' service is added/removed. When using > injection for dependencies the aspect is transparently injected. The > callbacks also handling aspect services the same way as 'regular' services > makes it difficult for a component developer to correctly implement these > callbacks. > For example take the following scenario: > Component A expresses a service dependency to Service B. > Without any aspects in the container the following callbacks would be added > on Component A. > added(Service B) > But whenever there's an aspect running on top of Service B, the order of > callbacks would be as follows: > added(Service B) > added(Service B aspect) > removed(Service B) > When backed by a typical HashMap administration this would result in: > put(B.id, B) > put(B.id, B) > remove(B.id) > This sequence would result in an empty Map, which is not a desirable > situation. In order to ease the dependency handling an additional callback > method is needed which hides the complexity as described above and translates > the callbacks to the following more functional callbacks: > added; called when the service required has become available. > swapped; called when the service required needs to be replaced due to add or > removal of an aspect. This to be sure the component uses the aspect that's on > top of the aspect chain for the required service. > changed; called when the service properties of an added required service have > changed. > removed; called when the service required has become unavailable. > With these callbacks a developer does not have to worry about the possible > sequences in which added/removed can occur. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3201) Offer more functional callback methods for services that have aspects on them.
[ https://issues.apache.org/jira/browse/FELIX-3201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13143991#comment-13143991 ] Marcel Offermans commented on FELIX-3201: - Thanks for this contribution, Xander! > Offer more functional callback methods for services that have aspects on them. > -- > > Key: FELIX-3201 > URL: https://issues.apache.org/jira/browse/FELIX-3201 > Project: Felix > Issue Type: Improvement > Components: Dependency Manager > Environment: n/a >Reporter: Xander Uiterlinden > Labels: features > Attachments: dm-core-patch.txt, dm-test-patch.txt > > > When programmatically adding service dependencies using the Apache felix > dependency manager there are two ways to have the component brought its > dependencies when they come available. These are the following: > - have the service injected in the component; this is usually sufficient for > cases where there's only one service expected to satisfy the dependency > (1-to-1) . > - explicitly specify callback methods; callbacks can be used when there might > be more than one service satisfying the dependency (1-to-n). When a > dependency is marked optional, the callback method also helps to determine > when the dependency actually became satisfied. > When using callback methods with the dependency manager you can specify the > following callbacks: > - added; gets called when the service required has become available. > - changed; gets called when the service properties of a added required > service have changed. > - removed; gets called when the service required has become unavailable. > At first these callbacks seem pretty simple. Just add the service to the > component's internal administration on the added callback and remove it from > the administration whenever the removed callback is called. But, the > dependency manager also supports the concept of aspect services which make > using the callback method in a correct way a bit more difficult. > Aspect services are services that are put on top of another service while > still implementing the original service's interface. They allow you to > implement cross-cutting functional requirements. > In the OSGi service registry aspect services are individual services just > like 'regular' singleton services. When using callback methods for > dependencies a component is informed of the add/remove of an aspect service, > just like it is when a 'regular' service is added/removed. When using > injection for dependencies the aspect is transparently injected. The > callbacks also handling aspect services the same way as 'regular' services > makes it difficult for a component developer to correctly implement these > callbacks. > For example take the following scenario: > Component A expresses a service dependency to Service B. > Without any aspects in the container the following callbacks would be added > on Component A. > added(Service B) > But whenever there's an aspect running on top of Service B, the order of > callbacks would be as follows: > added(Service B) > added(Service B aspect) > removed(Service B) > When backed by a typical HashMap administration this would result in: > put(B.id, B) > put(B.id, B) > remove(B.id) > This sequence would result in an empty Map, which is not a desirable > situation. In order to ease the dependency handling an additional callback > method is needed which hides the complexity as described above and translates > the callbacks to the following more functional callbacks: > added; called when the service required has become available. > swapped; called when the service required needs to be replaced due to add or > removal of an aspect. This to be sure the component uses the aspect that's on > top of the aspect chain for the required service. > changed; called when the service properties of an added required service have > changed. > removed; called when the service required has become unavailable. > With these callbacks a developer does not have to worry about the possible > sequences in which added/removed can occur. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3201) Offer more functional callback methods for services that have aspects on them.
[ https://issues.apache.org/jira/browse/FELIX-3201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xander Uiterlinden updated FELIX-3201: -- Attachment: dm-test-patch.txt dm-core-patch.txt Attached a both a patch to the ServiceDependency, ServiceUtil and ServiceDependencyImpl which implements the improvement described. It also includes a test case. > Offer more functional callback methods for services that have aspects on them. > -- > > Key: FELIX-3201 > URL: https://issues.apache.org/jira/browse/FELIX-3201 > Project: Felix > Issue Type: Improvement > Components: Dependency Manager > Environment: n/a >Reporter: Xander Uiterlinden > Labels: features > Attachments: dm-core-patch.txt, dm-test-patch.txt > > > When programmatically adding service dependencies using the Apache felix > dependency manager there are two ways to have the component brought its > dependencies when they come available. These are the following: > - have the service injected in the component; this is usually sufficient for > cases where there's only one service expected to satisfy the dependency > (1-to-1) . > - explicitly specify callback methods; callbacks can be used when there might > be more than one service satisfying the dependency (1-to-n). When a > dependency is marked optional, the callback method also helps to determine > when the dependency actually became satisfied. > When using callback methods with the dependency manager you can specify the > following callbacks: > - added; gets called when the service required has become available. > - changed; gets called when the service properties of a added required > service have changed. > - removed; gets called when the service required has become unavailable. > At first these callbacks seem pretty simple. Just add the service to the > component's internal administration on the added callback and remove it from > the administration whenever the removed callback is called. But, the > dependency manager also supports the concept of aspect services which make > using the callback method in a correct way a bit more difficult. > Aspect services are services that are put on top of another service while > still implementing the original service's interface. They allow you to > implement cross-cutting functional requirements. > In the OSGi service registry aspect services are individual services just > like 'regular' singleton services. When using callback methods for > dependencies a component is informed of the add/remove of an aspect service, > just like it is when a 'regular' service is added/removed. When using > injection for dependencies the aspect is transparently injected. The > callbacks also handling aspect services the same way as 'regular' services > makes it difficult for a component developer to correctly implement these > callbacks. > For example take the following scenario: > Component A expresses a service dependency to Service B. > Without any aspects in the container the following callbacks would be added > on Component A. > added(Service B) > But whenever there's an aspect running on top of Service B, the order of > callbacks would be as follows: > added(Service B) > added(Service B aspect) > removed(Service B) > When backed by a typical HashMap administration this would result in: > put(B.id, B) > put(B.id, B) > remove(B.id) > This sequence would result in an empty Map, which is not a desirable > situation. In order to ease the dependency handling an additional callback > method is needed which hides the complexity as described above and translates > the callbacks to the following more functional callbacks: > added; called when the service required has become available. > swapped; called when the service required needs to be replaced due to add or > removal of an aspect. This to be sure the component uses the aspect that's on > top of the aspect chain for the required service. > changed; called when the service properties of an added required service have > changed. > removed; called when the service required has become unavailable. > With these callbacks a developer does not have to worry about the possible > sequences in which added/removed can occur. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-3201) Offer more functional callback methods for services that have aspects on them.
Offer more functional callback methods for services that have aspects on them. -- Key: FELIX-3201 URL: https://issues.apache.org/jira/browse/FELIX-3201 Project: Felix Issue Type: Improvement Components: Dependency Manager Environment: n/a Reporter: Xander Uiterlinden When programmatically adding service dependencies using the Apache felix dependency manager there are two ways to have the component brought its dependencies when they come available. These are the following: - have the service injected in the component; this is usually sufficient for cases where there's only one service expected to satisfy the dependency (1-to-1) . - explicitly specify callback methods; callbacks can be used when there might be more than one service satisfying the dependency (1-to-n). When a dependency is marked optional, the callback method also helps to determine when the dependency actually became satisfied. When using callback methods with the dependency manager you can specify the following callbacks: - added; gets called when the service required has become available. - changed; gets called when the service properties of a added required service have changed. - removed; gets called when the service required has become unavailable. At first these callbacks seem pretty simple. Just add the service to the component's internal administration on the added callback and remove it from the administration whenever the removed callback is called. But, the dependency manager also supports the concept of aspect services which make using the callback method in a correct way a bit more difficult. Aspect services are services that are put on top of another service while still implementing the original service's interface. They allow you to implement cross-cutting functional requirements. In the OSGi service registry aspect services are individual services just like 'regular' singleton services. When using callback methods for dependencies a component is informed of the add/remove of an aspect service, just like it is when a 'regular' service is added/removed. When using injection for dependencies the aspect is transparently injected. The callbacks also handling aspect services the same way as 'regular' services makes it difficult for a component developer to correctly implement these callbacks. For example take the following scenario: Component A expresses a service dependency to Service B. Without any aspects in the container the following callbacks would be added on Component A. added(Service B) But whenever there's an aspect running on top of Service B, the order of callbacks would be as follows: added(Service B) added(Service B aspect) removed(Service B) When backed by a typical HashMap administration this would result in: put(B.id, B) put(B.id, B) remove(B.id) This sequence would result in an empty Map, which is not a desirable situation. In order to ease the dependency handling an additional callback method is needed which hides the complexity as described above and translates the callbacks to the following more functional callbacks: added; called when the service required has become available. swapped; called when the service required needs to be replaced due to add or removal of an aspect. This to be sure the component uses the aspect that's on top of the aspect chain for the required service. changed; called when the service properties of an added required service have changed. removed; called when the service required has become unavailable. With these callbacks a developer does not have to worry about the possible sequences in which added/removed can occur. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3198) Support generic configuration properties
[ https://issues.apache.org/jira/browse/FELIX-3198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13143892#comment-13143892 ] Felix Meschberger commented on FELIX-3198: -- In what respect standard or non-standard ? The OSGi Configuration Admin just provides a Dictionary of properties and the administrator/tool preparing the configuration can put in there what they like. As such this is IMHO along the lines of spec. Now, what is special here, of course, is that not all properties actually supported by the service are declared in the metatype descriptor. This of course prevents these properties from directly and easily be edited in a metatype based configuration GUI, such as the web console. Unless the tool allows for raw configuration property editing. While this might be bending the concepts a bit, I don't think it really violates any spec. As for the servlet context path: The path configured here is the path to which the servlet cookie is bound. By default this is the servlet context path but it can be narrowed down. This, of course, is a Jetty feature which technically probably violates the Servlet API spec. Same as the cookie name and request parameter name configurations, where spec reads rather strict: The names have to be JSESSIONID for the cookie and jsessionid for the request parameter. The session does not talk about the session cookie's domain directly, though. And we had customers actually asking for the session cookie's domain to be something different than the default. As a consequence: -- I think it is ok to support configuration parameters not exposed through Metatype -- In retrospect (and there is still time to fix this), I am not sure whether it is good to expose the session cookie name, parameter name and cooke path properties -- I think having the cookie domain and lifetime configurable is ok, though. WDYT ? > Support generic configuration properties > > > Key: FELIX-3198 > URL: https://issues.apache.org/jira/browse/FELIX-3198 > Project: Felix > Issue Type: Improvement > Components: HTTP Service >Affects Versions: http-2.2.0 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: http-2.2.2 > > > Currently the Jetty configuration only allows for a hard-coded limited sets > of properties provided in either the Configuration Admin configuration or as > framework properties. > Adding support for generic properties allows administrators to configure the > Servlet Container more specifically. Examples of such properties would be > Jetty specific session configuration. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
