Re: DS code formatting

[Carsten Ziegeler]

David Jencks wrote
> For reasons unclear to me Eclipse has started saving modified files 
> reformatted with the felix eclipse code template.  This, to put it mildly, 
> has shown that the code isn’t formatted with  the template, and I can’t fish 
> out my actual changes by hand.
> 
> What would people think if I reformatted the entire DS project and checked in 
> the result?  I’m hoping that I can convince git to end up showing me my 
> actual changes after this exercise.
> 
> In a somewhat separate issue, I have so far been unable to convince Eclipse 
> to let me open the R7 branch, so it’s possible someone else may have to apply 
> similar changes to that.
> 

I'm not sure but this doesn't sound like a good option to me. It seems
you're the only one atm having problems and the above sounds to me like
it will be painful for everyone else.
In addition I don't understand what formating problems you exactly have
and what "reformatting the entire DS project" means?

Carsten

 

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

[jira] [Commented] (FELIX-5622) Serializer uses concatenated version of String when DTO is a subclass of org.osgi.dto.DTO

[David Leangen (JIRA)]

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

David Leangen commented on FELIX-5622:
--

The workaround seems to be to first convert to a Map, then serialize. Is that 
intended?

> Serializer uses concatenated version of String when DTO is a subclass of 
> org.osgi.dto.DTO
> -
>
> Key: FELIX-5622
> URL: https://issues.apache.org/jira/browse/FELIX-5622
> Project: Felix
>  Issue Type: Bug
>  Components: Converter
>Reporter: David Leangen
>
> When a DTO inherits from org.osgi.dto.DTO, instead of serializing the actual 
> String value of a field, the concatenated version of the String serializes 
> the concatenated version from the DTO superclass.
> I don't think it is wrong to subclass DTO, but it is certainly wrong to 
> serialize the concatenated version of the String. :-)



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

DS code formatting

[David Jencks]

For reasons unclear to me Eclipse has started saving modified files reformatted 
with the felix eclipse code template.  This, to put it mildly, has shown that 
the code isn’t formatted with  the template, and I can’t fish out my actual 
changes by hand.

What would people think if I reformatted the entire DS project and checked in 
the result?  I’m hoping that I can convince git to end up showing me my actual 
changes after this exercise.

In a somewhat separate issue, I have so far been unable to convince Eclipse to 
let me open the R7 branch, so it’s possible someone else may have to apply 
similar changes to that.

thanks
david jencks

[jira] [Created] (FELIX-5622) Serializer uses concatenated version of String when DTO is a subclass of org.osgi.dto.DTO

[David Leangen (JIRA)]

David Leangen created FELIX-5622:


 Summary: Serializer uses concatenated version of String when DTO 
is a subclass of org.osgi.dto.DTO
 Key: FELIX-5622
 URL: https://issues.apache.org/jira/browse/FELIX-5622
 Project: Felix
  Issue Type: Bug
  Components: Converter
Reporter: David Leangen


When a DTO inherits from org.osgi.dto.DTO, instead of serializing the actual 
String value of a field, the concatenated version of the String serializes the 
concatenated version from the DTO superclass.

I don't think it is wrong to subclass DTO, but it is certainly wrong to 
serialize the concatenated version of the String. :-)



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

Re: Modifying service properties in lifecycle and bind methods

[David Jencks]

I opened FELIX-5621  about 
this.  I still think returning service properties from event methods cannot be 
made thread safe.

As noted in the issue, I think ExtComponentContext can be used safely with code 
like:

final AtomicReference> propRef;

...
  Dictionary oldProps;
  Dictionary newProps;
  do {
synchronized(propRef) {
  oldProps =  propRef.get();
  newProps = new Hashtable<>(oldProps);
}
//update newProps with new information
extComponentContext.setServiceProperties(newProps);
  } while ( propsRef.compareAndSet( oldProps, newProps)}

I think all we can do in code now is to say not to use the annotation on event 
methods.

thanks
david jencks

> On Apr 11, 2017, at 9:09 PM, David Jencks  wrote:
> 
> We seem to be thinking along similar lines…. earlier today I wrote this but 
> got distracted before sending:
> 
> At the moment I don’t see how returning the new service properties from 
> bimd/updated/unbind methods can be thread safe.  I think the 
> activate/modify/deactivate methods are ok.
> 
> I wonder if using the ExtComponentContext to modify the properties and 
> synchronizing access would lead to deadlocks.  Better than this would be a 
> compare-and-set method of some sort on ExtComponentContext, perhaps based on 
> a change count
> 
> int cc;
> Dictionary newProps;
> do {
>   cc = etc.getChangeCount();
>  newProps = new Hashtable<>(ecc.getProperties());
>  //update properties
> } while (!ecc.compareAndSet(cc, newProps)}
> 
> david jencks
> 
> 
>> On Apr 11, 2017, at 10:25 AM, Brent Daniel  wrote:
>> 
>> I agree that serializing everything would be counterproductive (though the
>> impact could be reduced by limiting synchronization to methods with the Map
>> return signature.) I wonder if it would be possible to implement a
>> lightweight scheme using update counts, though.
>> 
>> Otherwise it's probably a bad idea to ever have lifecycle and bind methods
>> that both update service properties. And, unfortunately, that may not be
>> all that obvious because the updates will happen in the expected order most
>> of the time. I'm not sure if modifying service properties is documented
>> somewhere (I couldn't find anything), but if it is this should probably be
>> mentioned there.
>> 
>> On Mon, Apr 10, 2017 at 3:28 PM, David Jencks 
>> wrote:
>> 
>>> I don’t think this is a bug.  To avoid this behavior I think we’d have to
>>> serialize all lifecycle method invocations which I believe to be very
>>> undesirable.
>>> 
>>> I could be wrong.
>>> 
>>> david jencks
>>> 
 On Apr 10, 2017, at 2:39 PM, Brent Daniel 
>>> wrote:
 
 Should there be any guarantees on the ordering of service property
>>> updates
 across methods?
 
 For example, say I have an activate method that simply returns the
>>> current
 service properties and a bind method that adds "active=true" to the
>>> current
 properties and returns the updated properties. Both methods are
 synchronized.
 
 Let's say activate() is invoked first and exits. Before Felix updates the
 service properties, another thread calls the bind method, and Felix
>>> updates
 the service properties to contain "active=true". Then the first thread
 updates the service properties to the set returned from the activate()
 method, thus blowing away the changes from the bind method.
 
 Is this a bug? Or should we not be relying on the property updates from
>>> the
 first method being called taking effect before the second method's
>>> updates?
>>> 
>>> 
> 

[jira] [Updated] (FELIX-5621) [DS] event methods setting service properties not thread safe

[David Jencks (JIRA)]

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

David Jencks updated FELIX-5621:

Description: 
Thanks to Brent Daniels for pointing this out.

Setting service properties from returning properties from event methods is not 
thread safe and does not appear to be possible to make thread safe, as 
synchronizing will almost certainly produce deadlocks. 

I think use of ExtComponentContext could be thread safe using code similar 
to

final AtomicReference> propRef;

...
  Dictionary oldProps;
  Dictionary newProps;
  do {
synchronized(propRef) {
  oldProps =  propRef.get();
  newProps = new Hashtable<>(oldProps);
}
//update newProps with new information
extComponentContext.setServiceProperties(newProps);
  } while ( propsRef.compareAndSet( oldProps, newProps)}




  was:
Thanks to Brent Daniels for pointing this out.

Setting service properties from event methods is not thread safe and does not 
appear to be possible to make thread safe, as synchronizing will almost 
certainly produce deadlocks.  This applies to both setting the properties on 
ExtComponentContext or returning a properties map.

If ExtComponentContext reliably provided a change counter and a compareAndSet 
method then it could be used in e.g.

{code}
int cc;
Dictionary newProps;
do {
  cc = etc.getChangeCount();
 newProps = new Hashtable<>(ecc.getProperties());
 //update properties
} while (!ecc.compareAndSet(cc, newProps)}
{code}

I don't think this can be implemented unless ServiceRegistration provides the 
same API.  Certainly the felix ServiceRegistration implementation is not thread 
safe.


> [DS] event methods setting service properties not thread safe
> -
>
> Key: FELIX-5621
> URL: https://issues.apache.org/jira/browse/FELIX-5621
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-2.0.8
>Reporter: David Jencks
>
> Thanks to Brent Daniels for pointing this out.
> Setting service properties from returning properties from event methods is 
> not thread safe and does not appear to be possible to make thread safe, as 
> synchronizing will almost certainly produce deadlocks. 
> I think use of ExtComponentContext could be thread safe using code similar 
> to
> final AtomicReference> propRef;
> ...
>   Dictionary oldProps;
>   Dictionary newProps;
>   do {
> synchronized(propRef) {
>   oldProps =  propRef.get();
>   newProps = new Hashtable<>(oldProps);
> }
> //update newProps with new information
> extComponentContext.setServiceProperties(newProps);
>   } while ( propsRef.compareAndSet( oldProps, newProps)}
> 



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

[jira] [Created] (FELIX-5621) [DS] event methods setting service properties not thread safe

[David Jencks (JIRA)]

David Jencks created FELIX-5621:
---

 Summary: [DS] event methods setting service properties not thread 
safe
 Key: FELIX-5621
 URL: https://issues.apache.org/jira/browse/FELIX-5621
 Project: Felix
  Issue Type: Bug
  Components: Declarative Services (SCR)
Affects Versions: scr-2.0.8
Reporter: David Jencks


Thanks to Brent Daniels for pointing this out.

Setting service properties from event methods is not thread safe and does not 
appear to be possible to make thread safe, as synchronizing will almost 
certainly produce deadlocks.  This applies to both setting the properties on 
ExtComponentContext or returning a properties map.

If ExtComponentContext reliably provided a change counter and a compareAndSet 
method then it could be used in e.g.

{code}
int cc;
Dictionary newProps;
do {
  cc = etc.getChangeCount();
 newProps = new Hashtable<>(ecc.getProperties());
 //update properties
} while (!ecc.compareAndSet(cc, newProps)}
{code}

I don't think this can be implemented unless ServiceRegistration provides the 
same API.  Certainly the felix ServiceRegistration implementation is not thread 
safe.



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

Re: SVN query when updating Felix CMS

[Konrad Windszus]

I reported the same issue for Apache Sling already in 
https://issues.apache.org/jira/browse/INFRA-13980. Feel free to vote/watch.
The certificate has been updated recently and it seems the CA is not (yet) in 
all trust stores.
Konrad
> On 24. Apr 2017, at 14:47, dav...@apache.org wrote:
> 
> Hi infra,
> 
> When I update the Felix CMS using the 'Update' link on the page I'm getting
> the following message on the web page:
> 
> "Update complete
> 
> Status
> 
> Updating 'usr/local/cms/wc/felix/davidb-NVWGRt/trunk':
> Error validating server certificate for 'https://svn.apache.org:443':
> - The certificate is not issued by a trusted authority. Use the
>   fingerprint to validate the certificate manually!
> Certificate information:
> - Hostname: *.apache.org
> - Valid: from Fri, 21 Apr 2017 00:00:00 GMT until Sat, 20 Jul 2019
> 23:59:59 GMT
> - Issuer: www.ssl.com, SSL.com, US
> - Fingerprint: 2d:97:67:d9:2e:20:ee:07:3d:26:da:97:a6:43:36:5f:71:8e:94:19
> (R)eject, accept (t)emporarily or accept (p)ermanently? svn: E175002:
> Unable to connect to a repository at URL '
> https://svn.apache.org/repos/asf/felix/site'
> svn: E175002: OPTIONS of 'https://svn.apache.org/repos/asf/felix/site':
> Server certificate verification failed: issuer is not trusted (
> https://svn.apache.org)
> [Edit] [Browse] [Diff]"
> 
> I'm not sure what happened, maybe the SSL cert was updated or something. I
> also get this locally, but there I can simply accept this by responding.
> Does anyone know how we can do this in the CMS given that there is no way
> to anwer with 'R, t or p' to the question?
> 
> Thanks!
> 
> David

SVN query when updating Felix CMS

[davidb]

Hi infra,

When I update the Felix CMS using the 'Update' link on the page I'm getting
the following message on the web page:

"Update complete

Status

Updating 'usr/local/cms/wc/felix/davidb-NVWGRt/trunk':
Error validating server certificate for 'https://svn.apache.org:443':
 - The certificate is not issued by a trusted authority. Use the
   fingerprint to validate the certificate manually!
Certificate information:
 - Hostname: *.apache.org
 - Valid: from Fri, 21 Apr 2017 00:00:00 GMT until Sat, 20 Jul 2019
23:59:59 GMT
 - Issuer: www.ssl.com, SSL.com, US
 - Fingerprint: 2d:97:67:d9:2e:20:ee:07:3d:26:da:97:a6:43:36:5f:71:8e:94:19
(R)eject, accept (t)emporarily or accept (p)ermanently? svn: E175002:
Unable to connect to a repository at URL '
https://svn.apache.org/repos/asf/felix/site'
svn: E175002: OPTIONS of 'https://svn.apache.org/repos/asf/felix/site':
Server certificate verification failed: issuer is not trusted (
https://svn.apache.org)
[Edit] [Browse] [Diff]"

I'm not sure what happened, maybe the SSL cert was updated or something. I
also get this locally, but there I can simply accept this by responding.
Does anyone know how we can do this in the CMS given that there is no way
to anwer with 'R, t or p' to the question?

Thanks!

David

Re: [VOTE] Release Apache Felix Bundle Repository 2.0.10

[davidb]

With 5 +1s and no other votes this vote passes. I've promoted the artifacts
and will update the download page.

David

On 24 April 2017 at 12:21, Pierre De Rop  wrote:

> hi;
>
> +1
> Pierre
>
>
> On Mon, Apr 24, 2017 at 12:05 PM,  wrote:
>
>> Here's my +1
>>
>> David
>>
>> On 21 April 2017 at 11:33,  wrote:
>>
>> > Hi all,
>> >
>> > We solved 8 issues in org.apache.felix.bundlerepository-2.0.10:
>> > https://issues.apache.org/jira/browse/FELIX/fixforversion/12335500
>> >
>> > Staging repository:
>> > https://repository.apache.org/content/repositories/orgapachefelix-1176
>> >
>> > 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 1176 check-bundlerepository-2.0.10
>> >
>> > 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.
>> >
>> > Best regards,
>> >
>> > David
>> >
>>
>
>

adaptTo() 2017 Conference in Berlin - CfP extended

[Stefan Seifert]

Good morning everyone,

We are extending our Call for Papers by another two weeks. The new deadline is 
May 6.
So, if you would like to be a speaker, please visit http://adapt.to/cfp - 
and/or if you know any other potential speakers, please send them our way.

We will be the only (non-virtual) Sling/AEM Developer conference this year and 
we want to give everyone the chance to contribute.

With this in mind, we also advise you to buy tickets as early as possible.

Kind regards on behalf of the adaptTo() Team,
stefan

Re: [VOTE] Release Apache Felix Bundle Repository 2.0.10

[Pierre De Rop]

hi;

+1
Pierre


On Mon, Apr 24, 2017 at 12:05 PM,  wrote:

> Here's my +1
>
> David
>
> On 21 April 2017 at 11:33,  wrote:
>
> > Hi all,
> >
> > We solved 8 issues in org.apache.felix.bundlerepository-2.0.10:
> > https://issues.apache.org/jira/browse/FELIX/fixforversion/12335500
> >
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachefelix-1176
> >
> > 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 1176 check-bundlerepository-2.0.10
> >
> > 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.
> >
> > Best regards,
> >
> > David
> >
>

Re: [VOTE] Release Apache Felix Bundle Repository 2.0.10

[davidb]

Here's my +1

David

On 21 April 2017 at 11:33,  wrote:

> Hi all,
>
> We solved 8 issues in org.apache.felix.bundlerepository-2.0.10:
> https://issues.apache.org/jira/browse/FELIX/fixforversion/12335500
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachefelix-1176
>
> 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 1176 check-bundlerepository-2.0.10
>
> 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.
>
> Best regards,
>
> David
>

[jira] [Resolved] (FELIX-5620) Bundle start/stop buttons are missing

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved FELIX-5620.
-
Resolution: Fixed

Fixed in rev 1792427
The json serialization was return String type values for the state instead of 
integers/numbers

> Bundle start/stop buttons are missing
> -
>
> Key: FELIX-5620
> URL: https://issues.apache.org/jira/browse/FELIX-5620
> Project: Felix
>  Issue Type: Bug
>  Components: Web Console
>Affects Versions: webconsole-4.3.0
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>Priority: Blocker
> Fix For: webconsole-4.3.2
>
>
> The bundle list does not show the start/stop buttons for a bundle anymore



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

[jira] [Created] (FELIX-5620) Bundle start/stop buttons are missing

[Carsten Ziegeler (JIRA)]

Carsten Ziegeler created FELIX-5620:
---

 Summary: Bundle start/stop buttons are missing
 Key: FELIX-5620
 URL: https://issues.apache.org/jira/browse/FELIX-5620
 Project: Felix
  Issue Type: Bug
  Components: Web Console
Affects Versions: webconsole-4.3.0
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
Priority: Blocker
 Fix For: webconsole-4.3.2


The bundle list does not show the start/stop buttons for a bundle anymore



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