[jira] [Commented] (FELIX-5356) Component Factory and CM factory Configurations behave badly
[
https://issues.apache.org/jira/browse/FELIX-5356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15512090#comment-15512090
]
David Jencks commented on FELIX-5356:
-
On further consideration, setting the policy definitely won't work since a
factory component can be configured by any number of singleton configurations.
A better approach might be to look at the configuration merging code in
ConfigurableComponentHolder and prevent dealing with a matching factory
configurations if the component is a factory component. If the literal spec
behavior is correct, that might be a place to implement it as well.
> Component Factory and CM factory Configurations behave badly
>
>
> Key: FELIX-5356
> URL: https://issues.apache.org/jira/browse/FELIX-5356
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR)
>Affects Versions: scr-2.0.6
> Environment: All
>Reporter: Thomas Watson
>Priority: Minor
>
> This is a corner case and a minor issue in my opinion. The specification
> really only mentions the following with respect to what should happen with
> factory components and CM factory configurations:
> {quote}
> A factory configuration must not be used if the component is a factory
> component. This is because SCR is not free to create component configurations
> as necessary to support multiple Configurations. When SCR detects this
> condition, it must log an error message with the Log Service,
> if present, and ignore the component description.
> {quote}
> At face value it seems to suggest that any CM factory configurations must be
> ignored when they match the factory component PID. But the last sentence
> also makes a strong assertion that the component description must be ignored
> if matching factory configurations are detected while discovering a factory
> component description. This seems overkill to me. Why not just ignore the
> factory configurations? Why must the factory component description be
> ignored altogether?
> The other issue is that if a matching factory configuration is created later,
> after a ComponentFactory has been registered and a ComponentInstance has been
> created (with newInstance) then felix SCR will dispose of the
> ComponentInstance. In this case the component instance did not specify an
> update method.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-5332) Serializer
[ https://issues.apache.org/jira/browse/FELIX-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15511473#comment-15511473 ] David Leangen commented on FELIX-5332: -- Hey [~bosschaert], it was not really my intent to own a new project (unfortunately, I don't really have the time or energy right now), so I just want to stop and think a bit about what we are doing before I dig myself in any deeper. :-) The code I wrote is a very simplistic example, and needs a lot of work. It "works", in that I am able to do serialization with it, and I am now actually using it internally, but it's nowhere near ready for general use, I think. The main point I was trying to make is that OSGi is creating a "Serialization" spec, does not seem to be giving consideration for what, I believe, is a critical element of serialization: the schema. Without a schema, complex data cannot be deserialized. The only reason this can work without a Schema object is because during deserialization, the application already knows which DTO object (including help from TypeReference) needs to be used. If that context is not there, or if the object is too "complex", then boom! There are a few schema types out there. Here are a few: * xsd * [protobuf|https://developers.google.com/protocol-buffers/] * [Cap'n Proto|https://capnproto.org/] I am sure there are others. (I think the last one is really neat, as it also explicitly deals with generics.) The DTO in OSGi *is* the data schema. If it can not be properly serialized / deserialized, then there is a serious problem, IMHO. I was trying to point out this problem, but it is turning out to be much more involved than I had originally imagined. The above listed solutions are "complete", but they also drag in a log of baggage. It would seem that the last 2 even require a native compiler to be installed. They all seem to work "offline" or during the build, rather than at runtime. It would be awesome to have a language agnostic schema, which could be converted into any of these formats. The DTO has that potential. It would be extremely powerful, combined with the Converter and "Serializer". I think my little experiment here can be considered both a success and a failure. It is a success in that I was able to accomplish the job of serializing somewhat complex data (complex enough that it could not be done without a schema) by way of this simple prototype, but it was a failure in that we have not yet found a good way to integrate it, and I don't think I've yet convinced anybody of its necessity. I think we need to sit back and think of something more convincing, perhaps, before continuing to pursue my experiment. wdyt? BTW, I am having a bit of trouble with naming it a "Serializer" if it cannot completely do the job... Codec actually seemed more appropriate. Just sayin'. :-) > Serializer > -- > > Key: FELIX-5332 > URL: https://issues.apache.org/jira/browse/FELIX-5332 > Project: Felix > Issue Type: New Feature > Components: Converter >Reporter: David Leangen >Assignee: David Bosschaert > Attachments: patch.diff > > > Test case and a bit of code to show how a Serializer could work. > To work as a Serializer, the type information needs to be embedded into the > output. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (FELIX-4797) Enable client certificate requesting without verifying the certificates
[ https://issues.apache.org/jira/browse/FELIX-4797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed FELIX-4797. --- > 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-4797) Enable client certificate requesting without verifying the certificates
[ https://issues.apache.org/jira/browse/FELIX-4797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15510564#comment-15510564 ] Pascal Mainini commented on FELIX-4797: --- Hi Carsten thanks for your inquiry. It's already quite long ago and I honestly don't recall the full details. From my side however, the issue has been either resolved or worked around, so I think it can be closed here as well. Sorry for not keeping you updated! > 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-5332) Serializer
[ https://issues.apache.org/jira/browse/FELIX-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15509547#comment-15509547 ] David Bosschaert commented on FELIX-5332: - Hi [~dleangen], there is no rush at all - as a separate module this can evolve using its own timeline :) The idea of 'withContext(Object obj)' is to use that in place of what you proposed initially as with(Schema x) but then a little more generic. This would just provide a way to provide the (de)serializer with extra context, which could be a schema, but might also be something other implementation specific. It would not tie the Serializer API to whatever the context is, and implementations can choose to supply whatever they want, including a Schema object. As a suggested starting point I have added the withContext() to the Serializer and Deserializer APIs. By default they do nothing (as not all serializers need this context), but implementations can use these to get the Schema... Do you think this might work? It's just an idea... > Serializer > -- > > Key: FELIX-5332 > URL: https://issues.apache.org/jira/browse/FELIX-5332 > Project: Felix > Issue Type: New Feature > Components: Converter >Reporter: David Leangen >Assignee: David Bosschaert > Attachments: patch.diff > > > Test case and a bit of code to show how a Serializer could work. > To work as a Serializer, the type information needs to be embedded into the > output. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-5348) [HTTP Service] Location not URL Encoded during Redirect
[
https://issues.apache.org/jira/browse/FELIX-5348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15509113#comment-15509113
]
Carsten Ziegeler commented on FELIX-5348:
-
[~djaeggi] Important information is missing here, which version of the
sslfilter is used?
> [HTTP Service] Location not URL Encoded during Redirect
> ---
>
> Key: FELIX-5348
> URL: https://issues.apache.org/jira/browse/FELIX-5348
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Reporter: Dominique Jäggi
>
> With SSL forwarding enabled, a _sendRedirect_ will not properly encode the
> resulting location header value:
> {noformat}
> > GET /?$$bla$$=test HTTP/1.1
> > Host: localhost:4502
> > Authorization: Basic YWRtaW46YWRtaW4=
> > User-Agent: curl/7.49.1
> > Accept: */*
> > X-Forwarded-SSL:on
> >
> < HTTP/1.1 302 Found
> < Location: https://localhost/index.html?$$bla$$=test
> < Transfer-Encoding: chunked
> <
> * Connection #0 to host localhost left intact
> {noformat}
> Non-SSL-forwarded requests result in properly encoded location header.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-5348) [HTTP Service] Location not URL Encoded during Redirect
[
https://issues.apache.org/jira/browse/FELIX-5348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15509114#comment-15509114
]
Carsten Ziegeler commented on FELIX-5348:
-
Looks like a duplicate of FELIX-5027 to me
> [HTTP Service] Location not URL Encoded during Redirect
> ---
>
> Key: FELIX-5348
> URL: https://issues.apache.org/jira/browse/FELIX-5348
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Reporter: Dominique Jäggi
>
> With SSL forwarding enabled, a _sendRedirect_ will not properly encode the
> resulting location header value:
> {noformat}
> > GET /?$$bla$$=test HTTP/1.1
> > Host: localhost:4502
> > Authorization: Basic YWRtaW46YWRtaW4=
> > User-Agent: curl/7.49.1
> > Accept: */*
> > X-Forwarded-SSL:on
> >
> < HTTP/1.1 302 Found
> < Location: https://localhost/index.html?$$bla$$=test
> < Transfer-Encoding: chunked
> <
> * Connection #0 to host localhost left intact
> {noformat}
> Non-SSL-forwarded requests result in properly encoded location header.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (FELIX-5355) Allow to use properties having dots with configuration proxies
[
https://issues.apache.org/jira/browse/FELIX-5355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop updated FELIX-5355:
-
Description:
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.
was:
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.
> 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
