[jira] [Commented] (FELIX-6031) Converter is not working properly when the target is an interface that extends others

[JIRA]

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

Cristiano Gavião commented on FELIX-6031:
-

Hi [~bosschaert], it resolved the issue on my side. thanks a lot.

> Converter is not working properly when the target is an interface that 
> extends others
> -
>
> Key: FELIX-6031
> URL: https://issues.apache.org/jira/browse/FELIX-6031
> Project: Felix
>  Issue Type: Bug
>  Components: Converter
>Affects Versions: converter-1.0.2
>Reporter: Cristiano Gavião
>Assignee: David Bosschaert
>Priority: Critical
> Fix For: converter-1.0.4
>
>
> I'm converting from a map to an interface and since that interface has not 
> any direct method
>  it is not being considered a "map". But one of the interfaces that it 
> extends has the required method named with the source's map key name.
> The problem is in the routine that identifies the interfaces in the method 
> "getInterfaces0":
> {code:java}
>   private static boolean isMapType(Class< ? > cls, boolean asJavaBean,
>   boolean asDTO) {
>   if (asDTO)
>   return true;
>   // All interface types that are not Collections are treated as 
> maps
>   if (Map.class.isAssignableFrom(cls))
>   return true;
>   *else if (getInterfaces(cls).size() > 0)*
>   return true;
>   else if (DTOUtil.isDTOType(cls))
>   return true;
>   else if (asJavaBean && isWriteableJavaBean(cls))
>   return true;
>   else
>   return Dictionary.class.isAssignableFrom(cls);
>   }
> {code}
> {code:java}
>   private static Set> getInterfaces(Class< ? > cls) {
>   if (NO_MAP_VIEW_TYPES.contains(cls))
>   return Collections.emptySet();
>   Set> interfaces = getInterfaces0(cls);
>   for (Iterator> it = interfaces.iterator(); 
> it.hasNext();) {
>   Class< ? > intf = it.next();
>   if (intf.getDeclaredMethods().length == 0)
>   it.remove();
>   }
>   interfaces.removeAll(NO_MAP_VIEW_TYPES);
>   return interfaces;
>   }
> {code}
> {code:java}
>   private static Set> getInterfaces0(Class< ? > cls) {
>   if (cls == null)
>   return Collections.emptySet();
>   Set> classes = new LinkedHashSet<>();
>   if (cls.isInterface()) {
>   classes.add(cls);
>   } else {
>   classes.addAll(Arrays.asList(cls.getInterfaces()));
>   }
>   classes.addAll(getInterfaces(cls.getSuperclass()));
>   return classes;
>   }
> {code}
> Below is my proposed fix that recursively takes all interfaces that the 
> target extends:
> {code:java}
>   private static Set> getInterfaces0(Class< ? > cls) {
>   if (cls == null)
>   return Collections.emptySet();
>   Set> classes = new LinkedHashSet<>();
>   if (cls.isInterface()) {
>   classes.add(cls);
>   if (cls.getInterfaces()!= null && 
> cls.getInterfaces().length > 0) {
>   for (Class intf : cls.getInterfaces()) {
> classes.addAll(getInterfaces0(intf));
> }
>   }
>   } else {
>   classes.addAll(Arrays.asList(cls.getInterfaces()));
>   }
>   classes.addAll(getInterfaces(cls.getSuperclass()));
>   return classes;
>   }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FELIX-6008) ErrorHandlers should be applied in reverse order

[JIRA]

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

Cristiano Gavião commented on FELIX-6008:
-

[~bosschaert], I also think that it is the case for custom rules too.

> ErrorHandlers should be applied in reverse order
> 
>
> Key: FELIX-6008
> URL: https://issues.apache.org/jira/browse/FELIX-6008
> Project: Felix
>  Issue Type: Bug
>  Components: Converter
>Affects Versions: converter-1.0.2
>Reporter: Cristiano Gavião
>Assignee: David Bosschaert
>Priority: Major
>
> It could become common to create a new converter from an existent one.
> So, in case of more than one errorHandler were registered they must be 
> applied in reverse order.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [DISCUSS] First release of health check modules annotation, api, core, generalchecks and webconsoleplugin

[Raymond Auge]

On Fri, Jan 18, 2019 at 11:08 AM Georg Henzler  wrote:

> Hi Ray,
>
> this sound like a good idea! A generic, configurable HC would look
> something like [1] in pseudo code. Using OSGi headers in bundles to
> ensure correct wiring is straight forward, but I'm not sure if there is
> an API to get all currently available capabilities in framework?
>

It's more like can I transitively resolve a running system from:

a) only a code dependency (i.e. I implement some health check API): results
in at resolve I get -> health check implementation -> jaxrs/http servlet
whitebard implemetation
b) I specify @RequireHealthCheck in my main app app where I don't actually
implement any APIs: results in at resolve I get -> health check
implementation -> jaxrs/http servlet whitebard implemetation

:)

I can probably try it out and submit the proper cap&req.

- Ray


> -Georg
>
> [1]
> ...
> private List requiredCapabilitiesAsConfigured;
> ...
> public Result execute() {
>   List allCapabilitiesRegisteredInFramework = ???
>   List missing = new
> ArrayList<>(requiredCapabilitiesAsConfigured)
>   missing.removeAll(allCapabilitiesRegisteredInFramework)
>   if(missing.isEmpty()) {
>   return new Result(Result.Status.OK, "All capabilities
> available: "+StringUtils.join(requiredCapabilitiesAsConfigured))
>   } else {
>   return new Result(Result.Status.WARN, "Missing capabilities:
> "+StringUtils.join(missing) + "(configured as required:
> "+StringUtils.join(requiredCapabilitiesAsConfigured)+")")
>   }
> }
>
>
> On 2019-01-18 16:17, Raymond Auge wrote:
> > Great!
> >
> > I haven't looked so it might already be done, but I would ask that
> > requirements and capabilities be used so that we can resolve a running
> > system with minimal configuration.
> >
> > I can help if someone explains the pieces to me.
> >
> > - Ray
> >
> > On Fri, Jan 18, 2019 at 10:04 AM Georg Henzler 
> > wrote:
> >
> >> Hi all,
> >>
> >> I have spend quite a bit time to polish the new Felix Health Checks
> >> before the first release:
> >>
> >> * The API has been cleaned up while maintaining backwards
> >> compatibility
> >> for 99% of the checks out in the wild (migration guide will be
> >> provided
> >> in Sling)
> >> * Dependencies have been minimised, api and core core run as soon as
> >> slf4j api and servlet api is available
> >> * The new status TEMPORARILY_UNAVAILABLE allows to distinguish
> >> startup/deployment unavailabilities clearly from other CRITICAL
> >> problems
> >> * General checks have been introduced and polished (that part has
> >> improved quite a bit compared to what it was in Sling): Sys Admins can
> >> quickly add checks (web console by configuration only) for JMX
> >> attributes, requests or add scripts to check arbitrary conditions.
> >> * Servlet Filters have been introduced to a) flexibly track certain
> >> requests by registering dynamic tags and b) cut off certain (or all)
> >> requests with 503 if certain tags have a certain status values.
> >>
> >> See [1] for all tickets solved.
> >>
> >>  From my point of view everything is ready for the first release but
> >> feedback is welcome! I plan to create the releases for the modules
> >> annotation, api, core, generalchecks and webconsoleplugin next week.
> >>
> >> Best Regards
> >> Georg
> >>
> >> [1]
> >>
> >>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20FELIX%20AND%20resolution%20%3D%20Fixed%20AND%20component%20%3D%20%22Health%20Checks%22
> >>
>


-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)

Re: [DISCUSS] First release of health check modules annotation, api, core, generalchecks and webconsoleplugin

[Georg Henzler]

Hi Ray,

this sound like a good idea! A generic, configurable HC would look 
something like [1] in pseudo code. Using OSGi headers in bundles to 
ensure correct wiring is straight forward, but I'm not sure if there is 
an API to get all currently available capabilities in framework?


-Georg

[1]
...
private List requiredCapabilitiesAsConfigured;
...
public Result execute() {
 List allCapabilitiesRegisteredInFramework = ???
 List missing = new 
ArrayList<>(requiredCapabilitiesAsConfigured)

 missing.removeAll(allCapabilitiesRegisteredInFramework)
 if(missing.isEmpty()) {
 return new Result(Result.Status.OK, "All capabilities 
available: "+StringUtils.join(requiredCapabilitiesAsConfigured))

 } else {
 return new Result(Result.Status.WARN, "Missing capabilities: 
"+StringUtils.join(missing) + "(configured as required: 
"+StringUtils.join(requiredCapabilitiesAsConfigured)+")")

 }
}


On 2019-01-18 16:17, Raymond Auge wrote:

Great!

I haven't looked so it might already be done, but I would ask that
requirements and capabilities be used so that we can resolve a running
system with minimal configuration.

I can help if someone explains the pieces to me.

- Ray

On Fri, Jan 18, 2019 at 10:04 AM Georg Henzler  
wrote:



Hi all,

I have spend quite a bit time to polish the new Felix Health Checks
before the first release:

* The API has been cleaned up while maintaining backwards 
compatibility
for 99% of the checks out in the wild (migration guide will be 
provided

in Sling)
* Dependencies have been minimised, api and core core run as soon as
slf4j api and servlet api is available
* The new status TEMPORARILY_UNAVAILABLE allows to distinguish
startup/deployment unavailabilities clearly from other CRITICAL 
problems

* General checks have been introduced and polished (that part has
improved quite a bit compared to what it was in Sling): Sys Admins can
quickly add checks (web console by configuration only) for JMX
attributes, requests or add scripts to check arbitrary conditions.
* Servlet Filters have been introduced to a) flexibly track certain
requests by registering dynamic tags and b) cut off certain (or all)
requests with 503 if certain tags have a certain status values.

See [1] for all tickets solved.

 From my point of view everything is ready for the first release but
feedback is welcome! I plan to create the releases for the modules
annotation, api, core, generalchecks and webconsoleplugin next week.

Best Regards
Georg

[1]

https://issues.apache.org/jira/issues/?jql=project%20%3D%20FELIX%20AND%20resolution%20%3D%20Fixed%20AND%20component%20%3D%20%22Health%20Checks%22

[jira] [Commented] (FELIX-6008) ErrorHandlers should be applied in reverse order

[David Bosschaert (JIRA)]

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

David Bosschaert commented on FELIX-6008:
-

I'm thinking should this also be the case for custom rules?

> ErrorHandlers should be applied in reverse order
> 
>
> Key: FELIX-6008
> URL: https://issues.apache.org/jira/browse/FELIX-6008
> Project: Felix
>  Issue Type: Bug
>  Components: Converter
>Affects Versions: converter-1.0.2
>Reporter: Cristiano Gavião
>Assignee: David Bosschaert
>Priority: Major
>
> It could become common to create a new converter from an existent one.
> So, in case of more than one errorHandler were registered they must be 
> applied in reverse order.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FELIX-6031) Converter is not working properly when the target is an interface that extends others

[David Bosschaert (JIRA)]

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

David Bosschaert commented on FELIX-6031:
-

Ah [~bisch...@jena.de] could you please let us know if this fix also addresses 
FELIX-6020 ?

> Converter is not working properly when the target is an interface that 
> extends others
> -
>
> Key: FELIX-6031
> URL: https://issues.apache.org/jira/browse/FELIX-6031
> Project: Felix
>  Issue Type: Bug
>  Components: Converter
>Affects Versions: converter-1.0.2
>Reporter: Cristiano Gavião
>Assignee: David Bosschaert
>Priority: Critical
> Fix For: converter-1.0.4
>
>
> I'm converting from a map to an interface and since that interface has not 
> any direct method
>  it is not being considered a "map". But one of the interfaces that it 
> extends has the required method named with the source's map key name.
> The problem is in the routine that identifies the interfaces in the method 
> "getInterfaces0":
> {code:java}
>   private static boolean isMapType(Class< ? > cls, boolean asJavaBean,
>   boolean asDTO) {
>   if (asDTO)
>   return true;
>   // All interface types that are not Collections are treated as 
> maps
>   if (Map.class.isAssignableFrom(cls))
>   return true;
>   *else if (getInterfaces(cls).size() > 0)*
>   return true;
>   else if (DTOUtil.isDTOType(cls))
>   return true;
>   else if (asJavaBean && isWriteableJavaBean(cls))
>   return true;
>   else
>   return Dictionary.class.isAssignableFrom(cls);
>   }
> {code}
> {code:java}
>   private static Set> getInterfaces(Class< ? > cls) {
>   if (NO_MAP_VIEW_TYPES.contains(cls))
>   return Collections.emptySet();
>   Set> interfaces = getInterfaces0(cls);
>   for (Iterator> it = interfaces.iterator(); 
> it.hasNext();) {
>   Class< ? > intf = it.next();
>   if (intf.getDeclaredMethods().length == 0)
>   it.remove();
>   }
>   interfaces.removeAll(NO_MAP_VIEW_TYPES);
>   return interfaces;
>   }
> {code}
> {code:java}
>   private static Set> getInterfaces0(Class< ? > cls) {
>   if (cls == null)
>   return Collections.emptySet();
>   Set> classes = new LinkedHashSet<>();
>   if (cls.isInterface()) {
>   classes.add(cls);
>   } else {
>   classes.addAll(Arrays.asList(cls.getInterfaces()));
>   }
>   classes.addAll(getInterfaces(cls.getSuperclass()));
>   return classes;
>   }
> {code}
> Below is my proposed fix that recursively takes all interfaces that the 
> target extends:
> {code:java}
>   private static Set> getInterfaces0(Class< ? > cls) {
>   if (cls == null)
>   return Collections.emptySet();
>   Set> classes = new LinkedHashSet<>();
>   if (cls.isInterface()) {
>   classes.add(cls);
>   if (cls.getInterfaces()!= null && 
> cls.getInterfaces().length > 0) {
>   for (Class intf : cls.getInterfaces()) {
> classes.addAll(getInterfaces0(intf));
> }
>   }
>   } else {
>   classes.addAll(Arrays.asList(cls.getInterfaces()));
>   }
>   classes.addAll(getInterfaces(cls.getSuperclass()));
>   return classes;
>   }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (FELIX-6008) ErrorHandlers should be applied in reverse order

[David Bosschaert (JIRA)]

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

David Bosschaert reassigned FELIX-6008:
---

Assignee: David Bosschaert

> ErrorHandlers should be applied in reverse order
> 
>
> Key: FELIX-6008
> URL: https://issues.apache.org/jira/browse/FELIX-6008
> Project: Felix
>  Issue Type: Bug
>  Components: Converter
>Affects Versions: converter-1.0.2
>Reporter: Cristiano Gavião
>Assignee: David Bosschaert
>Priority: Major
>
> It could become common to create a new converter from an existent one.
> So, in case of more than one errorHandler were registered they must be 
> applied in reverse order.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [DISCUSS] First release of health check modules annotation, api, core, generalchecks and webconsoleplugin

[Raymond Auge]

Great!

I haven't looked so it might already be done, but I would ask that
requirements and capabilities be used so that we can resolve a running
system with minimal configuration.

I can help if someone explains the pieces to me.

- Ray

On Fri, Jan 18, 2019 at 10:04 AM Georg Henzler  wrote:

> Hi all,
>
> I have spend quite a bit time to polish the new Felix Health Checks
> before the first release:
>
> * The API has been cleaned up while maintaining backwards compatibility
> for 99% of the checks out in the wild (migration guide will be provided
> in Sling)
> * Dependencies have been minimised, api and core core run as soon as
> slf4j api and servlet api is available
> * The new status TEMPORARILY_UNAVAILABLE allows to distinguish
> startup/deployment unavailabilities clearly from other CRITICAL problems
> * General checks have been introduced and polished (that part has
> improved quite a bit compared to what it was in Sling): Sys Admins can
> quickly add checks (web console by configuration only) for JMX
> attributes, requests or add scripts to check arbitrary conditions.
> * Servlet Filters have been introduced to a) flexibly track certain
> requests by registering dynamic tags and b) cut off certain (or all)
> requests with 503 if certain tags have a certain status values.
>
> See [1] for all tickets solved.
>
>  From my point of view everything is ready for the first release but
> feedback is welcome! I plan to create the releases for the modules
> annotation, api, core, generalchecks and webconsoleplugin next week.
>
> Best Regards
> Georg
>
> [1]
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20FELIX%20AND%20resolution%20%3D%20Fixed%20AND%20component%20%3D%20%22Health%20Checks%22
>


-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)

[jira] [Commented] (FELIX-6031) Converter is not working properly when the target is an interface that extends others

[Stefan Bischof (JIRA)]

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

Stefan Bischof commented on FELIX-6031:
---

refs: https://issues.apache.org/jira/browse/FELIX-6020

> Converter is not working properly when the target is an interface that 
> extends others
> -
>
> Key: FELIX-6031
> URL: https://issues.apache.org/jira/browse/FELIX-6031
> Project: Felix
>  Issue Type: Bug
>  Components: Converter
>Affects Versions: converter-1.0.2
>Reporter: Cristiano Gavião
>Assignee: David Bosschaert
>Priority: Critical
> Fix For: converter-1.0.4
>
>
> I'm converting from a map to an interface and since that interface has not 
> any direct method
>  it is not being considered a "map". But one of the interfaces that it 
> extends has the required method named with the source's map key name.
> The problem is in the routine that identifies the interfaces in the method 
> "getInterfaces0":
> {code:java}
>   private static boolean isMapType(Class< ? > cls, boolean asJavaBean,
>   boolean asDTO) {
>   if (asDTO)
>   return true;
>   // All interface types that are not Collections are treated as 
> maps
>   if (Map.class.isAssignableFrom(cls))
>   return true;
>   *else if (getInterfaces(cls).size() > 0)*
>   return true;
>   else if (DTOUtil.isDTOType(cls))
>   return true;
>   else if (asJavaBean && isWriteableJavaBean(cls))
>   return true;
>   else
>   return Dictionary.class.isAssignableFrom(cls);
>   }
> {code}
> {code:java}
>   private static Set> getInterfaces(Class< ? > cls) {
>   if (NO_MAP_VIEW_TYPES.contains(cls))
>   return Collections.emptySet();
>   Set> interfaces = getInterfaces0(cls);
>   for (Iterator> it = interfaces.iterator(); 
> it.hasNext();) {
>   Class< ? > intf = it.next();
>   if (intf.getDeclaredMethods().length == 0)
>   it.remove();
>   }
>   interfaces.removeAll(NO_MAP_VIEW_TYPES);
>   return interfaces;
>   }
> {code}
> {code:java}
>   private static Set> getInterfaces0(Class< ? > cls) {
>   if (cls == null)
>   return Collections.emptySet();
>   Set> classes = new LinkedHashSet<>();
>   if (cls.isInterface()) {
>   classes.add(cls);
>   } else {
>   classes.addAll(Arrays.asList(cls.getInterfaces()));
>   }
>   classes.addAll(getInterfaces(cls.getSuperclass()));
>   return classes;
>   }
> {code}
> Below is my proposed fix that recursively takes all interfaces that the 
> target extends:
> {code:java}
>   private static Set> getInterfaces0(Class< ? > cls) {
>   if (cls == null)
>   return Collections.emptySet();
>   Set> classes = new LinkedHashSet<>();
>   if (cls.isInterface()) {
>   classes.add(cls);
>   if (cls.getInterfaces()!= null && 
> cls.getInterfaces().length > 0) {
>   for (Class intf : cls.getInterfaces()) {
> classes.addAll(getInterfaces0(intf));
> }
>   }
>   } else {
>   classes.addAll(Arrays.asList(cls.getInterfaces()));
>   }
>   classes.addAll(getInterfaces(cls.getSuperclass()));
>   return classes;
>   }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[DISCUSS] First release of health check modules annotation, api, core, generalchecks and webconsoleplugin

[Georg Henzler]

Hi all,

I have spend quite a bit time to polish the new Felix Health Checks 
before the first release:


* The API has been cleaned up while maintaining backwards compatibility 
for 99% of the checks out in the wild (migration guide will be provided 
in Sling)
* Dependencies have been minimised, api and core core run as soon as 
slf4j api and servlet api is available
* The new status TEMPORARILY_UNAVAILABLE allows to distinguish 
startup/deployment unavailabilities clearly from other CRITICAL problems
* General checks have been introduced and polished (that part has 
improved quite a bit compared to what it was in Sling): Sys Admins can 
quickly add checks (web console by configuration only) for JMX 
attributes, requests or add scripts to check arbitrary conditions.
* Servlet Filters have been introduced to a) flexibly track certain 
requests by registering dynamic tags and b) cut off certain (or all) 
requests with 503 if certain tags have a certain status values.


See [1] for all tickets solved.

From my point of view everything is ready for the first release but 
feedback is welcome! I plan to create the releases for the modules 
annotation, api, core, generalchecks and webconsoleplugin next week.


Best Regards
Georg

[1] 
https://issues.apache.org/jira/issues/?jql=project%20%3D%20FELIX%20AND%20resolution%20%3D%20Fixed%20AND%20component%20%3D%20%22Health%20Checks%22

[jira] [Commented] (FELIX-6017) Ongoing deployment servlet filter that controls a dynamic health check

[Georg Henzler (JIRA)]

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

Georg Henzler commented on FELIX-6017:
--

Improved config attribute names in [r1851627|http://svn.apache.org/r1851627]

> Ongoing deployment servlet filter that controls a dynamic health check 
> ---
>
> Key: FELIX-6017
> URL: https://issues.apache.org/jira/browse/FELIX-6017
> Project: Felix
>  Issue Type: New Feature
>  Components: Health Checks
>Reporter: Georg Henzler
>Assignee: Georg Henzler
>Priority: Major
>
> On configurable paths/headers/request parameters, a servlet filter is to be 
> implemented that dynamically adds a HC service with status 
> TEMPORARILY_UNAVAILABLE (or other status, configurable) while the request is 
> active. 
> This can be used for both bundle/config update/deployment http requests to 
> Felix web console (the plain Felix way) or other http deployment mechanisms 
> as used by products built on top of Felix.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (FELIX-6031) Converter is not working properly when the target is an interface that extends others

[David Bosschaert (JIRA)]

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

David Bosschaert resolved FELIX-6031.
-
Resolution: Fixed

> Converter is not working properly when the target is an interface that 
> extends others
> -
>
> Key: FELIX-6031
> URL: https://issues.apache.org/jira/browse/FELIX-6031
> Project: Felix
>  Issue Type: Bug
>  Components: Converter
>Affects Versions: converter-1.0.2
>Reporter: Cristiano Gavião
>Assignee: David Bosschaert
>Priority: Critical
> Fix For: converter-1.0.4
>
>
> I'm converting from a map to an interface and since that interface has not 
> any direct method
>  it is not being considered a "map". But one of the interfaces that it 
> extends has the required method named with the source's map key name.
> The problem is in the routine that identifies the interfaces in the method 
> "getInterfaces0":
> {code:java}
>   private static boolean isMapType(Class< ? > cls, boolean asJavaBean,
>   boolean asDTO) {
>   if (asDTO)
>   return true;
>   // All interface types that are not Collections are treated as 
> maps
>   if (Map.class.isAssignableFrom(cls))
>   return true;
>   *else if (getInterfaces(cls).size() > 0)*
>   return true;
>   else if (DTOUtil.isDTOType(cls))
>   return true;
>   else if (asJavaBean && isWriteableJavaBean(cls))
>   return true;
>   else
>   return Dictionary.class.isAssignableFrom(cls);
>   }
> {code}
> {code:java}
>   private static Set> getInterfaces(Class< ? > cls) {
>   if (NO_MAP_VIEW_TYPES.contains(cls))
>   return Collections.emptySet();
>   Set> interfaces = getInterfaces0(cls);
>   for (Iterator> it = interfaces.iterator(); 
> it.hasNext();) {
>   Class< ? > intf = it.next();
>   if (intf.getDeclaredMethods().length == 0)
>   it.remove();
>   }
>   interfaces.removeAll(NO_MAP_VIEW_TYPES);
>   return interfaces;
>   }
> {code}
> {code:java}
>   private static Set> getInterfaces0(Class< ? > cls) {
>   if (cls == null)
>   return Collections.emptySet();
>   Set> classes = new LinkedHashSet<>();
>   if (cls.isInterface()) {
>   classes.add(cls);
>   } else {
>   classes.addAll(Arrays.asList(cls.getInterfaces()));
>   }
>   classes.addAll(getInterfaces(cls.getSuperclass()));
>   return classes;
>   }
> {code}
> Below is my proposed fix that recursively takes all interfaces that the 
> target extends:
> {code:java}
>   private static Set> getInterfaces0(Class< ? > cls) {
>   if (cls == null)
>   return Collections.emptySet();
>   Set> classes = new LinkedHashSet<>();
>   if (cls.isInterface()) {
>   classes.add(cls);
>   if (cls.getInterfaces()!= null && 
> cls.getInterfaces().length > 0) {
>   for (Class intf : cls.getInterfaces()) {
> classes.addAll(getInterfaces0(intf));
> }
>   }
>   } else {
>   classes.addAll(Arrays.asList(cls.getInterfaces()));
>   }
>   classes.addAll(getInterfaces(cls.getSuperclass()));
>   return classes;
>   }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (FELIX-6031) Converter is not working properly when the target is an interface that extends others

[David Bosschaert (JIRA)]

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

David Bosschaert reassigned FELIX-6031:
---

Assignee: David Bosschaert

> Converter is not working properly when the target is an interface that 
> extends others
> -
>
> Key: FELIX-6031
> URL: https://issues.apache.org/jira/browse/FELIX-6031
> Project: Felix
>  Issue Type: Bug
>  Components: Converter
>Affects Versions: converter-1.0.2
>Reporter: Cristiano Gavião
>Assignee: David Bosschaert
>Priority: Critical
>
> I'm converting from a map to an interface and since that interface has not 
> any direct method
>  it is not being considered a "map". But one of the interfaces that it 
> extends has the required method named with the source's map key name.
> The problem is in the routine that identifies the interfaces in the method 
> "getInterfaces0":
> {code:java}
>   private static boolean isMapType(Class< ? > cls, boolean asJavaBean,
>   boolean asDTO) {
>   if (asDTO)
>   return true;
>   // All interface types that are not Collections are treated as 
> maps
>   if (Map.class.isAssignableFrom(cls))
>   return true;
>   *else if (getInterfaces(cls).size() > 0)*
>   return true;
>   else if (DTOUtil.isDTOType(cls))
>   return true;
>   else if (asJavaBean && isWriteableJavaBean(cls))
>   return true;
>   else
>   return Dictionary.class.isAssignableFrom(cls);
>   }
> {code}
> {code:java}
>   private static Set> getInterfaces(Class< ? > cls) {
>   if (NO_MAP_VIEW_TYPES.contains(cls))
>   return Collections.emptySet();
>   Set> interfaces = getInterfaces0(cls);
>   for (Iterator> it = interfaces.iterator(); 
> it.hasNext();) {
>   Class< ? > intf = it.next();
>   if (intf.getDeclaredMethods().length == 0)
>   it.remove();
>   }
>   interfaces.removeAll(NO_MAP_VIEW_TYPES);
>   return interfaces;
>   }
> {code}
> {code:java}
>   private static Set> getInterfaces0(Class< ? > cls) {
>   if (cls == null)
>   return Collections.emptySet();
>   Set> classes = new LinkedHashSet<>();
>   if (cls.isInterface()) {
>   classes.add(cls);
>   } else {
>   classes.addAll(Arrays.asList(cls.getInterfaces()));
>   }
>   classes.addAll(getInterfaces(cls.getSuperclass()));
>   return classes;
>   }
> {code}
> Below is my proposed fix that recursively takes all interfaces that the 
> target extends:
> {code:java}
>   private static Set> getInterfaces0(Class< ? > cls) {
>   if (cls == null)
>   return Collections.emptySet();
>   Set> classes = new LinkedHashSet<>();
>   if (cls.isInterface()) {
>   classes.add(cls);
>   if (cls.getInterfaces()!= null && 
> cls.getInterfaces().length > 0) {
>   for (Class intf : cls.getInterfaces()) {
> classes.addAll(getInterfaces0(intf));
> }
>   }
>   } else {
>   classes.addAll(Arrays.asList(cls.getInterfaces()));
>   }
>   classes.addAll(getInterfaces(cls.getSuperclass()));
>   return classes;
>   }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FELIX-6031) Converter is not working properly when the target is an interface that extends others

[David Bosschaert (JIRA)]

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

David Bosschaert commented on FELIX-6031:
-

Fixed in [http://svn.apache.org/viewvc?view=revision&revision=1851622] - 
[~cvgaviao] could you please double check that its all good for you?

> Converter is not working properly when the target is an interface that 
> extends others
> -
>
> Key: FELIX-6031
> URL: https://issues.apache.org/jira/browse/FELIX-6031
> Project: Felix
>  Issue Type: Bug
>  Components: Converter
>Affects Versions: converter-1.0.2
>Reporter: Cristiano Gavião
>Assignee: David Bosschaert
>Priority: Critical
> Fix For: converter-1.0.4
>
>
> I'm converting from a map to an interface and since that interface has not 
> any direct method
>  it is not being considered a "map". But one of the interfaces that it 
> extends has the required method named with the source's map key name.
> The problem is in the routine that identifies the interfaces in the method 
> "getInterfaces0":
> {code:java}
>   private static boolean isMapType(Class< ? > cls, boolean asJavaBean,
>   boolean asDTO) {
>   if (asDTO)
>   return true;
>   // All interface types that are not Collections are treated as 
> maps
>   if (Map.class.isAssignableFrom(cls))
>   return true;
>   *else if (getInterfaces(cls).size() > 0)*
>   return true;
>   else if (DTOUtil.isDTOType(cls))
>   return true;
>   else if (asJavaBean && isWriteableJavaBean(cls))
>   return true;
>   else
>   return Dictionary.class.isAssignableFrom(cls);
>   }
> {code}
> {code:java}
>   private static Set> getInterfaces(Class< ? > cls) {
>   if (NO_MAP_VIEW_TYPES.contains(cls))
>   return Collections.emptySet();
>   Set> interfaces = getInterfaces0(cls);
>   for (Iterator> it = interfaces.iterator(); 
> it.hasNext();) {
>   Class< ? > intf = it.next();
>   if (intf.getDeclaredMethods().length == 0)
>   it.remove();
>   }
>   interfaces.removeAll(NO_MAP_VIEW_TYPES);
>   return interfaces;
>   }
> {code}
> {code:java}
>   private static Set> getInterfaces0(Class< ? > cls) {
>   if (cls == null)
>   return Collections.emptySet();
>   Set> classes = new LinkedHashSet<>();
>   if (cls.isInterface()) {
>   classes.add(cls);
>   } else {
>   classes.addAll(Arrays.asList(cls.getInterfaces()));
>   }
>   classes.addAll(getInterfaces(cls.getSuperclass()));
>   return classes;
>   }
> {code}
> Below is my proposed fix that recursively takes all interfaces that the 
> target extends:
> {code:java}
>   private static Set> getInterfaces0(Class< ? > cls) {
>   if (cls == null)
>   return Collections.emptySet();
>   Set> classes = new LinkedHashSet<>();
>   if (cls.isInterface()) {
>   classes.add(cls);
>   if (cls.getInterfaces()!= null && 
> cls.getInterfaces().length > 0) {
>   for (Class intf : cls.getInterfaces()) {
> classes.addAll(getInterfaces0(intf));
> }
>   }
>   } else {
>   classes.addAll(Arrays.asList(cls.getInterfaces()));
>   }
>   classes.addAll(getInterfaces(cls.getSuperclass()));
>   return classes;
>   }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FELIX-6031) Converter is not working properly when the target is an interface that extends others

[David Bosschaert (JIRA)]

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

David Bosschaert updated FELIX-6031:

Fix Version/s: converter-1.0.4

> Converter is not working properly when the target is an interface that 
> extends others
> -
>
> Key: FELIX-6031
> URL: https://issues.apache.org/jira/browse/FELIX-6031
> Project: Felix
>  Issue Type: Bug
>  Components: Converter
>Affects Versions: converter-1.0.2
>Reporter: Cristiano Gavião
>Assignee: David Bosschaert
>Priority: Critical
> Fix For: converter-1.0.4
>
>
> I'm converting from a map to an interface and since that interface has not 
> any direct method
>  it is not being considered a "map". But one of the interfaces that it 
> extends has the required method named with the source's map key name.
> The problem is in the routine that identifies the interfaces in the method 
> "getInterfaces0":
> {code:java}
>   private static boolean isMapType(Class< ? > cls, boolean asJavaBean,
>   boolean asDTO) {
>   if (asDTO)
>   return true;
>   // All interface types that are not Collections are treated as 
> maps
>   if (Map.class.isAssignableFrom(cls))
>   return true;
>   *else if (getInterfaces(cls).size() > 0)*
>   return true;
>   else if (DTOUtil.isDTOType(cls))
>   return true;
>   else if (asJavaBean && isWriteableJavaBean(cls))
>   return true;
>   else
>   return Dictionary.class.isAssignableFrom(cls);
>   }
> {code}
> {code:java}
>   private static Set> getInterfaces(Class< ? > cls) {
>   if (NO_MAP_VIEW_TYPES.contains(cls))
>   return Collections.emptySet();
>   Set> interfaces = getInterfaces0(cls);
>   for (Iterator> it = interfaces.iterator(); 
> it.hasNext();) {
>   Class< ? > intf = it.next();
>   if (intf.getDeclaredMethods().length == 0)
>   it.remove();
>   }
>   interfaces.removeAll(NO_MAP_VIEW_TYPES);
>   return interfaces;
>   }
> {code}
> {code:java}
>   private static Set> getInterfaces0(Class< ? > cls) {
>   if (cls == null)
>   return Collections.emptySet();
>   Set> classes = new LinkedHashSet<>();
>   if (cls.isInterface()) {
>   classes.add(cls);
>   } else {
>   classes.addAll(Arrays.asList(cls.getInterfaces()));
>   }
>   classes.addAll(getInterfaces(cls.getSuperclass()));
>   return classes;
>   }
> {code}
> Below is my proposed fix that recursively takes all interfaces that the 
> target extends:
> {code:java}
>   private static Set> getInterfaces0(Class< ? > cls) {
>   if (cls == null)
>   return Collections.emptySet();
>   Set> classes = new LinkedHashSet<>();
>   if (cls.isInterface()) {
>   classes.add(cls);
>   if (cls.getInterfaces()!= null && 
> cls.getInterfaces().length > 0) {
>   for (Class intf : cls.getInterfaces()) {
> classes.addAll(getInterfaces0(intf));
> }
>   }
>   } else {
>   classes.addAll(Arrays.asList(cls.getInterfaces()));
>   }
>   classes.addAll(getInterfaces(cls.getSuperclass()));
>   return classes;
>   }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FELIX-6018) Servlet Filter to answer arbitrary http requests with 503 if certain HC tags are in non-OK status

[Georg Henzler (JIRA)]

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

Georg Henzler commented on FELIX-6018:
--

Obviously activating this filter comes at a cost for every request (unless 
autoDisableFilter is configured to true), however the cost is reasonably small 
- tests showed it takes around 0.2 ms per call. (~200,000 ns, see 
http://svn.apache.org/viewvc/felix/trunk/healthcheck/core/src/main/java/org/apache/felix/hc/core/impl/filter/ServiceUnavailableFilter.java?view=markup&pathrev=1850907#l196
 on how to track this).

> Servlet Filter to answer arbitrary http requests with 503 if certain HC tags 
> are in non-OK status
> -
>
> Key: FELIX-6018
> URL: https://issues.apache.org/jira/browse/FELIX-6018
> Project: Felix
>  Issue Type: New Feature
>  Components: Health Checks
>Reporter: Georg Henzler
>Assignee: Georg Henzler
>Priority: Major
>
> Servlet Filter to answer arbitrary http requests with 503 if certain HC tags 
> are in non-OK result:
> * Can be used together with ongoing deployment filter FELIX-6017 to answer 
> all http requests with 503 during deployment
> * Can replace sling startup filter SLING-2347 for sling platforms



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)