[http whiteboard] Clarification when failure DTOs are created

[bjhargrave]

Original bug ID: BZ#2762 From: @cziegeler Reported version: R6

[bjhargrave]

Comment author: @cziegeler

Right now we have a mixture of creating failure DTOs for whiteboard services wrt required properties: e.g. if required properties for the ServletContextHelper are missing, a failure DTO is created - if a required property for a Servlet or Filter is missing, the service registration is ignored - no failure DTO; although the latter is not explicitely mentioned on the spec.

I think these cases should be treated the same, the preferred solution would be to always create a failure DTO if a required property is missing. However, most of the service interfaces are not specified by the whiteboard spec and therefore might (and in fact are) used by other whiteboard implementations (like the current Apache Felix whiteboard or Apache Sling) - they might use Servlet service registrations with different properties. And all of those - while totally valid - would appear as failure DTOs.

Or in short we have three options

a) only the service interface is checked, and if a required property is missing a failure DTO is created

b) only if required properties of a service interface directly defined by the whiteboard spec is missing, a failure DTO is created; if it's missing on other service interfaces the registration is ignored.

c) all registrations without required properties are ignored

Right now, we have spec'ed b) - I have a slight tendency to stick with this. But in any case we should make this more clear in the spec

WDYT?

[bjhargrave]

Comment author: @bosschaert

+1 on making this more clear.

Was just thinking about two servlets registered on the same context. Obviously we use the service ranking rules to dictate which one wins, but for the one that doesn't get registered, will that one appear in the failure DTOs? I personally think it should...

[bjhargrave]

Comment author: @cziegeler

(In reply to David Bosschaert from comment BZ#1)

+1 on making this more clear.

Was just thinking about two servlets registered on the same context. Obviously we use the service ranking rules to dictate which one wins, but for the one that doesn't get registered, will that one appear in the failure DTOs? I personally think it should...

I think that case is handled and described - but maybe not that explicit. In general, once the whiteboard implementation is "seeing" a service, either a DTO or a failure DTO is created (depending on whether it's used or not). As a first step I would like to clarify the "seeing" part; but I agree we should check the other part as well.

[bjhargrave]

Comment author: @tjwatson

(In reply to Carsten Ziegeler from comment BZ#0)

Right now, we have spec'ed b) - I have a slight tendency to stick with this. But in any case we should make this more clear in the spec

WDYT?

I would stick with b) since I think even things like the felix webconsole uses Servlet services as a plug-in mechanism, right? I would not want all these things showing up as error DTOs. Should's are not great for specifications, but perhaps we should state that a warning should be logged in this case?

[bjhargrave]

Comment author: @rotty3000

What about listeners which have no required properties?

Remember that when no osgi.http.whiteboard.context.select property we bind the service to the "default" SCH.

[bjhargrave]

Comment author: @rotty3000

(In reply to Raymond Auge from comment BZ#4)

What about listeners which have no required properties?

Remember that when no osgi.http.whiteboard.context.select property we bind the service to the "default" SCH.

In clarification, listeners have no required properties at all.

[bjhargrave]

Comment author: @cziegeler

What about leveraging the whiteboard capability? I think right now, we don't require bundles to require this capability. Whiteboard services are picked up regardless of it. Now, if we would require this and use it as an opt-in mechanism, I think it would be fairly safe to simply listen for all services in that bundle and create failure DTOs if there are services with missing properties. It's very unlikely that a bundle uses more than one whiteboard approach at the same time. (A web console plugin might be the exception as it might be used in addition with "plain" servlets, but I think we can live with that). This would also solve the problem, that listeners are picked up even if they are not intended to be picked up.

[bjhargrave]

Comment author: @timothyjward

(In reply to Carsten Ziegeler from comment BZ#6)

What about leveraging the whiteboard capability? I think right now, we don't require bundles to require this capability. Whiteboard services are picked up regardless of it.

This would now be the osgi.implementation capability.

Now, if we would require this and use it as an opt-in mechanism, I think it would be fairly safe to simply listen for all services in that bundle and create failure DTOs if there are services with missing properties. It's very unlikely that a bundle uses more than one whiteboard approach at the same time. (A web console plugin might be the exception as it might be used in addition with "plain" servlets, but I think we can live with that). This would also solve the problem, that listeners are picked up even if they are not intended to be picked up.

Console plugins could check to see whether their osgi.implementation requirement has been wired (it would be declared as optional) and if so register using the whiteboard, if not using the "traditional" model.

I'm still not sure I like forcing all users to require the capability, but there isn't a problem with handling web-console type code.

[bjhargrave]

Comment author: @tjwatson

(In reply to Tim Ward from comment BZ#7)

I'm still not sure I like forcing all users to require the capability, but there isn't a problem with handling web-console type code.

I'm not sure I like this idea either. It strays from the normal pattern we take for other capabilities like the extender ones. There an extender is allowed to process extendee bundles that do not have any requirement for the extender capability, but if an extendee bundle does require the extender capability it must be wired to the extender implementations capability.

[bjhargrave]

Comment author: @rotty3000

(In reply to Thomas Watson from comment BZ#8)

(In reply to Tim Ward from comment BZ#7)

I'm still not sure I like forcing all users to require the capability, but there isn't a problem with handling web-console type code.

I'm not sure I like this idea either. It strays from the normal pattern we take for other capabilities like the extender ones. There an extender is allowed to process extendee bundles that do not have any requirement for the extender capability, but if an extendee bundle does require the extender capability it must be wired to the extender implementations capability.

I'm also not sure I like the idea!

The only counter proposal I have is to make

osgi.http.whiteboard.target

a required property of all http whiteboard services. This acts as the opt-in mechanism. A value of blank string, or maybe a * could indicate match to any.

[bjhargrave]

Comment author: @rotty3000

(In reply to Raymond Auge from comment BZ#9)

(In reply to Thomas Watson from comment BZ#8)

(In reply to Tim Ward from comment BZ#7)

I'm still not sure I like forcing all users to require the capability, but there isn't a problem with handling web-console type code.

I'm not sure I like this idea either. It strays from the normal pattern we take for other capabilities like the extender ones. There an extender is allowed to process extendee bundles that do not have any requirement for the extender capability, but if an extendee bundle does require the extender capability it must be wired to the extender implementations capability.

I'm also not sure I like the idea!

The only counter proposal I have is to make

osgi.http.whiteboard.target

a required property of all http whiteboard services. This acts as the opt-in mechanism. A value of blank string, or maybe a * could indicate match to any.

k, wait, in chatting with Tom on the subject, we certainly have some opt-in details already regarding at least the SCH, Servlet, Filter, Resource, all of those have required properties to work with http.whiteboard. I think those act as the opt in.

The only missing piece is for listeners which don't have any required properties.

[bjhargrave]

Comment author: @cziegeler

(In reply to Thomas Watson from comment BZ#8)

(In reply to Tim Ward from comment BZ#7)

I'm still not sure I like forcing all users to require the capability, but there isn't a problem with handling web-console type code.

I'm not sure I like this idea either. It strays from the normal pattern we take for other capabilities like the extender ones. There an extender is allowed to process extendee bundles that do not have any requirement for the extender capability, but if an extendee bundle does require the extender capability it must be wired to the extender implementations capability.

But aren't we doing so for compatibility reasons? For example if we would require bundles to require the DS extender, existing bundles wouldn't be picked up by the DS implementation anymore. We have a new spec here, so we can do whatever we think is the best thing to do - we just have to find out what that is :)

[bjhargrave]

Comment author: @cziegeler

(In reply to Raymond Auge from comment BZ#10)

(In reply to Raymond Auge from comment BZ#9)

(In reply to Thomas Watson from comment BZ#8)

(In reply to Tim Ward from comment BZ#7)

I'm still not sure I like forcing all users to require the capability, but there isn't a problem with handling web-console type code.

I'm not sure I like this idea either. It strays from the normal pattern we take for other capabilities like the extender ones. There an extender is allowed to process extendee bundles that do not have any requirement for the extender capability, but if an extendee bundle does require the extender capability it must be wired to the extender implementations capability.

I'm also not sure I like the idea!

The only counter proposal I have is to make

osgi.http.whiteboard.target

a required property of all http whiteboard services. This acts as the opt-in mechanism. A value of blank string, or maybe a * could indicate match to any.

k, wait, in chatting with Tom on the subject, we certainly have some opt-in details already regarding at least the SCH, Servlet, Filter, Resource, all of those have required properties to work with http.whiteboard. I think those act as the opt in.

The only missing piece is for listeners which don't have any required properties.

Right, all services except listeners have a required property. We could require listeners to specify the context select property - although that seems a little bit odd as we don't require that for servlets etc.

[bjhargrave]

Comment author: @rotty3000

(In reply to Carsten Ziegeler from comment BZ#12)

Right, all services except listeners have a required property. We could require listeners to specify the context select property - although that seems a little bit odd as we don't require that for servlets etc.

osgi.http.whiteboard.listener=true

??

(credit Tom)

[bjhargrave]

Comment author: @bjhargrave

(In reply to Raymond Auge from comment BZ#13)

osgi.http.whiteboard.listener=true

??

(credit Tom)

true seems bad. We may one day have a non-binary use for that service property. From the impls point of view, it should only care that the property is set (to indicate opt-in) rather than its value. For listener impls, they should set the property value to the empty string.

[bjhargrave]

Comment author: @rotty3000

(In reply to BJ Hargrave from comment BZ#14)

(In reply to Raymond Auge from comment BZ#13)

osgi.http.whiteboard.listener=true

??

(credit Tom)

true seems bad. We may one day have a non-binary use for that service property. From the impls point of view, it should only care that the property is set (to indicate opt-in) rather than its value. For listener impls, they should set the property value to the empty string.

Totally agree! (I believe this is what he implied.)

[bjhargrave]

Comment author: @rotty3000

(In reply to BJ Hargrave from comment BZ#14)

(In reply to Raymond Auge from comment BZ#13)

osgi.http.whiteboard.listener=true

For listener impls, they should set the property value to the empty string.

Speaking for myself now, I think this is the most logical solution.

[bjhargrave]

Comment author: @cziegeler

Alright, to summarize: a) for Servlets, Filters, Resources and ServletContextHelper services - only the services with the required properties are tracked - if a required property is missing, no failure DTO is created. (If the property is available but invalid (e.g. empty value) a failure DTO is created) b) For all listener services we use the new service property osgi.http.whiteboard.listener - if specified with any value, the service is tracked. Listeners should specify it with the empty value, but specifying a non empty value is currently not considered an error. As with a) if this property is missing, no failure DTO is created.

[bjhargrave]

Comment author: @tjwatson

Is the type for osgi.http.whiteboard.listener String? It seems that if we allow anything other than empty for the String then existing Listener registration values may collide with the valid values we specify in the future. I know we like to avoid boolean type params ... but what is the likely hood we would want to change this particular service property to be non-boolean in the future? It would seem that situation would call for a new service property.

[bjhargrave]

Comment author: @cziegeler

(In reply to Thomas Watson from comment BZ#18)

Is the type for osgi.http.whiteboard.listener String? It seems that if we allow anything other than empty for the String then existing Listener registration values may collide with the valid values we specify in the future. I know we like to avoid boolean type params ... but what is the likely hood we would want to change this particular service property to be non-boolean in the future? It would seem that situation would call for a new service property.

Sounds reasonable, so +1 for a boolean prop

[bjhargrave]

Comment author: @timothyjward

(In reply to Carsten Ziegeler from comment BZ#19)

(In reply to Thomas Watson from comment BZ#18)

Is the type for osgi.http.whiteboard.listener String? It seems that if we allow anything other than empty for the String then existing Listener registration values may collide with the valid values we specify in the future. I know we like to avoid boolean type params ... but what is the likely hood we would want to change this particular service property to be non-boolean in the future? It would seem that situation would call for a new service property.

Sounds reasonable, so +1 for a boolean prop

Would this mean that the property has a type of boolean, or that it has a type of String? The spec can be explicit here and state that the type of the property is String but that the value is "true". Other values can then be defined later if they are needed, and anything that isn't the String "true" (including a Boolean true) can be reported as an error.

[bjhargrave]

Comment author: @cziegeler

(In reply to Tim Ward from comment BZ#20)

Would this mean that the property has a type of boolean, or that it has a type of String? The spec can be explicit here and state that the type of the property is String but that the value is "true". Other values can then be defined later if they are needed, and anything that isn't the String "true" (including a Boolean true) can be reported as an error.

I would go with a property of type boolean and requiring this to be of type boolean. As Tom pointed out, for any future enhancement, a new property might be the better solution anyway.

[bjhargrave]

Comment author: @bjhargrave

(In reply to Carsten Ziegeler from comment BZ#21)

I would go with a property of type boolean and requiring this to be of type boolean. As Tom pointed out, for any future enhancement, a new property might be the better solution anyway.

Well it can't be boolean. It would have to be Boolean. And wrapper types are awkward. :-( I am more inclined to state the type is String and we define the only valid values (as of this spec version). That is, what Tim said.

[bjhargrave]

Comment author: @cziegeler

(In reply to BJ Hargrave from comment BZ#22)

(In reply to Carsten Ziegeler from comment BZ#21)

I would go with a property of type boolean and requiring this to be of type boolean. As Tom pointed out, for any future enhancement, a new property might be the better solution anyway.

Well it can't be boolean. It would have to be Boolean. And wrapper types are awkward. :-( I am more inclined to state the type is String and we define the only valid values (as of this spec version). That is, what Tim said.

In the end I don't care that much, as long as we have an opt in. On the other hand this feels like YAGNI (and sorry I meant Boolean of course)

[bjhargrave]

Comment author: @bosschaert

I'll update the spec chapter and will add the new property to the constants/javadoc too.

[bjhargrave]

Comment author: @bosschaert

BTW there is a precedence for a service property with no defined value or type. In Remote Services the 'service.imported' property is defined as follows:

Name: service.imported Type: * Description: Must be set by a distribution provider to any value when it registers the endpoint proxy as an imported service. A bundle can use this property to filter out imported services

We could do the same here and postpone the decision on the datatype...

[bjhargrave]

Comment author: @cziegeler

(In reply to David Bosschaert from comment BZ#25)

BTW there is a precedence for a service property with no defined value or type. In Remote Services the 'service.imported' property is defined as follows:

Name: service.imported Type: * Description: Must be set by a distribution provider to any value when it registers the endpoint proxy as an imported service. A bundle can use this property to filter out imported services

We could do the same here and postpone the decision on the datatype...

I think we should either a) specify type Boolean or b) specify type String with only one valid value "true"

I prefer a)

[bjhargrave]

Comment author: @tjwatson

(In reply to David Bosschaert from comment BZ#25)

We could do the same here and postpone the decision on the datatype...

I don't think you postponed the decision. Once you let all types of values in you cannot later restrict the types of values without possibly breaking someone. I'm fine with this definition for the osgi.http.whiteboard.listener value, but keep in mind I would not be for changing the type to a more restricted type in a later release. Effectively this makes the property a Boolean type even though we implement it as simply a presence check.

[bjhargrave]

Comment author: @tjwatson

(In reply to Carsten Ziegeler from comment BZ#26)

I think we should either a) specify type Boolean or b) specify type String with only one valid value "true"

I prefer a)

I prefer a) or David suggestion in comment 25 over b)

[bjhargrave]

Comment author: @bosschaert

As there seems to be consensus to go with option a) I will write that in the spec.

[bjhargrave]

Comment author: @tjwatson

(In reply to David Bosschaert from comment BZ#29)

As there seems to be consensus to go with option a) I will write that in the spec.

I'm wondering how strict a runtime must be with the check. For example, I would implement this with a filter if (osgi.http.whiteboard.listener=true) which will match a Boolean.TRUE or a String "true" value. Is it then required by the runtime to actually make sure the value is really a Boolean?

[bjhargrave]

Comment author: @rotty3000

(In reply to Thomas Watson from comment BZ#30)

(In reply to David Bosschaert from comment BZ#29)

As there seems to be consensus to go with option a) I will write that in the spec.

I'm wondering how strict a runtime must be with the check. For example, I would implement this with a filter if (osgi.http.whiteboard.listener=true) which will match a Boolean.TRUE or a String "true" value. Is it then required by the runtime to actually make sure the value is really a Boolean?

Why wouldn't you implement just using presence?

(osgi.http.whiteboard.listener=*)

[bjhargrave]

Comment author: @bosschaert

Added the Boolean listener property in https://www.osgi.org/members/gitweb/build.git/commitdiff/26c2304959270a350075e816471159190dc61e4f

[bjhargrave]

Comment author: @bjhargrave

(In reply to David Bosschaert from comment BZ#29)

As there seems to be consensus to go with option a) I will write that in the spec.

I still disagree. Requiring it to be a Boolean will require DS users to say something like:

@ Component(property = "osgi.http.whiteboard.listener:Boolean=true")

if they declare the component in their annotation. Many will forget the :Boolean. It will also mean that they cannot use

@ Component(properties = "myprops.properties")

since you can only put String properties in a properties file.

There is no benefit to forcing Boolean here and only programmer inconvenience and error. If the programmer forgets the :Boolean, their listener may be ignored.

(In reply to Raymond Auge from comment BZ#31)

Why wouldn't you implement just using presence?

(osgi.http.whiteboard.listener=*)

If this is how the impl looks for the property, then why specify anything including Boolean and true? If it must be Boolean, then why can't I say "false" and get ignored?

As Tom observes (with a slight paraphrase), (osgi.http.whiteboard.listener~=true) works fine on String types which are much easier to use in DS.

[bjhargrave]

Comment author: @bosschaert

(In reply to BJ Hargrave from comment BZ#33)

As Tom observes (with a slight paraphrase), (osgi.http.whiteboard.listener~=true) works fine on String types which are much easier to use in DS.

Wow - I've never actually seen anyone use the ~= operator. I would suspect that many people don't even know that it exists...

[bjhargrave]

Comment author: @cziegeler

As Tom observes (with a slight paraphrase), (osgi.http.whiteboard.listener~=true) works fine on String types which are much easier to use in DS.

That's why we have the new annotation based configuration stuff :)

But I see the point, tools like File Install only support string prop values. So wouldn't this mean as a consequence that we change the other props which currently have type Boolean to String, e.g. the async flag? Or to (Boolean or String)?

[bjhargrave]

Comment author: @bjhargrave

(In reply to Carsten Ziegeler from comment BZ#35)

But I see the point, tools like File Install only support string prop values. So wouldn't this mean as a consequence that we change the other props which currently have type Boolean to String, e.g. the async flag? Or to (Boolean or String)?

I would think so. We should stick to String since it is much easier for programmers to use (unless there is a compelling reason to do otherwise).

Impls can use (prop~=true) to find the TrUe values and ignore the non-tRuE values.

(In reply to David Bosschaert from comment BZ#34)

Wow - I've never actually seen anyone use the ~= operator. I would suspect that many people don't even know that it exists...

:-) It is used quite a bit in 3.10 for filters matching OS and processor names. But it is also useful here for matching any case variant of true.

[bjhargrave]

Comment author: @bjhargrave

(In reply to Carsten Ziegeler from comment BZ#35)

That's why we have the new annotation based configuration stuff :)

That only applies to using property values. In this case, we are talking about components setting the property values for their services.

[bjhargrave]

Comment author: @bosschaert

On a different note, the Filter services don't have a single required property. They have the following osgi.http.whiteboard.filter.pattern osgi.http.whiteboard.filter.regex osgi.http.whiteboard.filter.servlet

I guess any of these can be set to make the Filter a Whiteboard Filter. How do we handle this?

[bjhargrave]

Comment author: @rotty3000

(In reply to David Bosschaert from comment BZ#38)

On a different note, the Filter services don't have a single required property. They have the following osgi.http.whiteboard.filter.pattern osgi.http.whiteboard.filter.regex osgi.http.whiteboard.filter.servlet

I guess any of these can be set to make the Filter a Whiteboard Filter. How do we handle this?

We're doing:

(&(objectClass=javax.servlet.Filter)(|(osgi.http.whiteboard.filter.pattern=)(osgi.http.whiteboard.filter.regex=)(osgi.http.whiteboard.filter.servlet=*)))

[bjhargrave]

Comment author: @cziegeler

(In reply to Raymond Auge from comment BZ#39)

(In reply to David Bosschaert from comment BZ#38)

On a different note, the Filter services don't have a single required property. They have the following osgi.http.whiteboard.filter.pattern osgi.http.whiteboard.filter.regex osgi.http.whiteboard.filter.servlet

I guess any of these can be set to make the Filter a Whiteboard Filter. How do we handle this?

We're doing:

(&(objectClass=javax.servlet.Filter)(|(osgi.http.whiteboard.filter. pattern=)(osgi.http.whiteboard.filter.regex=)(osgi.http.whiteboard.filter. servlet=*)))

Yepp, that's what we do as well - so it's required that at least one of them is defined.

[bjhargrave]

Comment author: @timothyjward

(In reply to Carsten Ziegeler from comment BZ#40)

(In reply to Raymond Auge from comment BZ#39)

(In reply to David Bosschaert from comment BZ#38)

On a different note, the Filter services don't have a single required property. They have the following osgi.http.whiteboard.filter.pattern osgi.http.whiteboard.filter.regex osgi.http.whiteboard.filter.servlet

I guess any of these can be set to make the Filter a Whiteboard Filter. How do we handle this?

We're doing:

(&(objectClass=javax.servlet.Filter)(|(osgi.http.whiteboard.filter. pattern=)(osgi.http.whiteboard.filter.regex=)(osgi.http.whiteboard.filter. servlet=*)))

Yepp, that's what we do as well - so it's required that at least one of them is defined.

So I believe we've now reached the consensus that properties provided by the consumer should be defined as String or String+ to make them as easy as possible to provide? This is certainly my preferred option as it gives the fewest interoperability problems with other tools (as identified above).

I assume that properties that come from the provider (for example the http port) will still be specified using more specific types such as Integer? Again I see this as a way to make life easier for the user of the spec as they have to do less parsing.

A final question - will the spec require strict validation, issue warnings, or will it accept the toString() of the property value? For example I can use Boolean.TRUE and still match any filter looking for a value of "true", but the implementation may decide that I'm in error anyway.

[bjhargrave]

Comment author: @bjhargrave

(In reply to Tim Ward from comment BZ#41)

So I believe we've now reached the consensus that properties provided by the consumer should be defined as String or String+ to make them as easy as possible to provide? This is certainly my preferred option as it gives the fewest interoperability problems with other tools (as identified above).

I assume that properties that come from the provider (for example the http port) will still be specified using more specific types such as Integer? Again I see this as a way to make life easier for the user of the spec as they have to do less parsing.

Yes, this is an excellent principle for OSGi specs. Consumer provided properties should be String-ish and provider provided property can be of more specific types (where it makes sense).

This principle is not a hard rule since we already violate it in other specs. e.g. service.ranking:Integer.

A final question - will the spec require strict validation, issue warnings, or will it accept the toString() of the property value? For example I can use Boolean.TRUE and still match any filter looking for a value of "true", but the implementation may decide that I'm in error anyway.

Given the above principle, is there still a practical issue here?

Generally, I don't think we ever required strict validation but the user of the property may fail if the type is wrong. For example, the framework will ignore service.ranking if not an Integer.

[bjhargrave]

Comment author: @cziegeler

In general, it seems a little bit odd that we always tell we prefer strong typing etc. but then reduce ourselfs to string values. But anyway, as nearly everyone loves string as the type, let's do that. But I really would like to somehow spec that for the binary properties and the ones representing a number, that other types like Boolean or Integer are valid as well. I don't want to leave this up to the implementation.

[bjhargrave]

Comment author: @pkriens

I agree with Carsten ... We should use strong typing, would actually prefer to define these configuration properties in interfaces/DTOs. However, we need a way for configuration managers like File Install to convert their string representation to the actual types.

Using type safe properties just saves a hell of a lot of error cases to check for.

[bjhargrave]

Comment author: @bosschaert

It seems like we need to have another round of discussion about this. Most people on yesterday's CPEG call were in favor of using Strings for client-provided properties. I am also more in favor of strong typing on the properties, but the majority of people on the CPEG call were in favor of using a String property with values 'true' and 'false'.

[bjhargrave]

Comment author: @bjhargrave

The conclusion of the CPEG discussion yesterday was to accept Tim Ward's observation that these properties are enums which today have two possible values "true" and "false". In the future, we may define additional values for these enums.

Since there is no way other than String to represent the enum values, we will use String as the property type.

We need to proceed on this path to make progress to actually finish the Enterprise and Compendium R6 specs in this quarter.

We can entertain further discussion on this during spec review meetings.

[bjhargrave]

Comment author: @cziegeler

(In reply to BJ Hargrave from comment BZ#46)

The conclusion of the CPEG discussion yesterday was to accept Tim Ward's observation that these properties are enums which today have two possible values "true" and "false". In the future, we may define additional values for these enums.

Since there is no way other than String to represent the enum values, we will use String as the property type.

We need to proceed on this path to make progress to actually finish the Enterprise and Compendium R6 specs in this quarter.

We can entertain further discussion on this during spec review meetings.

It's not an enum, it's today a boolean - and I always see the "in the future" reference although there is no clue on what that even could be. And it has already been pointed out, that "in the future" we better use a new property with whatever someone will come up with.

[bjhargrave]

Comment author: @cziegeler

For the sake of moving on, I hope this summarizes it then:

a) for Servlets, Filters, Resources and ServletContextHelper services - only the services with the required properties are tracked - if a required property is missing, no failure DTO is created. (If the property is available but invalid (e.g. empty value) a failure DTO is created) b) For all listener services we add the new required service property osgi.http.whiteboard.listener - this is of type string with two allowed values, "true" and "false". As with a) if this property is missing, no failure DTO is created; the same happens if "false" is specified. If any other value than "true" or "false" is specified, a failure DTO is created for the invalid value

[bjhargrave]

Comment author: @tjwatson

(In reply to Carsten Ziegeler from comment BZ#48)

For the sake of moving on, I hope this summarizes it then:

a) for Servlets, Filters, Resources and ServletContextHelper services - only the services with the required properties are tracked - if a required property is missing, no failure DTO is created. (If the property is available but invalid (e.g. empty value) a failure DTO is created) b) For all listener services we add the new required service property osgi.http.whiteboard.listener - this is of type string with two allowed values, "true" and "false". As with a) if this property is missing, no failure DTO is created; the same happens if "false" is specified. If any other value than "true" or "false" is specified, a failure DTO is created for the invalid value

I think we agreed that if the value of osgi.http.whiteboard.listener is "false" then a ListenerDTO is create and we must add a field to ListenerDTO to indicate the listener is enabled or not ... is that a boolean field in the DTO?