[jira] [Created] (FELIX-6033) wc command should be compliant with posix ones

2019-01-21 Thread JIRA 
Jean-Baptiste Onofré created FELIX-6033:
---

 Summary: wc command should be compliant with posix ones
 Key: FELIX-6033
 URL: https://issues.apache.org/jira/browse/FELIX-6033
 Project: Felix
  Issue Type: Bug
  Components: Gogo JLine
Affects Versions: gogo.jline-1.1.2, gogo.jline-1.1.0
Reporter: Jean-Baptiste Onofré
Assignee: Jean-Baptiste Onofré
 Fix For: gogo.jline-1.1.3


The Posix {{wc}} command formatting is not fully correct. For instance, a 
simple:

{code}
echo "foo\nbar"|wc -l
{code}

displays:

{code}
   2 2
{code}

So the output formatting is not correct (result is displayed twice) and {{wc}} 
can't be easily used in scripting.

To be compliant with standard Posix {{wc}} command, the output should be:

{code}
2
{code}

I'm adding tests and fixes.



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

[jira] [Resolved] (FELIX-6019) Provide a bnd plugin to remove header parameters

2019-01-21 Thread Oliver Lietz (JIRA) 


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

Oliver Lietz resolved FELIX-6019.
-
Resolution: Won't Do

> Provide a bnd plugin to remove header parameters
> 
>
> Key: FELIX-6019
> URL: https://issues.apache.org/jira/browse/FELIX-6019
> Project: Felix
>  Issue Type: New Feature
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
>Priority: Major
>
> The plugin removes parameters from bundle headers.
> See bnd issue [#2429|https://github.com/bndtools/bnd/issues/2429] and 
> SLING-8178.
> Example instruction (for bnd file):
> {noformat}
> -plugin:\
>   org.apache.felix.bnd.plugins.header.RemoveParametersPlugin;\
> 
> 'Require-Capability'='osgi.service;filter:="(objectClass=org.osgi.service.event.EventAdmin)";effective:=active,osgi.service;filter:="(objectClass=org.osgi.service.event.EventHandler)";effective:=active;cardinality:=multiple'
> {noformat}
> Initial source: 
> https://svn.apache.org/repos/asf/felix/sandbox/olli/org.apache.felix.bnd.plugins/



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

[jira] [Closed] (FELIX-6019) Provide a bnd plugin to remove header parameters

2019-01-21 Thread Oliver Lietz (JIRA) 


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

Oliver Lietz closed FELIX-6019.
---

> Provide a bnd plugin to remove header parameters
> 
>
> Key: FELIX-6019
> URL: https://issues.apache.org/jira/browse/FELIX-6019
> Project: Felix
>  Issue Type: New Feature
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
>Priority: Major
>
> The plugin removes parameters from bundle headers.
> See bnd issue [#2429|https://github.com/bndtools/bnd/issues/2429] and 
> SLING-8178.
> Example instruction (for bnd file):
> {noformat}
> -plugin:\
>   org.apache.felix.bnd.plugins.header.RemoveParametersPlugin;\
> 
> 'Require-Capability'='osgi.service;filter:="(objectClass=org.osgi.service.event.EventAdmin)";effective:=active,osgi.service;filter:="(objectClass=org.osgi.service.event.EventHandler)";effective:=active;cardinality:=multiple'
> {noformat}
> Initial source: 
> https://svn.apache.org/repos/asf/felix/sandbox/olli/org.apache.felix.bnd.plugins/



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

Re: [VOTE] Release Felix Logback 1.0.2

2019-01-21 Thread Raymond Auge 
This vote passed with 6 votes from David, Karl, Robert, JB, Pierre and
myself.

I will publish the artifacts ASAP.

- Ray

On Mon, Jan 21, 2019 at 3:21 PM Raymond Auge 
wrote:

> +1
>
> - Ray
>
> On Thu, Jan 17, 2019 at 4:09 AM Pierre De Rop 
> wrote:
>
>> +1
>>
>> thanks
>> Pierre
>>
>>
>> On Tue, Jan 15, 2019 at 4:58 PM Jean-Baptiste Onofré 
>> wrote:
>>
>> > +1 (binding)
>> >
>> > Regards
>> > JB
>> >
>> > On 15/01/2019 15:40, Raymond Auge wrote:
>> > > Hi,
>> > >
>> > > We solved 1 issue in this release (release notes):
>> > >
>> >
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100=12343486
>> > >
>> > > Staging repository:
>> > >
>> https://repository.apache.org/content/repositories/orgapachefelix-1276
>> > >
>> > > You can use this UNIX script to download the release and verify the
>> > > signatures:
>> > > http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
>> > >
>> > > Usage:
>> > > sh check_staged_release.sh 1276 /tmp/felix-staging
>> > >
>> > > Please vote to approve this release:
>> > >
>> > > [ ] +1 Approve the release
>> > > [ ] -1 Veto the release (please provide specific comments)
>> > >
>> > > This vote will be open for 72 hours.
>> > >
>> >
>> > --
>> > Jean-Baptiste Onofré
>> > jbono...@apache.org
>> > http://blog.nanthrax.net
>> > Talend - http://www.talend.com
>> >
>>
>
>
> --
> *Raymond Augé* 
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* 
>  (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance 
> (@OSGiAlliance)
>


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

Re: [VOTE] Release Felix Logback 1.0.2

2019-01-21 Thread Raymond Auge 
+1

- Ray

On Thu, Jan 17, 2019 at 4:09 AM Pierre De Rop 
wrote:

> +1
>
> thanks
> Pierre
>
>
> On Tue, Jan 15, 2019 at 4:58 PM Jean-Baptiste Onofré 
> wrote:
>
> > +1 (binding)
> >
> > Regards
> > JB
> >
> > On 15/01/2019 15:40, Raymond Auge wrote:
> > > Hi,
> > >
> > > We solved 1 issue in this release (release notes):
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100=12343486
> > >
> > > Staging repository:
> > > https://repository.apache.org/content/repositories/orgapachefelix-1276
> > >
> > > You can use this UNIX script to download the release and verify the
> > > signatures:
> > > http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
> > >
> > > Usage:
> > > sh check_staged_release.sh 1276 /tmp/felix-staging
> > >
> > > Please vote to approve this release:
> > >
> > > [ ] +1 Approve the release
> > > [ ] -1 Veto the release (please provide specific comments)
> > >
> > > This vote will be open for 72 hours.
> > >
> >
> > --
> > Jean-Baptiste Onofré
> > jbono...@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
> >
>


-- 
*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

2019-01-21 Thread Raymond Auge 
On Mon, Jan 21, 2019 at 2:19 AM Georg Henzler  wrote:

> Hi Ray,
>
> so your suggestion is more about referring to a capability like
> "org.apache.felix.healthcheck" by using requirements in other bundles
> than writing a health check that ensures the framework provides a
> certain non-healthcheck-related capability.
>

Precisely,

- Ray


>
> > I can probably try it out and submit the proper cap
>
> that would be great!
>
> -Georg
>
>
> On 2019-01-18 17:28, Raymond Auge wrote:
> > 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
> >
> > :)
> >
> >
> > - 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)

[jira] [Resolved] (FELIX-6020) Converter could not convert to Interfaces, which only has methods from inherited Interfaces

2019-01-21 Thread David Bosschaert (JIRA) 


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

David Bosschaert resolved FELIX-6020.
-
   Resolution: Fixed
 Assignee: David Bosschaert
Fix Version/s: converter-1.0.4

Resolved with FELIX-6031

> Converter could not convert to Interfaces, which only has methods from 
> inherited Interfaces
> ---
>
> Key: FELIX-6020
> URL: https://issues.apache.org/jira/browse/FELIX-6020
> Project: Felix
>  Issue Type: Bug
>  Components: Converter
>Affects Versions: converter-1.0.2
>Reporter: Stefan Bischof
>Assignee: David Bosschaert
>Priority: Major
> Fix For: converter-1.0.4
>
>
> Hi,
> the Converter could not convert to an Interfaces, when the Interface only has 
> methods from inherited other Interfaces. 
> Here is a TestCase:
> {code:java}
> import static org.junit.Assert.assertEquals;
> import java.util.HashMap;
> import java.util.Map;
> import org.junit.Test;
> import org.osgi.util.converter.Converter;
> import org.osgi.util.converter.Converters;
> public class ConvTest {
>     interface InterfaceFoo {
>         String foo();
>     }
>     interface InterfaceFooBar extends InterfaceFoo {
>         String bar();
>     }
>     interface InterfaceFooNon extends InterfaceFoo {
>         // Empty
>     }
>     private static final String fooValue = "foofoo";
>     private static final String barValue = "barbar";
>     final Converter converter = Converters.standardConverter();
>     @Test
>     public void testFooPure() throws Exception {
>         final Map map = new HashMap();
>         map.put("foo", fooValue);
>         final InterfaceFoo iFoo = 
> converter.convert(map).to(InterfaceFoo.class);
>         assertEquals(fooValue, iFoo.foo());
>     }
>     @Test
>     public void testFooBar() throws Exception {
>         final Map map = new HashMap();
>         map.put("foo", fooValue);
>         map.put("bar", barValue);
>         final InterfaceFooBar iFooBar = 
> converter.convert(map).to(InterfaceFooBar.class);
>         assertEquals(fooValue, iFooBar.foo());
>         assertEquals(barValue, iFooBar.bar());
>     }
>     @Test
>     public void testFooNon() throws Exception {
>         final Map map = new HashMap();
>         map.put("foo", fooValue);
>         final InterfaceFooNon iFooNon = 
> converter.convert(map).to(InterfaceFooNon.class);
>         assertEquals(fooValue, iFooNon.foo());
>     }
> }{code}
>  
>  
> Stacktrace
> {code:java}
> org.osgi.util.converter.ConversionException: Cannot convert foo to interface 
> de.jena.servicehub.doc.latex.itest.ConvTest$InterfaceFooNon
>     at org.osgi.util.converter.ConvertingImpl.to(ConvertingImpl.java:212)
>     at 
> org.osgi.util.converter.CustomConverterImpl$ConvertingWrapper.to(CustomConverterImpl.java:176)
>     at 
> org.osgi.util.converter.CustomConverterImpl$ConvertingWrapper.to(CustomConverterImpl.java:139)
>     at 
> org.osgi.util.converter.ConvertingImpl.convertMapEntryToSingleValue(ConvertingImpl.java:260)
>     at org.osgi.util.converter.ConvertingImpl.to(ConvertingImpl.java:197)
>     at 
> org.osgi.util.converter.CustomConverterImpl$ConvertingWrapper.to(CustomConverterImpl.java:176)
>     at 
> org.osgi.util.converter.CustomConverterImpl$ConvertingWrapper.to(CustomConverterImpl.java:139)
>     at 
> org.osgi.util.converter.ConvertingImpl.convertMapToSingleValue(ConvertingImpl.java:236)
>     at org.osgi.util.converter.ConvertingImpl.to(ConvertingImpl.java:195)
>     at 
> org.osgi.util.converter.CustomConverterImpl$ConvertingWrapper.to(CustomConverterImpl.java:176)
>     at 
> org.osgi.util.converter.CustomConverterImpl$ConvertingWrapper.to(CustomConverterImpl.java:139)
> {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

2019-01-21 Thread David Bosschaert (JIRA) 


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

David Bosschaert commented on FELIX-6031:
-

Just deployed a snapshot: 
[https://repository.apache.org/content/groups/snapshots/org/apache/felix/org.apache.felix.converter/1.0.3-SNAPSHOT/]

> 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-6031) Converter is not working properly when the target is an interface that extends others

2019-01-21 Thread Stefan Bischof (JIRA) 


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

Stefan Bischof commented on FELIX-6031:
---

Hi [~bosschaert], i run the tests shown in 
https://issues.apache.org/jira/browse/FELIX-6020 and it worked.

 

Thanks a lot.

But: I didn't found an snapshot version in the apache mvn snapshot repo:

https://repository.apache.org/content/groups/snapshots/org/apache/felix/org.apache.felix.converter/

> 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)