[jira] [Closed] (FELIX-5349) Add ManagedServiceFactory to HTTP service
[ https://issues.apache.org/jira/browse/FELIX-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum closed FELIX-5349. - Tested locally and works for me. > Add ManagedServiceFactory to HTTP service > - > > Key: FELIX-5349 > URL: https://issues.apache.org/jira/browse/FELIX-5349 > Project: Felix > Issue Type: New Feature > Components: HTTP Service >Affects Versions: http.base-3.0.12, http.jetty-3.2.4 >Reporter: Derek Baum >Assignee: Carsten Ziegeler >Priority: Minor > Fix For: http.base-3.0.14, http.jetty-3.2.6, http.bridge-3.0.14 > > Attachments: factory.patch, factory2.patch > > > I need to run multiple HTTP services, with different configurations. > I was surprised to find that felix.http.jetty does not provide a > ManagedServiceFactory and so were others as indicated in this stack overflow > conversation: > http://stackoverflow.com/questions/20074211/osgi-http-bundle-bind-to-two-ports > I have experimented with creating a ManagedServiceFactory for the HTTP > service myself. It is difficult to do externally to the http.jetty bundle, as > it requires access to internal packages. > I have therefore created a small patch to revision 1760954 which adds a > ManagedServiceFactory, without changing any of the existing functionality of > the ManagedService. This allows multiple http.jetty instances to be > configured using WebConsole, fileinstall or other config admin clients. > I have also added a new configuration property: org.apache.felix.http.name, > which is added as a service property to the HTTP runtime instance. This makes > it easier to target a specific HTTP whiteboard service than filtering on the > port: > HTTP_WHITEBOARD_TARGET + "=(org.apache.felix.http.name=web1)" > I would be grateful if you would consider adding this functionality. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-5349) add ManagedServiceFactory to HTTP service
[ https://issues.apache.org/jira/browse/FELIX-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum updated FELIX-5349: -- Attachment: factory2.patch patch to revision 1761012 so that stopping jetty bundle also stops service instances created by factory. Also added synchronisation to factory methods. > add ManagedServiceFactory to HTTP service > - > > Key: FELIX-5349 > URL: https://issues.apache.org/jira/browse/FELIX-5349 > Project: Felix > Issue Type: New Feature > Components: HTTP Service >Affects Versions: http.base-3.0.12, http.jetty-3.2.4 >Reporter: Derek Baum >Assignee: Carsten Ziegeler >Priority: Minor > Fix For: http.base-3.0.14, http.jetty-3.2.6, http.bridge-3.0.14 > > Attachments: factory.patch, factory2.patch > > > I need to run multiple HTTP services, with different configurations. > I was surprised to find that felix.http.jetty does not provide a > ManagedServiceFactory and so were others as indicated in this stack overflow > conversation: > http://stackoverflow.com/questions/20074211/osgi-http-bundle-bind-to-two-ports > I have experimented with creating a ManagedServiceFactory for the HTTP > service myself. It is difficult to do externally to the http.jetty bundle, as > it requires access to internal packages. > I have therefore created a small patch to revision 1760954 which adds a > ManagedServiceFactory, without changing any of the existing functionality of > the ManagedService. This allows multiple http.jetty instances to be > configured using WebConsole, fileinstall or other config admin clients. > I have also added a new configuration property: org.apache.felix.http.name, > which is added as a service property to the HTTP runtime instance. This makes > it easier to target a specific HTTP whiteboard service than filtering on the > port: > HTTP_WHITEBOARD_TARGET + "=(org.apache.felix.http.name=web1)" > I would be grateful if you would consider adding this functionality. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (FELIX-5344) HTTP_WHITEBOARD_TARGET doesn't work reliably
[
https://issues.apache.org/jira/browse/FELIX-5344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Derek Baum closed FELIX-5344.
-
I have tested this and verify that it resolves the issue. Thanks. Derek
> HTTP_WHITEBOARD_TARGET doesn't work reliably
>
>
> Key: FELIX-5344
> URL: https://issues.apache.org/jira/browse/FELIX-5344
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http.base-3.0.12, http.jetty-3.2.4
>Reporter: Derek Baum
>Assignee: Carsten Ziegeler
> Fix For: http.base-3.0.14, http.jetty-3.2.6, http.bridge-3.0.14
>
>
> I am trying to use HTTP_WHITEBOARD_TARGET to match a specific http instance:
> (I'm actually experimenting with multiple http instances, but the problem
> occurs with a single instance).
> @Component(service = Servlet.class,
> property = {
> HttpWhiteboardConstants.HTTP_WHITEBOARD_TARGET +
> "=(org.osgi.service.http.port=)"
> })
> I am configuring http.jetty using config admin (via fileinstall)
> I have disabled automatic jetty startup using:
> org.apache.felix.http.enable=false
> Now I start jetty by dropping the file org.apache.felix.http.cfg into the
> fileinstall load directory:
> org.apache.felix.http.enable=true
> org.osgi.service.http.port=
> and my servlet is not always registered.
> This appears to be because WhiteboardManager.addWhiteboardService() is being
> called before the http service properties have been set.
> Here's the output of some debug I added to isMatchingService():
> XXXtarget =(org.osgi.service.http.port=) match=false
> XXXprop objectClass=[Ljava.lang.String;@292aebaf
> XXXprop osgi.http.service.id=[60]
> XXXprop service.bundleid=22
> XXXprop service.id=61
> XXXprop service.scope=singleton
> It doesn't contain any endpoint properties.
> To prove this is a timing issue, I stopped and started my web bundle, which
> then registered correctly. The corresponding debug is:
> XXXtarget =(org.osgi.service.http.port=) match=true
> XXXprop objectClass=[Ljava.lang.String;@292aebaf
> XXXprop org.apache.felix.http.enable=true
> XXXprop org.apache.felix.https.enable=false
> XXXprop org.osgi.service.http.port=
> XXXprop org.osgi.service.http.port.secure=8443
> XXXprop osgi.http.endpoint=[Ljava.lang.String;@1d1447fa
> XXXprop osgi.http.service.id=[60]
> XXXprop service.bundleid=22
> XXXprop service.id=61
> XXXprop service.scope=singleton
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-5349) add ManagedServiceFactory to HTTP service
[ https://issues.apache.org/jira/browse/FELIX-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15495640#comment-15495640 ] Derek Baum commented on FELIX-5349: --- I was just trying to keep the existing Activator behaviour, but yes, it should shutdown all instances when the bundle is stopped. And I think you're right about needing synchronisation. BTW, when testing this I was using configadmin 1.8.8, which didn't contain the fix for FELIX-5088 - CaseSensitiveDictionary should implement equals(). This caused JettyConfig.update(Dictionary props) to think that the props had not changed. It works fine with configadmin-1.8.10. > add ManagedServiceFactory to HTTP service > - > > Key: FELIX-5349 > URL: https://issues.apache.org/jira/browse/FELIX-5349 > Project: Felix > Issue Type: New Feature > Components: HTTP Service >Affects Versions: http.base-3.0.12, http.jetty-3.2.4 >Reporter: Derek Baum >Assignee: Carsten Ziegeler >Priority: Minor > Fix For: http.base-3.0.14, http.jetty-3.2.6 > > Attachments: factory.patch > > > I need to run multiple HTTP services, with different configurations. > I was surprised to find that felix.http.jetty does not provide a > ManagedServiceFactory and so were others as indicated in this stack overflow > conversation: > http://stackoverflow.com/questions/20074211/osgi-http-bundle-bind-to-two-ports > I have experimented with creating a ManagedServiceFactory for the HTTP > service myself. It is difficult to do externally to the http.jetty bundle, as > it requires access to internal packages. > I have therefore created a small patch to revision 1760954 which adds a > ManagedServiceFactory, without changing any of the existing functionality of > the ManagedService. This allows multiple http.jetty instances to be > configured using WebConsole, fileinstall or other config admin clients. > I have also added a new configuration property: org.apache.felix.http.name, > which is added as a service property to the HTTP runtime instance. This makes > it easier to target a specific HTTP whiteboard service than filtering on the > port: > HTTP_WHITEBOARD_TARGET + "=(org.apache.felix.http.name=web1)" > I would be grateful if you would consider adding this functionality. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-5349) add ManagedServiceFactory to HTTP service
[ https://issues.apache.org/jira/browse/FELIX-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15495618#comment-15495618 ] Derek Baum commented on FELIX-5349: --- Yes, I'm using the same PID. This also means that the existing Metadata is available in webconsole when creating a new instance. Enforcing the name property would be useful, otherwise it's difficult to target a specific whiteboard instance without using the port in the filter. If you only want to use the ManagedServiceFactory, then setting org.apache.felix.http.enable=false, stops the ManagedService instance from starting; although it can be re-enabled from webconsole/config admin. I did consider adding a property that would eenable either the existing ManagedService ot the new ManagedServiceFactory, but I don't think that's necessary. The ManagedServiceFactory could also check for conflicting configurations, for example a port that conflicts with an existing instance. > add ManagedServiceFactory to HTTP service > - > > Key: FELIX-5349 > URL: https://issues.apache.org/jira/browse/FELIX-5349 > Project: Felix > Issue Type: New Feature > Components: HTTP Service >Affects Versions: http.base-3.0.12, http.jetty-3.2.4 >Reporter: Derek Baum >Assignee: Carsten Ziegeler >Priority: Minor > Fix For: http.base-3.0.14, http.jetty-3.2.6 > > Attachments: factory.patch > > > I need to run multiple HTTP services, with different configurations. > I was surprised to find that felix.http.jetty does not provide a > ManagedServiceFactory and so were others as indicated in this stack overflow > conversation: > http://stackoverflow.com/questions/20074211/osgi-http-bundle-bind-to-two-ports > I have experimented with creating a ManagedServiceFactory for the HTTP > service myself. It is difficult to do externally to the http.jetty bundle, as > it requires access to internal packages. > I have therefore created a small patch to revision 1760954 which adds a > ManagedServiceFactory, without changing any of the existing functionality of > the ManagedService. This allows multiple http.jetty instances to be > configured using WebConsole, fileinstall or other config admin clients. > I have also added a new configuration property: org.apache.felix.http.name, > which is added as a service property to the HTTP runtime instance. This makes > it easier to target a specific HTTP whiteboard service than filtering on the > port: > HTTP_WHITEBOARD_TARGET + "=(org.apache.felix.http.name=web1)" > I would be grateful if you would consider adding this functionality. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FELIX-5349) add ManagedServiceFactory to HTTP service
Derek Baum created FELIX-5349: - Summary: add ManagedServiceFactory to HTTP service Key: FELIX-5349 URL: https://issues.apache.org/jira/browse/FELIX-5349 Project: Felix Issue Type: New Feature Components: HTTP Service Affects Versions: http.jetty-3.2.4, http.base-3.0.12 Reporter: Derek Baum Priority: Minor I need to run multiple HTTP services, with different configurations. I was surprised to find that felix.http.jetty does not provide a ManagedServiceFactory and so were others as indicated in this stack overflow conversation: http://stackoverflow.com/questions/20074211/osgi-http-bundle-bind-to-two-ports I have experimented with creating a ManagedServiceFactory for the HTTP service myself. It is difficult to do externally to the http.jetty bundle, as it requires access to internal packages. I have therefore created a small patch to revision 1760954 which adds a ManagedServiceFactory, without changing any of the existing functionality of the ManagedService. This allows multiple http.jetty instances to be configured using WebConsole, fileinstall or other config admin clients. I have also added a new configuration property: org.apache.felix.http.name, which is added as a service property to the HTTP runtime instance. This makes it easier to target a specific HTTP whiteboard service than filtering on the port: HTTP_WHITEBOARD_TARGET + "=(org.apache.felix.http.name=web1)" I would be grateful if you would consider adding this functionality. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-5349) add ManagedServiceFactory to HTTP service
[ https://issues.apache.org/jira/browse/FELIX-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum updated FELIX-5349: -- Attachment: factory.patch patch to implement FELIX-5349 > add ManagedServiceFactory to HTTP service > - > > Key: FELIX-5349 > URL: https://issues.apache.org/jira/browse/FELIX-5349 > Project: Felix > Issue Type: New Feature > Components: HTTP Service >Affects Versions: http.base-3.0.12, http.jetty-3.2.4 >Reporter: Derek Baum >Priority: Minor > Attachments: factory.patch > > > I need to run multiple HTTP services, with different configurations. > I was surprised to find that felix.http.jetty does not provide a > ManagedServiceFactory and so were others as indicated in this stack overflow > conversation: > http://stackoverflow.com/questions/20074211/osgi-http-bundle-bind-to-two-ports > I have experimented with creating a ManagedServiceFactory for the HTTP > service myself. It is difficult to do externally to the http.jetty bundle, as > it requires access to internal packages. > I have therefore created a small patch to revision 1760954 which adds a > ManagedServiceFactory, without changing any of the existing functionality of > the ManagedService. This allows multiple http.jetty instances to be > configured using WebConsole, fileinstall or other config admin clients. > I have also added a new configuration property: org.apache.felix.http.name, > which is added as a service property to the HTTP runtime instance. This makes > it easier to target a specific HTTP whiteboard service than filtering on the > port: > HTTP_WHITEBOARD_TARGET + "=(org.apache.felix.http.name=web1)" > I would be grateful if you would consider adding this functionality. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-5344) HTTP_WHITEBOARD_TARGET doesn't work reliably
[
https://issues.apache.org/jira/browse/FELIX-5344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15488606#comment-15488606
]
Derek Baum commented on FELIX-5344:
---
works a treat!
thanks for your fast response.
--
Derek
> HTTP_WHITEBOARD_TARGET doesn't work reliably
>
>
> Key: FELIX-5344
> URL: https://issues.apache.org/jira/browse/FELIX-5344
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http.base-3.0.12, http.jetty-3.2.4
>Reporter: Derek Baum
> Fix For: http.base-3.0.14, http.jetty-3.2.6, http.bridge-3.0.14
>
>
> I am trying to use HTTP_WHITEBOARD_TARGET to match a specific http instance:
> (I'm actually experimenting with multiple http instances, but the problem
> occurs with a single instance).
> @Component(service = Servlet.class,
> property = {
> HttpWhiteboardConstants.HTTP_WHITEBOARD_TARGET +
> "=(org.osgi.service.http.port=)"
> })
> I am configuring http.jetty using config admin (via fileinstall)
> I have disabled automatic jetty startup using:
> org.apache.felix.http.enable=false
> Now I start jetty by dropping the file org.apache.felix.http.cfg into the
> fileinstall load directory:
> org.apache.felix.http.enable=true
> org.osgi.service.http.port=
> and my servlet is not always registered.
> This appears to be because WhiteboardManager.addWhiteboardService() is being
> called before the http service properties have been set.
> Here's the output of some debug I added to isMatchingService():
> XXXtarget =(org.osgi.service.http.port=) match=false
> XXXprop objectClass=[Ljava.lang.String;@292aebaf
> XXXprop osgi.http.service.id=[60]
> XXXprop service.bundleid=22
> XXXprop service.id=61
> XXXprop service.scope=singleton
> It doesn't contain any endpoint properties.
> To prove this is a timing issue, I stopped and started my web bundle, which
> then registered correctly. The corresponding debug is:
> XXXtarget =(org.osgi.service.http.port=) match=true
> XXXprop objectClass=[Ljava.lang.String;@292aebaf
> XXXprop org.apache.felix.http.enable=true
> XXXprop org.apache.felix.https.enable=false
> XXXprop org.osgi.service.http.port=
> XXXprop org.osgi.service.http.port.secure=8443
> XXXprop osgi.http.endpoint=[Ljava.lang.String;@1d1447fa
> XXXprop osgi.http.service.id=[60]
> XXXprop service.bundleid=22
> XXXprop service.id=61
> XXXprop service.scope=singleton
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-5344) HTTP_WHITEBOARD_TARGET doesn't work reliably
[
https://issues.apache.org/jira/browse/FELIX-5344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15488518#comment-15488518
]
Derek Baum commented on FELIX-5344:
---
Hi Carsten,
This isn't working for me at all;
e.g. webconsole is not found.
I updated to revision 1760601 and did 'mvn clean install'. all tests passed.
I then tried: rm -rf
~/.m2/repository/org/apache/felix/org.apache.felix.http*/*-SNAPSHOT
and repeated: mvn clean install
This failed due to a missing dependency:
org.apache.felix.http.jetty-3.2.3-SNAPSHOT
(I obviously had a cached version of this in ~/.m2).
This dependency is in itest/pom.xml. I changed this to be 3.2.5-SNAPSHOT.
mvn clean install now fails the integration tests.
Tests run: 80, Failures: 36, Errors: 1, Skipped: 0
--
Derek
> HTTP_WHITEBOARD_TARGET doesn't work reliably
>
>
> Key: FELIX-5344
> URL: https://issues.apache.org/jira/browse/FELIX-5344
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http.base-3.0.12, http.jetty-3.2.4
>Reporter: Derek Baum
> Fix For: http.base-3.0.14, http.jetty-3.2.6, http.bridge-3.0.14
>
>
> I am trying to use HTTP_WHITEBOARD_TARGET to match a specific http instance:
> (I'm actually experimenting with multiple http instances, but the problem
> occurs with a single instance).
> @Component(service = Servlet.class,
> property = {
> HttpWhiteboardConstants.HTTP_WHITEBOARD_TARGET +
> "=(org.osgi.service.http.port=)"
> })
> I am configuring http.jetty using config admin (via fileinstall)
> I have disabled automatic jetty startup using:
> org.apache.felix.http.enable=false
> Now I start jetty by dropping the file org.apache.felix.http.cfg into the
> fileinstall load directory:
> org.apache.felix.http.enable=true
> org.osgi.service.http.port=
> and my servlet is not always registered.
> This appears to be because WhiteboardManager.addWhiteboardService() is being
> called before the http service properties have been set.
> Here's the output of some debug I added to isMatchingService():
> XXXtarget =(org.osgi.service.http.port=) match=false
> XXXprop objectClass=[Ljava.lang.String;@292aebaf
> XXXprop osgi.http.service.id=[60]
> XXXprop service.bundleid=22
> XXXprop service.id=61
> XXXprop service.scope=singleton
> It doesn't contain any endpoint properties.
> To prove this is a timing issue, I stopped and started my web bundle, which
> then registered correctly. The corresponding debug is:
> XXXtarget =(org.osgi.service.http.port=) match=true
> XXXprop objectClass=[Ljava.lang.String;@292aebaf
> XXXprop org.apache.felix.http.enable=true
> XXXprop org.apache.felix.https.enable=false
> XXXprop org.osgi.service.http.port=
> XXXprop org.osgi.service.http.port.secure=8443
> XXXprop osgi.http.endpoint=[Ljava.lang.String;@1d1447fa
> XXXprop osgi.http.service.id=[60]
> XXXprop service.bundleid=22
> XXXprop service.id=61
> XXXprop service.scope=singleton
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (FELIX-5344) HTTP_WHITEBOARD_TARGET doesn't work reliably
Derek Baum created FELIX-5344:
-
Summary: HTTP_WHITEBOARD_TARGET doesn't work reliably
Key: FELIX-5344
URL: https://issues.apache.org/jira/browse/FELIX-5344
Project: Felix
Issue Type: Bug
Components: HTTP Service
Affects Versions: http.jetty-3.2.4, http.base-3.0.12
Reporter: Derek Baum
I am trying to use HTTP_WHITEBOARD_TARGET to match a specific http instance:
(I'm actually experimenting with multiple http instances, but the problem
occurs with a single instance).
@Component(service = Servlet.class,
property = {
HttpWhiteboardConstants.HTTP_WHITEBOARD_TARGET +
"=(org.osgi.service.http.port=)"
})
I am configuring http.jetty using config admin (via fileinstall)
I have disabled automatic jetty startup using:
org.apache.felix.http.enable=false
Now I start jetty by dropping the file org.apache.felix.http.cfg into the
fileinstall load directory:
org.apache.felix.http.enable=true
org.osgi.service.http.port=
and my servlet is not always registered.
This appears to be because WhiteboardManager.addWhiteboardService() is being
called before the http service properties have been set.
Here's the output of some debug I added to isMatchingService():
XXXtarget =(org.osgi.service.http.port=) match=false
XXXprop objectClass=[Ljava.lang.String;@292aebaf
XXXprop osgi.http.service.id=[60]
XXXprop service.bundleid=22
XXXprop service.id=61
XXXprop service.scope=singleton
It doesn't contain any endpoint properties.
To prove this is a timing issue, I stopped and started my web bundle, which
then registered correctly. The corresponding debug is:
XXXtarget =(org.osgi.service.http.port=) match=true
XXXprop objectClass=[Ljava.lang.String;@292aebaf
XXXprop org.apache.felix.http.enable=true
XXXprop org.apache.felix.https.enable=false
XXXprop org.osgi.service.http.port=
XXXprop org.osgi.service.http.port.secure=8443
XXXprop osgi.http.endpoint=[Ljava.lang.String;@1d1447fa
XXXprop osgi.http.service.id=[60]
XXXprop service.bundleid=22
XXXprop service.id=61
XXXprop service.scope=singleton
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-5319) HttpServiceRuntime provides incorrect info for service that is both Servlet and Resource
[
https://issues.apache.org/jira/browse/FELIX-5319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15409596#comment-15409596
]
Derek Baum commented on FELIX-5319:
---
Hi Carsten,
Thanks for fixing this so quickly.
I can confirm that a local build of 3.2.3-SNAPSHOT works fine for me.
--
Derek
> HttpServiceRuntime provides incorrect info for service that is both Servlet
> and Resource
>
>
> Key: FELIX-5319
> URL: https://issues.apache.org/jira/browse/FELIX-5319
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http.base-3.0.10, http.jetty-3.2.2, http.bridge-3.0.10
>Reporter: Derek Baum
>Assignee: Carsten Ziegeler
>Priority: Minor
> Fix For: http.base-3.0.12, http.jetty-3.2.4, http.bridge-3.0.12
>
>
> I have a servlet defined as follows:
> Note: it defines _both_ servlet and resource properties.
> @Component(property = {
> HttpWhiteboardConstants.HTTP_WHITEBOARD_SERVLET_NAME + "=Hello
> World",
> HttpWhiteboardConstants.HTTP_WHITEBOARD_SERVLET_PATTERN +
> "=/hello/sayHello",
> HttpWhiteboardConstants.HTTP_WHITEBOARD_RESOURCE_PATTERN +
> "=/hello/static/*",
> HttpWhiteboardConstants.HTTP_WHITEBOARD_RESOURCE_PREFIX + "=/static"
> })
> public class HelloWorldServlet extends HttpServlet implements Servlet {
> }
> I am using the HttpServiceRuntime to discover servlet info, but this servlet
> does not appear.
> @Reference
> HttpServiceRuntime httpRuntime;
> RuntimeDTO runtimeDTO = httpRuntime.getRuntimeDTO();
> for (ServletContextDTO servletContextDTO : runtimeDTO.servletContextDTOs) {
> ServletDTO[] servletDTOs = servletContextDTO.servletDTOs;
> // servletDTOs.length == 0
> }
> The equivalent code for ResourceDTO _does_ find a ResourceDTO for this
> servlet, but it contains servlet, rather than resource info:
> resourceDTO.patterns = [/hello/sayHello]
> resourceDTO.prefix = null
> If I remove this resource property from the servlet, then the above code
> finds the servlet, as expected:
> HttpWhiteboardConstants.HTTP_WHITEBOARD_RESOURCE_PATTERN + "=/hello/static/*"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (FELIX-5319) HttpServiceRuntime provides incorrect info for service that is both Servlet and Resource
Derek Baum created FELIX-5319:
-
Summary: HttpServiceRuntime provides incorrect info for service
that is both Servlet and Resource
Key: FELIX-5319
URL: https://issues.apache.org/jira/browse/FELIX-5319
Project: Felix
Issue Type: Bug
Components: HTTP Service
Affects Versions: http.jetty-3.2.2
Reporter: Derek Baum
Priority: Minor
I have a servlet defined as follows:
Note: it defines _both_ servlet and resource properties.
@Component(property = {
HttpWhiteboardConstants.HTTP_WHITEBOARD_SERVLET_NAME + "=Hello
World",
HttpWhiteboardConstants.HTTP_WHITEBOARD_SERVLET_PATTERN +
"=/hello/sayHello",
HttpWhiteboardConstants.HTTP_WHITEBOARD_RESOURCE_PATTERN +
"=/hello/static/*",
HttpWhiteboardConstants.HTTP_WHITEBOARD_RESOURCE_PREFIX + "=/static"
})
public class HelloWorldServlet extends HttpServlet implements Servlet {
}
I am using the HttpServiceRuntime to discover servlet info, but this servlet
does not appear.
@Reference
HttpServiceRuntime httpRuntime;
RuntimeDTO runtimeDTO = httpRuntime.getRuntimeDTO();
for (ServletContextDTO servletContextDTO : runtimeDTO.servletContextDTOs) {
ServletDTO[] servletDTOs = servletContextDTO.servletDTOs;
// servletDTOs.length == 0
}
The equivalent code for ResourceDTO _does_ find a ResourceDTO for this servlet,
but it contains servlet, rather than resource info:
resourceDTO.patterns = [/hello/sayHello]
resourceDTO.prefix = null
If I remove this resource property from the servlet, then the above code finds
the servlet, as expected:
HttpWhiteboardConstants.HTTP_WHITEBOARD_RESOURCE_PATTERN + "=/hello/static/*"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (FELIX-5275) Felix & Equinox handling of OSGI-INF/permissions.perm differs
[ https://issues.apache.org/jira/browse/FELIX-5275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum resolved FELIX-5275. --- Resolution: Not A Bug The differences that I am seeing between Felix and Equinox is due to non spec'ed implementation specific behaviour, as explained in Karl's last comment. > Felix & Equinox handling of OSGI-INF/permissions.perm differs > - > > Key: FELIX-5275 > URL: https://issues.apache.org/jira/browse/FELIX-5275 > Project: Felix > Issue Type: Bug > Components: Configuration Admin, Framework Security >Affects Versions: configadmin-1.8.8 > Environment: Felix config-admin 1.8.8 running on Equinox with > SecurityManager >Reporter: Derek Baum > > Using Felix config-admin 1.8.8 in Equinox, with a SecurityManager active, > causes the ManagedService.updated() method to get AccessControlExceptions > when, for example, accessing System properties. > This is caused by: > #1 OSGI-INF/permissions.perm added to config-admin in FELIX-4039 > #2 Different handling of OSGI-INF/permissions.perm between Felix and Equinox. > I have previously raised this problem against Equinox (see External Issue > URL), and this is the gist of their analysis: > --- > The felix CM implementation is scoping their own permissions down to a strict > subset of permissions and Equinox is correctly enforcing that subset of > permissions. > So your bundle tries to read a system property, but the CM impl is not > authorized to read that property. > One complication may be that Felix is allowing its bundle protection domains > to be configured with the java policy file (because their ProtectionDomains > are constructed with that 4 arg constructor). > This would seem to break the specified behavior though, because clearly the > CM implementation should never be allowed to have permission to do things > outside of what is specified by the permissions.perm file or that are > "implied" permissions auto-granted by the framework for each bundle. > --- -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-5302) NPE using Http Whiteboard
[
https://issues.apache.org/jira/browse/FELIX-5302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15367402#comment-15367402
]
Derek Baum commented on FELIX-5302:
---
Hi Carsten,
This appears to have fixed the problem.
I've tried 10 times and I can no longer reproduce it. It used to occur about
every other time.
Thanks,
--
Derek
> NPE using Http Whiteboard
> -
>
> Key: FELIX-5302
> URL: https://issues.apache.org/jira/browse/FELIX-5302
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http.jetty-3.2.0
>Reporter: Derek Baum
>Assignee: Carsten Ziegeler
> Fix For: http.jetty-3.2.2
>
> Attachments: http.jetty.bad.log, http.jetty.good.log
>
>
> I am getting this NPE about 50% of the time after reconfiguring my servlet
> (causing it to unregister and re-register):
> [org.apache.felix.http.jetty:3.2.0] Exception while processing request to
> /hello/sayHello
> java.lang.NullPointerException: null
> org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:85)
> org.apache.felix.http.base.internal.dispatch.InvocationChain.doFilter(InvocationChain.java:79)
> org.apache.felix.http.base.internal.dispatch.Dispatcher.dispatch(Dispatcher.java:124)
> org.apache.felix.http.base.internal.DispatcherServlet.service(DispatcherServlet.java:61)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:845)
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:583)
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
> org.eclipse.jetty.server.Server.handle(Server.java:518)
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:246)
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:156)
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)
> java.lang.Thread.run(Thread.java:745)
> The servlet uses the Http Whiteboard:
> @Component(
> property = {
> HttpWhiteboardConstants.HTTP_WHITEBOARD_SERVLET_PATTERN + "=/hello/sayHello",
>HttpWhiteboardConstants.HTTP_WHITEBOARD_RESOURCE_PATTERN +
> "=/hello/static/*",
> HttpWhiteboardConstants.HTTP_WHITEBOARD_RESOURCE_PREFIX + "=/static"})
> public class HelloWorldServlet extends HttpServlet implements Servlet {
> }
> About 50% of the time when I initially deploy the Servlet, I've noticed that
> ServletRegistry.addServlet() is called twice for the same servlet with the
> same serviceId.
> I don't know why this happens, but when it does it leads to the NPE above.
> The second addServlet() invokes addToInactiveList().
> The system works in this state, but it has a duplicate servlet handler in the
> inactive list.
> If the servlet is now reconfigured, causing it to unregister and re-register,
> we get the NPE above on the next request.
> This appears to be because ServletRegistry.removeServlet() fails to invoke
> "resolvers.remove(regHandler)", when the inactive list contains the argument
> ServletInfo.
> Alternatively, addServlet() should never allow a duplicate registration to be
> added to the inactive list.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-5302) NPE using Http Whiteboard
[
https://issues.apache.org/jira/browse/FELIX-5302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15366359#comment-15366359
]
Derek Baum commented on FELIX-5302:
---
I'm afraid that didn't work. The duplicates are being added by different
instances of the WhiteboardServiceTracker.
There is a single instance of the WhiteboardManager in both cases.
The "good" case looks like:
manager.start context1
adding service id=24 ServletTracker@3b3af66
manager.stop
manager.start context2
adding service id=26 ServletTracker@6b419013
while the "bad" case looks like:
manager.start context1
adding service id=24 ServletTracker@7245c93a
adding service id=26 ServletTracker@7245c93a
manager.stop
manager.start context2
adding service id=26 ServletTracker@5240ac63
The difference is that in the bad case, service id=26 was added by
ServletTracker@7245c93a from the first start(context1) and then added again
from the second start(context2) from ServletTracker@5240ac63.
> NPE using Http Whiteboard
> -
>
> Key: FELIX-5302
> URL: https://issues.apache.org/jira/browse/FELIX-5302
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http.jetty-3.2.0
>Reporter: Derek Baum
>Assignee: Carsten Ziegeler
> Fix For: http.jetty-3.2.2
>
> Attachments: http.jetty.bad.log, http.jetty.good.log
>
>
> I am getting this NPE about 50% of the time after reconfiguring my servlet
> (causing it to unregister and re-register):
> [org.apache.felix.http.jetty:3.2.0] Exception while processing request to
> /hello/sayHello
> java.lang.NullPointerException: null
> org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:85)
> org.apache.felix.http.base.internal.dispatch.InvocationChain.doFilter(InvocationChain.java:79)
> org.apache.felix.http.base.internal.dispatch.Dispatcher.dispatch(Dispatcher.java:124)
> org.apache.felix.http.base.internal.DispatcherServlet.service(DispatcherServlet.java:61)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:845)
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:583)
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
> org.eclipse.jetty.server.Server.handle(Server.java:518)
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:246)
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:156)
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)
> java.lang.Thread.run(Thread.java:745)
> The servlet uses the Http Whiteboard:
> @Component(
> property = {
> HttpWhiteboardConstants.HTTP_WHITEBOARD_SERVLET_PATTERN + "=/hello/sayHello",
>HttpWhiteboardConstants.HTTP_WHITEBOARD_RESOURCE_PATTERN +
> "=/hello/static/*",
> HttpWhiteboardConstants.HTTP_WHITEBOARD_RESOURCE_PREFIX + "=/static"})
> public class HelloWorldServlet extends HttpServlet implements Servlet {
> }
> About 50% of the time when I initially deploy the Servlet, I've noticed that
> ServletRegistry.addServlet() is called twice for the same servlet with the
> same serviceId.
> I don't know why this happens, but when it does it leads to the NPE above.
> The second addServlet() invokes addToInactiveList().
> The system works in this state, but it has a duplicate servlet handler in the
> inactive list.
> If the servlet is now reconfigured, causing it to unregister and re-register,
> we get the NPE above on the next request.
> This appears to be because ServletRegistry.removeServlet() fails to invoke
> "resolvers.remove(regHandler)", when the inactive list contains the argument
>
[jira] [Commented] (FELIX-5302) NPE using Http Whiteboard
[
https://issues.apache.org/jira/browse/FELIX-5302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15366001#comment-15366001
]
Derek Baum commented on FELIX-5302:
---
I added logging to addingService(), modifiedService() and removedService().
Here is the output in the bad case, including the previous logging, but without
the stack trace:
WhiteboardServiceTracker: addingService: id=15 ref=[javax.servlet.Servlet]
ServletRegistry: addServlet: pattern=/hello/static/* serviceId=15
java.lang.Exception: Stack trace
ServletRegistry: addServlet: pattern=/hello/sayHello serviceId=15
java.lang.Exception: Stack trace
WhiteboardServiceTracker: addingService: id=15 ref=[javax.servlet.Servlet]
WhiteboardServiceTracker: removedService: id=15 ref=[javax.servlet.Servlet]
WhiteboardServiceTracker: removedService: id=15 ref=[javax.servlet.Servlet]
WhiteboardServiceTracker: addingService: id=15 ref=[javax.servlet.Servlet]
ServletRegistry: addServlet: pattern=/hello/sayHello serviceId=15
java.lang.Exception: Stack trace
ServletRegistry: addServlet: pattern=/hello/static/* serviceId=15
java.lang.Exception: Stack trace
ServletRegistry: addServlet: pattern=/hello/sayHello serviceId=15
java.lang.Exception: Stack trace
ServletRegistry: addServlet: addToInactiveList
WhiteboardServiceTracker: addingService: id=15 ref=[javax.servlet.Servlet]
> NPE using Http Whiteboard
> -
>
> Key: FELIX-5302
> URL: https://issues.apache.org/jira/browse/FELIX-5302
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http.jetty-3.2.0
>Reporter: Derek Baum
> Attachments: http.jetty.bad.log, http.jetty.good.log
>
>
> I am getting this NPE about 50% of the time after reconfiguring my servlet
> (causing it to unregister and re-register):
> [org.apache.felix.http.jetty:3.2.0] Exception while processing request to
> /hello/sayHello
> java.lang.NullPointerException: null
> org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:85)
> org.apache.felix.http.base.internal.dispatch.InvocationChain.doFilter(InvocationChain.java:79)
> org.apache.felix.http.base.internal.dispatch.Dispatcher.dispatch(Dispatcher.java:124)
> org.apache.felix.http.base.internal.DispatcherServlet.service(DispatcherServlet.java:61)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:845)
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:583)
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
> org.eclipse.jetty.server.Server.handle(Server.java:518)
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:246)
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:156)
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)
> java.lang.Thread.run(Thread.java:745)
> The servlet uses the Http Whiteboard:
> @Component(
> property = {
> HttpWhiteboardConstants.HTTP_WHITEBOARD_SERVLET_PATTERN + "=/hello/sayHello",
>HttpWhiteboardConstants.HTTP_WHITEBOARD_RESOURCE_PATTERN +
> "=/hello/static/*",
> HttpWhiteboardConstants.HTTP_WHITEBOARD_RESOURCE_PREFIX + "=/static"})
> public class HelloWorldServlet extends HttpServlet implements Servlet {
> }
> About 50% of the time when I initially deploy the Servlet, I've noticed that
> ServletRegistry.addServlet() is called twice for the same servlet with the
> same serviceId.
> I don't know why this happens, but when it does it leads to the NPE above.
> The second addServlet() invokes addToInactiveList().
> The system works in this state, but it has a duplicate servlet handler in the
> inactive list.
> If the
[jira] [Updated] (FELIX-5302) NPE using Http Whiteboard
[
https://issues.apache.org/jira/browse/FELIX-5302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Derek Baum updated FELIX-5302:
--
Attachment: http.jetty.good.log
http.jetty.bad.log
Hi Carsten,
I'm attaching the stack traces first as it's easier.
I'll look into attaching some bundles/test-case, but that will take longer.
The stack trace is generated using the SVN head built locally.
I've also added two log messages so that I can determine whether it is a good
or bad startup. I've done this without affecting the line numbers.
line 127 (patterns.add(pattern);) I've appended:
log("addServlet: pattern=" + pattern + " serviceId=" +
handler.getServletInfo().getServiceId()); Thread.dumpStack();
line 155 (this.addToInactiveList(pattern, handler, status);) I've appended:
log("addServlet: addToInactiveList");
The bad.log will fail on the next request with the NPE after the servlet is
unregistered/re-registered.
> NPE using Http Whiteboard
> -
>
> Key: FELIX-5302
> URL: https://issues.apache.org/jira/browse/FELIX-5302
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http.jetty-3.2.0
>Reporter: Derek Baum
> Attachments: http.jetty.bad.log, http.jetty.good.log
>
>
> I am getting this NPE about 50% of the time after reconfiguring my servlet
> (causing it to unregister and re-register):
> [org.apache.felix.http.jetty:3.2.0] Exception while processing request to
> /hello/sayHello
> java.lang.NullPointerException: null
> org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:85)
> org.apache.felix.http.base.internal.dispatch.InvocationChain.doFilter(InvocationChain.java:79)
> org.apache.felix.http.base.internal.dispatch.Dispatcher.dispatch(Dispatcher.java:124)
> org.apache.felix.http.base.internal.DispatcherServlet.service(DispatcherServlet.java:61)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:845)
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:583)
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
> org.eclipse.jetty.server.Server.handle(Server.java:518)
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:246)
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:156)
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)
> java.lang.Thread.run(Thread.java:745)
> The servlet uses the Http Whiteboard:
> @Component(
> property = {
> HttpWhiteboardConstants.HTTP_WHITEBOARD_SERVLET_PATTERN + "=/hello/sayHello",
>HttpWhiteboardConstants.HTTP_WHITEBOARD_RESOURCE_PATTERN +
> "=/hello/static/*",
> HttpWhiteboardConstants.HTTP_WHITEBOARD_RESOURCE_PREFIX + "=/static"})
> public class HelloWorldServlet extends HttpServlet implements Servlet {
> }
> About 50% of the time when I initially deploy the Servlet, I've noticed that
> ServletRegistry.addServlet() is called twice for the same servlet with the
> same serviceId.
> I don't know why this happens, but when it does it leads to the NPE above.
> The second addServlet() invokes addToInactiveList().
> The system works in this state, but it has a duplicate servlet handler in the
> inactive list.
> If the servlet is now reconfigured, causing it to unregister and re-register,
> we get the NPE above on the next request.
> This appears to be because ServletRegistry.removeServlet() fails to invoke
> "resolvers.remove(regHandler)", when the inactive list contains the argument
> ServletInfo.
> Alternatively, addServlet() should never allow a duplicate registration to be
> added to the inactive
[jira] [Created] (FELIX-5302) NPE using Http Whiteboard
Derek Baum created FELIX-5302:
-
Summary: NPE using Http Whiteboard
Key: FELIX-5302
URL: https://issues.apache.org/jira/browse/FELIX-5302
Project: Felix
Issue Type: Bug
Components: HTTP Service
Affects Versions: http.jetty-3.2.0
Reporter: Derek Baum
I am getting this NPE about 50% of the time after reconfiguring my servlet
(causing it to unregister and re-register):
[org.apache.felix.http.jetty:3.2.0] Exception while processing request to
/hello/sayHello
java.lang.NullPointerException: null
org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:85)
org.apache.felix.http.base.internal.dispatch.InvocationChain.doFilter(InvocationChain.java:79)
org.apache.felix.http.base.internal.dispatch.Dispatcher.dispatch(Dispatcher.java:124)
org.apache.felix.http.base.internal.DispatcherServlet.service(DispatcherServlet.java:61)
javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:845)
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:583)
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
org.eclipse.jetty.server.Server.handle(Server.java:518)
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:246)
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:156)
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)
java.lang.Thread.run(Thread.java:745)
The servlet uses the Http Whiteboard:
@Component(
property = {
HttpWhiteboardConstants.HTTP_WHITEBOARD_SERVLET_PATTERN + "=/hello/sayHello",
HttpWhiteboardConstants.HTTP_WHITEBOARD_RESOURCE_PATTERN +
"=/hello/static/*",
HttpWhiteboardConstants.HTTP_WHITEBOARD_RESOURCE_PREFIX + "=/static"})
public class HelloWorldServlet extends HttpServlet implements Servlet {
}
About 50% of the time when I initially deploy the Servlet, I've noticed that
ServletRegistry.addServlet() is called twice for the same servlet with the same
serviceId.
I don't know why this happens, but when it does it leads to the NPE above.
The second addServlet() invokes addToInactiveList().
The system works in this state, but it has a duplicate servlet handler in the
inactive list.
If the servlet is now reconfigured, causing it to unregister and re-register,
we get the NPE above on the next request.
This appears to be because ServletRegistry.removeServlet() fails to invoke
"resolvers.remove(regHandler)", when the inactive list contains the argument
ServletInfo.
Alternatively, addServlet() should never allow a duplicate registration to be
added to the inactive list.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-5275) Felix & Equinox handling of OSGI-INF/permissions.perm differs
[ https://issues.apache.org/jira/browse/FELIX-5275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15362350#comment-15362350 ] Derek Baum commented on FELIX-5275: --- Karl, thanks for your comments. Our use-case is indeed running with security enabled but _without_ framework.security installed. This is because we have some legacy RMI code that requires a SecurityManager, but we don’t otherwise use security and so we specify a policy that grants all permission. Thanks for indicating the reason that this works in Felix, (but not in Equinox), is because delegation to the java security policy (using the 4-arg ProtectionDomain constructor) is not spec’ed and is therefore framework-specific. This explains why our code runs with Felix + Felix CM, but not with Equinox + Felix CM. > Felix & Equinox handling of OSGI-INF/permissions.perm differs > - > > Key: FELIX-5275 > URL: https://issues.apache.org/jira/browse/FELIX-5275 > Project: Felix > Issue Type: Bug > Components: Configuration Admin, Framework Security >Affects Versions: configadmin-1.8.8 > Environment: Felix config-admin 1.8.8 running on Equinox with > SecurityManager >Reporter: Derek Baum > > Using Felix config-admin 1.8.8 in Equinox, with a SecurityManager active, > causes the ManagedService.updated() method to get AccessControlExceptions > when, for example, accessing System properties. > This is caused by: > #1 OSGI-INF/permissions.perm added to config-admin in FELIX-4039 > #2 Different handling of OSGI-INF/permissions.perm between Felix and Equinox. > I have previously raised this problem against Equinox (see External Issue > URL), and this is the gist of their analysis: > --- > The felix CM implementation is scoping their own permissions down to a strict > subset of permissions and Equinox is correctly enforcing that subset of > permissions. > So your bundle tries to read a system property, but the CM impl is not > authorized to read that property. > One complication may be that Felix is allowing its bundle protection domains > to be configured with the java policy file (because their ProtectionDomains > are constructed with that 4 arg constructor). > This would seem to break the specified behavior though, because clearly the > CM implementation should never be allowed to have permission to do things > outside of what is specified by the permissions.perm file or that are > "implied" permissions auto-granted by the framework for each bundle. > --- -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FELIX-5275) Felix & Equinox handling of OSGI-INF/permissions.perm differs
Derek Baum created FELIX-5275: - Summary: Felix & Equinox handling of OSGI-INF/permissions.perm differs Key: FELIX-5275 URL: https://issues.apache.org/jira/browse/FELIX-5275 Project: Felix Issue Type: Bug Components: Configuration Admin, Framework Security Affects Versions: configadmin-1.8.8 Environment: Felix config-admin 1.8.8 running on Equinox with SecurityManager Reporter: Derek Baum Using Felix config-admin 1.8.8 in Equinox, with a SecurityManager active, causes the ManagedService.updated() method to get AccessControlExceptions when, for example, accessing System properties. This is caused by: #1 OSGI-INF/permissions.perm added to config-admin in FELIX-4039 #2 Different handling of OSGI-INF/permissions.perm between Felix and Equinox. I have previously raised this problem against Equinox (see External Issue URL), and this is the gist of their analysis: --- The felix CM implementation is scoping their own permissions down to a strict subset of permissions and Equinox is correctly enforcing that subset of permissions. So your bundle tries to read a system property, but the CM impl is not authorized to read that property. One complication may be that Felix is allowing its bundle protection domains to be configured with the java policy file (because their ProtectionDomains are constructed with that 4 arg constructor). This would seem to break the specified behavior though, because clearly the CM implementation should never be allowed to have permission to do things outside of what is specified by the permissions.perm file or that are "implied" permissions auto-granted by the framework for each bundle. --- -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FELIX-4529) [Gogo] Let gosh be configured by files contributed by a bundle fragment
[ https://issues.apache.org/jira/browse/FELIX-4529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum resolved FELIX-4529. --- Resolution: Fixed fragment containing resource /etc/gosh_profile can now be used to override initialisation. [Gogo] Let gosh be configured by files contributed by a bundle fragment --- Key: FELIX-4529 URL: https://issues.apache.org/jira/browse/FELIX-4529 Project: Felix Issue Type: Improvement Components: Gogo Shell Affects Versions: gogo.shell-0.10.0 Reporter: Cristiano Gavião Assignee: Derek Baum Priority: Minor Fix For: gogo.shell-0.12.0 currently the ways to use an alternative gosh_profile are or setting a gosh.home system property and then copying the new file to gosh.home/etc or copying the new file to user.dir/etc. That is no feasible when you can't use external file system directories. In such scenario a good alternative is use a bundle fragment having gogo.shell as its host. Gogo.shell should search for an ext package containing gosh_profile and modt files after check for gosh.home and before check for internal gosh_profile. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (FELIX-3703) Race condition in gogo runtime activator
[ https://issues.apache.org/jira/browse/FELIX-3703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13474127#comment-13474127 ] Derek Baum commented on FELIX-3703: --- Hi Thomas, Thanks for the stack trace and test case. Coincidently, I recently filed FELIX-3706 which fixes this problem. (I didn't realise it was the same problem until I saw the stack trace). Your test case works if you use gogo-shell-0.11.0-SNAPSHOT, using the subversion HEAD containing the fix for FELIX-3706. Race condition in gogo runtime activator Key: FELIX-3703 URL: https://issues.apache.org/jira/browse/FELIX-3703 Project: Felix Issue Type: Bug Components: Gogo Runtime Affects Versions: gogo.runtime-0.10.0 Environment: Embedded felix 4.0.3 Reporter: Tomas Pan Attachments: my.patch, osgi-embedded.zip Starting gogo.command (0.12.0) before gogo.runtime(0.10.0) produces CommandNotFoundException: Command not found: gosh. This is because runtime's Activator first registers CommandProcessor before creating commandTracker. Creating CommandProcessor triggers event on .command which will start adding commands, but since commandTracker is not present, those commands will be ignored. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-3703) Race condition in gogo runtime activator
[ https://issues.apache.org/jira/browse/FELIX-3703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum resolved FELIX-3703. --- Resolution: Fixed Fix Version/s: gogo.shell-0.12.0 Assignee: Derek Baum fixed by FELIX-3706. Race condition in gogo runtime activator Key: FELIX-3703 URL: https://issues.apache.org/jira/browse/FELIX-3703 Project: Felix Issue Type: Bug Components: Gogo Runtime Affects Versions: gogo.runtime-0.10.0 Environment: Embedded felix 4.0.3 Reporter: Tomas Pan Assignee: Derek Baum Fix For: gogo.shell-0.12.0 Attachments: my.patch, osgi-embedded.zip Starting gogo.command (0.12.0) before gogo.runtime(0.10.0) produces CommandNotFoundException: Command not found: gosh. This is because runtime's Activator first registers CommandProcessor before creating commandTracker. Creating CommandProcessor triggers event on .command which will start adding commands, but since commandTracker is not present, those commands will be ignored. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-3706) gogo shell startup failure in busy system
Derek Baum created FELIX-3706: - Summary: gogo shell startup failure in busy system Key: FELIX-3706 URL: https://issues.apache.org/jira/browse/FELIX-3706 Project: Felix Issue Type: Bug Components: Gogo Shell Affects Versions: gogo.shell-0.10.0 Reporter: Derek Baum Assignee: Derek Baum Priority: Minor launching felix from within Eclipse using bndtools, occasionally fails: gogo: CommandNotFoundException: Command not found: gosh org.apache.felix.gogo.runtime.CommandNotFoundException: Command not found: gosh at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:474) at org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:403) 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. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-3706) gogo shell startup failure in busy system
[ https://issues.apache.org/jira/browse/FELIX-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum resolved FELIX-3706. --- Resolution: Fixed Fix Version/s: gogo.shell-0.12.0 changed fixed sleep of 100ms to loop that explicitly tests for gogo:gosh command becoming available. gogo shell startup failure in busy system - Key: FELIX-3706 URL: https://issues.apache.org/jira/browse/FELIX-3706 Project: Felix Issue Type: Bug Components: Gogo Shell Affects Versions: gogo.shell-0.10.0 Reporter: Derek Baum Assignee: Derek Baum Priority: Minor Fix For: gogo.shell-0.12.0 launching felix from within Eclipse using bndtools, occasionally fails: gogo: CommandNotFoundException: Command not found: gosh org.apache.felix.gogo.runtime.CommandNotFoundException: Command not found: gosh at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:474) at org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:403) 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. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3703) Race condition in gogo runtime activator
[ https://issues.apache.org/jira/browse/FELIX-3703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13471446#comment-13471446 ] Derek Baum commented on FELIX-3703: --- Hi Thomas, The gogo:gosh command is provided by the Shell bundle, not the Command bundle and is therefore present even if the Command bundle is not started. I cannot reproduce the condition you describe, even if I start the Shell bundle before the Runtime bundle. A ServiceTracker is used to locate gogo commands in other bundles. It should not matter when this tracker is started, as it gives an initial list of matching services and then updates and new services appear. The patch you provided caused a NPE at Activator:156 where the process field is accessed. Please provide more details of your problem, ideally a test-case. Race condition in gogo runtime activator Key: FELIX-3703 URL: https://issues.apache.org/jira/browse/FELIX-3703 Project: Felix Issue Type: Bug Components: Gogo Runtime Affects Versions: gogo.runtime-0.10.0 Environment: Embedded felix 4.0.3 Reporter: Tomas Pan Attachments: my.patch Starting gogo.command (0.12.0) before gogo.runtime(0.10.0) produces CommandNotFoundException: Command not found: gosh. This is because runtime's Activator first registers CommandProcessor before creating commandTracker. Creating CommandProcessor triggers event on .command which will start adding commands, but since commandTracker is not present, those commands will be ignored. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [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] [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] [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] [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-tabpanelfocusedCommentId=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] [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.jetty.handler.ContextHandler.doStop(ContextHandler.java:591) at
[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
[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-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] 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] 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.init(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.init(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] 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-tabpanelfocusedCommentId=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 codefalse/code
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] 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 codefalse/code
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-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-tabpanelfocusedCommentId=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] 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] 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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:335)
[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] 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 bundle-id;-imports=xxx, which is wrong, as the -imports compile dependencies are common to all bundles, so should not be prefixed by bundle-id; -- 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.init(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 bundle-id;-imports=xxx, which is wrong, as the -imports compile dependencies are common to all bundles, so should not be prefixed by bundle-id; -- 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-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-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] 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-2454) [gogo] the runtime coercion mechanism should leverage blueprint
[gogo] the runtime coercion mechanism should leverage blueprint --- Key: FELIX-2454 URL: https://issues.apache.org/jira/browse/FELIX-2454 Project: Felix Issue Type: Improvement Components: Gogo Runtime Reporter: Derek Baum The gogo runtime coercion mechanism, as implemented in Reflective.java, should be re-factored to benefit from the coercion used in blueprint. Note: we do NOT want a dependency on blueprint in the gogo runtime, but want to take advantage of the work already done, as coercion quickly becomes quite complex. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2453) [gogo] the new command should leverage the runtime coercion mechanism
[gogo] the new command should leverage the runtime coercion mechanism --- Key: FELIX-2453 URL: https://issues.apache.org/jira/browse/FELIX-2453 Project: Felix Issue Type: Improvement Components: Gogo Runtime, Gogo Shell Reporter: Derek Baum The gogo:new command currently performs only rudimentary argument type coercion. It should be moved into the runtime as osgi:new to leverage the runtime coercion mechanism. Alternatively, the runtime coercion mechanism should be exposed as a service to allow an external gogo:new command to use it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2455) [gogo API] the Function interface used for Closures, takes an unused session parameter
[gogo API] the Function interface used for Closures, takes an unused session
parameter
--
Key: FELIX-2455
URL: https://issues.apache.org/jira/browse/FELIX-2455
Project: Felix
Issue Type: Improvement
Components: Gogo Runtime
Reporter: Derek Baum
The org.osgi.service.command.Function interface (used for Closures), takes a
session argument, which is not used in the implementation:
The Closure constructor takes a session parameter. This is used by the
execute() method, which ignores its own session parameter.
Unless there is another reason for execute() taking a session parameter, I
suggest we change the API to remove this parameter
(deprecating the existing method to keep backward compatibility).
public interface Function {
Object execute(CommandSession session, ListObject arguments) throws
Exception;
}
Closure.java:113:
// implements Function interface
// XXX: session arg x not used?
public Object execute(CommandSession x, ListObject values) throws
Exception
{
try
{
location.remove();
session.variables.remove(LOCATION);
return execute(values);
}
catch (Exception e)
{
throw setLocation(e);
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2455) [gogo API] the Function interface used for Closures, takes an unused session parameter
[
https://issues.apache.org/jira/browse/FELIX-2455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12883600#action_12883600
]
Derek Baum commented on FELIX-2455:
---
I raised this issue as I noticed that the Closure implementation of Function
doesn't use its session parameter.
I've since found that CommandProxy also implements Function and it does use the
session parameter, so I'll mark this issue as 'won't fix'.
[gogo API] the Function interface used for Closures, takes an unused session
parameter
--
Key: FELIX-2455
URL: https://issues.apache.org/jira/browse/FELIX-2455
Project: Felix
Issue Type: Improvement
Components: Gogo Runtime
Reporter: Derek Baum
The org.osgi.service.command.Function interface (used for Closures), takes a
session argument, which is not used in the implementation:
The Closure constructor takes a session parameter. This is used by the
execute() method, which ignores its own session parameter.
Unless there is another reason for execute() taking a session parameter, I
suggest we change the API to remove this parameter
(deprecating the existing method to keep backward compatibility).
public interface Function {
Object execute(CommandSession session, ListObject arguments) throws
Exception;
}
Closure.java:113:
// implements Function interface
// XXX: session arg x not used?
public Object execute(CommandSession x, ListObject values) throws
Exception
{
try
{
location.remove();
session.variables.remove(LOCATION);
return execute(values);
}
catch (Exception e)
{
throw setLocation(e);
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-2455) [gogo API] the Function interface used for Closures, takes an unused session parameter
[
https://issues.apache.org/jira/browse/FELIX-2455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Derek Baum resolved FELIX-2455.
---
Resolution: Not A Problem
not a problem - other implementations of Function may use the session parameter.
[gogo API] the Function interface used for Closures, takes an unused session
parameter
--
Key: FELIX-2455
URL: https://issues.apache.org/jira/browse/FELIX-2455
Project: Felix
Issue Type: Improvement
Components: Gogo Runtime
Reporter: Derek Baum
The org.osgi.service.command.Function interface (used for Closures), takes a
session argument, which is not used in the implementation:
The Closure constructor takes a session parameter. This is used by the
execute() method, which ignores its own session parameter.
Unless there is another reason for execute() taking a session parameter, I
suggest we change the API to remove this parameter
(deprecating the existing method to keep backward compatibility).
public interface Function {
Object execute(CommandSession session, ListObject arguments) throws
Exception;
}
Closure.java:113:
// implements Function interface
// XXX: session arg x not used?
public Object execute(CommandSession x, ListObject values) throws
Exception
{
try
{
location.remove();
session.variables.remove(LOCATION);
return execute(values);
}
catch (Exception e)
{
throw setLocation(e);
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] 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] 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-tabpanelfocusedCommentId=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] 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] 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-tabpanelfocusedCommentId=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] 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] 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-tabpanelfocusedCommentId=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] 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] 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] 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] 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] 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-tabpanelfocusedCommentId=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] 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-tabpanelfocusedCommentId=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.
