[jira] Updated: (FELIX-1937) History command function does not work with a karaf instance created after executing command admin:create xxx
[ https://issues.apache.org/jira/browse/FELIX-1937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated FELIX-1937: --- Component/s: Karaf History command function does not work with a karaf instance created after executing command admin:create xxx - Key: FELIX-1937 URL: https://issues.apache.org/jira/browse/FELIX-1937 Project: Felix Issue Type: Bug Reporter: Charles Moulliard The history function does not work with a karaf instance created after executing command admin:create xxx Creation scenario 1) execute : admin:create slave 2) execute : admin:start slave 3) execute : admin:connect slave Now try to use on windows the upper arrow key to have access to the history of the commands and here is what is deplayed instead of the command executed before ka...@slave -32 ka...@slave H-32 ka...@slave H-32 ka...@slave H -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2454) [gogo] the runtime coercion mechanism should leverage blueprint
[gogo] the runtime coercion mechanism should leverage blueprint --- Key: FELIX-2454 URL: https://issues.apache.org/jira/browse/FELIX-2454 Project: Felix Issue Type: Improvement Components: Gogo Runtime Reporter: Derek Baum The gogo runtime coercion mechanism, as implemented in Reflective.java, should be re-factored to benefit from the coercion used in blueprint. Note: we do NOT want a dependency on blueprint in the gogo runtime, but want to take advantage of the work already done, as coercion quickly becomes quite complex. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2453) [gogo] the new command should leverage the runtime coercion mechanism
[gogo] the new command should leverage the runtime coercion mechanism --- Key: FELIX-2453 URL: https://issues.apache.org/jira/browse/FELIX-2453 Project: Felix Issue Type: Improvement Components: Gogo Runtime, Gogo Shell Reporter: Derek Baum The gogo:new command currently performs only rudimentary argument type coercion. It should be moved into the runtime as osgi:new to leverage the runtime coercion mechanism. Alternatively, the runtime coercion mechanism should be exposed as a service to allow an external gogo:new command to use it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2455) [gogo API] the Function interface used for Closures, takes an unused session parameter
[gogo API] the Function interface used for Closures, takes an unused session
parameter
--
Key: FELIX-2455
URL: https://issues.apache.org/jira/browse/FELIX-2455
Project: Felix
Issue Type: Improvement
Components: Gogo Runtime
Reporter: Derek Baum
The org.osgi.service.command.Function interface (used for Closures), takes a
session argument, which is not used in the implementation:
The Closure constructor takes a session parameter. This is used by the
execute() method, which ignores its own session parameter.
Unless there is another reason for execute() taking a session parameter, I
suggest we change the API to remove this parameter
(deprecating the existing method to keep backward compatibility).
public interface Function {
Object execute(CommandSession session, ListObject arguments) throws
Exception;
}
Closure.java:113:
// implements Function interface
// XXX: session arg x not used?
public Object execute(CommandSession x, ListObject values) throws
Exception
{
try
{
location.remove();
session.variables.remove(LOCATION);
return execute(values);
}
catch (Exception e)
{
throw setLocation(e);
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2455) [gogo API] the Function interface used for Closures, takes an unused session parameter
[
https://issues.apache.org/jira/browse/FELIX-2455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12883587#action_12883587
]
Guillaume Nodet commented on FELIX-2455:
How do you plan to access session variables (both read and write modes) if you
don't pass the session as an argument on the function execution ?
[gogo API] the Function interface used for Closures, takes an unused session
parameter
--
Key: FELIX-2455
URL: https://issues.apache.org/jira/browse/FELIX-2455
Project: Felix
Issue Type: Improvement
Components: Gogo Runtime
Reporter: Derek Baum
The org.osgi.service.command.Function interface (used for Closures), takes a
session argument, which is not used in the implementation:
The Closure constructor takes a session parameter. This is used by the
execute() method, which ignores its own session parameter.
Unless there is another reason for execute() taking a session parameter, I
suggest we change the API to remove this parameter
(deprecating the existing method to keep backward compatibility).
public interface Function {
Object execute(CommandSession session, ListObject arguments) throws
Exception;
}
Closure.java:113:
// implements Function interface
// XXX: session arg x not used?
public Object execute(CommandSession x, ListObject values) throws
Exception
{
try
{
location.remove();
session.variables.remove(LOCATION);
return execute(values);
}
catch (Exception e)
{
throw setLocation(e);
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2455) [gogo API] the Function interface used for Closures, takes an unused session parameter
[
https://issues.apache.org/jira/browse/FELIX-2455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12883589#action_12883589
]
Guillaume Nodet commented on FELIX-2455:
I guess the problem comes from the fact you consider that Closure is the only
implementation of Function, which is not the case, because there are users that
actually create commands that implement Function.
So either we still support this way of creating functions, or we'd have to
remove this interface all together.
[gogo API] the Function interface used for Closures, takes an unused session
parameter
--
Key: FELIX-2455
URL: https://issues.apache.org/jira/browse/FELIX-2455
Project: Felix
Issue Type: Improvement
Components: Gogo Runtime
Reporter: Derek Baum
The org.osgi.service.command.Function interface (used for Closures), takes a
session argument, which is not used in the implementation:
The Closure constructor takes a session parameter. This is used by the
execute() method, which ignores its own session parameter.
Unless there is another reason for execute() taking a session parameter, I
suggest we change the API to remove this parameter
(deprecating the existing method to keep backward compatibility).
public interface Function {
Object execute(CommandSession session, ListObject arguments) throws
Exception;
}
Closure.java:113:
// implements Function interface
// XXX: session arg x not used?
public Object execute(CommandSession x, ListObject values) throws
Exception
{
try
{
location.remove();
session.variables.remove(LOCATION);
return execute(values);
}
catch (Exception e)
{
throw setLocation(e);
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2437) Deadlock on refrsh Import and refresh
[ https://issues.apache.org/jira/browse/FELIX-2437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12883590#action_12883590 ] Richard S. Hall commented on FELIX-2437: Just a note to myself: I think we need to make sure that any invocation paths that touch the install locks and the global lock always grab the global lock first to avoid such locking cycles. Deadlock on refrsh Import and refresh - Key: FELIX-2437 URL: https://issues.apache.org/jira/browse/FELIX-2437 Project: Felix Issue Type: Bug Components: Configuration Admin Affects Versions: framework-2.0.4, webconsole-3.0.0 Environment: Felix framework 2.0.4 Felix webconsole 3.0.0 Sling Reporter: christian Assignee: Richard S. Hall Priority: Minor Fix For: framework-3.2.0 I encountred a Deadlock using Webconsole (s. stacktrace below) Stepps to reproduce: 1) in webconsole navigate to bundles 2) select and open the detail view of a bundle that has a lot dependencies (I used sling and as bundle the sling api bundle) 3) click refresh package import 4) click refresh It the request from 4) is processed while he one from 3) is still running, you get a deadlock. Found one Java-level deadlock: = 0:0:0:0:0:0:0:1 [1277221470284] GET /system/console/bundles/105 HTTP/1.1: waiting to lock monitor 0x0039de94 (object 0x06448fd0, a org.apache.felix.framework.BundleImpl), which is held by FelixPackageAdmin FelixPackageAdmin: waiting to lock monitor 0x0039deb4 (object 0x06235658, a [Ljava.lang.Object;), which is held by 0:0:0:0:0:0:0:1 [1277221470284] GET /system/console/bundles/105 HTTP/1.1 Java stack information for the threads listed above: === 0:0:0:0:0:0:0:1 [1277221470284] GET /system/console/bundles/105 HTTP/1.1: at org.apache.felix.framework.BundleImpl.getModules(BundleImpl.java:1001) - waiting to lock 0x06448fd0 (a org.apache.felix.framework.BundleImpl) at org.apache.felix.framework.Felix.getExportedPackages(Felix.java:3114) at org.apache.felix.framework.Felix.getExportedPackages(Felix.java:3093) - locked 0x06235658 (a [Ljava.lang.Object;) at org.apache.felix.framework.PackageAdminImpl.getExportedPackages(PackageAdminImpl.java:184) at org.apache.felix.webconsole.internal.core.BundlesServlet.listImportExport(BundlesServlet.java:834) at org.apache.felix.webconsole.internal.core.BundlesServlet.bundleDetails(BundlesServlet.java:752) at org.apache.felix.webconsole.internal.core.BundlesServlet.bundleInfo(BundlesServlet.java:675) at org.apache.felix.webconsole.internal.core.BundlesServlet.writeJSON(BundlesServlet.java:570) at org.apache.felix.webconsole.internal.core.BundlesServlet.writeJSON(BundlesServlet.java:511) at org.apache.felix.webconsole.internal.core.BundlesServlet.renderContent(BundlesServlet.java:485) at org.apache.felix.webconsole.AbstractWebConsolePlugin.doGet(AbstractWebConsolePlugin.java:148) at org.apache.felix.webconsole.internal.core.BundlesServlet.doGet(BundlesServlet.java:274) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:367) at org.apache.felix.http.base.internal.handler.ServletHandler.doHandle(ServletHandler.java:93) at org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:79) at org.apache.felix.http.base.internal.dispatch.ServletPipeline.handle(ServletPipeline.java:42) at org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:49) at org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:33) at org.apache.felix.http.base.internal.dispatch.FilterPipeline.dispatch(FilterPipeline.java:48) at org.apache.felix.http.base.internal.dispatch.Dispatcher.dispatch(Dispatcher.java:39) at org.apache.felix.http.base.internal.DispatcherServlet.service(DispatcherServlet.java:67) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.felix.http.proxy.ProxyServlet.service(ProxyServlet.java:60) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.sling.launchpad.base.webapp.SlingServletDelegate.service(SlingServletDelegate.java:275) at org.apache.sling.launchpad.webapp.SlingServlet.service(SlingServlet.java:130) at
[jira] Created: (FELIX-2456) Framework no longer fires UNRESOLVED event when a bundle is explicitly refreshed
Framework no longer fires UNRESOLVED event when a bundle is explicitly refreshed Key: FELIX-2456 URL: https://issues.apache.org/jira/browse/FELIX-2456 Project: Felix Issue Type: Bug Components: Framework Affects Versions: framework-3.0.0, framework-2.0.5, framework-2.0.4, framework-2.0.3, framework-2.0.2, framework-2.0.1, framework-2.0.0, framework-3.0.1 Reporter: Richard S. Hall Priority: Minor Fix For: framework-3.2.0 Between framework 1.8.x and 2.0.0, we removed the UNRESOLVED event when a bundle is explicitly refreshed. We need to put it back. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2456) Framework no longer fires UNRESOLVED event when a bundle is explicitly refreshed
[ https://issues.apache.org/jira/browse/FELIX-2456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall updated FELIX-2456: --- Description: Between framework 1.8.x and 2.0.0, we removed the UNRESOLVED event when a bundle is explicitly refreshed. We need to put it back. It appears that when the code was restructured to have bundle uninstallation fire an UNRESOLVED event, it missed the case where a bundle was refreshed directly. Due to the uninstallation requirement, it is not possible to simply put the event firing back in place in refreshBundle() since it would result in multiple UNRESOLVED events being fired. We need to walk our way back from the refreshBundle() method to see who is using it and to also make sure setBundleStateAndNotify() is correctly called in all cases. (was: Between framework 1.8.x and 2.0.0, we removed the UNRESOLVED event when a bundle is explicitly refreshed. We need to put it back.) Framework no longer fires UNRESOLVED event when a bundle is explicitly refreshed Key: FELIX-2456 URL: https://issues.apache.org/jira/browse/FELIX-2456 Project: Felix Issue Type: Bug Components: Framework Affects Versions: framework-2.0.0, framework-2.0.1, framework-2.0.2, framework-2.0.3, framework-2.0.4, framework-2.0.5, framework-3.0.0, framework-3.0.1 Reporter: Richard S. Hall Priority: Minor Fix For: framework-3.2.0 Between framework 1.8.x and 2.0.0, we removed the UNRESOLVED event when a bundle is explicitly refreshed. We need to put it back. It appears that when the code was restructured to have bundle uninstallation fire an UNRESOLVED event, it missed the case where a bundle was refreshed directly. Due to the uninstallation requirement, it is not possible to simply put the event firing back in place in refreshBundle() since it would result in multiple UNRESOLVED events being fired. We need to walk our way back from the refreshBundle() method to see who is using it and to also make sure setBundleStateAndNotify() is correctly called in all 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-2455) [gogo API] the Function interface used for Closures, takes an unused session parameter
[
https://issues.apache.org/jira/browse/FELIX-2455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12883600#action_12883600
]
Derek Baum commented on FELIX-2455:
---
I raised this issue as I noticed that the Closure implementation of Function
doesn't use its session parameter.
I've since found that CommandProxy also implements Function and it does use the
session parameter, so I'll mark this issue as 'won't fix'.
[gogo API] the Function interface used for Closures, takes an unused session
parameter
--
Key: FELIX-2455
URL: https://issues.apache.org/jira/browse/FELIX-2455
Project: Felix
Issue Type: Improvement
Components: Gogo Runtime
Reporter: Derek Baum
The org.osgi.service.command.Function interface (used for Closures), takes a
session argument, which is not used in the implementation:
The Closure constructor takes a session parameter. This is used by the
execute() method, which ignores its own session parameter.
Unless there is another reason for execute() taking a session parameter, I
suggest we change the API to remove this parameter
(deprecating the existing method to keep backward compatibility).
public interface Function {
Object execute(CommandSession session, ListObject arguments) throws
Exception;
}
Closure.java:113:
// implements Function interface
// XXX: session arg x not used?
public Object execute(CommandSession x, ListObject values) throws
Exception
{
try
{
location.remove();
session.variables.remove(LOCATION);
return execute(values);
}
catch (Exception e)
{
throw setLocation(e);
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-2455) [gogo API] the Function interface used for Closures, takes an unused session parameter
[
https://issues.apache.org/jira/browse/FELIX-2455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Derek Baum resolved FELIX-2455.
---
Resolution: Not A Problem
not a problem - other implementations of Function may use the session parameter.
[gogo API] the Function interface used for Closures, takes an unused session
parameter
--
Key: FELIX-2455
URL: https://issues.apache.org/jira/browse/FELIX-2455
Project: Felix
Issue Type: Improvement
Components: Gogo Runtime
Reporter: Derek Baum
The org.osgi.service.command.Function interface (used for Closures), takes a
session argument, which is not used in the implementation:
The Closure constructor takes a session parameter. This is used by the
execute() method, which ignores its own session parameter.
Unless there is another reason for execute() taking a session parameter, I
suggest we change the API to remove this parameter
(deprecating the existing method to keep backward compatibility).
public interface Function {
Object execute(CommandSession session, ListObject arguments) throws
Exception;
}
Closure.java:113:
// implements Function interface
// XXX: session arg x not used?
public Object execute(CommandSession x, ListObject values) throws
Exception
{
try
{
location.remove();
session.variables.remove(LOCATION);
return execute(values);
}
catch (Exception e)
{
throw setLocation(e);
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2457) Bundle repository does not respect NO_SYSTEM_BUNDLE or NO_LOCAL_RESOURCES flags
[ https://issues.apache.org/jira/browse/FELIX-2457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated FELIX-2457: --- Attachment: FELIX-2457.patch Patch for this problem. The problem is that the getResources() call to obtain a list of local resources is made before the m_resolutionFlags variable is set to the specified flags. Bundle repository does not respect NO_SYSTEM_BUNDLE or NO_LOCAL_RESOURCES flags --- Key: FELIX-2457 URL: https://issues.apache.org/jira/browse/FELIX-2457 Project: Felix Issue Type: Bug Components: Bundle Repository (OBR) Affects Versions: bundlerepository-1.6.4 Reporter: Jarek Gawor Attachments: FELIX-2457.patch When passing a Resolver.NO_SYSTEM_BUNDLE or NO_LOCAL_RESOURCES flags to resolver, the system bundle or local resources are still considered during resolution. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2457) Bundle repository does not respect NO_SYSTEM_BUNDLE or NO_LOCAL_RESOURCES flags
Bundle repository does not respect NO_SYSTEM_BUNDLE or NO_LOCAL_RESOURCES flags --- Key: FELIX-2457 URL: https://issues.apache.org/jira/browse/FELIX-2457 Project: Felix Issue Type: Bug Components: Bundle Repository (OBR) Affects Versions: bundlerepository-1.6.4 Reporter: Jarek Gawor When passing a Resolver.NO_SYSTEM_BUNDLE or NO_LOCAL_RESOURCES flags to resolver, the system bundle or local resources are still considered during resolution. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (FELIX-1473) [gogo] The syntax does not provide a way to call methods on a string
[
https://issues.apache.org/jira/browse/FELIX-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Derek Baum reopened FELIX-1473:
---
a better solution to this issue has been proposed:
currently any command object that implements CharSequence is treated as a
command, so it is impossible to call String methods. For example:
if {$HOSTNAME endsWith .com} {...} // this fails with 'command not found:
my.host.name'
The current solution uses the period to force method invocation, for example:
if {$HOSTNAME . endsWith .com} {...}
The new proposal is to only treat 'bare' words as commands and to treat
everything else as method calls. For example:
if {$HOSTNAME endsWith .com} {...} // $HOSTNAME is NOT a bareword as it is a
variable expansion, so this works as expected
g! cmd = echo
g! $cmd hello // fails with 'can't coerce hello() to any of []'
The above fails, as there is no method hello on the String object 'echo';
To make the indirect command expansion above work, we need to introduce an
osgi:eval command:
g! eval $cmd hello
hello
[gogo] The syntax does not provide a way to call methods on a string
Key: FELIX-1473
URL: https://issues.apache.org/jira/browse/FELIX-1473
Project: Felix
Issue Type: Bug
Components: Gogo Runtime
Reporter: Guillaume Nodet
Assignee: Derek Baum
Fix For: gogo-0.6.0
Attachments: FELIX-1473.patch
When the first argument is a string, gogo considers it to be a command.
The problem is that it leads to unpredictible behavior when using variables
$a length
Depending on the type of $a, it will either try to call a command named by
the value of $a, or call the length method on the $a object.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2458) osgi:addcommand/osgi:removecommand should apply to current session vs global to the osgi framework
osgi:addcommand/osgi:removecommand should apply to current session vs global to the osgi framework -- Key: FELIX-2458 URL: https://issues.apache.org/jira/browse/FELIX-2458 Project: Felix Issue Type: Improvement Components: Gogo Runtime Reporter: David Savage Priority: Minor The addcommand/removecommand commands currently apply to the global osgi console vs the current session. This seems confusing as if different users are logged in via different sessions, i.e. multiple ssh connections then one users request to add a command will be visible in the other users session - this could potentially even be viewed as a security hazard... Suggest a two tier map approach where the session keeps a list of added commands and delegates to CommandProcessorImpl if no matching command is found -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
