Re: [VOTE] framework 5.6.0 and related subproject releases

[Thomas Watson]

+1 non-binding

On Sep 22, 2016 10:53 AM, "Raymond Auge"  wrote:

> +1 (non-binding)
>
> On Thu, Sep 22, 2016 at 11:35 AM, David Bosschaert <
> david.bosscha...@gmail.com> wrote:
>
> > +1
> >
> > David
> >
> > On 22 September 2016 at 14:25, Karl Pauls  wrote:
> >
> > > I would like to call a vote on the following subproject releases:
> > >
> > > resolver 1.10.0
> > > framework  5.6.0
> > > framework.security 2.6.0
> > > main 5.6.0
> > > main.distribution 5.6.0
> > >
> > > The main changelogs are in jira and at:
> > > https://svn.apache.org/repos/asf/felix/releases/org.apache.
> > > felix.resolver-1.10.0/doc/changelog.txt
> > > https://svn.apache.org/repos/asf/felix/releases/org.apache.
> > > felix.framework-5.6.0/doc/changelog.txt
> > >
> > > Staging repositories:
> > > https://repository.apache.org/content/repositories/
> orgapachefelix-1139/
> > >
> > > 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 1139 /tmp/felix-staging
> > >
> > > Please vote to approve this release:
> > >
> > > [ ] +1 Approve the release
> > > [ ] -1 Veto the release (please provide specific comments)
> > >
> >
>
>
>
> --
> *Raymond Augé* 
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* 
>  (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance 
> (@OSGiAlliance)
>

[jira] [Created] (FELIX-5357) cfg and jar file deletion inconsistency when Karaf is offline

[Scott Leschke (JIRA)]

Scott Leschke created FELIX-5357:


 Summary: cfg and jar file deletion inconsistency when  Karaf is 
offline
 Key: FELIX-5357
 URL: https://issues.apache.org/jira/browse/FELIX-5357
 Project: Felix
  Issue Type: Bug
Affects Versions: fileinstall-3.5.4
 Environment: Karaf 4.0.6.
Reporter: Scott Leschke
Priority: Minor


if a .cfg file is deleted while Karaf is running, the associated configuration 
record is deleted from Configuration Admin as well.  OTOH, if the file is 
deleted while Karaf is NOT running, the associated configuration record is 
retained when Karaf is started again. I would have expected that records for 
files that no longer exist would be deleted when configuration admin service 
starts.

Likewise, a similar behavior exists with .jar files. If a jar file is deleted 
while Karaf is running, the corresponding bundle is uninstalled. If the jar 
file is deleted while Karaf is offline, the corresponding bundle still exists 
in it's previous state when Karaf starts up again.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] framework 5.6.0 and related subproject releases

[Raymond Auge]

+1 (non-binding)

On Thu, Sep 22, 2016 at 11:35 AM, David Bosschaert <
david.bosscha...@gmail.com> wrote:

> +1
>
> David
>
> On 22 September 2016 at 14:25, Karl Pauls  wrote:
>
> > I would like to call a vote on the following subproject releases:
> >
> > resolver 1.10.0
> > framework  5.6.0
> > framework.security 2.6.0
> > main 5.6.0
> > main.distribution 5.6.0
> >
> > The main changelogs are in jira and at:
> > https://svn.apache.org/repos/asf/felix/releases/org.apache.
> > felix.resolver-1.10.0/doc/changelog.txt
> > https://svn.apache.org/repos/asf/felix/releases/org.apache.
> > felix.framework-5.6.0/doc/changelog.txt
> >
> > Staging repositories:
> > https://repository.apache.org/content/repositories/orgapachefelix-1139/
> >
> > 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 1139 /tmp/felix-staging
> >
> > Please vote to approve this release:
> >
> > [ ] +1 Approve the release
> > [ ] -1 Veto the release (please provide specific comments)
> >
>



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

Re: [VOTE] framework 5.6.0 and related subproject releases

[David Bosschaert]

+1

David

On 22 September 2016 at 14:25, Karl Pauls  wrote:

> I would like to call a vote on the following subproject releases:
>
> resolver 1.10.0
> framework  5.6.0
> framework.security 2.6.0
> main 5.6.0
> main.distribution 5.6.0
>
> The main changelogs are in jira and at:
> https://svn.apache.org/repos/asf/felix/releases/org.apache.
> felix.resolver-1.10.0/doc/changelog.txt
> https://svn.apache.org/repos/asf/felix/releases/org.apache.
> felix.framework-5.6.0/doc/changelog.txt
>
> Staging repositories:
> https://repository.apache.org/content/repositories/orgapachefelix-1139/
>
> 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 1139 /tmp/felix-staging
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
>

Re: [VOTE] framework 5.6.0 and related subproject releases

[Guillaume Nodet]

+1

2016-09-22 15:25 GMT+02:00 Karl Pauls :

> I would like to call a vote on the following subproject releases:
>
> resolver 1.10.0
> framework  5.6.0
> framework.security 2.6.0
> main 5.6.0
> main.distribution 5.6.0
>
> The main changelogs are in jira and at:
> https://svn.apache.org/repos/asf/felix/releases/org.apache.
> felix.resolver-1.10.0/doc/changelog.txt
> https://svn.apache.org/repos/asf/felix/releases/org.apache.
> felix.framework-5.6.0/doc/changelog.txt
>
> Staging repositories:
> https://repository.apache.org/content/repositories/orgapachefelix-1139/
>
> 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 1139 /tmp/felix-staging
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
>



-- 

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Re: [VOTE] framework 5.6.0 and related subproject releases

[Carsten Ziegeler]

+1

 

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

Re: [VOTE] framework 5.6.0 and related subproject releases

[Pierre De Rop]

+1 (binding)

checked the signatures, built the sources, made some basic tests.

thanks Karl;
/Pierre

On Thu, Sep 22, 2016 at 3:25 PM, Karl Pauls  wrote:

> I would like to call a vote on the following subproject releases:
>
> resolver 1.10.0
> framework  5.6.0
> framework.security 2.6.0
> main 5.6.0
> main.distribution 5.6.0
>
> The main changelogs are in jira and at:
> https://svn.apache.org/repos/asf/felix/releases/org.apache.
> felix.resolver-1.10.0/doc/changelog.txt
> https://svn.apache.org/repos/asf/felix/releases/org.apache.
> felix.framework-5.6.0/doc/changelog.txt
>
> Staging repositories:
> https://repository.apache.org/content/repositories/orgapachefelix-1139/
>
> 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 1139 /tmp/felix-staging
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
>

[VOTE] framework 5.6.0 and related subproject releases

[Karl Pauls]

I would like to call a vote on the following subproject releases:

resolver 1.10.0
framework  5.6.0
framework.security 2.6.0
main 5.6.0
main.distribution 5.6.0

The main changelogs are in jira and at:
https://svn.apache.org/repos/asf/felix/releases/org.apache.felix.resolver-1.10.0/doc/changelog.txt
https://svn.apache.org/repos/asf/felix/releases/org.apache.felix.framework-5.6.0/doc/changelog.txt

Staging repositories:
https://repository.apache.org/content/repositories/orgapachefelix-1139/

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 1139 /tmp/felix-staging

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Veto the release (please provide specific comments)

[jira] [Commented] (FELIX-5356) Component Factory and CM factory Configurations behave badly

[Thomas Watson (JIRA)]

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

Thomas Watson commented on FELIX-5356:
--

Yes, that is the approach I was going to use.  Basically just ignore factory 
configurations for factory components, otherwise the rest of the code/behavior 
with respect to singleton configuration stays the same.

> Component Factory and CM factory Configurations behave badly
> 
>
> Key: FELIX-5356
> URL: https://issues.apache.org/jira/browse/FELIX-5356
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-2.0.6
> Environment: All
>Reporter: Thomas Watson
>Priority: Minor
>
> This is a corner case and a minor issue in my opinion.  The specification 
> really only mentions the following with respect to what should happen with 
> factory components and CM factory configurations:
> {quote}
> A factory configuration must not be used if the component is a factory 
> component. This is because SCR is not free to create component configurations 
> as necessary to support multiple Configurations. When SCR detects this 
> condition, it must log an error message with the Log Service,
> if present, and ignore the component description.
> {quote}
> At face value it seems to suggest that any CM factory configurations must be 
> ignored when they match the factory component PID.  But the last sentence 
> also makes a strong assertion that the component description must be ignored 
> if matching factory configurations are detected while discovering a factory 
> component description.  This seems overkill to me.  Why not just ignore the 
> factory configurations?  Why must the factory component description be 
> ignored altogether?
> The other issue is that if a matching factory configuration is created later, 
> after a ComponentFactory has been registered and a ComponentInstance has been 
> created (with newInstance) then felix SCR will dispose of the 
> ComponentInstance.  In this case the component instance did not specify an 
> update method.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (FELIX-4227) There should be a way to remove packages from the system package exports without redefining all exports

[Karl Pauls (JIRA)]

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

Karl Pauls updated FELIX-4227:
--
Fix Version/s: (was: framework-5.6.0)

> There should be a way to remove packages from the system package exports 
> without redefining all exports
> ---
>
> Key: FELIX-4227
> URL: https://issues.apache.org/jira/browse/FELIX-4227
> Project: Felix
>  Issue Type: New Feature
>  Components: Framework
>Affects Versions: framework-4.2.1
>Reporter: Christian Schneider
>
> Currently you define the system package exports using:
> org.osgi.framework.system.packages: allows to completely redefine the packages
> org.osgi.framework.system.packages.extra: allows to add packages to the 
> system package exports
> I am missing a way to mostly keep the exports as is but remove some package 
> and add some others.
> So some property like "org.osgi.framework.system.packages.remove" would be 
> nice.
> A typical scenario is cxf that wants to replace some JRE API and IMPLs with 
> their own jars.
> Currently this can only be solved by replacing all exports. To do this 
> correctly the exports even have to be different for each jdk version. So it 
> is a lot of effort.
> The requested feature would be most useful if it is a OSGi standard property 
> so it works on all frameworks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (FELIX-4018) System properties in conf/system.properties should be overridable from the command-line

[Karl Pauls (JIRA)]

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

Karl Pauls updated FELIX-4018:
--
Fix Version/s: (was: framework-5.6.0)
   framework-5.8.0

> System properties in conf/system.properties should be overridable from the 
> command-line
> ---
>
> Key: FELIX-4018
> URL: https://issues.apache.org/jira/browse/FELIX-4018
> Project: Felix
>  Issue Type: Improvement
>  Components: Main
>Affects Versions: framework-4.2.0
>Reporter: Jad Naous
>Priority: Minor
> Fix For: framework-5.8.0
>
>
> System properties set in conf/system.properties currently override whatever 
> is set on the command-line. It would be much more intuitive and user-friendly 
> if it were the other way around (i.e. Main should not override any properties 
> from system.properties that are already set).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (FELIX-5348) [HTTP Service] Location not URL Encoded during Redirect

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler closed FELIX-5348.
---

> [HTTP Service] Location not URL Encoded during Redirect
> ---
>
> Key: FELIX-5348
> URL: https://issues.apache.org/jira/browse/FELIX-5348
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Reporter: Dominique Jäggi
>
> With SSL forwarding enabled, a _sendRedirect_ will not properly encode the 
> resulting location header value:
> {noformat}
> > GET /?$$bla$$=test HTTP/1.1
> > Host: localhost:4502
> > Authorization: Basic YWRtaW46YWRtaW4=
> > User-Agent: curl/7.49.1
> > Accept: */*
> > X-Forwarded-SSL:on
> >
> < HTTP/1.1 302 Found
> < Location: https://localhost/index.html?$$bla$$=test
> < Transfer-Encoding: chunked
> <
> * Connection #0 to host localhost left intact
> {noformat}
> Non-SSL-forwarded requests result in properly encoded location header.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (FELIX-5348) [HTTP Service] Location not URL Encoded during Redirect

[JIRA]

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

Dominique Jäggi resolved FELIX-5348.

Resolution: Incomplete

As the client calling setHeader or sendRedirect must do the encoding, not the 
filter itself, this can be closed.

> [HTTP Service] Location not URL Encoded during Redirect
> ---
>
> Key: FELIX-5348
> URL: https://issues.apache.org/jira/browse/FELIX-5348
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Reporter: Dominique Jäggi
>
> With SSL forwarding enabled, a _sendRedirect_ will not properly encode the 
> resulting location header value:
> {noformat}
> > GET /?$$bla$$=test HTTP/1.1
> > Host: localhost:4502
> > Authorization: Basic YWRtaW46YWRtaW4=
> > User-Agent: curl/7.49.1
> > Accept: */*
> > X-Forwarded-SSL:on
> >
> < HTTP/1.1 302 Found
> < Location: https://localhost/index.html?$$bla$$=test
> < Transfer-Encoding: chunked
> <
> * Connection #0 to host localhost left intact
> {noformat}
> Non-SSL-forwarded requests result in properly encoded location header.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)