[jira] [Commented] (FELIX-5735) No possibility to deactivate the startup of the default server

[J.W. Janssen (JIRA)]

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

J.W. Janssen commented on FELIX-5735:
-

IIRC, passing the system/framework property {{org.osgi.service.http.port=0}} 
would disable the startup of the default server and allow you to create servers 
using configadmin.

> No possibility to deactivate the startup of the default server
> --
>
> Key: FELIX-5735
> URL: https://issues.apache.org/jira/browse/FELIX-5735
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Affects Versions: http.jetty-3.4.4
>Reporter: Jürgen Albert
>
> As far as I have seen, I can change the configuration of the default jetty, 
> but there is no way to suppress the start of a server. We have a couple of 
> cases, where we only want to start one or more server instances on demand.
> a system variable to prevent the startup could be a solution here.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (FELIX-5683) getServiceProperties returns null instead of empty dictionary

[J.W. Janssen (JIRA)]

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

J.W. Janssen commented on FELIX-5683:
-

As Marian and Bram suggested, I would also opt for always returning a 
{{Dictionary}} instance that is either empty if no service properties were 
defined for the service, or a *copy* of Dictionary with the existing service 
properties. It would make the usage pattern very clear regardless whether there 
were service properties defined on the original service.

> getServiceProperties returns null instead of empty dictionary
> -
>
> Key: FELIX-5683
> URL: https://issues.apache.org/jira/browse/FELIX-5683
> Project: Felix
>  Issue Type: Bug
>  Components: Dependency Manager
>Affects Versions: org.apache.felix.dependencymanager-r9
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Minor
>
> There are two issues:
> 1)
> In the felix users mailing list (see [1]), Bram reported the following:
> when you set a component service properties like this:
> {code}
> Component component = 
> m_dependencyManager.createComponent().setInterface(ApplicationService.class.getName(),new
>  Properties());
> component.getServiceProperties().put("a", "b");
> {code}
> then you get a NPE because the component.getServiceProperties() method 
> returns null instead of the empty dictionary that has been set in the 
> setInterfaceMethod.
> This is a regression made in r9 release, in the FELIX-5522 where a 
> refactoring was done regarding aspect service properties.
> A fix can be made in order to behave like before (that is : avoid the NPE). 
> 2)
> Bram, I may be wrong but I think that one new issue is that the dictionary 
> returned by the getServiceProperties() method was so far (since the initial 
> version of felix dm 2.0.1) a copy of the service properties dictionary 
> maintained in the ComponentImpl, so if you would like to do set service 
> properties like this:
> {code}
> Component component = 
> m_dependencyManager.createComponent().setInterface(ApplicationService.class.getName(),new
>  Properties());
> component.getServiceProperties().put("a", "b");
> m_dependencyManager.add(component);  // won't add "a=b" properties
> {code}
> then the "a" property will be set in the copy of the internal dictionary 
> returned by the getServiceProperties() method, and the "a=b" service 
> properties won't be set when the component is added in the 
> m_dependencyManager.
> So, if what I'm saying is correct and if you would like to see this new 
> behavior implemented, please open a new jira issue and I will manage to 
> implement it; thanks
> PS: I'm now fixing the 1) regression, in order to avoid the NPE.
> [1] http://www.mail-archive.com/users%40felix.apache.org/msg17939.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (FELIX-5683) getServiceProperties returns null instead of empty dictionary

[J.W. Janssen (JIRA)]

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

J.W. Janssen commented on FELIX-5683:
-

{quote}
> Bram, I may be wrong but I think that one new issue is that the dictionary 
> returned by the getServiceProperties() method was so far (since the initial 
> version of felix dm 2.0.1) a copy of the service properties dictionary 
> maintained in the ComponentImpl, so if you would like to do set service 
> properties like this:

I'm not sure that's a real issue I am aware that, furthermore I think that 
changing this behavior would be another breaking change.
{quote}

I tend to agree with Bram here, I think it would cause more trouble than it is 
worth: with the current (DM 2.0.1) behaviour, you can create "atomic" updates 
to the service properties by retrieving them, modifying them and updating them 
in a single call. With the proposed change it would allow the service 
properties to reflect "partial" changes while we're updating them.

> getServiceProperties returns null instead of empty dictionary
> -
>
> Key: FELIX-5683
> URL: https://issues.apache.org/jira/browse/FELIX-5683
> Project: Felix
>  Issue Type: Bug
>  Components: Dependency Manager
>Affects Versions: org.apache.felix.dependencymanager-r9
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Minor
>
> There are two issues:
> 1)
> In the felix users mailing list (see [1]), Bram reported the following:
> when you set a component service properties like this:
> {code}
> Component component = 
> m_dependencyManager.createComponent().setInterface(ApplicationService.class.getName(),new
>  Properties());
> component.getServiceProperties().put("a", "b");
> {code}
> then you get a NPE because the component.getServiceProperties() method 
> returns null instead of the empty dictionary that has been set in the 
> setInterfaceMethod.
> This is a regression made in r9 release, in the FELIX-5522 where a 
> refactoring was done regarding aspect service properties.
> A fix can be made in order to behave like before (that is : avoid the NPE). 
> 2)
> Bram, I may be wrong but I think that one new issue is that the dictionary 
> returned by the getServiceProperties() method was so far (since the initial 
> version of felix dm 2.0.1) a copy of the service properties dictionary 
> maintained in the ComponentImpl, so if you would like to do set service 
> properties like this:
> {code}
> Component component = 
> m_dependencyManager.createComponent().setInterface(ApplicationService.class.getName(),new
>  Properties());
> component.getServiceProperties().put("a", "b");
> m_dependencyManager.add(component);  // won't add "a=b" properties
> {code}
> then the "a" property will be set in the copy of the internal dictionary 
> returned by the getServiceProperties() method, and the "a=b" service 
> properties won't be set when the component is added in the 
> m_dependencyManager.
> So, if what I'm saying is correct and if you would like to see this new 
> behavior implemented, please open a new jira issue and I will manage to 
> implement it; thanks
> PS: I'm now fixing the 1) regression, in order to avoid the NPE.
> [1] http://www.mail-archive.com/users%40felix.apache.org/msg17939.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (FELIX-5660) DM r11 does not build after clean

[J.W. Janssen (JIRA)]

J.W. Janssen created FELIX-5660:
---

 Summary: DM r11 does not build after clean
 Key: FELIX-5660
 URL: https://issues.apache.org/jira/browse/FELIX-5660
 Project: Felix
  Issue Type: Bug
  Components: Dependency Manager
Affects Versions: org.apache.felix.dependencymanager-r11
Reporter: J.W. Janssen


Trying to build the DM sources from scratch fails the first time (also after a 
`clean`) with the following error:

{code}
:org.apache.felix.dependencymanager.runtime:build
:org.apache.felix.dependencymanager.runtime.itest:compileJava
Error  : Exception: java.lang.ClassNotFoundException: 
org.apache.felix.dm.annotation.plugin.bnd.AnnotationPlugin not found, parent:  
java.net.URLClassLoader@258ee7de 
urls:[file:/private/tmp/felix-staging/org.apache.felix.dependencymanager-r11/org.apache.felix.dependencymanager-r11-src/org.apache.felix.dependencymanager.annotation/generated/org.apache.felix.dependencymanager.annotation.jar]
 exception:java.lang.ClassNotFoundException: 
org.apache.felix.dm.annotation.plugin.bnd.AnnotationPlugin
Error  : Failed to load plugin 
org.apache.felix.dm.annotation.plugin.bnd.AnnotationPlugin;log=debug;path:="/private/tmp/felix-staging/org.apache.felix.dependencymanager-r11/org.apache.felix.dependencymanager-r11-src/org.apache.felix.dependencymanager.annotation/generated/org.apache.felix.dependencymanager.annotation.jar",
 error: java.lang.ClassNotFoundException: 
org.apache.felix.dm.annotation.plugin.bnd.AnnotationPlugin not found, parent:  
java.net.URLClassLoader@258ee7de 
urls:[file:/private/tmp/felix-staging/org.apache.felix.dependencymanager-r11/org.apache.felix.dependencymanager-r11-src/org.apache.felix.dependencymanager.annotation/generated/org.apache.felix.dependencymanager.annotation.jar]
 exception:java.lang.ClassNotFoundException: 
org.apache.felix.dm.annotation.plugin.bnd.AnnotationPlugin
Error  : Cannot load the plugin 
org.apache.felix.dm.annotation.plugin.bnd.AnnotationPlugin
:org.apache.felix.dependencymanager.runtime.itest:compileJava FAILED

FAILURE: Build failed with an exception.
{code}

The build is successful after re-running it again after this exception.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (FELIX-5603) Upgrade User Admin MongoDB Store to be compatible with mongo-java-driver 3.3.0

[J.W. Janssen (JIRA)]

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

J.W. Janssen commented on FELIX-5603:
-

thanks, will take a look at it and apply your PR...

> Upgrade User Admin MongoDB Store to be compatible with mongo-java-driver 3.3.0
> --
>
> Key: FELIX-5603
> URL: https://issues.apache.org/jira/browse/FELIX-5603
> Project: Felix
>  Issue Type: Improvement
>  Components: User Admin
>Reporter: Vladislav Potapov
>
> Current implementation of mongodb store in User Admin is based on 
> mongo-java-driver version 2.8.0 that is incompatible with the MongoDB version 
> 2.6 and above. 
> MongoClient initializaiton is now different and significant number of classes 
> or methods were marked as deprecated or removed. 
> In order to be compatible with the recent MongoDB versions and make it easier 
> to update/maintain it's required to upgrade to mongo-java-driver version 3.x.x



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (FELIX-5336) Add support for prototype scope services in DM4

[J.W. Janssen (JIRA)]

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

J.W. Janssen commented on FELIX-5336:
-

Injecting a ServiceObjects instance would also work for me. The service 
reference would provide me the ability to use the low-level stuff myself, but 
giving me the high-level ServiceObjects would also work :)

If you've anything working, I'd much like to give it a shot...

> Add support for prototype scope services in DM4
> ---
>
> Key: FELIX-5336
> URL: https://issues.apache.org/jira/browse/FELIX-5336
> Project: Felix
>  Issue Type: New Feature
>  Components: Dependency Manager
>Affects Versions: org.apache.felix.dependencymanager-r8
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
> Fix For: org.apache.felix.dependencymanager-r9
>
> Attachments: PrototypeServiceFactoryTest.java
>
>
> In the users mailing list, there is a wish to add support in DM4 for OSGi 
> prototype scope services, which allows any service consumer to get its own 
> instance of a given service dependency.
> See http://www.mail-archive.com/users@felix.apache.org/msg17473.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-5336) Add support for prototype scope services in DM4

[J.W. Janssen (JIRA)]

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

J.W. Janssen commented on FELIX-5336:
-

Hi Pierre, I'm very interested in this functionality as it might solve a 
problem I'm working on. While I could work around using the low-level prototype 
service mechanisms, getting native support from DM would we awesome!

Would it also be possible, for example, to get the service reference of the 
prototype service injected instead of the service directly? This way, we could 
control the lifecycle of the prototype service in our implementation, if 
needed...


> Add support for prototype scope services in DM4
> ---
>
> Key: FELIX-5336
> URL: https://issues.apache.org/jira/browse/FELIX-5336
> Project: Felix
>  Issue Type: New Feature
>  Components: Dependency Manager
>Affects Versions: org.apache.felix.dependencymanager-r8
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
> Fix For: org.apache.felix.dependencymanager-r9
>
> Attachments: PrototypeServiceFactoryTest.java
>
>
> In the users mailing list, there is a wish to add support in DM4 for OSGi 
> prototype scope services, which allows any service consumer to get its own 
> instance of a given service dependency.
> See http://www.mail-archive.com/users@felix.apache.org/msg17473.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-5355) Allow to use properties having dots with configuration proxies

[J.W. Janssen (JIRA)]

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

J.W. Janssen commented on FELIX-5355:
-

I don't think DM should favour one approach over the other. As long as it is 
documented how it can be used I'm fine with supporting both...


> Allow to use properties having dots with configuration proxies
> --
>
> Key: FELIX-5355
> URL: https://issues.apache.org/jira/browse/FELIX-5355
> Project: Felix
>  Issue Type: Improvement
>  Components: Dependency Manager
>Affects Versions: org.apache.felix.dependencymanager-r8
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Minor
> Fix For: org.apache.felix.dependencymanager-r9
>
> Attachments: FELIX-5355.patch
>
>
> Recently, a new feature has been introduced in DM to allow injecting 
> type-safe configuration proxies when a ConfigurationDependency is used (see 
> FELIX-5177).
> The principle is to deduce the name of a given property from a corresponding 
> method name of the configuration proxy interface.
> However, in some cases, you have some component depending on some 
> configuration with properties having some dots ("."), and this character 
> can't be used in java methods. Of course, the properties can be renamed to 
> new names without dots, but in some cases, when you want to use configuration 
> proxies on some legacy components, you often can't modify the existing 
> configuration properties.
> So, I would like to propose the attached patch which allows the support of 
> dots in properties. the patch does the same done by DS: it maps the "\_" 
> charater to ".". And if the property contains "\_" character, then you can 
> use a double "__" underscore:
> For example, assuming you have the two properties in the configuration:
> {code}
> foo.param1=123
> foo_param2=456
> {code}
> then you can use the following method names:
> {code}
> public interface MyConfig {
> public String getFoo_param1(); // maps to "foo.param1"
> public String getFoo__param2(); // maps to "foo_param2"
>}
> {code}
> Is there any objections if I commit the attached patch ?
> thanks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-5355) Allow to use properties having dots with configuration proxies

[J.W. Janssen (JIRA)]

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

J.W. Janssen commented on FELIX-5355:
-

[~djencks]: I wasn't aware of a OSGi standard aside from DS specifying how 
things should be named. 
I'm not sure I see your point in the metatype annotations: if you generate it 
*based* on the DM configuration type, then the naming of those properties 
shouldn't be of any issue? 

> Allow to use properties having dots with configuration proxies
> --
>
> Key: FELIX-5355
> URL: https://issues.apache.org/jira/browse/FELIX-5355
> Project: Felix
>  Issue Type: Improvement
>  Components: Dependency Manager
>Affects Versions: org.apache.felix.dependencymanager-r8
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Minor
> Fix For: org.apache.felix.dependencymanager-r9
>
> Attachments: FELIX-5355.patch
>
>
> Recently, a new feature has been introduced in DM to allow injecting 
> type-safe configuration proxies when a ConfigurationDependency is used (see 
> FELIX-5177).
> The principle is to deduce the name of a given property from a corresponding 
> method name of the configuration proxy interface.
> However, in some cases, you have some component depending on some 
> configuration with properties having some dots ("."), and this character 
> can't be used in java methods. Of course, the properties can be renamed to 
> new names without dots, but in some cases, when you want to use configuration 
> proxies on some legacy components, you often can't modify the existing 
> configuration properties.
> So, I would like to propose the attached patch which allows the support of 
> dots in properties. the patch does the same done by DS: it maps the "\_" 
> charater to ".". And if the property contains "\_" character, then you can 
> use a double "__" underscore:
> For example, assuming you have the two properties in the configuration:
> {code}
> foo.param1=123
> foo_param2=456
> {code}
> then you can use the following method names:
> {code}
> public interface MyConfig {
> public String getFoo_param1(); // maps to "foo.param1"
> public String getFoo__param2(); // maps to "foo_param2"
>}
> {code}
> Is there any objections if I commit the attached patch ?
> thanks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-5355) Allow to use properties having dots with configuration proxies

[J.W. Janssen (JIRA)]

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

J.W. Janssen commented on FELIX-5355:
-

Alternatively, you could use camel casing to adhere to the naming conventions 
used by most Java developers. In this case, {{foo.param1}} can be accessed 
through {{fooParam1()}} or {{getFooParam1()}} and {{foo_param2}} could be 
accessed through {{fooParam2()}} or {{getFooParam2()}}. 

> Allow to use properties having dots with configuration proxies
> --
>
> Key: FELIX-5355
> URL: https://issues.apache.org/jira/browse/FELIX-5355
> Project: Felix
>  Issue Type: Improvement
>  Components: Dependency Manager
>Affects Versions: org.apache.felix.dependencymanager-r8
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Minor
> Fix For: org.apache.felix.dependencymanager-r9
>
> Attachments: FELIX-5355.patch
>
>
> Recently, a new feature has been introduced in DM to allow injecting 
> type-safe configuration proxies when a ConfigurationDependency is used (see 
> FELIX-5177).
> The principle is to deduce the name of a given property from a corresponding 
> method name of the configuration proxy interface.
> However, in some cases, you have some component depending on some 
> configuration with properties having some dots ("."), and this character 
> can't be used in java methods. Of course, the properties can be renamed to 
> new names without dots, but in some cases, when you want to use configuration 
> proxies on some legacy components, you often can't modify the existing 
> configuration properties.
> So, I would like to propose the attached patch which allows the support of 
> dots in properties. the patch does the same done by DS: it maps the "\_" 
> charater to ".". And if the property contains "\_" character, then you can 
> use a double "__" underscore:
> For example, assuming you have the two properties in the configuration:
> {code}
> foo.param1=123
> foo_param2=456
> {code}
> then you can use the following method names:
> {code}
> public interface MyConfig {
> public String getFoo_param1(); // maps to "foo.param1"
> public String getFoo__param2(); // maps to "foo_param2"
>}
> {code}
> Is there any objections if I commit the attached patch ?
> thanks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-5238) ConfigurationDependency should provide the setRequired() method

[J.W. Janssen (JIRA)]

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

J.W. Janssen commented on FELIX-5238:
-

That objection is kind of moot: you can think of lots of use cases where a 
default configuration can be defined that allows your component to function 
properly as-is out of the box. Now, I've to resort to use the "old style" 
ManagedService implementation with all of its boilerplate stuff to get this 
configuration into my component. 

Please go ahead and commit your proposed changes. This discussion has been open 
long enough for everybody to react and object...

> ConfigurationDependency should provide the setRequired() method
> ---
>
> Key: FELIX-5238
> URL: https://issues.apache.org/jira/browse/FELIX-5238
> Project: Felix
>  Issue Type: Improvement
>  Components: Dependency Manager
>Affects Versions: dependencymanager-4.3.0
>Reporter: Guillaume Nodet
>Assignee: Pierre De Rop
> Attachments: FELIX-5238.patch, 
> OptionalConfigurationDependencyTest.java
>
>
> Even though the default required for configuration is {{true}}, there's no 
> reason why it could not be {{false}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-5238) ConfigurationDependency should provide the setRequired() method

[J.W. Janssen (JIRA)]

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

J.W. Janssen commented on FELIX-5238:
-

Apparently there was some discussion off-list about this, which is unfortunate 
because it is now unclear what the pros and cons were of the "Amdatu team". 
However, I'd like to see this functionality very much for the simple reason 
that it allows you to get all the nice goodies that DM provides for 
configurations that are optional. So, +1 from me.

> ConfigurationDependency should provide the setRequired() method
> ---
>
> Key: FELIX-5238
> URL: https://issues.apache.org/jira/browse/FELIX-5238
> Project: Felix
>  Issue Type: Improvement
>  Components: Dependency Manager
>Affects Versions: dependencymanager-4.3.0
>Reporter: Guillaume Nodet
>Assignee: Pierre De Rop
> Attachments: FELIX-5238.patch, 
> OptionalConfigurationDependencyTest.java
>
>
> Even though the default required for configuration is {{true}}, there's no 
> reason why it could not be {{false}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (FELIX-5337) Filter-based dependencies working differently for annotations

[J.W. Janssen (JIRA)]

J.W. Janssen created FELIX-5337:
---

 Summary: Filter-based dependencies working differently for 
annotations
 Key: FELIX-5337
 URL: https://issues.apache.org/jira/browse/FELIX-5337
 Project: Felix
  Issue Type: Bug
Affects Versions: dependencymanager-4.3.0
Reporter: J.W. Janssen


I've got a "catch all" service dependency that simply wants to see *all* 
services being registered. In the activator based implementation I simply 
express my dependency as 
{{createServiceDependency().setService("(objectClass=*)").setRequired(false).setCallbacks("addService",
 "removeService")}} and I get all services I'm interested in (I mean: each and 
every registered service).

However, if I rewrite my code to use annotations using 
{{@ServiceDependency(filter="(objectClass=*)", required = false, removed = 
...)}}, I suddenly do not see all services I expect: only services that seem to 
be compatible with the class-space of the bundle my code lives in.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (FELIX-5305) Direct injection of services fails when service properties are updated

[J.W. Janssen (JIRA)]

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

J.W. Janssen resolved FELIX-5305.
-
Resolution: Fixed

Tested the trunk of DM against the provided Bnd sample workspace and the issue 
no longer appears.

> Direct injection of services fails when service properties are updated
> --
>
> Key: FELIX-5305
> URL: https://issues.apache.org/jira/browse/FELIX-5305
> Project: Felix
>  Issue Type: Bug
>  Components: Dependency Manager
>Affects Versions: org.apache.felix.dependencymanager-r1
>Reporter: J.W. Janssen
>Assignee: Pierre De Rop
> Attachments: FELIX-5305.tgz
>
>
> Consider the following scenario: I've got a service, say, {{ServiceA}}, that 
> is instantiated through configuration by means of a 
> FactoryConfigurationAdapterService. The configuration-update callback manages 
> the service properties of the actual service (it is not propagated).
> Another service, {{ServiceB}}, has a dependency on all instances of ServiceA. 
> I use the direct field injection feature of DM to give me a map of all 
> instances.
> If I update the service properties of any of the {{ServiceA}} instances, I 
> lose them from my instance-map. The configuration is updated, but the 
> instance never is injected back into my map (or my map is not injected back).
> When rewriting {{ServiceB}} to use plain callbacks, all changes are properly 
> tracked.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (FELIX-5305) Direct injection of services fails when service properties are updated

[J.W. Janssen (JIRA)]

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

J.W. Janssen updated FELIX-5305:

Attachment: FELIX-5305.tgz

Sample Bnd workspace that demonstrates the issue. Usage:

- start the {{local.bndrun}} file;
- run {{getMessages}} in the gogo console;
- there are three results reported;
- run {{stop 1}} & {{start 1}} (this triggers the configuration update);
- run {{getMessages}} again;
- observe that there *no* results reported.

> Direct injection of services fails when service properties are updated
> --
>
> Key: FELIX-5305
> URL: https://issues.apache.org/jira/browse/FELIX-5305
> Project: Felix
>  Issue Type: Bug
>  Components: Dependency Manager
>Affects Versions: dependencymanager-4.3.0
>Reporter: J.W. Janssen
> Attachments: FELIX-5305.tgz
>
>
> Consider the following scenario: I've got a service, say, {{ServiceA}}, that 
> is instantiated through configuration by means of a 
> FactoryConfigurationAdapterService. The configuration-update callback manages 
> the service properties of the actual service (it is not propagated).
> Another service, {{ServiceB}}, has a dependency on all instances of ServiceA. 
> I use the direct field injection feature of DM to give me a map of all 
> instances.
> If I update the service properties of any of the {{ServiceA}} instances, I 
> lose them from my instance-map. The configuration is updated, but the 
> instance never is injected back into my map (or my map is not injected back).
> When rewriting {{ServiceB}} to use plain callbacks, all changes are properly 
> tracked.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (FELIX-5305) Direct injection of services fails when service properties are updated

[J.W. Janssen (JIRA)]

J.W. Janssen created FELIX-5305:
---

 Summary: Direct injection of services fails when service 
properties are updated
 Key: FELIX-5305
 URL: https://issues.apache.org/jira/browse/FELIX-5305
 Project: Felix
  Issue Type: Bug
  Components: Dependency Manager
Affects Versions: dependencymanager-4.3.0
Reporter: J.W. Janssen


Consider the following scenario: I've got a service, say, {{ServiceA}}, that is 
instantiated through configuration by means of a 
FactoryConfigurationAdapterService. The configuration-update callback manages 
the service properties of the actual service (it is not propagated).

Another service, {{ServiceB}}, has a dependency on all instances of ServiceA. I 
use the direct field injection feature of DM to give me a map of all instances.

If I update the service properties of any of the {{ServiceA}} instances, I lose 
them from my instance-map. The configuration is updated, but the instance never 
is injected back into my map (or my map is not injected back).

When rewriting {{ServiceB}} to use plain callbacks, all changes are properly 
tracked.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (FELIX-5282) Shell does not handle package refreshes correctly.

[J.W. Janssen (JIRA)]

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

J.W. Janssen updated FELIX-5282:

Component/s: Gogo Shell

> Shell does not handle package refreshes correctly.
> --
>
> Key: FELIX-5282
> URL: https://issues.apache.org/jira/browse/FELIX-5282
> Project: Felix
>  Issue Type: Bug
>  Components: Gogo Shell
>Affects Versions: gogo.shell-0.14.0
>Reporter: J.W. Janssen
>Priority: Critical
>
> When embedding Gogo shell in an executable JAR (using bnd export 
> functionality), the shell does not work correctly after stopping and 
> restarting the framework. It appears that some I/O threads are retained 
> incorrectly:
> {quote}
> gosh: java.lang.IllegalStateException: session is closed
> gosh: stopping framework
> gogo: IllegalStateException: Invalid BundleContext.
> java.lang.IllegalStateException: Invalid BundleContext.
>   at 
> org.apache.felix.framework.BundleContextImpl.checkValidity(BundleContextImpl.java:511)
>   at 
> org.apache.felix.framework.BundleContextImpl.getBundle(BundleContextImpl.java:175)
>   at org.apache.felix.gogo.shell.Shell.shutdown(Shell.java:183)
>   at org.apache.felix.gogo.shell.Shell.gosh(Shell.java:170)
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (FELIX-5282) Shell does not handle package refreshes correctly.

[J.W. Janssen (JIRA)]

J.W. Janssen created FELIX-5282:
---

 Summary: Shell does not handle package refreshes correctly.
 Key: FELIX-5282
 URL: https://issues.apache.org/jira/browse/FELIX-5282
 Project: Felix
  Issue Type: Bug
Affects Versions: gogo.shell-0.14.0
Reporter: J.W. Janssen
Priority: Critical


When embedding Gogo shell in an executable JAR (using bnd export 
functionality), the shell does not work correctly after stopping and restarting 
the framework. It appears that some I/O threads are retained incorrectly:
{quote}
gosh: java.lang.IllegalStateException: session is closed
gosh: stopping framework
gogo: IllegalStateException: Invalid BundleContext.
java.lang.IllegalStateException: Invalid BundleContext.
at 
org.apache.felix.framework.BundleContextImpl.checkValidity(BundleContextImpl.java:511)
at 
org.apache.felix.framework.BundleContextImpl.getBundle(BundleContextImpl.java:175)
at org.apache.felix.gogo.shell.Shell.shutdown(Shell.java:183)
at org.apache.felix.gogo.shell.Shell.gosh(Shell.java:170)
{quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (FELIX-4399) UserAdmin MongoDB plugin cannot return role when properties or members is null

[J.W. Janssen (JIRA)]

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

J.W. Janssen updated FELIX-4399:

Fix Version/s: useradmin-mongo-next

> UserAdmin MongoDB plugin cannot return role when properties or members is null
> --
>
> Key: FELIX-4399
> URL: https://issues.apache.org/jira/browse/FELIX-4399
> Project: Felix
>  Issue Type: Bug
>  Components: User Admin
> Environment: MongoDB 32-bit, v2.4.9
> Java 1.7
> UserAdmin 1.0.3
>Reporter: Alec de Zegher
>Assignee: J.W. Janssen
> Fix For: useradmin-mongo-next
>
>   Original Estimate: 5m
>  Remaining Estimate: 5m
>
> When fetching a role with no properties or roles from mongodb, a null object 
> is returned by the DB. This causes a null pointer exception and as a result 
> no roles are returned.
> This can be solved by modifying following three methods in 
> MongoSerializerHelper.java to:
> /**
>  * Deserializes the given {@link DBObject} into the given {@link 
> Dictionary}.
>  * 
>  * @param dictionary the dictionary to fill;
>  * @param object the {@link DBObject} to deserialize.
>  */
> private void deserializeDictionary(Dictionary dictionary, DBObject 
> object) {
> if(object != null) {
>   for (String key : object.keySet()) {
>   dictionary.put(KeyCodec.decode(key), object.get(key));
>   }
> }
> }
> 
> /**
>  * Serializes a given array of {@link Role}s to an list for storing in a 
> {@link DBObject}.
>  * 
>  * @param members the {@link Role}s to serialize, cannot be 
> null.
>  * @return the "serialized" array, never null.
>  */
> private List getRoleNames(Role[] members) {
> List result = new ArrayList();
> if (members != null) {
> for (Role member : members) {
> result.add(member.getName());
> }
> }
> return result;
> }
> 
> /**
>  * Returns all roles mentioned in the given list.
>  * 
>  * @param list the list with role names to convert.
>  * @return a list with {@link Role}s, never null.
>  */
> private List getRoles(BasicDBList list) {
> List result = new ArrayList();
> if(list !=null) {
>   for (int i = 0, size = list.size(); i < size; i++) {
>   final String memberName = (String) list.get(i);
>   result.add(findExistingMember(memberName));
>   }
> }
> return result;
> }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (FELIX-4279) UserAdmin does not export OSGi packages

[J.W. Janssen (JIRA)]

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

J.W. Janssen updated FELIX-4279:

Fix Version/s: useradmin-next

> UserAdmin does not export OSGi packages
> ---
>
> Key: FELIX-4279
> URL: https://issues.apache.org/jira/browse/FELIX-4279
> Project: Felix
>  Issue Type: Bug
>  Components: User Admin
>Reporter: J.W. Janssen
>Assignee: J.W. Janssen
>Priority: Critical
> Fix For: useradmin-next
>
>
> The Felix UserAdmin bundle does not export the `org.osgi.service.useradmin` 
> package. This means that a compendium bundle should always be deployed along 
> with this bundle.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (FELIX-4280) UserAdmin has hard dependency on EventAdmin

[J.W. Janssen (JIRA)]

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

J.W. Janssen updated FELIX-4280:

Fix Version/s: useradmin-next

> UserAdmin has hard dependency on EventAdmin
> ---
>
> Key: FELIX-4280
> URL: https://issues.apache.org/jira/browse/FELIX-4280
> Project: Felix
>  Issue Type: Bug
>  Components: User Admin
>Reporter: J.W. Janssen
>Assignee: J.W. Janssen
> Fix For: useradmin-next
>
>
> The import requirements of Felix UserAdmin require 
> `org.osgi.service.eventadmin` as well. This is not required by the UserAdmin 
> 1.1 specification and therefore should be optional.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (FELIX-3802) Remove MongoDB dependency from NOTICE file

[J.W. Janssen (JIRA)]

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

J.W. Janssen updated FELIX-3802:

Fix Version/s: useradmin-mongo-next

> Remove MongoDB dependency from NOTICE file
> --
>
> Key: FELIX-3802
> URL: https://issues.apache.org/jira/browse/FELIX-3802
> Project: Felix
>  Issue Type: Task
>  Components: User Admin
>Reporter: J.W. Janssen
> Fix For: useradmin-mongo-next
>
>
> The MongoDB-based store lists a dependency on MongoDB in its NOTICE file. 
> This isn't necessary/wanted and should be removed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-5177) Support injecting configuration proxies

[J.W. Janssen (JIRA)]

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

J.W. Janssen commented on FELIX-5177:
-

[~pderop]: I'll start reworking the factory pid adapter, no problem! I'll 
attach a patch when I'm done with it...

> Support injecting configuration proxies
> ---
>
> Key: FELIX-5177
> URL: https://issues.apache.org/jira/browse/FELIX-5177
> Project: Felix
>  Issue Type: Improvement
>  Components: Dependency Manager, Dependency Manager Annotations, 
> Dependency Manager Lambda, Dependency Manager Runtime
>Reporter: J.W. Janssen
>Assignee: Pierre De Rop
> Fix For:  org.apache.felix.dependencymanager-r7
>
> Attachments: FELIX-5177.patch
>
>
> DM supports mandatory configurations, but does not allow anything other than 
> a dictionary to be passed to the callback. In other DI frameworks (like DS) 
> it is possible to use type-safe configurations and let those be injected 
> instead of plain dictionaries.
> It would be great if DM also would support this, as it would remove lots of 
> configuration boiler plate code from our projects.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-5177) Support injecting configuration proxies

[J.W. Janssen (JIRA)]

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

J.W. Janssen commented on FELIX-5177:
-

Thanks for the update, [~pderop]! I'd be happy to assist you in fixing the 
additional steps, just let me know what I can do...

> Support injecting configuration proxies
> ---
>
> Key: FELIX-5177
> URL: https://issues.apache.org/jira/browse/FELIX-5177
> Project: Felix
>  Issue Type: Improvement
>  Components: Dependency Manager, Dependency Manager Annotations, 
> Dependency Manager Lambda, Dependency Manager Runtime
>Reporter: J.W. Janssen
>Assignee: Pierre De Rop
> Fix For:  org.apache.felix.dependencymanager-r7
>
> Attachments: FELIX-5177.patch
>
>
> DM supports mandatory configurations, but does not allow anything other than 
> a dictionary to be passed to the callback. In other DI frameworks (like DS) 
> it is possible to use type-safe configurations and let those be injected 
> instead of plain dictionaries.
> It would be great if DM also would support this, as it would remove lots of 
> configuration boiler plate code from our projects.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-5177) Support injecting configuration proxies

[J.W. Janssen (JIRA)]

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

J.W. Janssen commented on FELIX-5177:
-

[~pderop]: no problem; note that you probably want to move to unit test for the 
Configurable class as well...

> Support injecting configuration proxies
> ---
>
> Key: FELIX-5177
> URL: https://issues.apache.org/jira/browse/FELIX-5177
> Project: Felix
>  Issue Type: Improvement
>  Components: Dependency Manager Runtime
>Reporter: J.W. Janssen
> Attachments: FELIX-5177.patch
>
>
> DM supports mandatory configurations, but does not allow anything other than 
> a dictionary to be passed to the callback. In other DI frameworks (like DS) 
> it is possible to use type-safe configurations and let those be injected 
> instead of plain dictionaries.
> It would be great if DM also would support this, as it would remove lots of 
> configuration boiler plate code from our projects.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-5177) Support injecting configuration proxies

[J.W. Janssen (JIRA)]

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

J.W. Janssen commented on FELIX-5177:
-

Upgrading to:

java version "1.8.0_71"
Java(TM) SE Runtime Environment (build 1.8.0_71-b15)
Java HotSpot(TM) 64-Bit Server VM (build 25.71-b15, mixed mode)

solves the build/test issue. This might be a good thing to document on the site 
;)

> Support injecting configuration proxies
> ---
>
> Key: FELIX-5177
> URL: https://issues.apache.org/jira/browse/FELIX-5177
> Project: Felix
>  Issue Type: Improvement
>  Components: Dependency Manager Runtime
>Reporter: J.W. Janssen
> Attachments: FELIX-5177.patch
>
>
> DM supports mandatory configurations, but does not allow anything other than 
> a dictionary to be passed to the callback. In other DI frameworks (like DS) 
> it is possible to use type-safe configurations and let those be injected 
> instead of plain dictionaries.
> It would be great if DM also would support this, as it would remove lots of 
> configuration boiler plate code from our projects.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-5177) Support injecting configuration proxies

[J.W. Janssen (JIRA)]

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

J.W. Janssen commented on FELIX-5177:
-

My java info:
{{[jawi@machine:felix-trunk/dependencymanager (trunk)]$ java -version
java version "1.8.0_45"
Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)}}

I'm running the same steps as you, only using the gradle-wrapper in the project 
root.

Looking into the test-results, I see the following error:
{{
  

[jira] [Comment Edited] (FELIX-5177) Support injecting configuration proxies

[J.W. Janssen (JIRA)]

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

J.W. Janssen edited comment on FELIX-5177 at 2/4/16 4:22 PM:
-

My java info:
[jawi@machine:felix-trunk/dependencymanager (trunk)]$ java -version
java version "1.8.0_45"
Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)

I'm running the same steps as you, only using the gradle-wrapper in the project 
root.

Looking into the test-results, I see the following error:

  

[jira] [Resolved] (FELIX-5173) Metatype service's BundleResources ignore properties provided by fragment bundles

[J.W. Janssen (JIRA)]

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

J.W. Janssen resolved FELIX-5173.
-
Resolution: Fixed

Fixed in rev #1728499 & #1728500.

> Metatype service's BundleResources ignore properties provided by fragment 
> bundles
> -
>
> Key: FELIX-5173
> URL: https://issues.apache.org/jira/browse/FELIX-5173
> Project: Felix
>  Issue Type: Bug
>  Components: Metatype Service
>Affects Versions: metatype-1.1.2
>Reporter: Olaf Otto
>Priority: Minor
> Fix For: metatype-1.1.4
>
>
> OSGi Fragment bundles may - rather similar to OSGI bundles contributing 
> Resource Bundles for i18n - add translated properties for metatype services 
> to a host bundle. Also, fragment bundles may add declarative service to a 
> host bundle, thus having to contribute the corresponding properties.
> However, the current BundleResources implementation exclusively loads 
> properties from the declaring (host) bundle using "getEntry(...)":
> {code}
> URL resURL = this.bundle.getEntry(resourceName);
> ...
> {code}
> Instead, getResource(...) should be used, which takes into account resources 
> contributed by fragments.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (FELIX-5173) Metatype service's BundleResources ignore properties provided by fragment bundles

[J.W. Janssen (JIRA)]

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

J.W. Janssen updated FELIX-5173:

Fix Version/s: metatype-1.1.4

> Metatype service's BundleResources ignore properties provided by fragment 
> bundles
> -
>
> Key: FELIX-5173
> URL: https://issues.apache.org/jira/browse/FELIX-5173
> Project: Felix
>  Issue Type: Bug
>  Components: Metatype Service
>Affects Versions: metatype-1.1.2
>Reporter: Olaf Otto
>Priority: Minor
> Fix For: metatype-1.1.4
>
>
> OSGi Fragment bundles may - rather similar to OSGI bundles contributing 
> Resource Bundles for i18n - add translated properties for metatype services 
> to a host bundle. Also, fragment bundles may add declarative service to a 
> host bundle, thus having to contribute the corresponding properties.
> However, the current BundleResources implementation exclusively loads 
> properties from the declaring (host) bundle using "getEntry(...)":
> {code}
> URL resURL = this.bundle.getEntry(resourceName);
> ...
> {code}
> Instead, getResource(...) should be used, which takes into account resources 
> contributed by fragments.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-5177) Support injecting configuration proxies

[J.W. Janssen (JIRA)]

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

J.W. Janssen commented on FELIX-5177:
-

BTW: the patch is against the trunk of Felix (rev #1728498). 

I couldn't do a full test as there are currently test errors in the 
lambda.itest project.

> Support injecting configuration proxies
> ---
>
> Key: FELIX-5177
> URL: https://issues.apache.org/jira/browse/FELIX-5177
> Project: Felix
>  Issue Type: Improvement
>  Components: Dependency Manager Runtime
>Reporter: J.W. Janssen
> Attachments: FELIX-5177.patch
>
>
> DM supports mandatory configurations, but does not allow anything other than 
> a dictionary to be passed to the callback. In other DI frameworks (like DS) 
> it is possible to use type-safe configurations and let those be injected 
> instead of plain dictionaries.
> It would be great if DM also would support this, as it would remove lots of 
> configuration boiler plate code from our projects.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (FELIX-5177) Support injecting configuration proxies

[J.W. Janssen (JIRA)]

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

J.W. Janssen updated FELIX-5177:

Attachment: FELIX-5177.patch

I've attached my patch.

Some documentation: 

The approach is to take a map or dictionary along with a class, the 
configuration-type, and return a proxy that converts method calls from the 
configuration-type to lookups in the map or dictionary. The results of these 
lookups are then converted to the expected return type of the invoked 
configuration method. As proxies are returned, no implementations of the 
desired configuration-type are necessary!

To make this work, a new interface method on {{ConfigurationDependency}} is 
defined that has the following signature: {{setCallback(Object instance, String 
callback, Class configType)}}. This will make sure that the proper method is 
called with the correct configuration type. If this method is not used, the 
current/old behaviour is used.

The lookups performed are based on the name of the method called on the 
configuration type. The method names are "mangled" to the following form: 
{{(lower case letter) (any valid character)*}}. Method names starting with get 
or is (JavaBean convention) are stripped from these prefixes. For example: 
given a dictionary with the key "foo" can be accessed from a configuration-type 
using the following method names: {{foo()}}, {{getFoo()}} and {{isFoo()}}.

The return values supported are: primitive types (or their object wrappers), 
strings, enums, arrays of primitives/strings, Collection types, Map types, 
Classes and interfaces. When an interface is returned, it is treated equally to 
a configuration type, that is, it is returned as a proxy where lookups are 
performed against the original map or dictionary.

Arrays can be represented either as comma-separated values, optionally enclosed 
in square brackets. For example: {{[ a, b, c ]}} and {{a,b,c}} are both 
considered an array of length 3 with the values "a", "b" and "c". 
Alternatively, you can append the array index to the key in the dictionary to 
obtain the same: a dictionary with {{"arr.0" => "a", "arr.1" => "b", "arr.2" => 
"c"}} would result in the same array as the earlier examples.

Maps can be represented as single string values similarly as arrays, each value 
consisting of both the key and value separated by a dot. Optionally, the value 
can be enclosed in curly brackets. Similar to array, you can use the same dot 
notation using the keys. For example, a dictionary with {{"map" => 
"key1.value1, key2.value2"}} and a dictionary with {{"map.key1" => "value1", 
"map2.key2" => "value2"}} result in the same map being returned. Instead of a 
map, you could also define an interface with the methods {{getKey1()}} and 
{{getKey2()}} and use that interface as return type instead of a Map.

In case a lookup does not yield a value from the underlying map or dictionary, 
the following rules are applied:

# primitive types yield their default value, as defined by the Java 
Specification;
# string, Classes and enum values yield {{null}};
# for arrays, collections and maps, an empty array/collection/map is returned;
# for other interface types that are treated as configuration type a 
null-object is returned.


> Support injecting configuration proxies
> ---
>
> Key: FELIX-5177
> URL: https://issues.apache.org/jira/browse/FELIX-5177
> Project: Felix
>  Issue Type: Improvement
>  Components: Dependency Manager Runtime
>Reporter: J.W. Janssen
> Attachments: FELIX-5177.patch
>
>
> DM supports mandatory configurations, but does not allow anything other than 
> a dictionary to be passed to the callback. In other DI frameworks (like DS) 
> it is possible to use type-safe configurations and let those be injected 
> instead of plain dictionaries.
> It would be great if DM also would support this, as it would remove lots of 
> configuration boiler plate code from our projects.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-5177) Support injecting configuration proxies

[J.W. Janssen (JIRA)]

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

J.W. Janssen commented on FELIX-5177:
-

I'm currently working on a patch for this and got the basic principals already 
working. Need some cleanups and additional tests after which I'll add it to 
this issue.

> Support injecting configuration proxies
> ---
>
> Key: FELIX-5177
> URL: https://issues.apache.org/jira/browse/FELIX-5177
> Project: Felix
>  Issue Type: Improvement
>  Components: Dependency Manager Runtime
>Reporter: J.W. Janssen
>
> DM supports mandatory configurations, but does not allow anything other than 
> a dictionary to be passed to the callback. In other DI frameworks (like DS) 
> it is possible to use type-safe configurations and let those be injected 
> instead of plain dictionaries.
> It would be great if DM also would support this, as it would remove lots of 
> configuration boiler plate code from our projects.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (FELIX-5177) Support injecting configuration proxies

[J.W. Janssen (JIRA)]

J.W. Janssen created FELIX-5177:
---

 Summary: Support injecting configuration proxies
 Key: FELIX-5177
 URL: https://issues.apache.org/jira/browse/FELIX-5177
 Project: Felix
  Issue Type: Improvement
  Components: Dependency Manager Runtime
Reporter: J.W. Janssen


DM supports mandatory configurations, but does not allow anything other than a 
dictionary to be passed to the callback. In other DI frameworks (like DS) it is 
possible to use type-safe configurations and let those be injected instead of 
plain dictionaries.

It would be great if DM also would support this, as it would remove lots of 
configuration boiler plate code from our projects.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (FELIX-5175) Sessions are incorrectly destroyed

[J.W. Janssen (JIRA)]

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

J.W. Janssen resolved FELIX-5175.
-
Resolution: Fixed

Solved in rev #1727299.

> Sessions are incorrectly destroyed
> --
>
> Key: FELIX-5175
> URL: https://issues.apache.org/jira/browse/FELIX-5175
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Affects Versions: http.base-3.0.6
>Reporter: J.W. Janssen
>Assignee: J.W. Janssen
> Fix For: http.base-3.0.8
>
>
> HttpSessionWrapper contains a static member, getExpiredSessionContextIds, 
> that determines which sessions should be destroyed based on the timeouts that 
> are set on each session.
> The implementation incorrectly assumes these timeouts are in milliseconds, 
> while the timeouts are actually set in seconds (see JavaDoc of HttpSession). 
> This means that a timeout of 300 (5 minutes) is interpreted as 300 
> milliseconds, resulting in sessions being destroyed too soon.
> (Found through ACE-528)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (FELIX-5175) Sessions are incorrectly destroyed

[J.W. Janssen (JIRA)]

J.W. Janssen created FELIX-5175:
---

 Summary: Sessions are incorrectly destroyed
 Key: FELIX-5175
 URL: https://issues.apache.org/jira/browse/FELIX-5175
 Project: Felix
  Issue Type: Bug
  Components: HTTP Service
Affects Versions: http.base-3.0.6
Reporter: J.W. Janssen
Assignee: J.W. Janssen
 Fix For: http.base-3.0.8


HttpSessionWrapper contains a static member, getExpiredSessionContextIds, that 
determines which sessions should be destroyed based on the timeouts that are 
set on each session.

The implementation incorrectly assumes these timeouts are in milliseconds, 
while the timeouts are actually set in seconds (see JavaDoc of HttpSession). 
This means that a timeout of 300 (5 minutes) is interpreted as 300 
milliseconds, resulting in sessions being destroyed too soon.

(Found through ACE-528)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-3494) Missing motd should not produce error message

[J.W. Janssen (JIRA)]

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

J.W. Janssen commented on FELIX-3494:
-

Actually, the idea is that you include your own gosh_profile in case you want 
custom behaviour. However, it could be handy that you sometimes want to 
suppress the printing of the motd when starting Gogo.
I've added an option (`-q` or `--quiet`) to suppress printing the motd in rev 
#1725549. 

> Missing motd should not produce error message
> -
>
> Key: FELIX-3494
> URL: https://issues.apache.org/jira/browse/FELIX-3494
> Project: Felix
>  Issue Type: Improvement
>  Components: Gogo Shell
> Environment: Mac OS X, Java 6, Virgo kernel, Gogo 0.10.0
>Reporter: Glyn Normington
>Priority: Minor
>
> After upgrading from Gogo 0.8.0.v201105062003 to 0.10.0, an error message is 
> displayed when logging in to the shell. It would be nice if no error message 
> was produced if no motd is provided as the documentation 
> (http://felix.apache.org/site/apache-felix-gogo.html) does not say how to 
> disable the motd.
> The error message is, for example:
> jar:file:/Users/glynnormington/eclipse/virgo/org.eclipse.virgo.kernel/build-kernel/target/package-expanded/virgo-kernel-3.5.0.BUILD-20120430124155/plugins/org.apache.felix.gogo.shell_0.10.0.jar!/gosh_profile:
> ERROR: java.io.FileNotFoundException:
> /Users/glynnormington/eclipse/virgo/org.eclipse.virgo.kernel/build-kernel/target/package-expanded/virgo-kernel-3.5.0.BUILD-20120430124155/motd
> (No such file or directory)
> See the related bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=378076



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (FELIX-3494) Missing motd should not produce error message

[J.W. Janssen (JIRA)]

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

J.W. Janssen resolved FELIX-3494.
-
Resolution: Fixed

> Missing motd should not produce error message
> -
>
> Key: FELIX-3494
> URL: https://issues.apache.org/jira/browse/FELIX-3494
> Project: Felix
>  Issue Type: Improvement
>  Components: Gogo Shell
> Environment: Mac OS X, Java 6, Virgo kernel, Gogo 0.10.0
>Reporter: Glyn Normington
>Priority: Minor
>
> After upgrading from Gogo 0.8.0.v201105062003 to 0.10.0, an error message is 
> displayed when logging in to the shell. It would be nice if no error message 
> was produced if no motd is provided as the documentation 
> (http://felix.apache.org/site/apache-felix-gogo.html) does not say how to 
> disable the motd.
> The error message is, for example:
> jar:file:/Users/glynnormington/eclipse/virgo/org.eclipse.virgo.kernel/build-kernel/target/package-expanded/virgo-kernel-3.5.0.BUILD-20120430124155/plugins/org.apache.felix.gogo.shell_0.10.0.jar!/gosh_profile:
> ERROR: java.io.FileNotFoundException:
> /Users/glynnormington/eclipse/virgo/org.eclipse.virgo.kernel/build-kernel/target/package-expanded/virgo-kernel-3.5.0.BUILD-20120430124155/motd
> (No such file or directory)
> See the related bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=378076



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (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

[J.W. Janssen (JIRA)]

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

J.W. Janssen closed FELIX-1582.
---
Resolution: Fixed

Closing as requested.

> [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 Runtime
>Reporter: Guillaume Nodet
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (FELIX-4345) Add support for IPv4 and IPv6 addresses for console

[J.W. Janssen (JIRA)]

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

J.W. Janssen resolved FELIX-4345.
-
Resolution: Fixed

Fixed in rev #1725532.

> Add support for IPv4 and IPv6 addresses for console
> ---
>
> Key: FELIX-4345
> URL: https://issues.apache.org/jira/browse/FELIX-4345
> Project: Felix
>  Issue Type: Improvement
>  Components: Gogo Shell
>Affects Versions: gogo.shell-0.10.0
>Reporter: Alex Blewitt
>Priority: Trivial
>
> The telnetd server only listens to IPv4 or IPv6 because the default value for 
> the --ip parameter is "".
> Even though 'localhost' resolves to both ::1 and 127.0.0.1, passing in "" for 
> the address results in it picking one of them.
> If the value is 'null' for the IP address then it will resolve and bind to 
> both network addresses.
> The bug is here:
> 118   server = new ServerSocket(port, 0, InetAddress.getByName(ip));
> This should be:
> InetAddress address = "".equals(ip) ?  null : 
> InetAddress.getByName(p);
> 118   server = new ServerSocket(port, 0, address);



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (FELIX-2536) Gogo Shell should export org.apache.felix.gogo.options package

[J.W. Janssen (JIRA)]

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

J.W. Janssen closed FELIX-2536.
---
Resolution: Fixed

I agree with [~rickhall] on this: you're welcome to reuse the `Options` class 
for your own use cases, but I don't see the value of having it to be exported 
by default.

> Gogo Shell should export org.apache.felix.gogo.options package
> --
>
> Key: FELIX-2536
> URL: https://issues.apache.org/jira/browse/FELIX-2536
> Project: Felix
>  Issue Type: Improvement
>  Components: Gogo Shell
>Reporter: David Savage
>Priority: Minor
> Fix For: gogo.shell-0.14.0
>
>
> The Gogo shell bundle includes a helpful utility class to handle Options 
> parsing in the gogo environment.
> org.apache.felix.gogo.options.Options
> final String[] usage = {
> "test - test Options usage",
> "  text before Usage: is displayed when usage() is called and no 
> error has occurred.",
> "  so can be used as a simple help message.",
> "",
> "Usage: testOptions [OPTION]... PATTERN [FILES]...",
> "  Output control: arbitary non-option text can be included.",
> "  -? --helpshow help",
> "  -c --count=COUNT   show COUNT lines",
> "  -h --no-filename suppress the prefixing filename on 
> output",
> "  -q --quiet, --silent suppress all normal output",
> " --binary-files=TYPE   assume that binary files are TYPE",
> "   TYPE is 'binary', 'text', or 
> 'without-match'",
> "  -I   equivalent to 
> --binary-files=without-match",
> "  -d --directories=ACTION  how to handle directories 
> (default=skip)",
> "   ACTION is 'read', 'recurse', or 
> 'skip'",
> "  -D --devices=ACTION  how to handle devices, FIFOs and 
> sockets",
> "   ACTION is 'read' or 'skip'",
> "  -R, -r --recursive   equivalent to --directories=recurse" 
> };
> Option opt = Options.compile(usage).parse(args);
> if (opt.isSet("help")) {
> opt.usage(); // includes text before Usage:
> return;
> }
> if (opt.args().size() == 0)
> throw opt.usageError("PATTERN not specified");
> System.out.println(opt);
> if (opt.isSet("count"))
> System.out.println("count = " + opt.getNumber("count"));
> System.out.println("--directories specified: " + 
> opt.isSet("directories"));
> System.out.println("directories=" + opt.get("directories"));
> However the package containing this class is not exported from this bundle so 
> it cannot be used by client code



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (FELIX-4208) The Gogo shell thread doesn't stop when Gogo Shell bundle is stopped.

[J.W. Janssen (JIRA)]

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

J.W. Janssen resolved FELIX-4208.
-
Resolution: Fixed

> The Gogo shell thread doesn't stop when Gogo Shell bundle is stopped.
> -
>
> Key: FELIX-4208
> URL: https://issues.apache.org/jira/browse/FELIX-4208
> Project: Felix
>  Issue Type: Bug
>  Components: Gogo Shell
>Affects Versions: gogo.shell-0.10.0
> Environment: Equinox
>Reporter: Radoslaw Stachowiak
>Priority: Critical
>
> The Gogo shell thread doesn't stop when Gogo Shell bundle is stopped.
> This is  problem when using Gogo shell with Equinox.
> In Felix, the bundle starting thread is a daemon thread, so Gogo shell thread 
> is also a daemon thread and when Felix is shutdown, the virtual machine 
> closes.
> However in Equinox the bundle starting thread is a normal thread, so Gogo 
> shell thread is also a normal thread and when Equinox is shutdown, the 
> virtual machine doesn't close, because Gogo shell thread doesn't close (hangs 
> on blocking I/O trying to read from InputStream).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (FELIX-4024) Refreshing Gogo shell bundle leaves running daemon thread

[J.W. Janssen (JIRA)]

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

J.W. Janssen resolved FELIX-4024.
-
Resolution: Fixed

I think this issue is solved with the fixes for FELIX-5077 / FELIX-3331. That 
is: I cannot reproduce this issue with these changes...

> Refreshing Gogo shell bundle leaves running daemon thread
> -
>
> Key: FELIX-4024
> URL: https://issues.apache.org/jira/browse/FELIX-4024
> Project: Felix
>  Issue Type: Bug
>  Components: Gogo Shell
>Affects Versions: gogo.shell-0.8.0, gogo.shell-0.10.0
>Reporter: Lazar Kirchev
>
> In the Activator of the Gogo shell bundle a new thread is created (line 122) 
> and started (line 123). The thread instance is stored and upon bundle stop it 
> is interrupted (line 54). 
> However, the thread which is created on line 122 is daemon, so after 
> interruption on line 54 it does not go away. So each time the bundle is 
> refreshed a new thread is created and started, but the old one continues to 
> live. In this way a bunch of "Gogo shell" threads get created. These compete 
> for input from the std in and the commands are not read correctly.
> The line nubmers are valid for 0.8.0 and 0.10.0 versions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (FELIX-4375) Error when reading gosh_profile from stream

[J.W. Janssen (JIRA)]

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

J.W. Janssen resolved FELIX-4375.
-
Resolution: Fixed

Applied a slightly different version of your proposed patch in rev #1725519.

> Error when reading gosh_profile from stream
> ---
>
> Key: FELIX-4375
> URL: https://issues.apache.org/jira/browse/FELIX-4375
> Project: Felix
>  Issue Type: Bug
>  Components: Gogo Shell
>Affects Versions: gogo.shell-0.10.0
> Environment: Error occurred using Gogo shell on top op Concierge OSGi 
> runtime.
>Reporter: Tim Verbelen
>Priority: Minor
>
> An error occurs when "gosh_profile" is read from a stream without knowing the 
> lenght upfront. In that case, method `CharSequence readScript(URI script)` 
> from `Shell.java` causes an error, since it does not correctly handle the 
> case when the length is -1. In that case, a large size buffer is allocated 
> (fixed on 10240 atm), and thus as the buffer will not be completely filled, 
> one cannot use `cbuf.rewind()`, but use `cbuf.flip()` instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (FELIX-3354) InterruptedException with uninformative message

[J.W. Janssen (JIRA)]

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

J.W. Janssen resolved FELIX-3354.
-
Resolution: Fixed

No longer an issue with the fixes for FELIX-5077 / FELIX-3331. The 
InterruptedException is caught and properly handled.

> InterruptedException with uninformative message
> ---
>
> Key: FELIX-3354
> URL: https://issues.apache.org/jira/browse/FELIX-3354
> Project: Felix
>  Issue Type: Improvement
>  Components: Gogo Shell
>Affects Versions: gogo.shell-0.8.0
>Reporter: Lazar Kirchev
>Priority: Minor
>
> When the OSGi framework, in which the Gogo shell is started, is stopped 
> before the Gogo shell has finished initializing, the following exception 
> occurs:
> gogo: InterruptedException: sleep interrupted
> java.lang.InterruptedException: sleep interrupted
>   at java.lang.Thread.sleep(Native Method)
>   at org.apache.felix.gogo.shell.Activator.run(Activator.java:72)
>   at java.lang.Thread.run(Unknown Source)
> gogo.shell calls Thread.sleep(100) to wait for the gosh command to be 
> registered. The exception occurs when this wait gets interrupted by the 
> stopping of the framework. 
> Since the framework is stopping this interruption does not cause any errors, 
> but the message is not informative and users are getting confused that it is 
> caused by an error in their code.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (FELIX-3331) [gogo] Calling Activator.stop after Activator.start throws an exception

[J.W. Janssen (JIRA)]

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

J.W. Janssen resolved FELIX-3331.
-
Resolution: Fixed

Fixed in rev #1725510.

> [gogo] Calling Activator.stop after Activator.start throws an exception
> ---
>
> Key: FELIX-3331
> URL: https://issues.apache.org/jira/browse/FELIX-3331
> Project: Felix
>  Issue Type: Bug
>  Components: Gogo Shell
>Reporter: Krzysztof Daniel
> Attachments: ignoreActivatorException.patch
>
>
> https://bugzilla.redhat.com/show_bug.cgi?id=786041
> gogo: InterruptedException: sleep interrupted
> java.lang.InterruptedException: sleep interrupted
> at java.lang.Thread.sleep(Native Method)
> at org.apache.felix.gogo.shell.Activator.run(Activator.java:72)
> at java.lang.Thread.run(Thread.java:722)
> Thread.sleep() could be try catched and handle interrupted exception as a 
> proper workflow.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (FELIX-3331) [gogo] Calling Activator.stop after Activator.start throws an exception

[J.W. Janssen (JIRA)]

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

J.W. Janssen updated FELIX-3331:

Component/s: Gogo Shell

> [gogo] Calling Activator.stop after Activator.start throws an exception
> ---
>
> Key: FELIX-3331
> URL: https://issues.apache.org/jira/browse/FELIX-3331
> Project: Felix
>  Issue Type: Bug
>  Components: Gogo Shell
>Reporter: Krzysztof Daniel
> Attachments: ignoreActivatorException.patch
>
>
> https://bugzilla.redhat.com/show_bug.cgi?id=786041
> gogo: InterruptedException: sleep interrupted
> java.lang.InterruptedException: sleep interrupted
> at java.lang.Thread.sleep(Native Method)
> at org.apache.felix.gogo.shell.Activator.run(Activator.java:72)
> at java.lang.Thread.run(Thread.java:722)
> Thread.sleep() could be try catched and handle interrupted exception as a 
> proper workflow.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (FELIX-5077) Gogo shell prints out nasty error on shutdown

[J.W. Janssen (JIRA)]

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

J.W. Janssen resolved FELIX-5077.
-
Resolution: Fixed

Fixed in rev #1725510.


> Gogo shell prints out nasty error on shutdown
> -
>
> Key: FELIX-5077
> URL: https://issues.apache.org/jira/browse/FELIX-5077
> Project: Felix
>  Issue Type: Bug
>  Components: Gogo Shell
>Affects Versions: gogo.shell-0.12.0
>Reporter: David Bosschaert
>Assignee: J.W. Janssen
>
> The gogo shell always prints out a nasty error to the System.err stream on 
> framework shutdown:
> {code}$ java -jar bin/felix.jar
> 
> Welcome to Apache Felix Gogo
> g! stop 0
> g! !!! FAILED TO STOP EXECUTOR !!!{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (FELIX-5169) AutoConf incorrectly references constants from DeploymentAdmin

[J.W. Janssen (JIRA)]

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

J.W. Janssen resolved FELIX-5169.
-
Resolution: Fixed

Fixed in rev #1724974.

> AutoConf incorrectly references constants from DeploymentAdmin
> --
>
> Key: FELIX-5169
> URL: https://issues.apache.org/jira/browse/FELIX-5169
> Project: Felix
>  Issue Type: Bug
>  Components: Deployment Admin
>Affects Versions: autoconf-rp-0.1.6
>Reporter: J.W. Janssen
>Assignee: J.W. Janssen
> Fix For: autoconf-rp-0.1.8
>
>
> The autoconf resource processor references the constants class from 
> DeploymentAdmin. The package of this class is not exported, causing wiring 
> issues when deploying the autoconf resource processor at runtime.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (FELIX-5169) AutoConf incorrectly references constants from DeploymentAdmin

[J.W. Janssen (JIRA)]

J.W. Janssen created FELIX-5169:
---

 Summary: AutoConf incorrectly references constants from 
DeploymentAdmin
 Key: FELIX-5169
 URL: https://issues.apache.org/jira/browse/FELIX-5169
 Project: Felix
  Issue Type: Bug
  Components: Deployment Admin
Affects Versions: autoconf-rp-0.1.6
Reporter: J.W. Janssen
Assignee: J.W. Janssen
 Fix For: autoconf-rp-0.1.8


The autoconf resource processor references the constants class from 
DeploymentAdmin. The package of this class is not exported, causing wiring 
issues when deploying the autoconf resource processor at runtime.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (FELIX-3330) Allow autoconf to somehow resolve which configuration to send to which ConfigurationAdmin in case there is more than one

[J.W. Janssen (JIRA)]

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

J.W. Janssen updated FELIX-3330:

Component/s: Deployment Admin

> Allow autoconf to somehow resolve which configuration to send to which 
> ConfigurationAdmin in case there is more than one
> 
>
> Key: FELIX-3330
> URL: https://issues.apache.org/jira/browse/FELIX-3330
> Project: Felix
>  Issue Type: Task
>  Components: Deployment Admin
>Reporter: Marcel Offermans
>Assignee: Marcel Offermans
>
> For now, autoconf assumes there is only one single ConfigurationAdmin service 
> available, or if there are more it will pick the "best" one (according to the 
> normal OSGi rules). However, there might be more than one ConfigurationAdmin 
> service in the framework, and we might want to be able to send specific 
> pieces of configuration to specific ConfigurationAdmin services. This is not 
> defined in the spec, but it would be nice if we can extend our implementation 
> to support this in a compatible way.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (FELIX-3329) Allow the autoconf resource processor to defer the setting of the configuration until ConfigurationAdmin is available

[J.W. Janssen (JIRA)]

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

J.W. Janssen updated FELIX-3329:

Component/s: Deployment Admin

> Allow the autoconf resource processor to defer the setting of the 
> configuration until ConfigurationAdmin is available
> -
>
> Key: FELIX-3329
> URL: https://issues.apache.org/jira/browse/FELIX-3329
> Project: Felix
>  Issue Type: Task
>  Components: Deployment Admin
>Reporter: Marcel Offermans
>Assignee: Marcel Offermans
> Attachments: FELIX-3329_ResourceDeleteNPE.patch
>
>
> Right now, autoconf will always fail if you start out with an empty container 
> and install a deployment package with all your bundles, including 
> configuration data and ConfigurationAdmin, because at the time it tries to 
> find the ConfigurationAdmin service, that won't be started yet. A solution 
> would be to (in that case) defer setting the configuration until the service 
> becomes available. The downside of this is that we never know for sure if 
> this will work.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (FELIX-518) Wrong processing order of Localization-, Bundle and Processed-Resources

[J.W. Janssen (JIRA)]

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

J.W. Janssen updated FELIX-518:
---
Fix Version/s: deploymentadmin-0.9.8

> Wrong processing order of Localization-, Bundle and Processed-Resources
> ---
>
> Key: FELIX-518
> URL: https://issues.apache.org/jira/browse/FELIX-518
> Project: Felix
>  Issue Type: Bug
>  Components: Deployment Admin
> Environment: Maven version: 2.0.8
> Java version: 1.6.0_04
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
>Reporter: Siamak Haschemi
>Assignee: J.W. Janssen
> Fix For: deploymentadmin-0.9.8
>
> Attachments: gps_deployment_package-0.0.1-SNAPSHOT.dp
>
>
> The DeploymentAdmin specification defines in Section 114.3 (File Format), 
> Page 340 and 341, the order of resources in the Jar as follows:
> 1 META-INF/MANIFEST.MF 
> 2 META-INF/*.SF, META-INF/*.DSA, META-INF/*.RS 
> 3 Localization files
> 4 Bundles 
> 5 Resources
> The current DeploymentAdmin implementation processes the contents of the 
> JarInputStream with the UpdateCommand (handles bundles) and the 
> ProcessResourceCommand (handles resources). If the Jar contains 
> Localization-Resources (which are placed before any other resource or bundle) 
> the UpdateCommand failes, because assumes that the Bundles come at first in 
> the JarInputStream.
> As a result a DeploymentException with the message "Resource '...' is not 
> described in the manifest." is thrown.
> Kind regards,
> Siamak Haschemi



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (FELIX-518) Wrong processing order of Localization-, Bundle and Processed-Resources

[J.W. Janssen (JIRA)]

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

J.W. Janssen resolved FELIX-518.

Resolution: Fixed

Updated DA to correctly handle localised and/or signed deployment packages. 
Added some utility code to test the installation of signed deployment packages.

> Wrong processing order of Localization-, Bundle and Processed-Resources
> ---
>
> Key: FELIX-518
> URL: https://issues.apache.org/jira/browse/FELIX-518
> Project: Felix
>  Issue Type: Bug
>  Components: Deployment Admin
> Environment: Maven version: 2.0.8
> Java version: 1.6.0_04
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
>Reporter: Siamak Haschemi
>Assignee: J.W. Janssen
> Attachments: gps_deployment_package-0.0.1-SNAPSHOT.dp
>
>
> The DeploymentAdmin specification defines in Section 114.3 (File Format), 
> Page 340 and 341, the order of resources in the Jar as follows:
> 1 META-INF/MANIFEST.MF 
> 2 META-INF/*.SF, META-INF/*.DSA, META-INF/*.RS 
> 3 Localization files
> 4 Bundles 
> 5 Resources
> The current DeploymentAdmin implementation processes the contents of the 
> JarInputStream with the UpdateCommand (handles bundles) and the 
> ProcessResourceCommand (handles resources). If the Jar contains 
> Localization-Resources (which are placed before any other resource or bundle) 
> the UpdateCommand failes, because assumes that the Bundles come at first in 
> the JarInputStream.
> As a result a DeploymentException with the message "Resource '...' is not 
> described in the manifest." is thrown.
> Kind regards,
> Siamak Haschemi



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (FELIX-518) Wrong processing order of Localization-, Bundle and Processed-Resources

[J.W. Janssen (JIRA)]

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

J.W. Janssen reassigned FELIX-518:
--

Assignee: J.W. Janssen  (was: Christian van Spaandonk)

> Wrong processing order of Localization-, Bundle and Processed-Resources
> ---
>
> Key: FELIX-518
> URL: https://issues.apache.org/jira/browse/FELIX-518
> Project: Felix
>  Issue Type: Bug
>  Components: Deployment Admin
> Environment: Maven version: 2.0.8
> Java version: 1.6.0_04
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
>Reporter: Siamak Haschemi
>Assignee: J.W. Janssen
> Attachments: gps_deployment_package-0.0.1-SNAPSHOT.dp
>
>
> The DeploymentAdmin specification defines in Section 114.3 (File Format), 
> Page 340 and 341, the order of resources in the Jar as follows:
> 1 META-INF/MANIFEST.MF 
> 2 META-INF/*.SF, META-INF/*.DSA, META-INF/*.RS 
> 3 Localization files
> 4 Bundles 
> 5 Resources
> The current DeploymentAdmin implementation processes the contents of the 
> JarInputStream with the UpdateCommand (handles bundles) and the 
> ProcessResourceCommand (handles resources). If the Jar contains 
> Localization-Resources (which are placed before any other resource or bundle) 
> the UpdateCommand failes, because assumes that the Bundles come at first in 
> the JarInputStream.
> As a result a DeploymentException with the message "Resource '...' is not 
> described in the manifest." is thrown.
> Kind regards,
> Siamak Haschemi



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (FELIX-4516) Update command fails for non-bundle resource

[J.W. Janssen (JIRA)]

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

J.W. Janssen closed FELIX-4516.
---
Resolution: Not A Problem

Closing this issue as it is using the spec incorrectly. Please reopen if this 
problem this exists in the upcoming versions of DA.

> Update command fails for non-bundle resource
> 
>
> Key: FELIX-4516
> URL: https://issues.apache.org/jira/browse/FELIX-4516
> Project: Felix
>  Issue Type: Bug
>  Components: Deployment Admin
>Affects Versions: deploymentadmin-0.9.6
>Reporter: Norman Fomferra
> Attachments: com.acme.toolbox-1.0.4.jar
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> I have a deployment package containg two bundles and an image resource. All 
> three resources are listed in the manifest 
> in the given order. When trying to install the package, the 
> UpdateCommand.doExecute() thows the following exception:   
> {noformat}
> org.osgi.service.deploymentadmin.DeploymentException: Resource 'icon.png' is 
> not described in the manifest.
>   at 
> org.apache.felix.deploymentadmin.spi.UpdateCommand.doExecute(UpdateCommand.java:69)
>   at org.apache.felix.deploymentadmin.spi.Command.execute(Command.java:55)
>   at 
> org.apache.felix.deploymentadmin.spi.DeploymentSessionImpl.call(DeploymentSessionImpl.java:77)
>   at 
> org.apache.felix.deploymentadmin.DeploymentAdminImpl.installDeploymentPackage(DeploymentAdminImpl.java:214)
>   at org.teo.obr.DpCommand.installFromFile(DpCommand.java:153)
> {noformat}
> The exception is thrown in 
> org/apache/felix/deploymentadmin/spi/UpdateCommand.java(line 69) once the 
> current JAR
> entry is not the name of an expected bundle:
>  
> {code:java}
> 66  String name = entry.getPath();
> 67  BundleInfoImpl bundleInfo = (BundleInfoImpl) expectedBundles.remove(name);
> 68  if (bundleInfo == null) {
> 69  throw new DeploymentException(DeploymentException.CODE_OTHER_ERROR, 
> "Resource '" + name + "' is not described...");
> 70  }
> {code}
> The code should check first if the current JAR entry points to any other 
> resource in the manifest before assuming 
> it points to a bundle.  
> Issue FELIX-518 is closely created, if not the same.
> Thanks!
>Norman



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (FELIX-4912) Upgrade autoconf to Dependency Manager 4

[J.W. Janssen (JIRA)]

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

J.W. Janssen resolved FELIX-4912.
-
   Resolution: Fixed
Fix Version/s: deploymentadmin-0.9.8

Committed a slightly different fix which solves not only this issue, but also a 
couple of other problems, such as wrong parent POMs, etc.

> Upgrade autoconf to Dependency Manager 4
> 
>
> Key: FELIX-4912
> URL: https://issues.apache.org/jira/browse/FELIX-4912
> Project: Felix
>  Issue Type: Improvement
>  Components: Deployment Admin
>Affects Versions: deploymentadmin-0.9.6
>Reporter: Sander Mak
>Assignee: J.W. Janssen
> Fix For: deploymentadmin-0.9.8
>
> Attachments: FELIX-4912.patch
>
>
> I want to use org.apache.felix.deployment.rp.autoconf with DM4, but currently 
> it is built against DM3.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (FELIX-4912) Upgrade autoconf to Dependency Manager 4

[J.W. Janssen (JIRA)]

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

J.W. Janssen reassigned FELIX-4912:
---

Assignee: J.W. Janssen

> Upgrade autoconf to Dependency Manager 4
> 
>
> Key: FELIX-4912
> URL: https://issues.apache.org/jira/browse/FELIX-4912
> Project: Felix
>  Issue Type: Improvement
>  Components: Deployment Admin
>Affects Versions: deploymentadmin-0.9.6
>Reporter: Sander Mak
>Assignee: J.W. Janssen
> Attachments: FELIX-4912.patch
>
>
> I want to use org.apache.felix.deployment.rp.autoconf with DM4, but currently 
> it is built against DM3.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (FELIX-5077) Gogo shell prints out nasty error on shutdown

[J.W. Janssen (JIRA)]

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

J.W. Janssen reassigned FELIX-5077:
---

Assignee: J.W. Janssen

> Gogo shell prints out nasty error on shutdown
> -
>
> Key: FELIX-5077
> URL: https://issues.apache.org/jira/browse/FELIX-5077
> Project: Felix
>  Issue Type: Bug
>  Components: Gogo Shell
>Affects Versions: gogo.shell-0.12.0
>Reporter: David Bosschaert
>Assignee: J.W. Janssen
>
> The gogo shell always prints out a nasty error to the System.err stream on 
> framework shutdown:
> {code}$ java -jar bin/felix.jar
> 
> Welcome to Apache Felix Gogo
> g! stop 0
> g! !!! FAILED TO STOP EXECUTOR !!!{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-4994) Use JDK Logger in spite of System.out

[J.W. Janssen (JIRA)]

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

J.W. Janssen commented on FELIX-4994:
-

Why not commons-logging, or slf4j, or any other logging framework?

I'd rather would propose to omit logging to the console at all. If people want 
to have logging, they can use the LogService. If they want to use slf4j, or 
commons-logging, or JUL, they should implement a bridge from LogService to that 
framework...

> Use JDK Logger in spite of System.out
> -
>
> Key: FELIX-4994
> URL: https://issues.apache.org/jira/browse/FELIX-4994
> Project: Felix
>  Issue Type: Improvement
>  Components: HTTP Service
>Affects Versions: http-2.3.2, http-2.4.0
> Environment: Linux, JDK 1.7, Felix 4.6.1
>Reporter: Enrique Ruiz (DiSiD Technologies S.L.)
>
> If `LogServiceLogger` doesn't have a reference to the `LogService` it 
> delegates on `ConsoleLogger`.
> The problems are:
> * The `ConsoleLogger` writes the messages to `System.out`
> * We cannot configure the log verbosity
> I think it would be better if `ConsoleLogger` would use the 
> `java.util.logging.Logger`.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (FELIX-4946) Updates in service ranking not picked up by filters

[J.W. Janssen (JIRA)]

J.W. Janssen created FELIX-4946:
---

 Summary: Updates in service ranking not picked up by filters
 Key: FELIX-4946
 URL: https://issues.apache.org/jira/browse/FELIX-4946
 Project: Felix
  Issue Type: Bug
  Components: HTTP Service
Affects Versions: http.jetty-3.0.2, http-2.3.2
Reporter: J.W. Janssen


If I change the service ranking of a registered filter at runtime, it does not 
change the order in which the filter chain is executed. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-4925) Request path is not decoded

[J.W. Janssen (JIRA)]

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

J.W. Janssen commented on FELIX-4925:
-

[~cziegeler]: returning the servletPath + pathInfo sounds like the soundest 
option to me as well...

> Request path is not decoded
> ---
>
> Key: FELIX-4925
> URL: https://issues.apache.org/jira/browse/FELIX-4925
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: http.base-3.0.0, http.jetty-3.1.0
>
>
> The dispatcher servlet currently uses req.getRequestURI() to get the full 
> path of the request. However this information is not decoded and therefore 
> when the path contains unicode characters the encoded version is used instead 
> of the real path.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-4863) SSLFilter 0.1.0 and 0.2.0 have a Java race condition, stopping the Filter from working correctly

[J.W. Janssen (JIRA)]

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

J.W. Janssen commented on FELIX-4863:
-

Could you explain the problem in a little more detail? What reproduction steps 
are there, what stacktrace(s) do you see, etc...

> SSLFilter 0.1.0 and 0.2.0 have a Java race condition, stopping the Filter 
> from working correctly
> 
>
> Key: FELIX-4863
> URL: https://issues.apache.org/jira/browse/FELIX-4863
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Reporter: Antonio Sanso
>
> There is a Java race condition, where if the wrong method "wins", the 
> configuration does not get applied.
> The SSL Filter (which is supposed to override certain Request/Response 
> methods) does not work, causing mapping failures, wrong URLs, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-4546) Implement HttpServiceRuntime service

[J.W. Janssen (JIRA)]

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

J.W. Janssen commented on FELIX-4546:
-

applied patch of [~tkb] in rev #1669088.

> Implement HttpServiceRuntime service
> 
>
> Key: FELIX-4546
> URL: https://issues.apache.org/jira/browse/FELIX-4546
> Project: Felix
>  Issue Type: Sub-task
>  Components: HTTP Service
>Reporter: David Bosschaert
>Assignee: Carsten Ziegeler
> Fix For: http.base-3.0.0
>
> Attachments: felix-4546.e2a36d1.81e5a8f.patch, 
> felix-4546.failure_dtos.patch, felix-4546.resource_dto.patch, patch.txt
>
>
> Implement the Http Service Runtime service as described in RFC 189



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-4829) Gogo command error logging to available LogService

[J.W. Janssen (JIRA)]

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

J.W. Janssen commented on FELIX-4829:
-

Yes, something like that. But, why not log to all available log services? They 
are probably registered for a reason :)


>  Gogo command error logging to available LogService
> ---
>
> Key: FELIX-4829
> URL: https://issues.apache.org/jira/browse/FELIX-4829
> Project: Felix
>  Issue Type: Improvement
>  Components: Gogo Command
>Reporter: Kamesh Sampath
>Priority: Minor
> Attachments: FELIX-4829.patch
>
>
> As Felix Gogo shell user I would like gogo commands to log the exceptions to 
> an available log service in addition to Sys.err, this enables the 
> LogListeners of the clients to capture and manipulate the log if required



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-4829) Gogo command error logging to available LogService

[J.W. Janssen (JIRA)]

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

J.W. Janssen commented on FELIX-4829:
-

there is a flaw in your proposed patch: if the log service goes away or is 
started later than Gogo, it won't be picked up by this command. I think you 
should use a ServiceTracker and ask for *all* of its services if you are in 
need of logging something. 

In addition, I think there are a couple of more places whether exceptions can 
occur (all commands that are invoked by Gogo?), shouldn't these be logged as 
well?


>  Gogo command error logging to available LogService
> ---
>
> Key: FELIX-4829
> URL: https://issues.apache.org/jira/browse/FELIX-4829
> Project: Felix
>  Issue Type: Improvement
>  Components: Gogo Command
>Reporter: Kamesh Sampath
>Priority: Minor
> Attachments: FELIX-4829.patch
>
>
> As Felix Gogo shell user I would like gogo commands to log the exceptions to 
> an available log service in addition to Sys.err, this enables the 
> LogListeners of the clients to capture and manipulate the log if required



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-4797) Enable client certificate requesting without verifying the certificates

[J.W. Janssen (JIRA)]

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

J.W. Janssen commented on FELIX-4797:
-

[~reto] thanks for the patch, but I think it can be done even more simpler and 
with the current released version of Felix HTTP Jetty bundle: by registering a 
ConnectorFactory. I've added a sample project to demonstrate this, see 
.
 

> Enable client certificate requesting without verifying the certificates
> ---
>
> Key: FELIX-4797
> URL: https://issues.apache.org/jira/browse/FELIX-4797
> Project: Felix
>  Issue Type: Improvement
>  Components: HTTP Service
>Reporter: Pascal Mainini
>Priority: Minor
>  Labels: patch
> Attachments: 
> 0001-Patch-enabling-client-certificate-authentication-wit.patch, 
> enabling-sslContext-services.patch
>
>
> This is a patch enabling requesting client certificate authentication without 
> further validation of the certificates provided by the client. Rationale:
> Enabling requests of client certificates by setting 
> "org.apache.felix.https.clientcertificate" to "wants" or "needs" requests a 
> client-certificate from any connecting client. Depending on the value set, 
> this is either an optional or mandatory step to be fulfilled by the client in 
> order to have it's HTTP-request further processed. 
> The client-certificate obtained is validated against either the 
> CA-certificates found in the truststore or - if none given - by the server's 
> certificate itself.
> For some usecases, this validation is unsuitable or not possible at all, 
> namely for supporting WebID-style (https://en.wikipedia.org/wiki/WebID) 
> authorization processed by a servlet within the container. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-4541) Add support for multiple patterns in servlet/filter registration

[J.W. Janssen (JIRA)]

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

J.W. Janssen commented on FELIX-4541:
-

No problem...

> Add support for multiple patterns in servlet/filter registration
> 
>
> Key: FELIX-4541
> URL: https://issues.apache.org/jira/browse/FELIX-4541
> Project: Felix
>  Issue Type: Sub-task
>  Components: HTTP Service
>Reporter: J.W. Janssen
> Fix For: http.base-3.0.0
>
> Attachments: FELIX-4541.patch
>
>
> RFC-189 allows servlets and filters to be registered with multiple paths (and 
> even regex's for filters).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-4541) Add support for multiple patterns in servlet/filter registration

[J.W. Janssen (JIRA)]

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

J.W. Janssen commented on FELIX-4541:
-

[~cziegeler] [~ralucav] : hmm, I didn't know that. If Raluca creates a new 
patch, she can do this against the current trunk. This issue is still work in 
progress, so I don't think we need to revert the applied one...


> Add support for multiple patterns in servlet/filter registration
> 
>
> Key: FELIX-4541
> URL: https://issues.apache.org/jira/browse/FELIX-4541
> Project: Felix
>  Issue Type: Sub-task
>  Components: HTTP Service
>Reporter: J.W. Janssen
> Fix For: http.base-3.0.0
>
> Attachments: FELIX-4541.patch
>
>
> RFC-189 allows servlets and filters to be registered with multiple paths (and 
> even regex's for filters).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-4541) Add support for multiple patterns in servlet/filter registration

[J.W. Janssen (JIRA)]

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

J.W. Janssen commented on FELIX-4541:
-

Applied the patch from Raluca in rev #1665462.

> Add support for multiple patterns in servlet/filter registration
> 
>
> Key: FELIX-4541
> URL: https://issues.apache.org/jira/browse/FELIX-4541
> Project: Felix
>  Issue Type: Sub-task
>  Components: HTTP Service
>Reporter: J.W. Janssen
> Fix For: http.base-3.0.0
>
> Attachments: FELIX-4541.patch
>
>
> RFC-189 allows servlets and filters to be registered with multiple paths (and 
> even regex's for filters).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-4546) Implement HttpServiceRuntime service

[J.W. Janssen (JIRA)]

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

J.W. Janssen commented on FELIX-4546:
-

I've applied the patch from Thomas to the trunk, see rev #1661116.

While at it, fixed a couple of trivial issues in the itests, the number of 
failing ones is down to three...


> Implement HttpServiceRuntime service
> 
>
> Key: FELIX-4546
> URL: https://issues.apache.org/jira/browse/FELIX-4546
> Project: Felix
>  Issue Type: Sub-task
>  Components: HTTP Service
>Reporter: David Bosschaert
>Assignee: Carsten Ziegeler
> Fix For: http-next
>
> Attachments: felix-4546.e2a36d1.81e5a8f.patch, patch.txt
>
>
> Implement the Http Service Runtime service as described in RFC 189



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (FELIX-4799) Support for multiple factory designates in single MetaType file

[J.W. Janssen (JIRA)]

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

J.W. Janssen resolved FELIX-4799.
-
Resolution: Fixed

Solved in rev #1660612.

> Support for multiple factory designates in single MetaType file
> ---
>
> Key: FELIX-4799
> URL: https://issues.apache.org/jira/browse/FELIX-4799
> Project: Felix
>  Issue Type: Bug
>  Components: Metatype Service
>Reporter: J.W. Janssen
>Assignee: J.W. Janssen
> Fix For: metatype-1.0.12
>
>
> A MetaType file can contain multiple designates for both non-factory and 
> factory PIDs. The {{MetaData}} object returned by {{MetaDataReader}} returns 
> a map of all designates found in the file, using the (factory) PID as key. In 
> case multiple designates exist for the same factory PID, obviously only one 
> is returned.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (FELIX-4799) Support for multiple factory designates in single MetaType file

[J.W. Janssen (JIRA)]

J.W. Janssen created FELIX-4799:
---

 Summary: Support for multiple factory designates in single 
MetaType file
 Key: FELIX-4799
 URL: https://issues.apache.org/jira/browse/FELIX-4799
 Project: Felix
  Issue Type: Bug
  Components: Metatype Service
Reporter: J.W. Janssen
Assignee: J.W. Janssen
 Fix For: metatype-1.0.12


A MetaType file can contain multiple designates for both non-factory and 
factory PIDs. The {{MetaData}} object returned by {{MetaDataReader}} returns a 
map of all designates found in the file, using the (factory) PID as key. In 
case multiple designates exist for the same factory PID, obviously only one is 
returned.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-4797) Enable client certificate requesting without verifying the certificates

[J.W. Janssen (JIRA)]

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

J.W. Janssen commented on FELIX-4797:
-

[~pascal.mainini]: not sure what you are trying to solve exactly here: by 
simply trusting *any* certificate that the client provides without any 
validation, you basically are very much susceptible to MitM attacks, not?

> Enable client certificate requesting without verifying the certificates
> ---
>
> Key: FELIX-4797
> URL: https://issues.apache.org/jira/browse/FELIX-4797
> Project: Felix
>  Issue Type: Improvement
>  Components: HTTP Service
>Reporter: Pascal Mainini
>Priority: Minor
>  Labels: patch
> Attachments: 
> 0001-Patch-enabling-client-certificate-authentication-wit.patch
>
>
> This is a patch enabling requesting client certificate authentication without 
> further validation of the certificates provided by the client. Rationale:
> Enabling requests of client certificates by setting 
> "org.apache.felix.https.clientcertificate" to "wants" or "needs" requests a 
> client-certificate from any connecting client. Depending on the value set, 
> this is either an optional or mandatory step to be fulfilled by the client in 
> order to have it's HTTP-request further processed. 
> The client-certificate obtained is validated against either the 
> CA-certificates found in the truststore or - if none given - by the server's 
> certificate itself.
> For some usecases, this validation is unsuitable or not possible at all, 
> namely for supporting WebID-style (https://en.wikipedia.org/wiki/WebID) 
> authorization processed by a servlet within the container. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Issue Comment Deleted] (FELIX-4798) Support async servlets (filters)

[J.W. Janssen (JIRA)]

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

J.W. Janssen updated FELIX-4798:

Comment: was deleted

(was: [~cziegeler]: IIRC, there is already support for async servlets in the 
current HTTP service. What does this issue need to solve in addition to that?)

> Support async servlets (filters)
> 
>
> Key: FELIX-4798
> URL: https://issues.apache.org/jira/browse/FELIX-4798
> Project: Felix
>  Issue Type: Task
>  Components: HTTP Service
>Reporter: Carsten Ziegeler
> Fix For: http-next
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-4798) Support async servlets (filters)

[J.W. Janssen (JIRA)]

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

J.W. Janssen commented on FELIX-4798:
-

[~cziegeler]: IIRC, there is already support for async servlets in the current 
HTTP service. What does this issue need to solve in addition to that?

> Support async servlets (filters)
> 
>
> Key: FELIX-4798
> URL: https://issues.apache.org/jira/browse/FELIX-4798
> Project: Felix
>  Issue Type: Task
>  Components: HTTP Service
>Reporter: Carsten Ziegeler
> Fix For: http-next
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-4798) Support async servlets (filters)

[J.W. Janssen (JIRA)]

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

J.W. Janssen commented on FELIX-4798:
-

[~cziegeler]: IIRC, there is already support for async servlets in the current 
HTTP service. What does this issue need to solve in addition to that?

> Support async servlets (filters)
> 
>
> Key: FELIX-4798
> URL: https://issues.apache.org/jira/browse/FELIX-4798
> Project: Felix
>  Issue Type: Task
>  Components: HTTP Service
>Reporter: Carsten Ziegeler
> Fix For: http-next
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-4687) Support v. 1.3 metatype namespace

[J.W. Janssen (JIRA)]

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

J.W. Janssen commented on FELIX-4687:
-

Did glance through the latest drafts of the spec, but couldn't find any major 
things that are waiting to be implemented... Is there more work expected for 
this issue? 

> Support v. 1.3 metatype namespace
> -
>
> Key: FELIX-4687
> URL: https://issues.apache.org/jira/browse/FELIX-4687
> Project: Felix
>  Issue Type: New Feature
>  Components: Metatype Service
>Affects Versions: metatype-1.0.10
>Reporter: David Jencks
>Assignee: David Jencks
> Fix For: metatype-1.0.12
>
>
> Support the R6 v 1.3 metatype schema version.  The changes currently are:
> - new namespace
> - AD are now optional (not currently validated on earlier versions)
> - AD type "Char" spelling corrected to "Character".
> In line with the Eclipse metatype service I'm going to allow both "Character" 
> and 'Char" in any namespace.  If anyone objects I'm happy to change this to 
> validate which namespace each is valid under.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-3471) Support Schema validation for MetaData XML documents

[J.W. Janssen (JIRA)]

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

J.W. Janssen commented on FELIX-3471:
-

I've added some additional validations regarding missing elements, such as 
Objects and ADs (for MetaType < v1.3). While this does not come near a "real" 
schema validation, it already rejects most common errors in an early stage.

> Support Schema validation for MetaData XML documents
> 
>
> Key: FELIX-3471
> URL: https://issues.apache.org/jira/browse/FELIX-3471
> Project: Felix
>  Issue Type: Bug
>  Components: Metatype Service
>Affects Versions: metatype-1.0.4
>Reporter: Alexandre Castro Alves
>
> MetaData XML documents are not being W3C Schema-validated.
> Provide option for doing so.
> Thanks
> Alex



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (FELIX-3471) Support Schema validation for MetaData XML documents

[J.W. Janssen (JIRA)]

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

J.W. Janssen edited comment on FELIX-3471 at 1/21/15 4:28 PM:
--

I've added some additional validations regarding missing elements, such as 
Objects and ADs (for MetaType < v1.3). While this does not come near a "real" 
schema validation, it already rejects most common errors in an early stage.
Is there a need for additional validations, as it appears almost impossible to 
do real XMLSchema validations?


was (Author: jajans):
I've added some additional validations regarding missing elements, such as 
Objects and ADs (for MetaType < v1.3). While this does not come near a "real" 
schema validation, it already rejects most common errors in an early stage.

> Support Schema validation for MetaData XML documents
> 
>
> Key: FELIX-3471
> URL: https://issues.apache.org/jira/browse/FELIX-3471
> Project: Felix
>  Issue Type: Bug
>  Components: Metatype Service
>Affects Versions: metatype-1.0.4
>Reporter: Alexandre Castro Alves
>
> MetaData XML documents are not being W3C Schema-validated.
> Provide option for doing so.
> Thanks
> Alex



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (FELIX-4665) Metatype service does not allow a default empty string in XML resource

[J.W. Janssen (JIRA)]

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

J.W. Janssen resolved FELIX-4665.
-
   Resolution: Fixed
Fix Version/s: metatype-1.0.12

Fixed in rev #1653581.

> Metatype service does not allow a default empty string in XML resource
> --
>
> Key: FELIX-4665
> URL: https://issues.apache.org/jira/browse/FELIX-4665
> Project: Felix
>  Issue Type: Bug
>  Components: Metatype Service
>Affects Versions: metatype-1.0.10
>Reporter: David Humeniuk
> Fix For: metatype-1.0.12
>
>
> An entry like the following will be treated as invalid and the default will 
> change to null instead of an empty string:
> {code}
>  type="String" description="Some string property"/>
> {code}
> MetaDataReader.readAD() method will first set the default value, then later 
> check if the value is required:
> {code}
> ad.setDefaultValue( this.getOptionalAttribute( "default" ) );
> ad.setRequired( this.getOptionalAttribute( "required", true ) );
> {code}
> However, setDefaultValue method will check if the value is required (before 
> it is known) in ADValidator.validateString():
> {code}
> if (ad.isRequired() && ((value == null) || (length == 0)))
> {
> // Possible if the cardinality != 0 and input was something like
> // "0,,1"...
> return AD.VALIDATE_MISSING;
> }
> {code}
> The call to isRequired() will always be true at the time of the call.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (FELIX-4644) Designates with multiple Objects

[J.W. Janssen (JIRA)]

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

J.W. Janssen updated FELIX-4644:

Fix Version/s: metatype-1.0.12

> Designates with multiple Objects
> 
>
> Key: FELIX-4644
> URL: https://issues.apache.org/jira/browse/FELIX-4644
> Project: Felix
>  Issue Type: Bug
>  Components: Metatype Service
>Affects Versions: metatype-1.0.10
>Reporter: J.W. Janssen
> Fix For: metatype-1.0.12
>
>
> MetaType (schema) specifies a Designate tag should have only one Object tag. 
> This is currently not validated, and in case of multiple Object tags not even 
> detectable making external validation difficult to implement.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (FELIX-4644) Designates with multiple Objects

[J.W. Janssen (JIRA)]

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

J.W. Janssen resolved FELIX-4644.
-
Resolution: Fixed

Fixed in rev #1653489.

> Designates with multiple Objects
> 
>
> Key: FELIX-4644
> URL: https://issues.apache.org/jira/browse/FELIX-4644
> Project: Felix
>  Issue Type: Bug
>  Components: Metatype Service
>Affects Versions: metatype-1.0.10
>Reporter: J.W. Janssen
>
> MetaType (schema) specifies a Designate tag should have only one Object tag. 
> This is currently not validated, and in case of multiple Object tags not even 
> detectable making external validation difficult to implement.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-3464) Raise exception when a Designate's OCDREF points to non-existing OCD

[J.W. Janssen (JIRA)]

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

J.W. Janssen commented on FELIX-3464:
-

As far as I understand the spec, the OCD might not be included in a MetaType 
file, but provided externally. The use case I see in this is: a bundle 
registers a MetaType resource, for which an AutoConf file is used to define a 
(configuration) instance. In this situation, we cannot simply validate the 
{{ocdref}} using only its value...

> Raise exception when a Designate's OCDREF points to non-existing OCD
> 
>
> Key: FELIX-3464
> URL: https://issues.apache.org/jira/browse/FELIX-3464
> Project: Felix
>  Issue Type: Bug
>  Components: Metatype Service
>Affects Versions: metatype-1.0.4
>Reporter: Alexandre Castro Alves
>
> Currently, if a Designate's OCDREF references to a non-existing OCD, the MTI 
> implementation simply ignores it.
> The result of this behavior is that the following code returns null both when 
> (1) the designate ID is not defined in the meta-data, (2) the designate 
> points to an invalid OCD:
> ObjectClassDefinition objClassDef = 
> metaTypeInformation.getObjectClassDefinition(designateId, locale);
> It is my understanding from the spec that the latter situation should be 
> treated as an exception.
> Thanks



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (FELIX-4771) Possible NPE when accessing content of attribute

[J.W. Janssen (JIRA)]

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

J.W. Janssen updated FELIX-4771:

Fix Version/s: metatype-1.0.12

> Possible NPE when accessing content of attribute
> 
>
> Key: FELIX-4771
> URL: https://issues.apache.org/jira/browse/FELIX-4771
> Project: Felix
>  Issue Type: Bug
>  Components: Metatype Service
>Reporter: J.W. Janssen
> Fix For: metatype-1.0.12
>
>
> An attribute can have optional content, but will throw a NPE when no content 
> is present. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (FELIX-4771) Possible NPE when accessing content of attribute

[J.W. Janssen (JIRA)]

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

J.W. Janssen resolved FELIX-4771.
-
Resolution: Fixed

Solved in rev #1653464.

> Possible NPE when accessing content of attribute
> 
>
> Key: FELIX-4771
> URL: https://issues.apache.org/jira/browse/FELIX-4771
> Project: Felix
>  Issue Type: Bug
>  Components: Metatype Service
>Reporter: J.W. Janssen
>
> An attribute can have optional content, but will throw a NPE when no content 
> is present. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (FELIX-4771) Possible NPE when accessing content of attribute

[J.W. Janssen (JIRA)]

J.W. Janssen created FELIX-4771:
---

 Summary: Possible NPE when accessing content of attribute
 Key: FELIX-4771
 URL: https://issues.apache.org/jira/browse/FELIX-4771
 Project: Felix
  Issue Type: Bug
  Components: Metatype Service
Reporter: J.W. Janssen


An attribute can have optional content, but will throw a NPE when no content is 
present. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (FELIX-4100) Support osgi.http.whiteboard.target whiteboard property

[J.W. Janssen (JIRA)]

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

J.W. Janssen reassigned FELIX-4100:
---

Assignee: J.W. Janssen

> Support osgi.http.whiteboard.target whiteboard property
> ---
>
> Key: FELIX-4100
> URL: https://issues.apache.org/jira/browse/FELIX-4100
> Project: Felix
>  Issue Type: Sub-task
>  Components: HTTP Service
>Affects Versions: http-2.2.0
>Reporter: Mike Wilson
>Assignee: J.W. Janssen
>
> Consider an OSGi system running the Felix HTTP whiteboard service and 
> multiple HttpServices.
> Currently it is not possible to control which HttpService the Felix 
> whiteboard binds to for registering servlets. We get random binding 
> behaviour. It would be natural to provide a configuration setting for the 
> whiteboard that allows to specify a standard OSGi filter to refer to the 
> desired HttpService.
> This filter could then be used when calling superclass constructors from 
> org.apache.felix.http.whiteboard.internal.tracker.HttpServiceTracker.
> It might also be appropriate to integrate the configuration setting with the 
> standard ConfigurationAdmin service (this may deserve its own JIRA ticket 
> though).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-4671) Provide an expression parser

[J.W. Janssen (JIRA)]

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

J.W. Janssen commented on FELIX-4671:
-

Reverted the proposed changes in rev #1653078. Keeping issue open to rethink 
proposed solution...

> Provide an expression parser
> 
>
> Key: FELIX-4671
> URL: https://issues.apache.org/jira/browse/FELIX-4671
> Project: Felix
>  Issue Type: New Feature
>  Components: Gogo Runtime
>Reporter: Guillaume Nodet
>Assignee: J.W. Janssen
> Fix For: gogo.runtime-0.14.0
>
>
> Gogo provides no way to do arithmetic operations or to provide boolean 
> operators.
> This makes writing scripted loops or conditions extremely difficult.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (FELIX-4697) Error parsing the default gosh_profile.

[J.W. Janssen (JIRA)]

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

J.W. Janssen resolved FELIX-4697.
-
Resolution: Fixed

Reverted the code from FELIX-4671 in rev #1653078.

> Error parsing the default gosh_profile.
> ---
>
> Key: FELIX-4697
> URL: https://issues.apache.org/jira/browse/FELIX-4697
> Project: Felix
>  Issue Type: Bug
>  Components: Gogo Runtime
>Affects Versions: gogo.runtime-0.14.0
>Reporter: J.W. Janssen
>
> It appears that the implementation of FELIX-4671 has caused an unexpected 
> side-effect in the parsing of the default {{gosh_profile}}. More 
> specifically: the Tokenizer now bails out on the following expression:
> {code}
> addcommand system (((${.context} bundles) 0) loadclass java.lang.System)
> {code}
> The reason for this is that the {{((}} makes the Tokenizer believe that it 
> should keep parsing until {{))}} is found, which isn't the case in the above 
> situation. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Reopened] (FELIX-4671) Provide an expression parser

[J.W. Janssen (JIRA)]

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

J.W. Janssen reopened FELIX-4671:
-
  Assignee: J.W. Janssen  (was: Guillaume Nodet)

Reopening as problem still persists...

> Provide an expression parser
> 
>
> Key: FELIX-4671
> URL: https://issues.apache.org/jira/browse/FELIX-4671
> Project: Felix
>  Issue Type: New Feature
>  Components: Gogo Runtime
>Reporter: Guillaume Nodet
>Assignee: J.W. Janssen
> Fix For: gogo.runtime-0.14.0
>
>
> Gogo provides no way to do arithmetic operations or to provide boolean 
> operators.
> This makes writing scripted loops or conditions extremely difficult.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-4550) Upgrade embedded Jetty to version 9.2.x in Felix Http Jetty

[J.W. Janssen (JIRA)]

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

J.W. Janssen commented on FELIX-4550:
-

[~tri...@apache.org]: I'm not favouring putting websocket support directly in 
the jetty bundle. I'd like to make it a separate bundle. 

FWIW: Personal tests indicate that there are some bugs in the current websocket 
implementation of Jetty making it less than trivial to expose it in an OSGi 
context...

> Upgrade embedded Jetty to version 9.2.x in Felix Http Jetty
> ---
>
> Key: FELIX-4550
> URL: https://issues.apache.org/jira/browse/FELIX-4550
> Project: Felix
>  Issue Type: New Feature
>  Components: HTTP Service
>Reporter: Chetan Mehrotra
>Assignee: J.W. Janssen
> Attachments: 141204_FELIX-4550_jetty9.patch, FELIX-4550.patch
>
>
> Currently HTTP Service embeds Jetty 8.1.14.v20131031 which supports Servlet 
> 3.0. Current Jetty version 9.2.1.v20140609 supports Servlet 3.1 which 
> provided access to some new NIO based features. Further it also provides lots 
> of new features like Spdy support , Websocket support etc [1]
> [1] https://webtide.com/jetty-9-features/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-4550) Upgrade embedded Jetty to version 9.2.x in Felix Http Jetty

[J.W. Janssen (JIRA)]

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

J.W. Janssen commented on FELIX-4550:
-

Patch from Stefan applied in rev #1652026...

> Upgrade embedded Jetty to version 9.2.x in Felix Http Jetty
> ---
>
> Key: FELIX-4550
> URL: https://issues.apache.org/jira/browse/FELIX-4550
> Project: Felix
>  Issue Type: New Feature
>  Components: HTTP Service
>Reporter: Chetan Mehrotra
>Assignee: J.W. Janssen
> Attachments: 141204_FELIX-4550_jetty9.patch, FELIX-4550.patch
>
>
> Currently HTTP Service embeds Jetty 8.1.14.v20131031 which supports Servlet 
> 3.0. Current Jetty version 9.2.1.v20140609 supports Servlet 3.1 which 
> provided access to some new NIO based features. Further it also provides lots 
> of new features like Spdy support , Websocket support etc [1]
> [1] https://webtide.com/jetty-9-features/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (FELIX-4550) Upgrade embedded Jetty to version 9.2.x in Felix Http Jetty

[J.W. Janssen (JIRA)]

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

J.W. Janssen reassigned FELIX-4550:
---

Assignee: J.W. Janssen

> Upgrade embedded Jetty to version 9.2.x in Felix Http Jetty
> ---
>
> Key: FELIX-4550
> URL: https://issues.apache.org/jira/browse/FELIX-4550
> Project: Felix
>  Issue Type: New Feature
>  Components: HTTP Service
>Reporter: Chetan Mehrotra
>Assignee: J.W. Janssen
> Attachments: 141204_FELIX-4550_jetty9.patch, FELIX-4550.patch
>
>
> Currently HTTP Service embeds Jetty 8.1.14.v20131031 which supports Servlet 
> 3.0. Current Jetty version 9.2.1.v20140609 supports Servlet 3.1 which 
> provided access to some new NIO based features. Further it also provides lots 
> of new features like Spdy support , Websocket support etc [1]
> [1] https://webtide.com/jetty-9-features/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work started] (FELIX-4550) Upgrade embedded Jetty to version 9.2.x in Felix Http Jetty

[J.W. Janssen (JIRA)]

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

Work on FELIX-4550 started by J.W. Janssen.
---
> Upgrade embedded Jetty to version 9.2.x in Felix Http Jetty
> ---
>
> Key: FELIX-4550
> URL: https://issues.apache.org/jira/browse/FELIX-4550
> Project: Felix
>  Issue Type: New Feature
>  Components: HTTP Service
>Reporter: Chetan Mehrotra
>Assignee: J.W. Janssen
> Attachments: 141204_FELIX-4550_jetty9.patch, FELIX-4550.patch
>
>
> Currently HTTP Service embeds Jetty 8.1.14.v20131031 which supports Servlet 
> 3.0. Current Jetty version 9.2.1.v20140609 supports Servlet 3.1 which 
> provided access to some new NIO based features. Further it also provides lots 
> of new features like Spdy support , Websocket support etc [1]
> [1] https://webtide.com/jetty-9-features/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (FELIX-3780) Allow using configuration admin in addition to system properties

[J.W. Janssen (JIRA)]

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

J.W. Janssen resolved FELIX-3780.
-
Resolution: Fixed

Fixed a failing itest and allow both `stopUnaffectedBundle` as 
`stopUnaffectedBundles` to be used.

> Allow using configuration admin in addition to system properties
> 
>
> Key: FELIX-3780
> URL: https://issues.apache.org/jira/browse/FELIX-3780
> Project: Felix
>  Issue Type: New Feature
>  Components: Deployment Admin
>Reporter: Tuomas Kiviaho
>Assignee: J.W. Janssen
>Priority: Minor
> Fix For: deploymentadmin-0.9.8
>
>
> I wanted to put org.apache.felix.deploymentadmin.stopunaffectedbundle=false 
> to external file instead of having to declare it as system property but 
> noticed that the configuration admin spec isn't supported. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (FELIX-4756) Throw Invalid BundleContext when getAllServiceReferences()

[J.W. Janssen (JIRA)]

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

J.W. Janssen closed FELIX-4756.
---
Resolution: Fixed

Already edited and commented on FELIX-4751, but didn't see all the dupes that 
were created...

> Throw Invalid BundleContext when getAllServiceReferences()
> --
>
> Key: FELIX-4756
> URL: https://issues.apache.org/jira/browse/FELIX-4756
> Project: Felix
>  Issue Type: Bug
>  Components: Framework
>Affects Versions: framework-4.0.1
> Environment: Centos 6.0  JDK 6
>Reporter: Chenqiulin
>
> I registService like this:
> public class ManagerActivator implements BundleActivator {
>   private ServiceRegistration serviceRegistration;
>   // 运行服务
>   private ServiceRegistration serviceRegistrationRuntime;
>   public void start(BundleContext context) throws Exception {
>   Dictionary props = new Hashtable();
>   // service.pid
>   String symbolicName = (String) context.getBundle().getHeaders()
>   .get("Bundle-SymbolicName");
>   props.put("service.pid", symbolicName);
>   props.put(Constant.COMMANDNAME, "manager");
>   serviceRegistrationRuntime = context.registerService(
>   AgentAction.class.getName(), new 
> ManagerAction(context), props);
>   logger.info("manager regist success."); 
>   }
> }
> and I get the service like this:
> public Response handle(Message message) {
>   ServiceReference[] serviceRefs = null;
>   Response result = null;
>   try {
>   String mess = message.getContent().toString();
>   logger.debug(mess);
>   Map map = JsonUtil.toBean(mess, Map.class);
>   serviceRefs = context.getAllServiceReferences(
>   AgentAction.class.getName(), "(" + 
> Constant.COMMANDNAME
>   + "=manager)");
>   if (serviceRefs.length == 0) {
>   throw new Exception(" has not Command service 
> like this ");
>   }
>   if (serviceRefs.length > 1) {
>   throw new Exception("more than one Command 
> service like this ");
>   }
>   AgentAction action = (AgentAction) context
>   .getService(serviceRefs[0]);
>   // handle
>   result = action.handle(message);
>   } catch (Exception e) {
>   logger.error(e.getMessage(), e);
>   }
>   return result;
>   }
> But I always get Exception :
>   (AgentMessageHandler.java:72) ERROR - **.AgentMessageHandler  - Invalid 
> BundleContext.
> java.lang.IllegalStateException: Invalid BundleContext.
> at 
> org.apache.felix.framework.BundleContextImpl.checkValidity(BundleContextImpl.java:514)
> at 
> org.apache.felix.framework.BundleContextImpl.getAllServiceReferences(BundleContextImpl.java:411)
> at 
> cn.tianya.amm.agent.service.AgentMessageHandler.handle(AgentMessageHandler.java:55)
> at 
> cn.tianya.fw.mq.impl.activemq.FwMqListenService$MessageSyncHandlerAdapter.run(FwMqListenService.java:582)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:619)
> Did I need to synchronized regist service?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (FELIX-4752) getAllServiceReferences() Throw IllegalStateException: Invalid BundleContext

[J.W. Janssen (JIRA)]

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

J.W. Janssen closed FELIX-4752.
---
Resolution: Fixed

Already edited and commented on FELIX-4751, but didn't see all the dupes that 
were created...


> getAllServiceReferences() Throw IllegalStateException: Invalid BundleContext
> 
>
> Key: FELIX-4752
> URL: https://issues.apache.org/jira/browse/FELIX-4752
> Project: Felix
>  Issue Type: Bug
>  Components: Framework
>Affects Versions: framework-4.0.1
> Environment: Centos 6.0  JDK 6
>Reporter: Chenqiulin
>
> I register service like this:
> public void start(BundleContext context) throws Exception {
>   Dictionary props = new Hashtable();
>   // service.pid
>   String symbolicName = (String) context.getBundle().getHeaders()
>   .get("Bundle-SymbolicName");
>   props.put("service.pid", symbolicName);
>   props.put(Constant.COMMANDNAME, "manager");
>   
>   serviceRegistrationRuntime = context.registerService(
>   AgentAction.class.getName(), new 
> ManagerAction(context), props);
>   logger.info("manager Service regist success.");
>   }
> and I get the service like this:
> public Response handle(Message message) {
>   ServiceReference[] serviceRefs = null;
>   Response result = null;
> try {
>   String mess = message.getContent().toString();
>   logger.debug(mess);
>   Map map = JsonUtil.toBean(mess, Map.class);
>   logger.info("begin to handle message " + 
> map.get(MODULENAME));
>   serviceRefs = context.getAllServiceReferences(
>   AgentAction.class.getName(), "(" + 
> Constant.COMMANDNAME
>   + "=" + 
> map.get(MODULENAME) + ")");
>   // serviceRefs = context.getAllServiceReferences(
>   // AgentAction.class.getName(),null);
>   if (serviceRefs.length == 0) {
>   throw new Exception("has not command service 
> like this");
>   }
>   if (serviceRefs.length > 1) {
>   throw new Exception("more than one command 
> service like this");
>   }
>   AgentAction action = (AgentAction) context
>   .getService(serviceRefs[0]);
>   // handle the command
>   result = action.handle(message);
>   } catch (Exception e) {
>   result = message.createResponse();
>   result.setErrorMsg( e.getMessage());
>   logger.error(e.getMessage(), e);
>   }
>return result;
>   }
> the phenomenon is  I always catch the Exception(about 50%) like this:
> ERROR - cn.tianya.amm.agent.service.AgentMessageHandler  - Invalid 
> BundleContext.
> java.lang.IllegalStateException: Invalid BundleContext.
> at 
> org.apache.felix.framework.BundleContextImpl.checkValidity(BundleContextImpl.java:514)
> at 
> org.apache.felix.framework.BundleContextImpl.getAllServiceReferences(BundleContextImpl.java:411)
> at 
> cn.tianya.amm.agent.service.AgentMessageHandler.handle(AgentMessageHandler.java:55)
> at 
> cn.tianya.fw.mq.impl.activemq.FwMqListenService$MessageSyncHandlerAdapter.run(FwMqListenService.java:582)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:619)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (FELIX-4749) getAllServiceReferences() Throw IllegalStateException: Invalid BundleContext

[J.W. Janssen (JIRA)]

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

J.W. Janssen closed FELIX-4749.
---
Resolution: Fixed

Already edited and commented on FELIX-4751, but didn't see all the dupes that 
were created...


> getAllServiceReferences() Throw IllegalStateException: Invalid BundleContext
> 
>
> Key: FELIX-4749
> URL: https://issues.apache.org/jira/browse/FELIX-4749
> Project: Felix
>  Issue Type: Bug
>  Components: Framework
>Affects Versions: framework-4.0.1
> Environment: Centos 6.0  JDK 6
>Reporter: Chenqiulin
>
> I register service like this:
> public void start(BundleContext context) throws Exception {
>   Dictionary props = new Hashtable();
>   // service.pid
>   String symbolicName = (String) context.getBundle().getHeaders()
>   .get("Bundle-SymbolicName");
>   props.put("service.pid", symbolicName);
>   props.put(Constant.COMMANDNAME, "manager");
>   
>   serviceRegistrationRuntime = context.registerService(
>   AgentAction.class.getName(), new 
> ManagerAction(context), props);
>   logger.info("manager Service regist success.");
>   }
> and I get the service like this:
> public Response handle(Message message) {
>   ServiceReference[] serviceRefs = null;
>   Response result = null;
> try {
>   String mess = message.getContent().toString();
>   logger.debug(mess);
>   Map map = JsonUtil.toBean(mess, Map.class);
>   logger.info("begin to handle message " + 
> map.get(MODULENAME));
>   serviceRefs = context.getAllServiceReferences(
>   AgentAction.class.getName(), "(" + 
> Constant.COMMANDNAME
>   + "=" + 
> map.get(MODULENAME) + ")");
>   // serviceRefs = context.getAllServiceReferences(
>   // AgentAction.class.getName(),null);
>   if (serviceRefs.length == 0) {
>   throw new Exception("has not command service 
> like this");
>   }
>   if (serviceRefs.length > 1) {
>   throw new Exception("more than one command 
> service like this");
>   }
>   AgentAction action = (AgentAction) context
>   .getService(serviceRefs[0]);
>   // handle the command
>   result = action.handle(message);
>   } catch (Exception e) {
>   result = message.createResponse();
>   result.setErrorMsg( e.getMessage());
>   logger.error(e.getMessage(), e);
>   }
>return result;
>   }
> the phenomenon is  I always catch the Exception(about 50%) like this:
> ERROR - cn.tianya.amm.agent.service.AgentMessageHandler  - Invalid 
> BundleContext.
> java.lang.IllegalStateException: Invalid BundleContext.
> at 
> org.apache.felix.framework.BundleContextImpl.checkValidity(BundleContextImpl.java:514)
> at 
> org.apache.felix.framework.BundleContextImpl.getAllServiceReferences(BundleContextImpl.java:411)
> at 
> cn.tianya.amm.agent.service.AgentMessageHandler.handle(AgentMessageHandler.java:55)
> at 
> cn.tianya.fw.mq.impl.activemq.FwMqListenService$MessageSyncHandlerAdapter.run(FwMqListenService.java:582)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:619)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (FELIX-4750) getAllServiceReferences() Throw IllegalStateException: Invalid BundleContext

[J.W. Janssen (JIRA)]

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

J.W. Janssen closed FELIX-4750.
---
Resolution: Fixed

Already edited and commented on FELIX-4751, but didn't see all the dupes that 
were created...


> getAllServiceReferences() Throw IllegalStateException: Invalid BundleContext
> 
>
> Key: FELIX-4750
> URL: https://issues.apache.org/jira/browse/FELIX-4750
> Project: Felix
>  Issue Type: Bug
>  Components: Framework
>Affects Versions: framework-4.0.1
> Environment: Centos 6.0  JDK 6
>Reporter: Chenqiulin
>
> I register service like this:
> public void start(BundleContext context) throws Exception {
>   Dictionary props = new Hashtable();
>   // service.pid
>   String symbolicName = (String) context.getBundle().getHeaders()
>   .get("Bundle-SymbolicName");
>   props.put("service.pid", symbolicName);
>   props.put(Constant.COMMANDNAME, "manager");
>   
>   serviceRegistrationRuntime = context.registerService(
>   AgentAction.class.getName(), new 
> ManagerAction(context), props);
>   logger.info("manager Service regist success.");
>   }
> and I get the service like this:
> public Response handle(Message message) {
>   ServiceReference[] serviceRefs = null;
>   Response result = null;
> try {
>   String mess = message.getContent().toString();
>   logger.debug(mess);
>   Map map = JsonUtil.toBean(mess, Map.class);
>   logger.info("begin to handle message " + 
> map.get(MODULENAME));
>   serviceRefs = context.getAllServiceReferences(
>   AgentAction.class.getName(), "(" + 
> Constant.COMMANDNAME
>   + "=" + 
> map.get(MODULENAME) + ")");
>   // serviceRefs = context.getAllServiceReferences(
>   // AgentAction.class.getName(),null);
>   if (serviceRefs.length == 0) {
>   throw new Exception("has not command service 
> like this");
>   }
>   if (serviceRefs.length > 1) {
>   throw new Exception("more than one command 
> service like this");
>   }
>   AgentAction action = (AgentAction) context
>   .getService(serviceRefs[0]);
>   // handle the command
>   result = action.handle(message);
>   } catch (Exception e) {
>   result = message.createResponse();
>   result.setErrorMsg( e.getMessage());
>   logger.error(e.getMessage(), e);
>   }
>return result;
>   }
> the phenomenon is  I always catch the Exception(about 50%) like this:
> ERROR - cn.tianya.amm.agent.service.AgentMessageHandler  - Invalid 
> BundleContext.
> java.lang.IllegalStateException: Invalid BundleContext.
> at 
> org.apache.felix.framework.BundleContextImpl.checkValidity(BundleContextImpl.java:514)
> at 
> org.apache.felix.framework.BundleContextImpl.getAllServiceReferences(BundleContextImpl.java:411)
> at 
> cn.tianya.amm.agent.service.AgentMessageHandler.handle(AgentMessageHandler.java:55)
> at 
> cn.tianya.fw.mq.impl.activemq.FwMqListenService$MessageSyncHandlerAdapter.run(FwMqListenService.java:582)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:619)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)