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

Ron Koerner commented on FELIX-1114:
------------------------------------

It may be related to the fact that I used the ant task from 1.2.0... I got it 
running with a minimal test, but not yet with the real application.
I'll keep you updated.



> callback after configuration change needed
> ------------------------------------------
>
>                 Key: FELIX-1114
>                 URL: https://issues.apache.org/jira/browse/FELIX-1114
>             Project: Felix
>          Issue Type: Improvement
>          Components: iPOJO
>    Affects Versions: iPOJO-1.2.0
>            Reporter: Ron Koerner
>            Assignee: Clement Escoffier
>             Fix For: iPOJO-1.4.0
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> It often occurs that a configuration/property change requires some work to be 
> done. If only a single property is affected method injection can be used.
> If multiple properties are changed and these changes are kind of an atomic 
> transaction, there is no (sensible) way to tell the service to use the new 
> values.
> Imagine a service listening on a port and writing the output to a file. The 
> service has the two string properties "port" and "file". When the service is 
> validated, it opens a listening port and a writable file according to the 
> properties. Now imagine it is either dangerous to have a port input written 
> to the wrong file or opening ports and files is very costly or there is 
> already an object doing the work for us but it needs to be constructed with 
> port number and filename and cannot be changed at runtime. Therefore we 
> cannot use method injection like
> @Property(name="port")
> public void setPort(String port)
> {
>    incomingSocket.close();
>    incomingSocket=new IncomingSocket(port);
> }
> because that is costly and leaves the possibility to have things written to 
> the wrong file.
> Therefore something like
> @Updated
> public void updatedConfiguration()
> {
>   // put changed configuration in use
> }
> is needed. The method annotated with @Updated (or specified in XML) is to 
> called after all the configuration changes are done.
> Right now, the only way is to stop and start the service since only one 
> ManagedService per PID is recognized by ConfigurationAdmin.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to