[jira] Created: (FELIX-543) add switch to prevent classifier being appended to Bundle-Version
add switch to prevent classifier being appended to Bundle-Version - Key: FELIX-543 URL: https://issues.apache.org/jira/browse/FELIX-543 Project: Felix Issue Type: New Feature Components: Maven Bundle Plugin Reporter: Derek Baum Priority: Minor I have a use-case for using classifier to create multiple bundles with different symbolic names but the same Bundle-Version. This is not currently possible, as the maven-bundle-plugin automatically appends the classifier to the Bundle-Version. Could some switch be added, to disable the appending of classifier to Bundle-Version? Thanks, Derek stuart.mcculloch wrote: the use-case for adding this feature was for people who wanted to produce JDK5 and JDK1.4 versions of the _same_ bundle, so because the symbolic name would be the same, the classifier must then be added to the version to distinguish them. it is the intended behaviour for the above use-case, but we could add a switch to turn it off - it's difficult to detect whether the classifier should be added to the version automatically, because each bundling process is run in isolation there's also no way to distinguish where the bundle version came from in Maven (ie. general config or specific to the classifier) once it reaches the bundleplugin, so a new switch is the only safe way to detect the different use-case... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-543) add switch to prevent classifier being appended to Bundle-Version
[ https://issues.apache.org/jira/browse/FELIX-543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum closed FELIX-543. Thanks, this resolution works fine. Derek > add switch to prevent classifier being appended to Bundle-Version > - > > Key: FELIX-543 > URL: https://issues.apache.org/jira/browse/FELIX-543 > Project: Felix > Issue Type: New Feature > Components: Maven Bundle Plugin >Affects Versions: maven-bundle-plugin-1.4.0 >Reporter: Derek Baum >Assignee: Stuart McCulloch >Priority: Minor > Fix For: maven-bundle-plugin-1.4.1 > > > I have a use-case for using classifier to create multiple bundles with > different symbolic names but the same Bundle-Version. > This is not currently possible, as the maven-bundle-plugin automatically > appends the classifier to the Bundle-Version. > Could some switch be added, to disable the appending of classifier to > Bundle-Version? > Thanks, > Derek > stuart.mcculloch wrote: > the use-case for adding this feature was for people who > wanted to produce JDK5 and JDK1.4 versions of the _same_ bundle, so > because the symbolic name would be the same, the classifier must then > be added to the version to distinguish them. > it is the intended behaviour for the above use-case, but we could add a switch > to turn it off - it's difficult to detect whether the classifier should be > added to the > version automatically, because each bundling process is run in isolation > there's also no way to distinguish where the bundle version came from in Maven > (ie. general config or specific to the classifier) once it reaches the > bundleplugin, > so a new switch is the only safe way to detect the different use-case... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2290) [sigil] add [revision] to bundletask destpattern
[sigil] add [revision] to bundletask destpattern Key: FELIX-2290 URL: https://issues.apache.org/jira/browse/FELIX-2290 Project: Felix Issue Type: Improvement Components: Sigil Reporter: Derek Baum Assignee: Derek Baum Priority: Minor modify ant sigil.bundle task to also support [revision] in the destpattern and add an optional revision output property:
[jira] Resolved: (FELIX-2290) [sigil] add [revision] to bundletask destpattern
[ https://issues.apache.org/jira/browse/FELIX-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum resolved FELIX-2290. --- Resolution: Fixed sigil. bundle now supports [revision] in destpattern > [sigil] add [revision] to bundletask destpattern > > > Key: FELIX-2290 > URL: https://issues.apache.org/jira/browse/FELIX-2290 > Project: Felix > Issue Type: Improvement > Components: Sigil >Reporter: Derek Baum >Assignee: Derek Baum >Priority: Minor > > modify ant sigil.bundle task to also support [revision] in the destpattern > and add an optional revision output property: > classpathref="sigil.path.id" revision="sigil-revision" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (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 reassigned FELIX-1473: - Assignee: Derek Baum > [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 >Reporter: Guillaume Nodet >Assignee: Derek Baum > Fix For: gogo-0.4.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] Assigned: (FELIX-1493) [gogo] automatic expansion of $args in Closure stops direct access to $args list
[
https://issues.apache.org/jira/browse/FELIX-1493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Derek Baum reassigned FELIX-1493:
-
Assignee: Derek Baum
> [gogo] automatic expansion of $args in Closure stops direct access to $args
> list
>
>
> Key: FELIX-1493
> URL: https://issues.apache.org/jira/browse/FELIX-1493
> Project: Felix
> Issue Type: Bug
> Components: Gogo
>Reporter: Derek Baum
>Assignee: Derek Baum
>
> individual arguments to Closures can be accessed as $0, $1, $2
> all arguments can be accessed as the List $args.
> > x = { echo hello $args }
> > x a b
> used to produce:
> hello [a b]
> because the $args List was passed directly as a single argument to echo.
> This is not desirable in most cases, so the parser was changed to expand
> $args in Closures by expanding the $args List,
> thus producing:
> hello a b
> Unfortunately, this also broke the ability for a closure to access the $args
> list directly:
> % loop = { each $args { echo arg is $it }}
> % loop a b
> IllegalArgumentException: Cannot coerce each[1, 2, 3,
> org.apache.felix.gogo.runtime.shell.clos...@b1deea] to any of
> [(CommandSession, Collection, Function)]
> A simple fix would be to introduce an alternative Closure variable name e.g.
> argv that is NOT expanded, but remains as a list:
> % loop = { each $argv { echo arg is $it }}
> % loop a b
> arg is a
> arg is b
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (FELIX-1474) [gogo] result of commands is implicitly written to pipe
[
https://issues.apache.org/jira/browse/FELIX-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Derek Baum reassigned FELIX-1474:
-
Assignee: Derek Baum
> [gogo] result of commands is implicitly written to pipe
> ---
>
> Key: FELIX-1474
> URL: https://issues.apache.org/jira/browse/FELIX-1474
> Project: Felix
> Issue Type: Bug
> Components: Gogo
>Reporter: Derek Baum
>Assignee: Derek Baum
>Priority: Minor
>
> RFC132 commands are designed to be easy to create, allowing direct use of
> System.out
> void echo1(String[] args) {
> StrinbgBuilder buf = new StringBuilder();
> for (String arg : args) {
> if (buf.length() > 0)
> buf.append(' ');
> buf.append(arg)
> }
> System.out.println(buf.toString());
> }
> but it also allows commands that return values:
> String echo2(String[] args) {
> StrinbgBuilder buf = new StringBuilder();
> for (String arg : args) {
> if (buf.length() > 0)
> buf.append(' ');
> buf.append(arg)
> }
> return(buf.toString());
> }
> Both these command cause grep to match 'hello':
> % echo1 hello | grep hello
> % echo2 hello | grep hello
> This is expected with echo1, as it writes to System.out.
> It is more surprising that echo2 also works, as it doesn't write to
> System.out.
> In this case, the runtime is implicitly writing the result of 'echo2 hello'
> into the pipe.
> This is convenient, as it lets commands that don't write to System.out be
> used in pipelines.
> However, it can also get in the way.
> I have a grep command that writes to System.out and returns a boolean,
> depending on whether it matched:
> % bundles | grep felix | wc
> but in this case, the wc command gets the output from grep and also the
> result of grep (true) which not wanted,
> so I would like some way of disabling this behaviour.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-1487) Support for commands on multiple lines
[
https://issues.apache.org/jira/browse/FELIX-1487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Derek Baum resolved FELIX-1487.
---
Resolution: Fixed
I have refactored the Parser to split-out a separate Tokenizer to help fix this
and other issues.
The Parser now allows NEWLINE as a statement separator instead of semi-colon,
which makes it much easier to create scripts.
The Parser also tracks the exact location (line and column) when an error
occurs, which is useful when an error occurs in a script file.
The new Parser passes all the existing tests, except
assertEquals("a", c.execute("a = a; echo $(echo a)"));
because variable expansion does not allow command execution: $(echo a)
This can obviously be fixed if needed, but this expansion didn't seem to be the
purpose of the test anyway.
Also indirect variable expansion, now needs to be enclosed in ${} - so ${$a}
and not $$a.
It also passes some new tests that I've created in TestParser2.
> Support for commands on multiple lines
> --
>
> Key: FELIX-1487
> URL: https://issues.apache.org/jira/browse/FELIX-1487
> Project: Felix
> Issue Type: Improvement
> Components: Gogo
>Reporter: Guillaume Nodet
>Assignee: Derek Baum
> Fix For: gogo-0.4.0
>
>
> I think this is important, especially when writing closures, to be able to
> split commands on multiple lines.
> From the shell, it can't be easily leveraged, unless the command line edition
> also supports multiline edition, but for script files, it would be really
> handy.
> My original thinking would be to consider new lines as ';', but this may
> required changing the precedence order of | and ;
> The other solution would be add a pseudo grouping operator () on each line in
> addition to considering newlines as ';'
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (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 resolved FELIX-1473.
---
Resolution: Fixed
typing a period(.) after a command, forces reflective method invocation on
String, rather than trying to invoke a command.
This allows the use of all the methods on String, for example:
x = (method args..)
if { $x . startsWith /} {...}
> [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
>Reporter: Guillaume Nodet
>Assignee: Derek Baum
> Fix For: gogo-0.4.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] Resolved: (FELIX-1493) [gogo] automatic expansion of $args in Closure stops direct access to $args list
[
https://issues.apache.org/jira/browse/FELIX-1493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Derek Baum resolved FELIX-1493.
---
Resolution: Fixed
I have added $argv which is always a non-null List and is not expanded
specially like $args.
for example
x = {
shift = ($argv remove 0)
echo arg1=$shift rest=$args
}
% x 1 2 3
arg1=1 rest=2 3
> [gogo] automatic expansion of $args in Closure stops direct access to $args
> list
>
>
> Key: FELIX-1493
> URL: https://issues.apache.org/jira/browse/FELIX-1493
> Project: Felix
> Issue Type: Bug
> Components: Gogo
>Reporter: Derek Baum
>Assignee: Derek Baum
>
> individual arguments to Closures can be accessed as $0, $1, $2
> all arguments can be accessed as the List $args.
> > x = { echo hello $args }
> > x a b
> used to produce:
> hello [a b]
> because the $args List was passed directly as a single argument to echo.
> This is not desirable in most cases, so the parser was changed to expand
> $args in Closures by expanding the $args List,
> thus producing:
> hello a b
> Unfortunately, this also broke the ability for a closure to access the $args
> list directly:
> % loop = { each $args { echo arg is $it }}
> % loop a b
> IllegalArgumentException: Cannot coerce each[1, 2, 3,
> org.apache.felix.gogo.runtime.shell.clos...@b1deea] to any of
> [(CommandSession, Collection, Function)]
> A simple fix would be to introduce an alternative Closure variable name e.g.
> argv that is NOT expanded, but remains as a list:
> % loop = { each $argv { echo arg is $it }}
> % loop a b
> arg is a
> arg is b
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-1474) [gogo] result of commands is implicitly written to pipe
[
https://issues.apache.org/jira/browse/FELIX-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Derek Baum resolved FELIX-1474.
---
Resolution: Fixed
This behaviour can now be disabled by setting the session variable
.FormatPipe=false
> [gogo] result of commands is implicitly written to pipe
> ---
>
> Key: FELIX-1474
> URL: https://issues.apache.org/jira/browse/FELIX-1474
> Project: Felix
> Issue Type: Bug
> Components: Gogo
>Reporter: Derek Baum
>Assignee: Derek Baum
>Priority: Minor
>
> RFC132 commands are designed to be easy to create, allowing direct use of
> System.out
> void echo1(String[] args) {
> StrinbgBuilder buf = new StringBuilder();
> for (String arg : args) {
> if (buf.length() > 0)
> buf.append(' ');
> buf.append(arg)
> }
> System.out.println(buf.toString());
> }
> but it also allows commands that return values:
> String echo2(String[] args) {
> StrinbgBuilder buf = new StringBuilder();
> for (String arg : args) {
> if (buf.length() > 0)
> buf.append(' ');
> buf.append(arg)
> }
> return(buf.toString());
> }
> Both these command cause grep to match 'hello':
> % echo1 hello | grep hello
> % echo2 hello | grep hello
> This is expected with echo1, as it writes to System.out.
> It is more surprising that echo2 also works, as it doesn't write to
> System.out.
> In this case, the runtime is implicitly writing the result of 'echo2 hello'
> into the pipe.
> This is convenient, as it lets commands that don't write to System.out be
> used in pipelines.
> However, it can also get in the way.
> I have a grep command that writes to System.out and returns a boolean,
> depending on whether it matched:
> % bundles | grep felix | wc
> but in this case, the wc command gets the output from grep and also the
> result of grep (true) which not wanted,
> so I would like some way of disabling this behaviour.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1493) [gogo] automatic expansion of $args in Closure stops direct access to $args list
[
https://issues.apache.org/jira/browse/FELIX-1493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Derek Baum updated FELIX-1493:
--
Fix Version/s: gogo-0.6.0
> [gogo] automatic expansion of $args in Closure stops direct access to $args
> list
>
>
> Key: FELIX-1493
> URL: https://issues.apache.org/jira/browse/FELIX-1493
> Project: Felix
> Issue Type: Bug
> Components: Gogo
>Reporter: Derek Baum
>Assignee: Derek Baum
> Fix For: gogo-0.6.0
>
>
> individual arguments to Closures can be accessed as $0, $1, $2
> all arguments can be accessed as the List $args.
> > x = { echo hello $args }
> > x a b
> used to produce:
> hello [a b]
> because the $args List was passed directly as a single argument to echo.
> This is not desirable in most cases, so the parser was changed to expand
> $args in Closures by expanding the $args List,
> thus producing:
> hello a b
> Unfortunately, this also broke the ability for a closure to access the $args
> list directly:
> % loop = { each $args { echo arg is $it }}
> % loop a b
> IllegalArgumentException: Cannot coerce each[1, 2, 3,
> org.apache.felix.gogo.runtime.shell.clos...@b1deea] to any of
> [(CommandSession, Collection, Function)]
> A simple fix would be to introduce an alternative Closure variable name e.g.
> argv that is NOT expanded, but remains as a list:
> % loop = { each $argv { echo arg is $it }}
> % loop a b
> arg is a
> arg is b
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1474) [gogo] result of commands is implicitly written to pipe
[
https://issues.apache.org/jira/browse/FELIX-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Derek Baum updated FELIX-1474:
--
Fix Version/s: gogo-0.6.0
> [gogo] result of commands is implicitly written to pipe
> ---
>
> Key: FELIX-1474
> URL: https://issues.apache.org/jira/browse/FELIX-1474
> Project: Felix
> Issue Type: Bug
> Components: Gogo
>Reporter: Derek Baum
>Assignee: Derek Baum
>Priority: Minor
> Fix For: gogo-0.6.0
>
>
> RFC132 commands are designed to be easy to create, allowing direct use of
> System.out
> void echo1(String[] args) {
> StrinbgBuilder buf = new StringBuilder();
> for (String arg : args) {
> if (buf.length() > 0)
> buf.append(' ');
> buf.append(arg)
> }
> System.out.println(buf.toString());
> }
> but it also allows commands that return values:
> String echo2(String[] args) {
> StrinbgBuilder buf = new StringBuilder();
> for (String arg : args) {
> if (buf.length() > 0)
> buf.append(' ');
> buf.append(arg)
> }
> return(buf.toString());
> }
> Both these command cause grep to match 'hello':
> % echo1 hello | grep hello
> % echo2 hello | grep hello
> This is expected with echo1, as it writes to System.out.
> It is more surprising that echo2 also works, as it doesn't write to
> System.out.
> In this case, the runtime is implicitly writing the result of 'echo2 hello'
> into the pipe.
> This is convenient, as it lets commands that don't write to System.out be
> used in pipelines.
> However, it can also get in the way.
> I have a grep command that writes to System.out and returns a boolean,
> depending on whether it matched:
> % bundles | grep felix | wc
> but in this case, the wc command gets the output from grep and also the
> result of grep (true) which not wanted,
> so I would like some way of disabling this behaviour.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (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 updated FELIX-1473: -- Fix Version/s: gogo-0.6.0 (was: gogo-0.4.0) > [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 >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] Updated: (FELIX-1487) Support for commands on multiple lines
[ https://issues.apache.org/jira/browse/FELIX-1487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum updated FELIX-1487: -- Fix Version/s: gogo-0.6.0 (was: gogo-0.4.0) > Support for commands on multiple lines > -- > > Key: FELIX-1487 > URL: https://issues.apache.org/jira/browse/FELIX-1487 > Project: Felix > Issue Type: Improvement > Components: Gogo >Reporter: Guillaume Nodet >Assignee: Derek Baum > Fix For: gogo-0.6.0 > > > I think this is important, especially when writing closures, to be able to > split commands on multiple lines. > From the shell, it can't be easily leveraged, unless the command line edition > also supports multiline edition, but for script files, it would be really > handy. > My original thinking would be to consider new lines as ';', but this may > required changing the precedence order of | and ; > The other solution would be add a pseudo grouping operator () on each line in > addition to considering newlines as ';' -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2328) [gogo] tidy-up runtime to remove optional code etc
[gogo] tidy-up runtime to remove optional code etc -- Key: FELIX-2328 URL: https://issues.apache.org/jira/browse/FELIX-2328 Project: Felix Issue Type: Improvement Components: Gogo Reporter: Derek Baum Assignee: Derek Baum Priority: Minor now that gogo is going to be the default framework shell, we should tidy-up the runtime component to ensure it is the minimum necessary to implement RFC-147. Currently the runtime also registers many commands, most of which are trivial and should instead be added by the user of the runtime. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-2328) [gogo] tidy-up runtime to remove optional code etc
[ https://issues.apache.org/jira/browse/FELIX-2328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum resolved FELIX-2328. --- Resolution: Fixed dead code removed. optional code all in osgi sub-package, but still currently started by Activator. I'll move this 'optional' completely out of the runtime bundle later. > [gogo] tidy-up runtime to remove optional code etc > -- > > Key: FELIX-2328 > URL: https://issues.apache.org/jira/browse/FELIX-2328 > Project: Felix > Issue Type: Improvement > Components: Gogo >Reporter: Derek Baum >Assignee: Derek Baum >Priority: Minor > > now that gogo is going to be the default framework shell, we should tidy-up > the runtime component to ensure it is the minimum necessary to implement > RFC-147. > Currently the runtime also registers many commands, most of which are trivial > and should instead be added by the user of the runtime. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2337) [gogo] no way to access array[] elements produced by assignment
[gogo] no way to access array[] elements produced by assignment
---
Key: FELIX-2337
URL: https://issues.apache.org/jira/browse/FELIX-2337
Project: Felix
Issue Type: Bug
Components: Gogo
Reporter: Derek Baum
Assignee: Derek Baum
Priority: Minor
Fix For: gogo-0.6.0
the following two alternative assignments, should be equivalent:
x = command args ...
x = (command args ..)
but they are not, if the result is an array:
% x = [a b c] toarray
% $x get 0
IllegalArgumentException: Cannot coerce get[0] to any of []
% x = ([a b c] toarray)
% $x get 0
This is because gogo normally converts any array result into a list
(Closure.java:228):
if (last.result instanceof Object[])
{
return Arrays.asList((Object[]) last.result);
}
but the assignment without () bypasses this conversion, and results in a real
array.
I can obviously fix this so that the conversion to a List occurs in all cases,
but I was wondering whether gogo should be performing this conversion in the
first place? If the conversion is not performed, then we'll need to support
($array $index) to access arrays.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2339) [gogo] add support for running scripts
[gogo] add support for running scripts -- Key: FELIX-2339 URL: https://issues.apache.org/jira/browse/FELIX-2339 Project: Felix Issue Type: Improvement Components: Gogo Reporter: Derek Baum Assignee: Derek Baum Fix For: gogo-0.6.0 gogo should be able to run scripts from files, which control how it boots or do other tasks. something like: $ gosh script.osh arg1 arg2 or $ source aliases.osh -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-2339) [gogo] add support for running scripts
[
https://issues.apache.org/jira/browse/FELIX-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Derek Baum resolved FELIX-2339.
---
Resolution: Fixed
[felix-framework-2.0.4]$ ls bundle
org.apache.felix.gogo.felixcommands-0.9.0-SNAPSHOT.jar
org.apache.felix.gogo.runtime-0.5.0-SNAPSHOT.jar
org.apache.felix.gogo.shell-0.5.0-SNAPSHOT.jar
[felix-framework-2.0.4]$ java -jar bin/felix.jar
Welcome to Felix
___
Welcome to Gogo
Use 'type' to explore registered commands, 'type -?' for help.
// the above 'Welcome to Gogo' message was produced by the default gosh_profile
script, which is a resource in the shell bundle.
g! cat gosh_profile
# default gosh_profile
# only read if etc/gosh_profile doesn't exist relative to the System property
# gosh.home or failing that the current directory.
# ensure gogo commands are found first
SCOPE = gogo:*
# add methods on BundleContext object as commands
#addcommand context ${.context} (${.context} class)
# bug: above invokes (String, Object, String) instead of (String, Object, Class)
addcommand context ${.context}
# add methods on System object as commands
# FELIX-2335 prevents the use of (bundle 0) loadclass
addcommand system ((bundle 1) loadclass java.lang.System)
# alias to print full stack trace
e = { $exception printStackTrace }
## disable console auto-formatting of each result
# you will then need to explicitly use the 'format' command
# to print the result of commands that don't write to stdout.
#.Gogo.format = false
## disable printing the formatted result of a command into pipelines
#.Format.Pipe = false
# set prompt
prompt = 'g! '
# print welcome message
try {
cat ($0 resolve motd)
}
# end
// note how the welcome message was produced by: try {
cat ($0 resolve motd)
}
g! cat x.osh
echo hello derek
echo args: $args
echo script: $0
g! gosh x.osh a b c
hello derek
args: a b c
script: file:/Users/derek/Downloads/felix-framework-2.0.4/x.osh
g! type
basic:15
context:30
files:2
gogo:21
obr:6
osgi:2
system:28
true
g! type -s gogo
gogo:cat
gogo:each
gogo:echo
gogo:format
gogo:getopt
gogo:gosh
gogo:grep
gogo:if
gogo:new
gogo:not
gogo:set
gogo:sh
gogo:shutdown
gogo:source
gogo:tac
gogo:telnetd
gogo:throw
gogo:try
gogo:type
gogo:until
gogo:while
true
g!
> [gogo] add support for running scripts
> --
>
> Key: FELIX-2339
> URL: https://issues.apache.org/jira/browse/FELIX-2339
> Project: Felix
> Issue Type: Improvement
> Components: Gogo
>Reporter: Derek Baum
>Assignee: Derek Baum
> Fix For: gogo-0.6.0
>
>
> gogo should be able to run scripts from files, which control how it boots or
> do other tasks.
> something like:
> $ gosh script.osh arg1 arg2
> or
> $ source aliases.osh
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2339) [gogo] add support for running scripts
[ https://issues.apache.org/jira/browse/FELIX-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12867199#action_12867199 ] Derek Baum commented on FELIX-2339: --- the scripting support can also run scripts without invoking the interactive console, e.g. [felix-framework-2.0.4]$ java -Dgosh.args='-sc telnetd -p1234 start' -jar bin/felix.jar Welcome to Felix ___ Welcome to Gogo Use 'type' to explore registered commands, 'type -?' for help. telnetd is running on port 1234 // the -c is --command which provides an in-line script (like bash -c 'commands..') // the -s is --noshutdown, so the framework continues to run after the command completes [felix-framework-2.0.4]$ telnet localhost 1234 Trying ::1... Connected to localhost. Escape character is '^]'. ___ Welcome to Gogo Use 'type' to explore registered commands, 'type -?' for help. g! > [gogo] add support for running scripts > -- > > Key: FELIX-2339 > URL: https://issues.apache.org/jira/browse/FELIX-2339 > Project: Felix > Issue Type: Improvement > Components: Gogo >Reporter: Derek Baum >Assignee: Derek Baum > Fix For: gogo-0.6.0 > > > gogo should be able to run scripts from files, which control how it boots or > do other tasks. > something like: > $ gosh script.osh arg1 arg2 > or > $ source aliases.osh -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (FELIX-1670) [gogo] launcher bundle not required
[ https://issues.apache.org/jira/browse/FELIX-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum reassigned FELIX-1670: - Assignee: Derek Baum > [gogo] launcher bundle not required > --- > > Key: FELIX-1670 > URL: https://issues.apache.org/jira/browse/FELIX-1670 > Project: Felix > Issue Type: Task > Components: Gogo >Affects Versions: gogo-0.2.0 >Reporter: Derek Baum >Assignee: Derek Baum >Priority: Minor > Fix For: gogo-0.6.0 > > > gogo creates 4 bundles: commands console launcher runtime > launcher is not required. > gogo can be launched using the standard felix launcher by removing > bundle/org.apache.felix.shell.tui-1.4.0.jar and adding the gogo console and > runtime bundles: > $ ls bundle/ > org.apache.felix.bundlerepository-1.4.1.jar > org.apache.felix.gogo.console-0.3.0-SNAPSHOT.jar > org.apache.felix.gogo.runtime-0.3.0-SNAPSHOT.jar > org.apache.felix.shell-1.4.0.jar > $ java -jar bin/felix.jar > Welcome to Felix > > $ bundles > 00 ACT org.apache.felix.framework-2.0.0 > 01 ACT org.apache.felix.bundlerepository-1.4.1 > 02 ACT org.apache.felix.gogo.console-0.3.0.SNAPSHOT > 03 ACT org.apache.felix.gogo.runtime-0.3.0.SNAPSHOT > 04 ACT org.apache.felix.shell-1.4.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-1670) [gogo] launcher bundle not required
[ https://issues.apache.org/jira/browse/FELIX-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum resolved FELIX-1670. --- Resolution: Fixed launcher bundle removed. (It only contained a single class). > [gogo] launcher bundle not required > --- > > Key: FELIX-1670 > URL: https://issues.apache.org/jira/browse/FELIX-1670 > Project: Felix > Issue Type: Task > Components: Gogo >Affects Versions: gogo-0.2.0 >Reporter: Derek Baum >Assignee: Derek Baum >Priority: Minor > Fix For: gogo-0.6.0 > > > gogo creates 4 bundles: commands console launcher runtime > launcher is not required. > gogo can be launched using the standard felix launcher by removing > bundle/org.apache.felix.shell.tui-1.4.0.jar and adding the gogo console and > runtime bundles: > $ ls bundle/ > org.apache.felix.bundlerepository-1.4.1.jar > org.apache.felix.gogo.console-0.3.0-SNAPSHOT.jar > org.apache.felix.gogo.runtime-0.3.0-SNAPSHOT.jar > org.apache.felix.shell-1.4.0.jar > $ java -jar bin/felix.jar > Welcome to Felix > > $ bundles > 00 ACT org.apache.felix.framework-2.0.0 > 01 ACT org.apache.felix.bundlerepository-1.4.1 > 02 ACT org.apache.felix.gogo.console-0.3.0.SNAPSHOT > 03 ACT org.apache.felix.gogo.runtime-0.3.0.SNAPSHOT > 04 ACT org.apache.felix.shell-1.4.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2341) [gogo] the commands module is not used by gogo itself and should be moved elsewhere
[gogo] the commands module is not used by gogo itself and should be moved elsewhere --- Key: FELIX-2341 URL: https://issues.apache.org/jira/browse/FELIX-2341 Project: Felix Issue Type: Task Components: Gogo, Karaf Reporter: Derek Baum Priority: Minor package org.apache.felix.gogo.commands is not used within Gogo, so we are looking to re-home the 'commands' bundle elsewhere. It appears it's main use is within Karaf, so we'd like it moved there, if possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2341) [gogo] the commands module is not used by gogo itself and should be moved elsewhere
[ https://issues.apache.org/jira/browse/FELIX-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12867468#action_12867468 ] Derek Baum commented on FELIX-2341: --- that's fine. thanks. > [gogo] the commands module is not used by gogo itself and should be moved > elsewhere > --- > > Key: FELIX-2341 > URL: https://issues.apache.org/jira/browse/FELIX-2341 > Project: Felix > Issue Type: Task > Components: Gogo, Karaf >Reporter: Derek Baum >Priority: Minor > > package org.apache.felix.gogo.commands is not used within Gogo, so we are > looking to re-home the 'commands' bundle elsewhere. > It appears it's main use is within Karaf, so we'd like it moved there, if > possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2342) [gogo] remove old felix command adaptor
[gogo] remove old felix command adaptor --- Key: FELIX-2342 URL: https://issues.apache.org/jira/browse/FELIX-2342 Project: Felix Issue Type: Improvement Components: Gogo Reporter: Derek Baum Assignee: Derek Baum Priority: Minor Fix For: gogo-0.6.0 now that Richard has ported the Felix commands to native gogo commands (in the felixcommands bundle), gogo no longer needs the legacy FelixCommandAdaptor. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-2342) [gogo] remove old felix command adaptor
[ https://issues.apache.org/jira/browse/FELIX-2342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum resolved FELIX-2342. --- Resolution: Fixed now removed > [gogo] remove old felix command adaptor > --- > > Key: FELIX-2342 > URL: https://issues.apache.org/jira/browse/FELIX-2342 > Project: Felix > Issue Type: Improvement > Components: Gogo >Reporter: Derek Baum >Assignee: Derek Baum >Priority: Minor > Fix For: gogo-0.6.0 > > > now that Richard has ported the Felix commands to native gogo commands (in > the felixcommands bundle), gogo no longer needs the legacy > FelixCommandAdaptor. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-1980) Gogo TelnetShell cannot be activated
[ https://issues.apache.org/jira/browse/FELIX-1980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum resolved FELIX-1980. --- Assignee: Derek Baum Resolution: Won't Fix gogo has been refactored recently, so that it can become the default shell in Felix. This refactoring has changed how the Console and Telnet work, so this fix is no longer relevant. To start telnet in the current gogo shell: g! telnetd [-p port] start To start telnetd at launch: $ java -Dgosh.args="-sc telnetd start" bin/felix.jar or add 'telnetd start' to the login script etc/gosh_profile > Gogo TelnetShell cannot be activated > > > Key: FELIX-1980 > URL: https://issues.apache.org/jira/browse/FELIX-1980 > Project: Felix > Issue Type: Bug > Components: Gogo >Reporter: Arjun Panday >Assignee: Derek Baum >Priority: Minor > Attachments: gogo.tgz, gogo2.tgz > > > Gogo's TelnetShell is implemented as an SCR component but no XML is provided > to activate it. > /Arjun -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-2337) [gogo] no way to access array[] elements produced by assignment
[
https://issues.apache.org/jira/browse/FELIX-2337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Derek Baum resolved FELIX-2337.
---
Resolution: Fixed
This has been fixed by not automatically converting return values that are
Array[] into ArrayList.
If you want to explicitly convert an Array[] into an List, then use:
g! b = (bundles)
g! lb = [ $b ]
g! set lb
ArrayList lb [org.apache.felix.framework [0], org.apache.f...
g! set b
Bundle[]b [Lorg.osgi.framework.Bundle;@538f1d7e
g!
To access elements of an array or list, use:
g! $b 1
Location
file:/Users/derek/Downloads/felix-framework-2.0.4/bundle/org.apache.felix.gogo.command-0.5.0-SNAPSHOT.jar
...
or
g! $lb get 1
Location
file:/Users/derek/Downloads/felix-framework-2.0.4/bundle/org.apache.felix.gogo.command-0.5.0-SNAPSHOT.jar
...
> [gogo] no way to access array[] elements produced by assignment
> ---
>
> Key: FELIX-2337
> URL: https://issues.apache.org/jira/browse/FELIX-2337
> Project: Felix
> Issue Type: Bug
> Components: Gogo
>Reporter: Derek Baum
>Assignee: Derek Baum
>Priority: Minor
> Fix For: gogo-0.6.0
>
>
> the following two alternative assignments, should be equivalent:
> x = command args ...
> x = (command args ..)
> but they are not, if the result is an array:
> % x = [a b c] toarray
> % $x get 0
> IllegalArgumentException: Cannot coerce get[0] to any of []
> % x = ([a b c] toarray)
> % $x get 0
> This is because gogo normally converts any array result into a list
> (Closure.java:228):
> if (last.result instanceof Object[])
> {
> return Arrays.asList((Object[]) last.result);
> }
> but the assignment without () bypasses this conversion, and results in a real
> array.
> I can obviously fix this so that the conversion to a List occurs in all
> cases, but I was wondering whether gogo should be performing this conversion
> in the first place? If the conversion is not performed, then we'll need to
> support ($array $index) to access arrays.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2375) [gogo] when supplied args can't be coerced, the error message prints the arg values, rather than their types
[gogo] when supplied args can't be coerced, the error message prints the arg values, rather than their types Key: FELIX-2375 URL: https://issues.apache.org/jira/browse/FELIX-2375 Project: Felix Issue Type: Bug Components: Gogo Reporter: Derek Baum Priority: Minor e.g. g! headers (bundles) gogo: IllegalArgumentException: Cannot coerce headers[[org.apache.felix.framework [0], org.apache.felix.bundlerepository [1], org.apache.felix.gogo.command [2], org.apache.felix.gogo.runtime [3], org.apache.felix.gogo.shell [4]]] to any of [(Bundle[])] This message would be better as: gogo: IllegalArgumentException: Cannot coerce headers(ArrayList) to any of [(Bundle[])] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2380) [gogo] lock contention in piped writer when reader doesn't read all input
[gogo] lock contention in piped writer when reader doesn't read all input - Key: FELIX-2380 URL: https://issues.apache.org/jira/browse/FELIX-2380 Project: Felix Issue Type: Bug Components: Gogo Reporter: Derek Baum Assignee: Derek Baum Priority: Minor The following completes almost immediately: g! cat conf/config.properties | grep Apache # Licensed to the Apache Software Foundation (ASF) under one # to you under the Apache License, Version 2.0 (the true but adding the --quiet flag to grep makes it take 1000mS longer: g! cat conf/config.properties | grep --quiet Apache true This is because grep stops reading its input as soon as it has seen the first match when --quiet is given. The same delay also occurs if you pipe into a command that doesn't read its input: g! cat conf/config.properties | echo The contention occurs because the writer (cat) is blocked on wait(1024) in PipedInputStream when the 1024 byte buffer is full. It is only unblocked when the reader (grep) reads more input. It is NOT unblocked when the reader closes the piped input. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2375) [gogo] when supplied args can't be coerced, the error message prints the arg values, rather than their types
[ https://issues.apache.org/jira/browse/FELIX-2375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum updated FELIX-2375: -- Assignee: Derek Baum Fix Version/s: gogo-0.6.0 > [gogo] when supplied args can't be coerced, the error message prints the arg > values, rather than their types > > > Key: FELIX-2375 > URL: https://issues.apache.org/jira/browse/FELIX-2375 > Project: Felix > Issue Type: Bug > Components: Gogo >Reporter: Derek Baum >Assignee: Derek Baum >Priority: Minor > Fix For: gogo-0.6.0 > > > e.g. > g! headers (bundles) > gogo: IllegalArgumentException: Cannot coerce > headers[[org.apache.felix.framework [0], org.apache.felix.bundlerepository > [1], org.apache.felix.gogo.command [2], org.apache.felix.gogo.runtime [3], > org.apache.felix.gogo.shell [4]]] to any of [(Bundle[])] > This message would be better as: > gogo: IllegalArgumentException: Cannot coerce headers(ArrayList) to any of > [(Bundle[])] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-2375) [gogo] when supplied args can't be coerced, the error message prints the arg values, rather than their types
[ https://issues.apache.org/jira/browse/FELIX-2375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum resolved FELIX-2375. --- Resolution: Fixed fixed as described, e.g. g! headers x gogo: IllegalArgumentException: Cannot coerce headers(String) to any of [(Bundle[])] > [gogo] when supplied args can't be coerced, the error message prints the arg > values, rather than their types > > > Key: FELIX-2375 > URL: https://issues.apache.org/jira/browse/FELIX-2375 > Project: Felix > Issue Type: Bug > Components: Gogo >Reporter: Derek Baum >Assignee: Derek Baum >Priority: Minor > Fix For: gogo-0.6.0 > > > e.g. > g! headers (bundles) > gogo: IllegalArgumentException: Cannot coerce > headers[[org.apache.felix.framework [0], org.apache.felix.bundlerepository > [1], org.apache.felix.gogo.command [2], org.apache.felix.gogo.runtime [3], > org.apache.felix.gogo.shell [4]]] to any of [(Bundle[])] > This message would be better as: > gogo: IllegalArgumentException: Cannot coerce headers(ArrayList) to any of > [(Bundle[])] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2380) [gogo] lock contention in piped writer when reader doesn't read all input
[ https://issues.apache.org/jira/browse/FELIX-2380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum updated FELIX-2380: -- Fix Version/s: gogo-0.6.0 > [gogo] lock contention in piped writer when reader doesn't read all input > - > > Key: FELIX-2380 > URL: https://issues.apache.org/jira/browse/FELIX-2380 > Project: Felix > Issue Type: Bug > Components: Gogo >Reporter: Derek Baum >Assignee: Derek Baum >Priority: Minor > Fix For: gogo-0.6.0 > > > The following completes almost immediately: > g! cat conf/config.properties | grep Apache > # Licensed to the Apache Software Foundation (ASF) under one > # to you under the Apache License, Version 2.0 (the > true > but adding the --quiet flag to grep makes it take 1000mS longer: > g! cat conf/config.properties | grep --quiet Apache > true > This is because grep stops reading its input as soon as it has seen the first > match when --quiet is given. > The same delay also occurs if you pipe into a command that doesn't read its > input: > g! cat conf/config.properties | echo > The contention occurs because the writer (cat) is blocked on wait(1024) in > PipedInputStream when the 1024 byte buffer is full. It is only unblocked when > the reader (grep) reads more input. It is NOT unblocked when the reader > closes the piped input. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-2380) [gogo] lock contention in piped writer when reader doesn't read all input
[ https://issues.apache.org/jira/browse/FELIX-2380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum resolved FELIX-2380. --- Resolution: Fixed resolved by reflectively calling PipedInputStream.receivedLast(), which notifies the writer and stops it waiting. > [gogo] lock contention in piped writer when reader doesn't read all input > - > > Key: FELIX-2380 > URL: https://issues.apache.org/jira/browse/FELIX-2380 > Project: Felix > Issue Type: Bug > Components: Gogo >Reporter: Derek Baum >Assignee: Derek Baum >Priority: Minor > Fix For: gogo-0.6.0 > > > The following completes almost immediately: > g! cat conf/config.properties | grep Apache > # Licensed to the Apache Software Foundation (ASF) under one > # to you under the Apache License, Version 2.0 (the > true > but adding the --quiet flag to grep makes it take 1000mS longer: > g! cat conf/config.properties | grep --quiet Apache > true > This is because grep stops reading its input as soon as it has seen the first > match when --quiet is given. > The same delay also occurs if you pipe into a command that doesn't read its > input: > g! cat conf/config.properties | echo > The contention occurs because the writer (cat) is blocked on wait(1024) in > PipedInputStream when the 1024 byte buffer is full. It is only unblocked when > the reader (grep) reads more input. It is NOT unblocked when the reader > closes the piped input. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2396) Ability to have callbacks when accessing session variables
[
https://issues.apache.org/jira/browse/FELIX-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12877032#action_12877032
]
Derek Baum commented on FELIX-2396:
---
or use closures:
Object getAndEvaluate(String name)
{
Object value = session.get(name);
if (value instanceof Function)
{
try {
value = ((Function) value).execute(session, null);
} catch (Throwable e) {
// ignore
}
}
return value;
}
e.g.
prompt = getAndEvaluate("prompt");
will work with a simple
prompt = "g! "
or a closure:
prompt = { (pwd; echo '% ') | tac}
which will change the prompt in line with the current directory.
> Ability to have callbacks when accessing session variables
> --
>
> Key: FELIX-2396
> URL: https://issues.apache.org/jira/browse/FELIX-2396
> Project: Felix
> Issue Type: Improvement
> Components: Gogo
>Reporter: Guillaume Nodet
>
> This is required for a better integration when the value is computed without
> any simple way to be aware of the fact that the value has changed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2340) Combine "type" and "help" commands into a single help facility
[ https://issues.apache.org/jira/browse/FELIX-2340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum updated FELIX-2340: -- Component/s: Gogo command Gogo shell (was: Gogo) > Combine "type" and "help" commands into a single help facility > -- > > Key: FELIX-2340 > URL: https://issues.apache.org/jira/browse/FELIX-2340 > Project: Felix > Issue Type: Improvement > Components: Gogo command, Gogo shell >Affects Versions: gogo-0.6.0 >Reporter: Richard S. Hall > Fix For: gogo-0.8.0 > > > Currently, we have a "type" command for exploring existing commands and I've > implemented a "help" command in the felixcommands module. They serve slightly > different purposes, but I think it would be fairly straightforward to combine > them into a single help facility. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1521) [gogo] ANTLR grammar for gogo
[ https://issues.apache.org/jira/browse/FELIX-1521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum updated FELIX-1521: -- Component/s: Gogo runtime (was: Gogo) > [gogo] ANTLR grammar for gogo > - > > Key: FELIX-1521 > URL: https://issues.apache.org/jira/browse/FELIX-1521 > Project: Felix > Issue Type: New Feature > Components: Gogo runtime >Reporter: Guillaume Nodet > Attachments: gogo.g, gogo.g, gogo.g > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2396) Ability to have callbacks when accessing session variables
[ https://issues.apache.org/jira/browse/FELIX-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum updated FELIX-2396: -- Component/s: Gogo runtime (was: Gogo) > Ability to have callbacks when accessing session variables > -- > > Key: FELIX-2396 > URL: https://issues.apache.org/jira/browse/FELIX-2396 > Project: Felix > Issue Type: Improvement > Components: Gogo runtime >Reporter: Guillaume Nodet > > This is required for a better integration when the value is computed without > any simple way to be aware of the fact that the value has changed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1582) [gogo] the commands bundle include a class from the blueprint api (ReifiedType) which would be better located in a org.osgi.service.blueprint.converter private package
[ https://issues.apache.org/jira/browse/FELIX-1582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12880799#action_12880799 ] Derek Baum commented on FELIX-1582: --- The commands bundle has now been removed, so this issue can be closed. > [gogo] the commands bundle include a class from the blueprint api > (ReifiedType) which would be better located in a > org.osgi.service.blueprint.converter private package > --- > > Key: FELIX-1582 > URL: https://issues.apache.org/jira/browse/FELIX-1582 > Project: Felix > Issue Type: Task > Components: Gogo >Reporter: Guillaume Nodet > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1522) Add an eval command / keyword
[ https://issues.apache.org/jira/browse/FELIX-1522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum updated FELIX-1522: -- Component/s: (was: Gogo) Gogo runtime > Add an eval command / keyword > - > > Key: FELIX-1522 > URL: https://issues.apache.org/jira/browse/FELIX-1522 > Project: Felix > Issue Type: New Feature > Components: Gogo runtime >Reporter: Guillaume Nodet > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1498) After parameter evaluation, the result should be splitted again into tokens before executing the command line
[ https://issues.apache.org/jira/browse/FELIX-1498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum updated FELIX-1498: -- Component/s: Gogo runtime (was: Gogo) > After parameter evaluation, the result should be splitted again into tokens > before executing the command line > - > > Key: FELIX-1498 > URL: https://issues.apache.org/jira/browse/FELIX-1498 > Project: Felix > Issue Type: Bug > Components: Gogo runtime >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet > Attachments: FELIX-1498.patch > > > I think we should have: > > a = "echo b" > > $a > b > The previous behavior could be done by adding quotes: > > "$a" > echo b > This would be more consistent with the parameter expansion that is currently > done. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2432) [gogo] NPE/coercion failure when null first parameter to method expecting arry
[gogo] NPE/coercion failure when null first parameter to method expecting arry -- Key: FELIX-2432 URL: https://issues.apache.org/jira/browse/FELIX-2432 Project: Felix Issue Type: Bug Components: Gogo runtime Affects Versions: gogo-0.6.0 Reporter: Derek Baum Assignee: Derek Baum Fix For: gogo-0.8.0 g! echo null hello gogo: NullPointerException: null g! e java.lang.NullPointerException at org.apache.felix.gogo.runtime.Reflective.method(Reflective.java:174) at org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:82) at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:421) at org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:335) at org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108) at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:184) at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:121) at org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:78) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2433) [gogo] allow command expansion inside double quotes
[gogo] allow command expansion inside double quotes --- Key: FELIX-2433 URL: https://issues.apache.org/jira/browse/FELIX-2433 Project: Felix Issue Type: Improvement Components: Gogo runtime Affects Versions: gogo-0.6.0 Reporter: Derek Baum Assignee: Derek Baum Priority: Minor Fix For: gogo-0.8.0 currently, gogo does not allow command execution inside double quotes, so for example many operations must be done in multiple stages, first assigning the result to a variable, for later inclusion in a double quoted string: val = ($props get "framework-packages") packages = $val val = ($props get "jre-1.6") packages = "$packages, $val" val = ($props get "sun-packages") packages = "$packages, $val" The improvement suggested is to make "$(...)" expand to execution within string variable expansion: packages = "$($props get framework-packages), $($props get 'jre-1.6'), $($props get 'sun-packages')" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-2432) [gogo] NPE/coercion failure when null first parameter to method expecting arry
[ https://issues.apache.org/jira/browse/FELIX-2432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum resolved FELIX-2432. --- Resolution: Fixed fixed in coercion code > [gogo] NPE/coercion failure when null first parameter to method expecting arry > -- > > Key: FELIX-2432 > URL: https://issues.apache.org/jira/browse/FELIX-2432 > Project: Felix > Issue Type: Bug > Components: Gogo runtime >Affects Versions: gogo-0.6.0 >Reporter: Derek Baum >Assignee: Derek Baum > Fix For: gogo-0.8.0 > > > g! echo null hello > gogo: NullPointerException: null > g! e > java.lang.NullPointerException > at > org.apache.felix.gogo.runtime.Reflective.method(Reflective.java:174) > at > org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:82) > at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:421) > at > org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:335) > at org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108) > at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:184) > at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:121) > at > org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:78) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-2433) [gogo] allow command expansion inside double quotes
[ https://issues.apache.org/jira/browse/FELIX-2433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum resolved FELIX-2433. --- Resolution: Fixed "$(...)" now expands by executing command > [gogo] allow command expansion inside double quotes > --- > > Key: FELIX-2433 > URL: https://issues.apache.org/jira/browse/FELIX-2433 > Project: Felix > Issue Type: Improvement > Components: Gogo runtime >Affects Versions: gogo-0.6.0 >Reporter: Derek Baum >Assignee: Derek Baum >Priority: Minor > Fix For: gogo-0.8.0 > > > currently, gogo does not allow command execution inside double quotes, so for > example many operations must be done in multiple stages, first assigning the > result to a variable, for later inclusion in a double quoted string: > val = ($props get "framework-packages") > packages = $val > val = ($props get "jre-1.6") > packages = "$packages, $val" > val = ($props get "sun-packages") > packages = "$packages, $val" > The improvement suggested is to make "$(...)" expand to execution within > string variable expansion: > packages = "$($props get framework-packages), $($props get 'jre-1.6'), > $($props get 'sun-packages')" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (FELIX-2446) [Gogo] The bundle context command is not registered with a scope in gosh_profile
[ https://issues.apache.org/jira/browse/FELIX-2446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum reassigned FELIX-2446: - Assignee: Derek Baum > [Gogo] The bundle context command is not registered with a scope in > gosh_profile > > > Key: FELIX-2446 > URL: https://issues.apache.org/jira/browse/FELIX-2446 > Project: Felix > Issue Type: Bug > Components: Gogo Shell >Affects Versions: gogo-0.6.0 >Reporter: Richard S. Hall >Assignee: Derek Baum > Fix For: gogo-0.8.0 > > > The default gosh_profile shell registers the bundle context as a command, but > it is not assigned any scope. This apparently is problematic for anyone else > registering a command with overlapping names as what is on bundle context. > For example, registering a command named "bundle" causes the following > gosh_profile line to fail: > addcommand system ((bundle 1) loadclass java.lang.System) > I am not sure why or how it is shadowing it, since it seems like the order > should favor the built-in commands, but apparently. Regardless, if we had a > scope assigned to this we could be precise in our gosh_profile shell (e.g., > gogo:bundle) to avoid this issue altogether. > To make matters worse, this causes the entire shell bundle to die...it might > be nice if it continued to function even if there are errors in the > gosh_profile. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-2446) [Gogo] The bundle context command is not registered with a scope in gosh_profile
[
https://issues.apache.org/jira/browse/FELIX-2446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Derek Baum resolved FELIX-2446.
---
Resolution: Fixed
The context commands are registered into a scope - the first argument of
addcommand is the scope:
addcommand context ${.context}
I have however fixed gosh_profile to explicitly use this scope when referencing
the bundle command:
# add methods on System object as commands
addcommand system ((context:bundle 0) loadclass java.lang.System
since the bundle context is also set as a session variable, we could have
written the above as:
addcommand system (${.context} bundle 0) loadclass java.lang.System
We could protect errors in the whole gosh_profile from aborting startup by
enclosing them in a try block, as is used for displaying the message of the day
- rather than test whether the file exists, we just eclose it in a try block:
# print welcome message
try {
cat ($0 resolve motd)
}
> [Gogo] The bundle context command is not registered with a scope in
> gosh_profile
>
>
> Key: FELIX-2446
> URL: https://issues.apache.org/jira/browse/FELIX-2446
> Project: Felix
> Issue Type: Bug
> Components: Gogo Shell
>Affects Versions: gogo-0.6.0
>Reporter: Richard S. Hall
>Assignee: Derek Baum
> Fix For: gogo-0.8.0
>
>
> The default gosh_profile shell registers the bundle context as a command, but
> it is not assigned any scope. This apparently is problematic for anyone else
> registering a command with overlapping names as what is on bundle context.
> For example, registering a command named "bundle" causes the following
> gosh_profile line to fail:
> addcommand system ((bundle 1) loadclass java.lang.System)
> I am not sure why or how it is shadowing it, since it seems like the order
> should favor the built-in commands, but apparently. Regardless, if we had a
> scope assigned to this we could be precise in our gosh_profile shell (e.g.,
> gogo:bundle) to avoid this issue altogether.
> To make matters worse, this causes the entire shell bundle to die...it might
> be nice if it continued to function even if there are errors in the
> gosh_profile.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-2445) [Gogo] Default gosh_profile should be updated to use system bundle to load java.lang.System
[ https://issues.apache.org/jira/browse/FELIX-2445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum resolved FELIX-2445. --- Resolution: Fixed now load java.lang.System using bundle 0 > [Gogo] Default gosh_profile should be updated to use system bundle to load > java.lang.System > --- > > Key: FELIX-2445 > URL: https://issues.apache.org/jira/browse/FELIX-2445 > Project: Felix > Issue Type: Improvement > Components: Gogo Shell >Affects Versions: gogo-0.6.0 >Reporter: Richard S. Hall > Fix For: gogo-0.8.0 > > > The default gosh_profile file uses bundle 1 to load class because there was > an issue with using bundle 0 (FELIX-2335), but that issue has reportedly been > fixed, so in theory it should work now. Using bundle 1 is a bad idea, since > there is no guarantee that such a bundle will exist. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2446) [Gogo] The bundle context command is not registered with a scope in gosh_profile
[
https://issues.apache.org/jira/browse/FELIX-2446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12882337#action_12882337
]
Derek Baum commented on FELIX-2446:
---
the whole gosh_profile is now enclosed in a try {} block, so it doesn't abort
startup if an error occurs:
$ java -jar bin/felix.jar
bundle://4.0:1/gosh_profile: ERROR: java.io.IOException: Resource does not
exist: bundle://4.0:1/motdx
> [Gogo] The bundle context command is not registered with a scope in
> gosh_profile
>
>
> Key: FELIX-2446
> URL: https://issues.apache.org/jira/browse/FELIX-2446
> Project: Felix
> Issue Type: Bug
> Components: Gogo Shell
>Affects Versions: gogo-0.6.0
>Reporter: Richard S. Hall
>Assignee: Derek Baum
> Fix For: gogo-0.8.0
>
>
> The default gosh_profile shell registers the bundle context as a command, but
> it is not assigned any scope. This apparently is problematic for anyone else
> registering a command with overlapping names as what is on bundle context.
> For example, registering a command named "bundle" causes the following
> gosh_profile line to fail:
> addcommand system ((bundle 1) loadclass java.lang.System)
> I am not sure why or how it is shadowing it, since it seems like the order
> should favor the built-in commands, but apparently. Regardless, if we had a
> scope assigned to this we could be precise in our gosh_profile shell (e.g.,
> gogo:bundle) to avoid this issue altogether.
> To make matters worse, this causes the entire shell bundle to die...it might
> be nice if it continued to function even if there are errors in the
> gosh_profile.
--
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, List arguments) throws
Exception;
}
Closure.java:113:
// implements Function interface
// XXX: session arg x not used?
public Object execute(CommandSession x, List 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-tabpanel&focusedCommentId=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, List arguments) throws
> Exception;
> }
> Closure.java:113:
> // implements Function interface
> // XXX: session arg x not used?
> public Object execute(CommandSession x, List 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, List arguments) throws
> Exception;
> }
> Closure.java:113:
> // implements Function interface
> // XXX: session arg x not used?
> public Object execute(CommandSession x, List 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] 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] Work started: (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 ] Work on FELIX-1473 started by Derek Baum. > [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] Resolved: (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 resolved FELIX-1473. --- Fix Version/s: gogo-0.8.0 (was: gogo-0.6.0) Resolution: Fixed use new approach to call methods on Strings. e.g. this now works: g! $SCOPE length 6 g! cmd = echo echo g! $cmd hello gogo: IllegalArgumentException: Cannot coerce hello() to any of [] g! 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.8.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-2463) [sigil] order of -resources is not preserved
[sigil] order of -resources is not preserved Key: FELIX-2463 URL: https://issues.apache.org/jira/browse/FELIX-2463 Project: Felix Issue Type: Bug Components: Sigil Reporter: Derek Baum Assignee: Derek Baum the order of resources specified using -resources is not preserved - impl should use LinkedHashMap. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-2463) [sigil] order of -resources is not preserved
[ https://issues.apache.org/jira/browse/FELIX-2463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum resolved FELIX-2463. --- Resolution: Fixed > [sigil] order of -resources is not preserved > > > Key: FELIX-2463 > URL: https://issues.apache.org/jira/browse/FELIX-2463 > Project: Felix > Issue Type: Bug > Components: Sigil >Reporter: Derek Baum >Assignee: Derek Baum > > the order of resources specified using -resources is not preserved - impl > should use LinkedHashMap. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2468) [gogo] CharSequence types are converted to String
[gogo] CharSequence types are converted to String - Key: FELIX-2468 URL: https://issues.apache.org/jira/browse/FELIX-2468 Project: Felix Issue Type: Bug Components: Gogo Runtime Affects Versions: gogo-0.6.0 Reporter: Derek Baum Assignee: Derek Baum Priority: Minor Fix For: gogo-0.8.0 gogo now allows creation of a StringBuilder, but when it is accessed it is converted to String g! b = new StringBuilder g! $b append gogo: IllegalArgumentException: Cannot coerce append() to any of [] g! c = $b g! set null0 null String SCOPE gogo:* String _ StringBuilder b String c Closure e $exception printStackTrace String prompt g! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2477) [gogo] shell procedural commands don't inherit closure arguments
[gogo] shell procedural commands don't inherit closure arguments
Key: FELIX-2477
URL: https://issues.apache.org/jira/browse/FELIX-2477
Project: Felix
Issue Type: Bug
Components: Gogo Shell
Reporter: Derek Baum
Assignee: Derek Baum
Priority: Minor
Fix For: gogo-0.8.0
f = {
echo arg $1
if { echo arg $1 } { }
}
in the closure above, you would expect $1 to expand the same in both cases, but
it doesn't always as the procedural commands unnecessarily try to pass $args to
their Function arguments; this is now handled by the runtime, so the procedural
commands should pass null args.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-2477) [gogo] shell procedural commands don't inherit closure arguments
[
https://issues.apache.org/jira/browse/FELIX-2477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Derek Baum resolved FELIX-2477.
---
Resolution: Fixed
> [gogo] shell procedural commands don't inherit closure arguments
>
>
> Key: FELIX-2477
> URL: https://issues.apache.org/jira/browse/FELIX-2477
> Project: Felix
> Issue Type: Bug
> Components: Gogo Shell
>Reporter: Derek Baum
>Assignee: Derek Baum
>Priority: Minor
> Fix For: gogo-0.8.0
>
>
> f = {
> echo arg $1
> if { echo arg $1 } { }
> }
> in the closure above, you would expect $1 to expand the same in both cases,
> but it doesn't always as the procedural commands unnecessarily try to pass
> $args to their Function arguments; this is now handled by the runtime, so the
> procedural commands should pass null args.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2494) [sigil] need to restart Eclipse for change in sigil.properties to be recognised
[sigil] need to restart Eclipse for change in sigil.properties to be recognised --- Key: FELIX-2494 URL: https://issues.apache.org/jira/browse/FELIX-2494 Project: Felix Issue Type: Bug Components: Sigil Reporter: Derek Baum explicitly removed required dependency, then allowed "quick-fix" to re-add it. This resulted in new dependency having explicit version, where as before it inherited a version-range. reverted sigil.properties in scm, refreshed file in Eclipse, but Sigil UI still showed versioned dependency in dependencies view, while the sigil.properties view (correctly) showed the non-versioned dependency. I tried closing and reopening the project, but actually had to restart Eclipse before the UI dependencies tab correctly reflected the contents of sigil.properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2495) [sigil] UI update of project containing multiple bundles is broken
[sigil] UI update of project containing multiple bundles is broken -- Key: FELIX-2495 URL: https://issues.apache.org/jira/browse/FELIX-2495 Project: Felix Issue Type: Bug Components: Sigil Reporter: Derek Baum Assignee: Derek Baum sigil.properties supports multiple bundles, but the UI view only shows the "default" bundle. If the dependencies change, the UI creates a sigil.properties file with ;-imports=xxx, which is wrong, as the -imports compile dependencies are common to all bundles, so should not be prefixed by ; -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2496) [sigil] saving file with trival change results in many "red line" errors
[sigil] saving file with trival change results in many "red line" errors Key: FELIX-2496 URL: https://issues.apache.org/jira/browse/FELIX-2496 Project: Felix Issue Type: Bug Components: Sigil Reporter: Derek Baum I just updated a comment in a sigil project with no errors, saved the file and it no longer compiled: eclipse.buildId=M20100211-1343 java.version=1.6.0_20 java.vendor=Apple Inc. BootLoader constants: OS=macosx, ARCH=x86_64, WS=cocoa, NL=en_US Framework arguments: -keyring /Users/derek/.eclipse_keyring -showlocation Command-line arguments: -os macosx -ws cocoa -arch x86_64 -keyring /Users/derek/.eclipse_keyring -showlocation Error Fri Jul 30 13:14:52 BST 2010 JavaBuilder handling CoreException org.eclipse.core.runtime.CoreException: File not found: /Users/derek/devl/apache/sigil/common/core/build/classes/org/apache/felix/sigil/config/BldConverter.class. at org.eclipse.core.internal.filesystem.Policy.error(Policy.java:55) at org.eclipse.core.internal.filesystem.local.LocalFile.openInputStream(LocalFile.java:371) at org.eclipse.core.internal.localstore.FileSystemResourceManager.read(FileSystemResourceManager.java:667) at org.eclipse.core.internal.resources.File.getContents(File.java:288) at org.eclipse.jdt.internal.core.util.Util.getResourceContentsAsByteArray(Util.java:1110) at org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.writeClassFileCheck(IncrementalImageBuilder.java:875) at org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.writeClassFileContents(IncrementalImageBuilder.java:817) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.writeClassFile(AbstractImageBuilder.java:823) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.acceptResult(AbstractImageBuilder.java:187) at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:504) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:364) at org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.compile(IncrementalImageBuilder.java:321) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:301) at org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.build(IncrementalImageBuilder.java:134) at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildDeltas(JavaBuilder.java:265) at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:193) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:627) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:170) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:201) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:253) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:256) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:309) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:341) at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:140) at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:238) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) Caused by: java.io.FileNotFoundException: /Users/derek/devl/apache/sigil/common/core/build/classes/org/apache/felix/sigil/config/BldConverter.class (No such file or directory) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.(FileInputStream.java:106) at org.eclipse.core.internal.filesystem.local.LocalFile.openInputStream(LocalFile.java:362) ... 26 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-2495) [sigil] UI update of project containing multiple bundles is broken
[ https://issues.apache.org/jira/browse/FELIX-2495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum resolved FELIX-2495. --- Fix Version/s: sigil-1.0.0 Resolution: Fixed > [sigil] UI update of project containing multiple bundles is broken > -- > > Key: FELIX-2495 > URL: https://issues.apache.org/jira/browse/FELIX-2495 > Project: Felix > Issue Type: Bug > Components: Sigil >Reporter: Derek Baum >Assignee: Derek Baum > Fix For: sigil-1.0.0 > > > sigil.properties supports multiple bundles, but the UI view only shows the > "default" bundle. > If the dependencies change, the UI creates a sigil.properties file with > ;-imports=xxx, which is wrong, as the -imports compile > dependencies are common to all bundles, so should not be prefixed by > ; -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2545) [gogo] runtime should close all open sessions when it is stopped
[gogo] runtime should close all open sessions when it is stopped Key: FELIX-2545 URL: https://issues.apache.org/jira/browse/FELIX-2545 Project: Felix Issue Type: Bug Components: Gogo Runtime Affects Versions: gogo-0.6.0, gogo-0.4.0, gogo-0.2.2, gogo-0.2.0 Reporter: Derek Baum Assignee: Derek Baum Priority: Minor Fix For: gogo-0.8.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-2545) [gogo] runtime should close all open sessions when it is stopped
[ https://issues.apache.org/jira/browse/FELIX-2545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum resolved FELIX-2545. --- Resolution: Fixed fixed: $ java -jar bin/felix.jar Welcome to Apache Felix Gogo g! lb START LEVEL 1 ID|State |Level|Name 0|Active |0|System Bundle (3.0.1) 1|Active |1|Apache Felix Bundle Repository (1.6.2) 2|Active |1|Apache Felix Gogo Command (0.7.0.SNAPSHOT) 3|Active |1|Apache Felix Gogo Runtime (0.7.0.SNAPSHOT) 4|Active |1|Apache Felix Gogo Shell (0.7.0.SNAPSHOT) g! stop 3 g! lb gosh: java.lang.IllegalStateException: session is closed gosh: stopping framework > [gogo] runtime should close all open sessions when it is stopped > > > Key: FELIX-2545 > URL: https://issues.apache.org/jira/browse/FELIX-2545 > Project: Felix > Issue Type: Bug > Components: Gogo Runtime >Affects Versions: gogo-0.2.0, gogo-0.2.2, gogo-0.4.0, gogo-0.6.0 >Reporter: Derek Baum >Assignee: Derek Baum >Priority: Minor > Fix For: gogo-0.8.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-2618) Bundle resolution causes CNFE for java.lang.System
[ https://issues.apache.org/jira/browse/FELIX-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12914097#action_12914097 ] Derek Baum commented on FELIX-2618: --- OK, we've worked out what's going on. https://issues.apache.org/jira/browse/FELIX-2445 was not fixed until _after_ the gogo-0.6 release, thus gogo-0.6 tries to loadclass java.lang.System from bundle 1 (due to https://issues.apache.org/jira/browse/FELIX-2335). This happens to work in the default framework distribution, because bundle 1 is the felix bundle repository, but when you add your test bundle to the bundles directory, it becomes bundle 1 and thus we get the error. gogo-0.6.1 and a framework-3.0.3 are just about to be released, which will fix this. You can work-around it now, by extracting and fixing gosh_profile, as follows: $ cd felix-framework-3.0.2 $ jar xvf bundle/org.apache.felix.gogo.shell-0.6.0.jar gosh_profile $ mkdir etc $ mv gosh_profile etc Then edit etc/gosh_profile, and change the following line: addcommand system ((bundle 1) loadclass java.lang.System) to addcommand system ((bundle 0) loadclass java.lang.System) > Bundle resolution causes CNFE for java.lang.System > -- > > Key: FELIX-2618 > URL: https://issues.apache.org/jira/browse/FELIX-2618 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: gogo-0.6.0 > Environment: Fedora 11 Linux x86_64 Java 1.6.0_13-b03 Felix Framework > 3.0.2 >Reporter: John Dunlap >Priority: Minor > Fix For: gogo-0.8.0 > > Attachments: dictionary-service.zip > > > If I attempt to import the package org.apache.felix.shell in my bundle > manifest I get the following error, > ERROR: Error starting > file:/home/jddunlap/apache-felix/felix-framework-3.0.2/bundle/dictionary-service-1.0-SNAPSHOT.jar > (org.osgi.framework.BundleException: Unresolved constraint in bundle [1]: > Unable to resolve 1.0: missing requirement [1.0] package; > (package=org.osgi.framework.shell)) > org.osgi.framework.BundleException: Unresolved constraint in bundle [1]: > Unable to resolve 1.0: missing requirement [1.0] package; > (package=org.osgi.framework.shell) > at org.apache.felix.framework.Felix.resolveBundle(Felix.java:3409) > at org.apache.felix.framework.Felix.startBundle(Felix.java:1709) > at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1143) > at > org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264) > at java.lang.Thread.run(Thread.java:619) > bundle://5.0:1/gosh_profile:15.20: ClassNotFoundException: java.lang.System > java.lang.ClassNotFoundException: java.lang.System > at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1591) > at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:887) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.apache.felix.gogo.runtime.Reflective.method(Reflective.java:136) > at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:465) > at > org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:335) > at org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108) > at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:184) > at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:121) > at org.apache.felix.gogo.runtime.Closure.eval(Closure.java:265) > at > org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:307) > at org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108) > at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:184) > at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:121) > at > org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:78) > at org.apache.felix.gogo.shell.Shell.source(Shell.java:186) > at org.apache.felix.gogo.shell.Shell.gosh(Shell.java:106) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.apache.felix.gogo.runtime.Reflective.method(Reflective.java:136) > at > org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:82) > at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:421) > at > org.
[jira] Assigned: (FELIX-2661) [Gogo] It should be easier to start Gogo shell non-interactively
[ https://issues.apache.org/jira/browse/FELIX-2661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum reassigned FELIX-2661: - Assignee: Derek Baum > [Gogo] It should be easier to start Gogo shell non-interactively > > > Key: FELIX-2661 > URL: https://issues.apache.org/jira/browse/FELIX-2661 > Project: Felix > Issue Type: Improvement > Components: Gogo Shell >Affects Versions: gogo-0.6.1 >Reporter: Richard S. Hall >Assignee: Derek Baum > Fix For: gogo-0.8.0 > > > To start the Gogo shell non-interactively, you have to specify a dummy > command and tell it not to shutdown in its configuration...something like > this: > gosh.args=--noshutdown -c noop=true > This is not necessarily the most straightforward approach and it also results > in the gosh_profile being executed and the MOTD being displayed, which > doesn't really make sense in the non-interactive use case. > It seems like it would be better to have an explicit flag to tell the Gogo > shell to start up non-interactively (e.g., --noninteractive), which would > also imply not shutting down, but wouldn't require a dummy command, nor > execute the gosh_profile. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Work started: (FELIX-2661) [Gogo] It should be easier to start Gogo shell non-interactively
[ https://issues.apache.org/jira/browse/FELIX-2661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on FELIX-2661 started by Derek Baum. > [Gogo] It should be easier to start Gogo shell non-interactively > > > Key: FELIX-2661 > URL: https://issues.apache.org/jira/browse/FELIX-2661 > Project: Felix > Issue Type: Improvement > Components: Gogo Shell >Affects Versions: gogo-0.6.1 >Reporter: Richard S. Hall >Assignee: Derek Baum > Fix For: gogo-0.8.0 > > > To start the Gogo shell non-interactively, you have to specify a dummy > command and tell it not to shutdown in its configuration...something like > this: > gosh.args=--noshutdown -c noop=true > This is not necessarily the most straightforward approach and it also results > in the gosh_profile being executed and the MOTD being displayed, which > doesn't really make sense in the non-interactive use case. > It seems like it would be better to have an explicit flag to tell the Gogo > shell to start up non-interactively (e.g., --noninteractive), which would > also imply not shutting down, but wouldn't require a dummy command, nor > execute the gosh_profile. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-2661) [Gogo] It should be easier to start Gogo shell non-interactively
[ https://issues.apache.org/jira/browse/FELIX-2661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum resolved FELIX-2661. --- Resolution: Fixed added --nointeractive flag to gosh, so no interactive startup can now be achieved using: $ java -Dgosh.args=--nointeractive bin/felix.jar It is no longer necessary to specify a dummy command like '-sc echo'. The gosh_profile is not run in non-interactive mode (so the gogo banner will not be displayed). However, new sessions created by telnet or ssh, will be interactive and thus run gosh_profile and show gogo banner. > [Gogo] It should be easier to start Gogo shell non-interactively > > > Key: FELIX-2661 > URL: https://issues.apache.org/jira/browse/FELIX-2661 > Project: Felix > Issue Type: Improvement > Components: Gogo Shell >Affects Versions: gogo-0.6.1 >Reporter: Richard S. Hall >Assignee: Derek Baum > Fix For: gogo-0.8.0 > > > To start the Gogo shell non-interactively, you have to specify a dummy > command and tell it not to shutdown in its configuration...something like > this: > gosh.args=--noshutdown -c noop=true > This is not necessarily the most straightforward approach and it also results > in the gosh_profile being executed and the MOTD being displayed, which > doesn't really make sense in the non-interactive use case. > It seems like it would be better to have an explicit flag to tell the Gogo > shell to start up non-interactively (e.g., --noninteractive), which would > also imply not shutting down, but wouldn't require a dummy command, nor > execute the gosh_profile. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2661) [Gogo] It should be easier to start Gogo shell non-interactively
[ https://issues.apache.org/jira/browse/FELIX-2661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12921021#action_12921021 ] Derek Baum commented on FELIX-2661: --- > It is not clear that "-i" is a good alias for "--nointeractive"... aliases are a single letter, so -n would be ambiguous with --noshutdown. Often CAPS are used for single letter inverse options (-I), but in this case I don't think that there's any need for an alias. Aliases are generally used to save interactive typing. The full long option name is preferred in scripts as it is self-documenting, rather than wondering what the -i or -ni option does. Long options can be abbreviated to their shortest unambiguous form, e.g. --noi and --nos. So shall we just remove the -i alias for --nointeractive? > [Gogo] It should be easier to start Gogo shell non-interactively > > > Key: FELIX-2661 > URL: https://issues.apache.org/jira/browse/FELIX-2661 > Project: Felix > Issue Type: Improvement > Components: Gogo Shell >Affects Versions: gogo-0.6.1 >Reporter: Richard S. Hall >Assignee: Derek Baum > Fix For: gogo-0.8.0 > > > To start the Gogo shell non-interactively, you have to specify a dummy > command and tell it not to shutdown in its configuration...something like > this: > gosh.args=--noshutdown -c noop=true > This is not necessarily the most straightforward approach and it also results > in the gosh_profile being executed and the MOTD being displayed, which > doesn't really make sense in the non-interactive use case. > It seems like it would be better to have an explicit flag to tell the Gogo > shell to start up non-interactively (e.g., --noninteractive), which would > also imply not shutting down, but wouldn't require a dummy command, nor > execute the gosh_profile. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2661) [Gogo] It should be easier to start Gogo shell non-interactively
[ https://issues.apache.org/jira/browse/FELIX-2661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12921062#action_12921062 ] Derek Baum commented on FELIX-2661: --- OK -i alias removed. > [Gogo] It should be easier to start Gogo shell non-interactively > > > Key: FELIX-2661 > URL: https://issues.apache.org/jira/browse/FELIX-2661 > Project: Felix > Issue Type: Improvement > Components: Gogo Shell >Affects Versions: gogo-0.6.1 >Reporter: Richard S. Hall >Assignee: Derek Baum > Fix For: gogo-0.8.0 > > > To start the Gogo shell non-interactively, you have to specify a dummy > command and tell it not to shutdown in its configuration...something like > this: > gosh.args=--noshutdown -c noop=true > This is not necessarily the most straightforward approach and it also results > in the gosh_profile being executed and the MOTD being displayed, which > doesn't really make sense in the non-interactive use case. > It seems like it would be better to have an explicit flag to tell the Gogo > shell to start up non-interactively (e.g., --noninteractive), which would > also imply not shutting down, but wouldn't require a dummy command, nor > execute the gosh_profile. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-2468) [gogo] CharSequence types are converted to String
[ https://issues.apache.org/jira/browse/FELIX-2468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum resolved FELIX-2468. --- Resolution: Cannot Reproduce works fine in release gogo-0.6.1 > [gogo] CharSequence types are converted to String > - > > Key: FELIX-2468 > URL: https://issues.apache.org/jira/browse/FELIX-2468 > Project: Felix > Issue Type: Bug > Components: Gogo Runtime >Affects Versions: gogo-0.6.0 >Reporter: Derek Baum >Assignee: Derek Baum >Priority: Minor > Fix For: gogo-0.8.0 > > > gogo now allows creation of a StringBuilder, but when it is accessed it is > converted to String > g! b = new StringBuilder > g! $b append > gogo: IllegalArgumentException: Cannot coerce append() to any of [] > g! c = $b > g! set > null0 null > String SCOPE gogo:* > String _ > StringBuilder b > String c > Closure e $exception printStackTrace > String prompt g! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2724) loadclass command not available until some other command is added
[
https://issues.apache.org/jira/browse/FELIX-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12970591#action_12970591
]
Derek Baum commented on FELIX-2724:
---
This is the expected behaviour for gogo.
loadClass is a method on Bundle, which is not installed by default.
The 'type' command shows this:
g! type loadclass
type: loadclass not found.
false
The command:
addcommand b (bundle 0)
creates a new command group 'b' and adds all the methods on the System bundle -
including loadClass
which explicitly makes the loadclass available, as shown by the 'type' command:
g! type loadclass
loadclass is Class b:loadclass(String)
true
If you want these commands available by default, you can add your own
gosh_profile - the default one is embedded in the gogo.shell bundle:
# default gosh_profile
# only read if etc/gosh_profile doesn't exist relative to the System property
# gosh.home or failing that the current directory.
# catch all exceptions from this script to avoid it aborting startup
try {
# ensure gogo commands are found first
SCOPE = gogo:*
# add methods on BundleContext object as commands
#addcommand context ${.context} (${.context} class)
# bug: above invokes (String, Object, String) instead of (String, Object,
Class)
addcommand context ${.context}
# add methods on System object as commands
addcommand system ((${.context} bundle 0) loadclass java.lang.System)
# alias to print full stack trace
e = { $exception printStackTrace }
## disable console auto-formatting of each result
# you will then need to explicitly use the 'format' command
# to print the result of commands that don't write to stdout.
#.Gogo.format = false
## disable printing the formatted result of a command into pipelines
#.Format.Pipe = false
# set prompt
prompt = 'g! '
# print welcome message
cat ($0 resolve motd)
} {
echo "$0: ERROR: $exception"
}
You can see this script adds methods on the BundleContext to the context: scope
and methods on the System class to the system: scope.
To add your own gosh_profile, put in in etc/gosh_profile relative to the
current directory, or set the System property gosh.home and put it in
${posh.home}/etc. I need to improve profile handling, so that something like
~/.gosh/goshrc is read automatically (if it exists) like in bash.
> loadclass command not available until some other command is added
> -
>
> Key: FELIX-2724
> URL: https://issues.apache.org/jira/browse/FELIX-2724
> Project: Felix
> Issue Type: Bug
> Components: Gogo Shell
>Affects Versions: gogo-0.6.1
>Reporter: Sahoo
>
> ss141...@sahoo:~/software/felix-framework-3.0.6$ java -jar bin/felix.jar
>
> Welcome to Apache Felix Gogo
> g! loadclass
> gogo: CommandNotFoundException: Command not found: loadclass
> g! addcommand b (bundle 0)
> g! loadclass
> gogo: IllegalArgumentException: Cannot coerce loadclass() to any of [(String)]
> As you can see from the above output, first time I tried loadclass command,
> it was not available, but second time it was. I have only default felix
> bundles installed.
> g! lb
> START LEVEL 1
>ID|State |Level|Name
> 0|Active |0|System Bundle (3.0.6)
> 1|Active |1|Apache Felix Bundle Repository (1.6.2)
> 2|Active |1|Apache Felix Gogo Command (0.6.1)
> 3|Active |1|Apache Felix Gogo Runtime (0.6.1)
> 4|Active |1|Apache Felix Gogo Shell (0.6.1)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2768) HttpContext.handleSecurity returns SC_FORBIDDEN unless response is comitted
HttpContext.handleSecurity returns SC_FORBIDDEN unless response is comitted
---
Key: FELIX-2768
URL: https://issues.apache.org/jira/browse/FELIX-2768
Project: Felix
Issue Type: Bug
Components: HTTP Service
Reporter: Derek Baum
The JavaDoc for HttpContext.handleSecurity states:
* If the request requires authentication and the Authorization header
in
* the request is missing or not acceptable, then this method should
set the
* WWW-Authenticate header in the response object, set the status in the
* response object to Unauthorized(401) and return false
So the following implementation of handleSecurity() should cause an
UNAUTHORIZED response:
response.setHeader("WWW-Authenticate", "BASIC realm=\"Secure
Moixa Energy Gateway\"");
response.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
return false;
This worked OK in org.apache.felix.http.jetty-1.0.1, but fails in
org.apache.felix.http.jetty-2.0.4, by always returning SC_FORBIDDEN.
Examining the implementation:
org/apache/felix/http/base/internal/handler/ServletHandler.java:
if (!getContext().handleSecurity(req, res)) {
if (!res.isCommitted()) {
res.sendError(HttpServletResponse.SC_FORBIDDEN);
}
}
which means that SC_FORBIDDEN is always returned, unless the response is
committed.
In order to commit the response, response.flushBuffer() must be called in the
handleSecurity() implementation after setting the response code to
unauthorized. Howver, the JavaDoc for HttpContext does not indicate that it is
necessary to commit the response.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2768) HttpContext.handleSecurity returns SC_FORBIDDEN unless response is comitted
[
https://issues.apache.org/jira/browse/FELIX-2768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12979114#action_12979114
]
Derek Baum commented on FELIX-2768:
---
I've only come across this recently (since switching to 2.0.4). Incidentally,
it took me a while to find the correct source code, since there's an http.jetty
directory under the felix trunk, while the code for http.jetty is just under
the http directory.
Yes, it looks like the change you suggest would resolve this problem.
> HttpContext.handleSecurity returns SC_FORBIDDEN unless response is comitted
> ---
>
> Key: FELIX-2768
> URL: https://issues.apache.org/jira/browse/FELIX-2768
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http-2.0.4
>Reporter: Derek Baum
>
> The JavaDoc for HttpContext.handleSecurity states:
>* If the request requires authentication and the Authorization header
> in
>* the request is missing or not acceptable, then this method should
> set the
>* WWW-Authenticate header in the response object, set the status in the
>* response object to Unauthorized(401) and return false
> So the following implementation of handleSecurity() should cause an
> UNAUTHORIZED response:
> response.setHeader("WWW-Authenticate", "BASIC realm=\"Secure
> Moixa Energy Gateway\"");
> response.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
> return false;
> This worked OK in org.apache.felix.http.jetty-1.0.1, but fails in
> org.apache.felix.http.jetty-2.0.4, by always returning SC_FORBIDDEN.
> Examining the implementation:
> org/apache/felix/http/base/internal/handler/ServletHandler.java:
> if (!getContext().handleSecurity(req, res)) {
> if (!res.isCommitted()) {
> res.sendError(HttpServletResponse.SC_FORBIDDEN);
> }
> }
> which means that SC_FORBIDDEN is always returned, unless the response is
> committed.
> In order to commit the response, response.flushBuffer() must be called in the
> handleSecurity() implementation after setting the response code to
> unauthorized. Howver, the JavaDoc for HttpContext does not indicate that it
> is necessary to commit the response.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1946) jetty http service issues 'started' message when disabled
[ https://issues.apache.org/jira/browse/FELIX-1946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum closed FELIX-1946. - > jetty http service issues 'started' message when disabled > - > > Key: FELIX-1946 > URL: https://issues.apache.org/jira/browse/FELIX-1946 > Project: Felix > Issue Type: Bug > Components: HTTP Service >Affects Versions: http-2.0.4 >Reporter: Derek Baum >Assignee: Felix Meschberger >Priority: Minor > Fix For: http-2.0.6 > > > I want to configure the felix jetty http service using config admin, so I set > the following properties to stop it from starting automatically: > org.osgi.service.http.port = -1 > org.apache.felix.http.enable = false > However, when the bundle is activated, it still reports that it has started: > % [INFO] Started jetty 6.1.x at port -1 > A 'Jetty HTTP Service' thread is actually started, but as http is not > enabled, no http server connector is created. > The above 'Started' message should not appear when http (and https) are > disabled, and it would be good if the 'Jetty HTTP Service' was not created > until the service is enabled using config admin, for example: > % setpid org.apache.felix.http org.osgi.service.http.port==1234 > org.apache.felix.http.enable==true > % [INFO] Started jetty 6.1.x at port 1234 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2772) setting http.port=-1 should disable service rather than throw exception
setting http.port=-1 should disable service rather than throw exception --- Key: FELIX-2772 URL: https://issues.apache.org/jira/browse/FELIX-2772 Project: Felix Issue Type: Improvement Components: HTTP Service Reporter: Derek Baum Priority: Minor I want to stop http.jetty from starting automatically, as I want to ensure the correct port is first explicitly configured using config admin. I can currently do this by setting org.apache.felix.http.enable=false, but this then complicates starting the service, as I have to set both http.enable=true and http.port=PORT It would be useful if setting http.port=-1 effectively disabled the service, then just by using config admin to set a valid port the service would start. Currently setting http.port=-1 results in the following exception: [WARNING] failed selectchannelconnec...@0.0.0.0:-1: java.lang.IllegalArgumentException: port out of range:-1 [WARNING] failed ser...@1f195fc: java.lang.IllegalArgumentException: port out of range:-1 [ERROR] Exception while initializing Jetty. java.lang.IllegalArgumentException: port out of range:-1 at java.net.InetSocketAddress.(InetSocketAddress.java:83) The Equinox http service is disabled if http.port=-1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-2772) setting http.port=-1 should disable service rather than throw exception
[ https://issues.apache.org/jira/browse/FELIX-2772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum closed FELIX-2772. - great! thanks for resolving this so quickly. > setting http.port=-1 should disable service rather than throw exception > --- > > Key: FELIX-2772 > URL: https://issues.apache.org/jira/browse/FELIX-2772 > Project: Felix > Issue Type: Improvement > Components: HTTP Service >Affects Versions: http-2.0.4 >Reporter: Derek Baum >Assignee: Felix Meschberger >Priority: Minor > Fix For: http-2.0.6 > > > I want to stop http.jetty from starting automatically, as I want to ensure > the correct port is first explicitly configured using config admin. > I can currently do this by setting org.apache.felix.http.enable=false, but > this then complicates starting the service, as I have to set both > http.enable=true and http.port=PORT > It would be useful if setting http.port=-1 effectively disabled the service, > then just by using config admin to set a valid port the service would start. > Currently setting http.port=-1 results in the following exception: > [WARNING] failed selectchannelconnec...@0.0.0.0:-1: > java.lang.IllegalArgumentException: port out of range:-1 > [WARNING] failed ser...@1f195fc: java.lang.IllegalArgumentException: port out > of range:-1 > [ERROR] Exception while initializing Jetty. > java.lang.IllegalArgumentException: port out of range:-1 > at java.net.InetSocketAddress.(InetSocketAddress.java:83) > The Equinox http service is disabled if http.port=-1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-2767) gogo telnet IP address
[ https://issues.apache.org/jira/browse/FELIX-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum resolved FELIX-2767. --- Resolution: Fixed I've applied your patch. Although this is a trivial telnetd implementation, this change brings it into line with the Remote Shell, which only listens on 127.0.0.1 by default, which is good for security as it doesn't provide password support. To get the old behaviour, i.e. listening on all interfaces, specify: g! telnetd --ip=0 start > gogo telnet IP address > -- > > Key: FELIX-2767 > URL: https://issues.apache.org/jira/browse/FELIX-2767 > Project: Felix > Issue Type: New Feature > Components: Gogo Shell >Affects Versions: gogo-0.6.1 >Reporter: Arjun Panday >Priority: Minor > Attachments: Telnet.java > > > I would need to specify the IP address on which gogo telnet is listening (in > addition to the port) > Please find attached a proposed patch. > /arjun -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2816) dependency manager calls init() twice
dependency manager calls init() twice
-
Key: FELIX-2816
URL: https://issues.apache.org/jira/browse/FELIX-2816
Project: Felix
Issue Type: Bug
Components: Dependency Manager
Reporter: Derek Baum
Log messages are placed at the beginning of the component lifecycle methods
(init, start, stop, destroy).
The number is the hashCode, which shows that init() is called twice on the same
Object, without intervening stop() or destroy():
[Debug] [ ] MyServlet 1397120162 init: update=60
[Debug] [ ] MyServlet 1397120162 start: endpoint=/myservlet period=60
history=null
[Debug] [ ] MyServlet 1397120162 init: update=60
[Debug] [ ] MyServlet add: gx2
[Debug] [ ] MyServlet add: denzil
The component is created as follows:
manager.add(createComponent()
.setImplementation(MyServlet.class)
.add(createConfigurationDependency()
.setPropagate(true)
.setPid(PID))
.add(createServiceDependency()
.setService(HttpService.class).setRequired(true))
.add(createServiceDependency()
.setService(UserAdmin.class).setRequired(true))
.add(createServiceDependency()
.setService(MyStateStore.class).setRequired(false)
.setCallbacks("addStore",
"removeStore"))
.add(createServiceDependency()
.setService(HistoryService.class).setRequired(false))
.add(createServiceDependency()
.setService(LogService.class).setRequired(false))
);
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (FELIX-2870) ConcurrentModificationException in gogo runtime
ConcurrentModificationException in gogo runtime --- Key: FELIX-2870 URL: https://issues.apache.org/jira/browse/FELIX-2870 Project: Felix Issue Type: Bug Components: Gogo Runtime Affects Versions: gogo-0.6.1 Reporter: Derek Baum Assignee: Derek Baum Priority: Minor java.util.ConcurrentModificationException at java.util.LinkedHashMap$LinkedHashIterator.nextEntry(LinkedHashMap.java:373) at java.util.LinkedHashMap$EntryIterator.next(LinkedHashMap.java:392) at java.util.LinkedHashMap$EntryIterator.next(LinkedHashMap.java:391) at org.apache.felix.gogo.runtime.CommandProcessorImpl.getCommand(CommandProcessorImpl.java:119) at org.apache.felix.gogo.runtime.CommandSessionImpl.get(CommandSessionImpl.java:144) at org.apache.felix.gogo.runtime.Closure.get(Closure.java:602) at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:438) at org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:395) at org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108) at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183) at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120) at org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:89) at org.apache.felix.gogo.shell.Activator.run(Activator.java:75) at java.lang.Thread.run(Thread.java:680) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (FELIX-2870) ConcurrentModificationException in gogo runtime
[ https://issues.apache.org/jira/browse/FELIX-2870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum resolved FELIX-2870. --- Resolution: Fixed Fix Version/s: gogo.runtime-0.10.0 synchronize access to commands. > ConcurrentModificationException in gogo runtime > --- > > Key: FELIX-2870 > URL: https://issues.apache.org/jira/browse/FELIX-2870 > Project: Felix > Issue Type: Bug > Components: Gogo Runtime >Affects Versions: gogo.runtime-0.8.0 >Reporter: Derek Baum >Assignee: Derek Baum >Priority: Minor > Fix For: gogo.runtime-0.10.0 > > > java.util.ConcurrentModificationException >at > java.util.LinkedHashMap$LinkedHashIterator.nextEntry(LinkedHashMap.java:373) >at java.util.LinkedHashMap$EntryIterator.next(LinkedHashMap.java:392) >at java.util.LinkedHashMap$EntryIterator.next(LinkedHashMap.java:391) >at > org.apache.felix.gogo.runtime.CommandProcessorImpl.getCommand(CommandProcessorImpl.java:119) >at > org.apache.felix.gogo.runtime.CommandSessionImpl.get(CommandSessionImpl.java:144) >at org.apache.felix.gogo.runtime.Closure.get(Closure.java:602) >at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:438) >at > org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:395) >at org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108) >at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183) >at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120) >at > org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:89) >at org.apache.felix.gogo.shell.Activator.run(Activator.java:75) >at java.lang.Thread.run(Thread.java:680) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-2924) bundle stop hangs for http-2.2.0 in felix-3.2.0
bundle stop hangs for http-2.2.0 in felix-3.2.0 --- Key: FELIX-2924 URL: https://issues.apache.org/jira/browse/FELIX-2924 Project: Felix Issue Type: Bug Components: Framework Affects Versions: framework-3.2.0 Environment: Mac OSX java version "1.6.0_24" Reporter: Derek Baum stopping http jetty 2.2.0 hangs framework. it is fine with http jetty 2.0.4 in framework 3.2.0 or with http jetty 2.2.0 in framework 3.0.9 $ cd felix-framework-3.2.0 $ java -jar bin/felix.jar Welcome to Apache Felix Gogo g! [INFO] Started jetty 6.1.x at port(s) HTTP:8080 g! lb START LEVEL 1 ID|State |Level|Name 0|Active |0|System Bundle (3.2.0) 1|Active |1|Apache Felix Bundle Repository (1.6.2) 2|Active |1|Apache Felix Gogo Command (0.8.0) 3|Active |1|Apache Felix Gogo Runtime (0.8.0) 4|Active |1|Apache Felix Gogo Shell (0.8.0) 5|Active |1|Apache Felix Http Jetty (2.2.0) g! stop 5 [ HANGS HERE ] THREAD DUMP: ^\2011-04-20 19:07:35 Full thread dump Java HotSpot(TM) 64-Bit Server VM (19.1-b02-334 mixed mode): "Timer-0" daemon prio=5 tid=102a5f000 nid=0x10ac9c000 in Object.wait() [10ac9b000] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <7f30aa0d0> (a java.util.TaskQueue) at java.util.TimerThread.mainLoop(Timer.java:509) - locked <7f30aa0d0> (a java.util.TaskQueue) at java.util.TimerThread.run(Timer.java:462) "Poller SunPKCS11-Darwin" daemon prio=1 tid=1019c0800 nid=0x10ab99000 waiting on condition [10ab98000] java.lang.Thread.State: TIMED_WAITING (sleeping) at java.lang.Thread.sleep(Native Method) at sun.security.pkcs11.SunPKCS11$TokenPoller.run(SunPKCS11.java:692) at java.lang.Thread.run(Thread.java:680) "918201446@qtp-896472140-0" prio=5 tid=1029cf800 nid=0x10a93c000 in Object.wait() [10a93b000] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <7f42b2040> (a org.mortbay.thread.QueuedThreadPool$PoolThread) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:626) - locked <7f42b2040> (a org.mortbay.thread.QueuedThreadPool$PoolThread) "Jetty HTTP Service" daemon prio=5 tid=1029cd000 nid=0x10a839000 in Object.wait() [10a837000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <7f437f998> (a [Ljava.lang.Object;) at java.lang.Object.wait(Object.java:485) at org.apache.felix.framework.Felix.acquireBundleLock(Felix.java:4930) - locked <7f437f998> (a [Ljava.lang.Object;) at org.apache.felix.framework.Felix.removeServiceListener(Felix.java:2844) at org.apache.felix.framework.BundleContextImpl.removeServiceListener(BundleContextImpl.java:256) at org.osgi.util.tracker.ServiceTracker.close(ServiceTracker.java:391) - locked <7f4344008> (a org.apache.felix.http.base.internal.listener.HttpSessionAttributeListenerManager) at org.apache.felix.http.base.internal.HttpServiceController.unregister(HttpServiceController.java:144) at org.apache.felix.http.base.internal.DispatcherServlet.destroy(DispatcherServlet.java:54) at org.mortbay.jetty.servlet.ServletHolder.destroyInstance(ServletHolder.java:318) at org.mortbay.jetty.servlet.ServletHolder.doStop(ServletHolder.java:289) at org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:76) - locked <7f42f4cb0> (a java.lang.Object) at org.mortbay.jetty.servlet.ServletHandler.doStop(ServletHandler.java:174) - locked <7f42f49c8> (a org.mortbay.jetty.servlet.ServletHandler) at org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:76) - locked <7f42f4a38> (a java.lang.Object) at org.mortbay.jetty.handler.HandlerWrapper.doStop(HandlerWrapper.java:142) at org.mortbay.jetty.servlet.SessionHandler.doStop(SessionHandler.java:125) at org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:76) - locked <7f42f51a8> (a java.lang.Object) at org.mortbay.jetty.handler.HandlerWrapper.doStop(HandlerWrapper.java:142) at org.mortbay.jetty.handler.ContextHandler.doStop(ContextHandler.java:591) at org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:76) - locked <7f42f4890> (a java.lang.Object) at org.mortbay.jetty.handler.HandlerWrapper.doStop(HandlerWrapper.java:142) at org.mortbay.jetty.Server.doStop(Server.java:283) at org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:76) - locked <7f42f1d30> (a java.lang.Object) at org.a
[jira] [Created] (FELIX-2927) [gogo] coercion mechanism invokes foo(String) instead of foo(int) - even with explicit int argument
[gogo] coercion mechanism invokes foo(String) instead of foo(int) - even with explicit int argument --- Key: FELIX-2927 URL: https://issues.apache.org/jira/browse/FELIX-2927 Project: Felix Issue Type: Bug Components: Gogo Runtime Affects Versions: gogo.runtime-0.8.0 Reporter: Derek Baum Assignee: Derek Baum Equinox 3.7.M6 supports OSGi R4.3 which adds the overloaded method BundleContext.getBundle(String). This causes gogo startup to fail, as it expects to invoke getBundle(int) but actually invokes getBundle(String). Prior to R4.3, the gogo command: bundle 1 resulted in the String "1" being coerced into a long, so that getBundle(long) could be invoked. Now that getBundle(String) exists, the result depends on the order that methods are returned from Class.getMethods(), which varies between platforms: On Mac java version "1.6.0_24": g! type bundle bundle is Bundle context:bundle(long) bundle is Bundle context:bundle() bundle is Bundle context:bundle(String) On Windows 2003 server, java version "1.6.0_24": g! type bundle bundle is Bundle context:bundle() bundle is Bundle context:bundle(String) bundle is Bundle context:bundle(long) The first "exact" match wins, where "exact" just means that all supplied arguments are used. On the Mac, getBundle(long) still wins, but on Windows getBundle(String) wins and the gogo startup scripts fails. What's worse, is that even when you realise what is happening, it is still not possible to invoke getBundle(long): g! 1L = new Long 1 g! bundle $1L because in this case the long is coerced to a String to invoke get Bundle(String) and the getBundle(long) method is ignored. There are at least two problems here: 1. the gogo coercion mechanism simply invokes the first method it can, regardless of whether any arguments needed to be converted. It should instead try to score each method, perhaps adding to the score each time an argument needs to be converted, then it could invoke the method with the lowest score. However, there may still be occasions when two methods have the same score and gogo needs to behave deterministically and allow either method to be invoked by supplying less ambiguous arguments. 2. all arguments in gogo start out as Strings, which make it awkward to prefer a method that takes an integer: for example: g! bundle (new Long 1) getBundle(long) is the most likely target method, but gogo does not any syntax to indicate that arguments should be treated as numbers rather than Strings. One possibility would be to recognize numbers in gogo's Tokenizer similar to the way that true/false are handled: g! t = true true g! tt = 'true' true g! set t Boolean t true String tt true The above shows that the bare word: true is tokenized as a Boolean, where as the quoted word 'true' is tokenized as a String. So bare numbers could be tokenized as Numbers, and the existing coercion mechanism would convert them back to Strings as needed; alternative by quoting something that looks like a number, you force it to be tokenized as a String. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FELIX-2924) bundle stop hangs for http-2.2.0 in felix-3.2.0
[ https://issues.apache.org/jira/browse/FELIX-2924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum closed FELIX-2924. - patch fix on trunk resolves issue. Thanks > bundle stop hangs for http-2.2.0 in felix-3.2.0 > --- > > Key: FELIX-2924 > URL: https://issues.apache.org/jira/browse/FELIX-2924 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-3.2.0 > Environment: Mac OSX java version "1.6.0_24" >Reporter: Derek Baum >Assignee: Richard S. Hall > Fix For: framework-3.2.1 > > > stopping http jetty 2.2.0 hangs framework. > it is fine with http jetty 2.0.4 in framework 3.2.0 > or with http jetty 2.2.0 in framework 3.0.9 > $ cd felix-framework-3.2.0 > $ java -jar bin/felix.jar > > Welcome to Apache Felix Gogo > g! [INFO] Started jetty 6.1.x at port(s) HTTP:8080 > g! lb > START LEVEL 1 >ID|State |Level|Name > 0|Active |0|System Bundle (3.2.0) > 1|Active |1|Apache Felix Bundle Repository (1.6.2) > 2|Active |1|Apache Felix Gogo Command (0.8.0) > 3|Active |1|Apache Felix Gogo Runtime (0.8.0) > 4|Active |1|Apache Felix Gogo Shell (0.8.0) > 5|Active |1|Apache Felix Http Jetty (2.2.0) > g! stop 5 > [ HANGS HERE ] > THREAD DUMP: > ^\2011-04-20 19:07:35 > Full thread dump Java HotSpot(TM) 64-Bit Server VM (19.1-b02-334 mixed mode): > "Timer-0" daemon prio=5 tid=102a5f000 nid=0x10ac9c000 in Object.wait() > [10ac9b000] >java.lang.Thread.State: TIMED_WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > - waiting on <7f30aa0d0> (a java.util.TaskQueue) > at java.util.TimerThread.mainLoop(Timer.java:509) > - locked <7f30aa0d0> (a java.util.TaskQueue) > at java.util.TimerThread.run(Timer.java:462) > "Poller SunPKCS11-Darwin" daemon prio=1 tid=1019c0800 nid=0x10ab99000 waiting > on condition [10ab98000] >java.lang.Thread.State: TIMED_WAITING (sleeping) > at java.lang.Thread.sleep(Native Method) > at sun.security.pkcs11.SunPKCS11$TokenPoller.run(SunPKCS11.java:692) > at java.lang.Thread.run(Thread.java:680) > "918201446@qtp-896472140-0" prio=5 tid=1029cf800 nid=0x10a93c000 in > Object.wait() [10a93b000] >java.lang.Thread.State: TIMED_WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > - waiting on <7f42b2040> (a > org.mortbay.thread.QueuedThreadPool$PoolThread) > at > org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:626) > - locked <7f42b2040> (a > org.mortbay.thread.QueuedThreadPool$PoolThread) > "Jetty HTTP Service" daemon prio=5 tid=1029cd000 nid=0x10a839000 in > Object.wait() [10a837000] >java.lang.Thread.State: WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > - waiting on <7f437f998> (a [Ljava.lang.Object;) > at java.lang.Object.wait(Object.java:485) > at org.apache.felix.framework.Felix.acquireBundleLock(Felix.java:4930) > - locked <7f437f998> (a [Ljava.lang.Object;) > at > org.apache.felix.framework.Felix.removeServiceListener(Felix.java:2844) > at > org.apache.felix.framework.BundleContextImpl.removeServiceListener(BundleContextImpl.java:256) > at org.osgi.util.tracker.ServiceTracker.close(ServiceTracker.java:391) > - locked <7f4344008> (a > org.apache.felix.http.base.internal.listener.HttpSessionAttributeListenerManager) > at > org.apache.felix.http.base.internal.HttpServiceController.unregister(HttpServiceController.java:144) > at > org.apache.felix.http.base.internal.DispatcherServlet.destroy(DispatcherServlet.java:54) > at > org.mortbay.jetty.servlet.ServletHolder.destroyInstance(ServletHolder.java:318) > at > org.mortbay.jetty.servlet.ServletHolder.doStop(ServletHolder.java:289) > at > org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:76) > - locked <7f42f4cb0> (a java.lang.Object) > at > org.mortbay.jetty.servlet.ServletHandler.doStop(ServletHandler.java:174) > - locked <7f42f49c8> (a org.mortbay.jetty.servlet.ServletHandler) > at > org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:76) > - locked <7f42f4a38> (a java.lang.Object) > at > org.mortbay.jetty.handler.HandlerWrapper.doStop(HandlerWrapper.java:142) > at > org.mortbay.jetty.servlet.SessionHandler.doStop(SessionHandler.java:125) > at > org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:76) > - locked <7f42f51a8> (a java.lang.Object) > at > org.mortbay.jetty.handler.HandlerWrapper.doStop(HandlerWrapper.java:142) > at > org.mortbay
[jira] [Commented] (FELIX-2894) Gogo does not handles options but not parameters
[
https://issues.apache.org/jira/browse/FELIX-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13045602#comment-13045602
]
Derek Baum commented on FELIX-2894:
---
The code currently committed to resolve this issue (has wrong issue id in
comment so is not listed in subversion commits tab)
r1086855 | pkriens | 2011-03-30 07:40:15 +0100 (Wed, 30 Mar 2011) | 1 line
FELIX-2984 Invalid handling of parameters (options were ok). It works now
and the tests are running but I am not confident this
code is correct yet. Will probably have to rewrite this.
causes another problem:
no error is generated if too many args are supplied, as long as the initial
args are ok
e.g. before this change, specifying too many args causes an error, as expected:
g! addcommand 1 2 3 4
gogo: IllegalArgumentException: Cannot coerce addcommand(String, String,
String, String) to any of [(String, Object, String), (String, Object), (String,
Object, Class)]
after this change, no error is issued:
g! addcommand 1 2 3 4
g!
> Gogo does not handles options but not parameters
>
>
> Key: FELIX-2894
> URL: https://issues.apache.org/jira/browse/FELIX-2894
> Project: Felix
> Issue Type: Bug
> Components: Gogo Runtime
>Reporter: Peter Kriens
>
> If you create a function with a parameter then the correct method cannot be
> found:
> public void xyz( @Parameter( names="-v", absentValue="absent") String string
> ) { return string; }
> This method is not found for xyz -v abc
> There were two bugs in the code:
> - annotation values can never be null but null was checked for the
> presentValue to see if it was not there.
> - After handling the parameters the new length of the command line was
> checked against the xargs. However, this still contained the parameter name +
> value. So the size was too high to match.
> I've added a check for the Parameter.UNSPECIFIED when checking the status of
> presentValue and I removed the check for the length of xargs, only types is
> relevant I think. However, might need some other pair of eyes
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Work started] (FELIX-2894) Gogo does not handles options but not parameters
[
https://issues.apache.org/jira/browse/FELIX-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on FELIX-2894 started by Derek Baum.
> Gogo does not handles options but not parameters
>
>
> Key: FELIX-2894
> URL: https://issues.apache.org/jira/browse/FELIX-2894
> Project: Felix
> Issue Type: Bug
> Components: Gogo Runtime
>Reporter: Peter Kriens
>Assignee: Derek Baum
>
> If you create a function with a parameter then the correct method cannot be
> found:
> public void xyz( @Parameter( names="-v", absentValue="absent") String string
> ) { return string; }
> This method is not found for xyz -v abc
> There were two bugs in the code:
> - annotation values can never be null but null was checked for the
> presentValue to see if it was not there.
> - After handling the parameters the new length of the command line was
> checked against the xargs. However, this still contained the parameter name +
> value. So the size was too high to match.
> I've added a check for the Parameter.UNSPECIFIED when checking the status of
> presentValue and I removed the check for the length of xargs, only types is
> relevant I think. However, might need some other pair of eyes
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (FELIX-2894) Gogo does not handles options but not parameters
[
https://issues.apache.org/jira/browse/FELIX-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Derek Baum reassigned FELIX-2894:
-
Assignee: Derek Baum
> Gogo does not handles options but not parameters
>
>
> Key: FELIX-2894
> URL: https://issues.apache.org/jira/browse/FELIX-2894
> Project: Felix
> Issue Type: Bug
> Components: Gogo Runtime
>Reporter: Peter Kriens
>Assignee: Derek Baum
>
> If you create a function with a parameter then the correct method cannot be
> found:
> public void xyz( @Parameter( names="-v", absentValue="absent") String string
> ) { return string; }
> This method is not found for xyz -v abc
> There were two bugs in the code:
> - annotation values can never be null but null was checked for the
> presentValue to see if it was not there.
> - After handling the parameters the new length of the command line was
> checked against the xargs. However, this still contained the parameter name +
> value. So the size was too high to match.
> I've added a check for the Parameter.UNSPECIFIED when checking the status of
> presentValue and I removed the check for the length of xargs, only types is
> relevant I think. However, might need some other pair of eyes
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-2894) Gogo does not handles options but not parameters
[
https://issues.apache.org/jira/browse/FELIX-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Derek Baum resolved FELIX-2894.
---
Resolution: Fixed
Fix Version/s: gogo.runtime-0.10.0
added new testcases for argument coercion, including Parameters.
Refactored Reflective.java to simplify code.
> Gogo does not handles options but not parameters
>
>
> Key: FELIX-2894
> URL: https://issues.apache.org/jira/browse/FELIX-2894
> Project: Felix
> Issue Type: Bug
> Components: Gogo Runtime
>Reporter: Peter Kriens
>Assignee: Derek Baum
> Fix For: gogo.runtime-0.10.0
>
>
> If you create a function with a parameter then the correct method cannot be
> found:
> public void xyz( @Parameter( names="-v", absentValue="absent") String string
> ) { return string; }
> This method is not found for xyz -v abc
> There were two bugs in the code:
> - annotation values can never be null but null was checked for the
> presentValue to see if it was not there.
> - After handling the parameters the new length of the command line was
> checked against the xargs. However, this still contained the parameter name +
> value. So the size was too high to match.
> I've added a check for the Parameter.UNSPECIFIED when checking the status of
> presentValue and I removed the check for the length of xargs, only types is
> relevant I think. However, might need some other pair of eyes
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-2927) [gogo] coercion mechanism invokes foo(String) instead of foo(int) - even with explicit int argument
[ https://issues.apache.org/jira/browse/FELIX-2927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum resolved FELIX-2927. --- Resolution: Fixed Fix Version/s: gogo.runtime-0.10.0 fixed by refactoring Reflective.java to give conversion cost for coercion. > [gogo] coercion mechanism invokes foo(String) instead of foo(int) - even with > explicit int argument > --- > > Key: FELIX-2927 > URL: https://issues.apache.org/jira/browse/FELIX-2927 > Project: Felix > Issue Type: Bug > Components: Gogo Runtime >Affects Versions: gogo.runtime-0.8.0 >Reporter: Derek Baum >Assignee: Derek Baum > Fix For: gogo.runtime-0.10.0 > > > Equinox 3.7.M6 supports OSGi R4.3 which adds the overloaded method > BundleContext.getBundle(String). > This causes gogo startup to fail, as it expects to invoke getBundle(int) but > actually invokes getBundle(String). > Prior to R4.3, the gogo command: bundle 1 > resulted in the String "1" being coerced into a long, so that getBundle(long) > could be invoked. > Now that getBundle(String) exists, the result depends on the order that > methods are returned from Class.getMethods(), which varies between platforms: > On Mac java version "1.6.0_24": > g! type bundle > bundle is Bundle context:bundle(long) > bundle is Bundle context:bundle() > bundle is Bundle context:bundle(String) > On Windows 2003 server, java version "1.6.0_24": > g! type bundle > bundle is Bundle context:bundle() > bundle is Bundle context:bundle(String) > bundle is Bundle context:bundle(long) > The first "exact" match wins, where "exact" just means that all supplied > arguments are used. > On the Mac, getBundle(long) still wins, but on Windows getBundle(String) wins > and the gogo startup scripts fails. > What's worse, is that even when you realise what is happening, it is still > not possible to invoke getBundle(long): > g! 1L = new Long 1 > g! bundle $1L > because in this case the long is coerced to a String to invoke get > Bundle(String) and the getBundle(long) method is ignored. > There are at least two problems here: > 1. the gogo coercion mechanism simply invokes the first method it can, > regardless of whether any arguments needed to be converted. > It should instead try to score each method, perhaps adding to the score each > time an argument needs to be converted, > then it could invoke the method with the lowest score. > However, there may still be occasions when two methods have the same score > and gogo needs to behave deterministically > and allow either method to be invoked by supplying less ambiguous arguments. > 2. all arguments in gogo start out as Strings, which make it awkward to > prefer a method that takes an integer: > for example: g! bundle (new Long 1) > getBundle(long) is the most likely target method, but gogo does not any > syntax to indicate that arguments should be treated as numbers rather than > Strings. One possibility would be to recognize numbers in gogo's Tokenizer > similar to the way that true/false are handled: > g! t = true > true > g! tt = 'true' > true > g! set t > Boolean t true > String tt true > The above shows that the bare word: true is tokenized as a Boolean, where as > the quoted word 'true' is tokenized as a String. > So bare numbers could be tokenized as Numbers, and the existing coercion > mechanism would convert them back to Strings as needed; > alternative by quoting something that looks like a number, you force it to be > tokenized as a String. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-3001) [gogo] help command throws ClassCastException if any osgi.command.function service property is not String[]
[gogo] help command throws ClassCastException if any osgi.command.function service property is not String[] --- Key: FELIX-3001 URL: https://issues.apache.org/jira/browse/FELIX-3001 Project: Felix Issue Type: Bug Components: Gogo Command Reporter: Derek Baum Priority: Minor java.lang.ClassCastException: java.lang.String cannot be cast to [Ljava.lang.String; at org.apache.felix.gogo.command.Basic.getCommands(Basic.java:384) at org.apache.felix.gogo.command.Basic.help(Basic.java:211) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.felix.gogo.runtime.Reflective.method(Reflective.java:136) at -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (FELIX-3001) [gogo] help command throws ClassCastException if any osgi.command.function service property is not String[]
[ https://issues.apache.org/jira/browse/FELIX-3001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum reassigned FELIX-3001: - Assignee: Derek Baum > [gogo] help command throws ClassCastException if any osgi.command.function > service property is not String[] > --- > > Key: FELIX-3001 > URL: https://issues.apache.org/jira/browse/FELIX-3001 > Project: Felix > Issue Type: Bug > Components: Gogo Command >Reporter: Derek Baum >Assignee: Derek Baum >Priority: Minor > > java.lang.ClassCastException: java.lang.String cannot be cast to > [Ljava.lang.String; >at org.apache.felix.gogo.command.Basic.getCommands(Basic.java:384) >at org.apache.felix.gogo.command.Basic.help(Basic.java:211) >at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) >at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) >at java.lang.reflect.Method.invoke(Unknown Source) >at > org.apache.felix.gogo.runtime.Reflective.method(Reflective.java:136) >at -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Work started] (FELIX-3001) [gogo] help command throws ClassCastException if any osgi.command.function service property is not String[]
[ https://issues.apache.org/jira/browse/FELIX-3001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on FELIX-3001 started by Derek Baum. > [gogo] help command throws ClassCastException if any osgi.command.function > service property is not String[] > --- > > Key: FELIX-3001 > URL: https://issues.apache.org/jira/browse/FELIX-3001 > Project: Felix > Issue Type: Bug > Components: Gogo Command >Reporter: Derek Baum >Assignee: Derek Baum >Priority: Minor > > java.lang.ClassCastException: java.lang.String cannot be cast to > [Ljava.lang.String; >at org.apache.felix.gogo.command.Basic.getCommands(Basic.java:384) >at org.apache.felix.gogo.command.Basic.help(Basic.java:211) >at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) >at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) >at java.lang.reflect.Method.invoke(Unknown Source) >at > org.apache.felix.gogo.runtime.Reflective.method(Reflective.java:136) >at -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-3001) [gogo] help command throws ClassCastException if any osgi.command.function service property is not String[]
[ https://issues.apache.org/jira/browse/FELIX-3001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum resolved FELIX-3001. --- Resolution: Fixed > [gogo] help command throws ClassCastException if any osgi.command.function > service property is not String[] > --- > > Key: FELIX-3001 > URL: https://issues.apache.org/jira/browse/FELIX-3001 > Project: Felix > Issue Type: Bug > Components: Gogo Command >Reporter: Derek Baum >Assignee: Derek Baum >Priority: Minor > > java.lang.ClassCastException: java.lang.String cannot be cast to > [Ljava.lang.String; >at org.apache.felix.gogo.command.Basic.getCommands(Basic.java:384) >at org.apache.felix.gogo.command.Basic.help(Basic.java:211) >at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) >at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) >at java.lang.reflect.Method.invoke(Unknown Source) >at > org.apache.felix.gogo.runtime.Reflective.method(Reflective.java:136) >at -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (FELIX-946) Code for new OSGi TSL proposal
[
https://issues.apache.org/jira/browse/FELIX-946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12712903#action_12712903
]
Derek Baum commented on FELIX-946:
--
I have been working with this code and have made several bug fixes:
I can supply these as a diff against shell.zip attached to this issue, or when
the code is loaded in SVN, I could raise issues against each of the bugs.
Here is a brief list of the fixes I've made:
./aQute/shell/osgi/OSGiCommands.java:// DWB1: osgi:each too
verbose (formats results to System.out)
./aQute/shell/osgi/OSGiCommands.java:// DWB2:
ClassNotFoundException should be caught in convert() method
./aQute/shell/osgi/OSGiShell.java: // DWB3:
dynamically load optional framework components to reduce dependencies
./aQute/shell/osgi/OSGiShell.java: // DWB4: get() with
trailing colon causes org.osgi.framework.InvalidSyntaxException
./aQute/shell/runtime/Closure.java: // DWB5:
session.err is not redirected when creating pipeline
./aQute/shell/runtime/Closure.java: // DWB6: add 'set
-x' trace feature if echo is set
./aQute/shell/runtime/Closure.java: // DWB7: removing
variable via 'execute("name=") throws OutOfBoundsException
./aQute/shell/runtime/CommandSessionImpl.java: // DWB8: throw
IllegatlStateException if session used after closed (as per rfc132)
./aQute/shell/runtime/CommandSessionImpl.java: // DWB9: there is no API to list
all variables: https://www.osgi.org/bugzilla/show_bug.cgi?id=49
./aQute/shell/runtime/CommandSessionImpl.java: // DWB10: add SCOPE support:
https://www.osgi.org/bugzilla/show_bug.cgi?id=51
./aQute/shell/runtime/CommandShellImpl.java: // DWB11: add removeCommand:
https://www.osgi.org/bugzilla/show_bug.cgi?id=49
./aQute/shell/runtime/CommandShellImpl.java: // DWB12: there is no API to
list commands: https://www.osgi.org/bugzilla/show_bug.cgi?id=49
./aQute/shell/runtime/CommandShellImpl.java: // DWB13: addCommand() fails
to add static methods (if target is Class)
./aQute/shell/runtime/Parser.java: // DWB14: parser
loops if // comment at start of program
./aQute/shell/runtime/Parser.java: // DWB15: allow
program to have trailing ';'
./aQute/shell/runtime/Pipe.java: // DWB16:
redirect System.err when creating pipe
./aQute/shell/runtime/Reflective.java: // DWB16: coerce()
doesn't support static methods
./aQute/shell/runtime/Reflective.java: // DWB17: coerce()
doesn't support static void main(String[]) in rfc132
./aQute/shell/runtime/Reflective.java: // DWB18: coerce()
doesn't extract cause from InvocationTargetException
./aQute/shell/runtime/Reflective.java: // DWB19: coerce()
won't add empty array to satisfy Object[] argument
./aQute/threadio/ThreadIOImpl.java: // DWB20: ThreadIO
should check and reset IO if something (e.g. jetty) overrides
> Code for new OSGi TSL proposal
> --
>
> Key: FELIX-946
> URL: https://issues.apache.org/jira/browse/FELIX-946
> Project: Felix
> Issue Type: New Feature
>Reporter: Peter Kriens
>Assignee: Marcel Offermans
>Priority: Trivial
> Attachments: shell.zip
>
>
> Source code donation for the OSGi Shell proposal
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-946) Code for new OSGi TSL proposal
[ https://issues.apache.org/jira/browse/FELIX-946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum updated FELIX-946: - Attachment: dwb.patch.gz attached patches mentioned in my previous comment. The patch was created by copying my changes over a fresh checkout of http://svn.apache.org/repos/asf/felix/trunk/gogo and then running 'svn diff'. The patched files are also annotated with my name 'derek' and the DWBx bug numbers mentioned in previous comment. I have just submitted my ICLA to secret...@apache.org > Code for new OSGi TSL proposal > -- > > Key: FELIX-946 > URL: https://issues.apache.org/jira/browse/FELIX-946 > Project: Felix > Issue Type: New Feature >Reporter: Peter Kriens >Assignee: Marcel Offermans >Priority: Trivial > Attachments: dwb.patch.gz, shell.zip > > > Source code donation for the OSGi Shell proposal -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
