[jira] Created: (FELIX-2279) Access to ServiceReference in iPOJO service
Access to ServiceReference in iPOJO service --- Key: FELIX-2279 URL: https://issues.apache.org/jira/browse/FELIX-2279 Project: Felix Issue Type: New Feature Components: iPOJO Affects Versions: iPOJO-1.4.0 Reporter: Bengt Rodehav As a convenience, it would be very useful for an iPOJO service to have access to its ServiceReference object. E g for logging purposes this is essential information. Assuming that the service has been registered prior to the @Validate method being called, it makes sense to provide the ServiceReference as an argument to this method. If the service is not registered until the @Valid method returns, then another callback (e g @Registered) is needed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (FELIX-2329) Improve the URL handling in features-maven-plugin regarding the add-features-to-repo goal
Improve the URL handling in features-maven-plugin regarding the add-features-to-repo goal - Key: FELIX-2329 URL: https://issues.apache.org/jira/browse/FELIX-2329 Project: Felix Issue Type: Improvement Components: Karaf Affects Versions: karaf-1.4.0 Reporter: Bengt Rodehav Presently the fatures-maven-plugin cannot handle URL's starting with anything else than "mvn:" and "wrap:". As long as "mvn:" exists later on in the URL, the protocols before "mvn:" could be skipped since they are not used for the add-features-to-repo goal. E g the following bundle definition should be possible to handle: ipojo:mvn:com.acme/artifact/1.0 A similar problem arises when references (beginning with "#") and parameters/queries (beginning with "?") are appended to the URL. E g the following bundle definition should be possible to handle: war:mvn:com.acme/war-artifact/1.0/war?Webapp-Context=my_context -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2329) Improve the URL handling in features-maven-plugin regarding the add-features-to-repo goal
[ https://issues.apache.org/jira/browse/FELIX-2329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12865049#action_12865049 ] Bengt Rodehav commented on FELIX-2329: -- Attached to this issue is a modified version of AddFeaturesToRepoMojo.java. I added two configuration parameters: - skipNonMavenProtocols: Setting this to true (false is default) causes the plugin to look for the first occurence of "mvn:" and start passing the url from there. This enables url's like "ipojo:mvn:com.acme/artifact/1.0". - skipUrlParameters: Setting this to true (false is default) causes the plugin to truncate the url if a "#" or a "?" is encountered. This enables url's like: "war:mvn:com.acme/war-artifact/1.0/war?Webapp-Context=my_context" I haven't contributed to Apache before so you might want to check the code extra carefully. Note that I haven't modified ValidateFeaturesMojo.java. I understand that it implements the validate-features goal. Does it need to be changed too? I haven't used it so I wouldn't know. Anyway, the attached version solves the problems I've had so far. > Improve the URL handling in features-maven-plugin regarding the > add-features-to-repo goal > - > > Key: FELIX-2329 > URL: https://issues.apache.org/jira/browse/FELIX-2329 > Project: Felix > Issue Type: Improvement > Components: Karaf >Affects Versions: karaf-1.4.0 >Reporter: Bengt Rodehav > > Presently the fatures-maven-plugin cannot handle URL's starting with anything > else than "mvn:" and "wrap:". As long as "mvn:" exists later on in the URL, > the protocols before "mvn:" could be skipped since they are not used for the > add-features-to-repo goal. E g the following bundle definition should be > possible to handle: > ipojo:mvn:com.acme/artifact/1.0 > A similar problem arises when references (beginning with "#") and > parameters/queries (beginning with "?") are appended to the URL. E g the > following bundle definition should be possible to handle: > war:mvn:com.acme/war-artifact/1.0/war?Webapp-Context=my_context -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2329) Improve the URL handling in features-maven-plugin regarding the add-features-to-repo goal
[ https://issues.apache.org/jira/browse/FELIX-2329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bengt Rodehav updated FELIX-2329: - Attachment: AddFeaturesToRepoMojo.java > Improve the URL handling in features-maven-plugin regarding the > add-features-to-repo goal > - > > Key: FELIX-2329 > URL: https://issues.apache.org/jira/browse/FELIX-2329 > Project: Felix > Issue Type: Improvement > Components: Karaf >Affects Versions: karaf-1.4.0 >Reporter: Bengt Rodehav > Attachments: AddFeaturesToRepoMojo.java > > > Presently the fatures-maven-plugin cannot handle URL's starting with anything > else than "mvn:" and "wrap:". As long as "mvn:" exists later on in the URL, > the protocols before "mvn:" could be skipped since they are not used for the > add-features-to-repo goal. E g the following bundle definition should be > possible to handle: > ipojo:mvn:com.acme/artifact/1.0 > A similar problem arises when references (beginning with "#") and > parameters/queries (beginning with "?") are appended to the URL. E g the > following bundle definition should be possible to handle: > war:mvn:com.acme/war-artifact/1.0/war?Webapp-Context=my_context -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2329) Improve the URL handling in features-maven-plugin regarding the add-features-to-repo goal
[ https://issues.apache.org/jira/browse/FELIX-2329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bengt Rodehav updated FELIX-2329: - Attachment: AddFeaturesToRepoMojo.diff Diff file containing the changes made to AddFeaturesToRepoMojo.java. > Improve the URL handling in features-maven-plugin regarding the > add-features-to-repo goal > - > > Key: FELIX-2329 > URL: https://issues.apache.org/jira/browse/FELIX-2329 > Project: Felix > Issue Type: Improvement > Components: Karaf >Affects Versions: karaf-1.4.0 >Reporter: Bengt Rodehav > Attachments: AddFeaturesToRepoMojo.diff, AddFeaturesToRepoMojo.java > > > Presently the fatures-maven-plugin cannot handle URL's starting with anything > else than "mvn:" and "wrap:". As long as "mvn:" exists later on in the URL, > the protocols before "mvn:" could be skipped since they are not used for the > add-features-to-repo goal. E g the following bundle definition should be > possible to handle: > ipojo:mvn:com.acme/artifact/1.0 > A similar problem arises when references (beginning with "#") and > parameters/queries (beginning with "?") are appended to the URL. E g the > following bundle definition should be possible to handle: > war:mvn:com.acme/war-artifact/1.0/war?Webapp-Context=my_context -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2329) Improve the URL handling in features-maven-plugin regarding the add-features-to-repo goal
[ https://issues.apache.org/jira/browse/FELIX-2329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12868556#action_12868556 ] Bengt Rodehav commented on FELIX-2329: -- Perfect - will test as soon as possible. Thanks, /Bengt > Improve the URL handling in features-maven-plugin regarding the > add-features-to-repo goal > - > > Key: FELIX-2329 > URL: https://issues.apache.org/jira/browse/FELIX-2329 > Project: Felix > Issue Type: Improvement > Components: Karaf >Affects Versions: karaf-1.4.0 >Reporter: Bengt Rodehav >Assignee: Guillaume Nodet > Fix For: karaf 1.6.0 > > Attachments: AddFeaturesToRepoMojo.diff, AddFeaturesToRepoMojo.java > > > Presently the fatures-maven-plugin cannot handle URL's starting with anything > else than "mvn:" and "wrap:". As long as "mvn:" exists later on in the URL, > the protocols before "mvn:" could be skipped since they are not used for the > add-features-to-repo goal. E g the following bundle definition should be > possible to handle: > ipojo:mvn:com.acme/artifact/1.0 > A similar problem arises when references (beginning with "#") and > parameters/queries (beginning with "?") are appended to the URL. E g the > following bundle definition should be possible to handle: > war:mvn:com.acme/war-artifact/1.0/war?Webapp-Context=my_context -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2366) Avoiding property substitution by escaping does not remove escape character
Avoiding property substitution by escaping does not remove escape character
---
Key: FELIX-2366
URL: https://issues.apache.org/jira/browse/FELIX-2366
Project: Felix
Issue Type: Bug
Components: File Install
Affects Versions: fileinstall-3.0.0
Reporter: Bengt Rodehav
To avoid property substitution, an escape character was introduced in version
3.0.0 of File Install. The idea is that if I want to send the configuration
value
${propkey}
to my application without property substitution to take place, I can escape the
START_DELIM (${) and STOP_DELIM (}) with a backslash as follows:
$\{propkey\}
However, when doing this the escape character is not removed from the string.
The reason is as follows:
The method of interest is substVars in class
org.apache.felix.fileinstall.internal.Util. The logic tries to find matching
DELIM_START (${) and DELIM_STOP (}). When you escape either of these (by
specifying a backslash before "${" and/or "}"), the logic will never find
matching DELIM_START and DELIM_STOP which causes the method to immediately
return without performing property substitution. The logic at the end of the
method (that removes the backslashes) is never reached.
A workarount is to add an unnecessary property at the end of the value just to
make sure some property substitution will take place since then the logic at
the end of the substVars() method (that removes the escape character) will be
reached. Thus, this works:
$\{propkey\}${#}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2371) features-maven-plugin cannot handle classifiers
features-maven-plugin cannot handle classifiers --- Key: FELIX-2371 URL: https://issues.apache.org/jira/browse/FELIX-2371 Project: Felix Issue Type: Bug Components: Karaf Affects Versions: karaf 1.6.0 Reporter: Bengt Rodehav features-maven-plugin does not take the classifier into account when resolving the artifact. This is due to an incorrect usage of the ArtifactFactory in the class AddFeaturesToRepoMojo. The call: artifact = this.factory.createArtifact(groupId, artifactId, version, (classifier != null ? classifier : ""), type); shall instead be: artifact = this.factory.createArtifactWithClassifier(groupId, artifactId, version, type, classifier); Sincel most Karaf feature files are attached to the main artifact using a classifier, the feature files themselves cannot be resolved which makes the plugin impossible to use. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2371) features-maven-plugin cannot handle classifiers
[ https://issues.apache.org/jira/browse/FELIX-2371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bengt Rodehav updated FELIX-2371: - Attachment: AddFeaturesToRepoMojo.diff A diff file containing the required changes. > features-maven-plugin cannot handle classifiers > --- > > Key: FELIX-2371 > URL: https://issues.apache.org/jira/browse/FELIX-2371 > Project: Felix > Issue Type: Bug > Components: Karaf >Affects Versions: karaf 1.6.0 >Reporter: Bengt Rodehav > Attachments: AddFeaturesToRepoMojo.diff > > > features-maven-plugin does not take the classifier into account when > resolving the artifact. This is due to an incorrect usage of the > ArtifactFactory in the class AddFeaturesToRepoMojo. The call: > artifact = this.factory.createArtifact(groupId, artifactId, version, > (classifier != null ? classifier : ""), type); > shall instead be: > artifact = this.factory.createArtifactWithClassifier(groupId, artifactId, > version, type, classifier); > Sincel most Karaf feature files are attached to the main artifact using a > classifier, the feature files themselves cannot be resolved which makes the > plugin impossible to use. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2373) Wrapper service is not configured properly in Karaf 1.6.0
Wrapper service is not configured properly in Karaf 1.6.0 - Key: FELIX-2373 URL: https://issues.apache.org/jira/browse/FELIX-2373 Project: Felix Issue Type: Bug Components: Karaf Affects Versions: karaf 1.6.0 Reporter: Bengt Rodehav Changes related to Karaf startup has been done in Karaf 1.6.0 but those changes have not been reflected in the configuration of the Wrapper service. I had to do the following changes in "karaf-wrapper.conf" to get Karaf 1.6.0 to work with the Wrapper service: a) Change the main class: wrapper.app.parameter.1=org.apache.felix.karaf.main.Main b) Add the following line to the classpath: wrapper.java.classpath.4=%KARAF_HOME%/system/org/apache/felix/org.apache.felix.framework/2.0.5/org.apache.felix.framework-2.0.5.jar c) Add the following JVM parameters: wrapper.java.additional.6=-Djava.endorsed.dirs="%JAVA_HOME%/lib/endorsed;%KARAF_HOME%/lib/endorsed" wrapper.java.additional.7=-Djava.ext.dirs="%JAVA_HOME%/lib/ext;%KARAF_HOME%/lib/ext" Actually "c)" wasn't really necessary to get Karaf started but it seemed to have been omitted in comparison to "karaf.bat". Overall I think someone should compare the settings in "karaf.bat" with the ones in "karaf-wrapper.conf" to make sure they are the same. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2389) Problems with security extensions in Karaf 1.6.0
Problems with security extensions in Karaf 1.6.0 Key: FELIX-2389 URL: https://issues.apache.org/jira/browse/FELIX-2389 Project: Felix Issue Type: Bug Components: Karaf Affects Versions: karaf 1.6.0 Reporter: Bengt Rodehav I'm using camel-ftp for secure ftps connections. This requires encryption and thus access to extensions. Karaf.bat sets the following system property on the java command line: -Djava.ext.dirs="%JAVA_HOME%\lib\ext;%KARAF_HOME%\lib\ext" In the environments I have encountered, a JRE has also been installed as part of the JDK. In those cases the extensions are located under the JRE's lib\ext directory. If that is not included in "java.ext.dirs", then the security extensions will not be found. I made the following change to karaf.bat: -Djava.ext.dirs="%JAVA_HOME%\jre\lib\ext;%JAVA_HOME%\lib\ext;%KARAF_HOME%\lib\ext" ...and the following change to karaf-wrapper.conf: wrapper.java.additional.7=-Djava.ext.dirs="%JAVA_HOME%\jre\lib\ext;%JAVA_HOME%/lib/ext;%KARAF_HOME%/lib/ext" Note that in Karaf 1.6.0, java.ext.dirs is not specified at all in karaf-wrapper.conf. This has been reported in https://issues.apache.org/jira/browse/FELIX-2373. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2636) Cannot control the validity of an iPOJO instance using a configuration property
Cannot control the validity of an iPOJO instance using a configuration property --- Key: FELIX-2636 URL: https://issues.apache.org/jira/browse/FELIX-2636 Project: Felix Issue Type: Bug Components: iPOJO Affects Versions: iPOJO-1.4.0 Reporter: Bengt Rodehav Controlling the validity of an iPOJO instance as follows doesn't work: @Controller @Property(name = "connect.enabled", mandatory = true) private boolean mValid = false; When initialising mValid to false (as above), the iPOJO instance becomes invalid even though the configuration property (connect.enabled in this case) is true. On the other hand, if the following code is used... @Controller @Property(name = "connect.enabled", mandatory = true) private boolean mValid = true; ...then the instance becomes valid even though the configuration property is false. I use Karaf 1.6.0 with file installer 3.0.2 in the scenario above. The problem only occurs when starting Karaf. Subsequent changes of the configuration property will change the validity of the instance correctly. The problem does not show when using iPOJO 1.6.0 but it's still important to make sure that the above described scenario is supported by iPOJO. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2636) Cannot control the validity of an iPOJO instance using a configuration property
[ https://issues.apache.org/jira/browse/FELIX-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12919058#action_12919058 ] Bengt Rodehav commented on FELIX-2636: -- Great Clement! I'll try the latest trunk tomorrow. /Bengt > Cannot control the validity of an iPOJO instance using a configuration > property > --- > > Key: FELIX-2636 > URL: https://issues.apache.org/jira/browse/FELIX-2636 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: iPOJO-1.4.0 >Reporter: Bengt Rodehav >Assignee: Clement Escoffier > Fix For: iPOJO-1.8.0 > > > Controlling the validity of an iPOJO instance as follows doesn't work: > @Controller > @Property(name = "connect.enabled", mandatory = true) > private boolean mValid = false; > When initialising mValid to false (as above), the iPOJO instance becomes > invalid even though the configuration property (connect.enabled in this case) > is true. > On the other hand, if the following code is used... > @Controller > @Property(name = "connect.enabled", mandatory = true) > private boolean mValid = true; > ...then the instance becomes valid even though the configuration property is > false. > I use Karaf 1.6.0 with file installer 3.0.2 in the scenario above. The > problem only occurs when starting Karaf. Subsequent changes of the > configuration property will change the validity of the instance correctly. > The problem does not show when using iPOJO 1.6.0 but it's still important to > make sure that the above described scenario is supported by iPOJO. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2636) Cannot control the validity of an iPOJO instance using a configuration property
[ https://issues.apache.org/jira/browse/FELIX-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12919186#action_12919186 ] Bengt Rodehav commented on FELIX-2636: -- I've tried the latest trunk now. Seems to be 1.7.0-SNAPSHOT and not 1.8.0-SNAPSHOT which this JIRA indicates. It works! Great job Clement. I still have a couple of questions though: 1. INITIALISATION I presently use the following code: @Controller @Property(name = "connect.enabled", mandatory = true) private boolean mValid = true; Do I really have to initialise the mValid field? If yes, should I initialise it to true or false? My reasoning is like this: Since this is a mandatory property, the instance will not be valid until it gets a value from configuration manager. Thus I shouldn't have to initialise it at all. Is this reasoning correct? 2. FILE INSTALL vs BUNDLE CACHE I use file install to control my configuration. Thus I can change the configuration (the "connect.enabled" property) from either file install or directly in configuration manager (using the Webconsole or my own GUI). Which takes precedence on startup? My tests indicate that what I specify in file install will be used even when configuration manager's cache differ from this value. Is this by accident or is this the way it will always work? I think I can live with either way as long as it's deterministic. 3. RELEASE When do you think this fix will be available in an iPOJO release. I would like to get it into production as soon as possible since we've had incidents in production regarding this issue. > Cannot control the validity of an iPOJO instance using a configuration > property > --- > > Key: FELIX-2636 > URL: https://issues.apache.org/jira/browse/FELIX-2636 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: iPOJO-1.4.0 >Reporter: Bengt Rodehav >Assignee: Clement Escoffier > Fix For: iPOJO-1.8.0 > > > Controlling the validity of an iPOJO instance as follows doesn't work: > @Controller > @Property(name = "connect.enabled", mandatory = true) > private boolean mValid = false; > When initialising mValid to false (as above), the iPOJO instance becomes > invalid even though the configuration property (connect.enabled in this case) > is true. > On the other hand, if the following code is used... > @Controller > @Property(name = "connect.enabled", mandatory = true) > private boolean mValid = true; > ...then the instance becomes valid even though the configuration property is > false. > I use Karaf 1.6.0 with file installer 3.0.2 in the scenario above. The > problem only occurs when starting Karaf. Subsequent changes of the > configuration property will change the validity of the instance correctly. > The problem does not show when using iPOJO 1.6.0 but it's still important to > make sure that the above described scenario is supported by iPOJO. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2636) Cannot control the validity of an iPOJO instance using a configuration property
[ https://issues.apache.org/jira/browse/FELIX-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12919249#action_12919249 ] Bengt Rodehav commented on FELIX-2636: -- Thanks a lot Clement. Yes, you'r right, the FILE INSTALL vs BUNDLE CACHE question is better suited for the mailing list since it's not really connected to this issue (not connected to iPOJO at all probably). Looking forward to the release. > Cannot control the validity of an iPOJO instance using a configuration > property > --- > > Key: FELIX-2636 > URL: https://issues.apache.org/jira/browse/FELIX-2636 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: iPOJO-1.4.0 >Reporter: Bengt Rodehav >Assignee: Clement Escoffier > Fix For: iPOJO-1.8.0 > > > Controlling the validity of an iPOJO instance as follows doesn't work: > @Controller > @Property(name = "connect.enabled", mandatory = true) > private boolean mValid = false; > When initialising mValid to false (as above), the iPOJO instance becomes > invalid even though the configuration property (connect.enabled in this case) > is true. > On the other hand, if the following code is used... > @Controller > @Property(name = "connect.enabled", mandatory = true) > private boolean mValid = true; > ...then the instance becomes valid even though the configuration property is > false. > I use Karaf 1.6.0 with file installer 3.0.2 in the scenario above. The > problem only occurs when starting Karaf. Subsequent changes of the > configuration property will change the validity of the instance correctly. > The problem does not show when using iPOJO 1.6.0 but it's still important to > make sure that the above described scenario is supported by iPOJO. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2694) Instance state not recomputed after reconfiguration when the instance is stopped
[ https://issues.apache.org/jira/browse/FELIX-2694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12932660#action_12932660 ] Bengt Rodehav commented on FELIX-2694: -- I've tested against trunk again. Turns out that i had tested against 1.5.0-SNAPSHOT (the version of iPOJO parent) and not against 1.7.0-SNAPSHOT (the version of iPOJO core) - I had looked in the wron pom.xml for the version of iPOJO to use. It seems to work now so this issue can be closed. Sorry for my mistake... > Instance state not recomputed after reconfiguration when the instance is > stopped > > > Key: FELIX-2694 > URL: https://issues.apache.org/jira/browse/FELIX-2694 > Project: Felix > Issue Type: Bug > Components: iPOJO >Reporter: Clement Escoffier >Assignee: Clement Escoffier > Fix For: iPOJO-1.8.0 > > > When a component instance is stopped and reconfigured, the instance state is > not recomputed. The instance must be restarted with the new configuration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2694) Instance state not recomputed after reconfiguration when the instance is stopped
[
https://issues.apache.org/jira/browse/FELIX-2694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12932884#action_12932884
]
Bengt Rodehav commented on FELIX-2694:
--
Unfortunately there seems to still be some problems regarding this.
Consider this scenario:
1. I create an invalid configuration, that will cause my start() method to
throw an exception.
2. iPOJO stops the instance
3. I repair my configuration
4. iPOJO recognizes a configuration change and calls my start() method again
5. At this point, my configuration settings do not seem to be set.
E g I have these configuration settings:
private String mName;
private String mPid;
@Property(name = "name", mandatory = true)
public void setName(String theName) {
mName = theName;
}
@Property(name = org.osgi.framework.Constants.SERVICE_PID, mandatory = true)
public void setPid(String thePid) {
mPid = thePid;
}
Normally (when my instance is successfully started the first time), these
values are correctly initialised in my start() method. However, in the scenario
described above, these values are null. This causes the start() method to fail
again.
> Instance state not recomputed after reconfiguration when the instance is
> stopped
>
>
> Key: FELIX-2694
> URL: https://issues.apache.org/jira/browse/FELIX-2694
> Project: Felix
> Issue Type: Bug
> Components: iPOJO
>Reporter: Clement Escoffier
>Assignee: Clement Escoffier
> Fix For: iPOJO-1.8.0
>
>
> When a component instance is stopped and reconfigured, the instance state is
> not recomputed. The instance must be restarted with the new configuration.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2694) Instance state not recomputed after reconfiguration when the instance is stopped
[ https://issues.apache.org/jira/browse/FELIX-2694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12933344#action_12933344 ] Bengt Rodehav commented on FELIX-2694: -- Works perfectly Clement - excellent job! Now I just have to wait for the next release - any plans? > Instance state not recomputed after reconfiguration when the instance is > stopped > > > Key: FELIX-2694 > URL: https://issues.apache.org/jira/browse/FELIX-2694 > Project: Felix > Issue Type: Bug > Components: iPOJO >Reporter: Clement Escoffier >Assignee: Clement Escoffier > Fix For: iPOJO-1.8.0 > > > When a component instance is stopped and reconfigured, the instance state is > not recomputed. The instance must be restarted with the new configuration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2694) Instance state not recomputed after reconfiguration when the instance is stopped
[ https://issues.apache.org/jira/browse/FELIX-2694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12934446#action_12934446 ] Bengt Rodehav commented on FELIX-2694: -- Sounds really good. Thanks Clement. > Instance state not recomputed after reconfiguration when the instance is > stopped > > > Key: FELIX-2694 > URL: https://issues.apache.org/jira/browse/FELIX-2694 > Project: Felix > Issue Type: Bug > Components: iPOJO >Reporter: Clement Escoffier >Assignee: Clement Escoffier > Fix For: iPOJO-1.8.0 > > > When a component instance is stopped and reconfigured, the instance state is > not recomputed. The instance must be restarted with the new configuration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2773) Automatic restart of iPOJO instance on configuration update
Automatic restart of iPOJO instance on configuration update --- Key: FELIX-2773 URL: https://issues.apache.org/jira/browse/FELIX-2773 Project: Felix Issue Type: Improvement Components: iPOJO Affects Versions: iPOJO-1.6.0 Reporter: Bengt Rodehav Priority: Minor I use iPOJO and configuration admin. When certain configuration properties change, I want to "restart" my iPOJO instance. I e I want the instance to become invalid and then valid again. Currently I do some initialisation on the method marked as @Validate and some cleanup in the method marked as @Invalidate. It's very tricky to get this to work. When I start my application it seems like both the @Validate and the @Updated methods are called which causes problems. Ideally I would like to mark my iPOJO properties as requiring the instance to "restart", e g @Property(name = "rootUrl", restart = "true") private String mRootUrl; Whenever the "rootUrl" property of my instance is reconfigured, the iPOJO instance would be invalidated and then validated again (if it is valid of course). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] [Created] (FELIX-3487) Variables are not preserved during write-back if they are defined as framework properties
Bengt Rodehav created FELIX-3487: Summary: Variables are not preserved during write-back if they are defined as framework properties Key: FELIX-3487 URL: https://issues.apache.org/jira/browse/FELIX-3487 Project: Felix Issue Type: Improvement Components: File Install Affects Versions: fileinstall-3.2.2 Environment: Karaf 2.2.5 Reporter: Bengt Rodehav Priority: Minor Fileinstall tries to only write back (to the configuration file) properties that have been changed. This fails if the value uses a property that is defined as a framework property (accessible via BundleContext.getProperty). In theory file install does support this but when handling configuration changes, the framework properties are not taken into account. E g this is the case when using Karaf and defining properties in config.properties. This has been discussed on Felix user mailing list, see: http://www.mail-archive.com/users@felix.apache.org/msg12281.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3487) Variables are not preserved during write-back if they are defined as framework properties
[ https://issues.apache.org/jira/browse/FELIX-3487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bengt Rodehav updated FELIX-3487: - Attachment: ConfigInstaller.patch Properties.patch Note that the utils project must first be released. The pom.xml in the fileinstall project must then be changed to use the new version of the utils project. > Variables are not preserved during write-back if they are defined as > framework properties > - > > Key: FELIX-3487 > URL: https://issues.apache.org/jira/browse/FELIX-3487 > Project: Felix > Issue Type: Improvement > Components: File Install >Affects Versions: fileinstall-3.2.2 > Environment: Karaf 2.2.5 >Reporter: Bengt Rodehav >Priority: Minor > Attachments: ConfigInstaller.patch, Properties.patch > > > Fileinstall tries to only write back (to the configuration file) properties > that have been changed. This fails if the value uses a property that is > defined as a framework property (accessible via BundleContext.getProperty). > In theory file install does support this but when handling configuration > changes, the framework properties are not taken into account. > E g this is the case when using Karaf and defining properties in > config.properties. > This has been discussed on Felix user mailing list, see: > http://www.mail-archive.com/users@felix.apache.org/msg12281.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-3488) Improve documentation for the felix.fileinstall.enableConfigSave property
Bengt Rodehav created FELIX-3488: Summary: Improve documentation for the felix.fileinstall.enableConfigSave property Key: FELIX-3488 URL: https://issues.apache.org/jira/browse/FELIX-3488 Project: Felix Issue Type: Improvement Components: File Install Affects Versions: fileinstall-3.2.2 Reporter: Bengt Rodehav Priority: Minor The fileinstall documentation on the web gives the impression that the felix.fileinstall.enableConfigSave property can be configured per fileinstall configuration factory. This is not the case since it is stored as a framework property and is therefore global. It seems that the first configuration will be used (I have not verified this). This has been discussed on the mailing list: http://www.mail-archive.com/users@felix.apache.org/msg12279.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-3489) Make it possible to specify the felix.fileinstall.enableConfigSave per directory
Bengt Rodehav created FELIX-3489: Summary: Make it possible to specify the felix.fileinstall.enableConfigSave per directory Key: FELIX-3489 URL: https://issues.apache.org/jira/browse/FELIX-3489 Project: Felix Issue Type: New Feature Components: File Install Affects Versions: fileinstall-3.2.2 Reporter: Bengt Rodehav Priority: Minor It would be nice to have the possibility to specify per directory whether configuration changes should be written back to the configuration file or not. This has been discussed on the mailing list: http://www.mail-archive.com/users@felix.apache.org/msg12279.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-4332) Incorrect evalution of variables
Bengt Rodehav created FELIX-4332:
Summary: Incorrect evalution of variables
Key: FELIX-4332
URL: https://issues.apache.org/jira/browse/FELIX-4332
Project: Felix
Issue Type: Bug
Components: File Install
Affects Versions: fileinstall-3.2.6
Environment: Apache Karaf 2.3.3
Windows 7
Reporter: Bengt Rodehav
When using variables (${}) in configuration files in combination with the
escape character (\), the variables are sometimes evaluated when they shall
not. This can also fool FileInstall into believing that a property has been
changed and therefore incorrectly modify the configuration file.
This has been described in more detail in the following conversation on the
Felix user mailing list:
http://www.mail-archive.com/users@felix.apache.org/msg14804.html
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (FELIX-4338) Incorrect overwriting of properties that have not been changed
Bengt Rodehav created FELIX-4338: Summary: Incorrect overwriting of properties that have not been changed Key: FELIX-4338 URL: https://issues.apache.org/jira/browse/FELIX-4338 Project: Felix Issue Type: Bug Components: File Install Affects Versions: fileinstall-3.2.6 Reporter: Bengt Rodehav Fileinstall sometimes, incorrectly, believes that a property has been changed and thus overwrites it (if FileInstall is configured to write back configration changes) in the configuration file. This is because the configuration file is parsed differently on the original reading of the configuration file compared with the reading when a configuration has been updated. This has been described in more detail in the following conversation on the Felix user mailing list: http://www.mail-archive.com/users@felix.apache.org/msg14804.html -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (FELIX-4338) Incorrect overwriting of properties that have not been changed
[ https://issues.apache.org/jira/browse/FELIX-4338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bengt Rodehav updated FELIX-4338: - Attachment: ConfigInstaller.java.patch Changes the setConfig() method to parse the configuration file the same way that the method configurationEvent() does. This ensures that properties are always evaluated the same way. The only drawback is that configuration files in XML format is not supported. On the other hand, they cannot have been supported before either since the setConfig() method didn't support them. > Incorrect overwriting of properties that have not been changed > -- > > Key: FELIX-4338 > URL: https://issues.apache.org/jira/browse/FELIX-4338 > Project: Felix > Issue Type: Bug > Components: File Install >Affects Versions: fileinstall-3.2.6 >Reporter: Bengt Rodehav > Attachments: ConfigInstaller.java.patch > > > Fileinstall sometimes, incorrectly, believes that a property has been changed > and thus overwrites it (if FileInstall is configured to write back > configration changes) in the configuration file. > This is because the configuration file is parsed differently on the original > reading of the configuration file compared with the reading when a > configuration has been updated. > This has been described in more detail in the following conversation on the > Felix user mailing list: > http://www.mail-archive.com/users@felix.apache.org/msg14804.html -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (FELIX-4339) Make the use of escape characters deterministic
Bengt Rodehav created FELIX-4339: Summary: Make the use of escape characters deterministic Key: FELIX-4339 URL: https://issues.apache.org/jira/browse/FELIX-4339 Project: Felix Issue Type: Improvement Components: File Install Affects Versions: fileinstall-3.2.6 Reporter: Bengt Rodehav The number of escape characters needed depends on from where the property is referenced. This is because the substitution of variables can be done several times for each property causing escaped characters to become unescaped. This is not trivial to fix but I think that some kind of deterministic behavior must be supported. This has been described in more detail in the following conversation on the Felix user mailing list: http://www.mail-archive.com/users@felix.apache.org/msg14804.html -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (FELIX-4351) @Updated does not pass the current configuration
Bengt Rodehav created FELIX-4351:
Summary: @Updated does not pass the current configuration
Key: FELIX-4351
URL: https://issues.apache.org/jira/browse/FELIX-4351
Project: Felix
Issue Type: Bug
Components: iPOJO
Affects Versions: ipojo-runtime-1.11.0
Reporter: Bengt Rodehav
iPojo can inform the instance about configuration changes via the @Updated
annotation as follows:
@Updated
public void updated(Dictionary conf) {
// Do something
}
However, the "conf" parameter does not seem to contain the current
configuration but the default configuration (the configuration that was used
when the instance was created).
This has been discussed on the Felix user list:
http://www.mail-archive.com/users%40felix.apache.org/msg14902.html
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Created] (FELIX-4432) DefaultServiceRankingInterceptor holds duplicate dependencies
Bengt Rodehav created FELIX-4432: Summary: DefaultServiceRankingInterceptor holds duplicate dependencies Key: FELIX-4432 URL: https://issues.apache.org/jira/browse/FELIX-4432 Project: Felix Issue Type: Bug Components: iPOJO Affects Versions: ipojo-runtime-1.11.1 Reporter: Bengt Rodehav Priority: Minor It seems like every dependency is duplicated in the member "dependencies" in class DefaultServiceRankingInterceptor. This has been discussed on the mailing list: http://www.mail-archive.com/users@felix.apache.org/msg15121.html -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (FELIX-6502) IPOJO Java 11+ support
[ https://issues.apache.org/jira/browse/FELIX-6502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507040#comment-17507040 ] Bengt Rodehav commented on FELIX-6502: -- I have done some testing regarding this fix and after updating to Asm 9.2 iPojo now works with OpenJDK 17. I would really like for a new release of iPojo including this fix to be made. > IPOJO Java 11+ support > -- > > Key: FELIX-6502 > URL: https://issues.apache.org/jira/browse/FELIX-6502 > Project: Felix > Issue Type: Improvement > Components: iPOJO >Reporter: Alexander Shaklein >Priority: Minor > > I have made some changes in ipojo projects to work in java 11+. > The were successfully tested on java 11, 16. Should i make a PR or i can work > with fork alone? -- This message was sent by Atlassian Jira (v8.20.1#820001)
