[jira] Updated: (FELIX-1959) Move towards unified LF and extended branding support
[ https://issues.apache.org/jira/browse/FELIX-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Valchev updated FELIX-1959: Attachment: jqueryui-vs-default-lnf.png Move towards unified LF and extended branding support -- Key: FELIX-1959 URL: https://issues.apache.org/jira/browse/FELIX-1959 Project: Felix Issue Type: New Feature Components: Web Console Reporter: Valentin Valchev Priority: Minor Attachments: jqueryui-vs-default-lnf.png Currently the Web Console uses heavily on the JQuery framework. Using a unified JavaScript framework simplifies development of all plugins and unifies the used approach. However, when talking about visual styling, there are number of differences because each plugin developer uses own styles. My suggestion is to adopt the JQuery UI . The benefits of using it as unified widget/css framework are: - no time to spend on writing widgets already in the library - clean CSS visual styling - easy way to change the LF by changing the theme (extended branding support!) - improved cross-browser support (JQuery UI takes care of CSS differences) Using the JQuery UI framework the developer shouldn't care about color but only for layout - components position; and for data being displayed. To illustrate the benefits I've saved the Log Service page, modified it to use JQuery UI, took screen-shot, modified the theme CSS only, and again took screen-shot, and finally added the original LF for reference, so you can easily compare the result. The attached image contains the combined screen-shots. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1959) Move towards unified LF and extended branding support
Move towards unified LF and extended branding support -- Key: FELIX-1959 URL: https://issues.apache.org/jira/browse/FELIX-1959 Project: Felix Issue Type: New Feature Components: Web Console Reporter: Valentin Valchev Priority: Minor Attachments: jqueryui-vs-default-lnf.png Currently the Web Console uses heavily on the JQuery framework. Using a unified JavaScript framework simplifies development of all plugins and unifies the used approach. However, when talking about visual styling, there are number of differences because each plugin developer uses own styles. My suggestion is to adopt the JQuery UI . The benefits of using it as unified widget/css framework are: - no time to spend on writing widgets already in the library - clean CSS visual styling - easy way to change the LF by changing the theme (extended branding support!) - improved cross-browser support (JQuery UI takes care of CSS differences) Using the JQuery UI framework the developer shouldn't care about color but only for layout - components position; and for data being displayed. To illustrate the benefits I've saved the Log Service page, modified it to use JQuery UI, took screen-shot, modified the theme CSS only, and again took screen-shot, and finally added the original LF for reference, so you can easily compare the result. The attached image contains the combined screen-shots. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (FELIX-1959) Move towards unified LF and extended branding support
[ https://issues.apache.org/jira/browse/FELIX-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned FELIX-1959: --- Assignee: Carsten Ziegeler Move towards unified LF and extended branding support -- Key: FELIX-1959 URL: https://issues.apache.org/jira/browse/FELIX-1959 Project: Felix Issue Type: New Feature Components: Web Console Reporter: Valentin Valchev Assignee: Carsten Ziegeler Priority: Minor Attachments: jqueryui-vs-default-lnf.png Currently the Web Console uses heavily on the JQuery framework. Using a unified JavaScript framework simplifies development of all plugins and unifies the used approach. However, when talking about visual styling, there are number of differences because each plugin developer uses own styles. My suggestion is to adopt the JQuery UI . The benefits of using it as unified widget/css framework are: - no time to spend on writing widgets already in the library - clean CSS visual styling - easy way to change the LF by changing the theme (extended branding support!) - improved cross-browser support (JQuery UI takes care of CSS differences) Using the JQuery UI framework the developer shouldn't care about color but only for layout - components position; and for data being displayed. To illustrate the benefits I've saved the Log Service page, modified it to use JQuery UI, took screen-shot, modified the theme CSS only, and again took screen-shot, and finally added the original LF for reference, so you can easily compare the result. The attached image contains the combined screen-shots. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1959) Move towards unified LF and extended branding support
[ https://issues.apache.org/jira/browse/FELIX-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12793585#action_12793585 ] Carsten Ziegeler commented on FELIX-1959: - Looks really cool! I completly agree that having a common look at and feel across all plugins is desirable. The current implementation of some plugins when it comes to rendering is too complex. We generate partial html, have javascript that adds missing html etc. Very confusing and error prone. One idee I discussed briefly with Felix M., was to go one step back and make the plugins deliver all html - without styling, without javascript etc. and then add the dynamic stuff via jquery. I haven't done anything with jQuery UI (but will do in the next days). If it helps in making the development of plugins easier and more consistent, I'm all for it! Could you show some sample code of how this would look like from the development perspective? Move towards unified LF and extended branding support -- Key: FELIX-1959 URL: https://issues.apache.org/jira/browse/FELIX-1959 Project: Felix Issue Type: New Feature Components: Web Console Reporter: Valentin Valchev Priority: Minor Attachments: jqueryui-vs-default-lnf.png Currently the Web Console uses heavily on the JQuery framework. Using a unified JavaScript framework simplifies development of all plugins and unifies the used approach. However, when talking about visual styling, there are number of differences because each plugin developer uses own styles. My suggestion is to adopt the JQuery UI . The benefits of using it as unified widget/css framework are: - no time to spend on writing widgets already in the library - clean CSS visual styling - easy way to change the LF by changing the theme (extended branding support!) - improved cross-browser support (JQuery UI takes care of CSS differences) Using the JQuery UI framework the developer shouldn't care about color but only for layout - components position; and for data being displayed. To illustrate the benefits I've saved the Log Service page, modified it to use JQuery UI, took screen-shot, modified the theme CSS only, and again took screen-shot, and finally added the original LF for reference, so you can easily compare the result. The attached image contains the combined screen-shots. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1959) Move towards unified LF and extended branding support
[ https://issues.apache.org/jira/browse/FELIX-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Valchev updated FELIX-1959: Attachment: tb6.jar Ok, I've added the LogService refactored to use JQueryUI internally. Of course, the JQueryUI is exported temporally by plug-in resource, since it is not yet exported by the console itself. You can check the themes in a very simple way: - set the system property 'webconsole.alternative.theme=true' - update the bundle - refresh the web browser (Ctrl+F5) This is just proof of concept and is just code copied from the original log service with some modifications but it's not optimized to run at it's best performance. There are a number of optimizations that can be performed, if it is supposed to replace the original LogService. As example it can improved by: - caching of the loaded resource (data.html) - adding possibility to load the resource using the request locale (load data_en.html, data_fr.html, depending on request.getLocales()). Move towards unified LF and extended branding support -- Key: FELIX-1959 URL: https://issues.apache.org/jira/browse/FELIX-1959 Project: Felix Issue Type: New Feature Components: Web Console Reporter: Valentin Valchev Assignee: Carsten Ziegeler Priority: Minor Attachments: jqueryui-vs-default-lnf.png, tb6.jar Currently the Web Console uses heavily on the JQuery framework. Using a unified JavaScript framework simplifies development of all plugins and unifies the used approach. However, when talking about visual styling, there are number of differences because each plugin developer uses own styles. My suggestion is to adopt the JQuery UI . The benefits of using it as unified widget/css framework are: - no time to spend on writing widgets already in the library - clean CSS visual styling - easy way to change the LF by changing the theme (extended branding support!) - improved cross-browser support (JQuery UI takes care of CSS differences) Using the JQuery UI framework the developer shouldn't care about color but only for layout - components position; and for data being displayed. To illustrate the benefits I've saved the Log Service page, modified it to use JQuery UI, took screen-shot, modified the theme CSS only, and again took screen-shot, and finally added the original LF for reference, so you can easily compare the result. The attached image contains the combined screen-shots. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1792) Felix OBR seems to just randomly choose one of the satisifed bundles if more than one bundle meets the requirement
[ https://issues.apache.org/jira/browse/FELIX-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12793645#action_12793645 ] hehe ji commented on FELIX-1792: Hi Richard, Thanks for the patch. I tried it but I got deadlock problem for the following situation: Bundle71 (in repo) : Depends on Bundle72 Bundle72 v1 (in repo) : depends on bundle73 Bundle72_2 v2 (in eba) : Depends on Bundle.invalid // This should not be picked up Bundle73 (in eba) : No Dependencies I expect bundle71, bundle71 v1 and bundle73 are installed in framework. 3XMTHREADINFO Thread-129 TID:0x0238A400, j9thread_t:0x04000ABA1920, state:CW, prio=5 3XMTHREADINFO1(native thread ID:0x6BF9, native priority:0x5, native policy:UNKNOWN) 3XMTHREADINFO2(native stack address range from:0x04000B58, to:0x04000B54, size:0x4) 4XESTACKTRACE at java/lang/Character.toLowerCase(Character.java:4187(Compiled Code)) 4XESTACKTRACE at java/lang/String.compareValue(String.java:450(Compiled Code)) 4XESTACKTRACE at java/lang/String.compareToIgnoreCase(String.java:466(Compiled Code)) 4XESTACKTRACE at org/apache/felix/bundlerepository/ResourceImpl$1.compare(ResourceImpl.java:55(Compiled Code)) 4XESTACKTRACE at java/util/TreeMap.cmp(TreeMap.java:4472(Compiled Code)) 4XESTACKTRACE at java/util/TreeMap.get(TreeMap.java:4344(Compiled Code)) 4XESTACKTRACE at org/apache/felix/bundlerepository/ResourceImpl.getSymbolicName(ResourceImpl.java:107(Compiled Code)) 4XESTACKTRACE at org/apache/felix/bundlerepository/ResourceImpl.hashCode(ResourceImpl.java:84(Compiled Code)) 4XESTACKTRACE at java/util/HashMap.getEntry(HashMap.java:506(Compiled Code)) 4XESTACKTRACE at java/util/HashMap.containsKey(HashMap.java:432(Compiled Code)) 4XESTACKTRACE at java/util/HashSet.contains(HashSet.java:138(Compiled Code)) 4XESTACKTRACE at org/apache/felix/bundlerepository/ResolverImpl.resolve(ResolverImpl.java:158(Compiled Code)) 4XESTACKTRACE at org/apache/felix/bundlerepository/ResolverImpl.resolve(ResolverImpl.java:199(Compiled Code)) 4XESTACKTRACE at org/apache/felix/bundlerepository/ResolverImpl.resolve(ResolverImpl.java:199) 4XESTACKTRACE at org/apache/felix/bundlerepository/ResolverImpl.resolve(ResolverImpl.java:133) Please let me know if you need more information. Thanks Emily Felix OBR seems to just randomly choose one of the satisifed bundles if more than one bundle meets the requirement -- Key: FELIX-1792 URL: https://issues.apache.org/jira/browse/FELIX-1792 Project: Felix Issue Type: Bug Components: Bundle Repository (OBR) Affects Versions: bundlerepository-1.4.2 Environment: n/a Reporter: david small99 Assignee: Richard S. Hall Fix For: bundlerepository-1.6.0 I have one bundle bundle1, which imports a package called com.obr.bundle Bundle1's manifest: Manifest-Version: 1.0 Ant-Version: Apache Ant 1.7.0 Bundle-ManifestVersion: 2 Bundle-Name: Bundle Plug-in Bundle-SymbolicName: com.obr.bundle1 Bundle-Version: 1.0.0 Export-Package: com.obr.bundle1 Import-Package: com.obr.bundle;version=[1.2.0.999,3.2.2.bz] There are two bundles in my repositories, bundler2 and bundle 3. Both of them export package com.obr.bundle. Below are their manifest files. Bundle2 Manifest-Version: 1.0 Ant-Version: Apache Ant 1.7.0 Bundle-ManifestVersion: 2 Bundle-Name: Bundle Plug-in Bundle-SymbolicName: com.obr.bundle2 Bundle-Version: 1.0.0 Bundle-Vendor: xxx Import-Package: a.b.c Export-Package: com.obr.bundle;version=3.2.2.blah Bundle3: Manifest-Version: 1.0 Ant-Version: Apache Ant 1.7.0 Bundle-ManifestVersion: 2 Bundle-Name: Bundle Plug-in Bundle-SymbolicName: com.obr.bundle3 Bundle-Version: 1.0.0 Import-Package: a.b.c Export-Package: com.obr.bundle;version=3.1 As you can see, both bundle2 and bundle3 meet the requirements of bundle1. I hope the highest package version, which is bundle2, is chosen by felix obr. However, sometimes bundle 3 was chosen instead of bundle2. The behaviour is random. Am I right to say that the Felix obr runtime just picks the first bundle that meets the requirements and then stop searching for any more eligible bundles? Thanks -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1792) Felix OBR seems to just randomly choose one of the satisifed bundles if more than one bundle meets the requirement
[ https://issues.apache.org/jira/browse/FELIX-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12793654#action_12793654 ] Richard S. Hall commented on FELIX-1792: What is in eba mean? Could you give me a simplified example of the bundle manifests and a description of the steps needed to reproduce the issue? If so, I will look into it. Felix OBR seems to just randomly choose one of the satisifed bundles if more than one bundle meets the requirement -- Key: FELIX-1792 URL: https://issues.apache.org/jira/browse/FELIX-1792 Project: Felix Issue Type: Bug Components: Bundle Repository (OBR) Affects Versions: bundlerepository-1.4.2 Environment: n/a Reporter: david small99 Assignee: Richard S. Hall Fix For: bundlerepository-1.6.0 I have one bundle bundle1, which imports a package called com.obr.bundle Bundle1's manifest: Manifest-Version: 1.0 Ant-Version: Apache Ant 1.7.0 Bundle-ManifestVersion: 2 Bundle-Name: Bundle Plug-in Bundle-SymbolicName: com.obr.bundle1 Bundle-Version: 1.0.0 Export-Package: com.obr.bundle1 Import-Package: com.obr.bundle;version=[1.2.0.999,3.2.2.bz] There are two bundles in my repositories, bundler2 and bundle 3. Both of them export package com.obr.bundle. Below are their manifest files. Bundle2 Manifest-Version: 1.0 Ant-Version: Apache Ant 1.7.0 Bundle-ManifestVersion: 2 Bundle-Name: Bundle Plug-in Bundle-SymbolicName: com.obr.bundle2 Bundle-Version: 1.0.0 Bundle-Vendor: xxx Import-Package: a.b.c Export-Package: com.obr.bundle;version=3.2.2.blah Bundle3: Manifest-Version: 1.0 Ant-Version: Apache Ant 1.7.0 Bundle-ManifestVersion: 2 Bundle-Name: Bundle Plug-in Bundle-SymbolicName: com.obr.bundle3 Bundle-Version: 1.0.0 Import-Package: a.b.c Export-Package: com.obr.bundle;version=3.1 As you can see, both bundle2 and bundle3 meet the requirements of bundle1. I hope the highest package version, which is bundle2, is chosen by felix obr. However, sometimes bundle 3 was chosen instead of bundle2. The behaviour is random. Am I right to say that the Felix obr runtime just picks the first bundle that meets the requirements and then stop searching for any more eligible bundles? Thanks -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1959) Move towards unified LF and extended branding support
[ https://issues.apache.org/jira/browse/FELIX-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12793658#action_12793658 ] Felix Meschberger commented on FELIX-1959: -- This looks very promising -- but also like a big change in various rendering areas. Can we do this step by step aka page by page ? Anyways, a big +1 for pursuiing this. ... and investigation of internationalization would be a nice thing. Move towards unified LF and extended branding support -- Key: FELIX-1959 URL: https://issues.apache.org/jira/browse/FELIX-1959 Project: Felix Issue Type: New Feature Components: Web Console Reporter: Valentin Valchev Assignee: Carsten Ziegeler Priority: Minor Attachments: jqueryui-vs-default-lnf.png, tb6.jar Currently the Web Console uses heavily on the JQuery framework. Using a unified JavaScript framework simplifies development of all plugins and unifies the used approach. However, when talking about visual styling, there are number of differences because each plugin developer uses own styles. My suggestion is to adopt the JQuery UI . The benefits of using it as unified widget/css framework are: - no time to spend on writing widgets already in the library - clean CSS visual styling - easy way to change the LF by changing the theme (extended branding support!) - improved cross-browser support (JQuery UI takes care of CSS differences) Using the JQuery UI framework the developer shouldn't care about color but only for layout - components position; and for data being displayed. To illustrate the benefits I've saved the Log Service page, modified it to use JQuery UI, took screen-shot, modified the theme CSS only, and again took screen-shot, and finally added the original LF for reference, so you can easily compare the result. The attached image contains the combined screen-shots. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (FELIX-1792) Felix OBR seems to just randomly choose one of the satisifed bundles if more than one bundle meets the requirement
[ https://issues.apache.org/jira/browse/FELIX-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12793654#action_12793654 ] Richard S. Hall edited comment on FELIX-1792 at 12/22/09 4:35 PM: -- What does in eba mean? Could you give me a simplified example of the bundle manifests and a description of the steps needed to reproduce the issue? If so, I will look into it. was (Author: rickhall): What is in eba mean? Could you give me a simplified example of the bundle manifests and a description of the steps needed to reproduce the issue? If so, I will look into it. Felix OBR seems to just randomly choose one of the satisifed bundles if more than one bundle meets the requirement -- Key: FELIX-1792 URL: https://issues.apache.org/jira/browse/FELIX-1792 Project: Felix Issue Type: Bug Components: Bundle Repository (OBR) Affects Versions: bundlerepository-1.4.2 Environment: n/a Reporter: david small99 Assignee: Richard S. Hall Fix For: bundlerepository-1.6.0 I have one bundle bundle1, which imports a package called com.obr.bundle Bundle1's manifest: Manifest-Version: 1.0 Ant-Version: Apache Ant 1.7.0 Bundle-ManifestVersion: 2 Bundle-Name: Bundle Plug-in Bundle-SymbolicName: com.obr.bundle1 Bundle-Version: 1.0.0 Export-Package: com.obr.bundle1 Import-Package: com.obr.bundle;version=[1.2.0.999,3.2.2.bz] There are two bundles in my repositories, bundler2 and bundle 3. Both of them export package com.obr.bundle. Below are their manifest files. Bundle2 Manifest-Version: 1.0 Ant-Version: Apache Ant 1.7.0 Bundle-ManifestVersion: 2 Bundle-Name: Bundle Plug-in Bundle-SymbolicName: com.obr.bundle2 Bundle-Version: 1.0.0 Bundle-Vendor: xxx Import-Package: a.b.c Export-Package: com.obr.bundle;version=3.2.2.blah Bundle3: Manifest-Version: 1.0 Ant-Version: Apache Ant 1.7.0 Bundle-ManifestVersion: 2 Bundle-Name: Bundle Plug-in Bundle-SymbolicName: com.obr.bundle3 Bundle-Version: 1.0.0 Import-Package: a.b.c Export-Package: com.obr.bundle;version=3.1 As you can see, both bundle2 and bundle3 meet the requirements of bundle1. I hope the highest package version, which is bundle2, is chosen by felix obr. However, sometimes bundle 3 was chosen instead of bundle2. The behaviour is random. Am I right to say that the Felix obr runtime just picks the first bundle that meets the requirements and then stop searching for any more eligible bundles? Thanks -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release fileinstall 2.0.6
This vote is cancelled due to bad signatures on the artifacts. I'll launch a vote on a 2.0.8 release in a new thread. Chris -- Chris Custine FUSESource :: http://fusesource.com My Blog :: http://blog.organicelement.com Apache ServiceMix :: http://servicemix.apache.org Apache Felix :: http://felix.apache.org Apache Directory Server :: http://directory.apache.org On Thu, Dec 17, 2009 at 3:06 AM, Guillaume Nodet gno...@gmail.com wrote: Release Notes - Felix - Version fileinstall-2.0.6 ** Bug * [FELIX-1775] - fileinstall release archives contains an empty load folder which should be removed * [FELIX-1789] - FileInstall is too verbose * [FELIX-1851] - FileInstall watched bundles are restarted twice upon update * [FELIX-1861] - FileInstall created temp directories are never deleted * [FELIX-1862] - fileinstall thread name as printed in log messages need to be less verbose * [FELIX-1928] - File installer starts bundles too early on restart ** Task * [FELIX-1811] - fileinstall should depend on the official osgi artifacts Staging repository: https://repository.apache.org/content/repositories/felix-staging-054/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 054 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be open for 72 hours. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
[VOTE] Release fileinstall 2.0.8
Hi All, Before checking the staged artifacts, please be sure to import my public key from either http://www.apache.org/dist/felix/KEYS or a public keyserver. Release Notes - Felix - Version fileinstall-2.0.8 ** Bug * [FELIX-1775] - fileinstall release archives contains an empty load folder which should be removed * [FELIX-1789] - FileInstall is too verbose * [FELIX-1851] - FileInstall watched bundles are restarted twice upon update * [FELIX-1861] - FileInstall created temp directories are never deleted * [FELIX-1862] - fileinstall thread name as printed in log messages need to be less verbose * [FELIX-1928] - File installer starts bundles too early on restart ** Task * [FELIX-1811] - fileinstall should depend on the official osgi artifacts Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-005/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 005 /tmp/felix-staging Please vote 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, Chris -- Chris Custine FUSESource :: http://fusesource.com My Blog :: http://blog.organicelement.com Apache ServiceMix :: http://servicemix.apache.org Apache Felix :: http://felix.apache.org Apache Directory Server :: http://directory.apache.org
Re: [VOTE] Release fileinstall 2.0.6
Sorry about that (I'm in holidays until January so haven't had much time to follow on this vote). Chris, thx for taking care of that. On Tue, Dec 22, 2009 at 21:06, Chris Custine chris.cust...@gmail.com wrote: This vote is cancelled due to bad signatures on the artifacts. I'll launch a vote on a 2.0.8 release in a new thread. Chris -- Chris Custine FUSESource :: http://fusesource.com My Blog :: http://blog.organicelement.com Apache ServiceMix :: http://servicemix.apache.org Apache Felix :: http://felix.apache.org Apache Directory Server :: http://directory.apache.org On Thu, Dec 17, 2009 at 3:06 AM, Guillaume Nodet gno...@gmail.com wrote: Release Notes - Felix - Version fileinstall-2.0.6 ** Bug * [FELIX-1775] - fileinstall release archives contains an empty load folder which should be removed * [FELIX-1789] - FileInstall is too verbose * [FELIX-1851] - FileInstall watched bundles are restarted twice upon update * [FELIX-1861] - FileInstall created temp directories are never deleted * [FELIX-1862] - fileinstall thread name as printed in log messages need to be less verbose * [FELIX-1928] - File installer starts bundles too early on restart ** Task * [FELIX-1811] - fileinstall should depend on the official osgi artifacts Staging repository: https://repository.apache.org/content/repositories/felix-staging-054/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 054 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be open for 72 hours. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [VOTE] Release fileinstall 2.0.8
L.S., Here's my +1 (non-binding) Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/12/22 Chris Custine ccust...@apache.org: Hi All, Before checking the staged artifacts, please be sure to import my public key from either http://www.apache.org/dist/felix/KEYS or a public keyserver. Release Notes - Felix - Version fileinstall-2.0.8 ** Bug * [FELIX-1775] - fileinstall release archives contains an empty load folder which should be removed * [FELIX-1789] - FileInstall is too verbose * [FELIX-1851] - FileInstall watched bundles are restarted twice upon update * [FELIX-1861] - FileInstall created temp directories are never deleted * [FELIX-1862] - fileinstall thread name as printed in log messages need to be less verbose * [FELIX-1928] - File installer starts bundles too early on restart ** Task * [FELIX-1811] - fileinstall should depend on the official osgi artifacts Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-005/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 005 /tmp/felix-staging Please vote 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, Chris -- Chris Custine FUSESource :: http://fusesource.com My Blog :: http://blog.organicelement.com Apache ServiceMix :: http://servicemix.apache.org Apache Felix :: http://felix.apache.org Apache Directory Server :: http://directory.apache.org
[jira] Commented: (FELIX-1959) Move towards unified LF and extended branding support
[ https://issues.apache.org/jira/browse/FELIX-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12793956#action_12793956 ] Carsten Ziegeler commented on FELIX-1959: - Yes, I think we should move forward with this! Maybe we should start by adding the libraries to the console and then migrate one plugin after the other. When we have migrated all plugins we could cleanup the html/css of the console itself And having i18n support would be a real nice thing...but maybe we could do this afterwards? So if you have any patches, Valentin, they're more than welcome :) Move towards unified LF and extended branding support -- Key: FELIX-1959 URL: https://issues.apache.org/jira/browse/FELIX-1959 Project: Felix Issue Type: New Feature Components: Web Console Reporter: Valentin Valchev Assignee: Carsten Ziegeler Priority: Minor Attachments: jqueryui-vs-default-lnf.png, tb6.jar Currently the Web Console uses heavily on the JQuery framework. Using a unified JavaScript framework simplifies development of all plugins and unifies the used approach. However, when talking about visual styling, there are number of differences because each plugin developer uses own styles. My suggestion is to adopt the JQuery UI . The benefits of using it as unified widget/css framework are: - no time to spend on writing widgets already in the library - clean CSS visual styling - easy way to change the LF by changing the theme (extended branding support!) - improved cross-browser support (JQuery UI takes care of CSS differences) Using the JQuery UI framework the developer shouldn't care about color but only for layout - components position; and for data being displayed. To illustrate the benefits I've saved the Log Service page, modified it to use JQuery UI, took screen-shot, modified the theme CSS only, and again took screen-shot, and finally added the original LF for reference, so you can easily compare the result. The attached image contains the combined screen-shots. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1913) All events are processed in a queue
[ https://issues.apache.org/jira/browse/FELIX-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated FELIX-1913: Description: The current event admin implementation puts all events into a queue and processes this queue in one thread. This creates a bottleneck when different threads send events as they have to wait for other threads to be processed first. Events from different threads can be processed in parallel. In the async mode, event deliver might take a long time as these events are processed one after the other as well. was:The current event admin implementation puts all events into one single queue and processes this queue is in one thread. This creates a bottleneck when different threads send events as they have to wait for other threads to be processed first. Events from different threads can be processed in parallel. Summary: All events are processed in a queue (was: All synchronous events are processed in one queue) All events are processed in a queue --- Key: FELIX-1913 URL: https://issues.apache.org/jira/browse/FELIX-1913 Project: Felix Issue Type: Improvement Components: Event Admin Affects Versions: eventadmin 1.0.0 Reporter: Carsten Ziegeler Assignee: Karl Pauls Priority: Minor Attachments: ea.patch The current event admin implementation puts all events into a queue and processes this queue in one thread. This creates a bottleneck when different threads send events as they have to wait for other threads to be processed first. Events from different threads can be processed in parallel. In the async mode, event deliver might take a long time as these events are processed one after the other as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1960) Fine-grained timeout configuration
Fine-grained timeout configuration -- Key: FELIX-1960 URL: https://issues.apache.org/jira/browse/FELIX-1960 Project: Felix Issue Type: Improvement Components: Event Admin Affects Versions: eventadmin 1.0.0 Reporter: Carsten Ziegeler The timeout setting for event delivery is currentl a global setting - event listeners should (recommended by the spec as well) start an async thread if they need some time to process the event. With the timeout setting in place, this creates two threads for each event delivery: one for the timeout handling and one for the event processing. I think it would be nice, if one could optimize this behaviour by configuring the event admin to directly call specific event listeners and don't check the timeout. An administrator could add well-known event listeners to this configuration. This would reduce the server load for well-behaving event listeners. I could imagine something like ignore.timeout.for=org.apache.sling.jcr.*,my.special.EventListener (with a better name for the config property) - so you can either add package prefixes or specific classes to the configuration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
