[jira] Resolved: (FELIX-2123) Latest commit to ConfigurationRender is not OSGi/Minumum-1.0 compatible

[Felix Meschberger (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-2123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Felix Meschberger resolved FELIX-2123.
--

   Resolution: Fixed
Fix Version/s: webconsole-3.0.0

Good. Thanks for the feedback.
So this can be resolved.

> Latest commit to ConfigurationRender is not OSGi/Minumum-1.0 compatible
> ---
>
> Key: FELIX-2123
> URL: https://issues.apache.org/jira/browse/FELIX-2123
> Project: Felix
>  Issue Type: Bug
>  Components: Web Console
>Affects Versions: webconsole-3.0.0
>Reporter: Valentin Valchev
>Assignee: Felix Meschberger
> Fix For: webconsole-3.0.0
>
>
> The method URLDecoder.decode( String, String ) is not available in Minumum 
> EE. This is the reason for using the old, deprecated URLDecoder.decode( 
> String ) method.

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

[jira] Commented: (FELIX-2158) Localization of plugin titles

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on FELIX-2158:
--

How about following the standard OSGi way as defined in Section 3.10.2, 
Manifest Localization ?

If the title is prefixed with a "%" it is used as a key into the plugin's 
resource bundle, otherwise the title is used as is.

WDYT ?

> Localization of plugin titles
> -
>
> Key: FELIX-2158
> URL: https://issues.apache.org/jira/browse/FELIX-2158
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Reporter: Valentin Valchev
>
> We have added localization support, but there is one thing missing - the 
> titles of the plugins, that are rendered on top.
> So now, even though the plugins are completely localized, the navigation 
> between the plugins is not. However, we need to keep the web console 
> compatible with the old API, so the change should be transparent.
> I've been thinking about the problem and came to the following solution:
> when request is made, the webconsole will:
> 1. obtain the resource bundle for plugins
> 2. for each plugin
> 3. get the localized title, which is a resource key .pluginTitle
> 4. if the localized title doesn't exist - then use the default title
> 5. fill in the labelMap table
> the reason for using .pluginTitle instead of some other constant 
> name is that a bundle can provide more than one plugins, as example 
> webconsole itself. In this case we need to provide titles for all plugins and 
> this involves the label.
> This can be achieved easily by adding the following method in OsgiManager:
> private final Map localizedLabelMap(final Locale locale)
> {
> Map map = new HashMap();
> ResourceBundle resourceBundle;
> AbstractWebConsolePlugin plugin;
> String label;
> String title;
> for (Iterator pi = plugins.values().iterator(); pi.hasNext();)
> {
> plugin = (AbstractWebConsolePlugin) pi.next();
> resourceBundle = 
> resourceBundleManager.getResourceBundle(plugin.getBundle(),
> locale);
> label = plugin.getLabel();
> title = plugin.getTitle();
> try
> {
> final String res = plugin.getLabel() + ".pluginTitle";
> title = resourceBundle.getString(res);
> // our Resource Bundle doesn't throw exception, so if
> // the value is same as the property key - revert to
> // the original title
> if (title.equals(res))
> {
> title = plugin.getTitle();
> }
> }
> catch (Throwable e)
> {
> /* ignore missing resource - use default title */
> }
> map.put(label, title);
> }
> return map;
> }
> and modify the service() method as follows:
> Map labelMap = localizedLabelMap(request.getLocale());
> // the official request attributes
> req.setAttribute( WebConsoleConstants.ATTR_LABEL_MAP, labelMap );

-- 
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-2158) Localization of plugin titles

[Felix Meschberger (JIRA)]

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

Felix Meschberger edited comment on FELIX-2158 at 3/4/10 8:35 AM:
--

How about following the standard OSGi way as defined in Section 3.10.2, 
Manifest Localization ?

If the title is prefixed with a "%" it is used as a key into the plugin's 
resource bundle, otherwise the title is used as is.

In addition we can add  a new method to the AbstractWebConsolePlugin:

   public String getTitle(Locale locale);

Returning the localized title if available.

WDYT ?

  was (Author: fmeschbe):
How about following the standard OSGi way as defined in Section 3.10.2, 
Manifest Localization ?

If the title is prefixed with a "%" it is used as a key into the plugin's 
resource bundle, otherwise the title is used as is.

WDYT ?
  
> Localization of plugin titles
> -
>
> Key: FELIX-2158
> URL: https://issues.apache.org/jira/browse/FELIX-2158
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Reporter: Valentin Valchev
>
> We have added localization support, but there is one thing missing - the 
> titles of the plugins, that are rendered on top.
> So now, even though the plugins are completely localized, the navigation 
> between the plugins is not. However, we need to keep the web console 
> compatible with the old API, so the change should be transparent.
> I've been thinking about the problem and came to the following solution:
> when request is made, the webconsole will:
> 1. obtain the resource bundle for plugins
> 2. for each plugin
> 3. get the localized title, which is a resource key .pluginTitle
> 4. if the localized title doesn't exist - then use the default title
> 5. fill in the labelMap table
> the reason for using .pluginTitle instead of some other constant 
> name is that a bundle can provide more than one plugins, as example 
> webconsole itself. In this case we need to provide titles for all plugins and 
> this involves the label.
> This can be achieved easily by adding the following method in OsgiManager:
> private final Map localizedLabelMap(final Locale locale)
> {
> Map map = new HashMap();
> ResourceBundle resourceBundle;
> AbstractWebConsolePlugin plugin;
> String label;
> String title;
> for (Iterator pi = plugins.values().iterator(); pi.hasNext();)
> {
> plugin = (AbstractWebConsolePlugin) pi.next();
> resourceBundle = 
> resourceBundleManager.getResourceBundle(plugin.getBundle(),
> locale);
> label = plugin.getLabel();
> title = plugin.getTitle();
> try
> {
> final String res = plugin.getLabel() + ".pluginTitle";
> title = resourceBundle.getString(res);
> // our Resource Bundle doesn't throw exception, so if
> // the value is same as the property key - revert to
> // the original title
> if (title.equals(res))
> {
> title = plugin.getTitle();
> }
> }
> catch (Throwable e)
> {
> /* ignore missing resource - use default title */
> }
> map.put(label, title);
> }
> return map;
> }
> and modify the service() method as follows:
> Map labelMap = localizedLabelMap(request.getLocale());
> // the official request attributes
> req.setAttribute( WebConsoleConstants.ATTR_LABEL_MAP, labelMap );

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

[jira] Commented: (FELIX-2119) Bundle update fails, if OBR is not installed

[Valentin Valchev (JIRA)]

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

Valentin Valchev commented on FELIX-2119:
-

Ok, now it works even if OBR is not installed. I'm just curious why the 
updateFromBundleLocation() method is so complex?

If we update a bundle from it's own location, then why bothering opening 
getting it's location, creating URL, getting the stream, update from the new 
stream, and then make sure stream is closed ..

Isn't it better to leave the framework do it's job and just use 
bundle.update(), instead of bundle.update(InputStream). Plus, the framework 
might have some optimizations on this update, and may perform it faster, than 
us (example it might internally cache the URL object for the location, might 
also check last updated time of the URLConnection, and if no-later than 
current, might decide to simply ignore the update operation).

So IMHO, the method show be:
private boolean updateFromBundleLocation() throws BundleException
{
getLog().log( LogService.LOG_DEBUG, "Trying to update from bundle 
location " + location );

try
{
bundle.update();
getLog().log( LogService.LOG_INFO, "Bundle updated from bundle 
location " + location );
return true;
}
}
catch ( Throwable ioe )
{
// BundleException, IllegalStateException or SecurityException? 
lets use OBR then
getLog().log( LogService.LOG_DEBUG, "Update failure from bundle 
location " + location, ioe );
}
// not installed from the bundle location
return false;
}

> Bundle update fails, if OBR is not installed
> 
>
> Key: FELIX-2119
> URL: https://issues.apache.org/jira/browse/FELIX-2119
> Project: Felix
>  Issue Type: Bug
>  Components: Web Console
>Reporter: Valentin Valchev
> Fix For: webconsole-3.0.0
>
>
> The reason for this is that UpdateHelper depends on OBR service API. While 
> OBR is not a core service, its absence shouldn't disallow execution of normal 
> bundle life-cycle commands.
> Stack trace:
> Exception: java.lang.NoClassDefFoundError: [Lorg/osgi/service/obr/Resource;
> at java.lang.Class.getDeclaredMethods0(Native Method)
> at java.lang.Class.privateGetDeclaredMethods(Unknown Source)
> at java.lang.Class.getDeclaredMethod(Unknown Source)
> at java.lang.Thread$1.run(Unknown Source)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.lang.Thread.auditSubclass(Unknown Source)
> at java.lang.Thread.isCCLOverridden(Unknown Source)
> at java.lang.Thread.init(Unknown Source)
> at java.lang.Thread.(Unknown Source)
> at 
> org.apache.felix.webconsole.internal.core.BaseUpdateInstallHelper.(BaseUpdateInstallHelper.java:45)
> at 
> org.apache.felix.webconsole.internal.core.UpdateHelper.(UpdateHelper.java:52)
> at 
> org.apache.felix.webconsole.internal.core.UpdateHelper.(UpdateHelper.java:46)
> at 
> org.apache.felix.webconsole.internal.core.BundlesServlet$4.(BundlesServlet.java:1283)
> at 
> org.apache.felix.webconsole.internal.core.BundlesServlet.update(BundlesServlet.java:1282)
> at 
> org.apache.felix.webconsole.internal.core.BundlesServlet.doPost(BundlesServlet.java:312)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:815)
> at 
> org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:372)

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

[jira] Commented: (FELIX-2158) Localization of plugin titles

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on FELIX-2158:
--

Actually, we probably don't need a getTitle(Locale) method but something like:

public final String getLocalizableTitle() {
final String title = getTitle();
if (title.startsWith("%")) {
return "${" + title.substring(1) + "}";
} else {
return title;
}
}

This would cause the title to be automatically translated to the correct locale 
while being delivered.



> Localization of plugin titles
> -
>
> Key: FELIX-2158
> URL: https://issues.apache.org/jira/browse/FELIX-2158
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Reporter: Valentin Valchev
>
> We have added localization support, but there is one thing missing - the 
> titles of the plugins, that are rendered on top.
> So now, even though the plugins are completely localized, the navigation 
> between the plugins is not. However, we need to keep the web console 
> compatible with the old API, so the change should be transparent.
> I've been thinking about the problem and came to the following solution:
> when request is made, the webconsole will:
> 1. obtain the resource bundle for plugins
> 2. for each plugin
> 3. get the localized title, which is a resource key .pluginTitle
> 4. if the localized title doesn't exist - then use the default title
> 5. fill in the labelMap table
> the reason for using .pluginTitle instead of some other constant 
> name is that a bundle can provide more than one plugins, as example 
> webconsole itself. In this case we need to provide titles for all plugins and 
> this involves the label.
> This can be achieved easily by adding the following method in OsgiManager:
> private final Map localizedLabelMap(final Locale locale)
> {
> Map map = new HashMap();
> ResourceBundle resourceBundle;
> AbstractWebConsolePlugin plugin;
> String label;
> String title;
> for (Iterator pi = plugins.values().iterator(); pi.hasNext();)
> {
> plugin = (AbstractWebConsolePlugin) pi.next();
> resourceBundle = 
> resourceBundleManager.getResourceBundle(plugin.getBundle(),
> locale);
> label = plugin.getLabel();
> title = plugin.getTitle();
> try
> {
> final String res = plugin.getLabel() + ".pluginTitle";
> title = resourceBundle.getString(res);
> // our Resource Bundle doesn't throw exception, so if
> // the value is same as the property key - revert to
> // the original title
> if (title.equals(res))
> {
> title = plugin.getTitle();
> }
> }
> catch (Throwable e)
> {
> /* ignore missing resource - use default title */
> }
> map.put(label, title);
> }
> return map;
> }
> and modify the service() method as follows:
> Map labelMap = localizedLabelMap(request.getLocale());
> // the official request attributes
> req.setAttribute( WebConsoleConstants.ATTR_LABEL_MAP, labelMap );

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

[jira] Commented: (FELIX-2158) Localization of plugin titles

[Valentin Valchev (JIRA)]

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

Valentin Valchev commented on FELIX-2158:
-

It' really doesn't matter to me how this feature is achieved - through directly 
open the cached resource bundle, or through the manifest headers ... But what 
if a bundle contains multiple plugins like Web Console itself?

I will expect manifest entries like:
X-WebConsole-Plugin--Title: %title

Usually the label is lowercase, so the manifest entry will look ugly. As example
X-WebConsole-Plugin-log-Title: %log.title




> Localization of plugin titles
> -
>
> Key: FELIX-2158
> URL: https://issues.apache.org/jira/browse/FELIX-2158
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Reporter: Valentin Valchev
>
> We have added localization support, but there is one thing missing - the 
> titles of the plugins, that are rendered on top.
> So now, even though the plugins are completely localized, the navigation 
> between the plugins is not. However, we need to keep the web console 
> compatible with the old API, so the change should be transparent.
> I've been thinking about the problem and came to the following solution:
> when request is made, the webconsole will:
> 1. obtain the resource bundle for plugins
> 2. for each plugin
> 3. get the localized title, which is a resource key .pluginTitle
> 4. if the localized title doesn't exist - then use the default title
> 5. fill in the labelMap table
> the reason for using .pluginTitle instead of some other constant 
> name is that a bundle can provide more than one plugins, as example 
> webconsole itself. In this case we need to provide titles for all plugins and 
> this involves the label.
> This can be achieved easily by adding the following method in OsgiManager:
> private final Map localizedLabelMap(final Locale locale)
> {
> Map map = new HashMap();
> ResourceBundle resourceBundle;
> AbstractWebConsolePlugin plugin;
> String label;
> String title;
> for (Iterator pi = plugins.values().iterator(); pi.hasNext();)
> {
> plugin = (AbstractWebConsolePlugin) pi.next();
> resourceBundle = 
> resourceBundleManager.getResourceBundle(plugin.getBundle(),
> locale);
> label = plugin.getLabel();
> title = plugin.getTitle();
> try
> {
> final String res = plugin.getLabel() + ".pluginTitle";
> title = resourceBundle.getString(res);
> // our Resource Bundle doesn't throw exception, so if
> // the value is same as the property key - revert to
> // the original title
> if (title.equals(res))
> {
> title = plugin.getTitle();
> }
> }
> catch (Throwable e)
> {
> /* ignore missing resource - use default title */
> }
> map.put(label, title);
> }
> return map;
> }
> and modify the service() method as follows:
> Map labelMap = localizedLabelMap(request.getLocale());
> // the official request attributes
> req.setAttribute( WebConsoleConstants.ATTR_LABEL_MAP, labelMap );

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

[jira] Commented: (FELIX-2158) Localization of plugin titles

[Valentin Valchev (JIRA)]

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

Valentin Valchev commented on FELIX-2158:
-

I'm not sure if the localizableTitle will work. Does the resource bundle 
passed, to a plugin, when it is rendered contains a combined resources of all 
Plugins?

See, the title for each plugin is it's own resources. And the abstract console 
when rendering a single plugin, still need the title of all others - to display 
the navigation.

> Localization of plugin titles
> -
>
> Key: FELIX-2158
> URL: https://issues.apache.org/jira/browse/FELIX-2158
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Reporter: Valentin Valchev
>
> We have added localization support, but there is one thing missing - the 
> titles of the plugins, that are rendered on top.
> So now, even though the plugins are completely localized, the navigation 
> between the plugins is not. However, we need to keep the web console 
> compatible with the old API, so the change should be transparent.
> I've been thinking about the problem and came to the following solution:
> when request is made, the webconsole will:
> 1. obtain the resource bundle for plugins
> 2. for each plugin
> 3. get the localized title, which is a resource key .pluginTitle
> 4. if the localized title doesn't exist - then use the default title
> 5. fill in the labelMap table
> the reason for using .pluginTitle instead of some other constant 
> name is that a bundle can provide more than one plugins, as example 
> webconsole itself. In this case we need to provide titles for all plugins and 
> this involves the label.
> This can be achieved easily by adding the following method in OsgiManager:
> private final Map localizedLabelMap(final Locale locale)
> {
> Map map = new HashMap();
> ResourceBundle resourceBundle;
> AbstractWebConsolePlugin plugin;
> String label;
> String title;
> for (Iterator pi = plugins.values().iterator(); pi.hasNext();)
> {
> plugin = (AbstractWebConsolePlugin) pi.next();
> resourceBundle = 
> resourceBundleManager.getResourceBundle(plugin.getBundle(),
> locale);
> label = plugin.getLabel();
> title = plugin.getTitle();
> try
> {
> final String res = plugin.getLabel() + ".pluginTitle";
> title = resourceBundle.getString(res);
> // our Resource Bundle doesn't throw exception, so if
> // the value is same as the property key - revert to
> // the original title
> if (title.equals(res))
> {
> title = plugin.getTitle();
> }
> }
> catch (Throwable e)
> {
> /* ignore missing resource - use default title */
> }
> map.put(label, title);
> }
> return map;
> }
> and modify the service() method as follows:
> Map labelMap = localizedLabelMap(request.getLocale());
> // the official request attributes
> req.setAttribute( WebConsoleConstants.ATTR_LABEL_MAP, labelMap );

-- 
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-2158) Localization of plugin titles

[Valentin Valchev (JIRA)]

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

Valentin Valchev edited comment on FELIX-2158 at 3/4/10 8:50 AM:
-

I'm not sure if the localizableTitle will work. Does the resource bundle 
passed, to a plugin, when it is rendered contains a combined resources of all 
Plugins?

See, the title for each plugin is it's own resources. And the abstract console 
when rendering a single plugin, still need the title of all others - to display 
the navigation.

Though, we might use this % prefix to optimize a little bit the process:
- getTitle()
- if starts with %
   - getLocalizedTitle()
- store into the labelMap

  was (Author: v_valchev):
I'm not sure if the localizableTitle will work. Does the resource bundle 
passed, to a plugin, when it is rendered contains a combined resources of all 
Plugins?

See, the title for each plugin is it's own resources. And the abstract console 
when rendering a single plugin, still need the title of all others - to display 
the navigation.
  
> Localization of plugin titles
> -
>
> Key: FELIX-2158
> URL: https://issues.apache.org/jira/browse/FELIX-2158
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Reporter: Valentin Valchev
>
> We have added localization support, but there is one thing missing - the 
> titles of the plugins, that are rendered on top.
> So now, even though the plugins are completely localized, the navigation 
> between the plugins is not. However, we need to keep the web console 
> compatible with the old API, so the change should be transparent.
> I've been thinking about the problem and came to the following solution:
> when request is made, the webconsole will:
> 1. obtain the resource bundle for plugins
> 2. for each plugin
> 3. get the localized title, which is a resource key .pluginTitle
> 4. if the localized title doesn't exist - then use the default title
> 5. fill in the labelMap table
> the reason for using .pluginTitle instead of some other constant 
> name is that a bundle can provide more than one plugins, as example 
> webconsole itself. In this case we need to provide titles for all plugins and 
> this involves the label.
> This can be achieved easily by adding the following method in OsgiManager:
> private final Map localizedLabelMap(final Locale locale)
> {
> Map map = new HashMap();
> ResourceBundle resourceBundle;
> AbstractWebConsolePlugin plugin;
> String label;
> String title;
> for (Iterator pi = plugins.values().iterator(); pi.hasNext();)
> {
> plugin = (AbstractWebConsolePlugin) pi.next();
> resourceBundle = 
> resourceBundleManager.getResourceBundle(plugin.getBundle(),
> locale);
> label = plugin.getLabel();
> title = plugin.getTitle();
> try
> {
> final String res = plugin.getLabel() + ".pluginTitle";
> title = resourceBundle.getString(res);
> // our Resource Bundle doesn't throw exception, so if
> // the value is same as the property key - revert to
> // the original title
> if (title.equals(res))
> {
> title = plugin.getTitle();
> }
> }
> catch (Throwable e)
> {
> /* ignore missing resource - use default title */
> }
> map.put(label, title);
> }
> return map;
> }
> and modify the service() method as follows:
> Map labelMap = localizedLabelMap(request.getLocale());
> // the official request attributes
> req.setAttribute( WebConsoleConstants.ATTR_LABEL_MAP, labelMap );

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

Re: [VOTE] Release Karaf 1.4.0 - Take 3

[Freeman Fang]

+1 (Non-binding)

Freeman
On 2010-3-3, at 下午5:15, Chris Custine wrote:


The Karaf 1.4.0 artifacts have been staged for release.

This release build includes some missing headers as pointed out by  
Karl in

the previous vote, as well as some additional ones discovered after
upgrading to a newer Rat version.  There is one known Rat failure in
manual/src/styles/print.css because rat does not recognize the MIT  
license
text, but this file is now properly noted in the manual NOTICE file  
so the
rat failure can be safely ignored.  I have also fixed the  
duplicate .asc.asc

signatures.

As with the previous vote, I have noted that the vote will be open  
for *at
least* 72 hours in order to allow time for proper review.  Thanks  
for your

patience.

Release notes are here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&styleName=Html&version=12314410

Staging repository:
https://repository.apache.org/content/repositories/orgapachefelix-003/

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 003 /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 at least 72 hours.

--
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



--
Freeman Fang

Open Source SOA: http://fusesource.com

[jira] Commented: (FELIX-2158) Localization of plugin titles

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on FELIX-2158:
--

It doesn't use the manifest, it just uses the same mechanism.

Its all in the getTitle() method:

   * If getTitle() returns a string prefixed with "%" it will be translated
   * If getTitle() does not return such a prefixed string, it will not be 
translated

Or, even easier: We can say, that if plugins want to have their titles 
translated, the title should be a string enclosed in ${} and then the output 
filter handles the rest.

Or, we enclose the raw title in ${} when rendering it

 

> Localization of plugin titles
> -
>
> Key: FELIX-2158
> URL: https://issues.apache.org/jira/browse/FELIX-2158
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Reporter: Valentin Valchev
>
> We have added localization support, but there is one thing missing - the 
> titles of the plugins, that are rendered on top.
> So now, even though the plugins are completely localized, the navigation 
> between the plugins is not. However, we need to keep the web console 
> compatible with the old API, so the change should be transparent.
> I've been thinking about the problem and came to the following solution:
> when request is made, the webconsole will:
> 1. obtain the resource bundle for plugins
> 2. for each plugin
> 3. get the localized title, which is a resource key .pluginTitle
> 4. if the localized title doesn't exist - then use the default title
> 5. fill in the labelMap table
> the reason for using .pluginTitle instead of some other constant 
> name is that a bundle can provide more than one plugins, as example 
> webconsole itself. In this case we need to provide titles for all plugins and 
> this involves the label.
> This can be achieved easily by adding the following method in OsgiManager:
> private final Map localizedLabelMap(final Locale locale)
> {
> Map map = new HashMap();
> ResourceBundle resourceBundle;
> AbstractWebConsolePlugin plugin;
> String label;
> String title;
> for (Iterator pi = plugins.values().iterator(); pi.hasNext();)
> {
> plugin = (AbstractWebConsolePlugin) pi.next();
> resourceBundle = 
> resourceBundleManager.getResourceBundle(plugin.getBundle(),
> locale);
> label = plugin.getLabel();
> title = plugin.getTitle();
> try
> {
> final String res = plugin.getLabel() + ".pluginTitle";
> title = resourceBundle.getString(res);
> // our Resource Bundle doesn't throw exception, so if
> // the value is same as the property key - revert to
> // the original title
> if (title.equals(res))
> {
> title = plugin.getTitle();
> }
> }
> catch (Throwable e)
> {
> /* ignore missing resource - use default title */
> }
> map.put(label, title);
> }
> return map;
> }
> and modify the service() method as follows:
> Map labelMap = localizedLabelMap(request.getLocale());
> // the official request attributes
> req.setAttribute( WebConsoleConstants.ATTR_LABEL_MAP, labelMap );

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

[jira] Commented: (FELIX-2158) Localization of plugin titles

[Valentin Valchev (JIRA)]

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

Valentin Valchev commented on FELIX-2158:
-

I guess, the easiest is always better if works correctly ;))



> Localization of plugin titles
> -
>
> Key: FELIX-2158
> URL: https://issues.apache.org/jira/browse/FELIX-2158
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Reporter: Valentin Valchev
>
> We have added localization support, but there is one thing missing - the 
> titles of the plugins, that are rendered on top.
> So now, even though the plugins are completely localized, the navigation 
> between the plugins is not. However, we need to keep the web console 
> compatible with the old API, so the change should be transparent.
> I've been thinking about the problem and came to the following solution:
> when request is made, the webconsole will:
> 1. obtain the resource bundle for plugins
> 2. for each plugin
> 3. get the localized title, which is a resource key .pluginTitle
> 4. if the localized title doesn't exist - then use the default title
> 5. fill in the labelMap table
> the reason for using .pluginTitle instead of some other constant 
> name is that a bundle can provide more than one plugins, as example 
> webconsole itself. In this case we need to provide titles for all plugins and 
> this involves the label.
> This can be achieved easily by adding the following method in OsgiManager:
> private final Map localizedLabelMap(final Locale locale)
> {
> Map map = new HashMap();
> ResourceBundle resourceBundle;
> AbstractWebConsolePlugin plugin;
> String label;
> String title;
> for (Iterator pi = plugins.values().iterator(); pi.hasNext();)
> {
> plugin = (AbstractWebConsolePlugin) pi.next();
> resourceBundle = 
> resourceBundleManager.getResourceBundle(plugin.getBundle(),
> locale);
> label = plugin.getLabel();
> title = plugin.getTitle();
> try
> {
> final String res = plugin.getLabel() + ".pluginTitle";
> title = resourceBundle.getString(res);
> // our Resource Bundle doesn't throw exception, so if
> // the value is same as the property key - revert to
> // the original title
> if (title.equals(res))
> {
> title = plugin.getTitle();
> }
> }
> catch (Throwable e)
> {
> /* ignore missing resource - use default title */
> }
> map.put(label, title);
> }
> return map;
> }
> and modify the service() method as follows:
> Map labelMap = localizedLabelMap(request.getLocale());
> // the official request attributes
> req.setAttribute( WebConsoleConstants.ATTR_LABEL_MAP, labelMap );

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

[jira] Commented: (FELIX-2119) Bundle update fails, if OBR is not installed

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on FELIX-2119:
--

You are right ;-)

> Bundle update fails, if OBR is not installed
> 
>
> Key: FELIX-2119
> URL: https://issues.apache.org/jira/browse/FELIX-2119
> Project: Felix
>  Issue Type: Bug
>  Components: Web Console
>Reporter: Valentin Valchev
> Fix For: webconsole-3.0.0
>
>
> The reason for this is that UpdateHelper depends on OBR service API. While 
> OBR is not a core service, its absence shouldn't disallow execution of normal 
> bundle life-cycle commands.
> Stack trace:
> Exception: java.lang.NoClassDefFoundError: [Lorg/osgi/service/obr/Resource;
> at java.lang.Class.getDeclaredMethods0(Native Method)
> at java.lang.Class.privateGetDeclaredMethods(Unknown Source)
> at java.lang.Class.getDeclaredMethod(Unknown Source)
> at java.lang.Thread$1.run(Unknown Source)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.lang.Thread.auditSubclass(Unknown Source)
> at java.lang.Thread.isCCLOverridden(Unknown Source)
> at java.lang.Thread.init(Unknown Source)
> at java.lang.Thread.(Unknown Source)
> at 
> org.apache.felix.webconsole.internal.core.BaseUpdateInstallHelper.(BaseUpdateInstallHelper.java:45)
> at 
> org.apache.felix.webconsole.internal.core.UpdateHelper.(UpdateHelper.java:52)
> at 
> org.apache.felix.webconsole.internal.core.UpdateHelper.(UpdateHelper.java:46)
> at 
> org.apache.felix.webconsole.internal.core.BundlesServlet$4.(BundlesServlet.java:1283)
> at 
> org.apache.felix.webconsole.internal.core.BundlesServlet.update(BundlesServlet.java:1282)
> at 
> org.apache.felix.webconsole.internal.core.BundlesServlet.doPost(BundlesServlet.java:312)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:815)
> at 
> org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:372)

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

[jira] Updated: (FELIX-2158) Localization of plugin titles

[Felix Meschberger (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-2158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Felix Meschberger updated FELIX-2158:
-

Attachment: FELIX-2158.patch

Trivial patch to localize the navigation header.

This patch simply wraps the plugin titles with "${ ... }" causing them to be 
localized on output by the output filter. This makes use of the fact, that the 
key is used if there is no resource for a given key.

Thus:

${Non Translated Title}  converts to "Non Translated Title"
${l10n.title} might convert to "Übersetzter Titel" ("Tranlsated Title" in 
German)

> Localization of plugin titles
> -
>
> Key: FELIX-2158
> URL: https://issues.apache.org/jira/browse/FELIX-2158
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Reporter: Valentin Valchev
> Attachments: FELIX-2158.patch
>
>
> We have added localization support, but there is one thing missing - the 
> titles of the plugins, that are rendered on top.
> So now, even though the plugins are completely localized, the navigation 
> between the plugins is not. However, we need to keep the web console 
> compatible with the old API, so the change should be transparent.
> I've been thinking about the problem and came to the following solution:
> when request is made, the webconsole will:
> 1. obtain the resource bundle for plugins
> 2. for each plugin
> 3. get the localized title, which is a resource key .pluginTitle
> 4. if the localized title doesn't exist - then use the default title
> 5. fill in the labelMap table
> the reason for using .pluginTitle instead of some other constant 
> name is that a bundle can provide more than one plugins, as example 
> webconsole itself. In this case we need to provide titles for all plugins and 
> this involves the label.
> This can be achieved easily by adding the following method in OsgiManager:
> private final Map localizedLabelMap(final Locale locale)
> {
> Map map = new HashMap();
> ResourceBundle resourceBundle;
> AbstractWebConsolePlugin plugin;
> String label;
> String title;
> for (Iterator pi = plugins.values().iterator(); pi.hasNext();)
> {
> plugin = (AbstractWebConsolePlugin) pi.next();
> resourceBundle = 
> resourceBundleManager.getResourceBundle(plugin.getBundle(),
> locale);
> label = plugin.getLabel();
> title = plugin.getTitle();
> try
> {
> final String res = plugin.getLabel() + ".pluginTitle";
> title = resourceBundle.getString(res);
> // our Resource Bundle doesn't throw exception, so if
> // the value is same as the property key - revert to
> // the original title
> if (title.equals(res))
> {
> title = plugin.getTitle();
> }
> }
> catch (Throwable e)
> {
> /* ignore missing resource - use default title */
> }
> map.put(label, title);
> }
> return map;
> }
> and modify the service() method as follows:
> Map labelMap = localizedLabelMap(request.getLocale());
> // the official request attributes
> req.setAttribute( WebConsoleConstants.ATTR_LABEL_MAP, labelMap );

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

[jira] Assigned: (FELIX-2119) Bundle update fails, if OBR is not installed

[Felix Meschberger (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-2119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Felix Meschberger reassigned FELIX-2119:


Assignee: Felix Meschberger

> Bundle update fails, if OBR is not installed
> 
>
> Key: FELIX-2119
> URL: https://issues.apache.org/jira/browse/FELIX-2119
> Project: Felix
>  Issue Type: Bug
>  Components: Web Console
>Reporter: Valentin Valchev
>Assignee: Felix Meschberger
> Fix For: webconsole-3.0.0
>
>
> The reason for this is that UpdateHelper depends on OBR service API. While 
> OBR is not a core service, its absence shouldn't disallow execution of normal 
> bundle life-cycle commands.
> Stack trace:
> Exception: java.lang.NoClassDefFoundError: [Lorg/osgi/service/obr/Resource;
> at java.lang.Class.getDeclaredMethods0(Native Method)
> at java.lang.Class.privateGetDeclaredMethods(Unknown Source)
> at java.lang.Class.getDeclaredMethod(Unknown Source)
> at java.lang.Thread$1.run(Unknown Source)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.lang.Thread.auditSubclass(Unknown Source)
> at java.lang.Thread.isCCLOverridden(Unknown Source)
> at java.lang.Thread.init(Unknown Source)
> at java.lang.Thread.(Unknown Source)
> at 
> org.apache.felix.webconsole.internal.core.BaseUpdateInstallHelper.(BaseUpdateInstallHelper.java:45)
> at 
> org.apache.felix.webconsole.internal.core.UpdateHelper.(UpdateHelper.java:52)
> at 
> org.apache.felix.webconsole.internal.core.UpdateHelper.(UpdateHelper.java:46)
> at 
> org.apache.felix.webconsole.internal.core.BundlesServlet$4.(BundlesServlet.java:1283)
> at 
> org.apache.felix.webconsole.internal.core.BundlesServlet.update(BundlesServlet.java:1282)
> at 
> org.apache.felix.webconsole.internal.core.BundlesServlet.doPost(BundlesServlet.java:312)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:815)
> at 
> org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:372)

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

[jira] Created: (FELIX-2167) Simplify UpdateHelper.updateFromBundleLocation method

[Felix Meschberger (JIRA)]

Simplify UpdateHelper.updateFromBundleLocation method
-

 Key: FELIX-2167
 URL: https://issues.apache.org/jira/browse/FELIX-2167
 Project: Felix
  Issue Type: Improvement
  Components: Web Console
Reporter: Felix Meschberger
Assignee: Felix Meschberger
 Fix For: webconsole-3.0.0


As noted by Valentin Valchev in a comment [1] to FELIX-2119, the 
UpdateHelper.updateFromBundleLocation should be modified to just call 
Bundle.upate() to have the framework itself care to try to update the bundle 
from the bundle location.

[1] 
https://issues.apache.org/jira/browse/FELIX-2119?focusedCommentId=12841123&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12841123

-- 
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-2119) Bundle update fails, if OBR is not installed

[Felix Meschberger (JIRA)]

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

Felix Meschberger edited comment on FELIX-2119 at 3/4/10 10:09 AM:
---

You are right ;-)

Created FELIX-2167 to track this change

  was (Author: fmeschbe):
You are right ;-)
  
> Bundle update fails, if OBR is not installed
> 
>
> Key: FELIX-2119
> URL: https://issues.apache.org/jira/browse/FELIX-2119
> Project: Felix
>  Issue Type: Bug
>  Components: Web Console
>Reporter: Valentin Valchev
>Assignee: Felix Meschberger
> Fix For: webconsole-3.0.0
>
>
> The reason for this is that UpdateHelper depends on OBR service API. While 
> OBR is not a core service, its absence shouldn't disallow execution of normal 
> bundle life-cycle commands.
> Stack trace:
> Exception: java.lang.NoClassDefFoundError: [Lorg/osgi/service/obr/Resource;
> at java.lang.Class.getDeclaredMethods0(Native Method)
> at java.lang.Class.privateGetDeclaredMethods(Unknown Source)
> at java.lang.Class.getDeclaredMethod(Unknown Source)
> at java.lang.Thread$1.run(Unknown Source)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.lang.Thread.auditSubclass(Unknown Source)
> at java.lang.Thread.isCCLOverridden(Unknown Source)
> at java.lang.Thread.init(Unknown Source)
> at java.lang.Thread.(Unknown Source)
> at 
> org.apache.felix.webconsole.internal.core.BaseUpdateInstallHelper.(BaseUpdateInstallHelper.java:45)
> at 
> org.apache.felix.webconsole.internal.core.UpdateHelper.(UpdateHelper.java:52)
> at 
> org.apache.felix.webconsole.internal.core.UpdateHelper.(UpdateHelper.java:46)
> at 
> org.apache.felix.webconsole.internal.core.BundlesServlet$4.(BundlesServlet.java:1283)
> at 
> org.apache.felix.webconsole.internal.core.BundlesServlet.update(BundlesServlet.java:1282)
> at 
> org.apache.felix.webconsole.internal.core.BundlesServlet.doPost(BundlesServlet.java:312)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:815)
> at 
> org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:372)

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

[jira] Resolved: (FELIX-2167) Simplify UpdateHelper.updateFromBundleLocation method

[Felix Meschberger (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-2167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Felix Meschberger resolved FELIX-2167.
--

Resolution: Fixed

Implemented this change in Rev. 918922.

This has the added benefit, that the bundle is not only updated through the 
bundle location but through the bundle update location if the 
"Bundle-UpdateLocation" is set in the bundle manifest.

> Simplify UpdateHelper.updateFromBundleLocation method
> -
>
> Key: FELIX-2167
> URL: https://issues.apache.org/jira/browse/FELIX-2167
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Reporter: Felix Meschberger
>Assignee: Felix Meschberger
> Fix For: webconsole-3.0.0
>
>
> As noted by Valentin Valchev in a comment [1] to FELIX-2119, the 
> UpdateHelper.updateFromBundleLocation should be modified to just call 
> Bundle.upate() to have the framework itself care to try to update the bundle 
> from the bundle location.
> [1] 
> https://issues.apache.org/jira/browse/FELIX-2119?focusedCommentId=12841123&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12841123

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

[jira] Commented: (FELIX-2158) Localization of plugin titles

[Valentin Valchev (JIRA)]

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

Valentin Valchev commented on FELIX-2158:
-

Unfortunately the provided patch doesn't work correctly.

All plugin titles from web console are translated correctly - this is OK.
The title of a plugin that is in external bundle, is translated ONLY when you 
select the plugin. If you current selection is "Bundles" as example, the title 
is not translated.

This is what I've tried to explain you. The resource bundle of a plugin is 
accessible only if you open it. And rendering a selected plugin, still requires 
the localization of all other plugin titles.

> Localization of plugin titles
> -
>
> Key: FELIX-2158
> URL: https://issues.apache.org/jira/browse/FELIX-2158
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Reporter: Valentin Valchev
> Attachments: FELIX-2158.patch
>
>
> We have added localization support, but there is one thing missing - the 
> titles of the plugins, that are rendered on top.
> So now, even though the plugins are completely localized, the navigation 
> between the plugins is not. However, we need to keep the web console 
> compatible with the old API, so the change should be transparent.
> I've been thinking about the problem and came to the following solution:
> when request is made, the webconsole will:
> 1. obtain the resource bundle for plugins
> 2. for each plugin
> 3. get the localized title, which is a resource key .pluginTitle
> 4. if the localized title doesn't exist - then use the default title
> 5. fill in the labelMap table
> the reason for using .pluginTitle instead of some other constant 
> name is that a bundle can provide more than one plugins, as example 
> webconsole itself. In this case we need to provide titles for all plugins and 
> this involves the label.
> This can be achieved easily by adding the following method in OsgiManager:
> private final Map localizedLabelMap(final Locale locale)
> {
> Map map = new HashMap();
> ResourceBundle resourceBundle;
> AbstractWebConsolePlugin plugin;
> String label;
> String title;
> for (Iterator pi = plugins.values().iterator(); pi.hasNext();)
> {
> plugin = (AbstractWebConsolePlugin) pi.next();
> resourceBundle = 
> resourceBundleManager.getResourceBundle(plugin.getBundle(),
> locale);
> label = plugin.getLabel();
> title = plugin.getTitle();
> try
> {
> final String res = plugin.getLabel() + ".pluginTitle";
> title = resourceBundle.getString(res);
> // our Resource Bundle doesn't throw exception, so if
> // the value is same as the property key - revert to
> // the original title
> if (title.equals(res))
> {
> title = plugin.getTitle();
> }
> }
> catch (Throwable e)
> {
> /* ignore missing resource - use default title */
> }
> map.put(label, title);
> }
> return map;
> }
> and modify the service() method as follows:
> Map labelMap = localizedLabelMap(request.getLocale());
> // the official request attributes
> req.setAttribute( WebConsoleConstants.ATTR_LABEL_MAP, labelMap );

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

[jira] Commented: (FELIX-2166) creating a second sigil project breaks with internal error

[Gustavo Morozowski (JIRA)]

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

Gustavo Morozowski commented on FELIX-2166:
---

confirmed working

> creating a second sigil project breaks with internal error
> --
>
> Key: FELIX-2166
> URL: https://issues.apache.org/jira/browse/FELIX-2166
> Project: Felix
>  Issue Type: Bug
>  Components: Sigil
>Reporter: Gustavo Morozowski
>
> Created NewtonInterface project and NewtonService project in sequence latest 
> daily build
> eclipse.buildId=unknown
> java.version=1.6.0_18
> java.vendor=Sun Microsystems Inc.
> BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US
> Framework arguments:  -product org.eclipse.epp.package.java.product
> Command-line arguments:  -os win32 -ws win32 -arch x86 -product 
> org.eclipse.epp.package.java.product
> Error
> Wed Mar 03 19:24:21 GMT-03:00 2010
> An internal error occurred during: "Resolving Sigil project".
> java.lang.IllegalArgumentException: Attempted to beginRule: R/, does not 
> match outer scope rule: P/NewtonInterface
> at org.eclipse.core.runtime.Assert.isLegal(Assert.java:63)
> at org.eclipse.core.internal.jobs.ThreadJob.illegalPush(ThreadJob.java:120)
> at org.eclipse.core.internal.jobs.ThreadJob.push(ThreadJob.java:230)
> at org.eclipse.core.internal.jobs.ImplicitJobs.begin(ImplicitJobs.java:80)
> at org.eclipse.core.internal.jobs.JobManager.beginRule(JobManager.java:232)
> at 
> org.eclipse.core.internal.resources.WorkManager.checkIn(WorkManager.java:117)
> at 
> org.eclipse.core.internal.resources.Workspace.prepareOperation(Workspace.java:1747)
> at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1795)
> at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1782)
> at org.eclipse.core.internal.resources.Project.internalBuild(Project.java:502)
> at org.eclipse.core.internal.resources.Project.build(Project.java:94)
> at org.apache.felix.sigil.eclipse.SigilCore.rebuild(SigilCore.java:587)
> at 
> org.apache.felix.sigil.eclipse.SigilCore.rebuildBundleDependencies(SigilCore.java:577)
> at 
> org.apache.felix.sigil.eclipse.internal.model.project.SigilProject.rebuildDependencies(SigilProject.java:179)
> at 
> org.apache.felix.sigil.eclipse.job.ResolveProjectsJob.run(ResolveProjectsJob.java:65)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

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

[jira] Created: (FELIX-2168) recreating a deleted project with the same name fails

[Gustavo Morozowski (JIRA)]

recreating a deleted project with the same name fails
-

 Key: FELIX-2168
 URL: https://issues.apache.org/jira/browse/FELIX-2168
 Project: Felix
  Issue Type: Bug
  Components: Sigil
 Environment: windows xp sp3
sun jre 1.6.0_18
Reporter: Gustavo Morozowski
Priority: Minor


Create a new Sigil project named dummyproject, then delete with delete on disk 
set. Recreate the project with the same name, when I click finish the dialog 
box doesn't close.

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

Re: Modifying multi-value property with Ecmascript

[Felix Meschberger]

Hi

(from the user@ question):

Without further thinking, it might be interesting to extend the
JavaScript functionality as follows:

  * Have the JCR Property representation ScriptableProperty be an
EcmaScript array, allowing indexed access to the values and allowing
for EcmaScript Array API.

 Example: add a value to the property
node.propName.push("new value");

Critical here is that the ScriptableProperty would have to cope
with the multi-value issues around this.

  * Allow for direct node assignment to set property values.

  Example: set a property to a new value (array possible)
 node.propName = "single value";
 node.anotherProp = [ "value1", "value2" ];

A final note, though: Adding support for such idioms clearly separates
the EcmaScript support from the API supported in (all) other languags.
Specifically it would support API not supported by the core JCR API.
This may be fine, but we have to be aware of it.

Regards
Felix


On 04.03.2010 11:05, Erik Buene wrote:
> Hi
> 
> What is the best way to modify a multi-value property using ecmascript (.esp
> files)?
> 
> Was expecting something like this to work:
> 
> var arr = node.property;
> arr.push("added value");
> node.property = arr;
> node.save();
> 
> And it doesn't produce errors, but the value does not seem to be modified in
> the repository.
> 
> The only way I have been able to do it is:
> 
> var arr = node.property;
> arr.push("added value");
> var valueMap =
> (resource.adaptTo(Packages.org.apache.sling.api.resource.PersistableValueMap));
> var stringArray = java.lang.reflect.Array.newInstance(java.lang.String,
> arr.length);
> for(var i =0; i stringArray[i] = new Packages.java.lang.String(arr[i]);
> }
> vm.put("property", stringArray);
> vm.save();
> 
> Surely, there must be a more practical way of doing this.
> 
> Best regards,
> Erik Buene
> 

[jira] Created: (FELIX-2169) Improve dev:show-tree performance and avoid NPE for installed bundle

[Gert Vanthienen (JIRA)]

Improve dev:show-tree performance and avoid NPE for installed bundle


 Key: FELIX-2169
 URL: https://issues.apache.org/jira/browse/FELIX-2169
 Project: Felix
  Issue Type: Bug
  Components: Karaf
Affects Versions: karaf-1.2.0
Reporter: Gert Vanthienen
Assignee: Gert Vanthienen
 Fix For: karaf-1.4.0


As reported in https://issues.apache.org/activemq/browse/SMX4-489, the current 
implementation of the dev:show-tree command has two problems:
* for bundles with an extensive set of dependencies, calculating the dependency 
tree can take a long time (several seconds)
* for installed bundles with imports for which no suitable export is available, 
the command fails with a NullPointerException

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

[jira] Updated: (FELIX-2169) Improve dev:show-tree performance and avoid NPE for installed bundle

[Gert Vanthienen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gert Vanthienen updated FELIX-2169:
---

Affects Version/s: (was: karaf-1.2.0)
   karaf-1.4.0
Fix Version/s: (was: karaf-1.4.0)
   karaf 1.6.0

> Improve dev:show-tree performance and avoid NPE for installed bundle
> 
>
> Key: FELIX-2169
> URL: https://issues.apache.org/jira/browse/FELIX-2169
> Project: Felix
>  Issue Type: Bug
>  Components: Karaf
>Affects Versions: karaf-1.4.0
>Reporter: Gert Vanthienen
>Assignee: Gert Vanthienen
> Fix For: karaf 1.6.0
>
>
> As reported in https://issues.apache.org/activemq/browse/SMX4-489, the 
> current implementation of the dev:show-tree command has two problems:
> * for bundles with an extensive set of dependencies, calculating the 
> dependency tree can take a long time (several seconds)
> * for installed bundles with imports for which no suitable export is 
> available, the command fails with a NullPointerException

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

[jira] Commented: (FELIX-2158) Localization of plugin titles

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on FELIX-2158:
--

Ah yes, you are right --- sometimes it takes a bit longer until I get it ;-)

So, your initial proposal is then propably the only solution with the 
simplification that we just run all regular titles past the resource bundle (or 
limit this step to titles with a leading "%").

For increased performance, we might want to cache the maps for different 
languages.

> Localization of plugin titles
> -
>
> Key: FELIX-2158
> URL: https://issues.apache.org/jira/browse/FELIX-2158
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Reporter: Valentin Valchev
> Attachments: FELIX-2158.patch
>
>
> We have added localization support, but there is one thing missing - the 
> titles of the plugins, that are rendered on top.
> So now, even though the plugins are completely localized, the navigation 
> between the plugins is not. However, we need to keep the web console 
> compatible with the old API, so the change should be transparent.
> I've been thinking about the problem and came to the following solution:
> when request is made, the webconsole will:
> 1. obtain the resource bundle for plugins
> 2. for each plugin
> 3. get the localized title, which is a resource key .pluginTitle
> 4. if the localized title doesn't exist - then use the default title
> 5. fill in the labelMap table
> the reason for using .pluginTitle instead of some other constant 
> name is that a bundle can provide more than one plugins, as example 
> webconsole itself. In this case we need to provide titles for all plugins and 
> this involves the label.
> This can be achieved easily by adding the following method in OsgiManager:
> private final Map localizedLabelMap(final Locale locale)
> {
> Map map = new HashMap();
> ResourceBundle resourceBundle;
> AbstractWebConsolePlugin plugin;
> String label;
> String title;
> for (Iterator pi = plugins.values().iterator(); pi.hasNext();)
> {
> plugin = (AbstractWebConsolePlugin) pi.next();
> resourceBundle = 
> resourceBundleManager.getResourceBundle(plugin.getBundle(),
> locale);
> label = plugin.getLabel();
> title = plugin.getTitle();
> try
> {
> final String res = plugin.getLabel() + ".pluginTitle";
> title = resourceBundle.getString(res);
> // our Resource Bundle doesn't throw exception, so if
> // the value is same as the property key - revert to
> // the original title
> if (title.equals(res))
> {
> title = plugin.getTitle();
> }
> }
> catch (Throwable e)
> {
> /* ignore missing resource - use default title */
> }
> map.put(label, title);
> }
> return map;
> }
> and modify the service() method as follows:
> Map labelMap = localizedLabelMap(request.getLocale());
> // the official request attributes
> req.setAttribute( WebConsoleConstants.ATTR_LABEL_MAP, labelMap );

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

[jira] Resolved: (FELIX-2169) Improve dev:show-tree performance and avoid NPE for installed bundle

[Gert Vanthienen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gert Vanthienen resolved FELIX-2169.


Resolution: Fixed

Fixed in http://svn.apache.org/viewvc?view=revision&revision=918963
Will ask Charles Mouillard to confirm that this fixes the issue he has reported.

> Improve dev:show-tree performance and avoid NPE for installed bundle
> 
>
> Key: FELIX-2169
> URL: https://issues.apache.org/jira/browse/FELIX-2169
> Project: Felix
>  Issue Type: Bug
>  Components: Karaf
>Affects Versions: karaf-1.4.0
>Reporter: Gert Vanthienen
>Assignee: Gert Vanthienen
> Fix For: karaf 1.6.0
>
>
> As reported in https://issues.apache.org/activemq/browse/SMX4-489, the 
> current implementation of the dev:show-tree command has two problems:
> * for bundles with an extensive set of dependencies, calculating the 
> dependency tree can take a long time (several seconds)
> * for installed bundles with imports for which no suitable export is 
> available, the command fails with a NullPointerException

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

[jira] Commented: (FELIX-2169) Improve dev:show-tree performance and avoid NPE for installed bundle

[Charles Moulliard (JIRA)]

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

Charles Moulliard commented on FELIX-2169:
--

I rebuild karaf and make a test.

> Improve dev:show-tree performance and avoid NPE for installed bundle
> 
>
> Key: FELIX-2169
> URL: https://issues.apache.org/jira/browse/FELIX-2169
> Project: Felix
>  Issue Type: Bug
>  Components: Karaf
>Affects Versions: karaf-1.4.0
>Reporter: Gert Vanthienen
>Assignee: Gert Vanthienen
> Fix For: karaf 1.6.0
>
>
> As reported in https://issues.apache.org/activemq/browse/SMX4-489, the 
> current implementation of the dev:show-tree command has two problems:
> * for bundles with an extensive set of dependencies, calculating the 
> dependency tree can take a long time (several seconds)
> * for installed bundles with imports for which no suitable export is 
> available, the command fails with a NullPointerException

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

Re: [VOTE] Release Karaf 1.4.0 - Take 3

[Charles Moulliard]

+1

Charles Moulliard
Senior Enterprise Architect
Apache Camel Committer

*
blog : http://cmoulliard.blogspot.com
twitter : http://twitter.com/cmoulliard
Linkedlin : http://www.linkedin.com/in/charlesmoulliard

Apache Camel Group :
http://www.linkedin.com/groups?home=&gid=2447439&trk=anet_ug_hm



On Thu, Mar 4, 2010 at 9:59 AM, Freeman Fang  wrote:
> +1 (Non-binding)
>
> Freeman
> On 2010-3-3, at 下午5:15, Chris Custine wrote:
>
>> The Karaf 1.4.0 artifacts have been staged for release.
>>
>> This release build includes some missing headers as pointed out by Karl in
>> the previous vote, as well as some additional ones discovered after
>> upgrading to a newer Rat version.  There is one known Rat failure in
>> manual/src/styles/print.css because rat does not recognize the MIT license
>> text, but this file is now properly noted in the manual NOTICE file so the
>> rat failure can be safely ignored.  I have also fixed the duplicate
>> .asc.asc
>> signatures.
>>
>> As with the previous vote, I have noted that the vote will be open for *at
>> least* 72 hours in order to allow time for proper review.  Thanks for your
>> patience.
>>
>> Release notes are here:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&styleName=Html&version=12314410
>>
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapachefelix-003/
>>
>> 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 003 /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 at least 72 hours.
>>
>> --
>> 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
>
>
> --
> Freeman Fang
> 
> Open Source SOA: http://fusesource.com
>
>

[jira] Created: (FELIX-2170) History of karaf does not work anymore when a second instance of karaf is created and that we are connected to that one

[Charles Moulliard (JIRA)]

History of karaf does not work anymore when a second instance of karaf is 
created and that we are connected to that one
---

 Key: FELIX-2170
 URL: https://issues.apache.org/jira/browse/FELIX-2170
 Project: Felix
  Issue Type: Bug
Affects Versions: karaf-1.2.0
Reporter: Charles Moulliard


History of karaf does not work anymore when a second instance of karaf is 
create and that we are connected to that one

Connecting to host localhost on port 8102
Connected
   __ __  
  / //_/ __ _/ __/
 / ,<  / __ `/ ___/ __ `/ /_
/ /| |/ /_/ / /  / /_/ / __/
   /_/ |_|\__,_/_/   \__,_/_/

 Apache Felix Karaf (1.3.0-SNAPSHOT)

Hit '' for a list of available commands
and '[cmd] --help' for help on a specific command.
Hit '' or 'osgi:shutdown' to shutdown Karaf.

Historic command is still buggy on Windows :

ka...@test> Error executing command: -32
ka...@test> HError executing command: -32
ka...@test> H

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

[jira] Commented: (FELIX-2169) Improve dev:show-tree performance and avoid NPE for installed bundle

[Charles Moulliard (JIRA)]

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

Charles Moulliard commented on FELIX-2169:
--

I have made a test with camel-cxf which contain a lot of dependencies and it 
works fine.

{code}
ka...@root> dev:show-tree  178
Bundle org.apache.camel.camel-cxf [178] is currently ACTIVE

org.apache.camel.camel-cxf [178]
+- org.apache.servicemix.bundles.wsdl4j [173]
+- org.apache.servicemix.specs.activation-api-1.1 [41]
+- org.springframework.beans [37]
|  +- org.ops4j.pax.logging.pax-logging-api [3]
|  +- org.springframework.core [36]
|  |  +- org.ops4j.pax.logging.pax-logging-api [3]
|  |  +- org.apache.commons.collections [119]
|  +- org.apache.servicemix.bundles.cglib [47]
+- org.apache.camel.camel-spring-osgi [55]
|  +- org.springframework.beans [37]
|  +- org.springframework.osgi.core [49]
|  |  +- org.apache.felix.configadmin [5]
|  |  |  +- org.ops4j.pax.logging.pax-logging-api [3]
|  |  +- org.springframework.aop [38]
|  |  |  +- org.springframework.beans [37]
|  |  |  +- org.ops4j.pax.logging.pax-logging-api [3]
|  |  |  +- org.springframework.core [36]
|  |  |  +- org.apache.servicemix.bundles.commons-pool [69]
|  |  |  +- org.apache.servicemix.bundles.aopalliance [35]
|  |  |  +- org.apache.servicemix.bundles.cglib [47]
|  |  +- org.springframework.beans [37]
|  |  +- org.ops4j.pax.logging.pax-logging-api [3]
|  |  +- org.springframework.core [36]
|  |  +- org.springframework.context [39]
|  |  |  +- org.apache.geronimo.specs.geronimo-annotation_1.0_spec [171]
|  |  |  +- org.springframework.aop [38]
|  |  |  +- org.springframework.beans [37]
|  |  |  +- org.apache.geronimo.specs.geronimo-jms_1.1_spec [70]
|  |  |  |  +- org.apache.geronimo.specs.geronimo-jta_1.1_spec [53]
|  |  |  +- org.ops4j.pax.logging.pax-logging-api [3]
|  |  |  +- org.springframework.core [36]
|  |  |  +- org.apache.servicemix.bundles.aopalliance [35]
|  |  |  +- org.apache.servicemix.bundles.cglib [47]
|  |  +- org.apache.servicemix.bundles.aopalliance [35]
|  |  +- org.springframework.osgi.io [48]
|  | +- org.ops4j.pax.logging.pax-logging-api [3]
|  | +- org.springframework.core [36]
|  +- org.ops4j.pax.logging.pax-logging-api [3]
|  +- org.apache.camel.camel-core [46]
|  |  +- org.apache.servicemix.specs.activation-api-1.1 [41]
|  |  +- org.apache.servicemix.bundles.xalan [152]
|  |  |  +- org.apache.servicemix.bundles.xerces [153]
|  |  +- org.ops4j.pax.logging.pax-logging-api [3]
|  |  +- org.apache.servicemix.specs.jaxb-api-2.1 [42]
|  |  |  +- org.apache.servicemix.specs.activation-api-1.1 [41]
|  |  |  +- org.apache.servicemix.specs.stax-api-1.0 [43]
|  |  +- org.springframework.context [39]
|  |  +- org.apache.servicemix.specs.stax-api-1.0 [43]
|  |  +- commons-management [45]
|  +- org.springframework.core [36]
|  +- org.springframework.transaction [54]
|  |  +- org.springframework.aop [38]
|  |  +- org.springframework.beans [37]
|  |  +- org.apache.geronimo.specs.geronimo-jta_1.1_spec [53]
|  |  +- org.ops4j.pax.logging.pax-logging-api [3]
|  |  +- org.springframework.core [36]
|  |  +- org.springframework.context [39]
|  |  +- org.apache.servicemix.bundles.aopalliance [35]
|  +- org.apache.servicemix.specs.jaxb-api-2.1 [42]
|  +- org.springframework.context [39]
+- org.springframework.core [36]
+- org.apache.cxf.bundle [176]
|  +- org.codehaus.jettison.jettison [149]
|  |  +- org.apache.servicemix.specs.stax-api-1.0 [43]
|  +- org.apache.servicemix.bundles.wsdl4j [173]
|  +- org.springframework.jms [144]
|  |  +- org.springframework.aop [38]
|  |  +- org.springframework.beans [37]
|  |  +- org.apache.geronimo.specs.geronimo-jms_1.1_spec [70]
|  |  +- org.ops4j.pax.logging.pax-logging-api [3]
|  |  +- org.springframework.core [36]
|  |  +- org.apache.servicemix.bundles.commons-pool [69]
|  |  +- org.springframework.transaction [54]
|  |  +- org.springframework.context [39]
|  |  +- org.apache.servicemix.bundles.aopalliance [35]
|  +- org.apache.servicemix.specs.activation-api-1.1 [41]
|  +- org.springframework.aop [38]
|  +- org.springframework.beans [37]
|  +- org.apache.geronimo.specs.geronimo-jms_1.1_spec [70]
|  +- org.apache.servicemix.bundles.neethi [168]
|  |  +- org.apache.ws.commons.axiom.axiom-impl [165]
|  |  |  +- org.apache.servicemix.specs.activation-api-1.1 [41]
|  |  |  +- org.ops4j.pax.logging.pax-logging-api [3]
|  |  |  +- org.apache.servicemix.specs.stax-api-1.0 [43]
|  |  |  +- org.apache.ws.commons.axiom.axiom-api [166]
|  |  | +- org.apache.servicemix.specs.activation-api-1.1 [41]
|  |  | +- javax.mail [167]
|  |  | |  +- org.apache.servicemix.specs.activation-api-1.1 [41]
|  |  | +- org.ops4j.pax.logging.pax-logging-api [3]
|  |  | +- org.apache.servicemix.specs.stax-api-1.0 [43]
|  |  +- org.apache.ws.commons.axiom.axiom-api [166]
|  |  +- org.apache.servicemix.specs.stax-api-1.0 [43]
|  +- org.apach

[jira] Closed: (FELIX-2169) Improve dev:show-tree performance and avoid NPE for installed bundle

[Gert Vanthienen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gert Vanthienen closed FELIX-2169.
--


@Charles: Thanks for the feedback!

> Improve dev:show-tree performance and avoid NPE for installed bundle
> 
>
> Key: FELIX-2169
> URL: https://issues.apache.org/jira/browse/FELIX-2169
> Project: Felix
>  Issue Type: Bug
>  Components: Karaf
>Affects Versions: karaf-1.4.0
>Reporter: Gert Vanthienen
>Assignee: Gert Vanthienen
> Fix For: karaf 1.6.0
>
>
> As reported in https://issues.apache.org/activemq/browse/SMX4-489, the 
> current implementation of the dev:show-tree command has two problems:
> * for bundles with an extensive set of dependencies, calculating the 
> dependency tree can take a long time (several seconds)
> * for installed bundles with imports for which no suitable export is 
> available, the command fails with a NullPointerException

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

[jira] Resolved: (FELIX-2166) creating a second sigil project breaks with internal error

[David Savage (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-2166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Savage resolved FELIX-2166.
-

   Resolution: Fixed
Fix Version/s: sigil-1.0.0

resolving issue as confirmed fixed

> creating a second sigil project breaks with internal error
> --
>
> Key: FELIX-2166
> URL: https://issues.apache.org/jira/browse/FELIX-2166
> Project: Felix
>  Issue Type: Bug
>  Components: Sigil
>Reporter: Gustavo Morozowski
> Fix For: sigil-1.0.0
>
>
> Created NewtonInterface project and NewtonService project in sequence latest 
> daily build
> eclipse.buildId=unknown
> java.version=1.6.0_18
> java.vendor=Sun Microsystems Inc.
> BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US
> Framework arguments:  -product org.eclipse.epp.package.java.product
> Command-line arguments:  -os win32 -ws win32 -arch x86 -product 
> org.eclipse.epp.package.java.product
> Error
> Wed Mar 03 19:24:21 GMT-03:00 2010
> An internal error occurred during: "Resolving Sigil project".
> java.lang.IllegalArgumentException: Attempted to beginRule: R/, does not 
> match outer scope rule: P/NewtonInterface
> at org.eclipse.core.runtime.Assert.isLegal(Assert.java:63)
> at org.eclipse.core.internal.jobs.ThreadJob.illegalPush(ThreadJob.java:120)
> at org.eclipse.core.internal.jobs.ThreadJob.push(ThreadJob.java:230)
> at org.eclipse.core.internal.jobs.ImplicitJobs.begin(ImplicitJobs.java:80)
> at org.eclipse.core.internal.jobs.JobManager.beginRule(JobManager.java:232)
> at 
> org.eclipse.core.internal.resources.WorkManager.checkIn(WorkManager.java:117)
> at 
> org.eclipse.core.internal.resources.Workspace.prepareOperation(Workspace.java:1747)
> at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1795)
> at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1782)
> at org.eclipse.core.internal.resources.Project.internalBuild(Project.java:502)
> at org.eclipse.core.internal.resources.Project.build(Project.java:94)
> at org.apache.felix.sigil.eclipse.SigilCore.rebuild(SigilCore.java:587)
> at 
> org.apache.felix.sigil.eclipse.SigilCore.rebuildBundleDependencies(SigilCore.java:577)
> at 
> org.apache.felix.sigil.eclipse.internal.model.project.SigilProject.rebuildDependencies(SigilProject.java:179)
> at 
> org.apache.felix.sigil.eclipse.job.ResolveProjectsJob.run(ResolveProjectsJob.java:65)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

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

[jira] Commented: (FELIX-1996) Console should warn when config is bound to a different bundle

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on FELIX-1996:
--

Actually, if the boundle with the bundle location to which the configuration is 
bound has been uninstalled, the configuration admin support of the current 
(Rev. 918988) trunk locates another bundle providing a description of the 
configuration. If found, that description is used to render the configuration.

Thus, it makes sense, that in such a situation the bundle has been uninstalled 
and re-installed with a different bundle location. Thus informing about the 
bundle location mismatch makes perfect sense.

The user can then still unbind the configuration from the old location and then 
save the configuration to have it bound to the bundle at the new location.

> Console should warn when config is bound to a different bundle
> --
>
> Key: FELIX-1996
> URL: https://issues.apache.org/jira/browse/FELIX-1996
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Affects Versions: webconsole-2.0.4
>Reporter: Bertrand Delacretaz
>Priority: Minor
>
> Working on upgrades of an OSGi-based system, which include moving services 
> from one bundle to another for refactoring purposes, I had several cases 
> where the console didn't display configuration values correctly, because the 
> configuration was bound to a different bundle (B) than the one (A) where the 
> corresponding service comes from. 
> Usually because the service that uses the config used to be in bundle A, but 
> was moved to bundle B.
> The symptoms are either no fields or values shown on the configuration page 
> at all, or all name/value pairs displayed in a single textarea instead of 
> individual fields.
> IIUC that's because the webconsole cannot access the metadata about the 
> configuration fields anymore in this case. 
> If that's correct, it would be good to have a warning on the configuration 
> page when that happens, to help troubleshooting such cases.

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

[jira] Commented: (FELIX-2158) Localization of plugin titles

[Valentin Valchev (JIRA)]

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

Valentin Valchev commented on FELIX-2158:
-

Ok, the modified method is:

private final Map localizedLabelMap(final Locale locale)
{
Map map = new HashMap();
ResourceBundle resourceBundle;
AbstractWebConsolePlugin plugin;
String label;
String title;
for (Iterator pi = plugins.values().iterator(); pi.hasNext();)
{
plugin = (AbstractWebConsolePlugin) pi.next();
resourceBundle = 
resourceBundleManager.getResourceBundle(plugin.getBundle(),
locale);
label = plugin.getLabel();
title = plugin.getTitle();
if (title.startsWith("%"))
{
try
{
title = resourceBundle.getString(title.substring(1));
}
catch (Throwable e)
{
/* ignore missing resource - use default title */
}
}
map.put(label, title);
}

return map;
}

---
I'm not sure that we need cache for different languages since the resource 
bundles are already cached. If we add additional cache it also should care of 
new and disappearing plugins. This might even require some synchronized 
sections. So we will suffer from increased complexity and maybe slowdown 
because of synchronization - or just a little bit more temporary memory per 
request, that is required for the label-to-title map.

> Localization of plugin titles
> -
>
> Key: FELIX-2158
> URL: https://issues.apache.org/jira/browse/FELIX-2158
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Reporter: Valentin Valchev
> Attachments: FELIX-2158.patch
>
>
> We have added localization support, but there is one thing missing - the 
> titles of the plugins, that are rendered on top.
> So now, even though the plugins are completely localized, the navigation 
> between the plugins is not. However, we need to keep the web console 
> compatible with the old API, so the change should be transparent.
> I've been thinking about the problem and came to the following solution:
> when request is made, the webconsole will:
> 1. obtain the resource bundle for plugins
> 2. for each plugin
> 3. get the localized title, which is a resource key .pluginTitle
> 4. if the localized title doesn't exist - then use the default title
> 5. fill in the labelMap table
> the reason for using .pluginTitle instead of some other constant 
> name is that a bundle can provide more than one plugins, as example 
> webconsole itself. In this case we need to provide titles for all plugins and 
> this involves the label.
> This can be achieved easily by adding the following method in OsgiManager:
> private final Map localizedLabelMap(final Locale locale)
> {
> Map map = new HashMap();
> ResourceBundle resourceBundle;
> AbstractWebConsolePlugin plugin;
> String label;
> String title;
> for (Iterator pi = plugins.values().iterator(); pi.hasNext();)
> {
> plugin = (AbstractWebConsolePlugin) pi.next();
> resourceBundle = 
> resourceBundleManager.getResourceBundle(plugin.getBundle(),
> locale);
> label = plugin.getLabel();
> title = plugin.getTitle();
> try
> {
> final String res = plugin.getLabel() + ".pluginTitle";
> title = resourceBundle.getString(res);
> // our Resource Bundle doesn't throw exception, so if
> // the value is same as the property key - revert to
> // the original title
> if (title.equals(res))
> {
> title = plugin.getTitle();
> }
> }
> catch (Throwable e)
> {
> /* ignore missing resource - use default title */
> }
> map.put(label, title);
> }
> return map;
> }
> and modify the service() method as follows:
> Map labelMap = localizedLabelMap(request.getLocale());
> // the official request attributes
> req.setAttribute( WebConsoleConstants.ATTR_LABEL_MAP, labelMap );

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

Re: Modifying multi-value property with Ecmascript

[Felix Meschberger]

oh man ... another one of those mails sent to the wrong list.

Sorry and please ignore.

Regards
Felix

On 04.03.2010 12:36, Felix Meschberger wrote:
> Hi
> 
> (from the user@ question):
> 
> Without further thinking, it might be interesting to extend the
> JavaScript functionality as follows:
> 
>   * Have the JCR Property representation ScriptableProperty be an
> EcmaScript array, allowing indexed access to the values and allowing
> for EcmaScript Array API.
> 
>  Example: add a value to the property
> node.propName.push("new value");
> 
> Critical here is that the ScriptableProperty would have to cope
> with the multi-value issues around this.
> 
>   * Allow for direct node assignment to set property values.
> 
>   Example: set a property to a new value (array possible)
>  node.propName = "single value";
>  node.anotherProp = [ "value1", "value2" ];
> 
> A final note, though: Adding support for such idioms clearly separates
> the EcmaScript support from the API supported in (all) other languags.
> Specifically it would support API not supported by the core JCR API.
> This may be fine, but we have to be aware of it.
> 
> Regards
> Felix
> 
> 
> On 04.03.2010 11:05, Erik Buene wrote:
>> Hi
>>
>> What is the best way to modify a multi-value property using ecmascript (.esp
>> files)?
>>
>> Was expecting something like this to work:
>>
>> var arr = node.property;
>> arr.push("added value");
>> node.property = arr;
>> node.save();
>>
>> And it doesn't produce errors, but the value does not seem to be modified in
>> the repository.
>>
>> The only way I have been able to do it is:
>>
>> var arr = node.property;
>> arr.push("added value");
>> var valueMap =
>> (resource.adaptTo(Packages.org.apache.sling.api.resource.PersistableValueMap));
>> var stringArray = java.lang.reflect.Array.newInstance(java.lang.String,
>> arr.length);
>> for(var i =0; i> stringArray[i] = new Packages.java.lang.String(arr[i]);
>> }
>> vm.put("property", stringArray);
>> vm.save();
>>
>> Surely, there must be a more practical way of doing this.
>>
>> Best regards,
>> Erik Buene
>>

[jira] Issue Comment Edited: (FELIX-2168) recreating a deleted project with the same name fails

[David Savage (JIRA)]

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

David Savage edited comment on FELIX-2168 at 3/4/10 2:41 PM:
-

Ok found the issue, simply failing to clear up the cache. Would be nice if 
there were some way to unit test these sorts of problems as part of the 
build...will send a mail to the list to see if anyone knows of any swt testing 
frameworks that can be used with apache licensed projects...

I've run the daily build early so you should be able to update and get the 
patches. Please close this issue if it works for you...(or obviously reopen if 
still appears broken)

Many thanks...

  was (Author: davemssavage):
Ok found the issue, simply failing to close the cache. Would be nice if 
there were some way to unit test these sorts of problems as part of the 
build...will send a mail to the list to see if anyone knows of any swt testing 
frameworks that can be used with apache licensed projects...

I've run the daily build early so you should be able to update and get the 
patches. Please close this issue if it works for you...(or obviously reopen if 
still appears broken)

Many thanks...
  
> recreating a deleted project with the same name fails
> -
>
> Key: FELIX-2168
> URL: https://issues.apache.org/jira/browse/FELIX-2168
> Project: Felix
>  Issue Type: Bug
>  Components: Sigil
> Environment: windows xp sp3
> sun jre 1.6.0_18
>Reporter: Gustavo Morozowski
>Assignee: David Savage
>Priority: Minor
> Fix For: sigil-1.0.0
>
>
> Create a new Sigil project named dummyproject, then delete with delete on 
> disk set. Recreate the project with the same name, when I click finish the 
> dialog box doesn't close.

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

[jira] Resolved: (FELIX-2168) recreating a deleted project with the same name fails

[David Savage (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-2168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Savage resolved FELIX-2168.
-

   Resolution: Fixed
Fix Version/s: sigil-1.0.0
 Assignee: David Savage

Ok found the issue, simply failing to close the cache. Would be nice if there 
were some way to unit test these sorts of problems as part of the build...will 
send a mail to the list to see if anyone knows of any swt testing frameworks 
that can be used with apache licensed projects...

I've run the daily build early so you should be able to update and get the 
patches. Please close this issue if it works for you...(or obviously reopen if 
still appears broken)

Many thanks...

> recreating a deleted project with the same name fails
> -
>
> Key: FELIX-2168
> URL: https://issues.apache.org/jira/browse/FELIX-2168
> Project: Felix
>  Issue Type: Bug
>  Components: Sigil
> Environment: windows xp sp3
> sun jre 1.6.0_18
>Reporter: Gustavo Morozowski
>Assignee: David Savage
>Priority: Minor
> Fix For: sigil-1.0.0
>
>
> Create a new Sigil project named dummyproject, then delete with delete on 
> disk set. Recreate the project with the same name, when I click finish the 
> dialog box doesn't close.

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

[jira] Updated: (FELIX-2121) ProSyst donation of UPnP plugin for the web console

[Valentin Valchev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-2121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Valentin Valchev updated FELIX-2121:


Attachment: (was: upnp_plugin.zip)

> ProSyst donation of UPnP plugin for the web console
> ---
>
> Key: FELIX-2121
> URL: https://issues.apache.org/jira/browse/FELIX-2121
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Reporter: Valentin Valchev
>Assignee: Felix Meschberger
>
> This plugin is similar to the UPnP Test application but developed as a plugin 
> for the Web Console.
> It is developed as standalone plugin - e.g. not build-into the Apache Web 
> Console but is separate bundle.
> This allows the plugin to dynamically register/unregister itself. This way 
> the plugin is available only when UPnP Service is active.
> Unfortunately I'm not quite aware with maven since most of our projects use 
> ANT. Otherwise I was going to create the full maven structure required to 
> build it.

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

[jira] Updated: (FELIX-2121) ProSyst donation of UPnP plugin for the web console

[Valentin Valchev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-2121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Valentin Valchev updated FELIX-2121:


Attachment: upnp.zip

Updated the attachment, includes NOTICE and apache headers on top of files.
Refactored the package name and added pom.xml base on the events plugin.

The MD5 sum is:
8299dd3424ea1e467da512028dc388ab  upnp.zip


As for the grant - who should be the "Licensor" - me or the CEO of ProSyst 
Labs? 


> ProSyst donation of UPnP plugin for the web console
> ---
>
> Key: FELIX-2121
> URL: https://issues.apache.org/jira/browse/FELIX-2121
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Reporter: Valentin Valchev
>Assignee: Felix Meschberger
> Attachments: upnp.zip
>
>
> This plugin is similar to the UPnP Test application but developed as a plugin 
> for the Web Console.
> It is developed as standalone plugin - e.g. not build-into the Apache Web 
> Console but is separate bundle.
> This allows the plugin to dynamically register/unregister itself. This way 
> the plugin is available only when UPnP Service is active.
> Unfortunately I'm not quite aware with maven since most of our projects use 
> ANT. Otherwise I was going to create the full maven structure required to 
> build it.

-- 
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-2121) ProSyst donation of UPnP plugin for the web console

[Valentin Valchev (JIRA)]

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

Valentin Valchev edited comment on FELIX-2121 at 3/4/10 3:23 PM:
-

Updated the attachment, includes NOTICE and apache headers on top of files.
Refactored the package name and added pom.xml base on the events plugin.

The MD5 sum is:
80390b4b3bed18b16e54ab5492f4b96d  upnp.zip


As for the grant - who should be the "Licensor" - me or the CEO of ProSyst 
Labs? 


  was (Author: v_valchev):
Updated the attachment, includes NOTICE and apache headers on top of files.
Refactored the package name and added pom.xml base on the events plugin.

The MD5 sum is:
8299dd3424ea1e467da512028dc388ab  upnp.zip


As for the grant - who should be the "Licensor" - me or the CEO of ProSyst 
Labs? 

  
> ProSyst donation of UPnP plugin for the web console
> ---
>
> Key: FELIX-2121
> URL: https://issues.apache.org/jira/browse/FELIX-2121
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Reporter: Valentin Valchev
>Assignee: Felix Meschberger
> Attachments: upnp.zip
>
>
> This plugin is similar to the UPnP Test application but developed as a plugin 
> for the Web Console.
> It is developed as standalone plugin - e.g. not build-into the Apache Web 
> Console but is separate bundle.
> This allows the plugin to dynamically register/unregister itself. This way 
> the plugin is available only when UPnP Service is active.
> Unfortunately I'm not quite aware with maven since most of our projects use 
> ANT. Otherwise I was going to create the full maven structure required to 
> build it.

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

Maven bundle plugin version conversion

[Graham Charters]

Hi, I'm writing a maven plugin that needs to do coversion of maven
versions to osgi versions.  I want to depend on the
maven-bundle-plugin for this because I need the conversion scheme to
be identical.  I've done this and started using the
DefaultMaven2OsgiConverter, but for some reason, the versions I get
are different from those generated by the maven-bundle-plugin.  For
example, the converter changes 1.0.0-incubating-SNAPSHOT to
1.0.0.incubating_SNAPSHOT (as well as making it a valid OSGi version,
it converts the '-' to '_'), whereas the maven-bundle-plugin changes
this to 1.0.0.incubating-SNAPSHOT (leaves '-' alone).  Am I using the
wrong bit of code to do the conversion or driving it incorrectly?  Any
help would be greatly appreciated.

My apologies if this should be on the users list rather than dev.  It
seems to fall between the two...

Many thanks,

Graham.

UI testing frameworks

[David Savage]

Hi there,

I'm in the process of getting a 1.0.0 release of Sigil in shape and a
number of bugs have popped up that could most likely have been caught
if there were some unit tests that could drive the ui. However I've
not had much experience of UI testing frameworks, hence I'm wondering
if anyone on the list knows anything - or knows anyone who knows
anything about how this could be setup?

A quick web search led me to the following:
http://wiki.eclipse.org/Automated_Testing looks like there are some
possibilities but the better ones are commercially licensed - not sure
how this would work in apache etc?

Any thoughts welcome.

Regards,

Dave

Re: Maven bundle plugin version conversion

[Graham Charters]

This bug seems to describe my poblem:
https://jira.codehaus.org/browse/MECLIPSE-467

What I don't understand is why DefaultMaven2OsgiConverter gives
results different from the maven-bundle-plugin.

Any help in understanding this and how to resolve it would be greatly
appreciated.

Thanks, Graham.

On 4 March 2010 15:56, Graham Charters  wrote:
> Hi, I'm writing a maven plugin that needs to do coversion of maven
> versions to osgi versions.  I want to depend on the
> maven-bundle-plugin for this because I need the conversion scheme to
> be identical.  I've done this and started using the
> DefaultMaven2OsgiConverter, but for some reason, the versions I get
> are different from those generated by the maven-bundle-plugin.  For
> example, the converter changes 1.0.0-incubating-SNAPSHOT to
> 1.0.0.incubating_SNAPSHOT (as well as making it a valid OSGi version,
> it converts the '-' to '_'), whereas the maven-bundle-plugin changes
> this to 1.0.0.incubating-SNAPSHOT (leaves '-' alone).  Am I using the
> wrong bit of code to do the conversion or driving it incorrectly?  Any
> help would be greatly appreciated.
>
> My apologies if this should be on the users list rather than dev.  It
> seems to fall between the two...
>
> Many thanks,
>
> Graham.
>

[jira] Created: (FELIX-2171) The OBR page should be able to display detailed information about a bundle

[Guillaume Nodet (JIRA)]

The OBR page should be able to display detailed information about a bundle
--

 Key: FELIX-2171
 URL: https://issues.apache.org/jira/browse/FELIX-2171
 Project: Felix
  Issue Type: Improvement
  Components: Web Console
Reporter: Guillaume Nodet
Assignee: Guillaume Nodet
 Fix For: webconsole-3.0.0




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

[jira] Updated: (FELIX-2162) The bundle repository page can't scale

[Guillaume Nodet (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Nodet updated FELIX-2162:
---

Fix Version/s: webconsole-3.0.0
 Assignee: Guillaume Nodet

> The bundle repository page can't scale
> --
>
> Key: FELIX-2162
> URL: https://issues.apache.org/jira/browse/FELIX-2162
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
> Fix For: webconsole-3.0.0
>
>
> Now that OBR is fast enough to be used, the web console page design makes it 
> difficult to actually scale to real repositories.
> We should think about using some pagination mechanism and not display all the 
> available resources.
> In addition, I think we should provide some detailed informations on a bundle 
> such as the one given by the springsource repository:
>
> http://www.springsource.com/repository/app/bundle/version/detail?name=com.springsource.org.apache.activemq&version=5.3.0

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

[jira] Commented: (FELIX-2121) ProSyst donation of UPnP plugin for the web console

[Felix Meschberger (JIRA)]

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

Felix Meschberger commented on FELIX-2121:
--

Thanks for resubmitting.

This looks good to me. Two small issues can be fixed on import: I think we can 
move the note about the original origin to twards the top of the NOTICE file 
and we may add the ASL header to the bundle*.properties files.

The Licensor in the Software Grant is your Company, i.e. ProSyst Labs. Your CEO 
(or someone with legal signature competence) will have to sign the grant at the 
bottom.

> ProSyst donation of UPnP plugin for the web console
> ---
>
> Key: FELIX-2121
> URL: https://issues.apache.org/jira/browse/FELIX-2121
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Reporter: Valentin Valchev
>Assignee: Felix Meschberger
> Attachments: upnp.zip
>
>
> This plugin is similar to the UPnP Test application but developed as a plugin 
> for the Web Console.
> It is developed as standalone plugin - e.g. not build-into the Apache Web 
> Console but is separate bundle.
> This allows the plugin to dynamically register/unregister itself. This way 
> the plugin is available only when UPnP Service is active.
> Unfortunately I'm not quite aware with maven since most of our projects use 
> ANT. Otherwise I was going to create the full maven structure required to 
> build it.

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

[VOTE] Accept UPNP Web Console Plugin Contribution (FELIX-2121)

[Felix Meschberger]

Hi all,

I would like to start a vote here to accept the contribution of a UPNP
plugin for the Web Console. The code is attached as upnp.zip [1] to
issue FELIX-2121 [2].

The checksum of this file is:
80390b4b3bed18b16e54ab5492f4b96d  upnp.zip

I would like to thank Valentin Valchev and ProSyst for this contribution.

So please cast your votes. The vote will be open for 72h. Everyone is
invited to vote (though only votes by members of Felix PMC count as
binding).

I am in the process of preparing the IP Clearance form at [3]. The
missing items are this vote and the submission and registration of the
Software Grant from ProSyst.

Regards
Felix

[1] https://issues.apache.org/jira/secure/attachment/12437892/upnp.zip
[2] https://issues.apache.org/jira/browse/FELIX-2121
[3] http://incubator.apache.org/ip-clearance/felix-upnp-console-plugin.html

Re: [VOTE] Accept UPNP Web Console Plugin Contribution (FELIX-2121)

[Felix Meschberger]

+1

Regards
Felix

On 04.03.2010 23:32, Felix Meschberger wrote:
> Hi all,
> 
> I would like to start a vote here to accept the contribution of a UPNP
> plugin for the Web Console. The code is attached as upnp.zip [1] to
> issue FELIX-2121 [2].
> 
> The checksum of this file is:
> 80390b4b3bed18b16e54ab5492f4b96d  upnp.zip
> 
> I would like to thank Valentin Valchev and ProSyst for this contribution.
> 
> So please cast your votes. The vote will be open for 72h. Everyone is
> invited to vote (though only votes by members of Felix PMC count as
> binding).
> 
> I am in the process of preparing the IP Clearance form at [3]. The
> missing items are this vote and the submission and registration of the
> Software Grant from ProSyst.
> 
> Regards
> Felix
> 
> [1] https://issues.apache.org/jira/secure/attachment/12437892/upnp.zip
> [2] https://issues.apache.org/jira/browse/FELIX-2121
> [3] http://incubator.apache.org/ip-clearance/felix-upnp-console-plugin.html

Re: [VOTE] Accept UPNP Web Console Plugin Contribution (FELIX-2121)

[Guillaume Nodet]

+1

On Thu, Mar 4, 2010 at 23:32, Felix Meschberger  wrote:
> Hi all,
>
> I would like to start a vote here to accept the contribution of a UPNP
> plugin for the Web Console. The code is attached as upnp.zip [1] to
> issue FELIX-2121 [2].
>
> The checksum of this file is:
>    80390b4b3bed18b16e54ab5492f4b96d  upnp.zip
>
> I would like to thank Valentin Valchev and ProSyst for this contribution.
>
> So please cast your votes. The vote will be open for 72h. Everyone is
> invited to vote (though only votes by members of Felix PMC count as
> binding).
>
> I am in the process of preparing the IP Clearance form at [3]. The
> missing items are this vote and the submission and registration of the
> Software Grant from ProSyst.
>
> Regards
> Felix
>
> [1] https://issues.apache.org/jira/secure/attachment/12437892/upnp.zip
> [2] https://issues.apache.org/jira/browse/FELIX-2121
> [3] http://incubator.apache.org/ip-clearance/felix-upnp-console-plugin.html
>



-- 
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Open Source SOA
http://fusesource.com

[jira] Resolved: (FELIX-2171) The OBR page should be able to display detailed information about a bundle

[Guillaume Nodet (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-2171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Nodet resolved FELIX-2171.


Resolution: Fixed

URL: http://svn.apache.org/viewvc?rev=919175&view=rev
Log:
FELIX-2162, FELIX-2171: rewrite the OBR webconsole page to be more scalable and 
display detailed informations about a given bundle

Added:
   felix/trunk/webconsole/src/main/resources/res/ui/jquery.uuid.js
   felix/trunk/webconsole/src/main/resources/res/ui/obr.css
Modified:
   felix/trunk/webconsole/pom.xml
   
felix/trunk/webconsole/src/main/java/org/apache/felix/webconsole/internal/core/BaseUpdateInstallHelper.java
   
felix/trunk/webconsole/src/main/java/org/apache/felix/webconsole/internal/core/BundlesServlet.java
   
felix/trunk/webconsole/src/main/java/org/apache/felix/webconsole/internal/core/UpdateHelper.java
   
felix/trunk/webconsole/src/main/java/org/apache/felix/webconsole/internal/obr/BundleRepositoryRender.java
   
felix/trunk/webconsole/src/main/java/org/apache/felix/webconsole/internal/obr/DeployerThread.java
   felix/trunk/webconsole/src/main/resources/res/ui/obr.js
   felix/trunk/webconsole/src/main/resources/templates/obr.html


> The OBR page should be able to display detailed information about a bundle
> --
>
> Key: FELIX-2171
> URL: https://issues.apache.org/jira/browse/FELIX-2171
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
> Fix For: webconsole-3.0.0
>
>


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

[jira] Resolved: (FELIX-2162) The bundle repository page can't scale

[Guillaume Nodet (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Nodet resolved FELIX-2162.


Resolution: Fixed

URL: http://svn.apache.org/viewvc?rev=919175&view=rev
Log:
FELIX-2162, FELIX-2171: rewrite the OBR webconsole page to be more scalable and 
display detailed informations about a given bundle

Added:
   felix/trunk/webconsole/src/main/resources/res/ui/jquery.uuid.js
   felix/trunk/webconsole/src/main/resources/res/ui/obr.css
Modified:
   felix/trunk/webconsole/pom.xml
   
felix/trunk/webconsole/src/main/java/org/apache/felix/webconsole/internal/core/BaseUpdateInstallHelper.java
   
felix/trunk/webconsole/src/main/java/org/apache/felix/webconsole/internal/core/BundlesServlet.java
   
felix/trunk/webconsole/src/main/java/org/apache/felix/webconsole/internal/core/UpdateHelper.java
   
felix/trunk/webconsole/src/main/java/org/apache/felix/webconsole/internal/obr/BundleRepositoryRender.java
   
felix/trunk/webconsole/src/main/java/org/apache/felix/webconsole/internal/obr/DeployerThread.java
   felix/trunk/webconsole/src/main/resources/res/ui/obr.js
   felix/trunk/webconsole/src/main/resources/templates/obr.html


> The bundle repository page can't scale
> --
>
> Key: FELIX-2162
> URL: https://issues.apache.org/jira/browse/FELIX-2162
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
> Fix For: webconsole-3.0.0
>
>
> Now that OBR is fast enough to be used, the web console page design makes it 
> difficult to actually scale to real repositories.
> We should think about using some pagination mechanism and not display all the 
> available resources.
> In addition, I think we should provide some detailed informations on a bundle 
> such as the one given by the springsource repository:
>
> http://www.springsource.com/repository/app/bundle/version/detail?name=com.springsource.org.apache.activemq&version=5.3.0

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

Re: [DISCUSS] Review / release OBR 2.0.0

[Guillaume Nodet]

On Wed, Mar 3, 2010 at 19:14, Arjun Panday
 wrote:
> Hi Guillaume,
>
> A few comments about the new OBR:
>
>   * great job on the speed improvement!
>   * thanks for the new Reason API; i'd been hoping for something like this
>   * I've tried the new Resolver flags, but none of them seem to behave
>     like what i do with:
>
> final Repository[] repolist = _repoAdmin.listRepositories();
> Resolver resolver = _repoAdmin.resolver((Repository[]) (new ArrayList() {{
>      add(_repoAdmin.getSystemRepository());
>      addAll(Arrays.asList(repolist));
> }}).toArray(new Repository[repolist.length + 1]));
>
>   * when i use NO_LOCAL_RESOURCES or DO_NOT_PREFER_LOCAL, my local
>     resources are still stripped from the OBR resolution; which is
>     precisely what i'm trying to avoid.. or maybe i misunderstood
>     these flags and a new flag could be introduced to reflect the use
>     case above.

I've fixed that.

>   * more importantly, the output of the new implementation is
>     different from the previous one; namely, in my use case, it pulls
>     one additional resource that i do not need (nor want).. I haven't
>     yet managed to pinpoint the exact problem but here's what happens:
>         o i'm trying to resolve one single resource wich has a list of
>           "Require-Bundle" dependencies
>         o one of these required bundles provides packages required by
>           the other ones
>         o my OBR happens to contain another resource which also
>           exports the same packages (same version!)
>         o the new implementation now pulls that other resource while
>           the old implementation did not, so i guess the resolution
>           order has changed and it impacts the result

The algorithm has not changed.  After having a look at the repository
you sent me, I do understand the problem but I don't see why the
resolution output has changed or what we can do about it.
The problem is that the first resource has lots of requirements on
bundles.  So the resolver tries to resolve them one by one.  While
resolving the first ones, it needs an import on javax.servlet, so the
best resource for that one is selected.  Later, the servlet api is
resolved, so we end up with two bundles exporting the javax.servlet
api.

I'm not really sure how to solve the problem.  My guess is that we'd
need some backtracking for that, but the current algorithm does not
uses backtracking because the current heuristic can't lead to
conflicts.   Resolving all the bundles requirements first can't really
be done either, because we may have multiple candidate bundles for the
same requirement, so we need to fully test one before going to the
second.

Richard may have more thoughts on that, as he is the resolution
expert.  I don't even know how the current OSGi resolver deals with
that.

> /arjun
>
>
>
> Le 03/01/2010 11:41 AM, Guillaume Nodet a écrit :
>>
>> I've done a fait amount of changes to OBR those last weeks and I think
>> it could deserve a release asap.
>> However, i'd like to have a few people reviewing the new API so that
>> we all agree on it before starting the release process.
>> For those who haven't followed the stream of JIRA issues, here is a
>> short summary:
>>    * a new API named org.apache.felix.bundlerepository is available,
>> it's mostly based on the org.osgi.service.obr one
>>       but include a lot of small improvements
>>    * the org.osgi.service.obr isn't shipped anymore, but the if
>> present, a wrapper service will be exposed to offer compatibility
>>       with previous versions of OBR
>>    * the speed has been improved by a factor x10 or more (both parsing
>> and resolution)
>>    * ability to not resolve / install optional resources
>>    * support for requirements as an input for the resolution
>>    * support global constraints and capabilities
>>
>> Feedback welcomed.   If there aren't any, I plan to start a release
>> early next week.
>>
>>
>
>



-- 
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Open Source SOA
http://fusesource.com

Re: [VOTE] Accept UPNP Web Console Plugin Contribution (FELIX-2121)

[Richard S. Hall]

+1

-> richard

On 3/4/10 17:32, Felix Meschberger wrote:

Hi all,

I would like to start a vote here to accept the contribution of a UPNP
plugin for the Web Console. The code is attached as upnp.zip [1] to
issue FELIX-2121 [2].

The checksum of this file is:
 80390b4b3bed18b16e54ab5492f4b96d  upnp.zip

I would like to thank Valentin Valchev and ProSyst for this contribution.

So please cast your votes. The vote will be open for 72h. Everyone is
invited to vote (though only votes by members of Felix PMC count as
binding).

I am in the process of preparing the IP Clearance form at [3]. The
missing items are this vote and the submission and registration of the
Software Grant from ProSyst.

Regards
Felix

[1] https://issues.apache.org/jira/secure/attachment/12437892/upnp.zip
[2] https://issues.apache.org/jira/browse/FELIX-2121
[3] http://incubator.apache.org/ip-clearance/felix-upnp-console-plugin.html
   

Is there any way to get a more up to date maven-bundle-plugin?

[David Jencks]

It looks like Peter has implemented some nice new features in bnd  
in particular the fancier version policies described here


http://www.aqute.biz/Code/XBnd

However I don't see a release at maven central including this code.   
Is there any process for moving towards a more up to date maven plugin?


thanks
david jencks

Re: Is there any way to get a more up to date maven-bundle-plugin?

[Chris Custine]

Hi David,
I haven't tried this lately, but you could try bootstrapping in a specific
version of bnd as Stuart points out in this Jira issue:
https://issues.apache.org/jira/browse/FELIX-2003 (I can't find any other
docs about this).

Assuming there are no
incompatible changes in bnd you could then try the bnd instructions like
<_versionpolicy-impl>[${version;==;$...@}},${version;=+;$...@}})

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, Mar 4, 2010 at 7:58 PM, David Jencks  wrote:

> It looks like Peter has implemented some nice new features in bnd in
> particular the fancier version policies described here
>
> http://www.aqute.biz/Code/XBnd
>
> However I don't see a release at maven central including this code.  Is
> there any process for moving towards a more up to date maven plugin?
>
> thanks
> david jencks
>
>

Re: [VOTE] Accept UPNP Web Console Plugin Contribution (FELIX-2121)

[clement escoffier]

+1

Clement

2010/3/5 Richard S. Hall 

> +1
>
> -> richard
>
>
> On 3/4/10 17:32, Felix Meschberger wrote:
>
>> Hi all,
>>
>> I would like to start a vote here to accept the contribution of a UPNP
>> plugin for the Web Console. The code is attached as upnp.zip [1] to
>> issue FELIX-2121 [2].
>>
>> The checksum of this file is:
>> 80390b4b3bed18b16e54ab5492f4b96d  upnp.zip
>>
>> I would like to thank Valentin Valchev and ProSyst for this contribution.
>>
>> So please cast your votes. The vote will be open for 72h. Everyone is
>> invited to vote (though only votes by members of Felix PMC count as
>> binding).
>>
>> I am in the process of preparing the IP Clearance form at [3]. The
>> missing items are this vote and the submission and registration of the
>> Software Grant from ProSyst.
>>
>> Regards
>> Felix
>>
>> [1] https://issues.apache.org/jira/secure/attachment/12437892/upnp.zip
>> [2] https://issues.apache.org/jira/browse/FELIX-2121
>> [3]
>> http://incubator.apache.org/ip-clearance/felix-upnp-console-plugin.html
>>
>>
>