[jira] [Created] (FELIX-3834) Create separate language fragment bundles
Felix Meschberger created FELIX-3834: Summary: Create separate language fragment bundles Key: FELIX-3834 URL: https://issues.apache.org/jira/browse/FELIX-3834 Project: Felix Issue Type: Task Components: Web Console Affects Versions: webconsole-4.0.0 Reporter: Felix Meschberger Assignee: Felix Meschberger Upto now the web console bundle itself provides the basic (english) labels as well as translations for bulgarian, german, and russian. Additional translations can be added as fragments. To ease translation maintenance I suggest to break out the existing translations into separate fragment bundles. The default language (english) remains part of the web console bundle. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3834) Create separate language fragment bundles
[ https://issues.apache.org/jira/browse/FELIX-3834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-3834: - Attachment: FELIX-3834.patch Proposed patch: * create webconsole-l10n folder * create bg, de, and ru projects * move respective bundle_xx.properties and xx.gif flags * copy and adapt appended (license) resources Create separate language fragment bundles - Key: FELIX-3834 URL: https://issues.apache.org/jira/browse/FELIX-3834 Project: Felix Issue Type: Task Components: Web Console Affects Versions: webconsole-4.0.0 Reporter: Felix Meschberger Assignee: Felix Meschberger Attachments: FELIX-3834.patch Upto now the web console bundle itself provides the basic (english) labels as well as translations for bulgarian, german, and russian. Additional translations can be added as fragments. To ease translation maintenance I suggest to break out the existing translations into separate fragment bundles. The default language (english) remains part of the web console bundle. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[WebConsole] breaking out localizations
Hi The Web Console currently embeds the english (default) labels as well as bulgarian, german, and russian translations. Other languages/translations may be added as fragments to the web console. To ease translation work and selection of supported languages, I suggest we also break out the existing translations into separate fragment bundles. Each fragment basically has the translation strings as well as the flag representing the language. I have created FELIX-3834 [1] with an attached patch explaining the changes. WDYT ? Regards Felix
[jira] [Assigned] (FELIX-3820) Possible NPE in ConfigAdmin after shutting down when accessed by bad behaving bundles
[
https://issues.apache.org/jira/browse/FELIX-3820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger reassigned FELIX-3820:
Assignee: Felix Meschberger
Possible NPE in ConfigAdmin after shutting down when accessed by bad behaving
bundles
-
Key: FELIX-3820
URL: https://issues.apache.org/jira/browse/FELIX-3820
Project: Felix
Issue Type: Bug
Components: Configuration Admin
Reporter: Guillaume Nodet
Assignee: Felix Meschberger
Priority: Minor
Attachments: FELIX-3820.patch
When a bundle accesses the ConfigAdmin service while or after it has been
stopped, NPE can occur because the internal
ConfigurationAdminImpl#configurationManager field has been nulled.
While this is a minor issue, it would be better to throw a nicer exception
indicating the COnfigAdmin service has been stopped.
This is mostly for bad behaving bundles that do not react to the service
being unregistered though, so it's really a minor issue
{code}
at
org.apache.felix.cm.impl.ConfigurationAdminImpl.listConfigurations(ConfigurationAdminImpl.java:166)
at
org.apache.felix.fileinstall.internal.ConfigInstaller.findExistingConfiguration(ConfigInstaller.java:346)
at
org.apache.felix.fileinstall.internal.ConfigInstaller.getConfiguration(ConfigInstaller.java:320)
at
org.apache.felix.fileinstall.internal.ConfigInstaller.setConfig(ConfigInstaller.java:245)
at
org.apache.felix.fileinstall.internal.ConfigInstaller.install(ConfigInstaller.java:84)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:929)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:857)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:483)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.start(DirectoryWatcher.java:224)
at
org.apache.felix.fileinstall.internal.FileInstall.updated(FileInstall.java:252)
at
org.apache.felix.fileinstall.internal.FileInstall.start(FileInstall.java:139)
at
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:645)
at org.apache.felix.framework.Felix.doActivateBundle(Felix.java:2259)
at org.apache.felix.framework.Felix$7.call(Felix.java:2197)
at org.apache.felix.framework.Felix$6.call(Felix.java:2141)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3820) Possible NPE in ConfigAdmin after shutting down when accessed by bad behaving bundles
[
https://issues.apache.org/jira/browse/FELIX-3820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger updated FELIX-3820:
-
Affects Version/s: configadmin-1.6.0
Possible NPE in ConfigAdmin after shutting down when accessed by bad behaving
bundles
-
Key: FELIX-3820
URL: https://issues.apache.org/jira/browse/FELIX-3820
Project: Felix
Issue Type: Bug
Components: Configuration Admin
Affects Versions: configadmin-1.6.0
Reporter: Guillaume Nodet
Assignee: Felix Meschberger
Priority: Minor
Attachments: FELIX-3820.patch
When a bundle accesses the ConfigAdmin service while or after it has been
stopped, NPE can occur because the internal
ConfigurationAdminImpl#configurationManager field has been nulled.
While this is a minor issue, it would be better to throw a nicer exception
indicating the COnfigAdmin service has been stopped.
This is mostly for bad behaving bundles that do not react to the service
being unregistered though, so it's really a minor issue
{code}
at
org.apache.felix.cm.impl.ConfigurationAdminImpl.listConfigurations(ConfigurationAdminImpl.java:166)
at
org.apache.felix.fileinstall.internal.ConfigInstaller.findExistingConfiguration(ConfigInstaller.java:346)
at
org.apache.felix.fileinstall.internal.ConfigInstaller.getConfiguration(ConfigInstaller.java:320)
at
org.apache.felix.fileinstall.internal.ConfigInstaller.setConfig(ConfigInstaller.java:245)
at
org.apache.felix.fileinstall.internal.ConfigInstaller.install(ConfigInstaller.java:84)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:929)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:857)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:483)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.start(DirectoryWatcher.java:224)
at
org.apache.felix.fileinstall.internal.FileInstall.updated(FileInstall.java:252)
at
org.apache.felix.fileinstall.internal.FileInstall.start(FileInstall.java:139)
at
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:645)
at org.apache.felix.framework.Felix.doActivateBundle(Felix.java:2259)
at org.apache.felix.framework.Felix$7.call(Felix.java:2197)
at org.apache.felix.framework.Felix$6.call(Felix.java:2141)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-3820) Possible NPE in ConfigAdmin after shutting down when accessed by bad behaving bundles
[
https://issues.apache.org/jira/browse/FELIX-3820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger resolved FELIX-3820.
--
Resolution: Fixed
Fix Version/s: configadmin-1.6.2
Thanks for the patch.
I have applied a slightly modified version (using a local variable to prevent
repeated checks) in Rev. 747165 and added integration tests. In addition I
extended the guard for the permission checks.
Possible NPE in ConfigAdmin after shutting down when accessed by bad behaving
bundles
-
Key: FELIX-3820
URL: https://issues.apache.org/jira/browse/FELIX-3820
Project: Felix
Issue Type: Bug
Components: Configuration Admin
Affects Versions: configadmin-1.6.0
Reporter: Guillaume Nodet
Assignee: Felix Meschberger
Priority: Minor
Fix For: configadmin-1.6.2
Attachments: FELIX-3820.patch
When a bundle accesses the ConfigAdmin service while or after it has been
stopped, NPE can occur because the internal
ConfigurationAdminImpl#configurationManager field has been nulled.
While this is a minor issue, it would be better to throw a nicer exception
indicating the COnfigAdmin service has been stopped.
This is mostly for bad behaving bundles that do not react to the service
being unregistered though, so it's really a minor issue
{code}
at
org.apache.felix.cm.impl.ConfigurationAdminImpl.listConfigurations(ConfigurationAdminImpl.java:166)
at
org.apache.felix.fileinstall.internal.ConfigInstaller.findExistingConfiguration(ConfigInstaller.java:346)
at
org.apache.felix.fileinstall.internal.ConfigInstaller.getConfiguration(ConfigInstaller.java:320)
at
org.apache.felix.fileinstall.internal.ConfigInstaller.setConfig(ConfigInstaller.java:245)
at
org.apache.felix.fileinstall.internal.ConfigInstaller.install(ConfigInstaller.java:84)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:929)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:857)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:483)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.start(DirectoryWatcher.java:224)
at
org.apache.felix.fileinstall.internal.FileInstall.updated(FileInstall.java:252)
at
org.apache.felix.fileinstall.internal.FileInstall.start(FileInstall.java:139)
at
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:645)
at org.apache.felix.framework.Felix.doActivateBundle(Felix.java:2259)
at org.apache.felix.framework.Felix$7.call(Felix.java:2197)
at org.apache.felix.framework.Felix$6.call(Felix.java:2141)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3607) ThreadIO doesn't utilize changed system streams after bundle activation
[ https://issues.apache.org/jira/browse/FELIX-3607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-3607: - Component/s: (was: Configuration Admin) ThreadIO doesn't utilize changed system streams after bundle activation --- Key: FELIX-3607 URL: https://issues.apache.org/jira/browse/FELIX-3607 Project: Felix Issue Type: Bug Components: Gogo Runtime Affects Versions: gogo.runtime-0.12.0 Reporter: Tuomas Kiviaho Priority: Minor Attachments: gogo-runtime.patch I use maven failsafe to run integration test fragments inside external osgi framework and remote gogo is used to bridge forked failsafe execution with a bundled failsafe junit provider. Everything has worked fine until I noticed that once executing thread changes. Then I seem to start receiving surefire/failsafe directives along with whatever is printed to system streams. When thread execution stays the same there is no problem 'Hello World' - server[failsafe] - '3,0001,Hello World' - server[telnetconsole] - '3,0001,Hello World' - client[telnetconsole] - '3,0001,Hello World' - client[failsafe] - 'Hello World' but thread changes due to using log service for instance then the message isn't coming back (which is perfectly normal) but instead is poured over to System.out 'Hello World' - server[logservice] - 'Hello World' - server[loglistener] - // here we have a different thread 'Hello World' - server[failsafe] - '3,0001,Hello World' - server[telnetconsole] - '3,0001,Hello World' - System.out // and here thread local can't be found so System.out is used as fallback mechanism or that's what I think was meant to be. Actually the printing is done to some ancient System.out that was set during the bundle got active. Failsafe infact pushes and pops the System.out in between without Gogo noticing it. This kind of possiblility could be taken into account by wrapping the system in, out and error to a dedicated FilteredStreams that use the previously obtained streams in case system streams do not point to ThreadIOImpl's err,out and in anymore. The close() method already contains similar logic. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3607) ThreadIO doesn't utilize changed system streams after bundle activation
[ https://issues.apache.org/jira/browse/FELIX-3607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13541481#comment-13541481 ] Felix Meschberger commented on FELIX-3607: -- The patch looks good to me. Could someone else knowledgeable with the ThreadIO stuff have a look, too ? Thanks. (Removed the config admin component, because this looks like unrelated) ThreadIO doesn't utilize changed system streams after bundle activation --- Key: FELIX-3607 URL: https://issues.apache.org/jira/browse/FELIX-3607 Project: Felix Issue Type: Bug Components: Gogo Runtime Affects Versions: gogo.runtime-0.12.0 Reporter: Tuomas Kiviaho Priority: Minor Attachments: gogo-runtime.patch I use maven failsafe to run integration test fragments inside external osgi framework and remote gogo is used to bridge forked failsafe execution with a bundled failsafe junit provider. Everything has worked fine until I noticed that once executing thread changes. Then I seem to start receiving surefire/failsafe directives along with whatever is printed to system streams. When thread execution stays the same there is no problem 'Hello World' - server[failsafe] - '3,0001,Hello World' - server[telnetconsole] - '3,0001,Hello World' - client[telnetconsole] - '3,0001,Hello World' - client[failsafe] - 'Hello World' but thread changes due to using log service for instance then the message isn't coming back (which is perfectly normal) but instead is poured over to System.out 'Hello World' - server[logservice] - 'Hello World' - server[loglistener] - // here we have a different thread 'Hello World' - server[failsafe] - '3,0001,Hello World' - server[telnetconsole] - '3,0001,Hello World' - System.out // and here thread local can't be found so System.out is used as fallback mechanism or that's what I think was meant to be. Actually the printing is done to some ancient System.out that was set during the bundle got active. Failsafe infact pushes and pops the System.out in between without Gogo noticing it. This kind of possiblility could be taken into account by wrapping the system in, out and error to a dedicated FilteredStreams that use the previously obtained streams in case system streams do not point to ThreadIOImpl's err,out and in anymore. The close() method already contains similar logic. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-2100) Initial Config Loader
[ https://issues.apache.org/jira/browse/FELIX-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13541492#comment-13541492 ] Felix Meschberger commented on FELIX-2100: -- This is quite dated. I am also not sure what to make of it: For one thing I think relating the life cycle of a bundle with the life cycle of configuration is conceptually wrong. Also the creators are generally (conceptually) different: A bundle is created by a developer while configuration is created and managed by a systems administrator (even though default configuration might be provided by a developer). IMHO approaches like those provided by the Felix File Install or Sling OSGi Installer are more appropriate. Initial Config Loader - Key: FELIX-2100 URL: https://issues.apache.org/jira/browse/FELIX-2100 Project: Felix Issue Type: New Feature Components: Bundle Repository (OBR), Configuration Admin Reporter: Róbert Csákány Attachments: configloader.zip I've a request to be able to make customer specific configuration bundles - bundles that includes Configurations for other bundles. If a bundle is deployed, extracts the configuration files and register it with configadmin. If bundle is removed, removes configurations. If you have ideas, please share it! (I'm new in this Felix world, I've used it only with Sling as a user) I will make a short proporsal and a whiteboard implementation. The name of impmelemtation is configloader The configloader service will implement the SynchronousBundleListener, and registering itself in activation and unregistering in deactivation. When a new bundle is registering, checking the Bundle-InitialConfigurations in META-INF/MANIFEST.MF file. If the entry is presented, checking the given folders for *.xml files describes the configurations entry. (To handle the Factory services also). Is it correct? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
